41 各种不同的交易类型
虽然与其他文章相比，这篇更具有技术性。但我还是选择收录它，因为这有助于理解为什么中本聪的核心设计首次可以支持各种可能的交易类型，以有效避免未来的重大修改。
回复：交易和脚本：DUP HASH160…EQUALVERIFY CHECKSIG
中本聪，2010年6月17日，下午06:46:08
引自：加文•安德烈森（Gavin Andresen)，2010年6月17日，上午11:38:31
我写了一个分析比特币wallet.dat的小工具，主要是想更好地理解比特币的工 作原理。
我看到交易输出了一个数值（比特币数量）和一些字节，这些字节经过比特币内置的类Forth脚本语言的处理。例如，〔‘TxOut： value： 100.00 Script： DUP HASH1606fad…ab90EQUALVERIFY CHECKSIG’〕。
首先，让我感到有点儿紧张的是比特币有内置的脚本语言，尽管是非常简单的脚本语言（没有循环、指针，除了数学和密码外什么都没有）。让我感到紧张的原因是它更复杂，而复杂是安全大敌。这也使创建第二个兼容系统变得更加困难。但是我想自己能克服这样的困难。
代码显示新交易是通过将签名和公钥压入解释器堆栈来完成验证，然后再运行TxOut脚本，对吗？
是否可以在TxOut中用某种有效脚本编写代码创建交易？
例如，是否可以创建一段脚本（OP_2DROP OP_TRUE…)来产生一枚可以由任何人支付的比特币？
创建比特币类型的灵活性是否就源于这种编码方式？
比特币的性质是0.1版一旦发布，其核心设计在剩余的生命周期中就不再改变 。因此，我想将其设计成能支撑各种可能交易类型的系统。问题在于不管是否用到这些类型，都需要特殊的支持代码和数据字段，并且每次只能覆盖一种情况， 这会产生海量的特例。解决方案是用脚本来概括问题，因此交易方可以将交易描述为对网络节点评估的断言。节点对交易的了解只需到可以评估支付方是否满足条件就可以了。
脚本实际上是一种断言。它只是用来评估真假的方程式。断言是一个生僻的词，所以我称之为脚本。
收款方在脚本上匹配模板。目前，收款方只接受两种模板：直接支付和比特币地址。未来的版本可以为更多的交易类型提供更多的模板，运行那个版本或更高版本的节点就能接收这些交易类型。网络中所有版本的节点都可以验证并且处理任何新交易，然后移至区块里，即使它们可能不知道如何读取这些新交易类型 。
这个设计支持我多年前设计的各种可能的交易类型，包括托管交易、担保交易、第三方仲裁、多方签名等。如果比特币的发展规模够大，这些就是未来我们想要探索的，但它们都必须在一开始就设计才能确保未来成为可能。
我不相信与比特币兼容的第二个实现是个好主意。如此之多的设计依赖于所有节点步伐一致地得到完全相同的结果，第二个实现会对网络构成威胁。因为MIT许可协议与所有其他许可协议及商业用途兼容，所以从许可证的角度看没必要重写代码。
第二个版本对我意味着大量的开发和维护工作。升级网络时不锁定第二个版本就很难保持向后兼容性。如果第二个版本出了大麻烦，两个版本的用户体验都不好，尽管这会增强用户留在官方版本的重要性。如果有人正在准备第二版本的分叉，那我就必须要对使用分叉版本的风险提出很多免责声明。这种设计使出现分歧时主版本受益，对分叉版本来说可能不太公平，并且我也不愿这么干，只要只有一个版本，我就没有必做这些事了。
我知道大多数开发人员不喜欢自己的软件分叉，但这件事有真正的技术原因 。
引自：加文•安德烈森（Gavin Andresen)，2010年6月17日，下午07:58:14
我钦佩交易脚本设计方案的灵活性，但是我那邪恶的小脑袋立刻开始考虑如何滥用该方案。我可以在TxOut脚本中对各种信息做有趣的编码，如果那些没被黑过的客户端验证并忽略那些交易，这将是个有用的改装的广播通信信道。
这个功能很酷，流行以后会有人通过数以百万计的交易来转播Lady Gaga最新的视频给所有的朋友，因为用这种方式洪水式攻击支付网络很好玩……
这是收取交易费的原因之一。如果有必要，我们还有其他的手段。
引自：拉兹洛（laszlo)，2010年6月17日，下午06:50:31
聪，您这个设计做多久了？看起来想得非常透彻，不像那种没做过大量头脑风暴和讨论坐下来就写代码的项目。尽管所有人都满腹疑虑寻找漏洞，但迄今为止它仍然坚不可摧。
从2007年就开始了。有一天，我确信有一种方法可以无需任何信任就能做到这一点，于是不断地思考这个问题。更多的工作在于设计而非编码。
幸运的是，到目前为止他们所提出的问题都是我之前考虑和计划过的。