SN-10010 附来源、原文与上下文。
Hal Finney 写道：
Hal Finney wrote:
引用的来信Hal Finney来源 ↗文中提到，如果一笔广播的交易没有到达所有节点，也没关系，因为它很快就会进入区块链。这是怎样发生的——如果创建“下一个”区块的节点（第一个找到 hashcash 碰撞的节点）没收到这笔交易，随后又有几个区块由同样没收到这笔交易的节点添加上去，会怎么样？所有收到它的节点，是否都会一直保留这笔交易，希望等自己足够幸运，成为找到下一个碰撞的节点时，把它纳入区块？
it is mentioned that if a broadcast transaction does not reach all nodes, it is OK, as it will get into the block chain before long. How does this happen - what if the node that creates the "next" block (the first node to find the hashcash collision) did not hear about the transaction, and then a few more blocks get added also by nodes that did not hear about that transaction? Do all the nodes that did hear it keep that transaction around, hoping to incorporate it into a block once they get lucky enough to be the one which finds the next collision?
是的，节点会把交易保留在工作集中，直到它们进入一个区块。如果一笔交易到达了 90% 的节点，那么每次找到新区块时，它就有 90% 的概率被纳入其中。
Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.
引用的来信Hal Finney来源 ↗或者举个例子，如果一个节点保留着两条或更多条链，等着看哪条增长最快，这时链 A 收到一个区块，其中包含对链 B 中某个币的双重支付，会怎么样？会不会检查这种情况？（如果有人双重支付，而两组不同的节点分别听到了使用同一个币的两笔不同交易，就可能出现这种情况。）
Or for example, what if a node is keeping two or more chains around as it waits to see which grows fastest, and a block comes in for chain A which would include a double-spend of a coin that is in chain B? Is that checked for or not? (This might happen if someone double-spent and two different sets of nodes heard about the two different transactions with the same coin.)
不需要检查这种情况。哪个分支最终领先，其中的交易就有效，另一个分支中的交易就无效。如果有人这样尝试双重支付，总会有且只有一次支付变得有效，其他的都无效。
That does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.
交易接收方通常需要将交易保留大约一小时或更久，留出时间，让这种可能的情况得到解决。他们仍然可以立即把币再次花出去，但在发货等操作之前应该等待。
Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.
引用的来信Hal Finney来源 ↗我也不完全理解，一个能调集比所有诚实参与者更多算力的强大攻击者，究竟如何实现双重支付或取消交易。我知道他可以创建新区块，把它们接起来，形成最长链，但他怎么能删除或添加链上的旧交易？攻击者发出新区块时，诚实节点不能进行一致性检查，确认没有任何内容被删除吗？如果能进一步解释这种攻击，会更有助于判断攻击者从中得到的收益，与单纯使用自己的算力诚实地铸造新币相比如何。
I also don't understand exactly how double-spending, or cancelling transactions, is accomplished by a superior attacker who is able to muster more computing power than all the honest participants. I see that he can create new blocks and add them to create the longest chain, but how can he erase or add old transactions in the chain? As the attacker sends out his new blocks, aren't there consistency checks which honest nodes can perform, to make sure that nothing got erased? More explanation of this attack would be helpful, in order to judge the gains to an attacker from this, versus simply using his computing power to mint new coins honestly.
攻击者不是在末尾添加区块。他必须回头重做包含自己交易的区块，以及之后的所有区块，还包括他做这些工作时网络继续添加到末尾的所有新区块。他是在改写历史。一旦他的分支更长，它就成为新的有效分支。
The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.
这涉及一个关键点。即使所有在场的人都看到了这些小动作，也无法利用这个事实。
This touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact.
必须始终严格地把最长链视为有效链。在场的节点可能记得，一个分支先出现，后来被另一个取代，但它们无法向不在场的节点证明这一点。不能让节点分成几个小派别：一派坚持自己认为最早的分支，一派先看到了另一个分支，还有一派后来才加入，根本没看到发生了什么。基于 CPU 算力的工作量证明投票必须拥有最终决定权。让所有人保持一致的唯一办法，就是无论发生什么，都相信最长链始终有效。
It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.
引用的来信Hal Finney来源 ↗至于支付交易，币的接收方需要进行哪些检查？她需要追溯这个币的完整转手历史，确认列表中的每笔交易确实都已链接到“时间戳”区块链中吗？还是只需要检查最近的一笔？
As far as the spending transactions, what checks does the recipient of a coin have to perform? Does she need to go back through the coin's entire history of transfers, and make sure that every transaction on the list is indeed linked into the "timestamp" block chain? Or can she just do the latest one?
接收方只需要向前验证到区块链中足够久远的位置，通常只需要追溯 2 笔交易的深度。再早的所有交易都可以丢弃。
The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.
引用的来信Hal Finney来源 ↗时间戳节点会不会检查交易，确保某个币的上一笔交易已经在链上，从而保证链上的所有交易都代表有效的币？
Do the timestamp nodes check transactions, making sure that the previous transaction on a coin is in the chain, thereby enforcing the rule that all transactions in the chain represent valid coins?
对，正是如此。节点收到一个区块时，会根据已有区块中的先前交易，检查其中每笔交易的签名。区块只能包含依赖于先前区块或同一区块中有效交易的交易。交易 C 可以依赖于同一区块中的交易 B，而 B 又依赖于更早区块中的交易 A。
Right, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.
引用的来信Hal Finney来源 ↗抱歉问了这么多问题，但正如我说的，这的确是一个很有前景而且很新颖的想法，我很期待看到这个概念进一步发展。如果能更侧重流程来描述这个想法，提供各种对象（币、区块、交易）的数据结构细节、消息中包含的数据，以及对系统中各种可能事件的处理步骤作出算法描述，都会很有帮助。你提到正在编写一个实现，但我认为下一步如果能给出更正式的系统文字描述，会很有帮助。
Sorry about all the questions, but as I said this does seem to be a very promising and original idea, and I am looking forward to seeing how the concept is further developed. It would be helpful to see a more process oriented description of the idea, with concrete details of the data structures for the various objects (coins, blocks, transactions), the data which is included in messages, and algorithmic descriptions of the procedures for handling the various events which would occur in this system. You mentioned that you are working on an implementation, but I think a more formal, text description of the system would be a helpful next step.
感谢你的提问。实际上，我做这件事的顺序有点反过来了。我必须先写出全部代码，才能确信自己能解决每一个问题，然后才写论文。我想我应该能先发布代码，再写出详细规范。你自行补全的那些细节，绝大多数假设已经是对的了。
I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks.
Satoshi Nakamoto
Satoshi Nakamoto
