SN-10213 附来源、原文与上下文。
引用的来信Mike Hearn来源 ↗希望你一切都好。我终于让所有律师都满意了，可以以 Google 的名义，按 Apache 2 许可证发布 BitCoinJ：
I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license:
它还不完整——特别是还不能正确处理区块链分叉——但其余部分会陆续完成。我在文档和注释上花了很多功夫，希望能让那些无法理解或构建现有代码的新群体，也能接触比特币。在接下来一两个月里，我会补齐完整客户端模式实现中一些较大的缺失部分。
It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation.
这真是个好消息！只满足客户端需求、从头清晰地重写，可以摆脱许多复杂性，而且也向 Java 开发者打开了大门。
That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too.
引用的来信Mike Hearn来源 ↗我知道你现在很忙，但希望你能抽时间回答我的几个问题。
I know you are busy right now but I'm hoping you can find time to answer a few questions I had.
我很乐意回答任何问题。
I'm happy to answer any questions.
引用的来信Mike Hearn来源 ↗为了实现完整 SPV，我在考虑向协议添加一个 getmerklebranch 消息。它会返回一组 {blockhash, branch} 对
As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs
那就是 CMerkleTx
That's a CMerkleTx
引用的来信Mike Hearn来源 ↗输入是交易哈希，这样无需保存完整链，就能在广播的交易被纳入区块之前对其进行验证。你觉得这种办法好吗？
given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you?
我不明白。Merkle 分支把一笔交易连接回某个区块，而只有该区块具有工作量证明时，这才有意义。连接回一个尚未求解的区块，什么也证明不了。
I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing.
网络节点能够验证零确认交易，是因为它们拥有完整的交易索引，所以它们可以：
Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can:
你说的是这笔交易所依赖交易的 CMerkleTx 吗？那可以做到第 1) 点，但做不到第 2) 点。
Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2).
如果不知道所有现存的交易，我不知道该如何做到第 2) 点。对此，你只能依靠信任其他节点。这种信任可以分散到多个节点。节点只会转发它们接受为有效的交易。如果你从所有相连的节点都收到了某笔交易的 inv 消息，它们就是在作证：这笔交易有效，而且是它们最先看到的花费。
If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.
引用的来信Mike Hearn来源 ↗另外，最近我在考虑探索不同的交易类型，例如移除测试网上的 IsStandard() 检查。
Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet.
很好的想法。在 -testnet 上绝对应该允许这样做。
Very good idea. That should definitely be allowed on -testnet.
引用的来信Mike Hearn来源 ↗显然，你一开始就在交易方面作了很多考虑，远不止简单地转移币，但遗憾的是，论文没有提到，代码里也没有文档说明。托管、多方支付等等都很有趣，我想知道，你是否能在某个时候整理一份清单，列出我们可以用脚本语言做的事情。
It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point.
最后，允许交易替换的代码已经禁用了，但注释没有说原因。这只是为了减少攻击面/复杂性，还是有更深层的原因？
Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason?
只是为了减少攻击面。它对提高手续费没有帮助。交易从 nLockTime 开始有效。让一笔交易在某个时间停止有效，是行不通的；一笔交易一旦变得有效，就必须永久保持有效。
Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.
引用的来信Mike Hearn来源 ↗我还没有完全理解，为什么序列号是交易输入的属性，而不是交易本身的属性。
I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself.
这是为合约准备的。一笔尚未记录、仍未定稿的交易，可以在 nLockTime 之前不断被替换。它可能包含多方的付款。每个输入的所有者签署自己的输入。要写出一个新版本，每个人都必须签署更高的序列号（参见 IsNewerThan）。输入所有者签名，等于是在说：“只要大家都把钱放进来，而且输出是这样，我就同意把自己的钱放进来。”SignatureHash 还有其他选项，例如 SIGHASH_SINGLE，意思是：“只要这一个输出（也就是我的）符合我的要求，我就同意，其他输出怎么处理我不管。”如果以较高的 nSequenceNumber 签署这一项，该方就可以退出协商，只保留这一条要求；或者签署 SIGHASH_NONE，完全退出协商。
It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
各方可以创建一笔 nSequenceNumber 更高的交易，使用 OP_CHECKMULTISIG，要求其中部分参与方签名才能完成签名，从而建立一个预先商定的默认选项。各方保留这笔交易备用，必要时相互传递，直到它获得足够的签名。
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
nLockTime 的一种用途，是一组参与方之间的高频交易。他们可以经全体一致同意，不断更新一笔交易。付款方会首先签署下一个版本。如果某一方不再同意变更，最后的状态就会在 nLockTime 被记录。需要的话，可以在每个版本之后准备一笔默认交易，让 n-1 方能够把一个不响应的参与方排除出去。中间交易无需广播。网络只记录最终结果。在 nLockTime 到来之前，各方及少数见证节点会广播它们见过的序列号最高的交易。
One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.
