谢谢，Satoshi，
Thanks Satoshi,
我昨天试了这个应用。通过 Wine 运行时似乎表现相当不错（我在 MacOS 上试的，不过它应该也能在 Linux 上运行；下周回去上班时，我会再试）。
I tried the app yesterday. It seems to work pretty well running on Wine (I tried it on MacOS but it should run on Linux too, and will try that next week when I am back at work).
右下角有一个区块计数，会迅速增加，然后停下来。这是全局链的长度吗？如果是，它增加得似乎太快了。还是说，这是尝试过、却没有找到部分碰撞的创世区块数量？我不确定，这种时停时走是正常现象，还是通过模拟环境运行造成的故障。我觉得最有可能的解释是：它表示全局链的长度，刚开始迅速增加，是因为软件正在下载链上之前的区块，并验证它们是否有效。
In the lower right hand corner it has a block count which increases rapidly and then stops. Is this the length of the global chain? It seems to advance far too fast for that. Or is this the number of genesis blocks that have been tried but did not result in a partial collision? I'm not sure if the way it stops and starts is expected, or some glitch caused by it running under emulation. 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.
关于买卖双方的使用体验，我理解按当前设置，全局链每小时大约增加 6 至 7 个区块。如果假定 0.1% 是个可以接受的风险，那么 z=5，因此一笔交易必须等待接近一小时，才能在链中稳固下来。网页内容、虚拟商品等微支付，本来就要求很低的额外成本；等待一小时似乎是个相当大的障碍。
With regards to the buyer/seller experience, I understand that the global chain advances at about 6-7 blocks per hour under the current settings. 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.
我理解，各节点会在没有协调的情况下尝试寻找工作量证明，来延长全局链。不过，下面这句话：
I understand that nodes attempt to find a POW to advance the global chain in an uncoordinated fashion. This sentence however:
引用白皮书Satoshi Nakamoto来源 ↗“如果大多数 CPU 算力由诚实节点控制，诚实链就会增长得最快，并超过任何竞争链。”
"If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains."
让我感到困惑。因为在我看来，诚实链要比攻击者用一个 CPU 维护的链增长得更快，唯一的办法似乎是：把寻找部分碰撞时需要扫描的密钥空间，平均分配给参与的诚实节点。这样，找到碰撞的速度才会与节点数量成正比。但我没有看到任何关于这种工作划分的讨论，而它显然会增加复杂度。类似地：
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. Likewise:
引用白皮书Satoshi Nakamoto来源 ↗“为了应对硬件速度的提高，以及人们运行节点的意愿随时间变化，工作量证明的难度由移动平均确定，目标是每小时平均生成一定数量的区块。如果生成得太快，难度就会提高。”
"To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases."
每个区块所需的难度，是怎样在网络中传达并达成一致的？
How is the required difficulty of each block communicated through the network and agreed upon?
再次感谢。我还有更多问题，不过一封邮件问这些已经够多了 :) 找个时候，我很乐意把这些讨论整理成类似常见问题的文档。如果这些问题显得太基础，还请见谅。
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.
—mike
-mike
引用的来信Mike Hearn来源 ↗我觉得最有可能的解释是：这是全局链的长度，而开始时快速增长，是因为软件正在下载并验证链中已有的区块是否有效。
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.
对。我正在想更清楚的表述，也许用“%d 个网络区块”或者“%d 个区块的链”。
Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
引用的来信Mike Hearn来源 ↗如果我们认为 0.1% 是可以接受的风险率，那么 z=5，因此任何交易都必须等待将近一小时，才能在链中确定下来。用于网页内容或虚拟商品等的微支付，顾名思义就需要很低的额外负担，等一小时似乎是个相当大的障碍。
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.
计算实际风险时，要把 0.1% 乘以买家是一个拥有庞大计算机网络的攻击者的概率。
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.
目前，商家会接受一定比例的坏账。我相信，即使只有 1 个、甚至 0 个确认区块，风险也会远低于已验证信用卡交易的拒付率。
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.
对不等待确认区块的商家，常见的骗局会是先向商家付款，然后赶在商家的交易副本之前，迅速尝试向网络传播一笔双重支付。商家可以广播自己的交易，再监测网络中是否出现任何双重支付副本。窃贼无法在监测期间广播，否则商家的节点就会收到副本。商家只需监测一两分钟，直到大多数网络节点拥有自己的版本，而窃贼的版本已经来不及追上并传遍大量节点。只延迟一两分钟，就能把不付款而得手的概率降到不值得行骗的程度。窃贼通常需要很高的概率免费拿到商品，才值得做。除了上述骗局，再投入大量 CPU 算力进行论文中讨论的暴力攻击，也不会显著增加窃贼的胜算。
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.
引用的来信Mike Hearn来源 ↗这一点让我困惑，因为看起来，诚实链要比攻击者用 1 个 CPU 计算的链增长得更快，唯一办法就是把寻找部分碰撞需要扫描的搜索空间，均匀划分给参与的诚实节点。这样，找到碰撞的速度才会与节点数量成正比。但我没看到任何关于这种任务划分的讨论，而这显然会增加复杂性。
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.
搜索空间非常大，有 2^256。被哈希的内容包含节点的公钥和一个随机 nonce，所以任意两个节点在同一空间重复计算的概率可以忽略不计。
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.
引用的来信Mike Hearn来源 ↗每个区块所要求的难度，是如何在网络中传播并达成一致的？
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.
引用的来信Mike Hearn来源 ↗再次感谢。我还有更多问题，不过一封邮件写这些就够了 :) 我很乐意在某个时候把这些讨论整理成类似常见问题解答的文档。如果这些问题显得太浅显，抱歉。
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.
没问题，谢谢你在 Mac Wine 上测试。
No problem, thanks for testing it on Mac Wine.
Satoshi
Satoshi
当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。
译文内容版本：d92d4652f65b。用于比对文本，不代表校对等级或更新时间。
请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交；此处不会自动发送。
Satoshi to Mike Hearn on micropayments (April 13, 2009)
