回复：交易与脚本：DUP HASH160 ... EQUALVERIFY CHECKSIG
原始发布页
打开来源页面查看 1 个交叉存档
比特币的性质决定了，一旦 0.1 版本发布，其核心设计在此后的整个生命周期中就已不可更改。因此，我希望将它设计成能够支持我所能想到的每一种交易类型。问题是，无论是否使用，每一种类型都需要专门的支持代码和数据字段，而且每次只能涵盖一种特殊情况。这会造成特殊情况的爆炸式增长。解决办法是脚本，它将这个问题一般化，使交易各方能够把交易描述为一个由节点网络求值的谓词。节点只需要理解交易到足以判断发送方的条件是否得到满足的程度。
脚本实际上是一个谓词。它只是一个求值结果为真或假的等式。Predicate 是个又长又陌生的词，所以我把它叫作脚本。
付款接收方会对脚本进行模板匹配。目前，接收方只接受两种模板：直接付款和比特币地址。未来版本可以为更多交易类型添加模板，运行该版本或更高版本的节点将能够接收它们。网络中所有版本的节点都能验证任何新交易并将其处理进区块，即使它们可能不知道如何读取这些交易。
这一设计支持种类极其丰富的潜在交易类型，这些都是我多年前设计的。托管交易、担保合约、第三方仲裁、多方签名等等。如果比特币得到大规模采用，这些就是我们未来想要探索的东西，但它们都必须在一开始就设计好，以确保日后能够实现。
我不认为比特币的第二种兼容实现会是个好主意。该设计有太多部分依赖所有节点步调一致地得到完全相同的结果，第二种实现会对网络构成威胁。MIT 许可证与所有其他许可证及商业用途兼容，因此从许可角度看，没有必要重写它。
英文原文
展开英文原文
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.