原始文献 / 邮件 / Bitcoin P2P e-cash paper
Bitcoin P2P e-cash paper
Cryptography Mailing List · 2008-11-17 17:24:43 UTC
James A. Donald 写道：
> > 幸运的是，我们只需要为
> > 当前最佳分支维护一个
> > 待处理交易池。
>
> 这就要求我们知道，也就是说一个诚实
> 守规矩的对等方，其通信和数据存储
> 都工作正常，知道当前的最佳分支是什么——
我的意思是，一个节点只为它所拥有的最佳分支维护待处理交易池。就是它当前认为是最佳的那条分支。这正是它将尝试在其上生成区块的分支，也是它需要这个池的全部用途。
> 广播可能几乎完全
> 可靠。
与其假设每条消息至少送达一次，
我们必须设计一种机制，使信息即使
通过经常丢失的消息传递也能送达。
我认为点对点网络的广播机制我已经想清楚了。
每个节点向其邻居发送一份库存清单，列出它拥有的新区块和交易的哈希。邻居们请求它们还没有的条目。如果超时后条目仍未送达，它们会向另一个拥有该条目的邻居请求。由于所有或大多数邻居最终都会拥有每个条目，即使与某个邻居的通信出了问题，它们也可以逐个尝试从其他邻居那里获取。
这种清单—请求—数据（inventory-request-data）方案会引入一点延迟，但通过让多余的数据块不进入传输队列、节省带宽，最终反而有助于提速。
你已经有了一个
大纲和设计方案，这是很大的进步，
但魔鬼藏在细节里。
我相信在过去一年半的编码过程中，我已经把所有这些小细节都理清了，而且细节确实很多。论文中没有涉及功能层面的细节，但源代码很快就会发布。我把主要文件发给你了。（目前可应要求提供，完整版即将发布）
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
英文原文
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
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com