比特币：点对点电子现金论文
原始发布页
打开来源页面查看 1 个交叉存档
James A. Donald 写道：
好在，只需要为当前最佳分支保留一个 待处理交易池。
这要求我们知道，也就是说，一个诚实且 行为良好的对等节点，在通信和数据存储 运作正常的情况下，知道当前最佳分支是什么——
我的意思是，一个节点只需为它所拥有的最佳分支保留待处理交易池。也就是它当前认为最好的那个分支。它会尝试基于该分支创建一个区块，而这正是它需要这个池的全部原因。
广播很可能几乎完全 可靠。
与其假定每条消息至少能到达 一次，我们必须设计一种机制，使得即便承载 信息的消息经常无法到达， 信息仍能送达。
我想我已经解决了对等网络的广播机制。
每个节点都会向其邻居发送一份清单，其中列出它所拥有的新区块和交易的哈希。邻居会请求那些尚未拥有的项目。如果某个项目在超时后仍未传来，它们就会向另一个拥有该项目的邻居请求。由于所有或大多数邻居最终都应该拥有每个项目，即使与其中一个邻居的通信出了岔子，它们也可以逐个尝试，从其他任意邻居那里获取。
这种“清单—请求—数据”方案会引入少许延迟，但通过避免多余的数据块进入传输队列并节省带宽，它最终反而更有助于提升速度。
你已经有了这种设计的概要 和提案，这是向前迈出的一大步， 但魔鬼藏在细节里。
我相信，在过去一年半编写代码的过程中，我已经推敲过所有这些细节，而这样的细节有很多。论文没有涵盖功能细节，但源代码很快就会发布。我把主要文件发给你了。 （目前可索取，很快会完整发布）
中本聪
英文原文
展开英文原文
James A. Donald wrote:
Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch.
This requires that we know, that is to say an honest well behaved peer whose communications and data storage is working well knows, what the current best branch is -
I mean a node only needs the pending-tx pool for the best branch it has. The branch that it currently thinks is the best branch. That's the branch it'll be trying to make a block out of, which is all it needs the pool for.
Broadcasts will probably be almost completely reliable.
Rather than assuming that each message arrives at least once, we have to make a mechanism such that the information arrives even though conveyed by messages that frequently fail to arrive.
I think I've got the peer networking broadcast mechanism covered.
Each node sends its neighbours an inventory list of hashes of the new blocks and transactions it has. The neighbours request the items they don't have yet. If the item never comes through after a timeout, they request it from another neighbour that had it. Since all or most of the neighbours should eventually have each item, even if the coms get fumbled up with one, they can get it from any of the others, trying one at a time.
The inventory-request-data scheme introduces a little latency, but it ultimately helps speed more by keeping extra data blocks off the transmit queues and conserving bandwidth.
You have an outline and proposal for such a design, which is a big step forward, but the devil is in the little details.
I believe I've worked through all those little details over the last year and a half while coding it, and there were a lot of them. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)
Satoshi Nakamoto