SN-10214 附来源、原文与上下文。
引用的来信Mike Hearn来源 ↗Mike 引用的中本聪旧信中本聪来源 ↗明白了。所以现在手续费很棘手，因为必须事先决定手续费应该是多少；如果估得太低，就无法修正交易。虽然网络最终会忘掉它，你的钱包仍会记录这些币已经花出。这种情况已经开始发生了。
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.
网络不会忘掉，所有者的客户端也会不断重新广播它。即使剩余的 0.3.8 节点逐渐减少，网络仍记得那笔溢出交易，持续了好几个月。
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.
目前的系统运作得足够好：节点确保按当前状况附上足够的手续费，而网络确保所有交易最终都得到处理。节点在创建自己的交易时没有检查优先级，这是一个疏漏，Gavin 正在修复。
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.
引用的来信Mike Hearn来源 ↗协议中有一个未完成的部分，涉及建立发布/订阅通道，通过网络进行分布式路由。它是做什么用的？是想做一个点对点市场，还是有某种更底层的功能，例如广播预期手续费？
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?
我当时试图实现一个内置于客户端的 eBay 式市场。发布/订阅机制用来广播商品报价和评分/评价。你发表的评价会按你生成的区块加权。后来我放弃了它，转而采用 JSON-RPC，让其他作者可以在外部实现，这是正确的选择。发布/订阅的“在中间相遇”机制是个有趣的概念，但现在没有任何东西再使用它。
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.
引用的来信Mike Hearn来源 ↗几个月前，有一场关于推广比特币用途的有趣讨论，但我们很难完全理解你打算如何实现。我想我理解了在多条独立链之上再放一棵 Merkle 树的概念：
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:
但我不明白你关于为向后兼容保留 200 字节的说法。另外，我猜这很明显，但为了彻底说清楚——按照你的想法，其他链会与比特币使用完全相同的格式和验证规则集（相同的脚本语言等），这样所有矿工都可以验证所有区块，即使它们不是金融性质的？那么，使用独立区块链的目的，只是管理客户端模式实现的存储成本和带宽吗？
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.
对 BitDNS 区块进行哈希运算的步骤：
Procedure to hash a BitDNS block:
如果该哈希低于 BitDNS 的目标值，BitDNS 区块就有效。
The BitDNS block is valid if that hash is below BitDNS's target.
BitDNS 区块需要附带约 200 字节的数据，以重建哈希运算中使用的比特币区块：
The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash:
注意，作为计算材料的“比特币区块”在比特币链中是否真的有效，并不重要，虽然它也可能有效。对 BitDNS 来说，它只是一堆用于执行复杂哈希计算的必要盐值。如果一个矿工只为 BitDNS 挖矿，不关心比特币，就会使用一个全为 0 的空白比特币区块（nonce 除外）。
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).
为了进一步扩展这个想法、增强可扩展性，可以考虑：不把 BitDNS 区块哈希放进第 0 笔交易，而是放入一棵包含 BitDNS 的 Merkle 树的根。这就是概念上位于最顶层的那棵 Merkle 树。
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.
