中本聪致迈克·赫恩：微支付（2009 年 4 月 13 日）
首次公开证据
打开首次公开证据我最好的猜测是——它是全局链的长度，开始时的快速增长是因为软件正在下载并验证链中先前的区块是否有效。
对。我正在想怎样措辞更清楚，也许是“%d 个网络区块”或“%d 条区块链”。
如果我们假设 0.1% 是一个合适的风险率，那么 z=5，因此任何交易都必须等待不到一小时，才能在链中稳固下来。对于 Web 内容或虚拟物品之类的微支付，按定义这类支付要求低开销，等待一小时似乎是相当大的障碍。
对于实际风险，将 0.1% 乘以买方是拥有庞大计算机网络的攻击者的概率。
对于微支付，你可以放心立即接受付款。支付金额太小，不值得付出努力去窃取。微支付几乎总是用于知识产权，商家不会因此遭受实物损失。任何试图窃取微支付的人可能本来就不是付费客户；如果他们想窃取知识产权，他们可以使用文件共享网络。
目前，企业会接受一定的坏账率。我相信，等待 1 个甚至 0 个确认区块的风险，会远低于已验证信用卡交易的退款撤销率。
对不等待确认区块的商家来说，通常的诈骗方式是先向商家发送付款，然后在商家的副本之前迅速向网络传播双重支付。商家可以广播自己的交易，然后监视网络，看是否有任何双重支付副本。小偷不能在监视期间广播，否则商家的节点就会收到副本。商家只需监视一两分钟，直到大多数网络节点都拥有他的版本，小偷的版本已经来不及追上并抵达许多节点。只需延迟一两分钟，就可以把不付款逃脱的机会降到低得不值得诈骗。小偷通常需要很高的免费获得物品的概率，才会觉得值得。在上述诈骗之外，再投入大量 CPU 算力实施论文中讨论的暴力攻击，也不会大幅增加小偷的机会。
任何能授予某种访问权限的东西，例如需要一段时间下载的内容、网站访问权、Web 托管、订阅或服务，如果交易被拒绝，都可以在几分钟后取消。
这让我感到困惑，因为看起来诚实链唯一能比 1 个攻击 CPU 所处理的链增长得更快的方式，就是将用于寻找部分碰撞的密钥空间平均分片给参与的诚实节点。这样，找到碰撞的速度就会与节点数量成正比。然而我没有看到任何关于这种工作分片的讨论，而这显然会增加复杂性。
密钥空间非常巨大，为 2^256。被哈希的内容包括节点的公钥和一个随机 nonce，因此任意两个节点在同一空间重复工作的概率微乎其微。
每个区块所需的难度是如何通过网络传达并达成一致的？
它不会被传达。公式硬编码在程序中，每个节点都会进行相同的计算，以得知下一个区块所需的难度。如果有人偏离公式，他们的区块就不会被多数接受。
再次感谢。我还有更多问题，但一封邮件问这些就够了 😃 以后某个时候我很乐意把这些讨论总结成类似 FAQ 的文档。如果这些问题看起来很琐碎，请见谅。
没问题，谢谢你在 Mac Wine 上测试它。
Satoshi
英文原文
展开英文原文
My best guess - it is the length of the global chain, and the rapid advance at the start is as the software downloads and verifies the preceding blocks in the chain as being valid.
Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
If we assume that 0.1% is a good risk rate, then z=5 thus any transaction must wait a bit less than an hour before being solidified in the chain. As micropayments for things like web content or virtual goods are by definition something that requires low overhead, waiting an hour seems like quite a significant hurdle.
For the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers.
For micropayments, you can safely accept the payment immediately. The size of the payment is too small for the effort to steal it. Micropayments are almost always for intellectual property, where there's no physical loss to the merchant. Anyone trying to steal a micropayment would probably not be a paying customer anyway, and if they want to steal intellectual property they can use the file sharing networks.
Currently, businesses accept a certain chargeoff rate. I believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions.
The usual scam against a merchant that doesn't wait for confirming blocks would be to send a payment to a merchant, then quickly try to propagate a double-spend to the network before the merchant's copy. What the merchant can do is broadcast his transaction and then monitor the network for any double-spend copies. The thief would not be able to broadcast during the monitoring period or else the merchant's node would receive a copy. The merchant would only have to monitor for a minute or two until most of the network nodes have his version and it's too late for the thief's version to catch up and reach many nodes. With just a minute or two delay, the chance of getting away without paying could be made much too low to scam. A thief usually needs a high probability of getting an item for free to make it worthwhile. Using a lot of CPU power to do the brute force attack discussed in the paper in addition to the above scam would not increase the thief's chances very much.
Anything that grants access to something, like something that takes a while to download, access to a website, web hosting, a subscription or service, can be cancelled a few minutes later if the transaction is rejected.
is confusing for me, because it appears the only way the honest chain can grow faster than a chain worked on by 1 attacking cpu is if the keyspace to scan looking for a partial collision is sharded evenly amongst the participating honest nodes. That way the speed at which collisions are found would be proportional to the number of nodes. Yet I don't see any discussion of such work sharding, which obviously adds complexity.
The keyspace is huge, 2^256. The thing being hashed includes the node's public key and a random nonce, so the chance of any two nodes duplicating work on the same space is negligible.
How is the required difficulty of each block communicated through the network and agreed upon?
It's not communicated. The formula is hardcoded in the program and every node does the same calculation to know what difficulty is required for the next block. If someone diverged from the formula, their block would not be accepted by the majority.
Thanks once again. I have yet more questions but this is enough for one email 😃 I will be happy to summarize these discussions into an FAQ-like document at some point. Apologies if the questions seem trivial.
No problem, thanks for testing it on Mac Wine.
Satoshi