原始文献 / 邮件 / Bitcoin P2P e-cash paper
Bitcoin P2P e-cash paper
Cryptography Mailing List · 2008-11-14 18:55:35 UTC
Hal Finney 写道：
> 我认为节点有必要为每个候选链分别维护一份待处理交易列表。
> ……人们也可能会问……一个节点在同一时间平均必须跟踪多少条候选链？
幸运的是，只需要为当前最优分支维护一个待处理交易池。当最优分支有新区块到来时，ConnectBlock 会把该区块的交易从 pending-tx 池中移除。如果另一条分支变长，它会从分叉点对主分支调用 DisconnectBlock，把区块交易返回到 pending-tx 池，再对新分支调用 ConnectBlock，吸回两个分支中都包含的交易。预计这种重组会很少见，也很浅。
有了这个优化，候选分支基本不算负担。它们只是放在磁盘上，除非成为主链，否则无需理会。
或者如 James 早前提出的，如果网络广播可靠但依赖于可能缓慢的泛洪算法，这对性能有何影响？
广播很可能几乎完全可靠。如今 TCP 传输很少丢包，广播协议还有重试机制，过一段时间可以从其他节点获取数据。如果实践中广播比预期慢，可能需要增加区块间隔目标时间以避免浪费资源。我们希望区块传播通常远快于生成，否则节点会把太多时间花在过时区块上。
我计划运行一个自动化测试：计算机随机地互相发送支付，并随机丢包。
3. 比特币系统被证明对社会有用且有价值，于是节点运营者觉得自己的努力在为世界做有益的贡献（类似于各种 "@Home" 计算项目，人们自愿捐出算力做公益）。
在这种情况下，我觉得单纯的利他主义就足以维持网络正常运行。
如果我们能解释清楚，这对自由主义者观点很有吸引力。不过我更擅长写代码，不擅长写文字。
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
英文原文
Hal Finney wrote:
> I think it is necessary that nodes keep a separate
> pending-transaction list associated with each candidate chain.
> ... One might also ask ... how many candidate chains must
> a given node keep track of at one time, on average?
Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.
With this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain.
Or as James raised earlier, if the network broadcast
is reliable but depends on a potentially slow flooding
algorithm, how does that impact performance?
Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.
I'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.
3. The bitcoin system turns out to be socially useful and valuable, so
that node operators feel that they are making a beneficial contribution
to the world by their efforts (similar to the various "@Home" compute
projects where people volunteer their compute resources for good causes).
In this case it seems to me that simple altruism can suffice to keep the
network running properly.
It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com