中本聪致迈克·赫恩：合并挖矿、被放弃的市场及独立链（2011 年 3 月 9 日）
首次公开证据
打开首次公开证据请看这些帖子： http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
我明白了。所以现在交易费很棘手，因为你必须预先决定交易费应该是多少；如果估得太低，就没有办法修正交易，而且尽管网络最终会忘掉它，你的钱包仍会记录你已经花掉了这些币。这种情况已经开始出现了。
网络不会忘掉它，而且币主的客户端会不断重新广播它。即使剩余的 0.3.8 节点越来越少，那笔溢出交易仍被网络记了好几个月。
优先级包含币龄因素，所以一笔交易在等待时会逐渐变老，最终获得足够高的优先级。
看看上面的一个链接，我在那里考虑过发送一笔诚实的双重支付来提高交易费。这要做很多工作，但确实可以实现。我认为目前不值得这么做。
当前的系统已经足够好用：节点会确保根据当前情况附带足够的交易费，而网络会确保所有交易最终都得到处理。加文正在修复一处疏漏：节点在写入自己的交易时没有检查这些交易的优先级。
仍然担心处理速度不确定的用户，应该把它看作附带交易费的一种激励。
协议中有一个尚未完成的部分，用来建立发布者/订阅者频道，以便通过网络进行分布式路由。它的用途是什么？当时的想法是建立一个点对点市场，还是它有某种更底层的功能，比如广播预期的交易费？
我当时试图实现一个内置于客户端的 eBay 风格市场。发布/订阅机制将用于广播商品报价和评分/评论。你的评论权重将取决于你生成过的区块数。我后来放弃它、转而采用 JSON-RPC 是正确的，这样其他作者就能在外部实现它。发布/订阅的“中途相遇”机制是个有趣的概念，但现在没有任何东西还在使用它。
这是为了通过编写代码来探索技术要求最高的使用场景，并确保比特币能够支持未来可能需要的一切，因为区块链一旦启动，规则就具有锁定不变的性质。
几个月前有过一场关于泛化比特币的有趣讨论，但我们一直没能完全理解你打算如何实现它。我想我理解了在多条彼此独立的链之上再放置一棵默克尔树的概念：
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
但我不理解你关于用 200 字节来实现向后兼容的说法。另外，我想这应该很明显，但还是要把话说得极其清楚——在你的构想中，替代链会采用与比特币完全相同的格式和验证规则集（相同的脚本语言等），这样所有矿工就都能验证所有区块，即使它们本质上并非用于金融用途？那么，采用独立区块链的目的，就只是为了管理客户端模式实现的存储成本和带宽吗？
不是，其他链并不遵循比特币的规则。它们是完全独立的链。除了矿工之外，它们不共享任何东西。另一个网络对工作量证明的定义是：制作一个已经求解的（按它们自己的链的难度标准）比特币格式区块，其中包含它们自己的区块的哈希。它们不关心这个比特币区块是否有效，或是否被比特币使用，但这能让矿工同时为两条链工作。
对 BitDNS 区块进行哈希的步骤：
- 对 BitDNS 区块进行哈希
- 构造一个比特币区块
- 将 BitDNS 哈希插入比特币区块中第 0 笔交易的 scriptSig
- 对比特币区块进行哈希
如果该哈希低于 BitDNS 的目标值，这个 BitDNS 区块就是有效的。
BitDNS 区块需要随附约 200 字节的数据，用来重构进行哈希时所使用的比特币区块：
- 比特币区块头
- 通往第 0 笔交易的默克尔分支
- 第 0 笔交易（顺便说一下，第 0 笔交易的前序哈希总是 0，所以省略它可以节省 32 字节）
请注意，作为填充材料的“比特币区块”在比特币链中实际上是否有效并不重要，尽管它本来可以是有效的。对 BitDNS 来说，它只是一堆为完成其复杂曲折的哈希计算所必需的盐值。如果一个矿工只为 BitDNS 挖矿而不关心比特币，他会使用一个全部为零（nonce 除外）的空白比特币区块。
进一步扩展这个构想以获得可扩展性：可以考虑不把 BitDNS 区块哈希放入第 0 笔交易，而是放入一棵包含 BitDNS 的默克尔树的根。这就是概念上位于最顶层的那棵默克尔树。
英文原文
展开英文原文
See these threads: http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.
The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished.
Priority includes age, so as a transaction waits it ages and will eventually have enough priority.
See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now.
The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them.
Users still worried about processing speed uncertainty should think of it as encouragement to include a fee.
There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?
I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it.
It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started.
There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?
No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once.
Procedure to hash a BitDNS block:
- hash the BitDNS block
- construct a Bitcoin block
- insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block
- hash the Bitcoin block
The BitDNS block is valid if that hash is below BitDNS's target.
The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash:
- the Bitcoin block header
- the merkle branch to tx 0
- tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes)
Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce).
To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top.