附录２ 比特币改进协议

比特币改进协议（Bitcoin improvement proposals 简称BIP）是为比特币社区提供规范，完善比特币及其运行进程和外部环境特性的设计指导文件。 依据 BIP0001协议即比特币改进协议的目的与指南，比特币改进协议有以下三种类型：
标准协议（Standard BIP）
描述任何影响大多或全部比特币应用的变化，比如网络协议、交易有效性规则的变化，或者任何影响使用比特币交互操作性的变化或补充。
信息补充协议（Informational BIP）
描述比特币的设计事项而不是为其提供新特性，或者为比特币社区提供一般性的指南或信息。信息补充型协议 不一定需要比特币社区达成共识或推荐，因此用户和开发人员可以选择忽略或者接受信息补充型协议的建议。
开发指导协议（Process BIP）
描述比特币进程，或者提议更改进程或事项。Process BIP与Standard BIP 相似，但是也可以应用于除比特币协议以外的领域。在普遍达成共识的情况下，它可以向比特币以外的代码库提出改进建议。与Informational BIP不同，Process BIP 是强制性的，用户必须遵守。例如针对决策进程的过程、指南、改变，在比特币开发过程中使用的工具、环境的改变。任何meta-BIP也应被认为是 Process BIP。 比特币改进协议在 GitHub 中更新版本。
表B-1为比特币改进协议一览表（更新至2014年底） 。需要有关目前 BIP 内容的最新信息，请参考官方版本。
表B-1 BIP一览表

第10章 比特币安全

保护比特币是很具有挑战性的事，因为比特币不像银行账户余额那样体现抽象价值。比特币其实更像数字现金或黄金。你可能听过这样的说法，“现实持有， 败一胜九。”好吧，在比特币的世界里，这样的持有只能让你有一成胜率。而只有拥有解锁比特币的密钥才相当于持有现金或一块贵重金属。你可能会将密钥丢失， 会放错地方，会被盗或者不小心错支了数额。无论是哪种场景，用户都没有办法撤回，因为这就像是将现金丢在了车水马龙的大街上。
不过，与现金、黄金或者银行账户相比，比特币有着一个独一无二的优势。你不能“备份”你的现金、黄金或者银行账户，但你可以像备份其他文件一样，备 份含有密钥的比特币钱包。它可以被复制成很多份，放到不同的地方保存起来，甚至能打印到纸上进行实体备份。比特币与至今为止的其他货币是如此不同，以致于 我们需要以一种全新的思维方式来衡量比特币的安全性。

10.1 安全准则

比特币的核心准则是去中心化，这一点对安全性具有重要意义。在中心化的模式下，例如传统的银行或支付网络，需要依赖于访问控制和审查制度将不良行为 者拒之门外。相比之下，比特币这样的去中心化系统则将责任和控制权都移交给了用户。由于网络的安全性是基于工作量证明而非访问控制，比特币网络可以对所有 人开放，也无需对比特币流量进行加密。
在一个传统的支付网络中，例如信用卡系统，支付是终端开放式的，因为它包含了用户的个人标识（信用卡号）。在初次支付后，任何能获得该标识的人都可 以从所有者那里反复“提取”资金。因此，该支付网络必须采取端对端加密的方式，以确保没有窃听者或中间人可以在资金流通或存储过程中将交易数据截获。如果 坏人获得该系统的控制权，他将能破获破获当前的的交易和支付令牌，他还可以随意动用这笔资金。更糟的是，当客户数据被泄露时，顾客的个人身份信息将被盗窃 者们一览无余。客户这时必须立即采取措施，以防失窃帐户被盗窃者用于欺诈。
比特币则截然不同，一笔比特币交易只授权向指定接收方发送一个指定数额，并且不能被修改或伪造。它不会透露任何个人信息，例如当事人的身份，也不能 用于权限外的支付。因此，比特币的支付网络并不需要加密或防窃听保护。事实上，你可以在任何公开的网络上广播比特币交易的数据，例如在不安全的WiFi或 蓝牙网络上公开传播比特币交易的数据，这对安全性没有任何影响。
比特币的去中心化安全模型很大程度上将权力移交到用户手上，随之而来的是用户们保管好密钥的责任。这对于大多数用户来说并非一件易事，特别是在像智 能手机或笔记本电脑这种能能时刻联网的通用设备上。虽然比特币的去中心化模型避免了常见的信用卡盗用等情况，但很多用户由于无法保管好密钥从而被黑客攻 击。

10.1.1 比特币系统安全开发

对于比特币开发者而言最重要的是去中心化原则。大多数开发者对中心化的安全模型很熟悉，并可能试图将中心化的模型运用到借鉴比特币的应用中去去，这将给比特币带来灭顶之灾。
比特币的安全性依赖于密钥的分散性控制，并且需要矿工们各自独立地进行交易验证。如果你想利用好比特币的安全性，你需要确保自己处于比特币的安全模型里。简而言之，不要将用户的密钥控制权拿走，不要接受非区块链交易信息。
例如，许多早期的比特币交易所将所有用户的资金集中在一个包含着私钥的“热钱包”里，并存放在服务器上。这样的设计夺取了用户的掌控权，并将密钥集中到单个系统里。很多这样的系统都被黑客攻破了，并给客户带来灾难性后果。
另一个常见的错误是接受区块链离线交易，妄图减少交易费或加速交易处理速度。一个“区块链离线交易”系统将交易数据记录在一个内部的中心化账本上， 然后偶尔将它们同步到比特币区块链中。这种做法，再一次，用专制和集中的方式取代比特币的去中心化安全模型。当数据处于离线的区块链上的时候，保护不当的 中心化账本里的资金可能会不知不觉被伪造、被挪用、被消耗。
除非你是准备大力投资运营安全，叠加多层访问控制，或（像传统的银行那样）加强审计，否则在将资金从比特币的去中心化安全场景中抽离出来之前，你应 该慎重考虑一番。即使你有足够的资金和纪律去实现一个可靠的安全模型，这样的设计也仅仅是复制了一个脆弱不堪，深受账户盗窃威胁、贪污和挪用公款困扰的传 统金融网络而已。要想充分利用比特币特有的去中心化安全模型，你必须避免中心化架构的常见诱惑，因它最终将摧毁比特币的安全性。

10.1.2 信任根源

传统的安全体系基于一个称为信任根源的概念，它指的总体系统或应用程序中一个可信赖的安全核心。安全体系像一圈同心圆一样围绕着信任根源来进行开 发，像层层包裹的洋葱一样，信任从内至外依次延伸。每一层都构建于更可信的内层之上，通过访问控制，数字签名，加密和其他安全方式确保可信。随着软件系统 变得越来越复杂，它们更可能出现问题，安全更容易受到威胁。其结果是，软件系统变得越复杂，就越难维护安全性。信任根源的概念确保绝大多数的信任被置于系 统一个不是过于复杂的部分，因此该系统的这部分也相对坚固，而更复杂的软件则在它之上构建。这样的安全体系随着规模扩大而不断重复出现，首先信任根源建立 于单个系统的硬件内，然后将该信任根源通过操作系统扩展到更高级别的系统服务，最后逐次扩散到圈内多台服务器上。
比特币的安全体系与这不同。在比特币里，共识系统创建了一个可信的完全去中心化的公开账本，一个正确验证过的区块使用创世块作为信任的根源，建立一 条直至当前区块的可信任链。比特币系统可以并应该使用区块链作为它们的信任根源。在设计一个多系统服务机制的比特币应用时，你应该仔细确认安全体系，以确 保对它的信任能有据可依。最终，唯一可确信无疑的是一条完全有效的区块链。如果你的应用程序或明或暗地信赖于区块链以外的东西，就该引起重视，因为它可能 会引入漏洞。一个不错的方法评估你应用程序的安全体系：单独考量每个组件，设想该组件被完全攻破并被坏人掌控的场景。依次取出应用程序的每个组件，并评估 它被攻破时对整体安全的影响。如果你的应用程序的安全性在该组件沦陷后大打折扣，那就说明你已经对这些组件过度信任了。一个没有漏洞的比特币应用程序应该 只受限于比特币的共识机制，这意味着其安全体系的信任源于比特币最坚固的部分。
无数个黑客攻击比特币交易所的例子都是因为轻视了这一点，他们的安全体系和设计甚至无法通过基本的审查。这种中心化的实现方式将信任置于比特币区块链之外的诸多组件之上，例如热钱包，中心化的账本数据库，简易加密的密钥，以及许多类似的方案。

10.2 用户最佳安全实践

人类使用物理的安全控制已经有数千年之久。相比之下，我们的数字化安全经验的年纪还不满50岁。现代通用的操作系统并不是十分安全，亦不特别适合用 来存储数字货币。我们的电脑通过一直连接的互联网长时间暴露在外，它们运行着成千上万第三方软件组件，这些软件往往可以不受约束地访问用户的文件。你电脑 上安装的众多软件只要有一个恶意软件，就会威胁到你的文件，可窃取你钱包里的所有比特币。想要杜绝病毒和木马对电脑的威胁，用户要达到一定的计算机维护水 平，只有小部分人能做到。
尽管信息安全经过了数十年的研究和发展，数字资产在绵延不绝的攻势下还是十分脆弱。纵使是像金融服务公司，情报机构或国防承包商这样拥有高度防护和 限制的系统，也经常会被攻破。比特币创造了具有内在价值的数字资产，它可以被窃取，并立即转移给他人而无法撤回。这让黑客有了强烈的作案动机。至今为止， 黑客都不得不在套现后更换身份信息或帐户口令，例如信用卡或银行账户。尽管掩饰和洗白这部分财务信息的难度不小，但越来越多的窃贼从于此道。而比特币使这 个问题加剧了，因为它不需要掩饰或洗白，它本身就是具有内在价值的数字资产。
幸运的是，比特币也有着激励机制，以提高计算机的安全性。如前所述，计算机受威胁的风险是模糊的，间接的，而比特币让这些风险变得明确清晰。在电脑 上保存比特币让用户时刻注意他们需要提高计算机的安全性，结果便是这使得比特币和其它数字货币得以传播和扩散，我们已经看到在黑客技术和安全解决方案双方 的提升。简单来说，黑客现在有着一个非常诱人的目标，而用户也有明确的激励性去保卫自己。
在过去的三年里，随着比特币不断被接纳，一个直接的结果是，我们已经看到信息安全领域取得了巨大创新，例如硬件加密，密钥存储和硬件钱包，多重签名技术和数字托管。在下面的章节中，我们将研究各种实际用户安全中的实践经验。

10.2.1 比特币物理存储

相比数字信息的安全，大多数用户对物理安全更加熟悉，一个非常有效保护比特币的方法是，将它们转换为物理形式。比特币密钥不过是串长数字而已。这意 味着它们可以以物理形式存储起来，如印在纸上或蚀刻成金属硬币上。这样保护密钥就变成了简单地保护印着比特币密钥的物理实体。一组打印在纸上的比特币密钥 被称为“纸钱包”，有许多可以用来创建它们的免费工具。我个人将大部分（99％以上）的比特币存储在纸钱包上，并用BIP0038加密，复制了多份并锁在 保险箱里。将比特币离线保存被称为冷存储，它是最有效的安全技术之一。冷存储系统是在一个离线系统（一个从来没有连接过互联网的系统）上生成密钥，并离线 存储到纸上或者U盘等电子媒介。

10.2.2 硬件钱包

从长远来看，比特币安全将越来越多地以硬件防篡改钱包的形式出现。与智能手机或台式电脑不同，一个比特币硬件钱包只有一个目的，安全地存储比特币。 不像容易受害的常用软件那样，硬件钱包只提供了有限的接口，从而可以给非专业用户提供近乎万无一失的安全等级。我预期将看到硬件钱包成为比特币储存的主要 方式。要想看硬件钱包的实例，请查阅Trezor。

10.2.3 平衡风险

虽然大多数用户都非常关注比特币防盗，其实还有一个更大的风险存在。数据文件丢失的情况时有发生。如果比特币的数据也在其中，损失将会让人痛苦不 堪。为了保护好比特币钱包，用户必须非常注意不要剑走偏锋，这样不至于会搞丢比特币。在2011年7月，一个著名的比特币认知教育项目损失了近7,000 枚比特币。为了防止被盗窃，其主人曾之前采取了一系列复杂的操作去加密备份。结果他们不慎丢失了加密的密钥，使得备份变得毫无价值，白白失去了一大笔财 富。如果你保护比特币的方式太过了，这好比于把钱藏在沙漠里，你可能不能再把它找回来了。

10.2.4 分散风险

你会将你的全部家当换成现金放在钱包里随身携带么？大多数人会认为这非常不明智，但比特币用户经常会将所有的比特币放在一个钱包里。用户应该将风险 分散到不同类型的比特币钱包。审慎的用户应该只留一小部分（或许低于5%）的比特币在一个在线的或手机钱包，就像零用钱一样，其余的部分应该采用不同存储 机制分散开来，诸如电脑钱包和离线（冷存储）钱包。

10.2.5 多重签名管理

当一个公司或个人持有大量比特币时，他们应该考虑采用多重签名的比特币地址。多重签名比特币地址需要多个签名才能支付，从而保证资金的安全。多重签 名的密钥应存储在多个不同的地方，并由不同的人掌控。打个比方，在企业环境中，密钥应该分别生成并由若干公司管理人员持有，以确保没有任何一个人可以独自 占有资金。多重签名的地址也可以提供冗余，例如一个人持有多个密钥，并将它们分别存储在不同的地方。

10.2.6 存活能力

一个非常重要却又常常被忽视的安全性考虑是可用性，尤其是在密钥持有者丧失工作能力或死亡的情况下。比特币的用户被告知应该使用复杂的密码，并保证 他们的密钥安全且不为他人所知。不幸的是，这种做法使得在用户无法解锁时，用户的家人几乎无法将该财产恢复。事实上，比特币用户的家人可能完全不知道这笔 比特币资金的存在。
如果你有很多的比特币，你应该考虑与一个值得信赖的亲属或律师分享解密的细节。一个更复杂的比特币生还计划，可以通过设置多重签名，做好遗产规划，并通过专门的“数字资产执行者”律师处理后事。

10.3 总结

比特币是一项全新的，前所未有的，复杂的技术。随着时间的推移，我们将开发出更好的安全工具，而且更容易被非专业人士使用的做法。而现在，比特币用户可以使用许多这里所讨论的技巧，享受安全而无困扰的比特币生活。

第8章 挖矿与共识

8.1 简介

挖矿是增加比特币货币供应的一个过程。挖矿同时还保护着比特币系统的安全，防止欺诈交易，避免“双重支付”，“双重支付”是指多次花费同一笔比特币。矿工们通过为比特币网络提供算力来换取获得比特币奖励的机会。
矿工们验证每笔新的交易并把它们记录在总帐簿上。每10分钟就会有一个新的区块被“挖掘”出来，每个区块里包含着从上一个区块产生到目前这段时间内 发生的所有交易，这些交易被依次添加到区块链中。我们把包含在区块内且被添加到区块链上的交易称为“确认”交易，交易经过“确认”之后，新的拥有者才能够 花费他在交易中得到的比特币。
矿工们在挖矿过程中会得到两种类型的奖励：创建新区块的新币奖励，以及区块中所含交易的交易费。为了得到这些奖励，矿工们争相完成一种基于加密哈希 算法的数学难题，这些难题的答案包括在新区块中，作为矿工的计算工作量的证明，被称为”“工作量证明”。该算法的竞争的机制以及获胜者有权在区块链上进行 交易记录的机制，这二者比特币安全的基石。
新比特币的生成过程被称为挖矿是因为它的奖励机制被设计为速度递减模式，类似于贵重金属的挖矿过程。比特币的货币是通过挖矿发行的，类似于中央银行 通过印刷银行纸币来发行货币。矿工通过创造一个新区块得到的比特币数量大约每四年（或准确说是每隔210,000个块）减少一半。开始时为2009年1月 每个区块奖励50个比特币，然后到2012年11月减半为每个区块奖励25个比特币。之后将在2016年的某个时刻再次减半为每个新区块奖励12.5个比 特币。基于这个公式，比特币挖矿奖励以指数方式递减，直到2140年。届时所有的比特币（20,999,999,980）全部发行完毕。换句话说在 2140年之后，不会再有新的比特币产生。
矿工们同时也会获取交易费。每笔交易都可能包含一笔交易费，交易费是每笔交易记录的输入和输出的差额。在挖矿过程中“挖出”新区块的矿工获胜者可以 得到该区块中包含的所有交易“小费”。目前，这笔费用占矿工收入的0.5%或更少，大部分收益仍来自挖矿所得的比特币奖励。然而随着挖矿奖励的递减，以及 每个区块中包含的交易数量增加，交易费在矿工收益中所占的比重将会逐渐增加。在2140年之后，所有的矿工收益都将由交易费构成。
“挖矿”这个词有一定的误导性。它容易引起对贵重金属采矿的的联想，从而使我们的注意力都集中在每个新区块产生的奖励上。尽管挖矿带来的奖励是一种 激励，但它最主要的目的并不是奖励本身或者新币的产生。如果只把挖矿看作生产新币的过程，那你是把手段（激励措施）当成了目的。挖矿是一种将结算所去中心 化的过程，每个结算所对处理的交易进行验证和结算。挖矿保护了比特币系统的安全，并且实现了在没有中心机构的情况下，也能使整个比特币网络达成共识。
挖矿这个发明使比特币变得很特别，这种去中心化的安全机制是点对点的电子货币的基础。铸造新币的奖励和交易费是一种激励机制，它可以调节矿工行为和网络安全，同时又完成了比特币的货币发行。
在本章中，我们先来审视比特币的货币发行机制，然后再来了解挖矿的最重要的功能：支撑比特币安全的去中心化的自发共识机制。

8.1.1 比特币经济学和货币创造

通过创造出新区块，比特币以一个确定的但不断减慢的速率被铸造出来。大约每十分钟产生一个新区块，每一个新区块都伴随着一定数量从无到有的全新比特 币。每开采210,000个块，大约耗时4年，货币发行速率降低50%。在比特币运行的第一个四年中，每个区块创造出50个新比特币。
2012年11月，比特币的新发行速度降低到每区块25个比特币，并且预计会在2016年的某个时刻，在第420,000个区块被“挖掘”出来之后 降低到12.5比特币/区块。在第13,230,000个区块（大概在2137年被挖出）之前，新币的发行速度会以指数形式进行64次“二等分”。到那时 每区块发行比特币数量变为比特币的最小货币单位——1聪。最终，在经过1,344万个区块之后，所有的共2,099,999,997,690,000聪比 特币将全部发行完毕。换句话说，到2140年左右，会存在接近2,100万比特币。在那之后，新的区块不再包含比特币奖励，矿工的收益全部来自交易费。图 8-1展示了在发行速度不断降低的情况下，比特币总流通量与时间的关系。
在例8-1的代码展示中，我们计算了比特币的总发行量。
例8-1 比特币发行总量的计算脚本

# 初始的块奖励为50BTC
start_block_reward = 50
# 以10分钟为一个区块的间隔，210000个块共约4年时间
reward_interval = 210000
def max_money():
    # 50 BTC = 50 0000 0000 Satoshis
    current_reward = 50 * 10**8
    total = 0
    while current_reward > 0:
        total += reward_interval * current_reward
        current_reward /= 2
    return total
print "Total BTC to ever be created:", max_money(), "Satoshis"

例8-2显示了这个脚本的运行结果。
例8-2 运行 max_money.py 脚本

$ python max_money.py
Total BTC to ever be created: 2099999997690000 Satoshis

图8-1 比特币货币供应速度随着时间发生几何级降低

总量有限并且发行速度递减创造了一种抗通胀的货币供应模式。法币可被中央银行无限制地印刷出来，而比特币永远不会因超额印发而出现通胀。

通货紧缩货币

最重要并且最有争议的一个结论是一种事先确定的发行速率递减的货币发行模式会导致货币通货紧缩（简称通缩）。通缩是一种由于货币的供应和需求不匹配导致的货币增值的现象。它与通胀相反，价格通缩意味着货币随着时间有越来越强的购买力。
许多经济学家提出通缩经济是一种无论如何都要避免的灾难型经济。因为在快速通缩时期，人们预期着商品价格会下跌，人们将会储存货币，避免花掉它。这种现象充斥了日本经济“失去的十年”，就是因为在需求坍塌之后导致了滞涨状态。
比特币专家们认为通缩本身并不坏。更确切地说，我们将通缩与需求坍塌联系在一起是因为过去出现的一个特例。在法币届，货币是有可能被无限制印刷出来 的，除非遇到需求完全崩塌并且毫无发行货币意愿的情形，因此经济很难进入滞涨期。而比特币的通缩并不是需求坍塌引起的，它遵循一种预定且有节制的货币供应 模型。
实际上，通缩货币会让卖家考虑到折现的影响，容易诱发过度的囤积本能，除非这部分折现率超过买家的囤积本能。因为买卖双方都有囤积的动机，这两种折 现率会因为双方的囤积本能相互抵消，而达成一个平衡价格。因此即使在比特币价格贴现率为30%的情况下，大部分使用比特币的零售商并不会感受到花费比特币 很困难，也能因此盈利。当然，比特币这种不是因经济快速衰退而引起的通缩，是否会引发其他问题，仍有待观察。

8.2 去中心化共识

在上一章中我们了解了区块链。可以将区块链看作一本记录所有交易的公开总帐簿（列表），比特币网络中的每个参与者都把它看作一本所有权的权威记录。
但在不考虑相信任何人的情况下，比特币网络中的所有参与者如何达成对任意一个所有权的共识呢？所有的传统支付系统都依赖于一个中心认证机构，依靠中 心机构提供的结算服务来验证并处理所有的交易。比特币没有中心机构，几乎所有的完整节点都有一份公共总帐的备份，这份总帐可以被视为认证过的记录。区块链 并不是由一个中心机构创造的，它是由比特币网络中的所有节点各自独立竞争完成的。换句话说比特币网络中的所有节点，依靠着节点间的不稳定的网络连接所传输 的信息，最终得出同样的结果并维护了同一个公共总帐。这一章将介绍比特币网络不依靠中心机构而达成共识的机制。
中本聪的主要发明就是这种去中心化的自发共识机制。这种自发，是指没有经过明确选举或者没有固定达成的共识的时间。换句话说，共识是数以千计的独立 节点遵守了简单的规则通过异步交互自发形成的产物。所有的比特币属性，包括货币、交易、支付以及不依靠中心机构和信任的安全模型等都是这个机制的衍生物。 比特币的去中心化共识由所有网络节点的4种独立过程相互作用而产生：
▷ 每个全节点依据综合标准对每个交易进行独立验证
▷ 通过完成工作量证明算法的验算，挖矿节点将交易记录独立打包进新区块，
▷ 每个节点独立的对新区块进行校验并组装进区块链
▷ 每个节点对区块链进行独立选择，在工作量证明机制下选择累计工作量最大的区块链
在接下来的几节中，我们将审视这些过程，了解它们之间如何相互作用并达成全网的自发共识，从而使任意节点组合出它自己的权威、可信、公开的总帐。

8.3 交易的独立校验

在第5章中，我们知道了钱包软件通过收集UTXO、提供正确的解锁脚本、构造支付给接收者的输出这一系列的方式来创建交易。产生的交易随后将被发送到比特币网络临近的节点，从而使得该交易能够在整个比特币网络中传播。
然而，在交易传递到临近的节点前，每一个收到交易的比特币节点将会首先验证该交易，这将确保只有有效的交易才会在网络中传播，而无效的交易将会在第一个节点处被废弃。
每一个节点在校验每一笔交易时，都需要对照一个长长的标准列表：
▷交易的语法和数据结构必须正确。
▷输入与输出列表都不能为空。
▷交易的字节大小是小于MAX_BLOCK_SIZE的。
▷每一个输出值，以及总量，必须在规定值的范围内 （小于2,100万个币，大于0）。
▷没有哈希等于0，N等于-1的输入（coinbase交易不应当被中继）。
▷nLockTime是小于或等于INT_MAX的。
▷交易的字节大小是大于或等于100的。
▷交易中的签名数量应小于签名操作数量上限。
▷解锁脚本（scriptSig）只能够将数字压入栈中，并且锁定脚本（scriptPubkey）必须要符合isStandard的格式 （该格式将会拒绝非标准交易）。
▷池中或位于主分支区块中的一个匹配交易必须是存在的。
▷对于每一个输入，如果引用的输出存在于池中任何的交易，该交易将被拒绝。
▷对于每一个输入，在主分支和交易池中寻找引用的输出交易。如果输出交易缺少任何一个输入，该交易将成为一个孤立的交易。如果与其匹配的交易还没有出现在池中，那么将被加入到孤立交易池中。
▷对于每一个输入，如果引用的输出交易是一个coinbase输出，该输入必须至少获得COINBASE_MATURITY (100)个确认。
▷对于每一个输入，引用的输出是必须存在的，并且没有被花费。
▷使用引用的输出交易获得输入值，并检查每一个输入值和总值是否在规定值的范围内 （小于2100万个币，大于0）。
▷如果输入值的总和小于输出值的总和，交易将被中止。
▷如果交易费用太低以至于无法进入一个空的区块，交易将被拒绝。
▷每一个输入的解锁脚本必须依据相应输出的锁定脚本来验证。
这些条件能够在比特币标准客户端下的AcceptToMemoryPool、CheckTransaction和CheckInputs函数中获得更详细的阐述。请注意，这些条件会随着时间发生变化，为了处理新型拒绝服务攻击，有时候也为交易类型多样化而放宽规则。
在收到交易后，，每一个节点都会在全网广播前对这些交易进行校验，并以接收时的相应顺序，为有效的新交易建立一个池（交易池）。

8.4 挖矿节点

在比特币网络中，一些节点被称为专业节点矿工。第1章中，我们介绍了Jing，在中国上海的计算机工程专业学生，他就是一位矿工。Jing通过矿机 挖矿获得比特币，矿机是专门设计用于挖比特币的计算机硬件系统。Jing的这台专业挖矿设备连接着一个运行完整比特币节点的服务器。与Jing不同，一些 矿工是在没有完整节点的条件下进行挖矿，正如我们在“8.11.2 矿池”一节中所述的。与其他任一完整节点相同，Jing的节点在比特币网络中进行接收和传播未确认交易记录。然而，Jing的节点也能够在新区块中整合这些交易记录。
同其他节点一样，Jing的节点时刻监听着传播到比特币网络的新区块。而这些新加入的区块对挖矿节点有着特殊的意义。矿工间的竞争以新区块的传播而 结束，如同宣布谁是最后的赢家。对于矿工们来说，获得一个新区块意味着某个参与者赢了，而他们则输了这场竞争。然而，一轮竞争的结束也代表着下一轮竞争的 开始。新区块并不仅仅是象征着竞赛结束的方格旗；它也是下一个区块竞赛的发令枪。

8.5 整合交易至区块

验证交易后，比特币节点会将这些交易添加到自己的内存池中。内存池也称作交易池，用来暂存尚未被加入到区块的交易记录。与其他节点一样，Jing的节点会收集、验证并中继新的交易。而与其他节点不同的是，Jing的节点会把这些交易整合到一个候选区块中。
让我们继续跟进，看下Alice从Bob咖啡店购买咖啡时产生的那个区块（参见“2.1.2 买咖啡”）。Alice的交易在区块277,316。为了演示本章中提到的概念，我们假设这个区块是由Jing的挖矿系统挖出的，并且继续跟进Alice的交易，因为这个交易已经成为了新区块的一部分。
Jing的挖矿节点维护了一个区块链的本地副本，包含了自2009年比特币系统启动运行以来的全部区块。当Alice买咖啡的时候，Jing节点的 区块链已经收集到了区块277,314，并继续监听着网络上的交易，在尝试挖掘新区块的同时，也监听着由其他节点发现的区块。当Jing的节点在挖矿时， 它从比特币网络收到了区块277,315。这个区块的到来标志着终结了产出区块277,315竞赛，与此同时也是产出区块277,316竞赛的开始。
在上一个10分钟内，当Jing的节点正在寻找区块277,315的解的同时，它也在收集交易记录为下一个区块做准备。目前它已经收到了几百笔交易 记录，并将它们放进了内存池。直到接收并验证区块277,315后，Jing的节点会检查内存池中的全部交易，并移除已经在区块277,315中出现过的 交易记录，确保任何留在内存池中的交易都是未确认的，等待被记录到新区块中。
Jing的节点立刻构建一个新的空区块，做为区块277,316的候选区块。称作候选区块是因为它还没有包含有效的工作量证明，不是一个有效的区块，而只有在矿工成功找到一个工作量证明解之后，这个区块才生效。

8.5.1 交易块龄，矿工费和优先级

Jing的比特币节点需要为内存池中的每笔交易分配一个优先级，并选择较高优先级的交易记录来构建候选区块。交易的优先级是由交易输入所花费的 UTXO的“块龄”决定，交易输入值高、“块龄”大的交易比那些新的、输入值小的交易拥有更高的优先级。如果区块中有足够的空间，高优先级的交易行为将不 需要矿工费。
交易的优先级是通过输入值和输入的“块龄”乘积之和除以交易的总长度得到的：

Priority = Sum (Value of input * Input Age) / Transaction Size

在这个等式中，交易输入的值是由比特币单位“聪”（100万分之1个比特币）来表示的。UTXO的“块龄”是自该UTXO被记录到区块链为止所经历过的区块数，即这个UTXO在区块链中的深度。交易记录的大小由字节来表示。
一个交易想要成为“较高优先级”，需满足的条件：优先值大于57,600,000，相当于一个比特币（即100万聪），年龄为一天（144个区块），交易的大小为250个字节：

High Priority > 100,000,000 satoshis * 144 blocks / 250 bytes = 57,600,000

区块中用来存储交易的前50K字节是保留给较高优先级交易的。Jing的节点在填充这50K字节的时候，会优先考虑这些最高优先级的交易，不管它们是否包含了矿工费。这种机制使得高优先级交易即便是零矿工费，也可以优先被处理。
然后，Jing的挖矿节点会选出那些包含最小矿工费的交易，并按照“每千字节矿工费”进行排序，优先选择矿工费高的交易来填充剩下的区块，区块大小上限为MAX_BLOCK_SIZE。
如区块中仍有剩余空间，Jing的挖矿节点可以选择那些不含矿工费的交易。有些矿工会竭尽全力将那些不含矿工费的交易整合到区块中，而其他矿工也许会选择忽略这些交易。
在区块被填满后，内存池中的剩余交易会成为下一个区块的候选交易。因为这些交易还留在内存池中，所以随着新的区块被加到链上，这些交易输入时所引用 UTXO的深度（即交易“块龄”）也会随着变大。由于交易的优先值取决于它交易输入的“块龄”，所以这个交易的优先值也就随之增长了。最后，一个零矿工费 交易的优先值就有可能会满足高优先级的门槛，被免费地打包进区块。
比特币交易中没有过期、超时的概念，一笔交易现在有效，那么它就永远有效。然而，如果一笔交易只在全网广播了一次，那么它只会保存在一个挖矿节点的 内存中。因为内存池是以未持久化的方式保存在挖矿节点存储器中的，所以一旦这个节点重新启动，内存池中的数据就会被完全擦除。而且，即便一笔有效交易被传 播到了全网，如果它长时间未处理，它将从挖矿节点的内存池中消失。如果交易本应该在一段时间内被处理而实际没有，那么钱包软件应该重新发送交易或重新支付 更高的矿工费。
现在，Jing的节点从内存池中整合到了全部的交易，新的候选区块包含有418笔交易，总的矿工费为0.09094925个比特币。你可以通过比特币核心客户端命令行来查看这个区块，如例8-3所示：
例8-3 区块277,316

{
    "hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
    "confirmations" : 35561,
    "size" : 218629,
    "height" : 277316,
    "version" : 2,
    "merkleroot" :
"c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e",
    "tx":[
        "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
        "b268b45c59b39d759614757718b9918caf0ba9d97c56f3b91956ff877c503fbe",
        ... 417 more transactions ...
        ],
    "time" : 1388185914,
    "nonce" : 924591752,
    "bits" : "1903a30c",
    "difficulty" : 1180923195.25802612,
    "chainwork" :
"000000000000000000000000000000000000000000000934695e92aaf53afa1a",
    "previousblockhash" :
"0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569",
    "nextblockhash" :
"000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
}

8.5.2 创币交易

区块中的第一笔交易是笔特殊交易，称为创币交易或者coinbase交易。这个交易是由Jing的节点构造并用来奖励矿工们所做的贡献的。Jing 的节点会创建“向Jing的地址支付25.09094928个比特币”这样一个交易，把生成交易的奖励发送到自己的钱包。Jing挖出区块获得的奖励金额 是coinbase奖励（25个全新的比特币）和区块中全部交易矿工费的总和。如例8-4所示：

$ bitcoin-cli getrawtransaction
d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1

例8-4 创币交易

{
    "hex" :
"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
    "txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "coinbase" : "03443b0403858402062f503253482f",                  "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 25.09094928,
            "n":0, "
            scriptPubKey" : {
                "asm" : "02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21OP_CHECKSIG",
                "hex" : "2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
                "reqSigs" : 1,
                "type" : "pubkey",
                "addresses" : [
                    "1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N"
                ]
            }
        }
    ],
    "blockhash" :
"0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
    "confirmations" : 35566,
    "time" : 1388185914,
    "blocktime" : 1388185914
}

与常规交易不同，创币交易没有输入，不消耗UTXO。它只包含一个被称作coinbase的输入，仅仅用来创建新的比特 币。创币交易有一个输出，支付到这个矿工的比特币地址。创币交易的输出将这25.09094928个比特币发送到矿工的比特币地址，如本例所示的 1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N。

8.5.3 Coinbase奖励与矿工费

为了构造创币交易，Jing的节点需要计算矿工费的总额，将这418个已添加到区块交易的输入和输出分别进行加总，然后用输入总额减去输出总额得到矿工费总额，公式如下：

 Total Fees = Sum(Inputs) - Sum(Outputs)

在区块277,316中，矿工费的总额是0.09094925个比特币。
紧接着，Jing的节点计算出这个新区块正确的奖励额。奖励额的计算是基于区块高度的，以每个区块50个比特币为开始，每产生210,000个区块减半一次。这个区块高度是277,316，所以正确的奖励额是25个比特币。
详细的计算过程可以参看比特币核心客户端中的GetBlockValue函数，如例8-5所示：
例8-5 计算区块奖励—Function GetBlockValue, Bitcoin Core Client, main.cpp, line 1305

int64_t GetBlockValue(int nHeight, int64_t nFees)
{
    int64_t nSubsidy = 50 * COIN;
    int halvings = nHeight / Params().SubsidyHalvingInterval();
    // 如果右移的次数未定义，区块奖励强制为零
    if (halvings >= 64)
            return nFees;
    // Subsidy每210,000个区块减半一次，大概每4年发生一次
    nSubsidy >>= halvings;
    return nSubsidy + nFees;
}

变量nSubsidy表示初始奖励额，值为COIN常量（100,000,000聪)与50的乘积，也就是说初始奖励额为50亿聪。
紧接着，这个函数用当前区块高度除以减半间隔(SubsidyHalvingInterval函数)得到减半次数（变量halvings）。每210,000个区块为一个减半间隔，对应本例中的区块277316，所以减半次数为1。
变量halvings最大值64，如果超出这个值，代码算得的奖励额为0，整个函数将只返回矿工费总额，作为奖励总额。
然后，这个函数会使用二进制右移操作将奖励额(变量nSubsidy)右移一位（等同与除以2），每一轮减半右移一次。在这个例子中，对于区块277,316只需要将值为50亿聪的奖励额右移一次，得到25亿聪，也就是25个比特币的奖励额。之所以采用二进制右移操作，是因为相比于整数或浮点数除法，右移操作的效率更高。
最后，将coinbase奖励额（变量nSubsidy）与矿工费(nFee)总额求和，并返回这个值。

8.5.4 创币交易的结构

经过计算，Jing的节点构造了一个创币交易，支付给自己25.09094928枚比特币。
如例8-4所示，创币交易的结构比较特殊，与一般交易输入需要指定一个先前的UTXO不同，它包含一个“coinbase“输入。在表5-3中，我 们已经给出了交易输入的结构。现在让我们来比较一下常规交易输入与创币交易输入。表8-1给出了常规交易输入的结构，表8-2给出的是创币交易输入的结 构。
表8-1 “普通“交易输入的结构

表8-2 生成交易输入的结构

在创币交易中，“交易哈希”字段32个字节全部填充0，“交易输出索引”字段全部填充0xFF(十进制的255)，这两个字段的值表示不引用UTXO。“解锁脚本”由coinbase数据代替，数据可以由矿工自定义。

8.5.5 Coinbase数据

创币交易不包含“解锁脚本“(又称作 scriptSig)字段，这个字段被coinbase数据替代，长度最小2字节，最大100字节。除了开始的几个字节外，矿工可以任意使用coinbase的其他部分，随意填充任何数据。
以创世块为例，中本聪在coinbase中填入了这样的数据“The Times 03/Jan/ 2009 Chancellor on brink of second bailout for banks“(泰晤士报 2009年1月3日 财政大臣将再次对银行施以援手)，表示对日期的证明，同时也表达了对银行系统的不信任。现在，矿工使用coinbase数据实现extra nonce功能，并嵌入字符串来标识挖出它的矿池，这部分内容会在后面的小节描述。coinbase前几个字节也曾是可以任意填写的，不过在后来的第34 号比特币改进提议(BIP34)中规定了版本2的区块（版本字段为2的区块），这个区块的高度必须跟在脚本操作“push“之后，填充在coinbase 字段的起始处。
我们以例8-4中的区块277,316为例，coinbase就是交易输入的“解锁脚本“（或scriptSig）字段，这个字段的十六进制值为03443b0403858402062f503253482f。下面让我们来解码这段数据。
第一个字节是03，脚本执行引擎执行这个指令将后面3个字节压入脚本栈(见表4-1)，紧接着的3个字节——0x443b04，是以小端格式(最低有效字节在先)编码的区块高度。翻转字节序得到0x043b44，表示为十进制是277,316。
紧接着的几个十六进制数（03858402062）用于编码extra nonce(参见”8.11.1 随机值升位方案“)，或者一个随机值，从而求解一个适当的工作量证明。
coinbase数据结尾部分(2f503253482f)是ASCII编码字符 /P2SH/，表示挖出这个区块的挖矿节点支持BIP0016所定义的pay-to-script-hash(P2SH)改进方案。在P2SH功能引入到 比特币的时候，曾经有过一场对P2SH不同实现方式的投票，候选者是BIP0016和BIP0017。支持BIP0016的矿工将/P2SH/放入 coinbase数据中，支持BIP0017的矿工将 p2sh/CHV放入他们的coinbase数据中。最后，BIP0016在选举中胜出，直到现在依然有很多矿工在他们的coinbase中填入 /P2SH/以表示支持这个功能。
例8-6使用了libbitcoin库（在56页“其他替代客户端、资料库、工具包”中提到）从创世块中提取coinbase数据，并显示出中本聪留下的信息。libbitcoin库中自带了一份创世块的静态拷贝，所以这段示例代码可以直接取自库中的创世块数据。
例8-6 从创世区块中提取coinbase数据

/*
  Display the genesis block message by Satoshi.
*/
#include
#include
int main()
{
    // Create genesis block.
    bc::block_type block = bc::genesis_block();
    // Genesis block contains a single coinbase transaction.     assert(block.transactions.size() == 1);
    // Get first transaction in block (coinbase).
    const bc::transaction_type& coinbase_tx = block.transactions[0];
    // Coinbase tx has a single input.
    assert(coinbase_tx.inputs.size() == 1);
    const bc::transaction_input_type& coinbase_input = coinbase_tx.inputs[0];
    // Convert the input script to its raw format.
    const bc::data_chunk& raw_message = save_script(coinbase_input.script);
    // Convert this to an std::string.
    std::string message;
    message.resize(raw_message.size());
    std::copy(raw_message.begin(), raw_message.end(), message.begin());
    // Display the genesis block message.
    std::cout << message << std::endl;
    return 0;
}

在例8-7中，我们使用GNU C++编译器编译源代码并运行得到的可执行文件
例8-7 编译并运行satoshi-words示例代码

$ # Compile the code
$ g++ -o satoshi-words satoshi-words.cpp $(pkg-config --cflags --libs libbitcoin) $ # Run the executable
$ ./satoshi-words
^D^A^DEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

8.6 构造区块头

为了构造区块头，挖矿节点需要填充六个字段，如表8-3中所示。
表8-3 区块头的结构

在区块277,316被挖出的时候，区块结构中用来表示版本号的字段值为2，长度为4字节，以小段格式编码值为0x20000000。接着，挖矿节 点需要填充“前区块哈希”，在本例中，这个值为Jing的节点从网络上接收到的区块277,315的区块头哈希值，它是区块277316候选区块的父区 块。区块277,315的区块头哈希值为：

0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569

为了向区块头填充merkle根字段，要将全部的交易组成一个merkle树。创币交易作为区块中的首个交易，后将余下 的418笔交易添至其后，这样区块中的交易一共有419笔。在164页，我们已经见到过“Merkle树”，树中必须有偶数个叶子节点，所以需要复制最后 一个交易作为第420个节点，每个节点是对应交易的哈希值。这些交易的哈希值逐层地、成对地组合，直到最终组合并成一个根节点。merkle数的根节点将 全部交易数据摘要为一个32字节长度的值，例8-3中merkel根的值如下：

c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e

挖矿节点会继续添加一个4字节的时间戳，以Unix纪元时间编码，即自1970年1月1日0点到当下总共流逝的秒数。本例中的1388185914对应的时间是2013年12月27日，星期五，UTC/GMT。
接下来，节点需要填充难度目标值，为了使得该区块有效，这个字段定义了所需满足的工作量证明的难度。难度在区块中以“尾数-指数”的格式，编码并存 储，这种格式称作“难度位”。这种编码的首字节表示指数，后面的3字节表示尾数(系数)。以区块277316为例，难度位的值为 0x1903a30c，0x19是指数的十六进制格式，后半部0x03a30c是系数。这部分的概念在第195页的“难度目标与难度调整”和第194的 “难度表示”有详细的解释。
最后一个字段是nonce，初始值为0。
区块头完成全部的字段填充后，挖矿就可以开始进行了。挖矿的目标是找到一个使区块头哈希值小于难度目标的nonce。挖矿节点通常需要尝试数十亿甚至数万亿个不同的nonce取值，直到找到一个满足条件的nonce值。

8.7 构建区块

既然Jing的节点已经构建了一个候选区块，那么就轮到Jing的矿机对这个新区块进行“挖掘”，求解工作量证明算法以使这个区块有效。从本书中我们已经学习了比特币系统中不同地方用到的哈希加密函数。比特币挖矿过程使用的是SHA256哈希函数。
用最简单的术语来说，挖矿就是重复计算区块头的哈希值，不断修改该参数，直到与哈希值匹配的一个过程。哈希函数的结果无法提前得知，也没有能得到一 个特定哈希值的模式。哈希函数的这个特性意味着：得到哈希值的唯一方法是不断的尝试，每次随机修改输入，直到出现适当的哈希值。

8.7.1 工作量证明算法

哈希函数的输入数据的长度是任意的，将产生一个长度固定且绝不雷同的值，可将其视为输入的数字指纹。对于特定输入，哈希的结果每次都一样，任何实现 相同哈希函数的人都可以计算和验证。一个加密哈希函数的主要特征就是不同的输入几乎不可能出现相同的数字指纹。因此，相对于随机选择输入，有意地选择输入 去生成一个想要的哈希值几乎是不可能的。
无论输入的大小是多少，SHA256函数的输出的长度总是256bit。在例8-8中，我们将使用Python解释器来计算语句 “I am Satoshi Nakamoto” 的SHA256的哈希值。
例8-8 SHA256示例

$ python
Python 2.7.1
>>> import hashlib
>>> print hashlib.sha256("I am Satoshi Nakamoto").hexdigest() 5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e

在例8-8中，5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e是”I am Satoshi Nakamoto”的哈希值。改变原句中的任何一个字母、标点、或增加字母都会产生不同的哈希值。
如果我们改变原句，得到的应该是完全不同的哈希值。例如，我们在句子末尾加上一个数字，运行例8-9中的Python脚本。
例8-9 通过迭代 nonce 来生成不同哈希值的脚本（SHA256）

# example of iterating a nonce in a hashing algorithm's input
import hashlib
text = "I am Satoshi Nakamoto"
# iterate nonce from 0 to 19
for nonce in xrange(20):
# add the nonce to the end of the text
input = text + str(nonce)
# calculate the SHA-256 hash of the input (text+nonce)
hash = hashlib.sha256(input).hexdigest() # show the input and hash result
print input, '=>', hash

执行这个脚本就能生成这些只是末尾数字不同的语句的哈希值。例8-10 中显示了我们只是增加了这个数字，却得到了非常不同的哈希值。
例8-10 通过迭代 nonce 来生成不同哈希值的脚本的输出

$ python hash_example.py
I am Satoshi Nakamoto0 => a80a81401765c8eddee25df36728d732...
I am Satoshi Nakamoto1 => f7bc9a6304a4647bb41241a677b5345f...
I am Satoshi Nakamoto2 => ea758a8134b115298a1583ffb80ae629...
I am Satoshi Nakamoto3 => bfa9779618ff072c903d773de30c99bd...
I am Satoshi Nakamoto4 => bce8564de9a83c18c31944a66bde992f...
I am Satoshi Nakamoto5 => eb362c3cf3479be0a97a20163589038e...
I am Satoshi Nakamoto6 => 4a2fd48e3be420d0d28e202360cfbaba...
I am Satoshi Nakamoto7 => 790b5a1349a5f2b909bf74d0d166b17a...
I am Satoshi Nakamoto8 => 702c45e5b15aa54b625d68dd947f1597...
I am Satoshi Nakamoto9 => 7007cf7dd40f5e933cd89fff5b791ff0...
I am Satoshi Nakamoto10 => c2f38c81992f4614206a21537bd634a...
I am Satoshi Nakamoto11 => 7045da6ed8a914690f087690e1e8d66...
I am Satoshi Nakamoto12 => 60f01db30c1a0d4cbce2b4b22e88b9b...
I am Satoshi Nakamoto13 => 0ebc56d59a34f5082aaef3d66b37a66...
I am Satoshi Nakamoto14 => 27ead1ca85da66981fd9da01a8c6816...
I am Satoshi Nakamoto15 => 394809fb809c5f83ce97ab554a2812c...
I am Satoshi Nakamoto16 => 8fa4992219df33f50834465d3047429...
I am Satoshi Nakamoto17 => dca9b8b4f8d8e1521fa4eaa46f4f0cd...
I am Satoshi Nakamoto18 => 9989a401b2a3a318b01e9ca9a22b0f3...
I am Satoshi Nakamoto19 => cda56022ecb5b67b2bc93a2d764e75f...

每个语句都生成了一个完全不同的哈希值。它们看起来是完全随机的，但你在任何计算机上用Python执行上面的脚本都能重现这些完全相同的哈希值。
类似这样在语句末尾的变化的数字叫做nonce。Nonce是用来改变加密函数输出的，在这个示例中改变了这个语句的SHA256指纹。
为了使这个哈希算法变得富有挑战，我们来设定一个具有任意性的目标：找到一个语句，使之哈希值的十六进制表示以0开头。幸运的是，这很容易！在例8-10中语句 “I am Satoshi Nakamoto13” 的哈希值是 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5， 刚好满足条件。我们得到它用了13次。用概率的角度来看，如果哈希函数的输出是平均分布的，我们可以期望每16次得到一个以0开头的哈希值（十六进制每一 位数字为0到F）。从数字的角度来看，我们要找的是小于 0x1000000000000000000000000000000000000000000000000000000000000000的哈希值。我 们称这个为目标阀值，我们的目的是找到一个小于这个目标的哈希值。如果我们减小这个目标值，那找到一个小于它的哈希值会越来越难。
简单打个比方，想象人们不断扔一对色子以得到小于一个特定点数的游戏。第一局，目标是12。只要你不扔出两个6，你就会赢。然后下一局目标为11。 玩家只能扔10或更小的点数才能赢，不过也很简单。假如几局之后目标降低为了5。现在有一半机率以上扔出来的色子加起来点数会超过5，因此无效。随着目标 越来越小，要想赢的话，扔色子的次数会指数级的上升。最终当目标为2时（最小可能点数），只有一个人平均扔36次或2%扔的次数中，他才能赢。
在例8-10中，成功的nonce为13，且这个结果能被所有人独立确认。任何人将13加到语句 “I am Satoshi Nakamoto” 后面再计算哈希值都能确认它比目标值要小。这个正确的结果同时也是工作量证明（Proof of Work），因为它证明我们的确花时间找到了这个nonce。验证这个哈希值只需要一次计算，而我们找到它却花了13次。如果目标值更小（难度更大），那 我们需要多得多的哈希计算才能找到合适的nonce，但其他人验证它时只需要一次哈希计算。此外，知道目标值后，任何人都可以用统计学来估算其难度，因此 就能知道找到这个nonce需要多少工作。
比特币的工作量证明和例8-10中的挑战非常类似。矿工用一些交易构建一个候选区块。接下来，这个矿工计算这个区块头信息的哈希值，看其是否小于当 前目标值。如果这个哈希值不小于目标值，矿工就会修改这个nonce（通常将之加1）然后再试一次。按当前比特币系统的难度，矿工得试10^15次（10 的15次方）才能找到一个合适的nonce使区块头信息哈希值足够小。
例8-11是一个简化很多的工作量证明算法的实现。
例8-11 简化的工作量证明算法

#!/usr/bin/env python
# example of proof-of-work algorithm
import hashlib
import time
max_nonce = 2 ** 32 # 4 billion
def proof_of_work(header, difficulty_bits):
    # calculate the difficulty target
    target = 2 ** (256-difficulty_bits)
    for nonce in xrange(max_nonce):
        hash_result = hashlib.sha256(str(header)+str(nonce)).hexdigest()
        # check if this is a valid result, below the target
        if long(hash_result, 16) < target:
            print "Success with nonce %d" % nonce
            print "Hash is %s" % hash_result
            return (hash_result,nonce)
    print "Failed after %d (max_nonce) tries" % nonce
    return nonce
if __name__ == '__main__':
    nonce = 0
    hash_result = ''
    # difficulty from 0 to 31 bits
    for difficulty_bits in xrange(32):
        difficulty = 2 ** difficulty_bits
        print "Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits)
        print "Starting search..."
        # checkpoint the current time
        start_time = time.time()
        # make a new block which includes the hash from the previous block
        # we fake a block of transactions - just a string
        new_block = 'test block with transactions' + hash_result
        # find a valid nonce for the new block
        (hash_result, nonce) = proof_of_work(new_block, difficulty_bits)
        # checkpoint how long it took to find a result
        end_time = time.time()
        elapsed_time = end_time - start_time
        print "Elapsed Time: %.4f seconds" % elapsed_time
        if elapsed_time > 0:
            # estimate the hashes per second
            hash_power = float(long(nonce)/elapsed_time)
            print "Hashing Power: %ld hashes per second" % hash_power

你可以任意调整难度值（按二进制bit数来设定，即哈希值开头多少个bit必须是0）。然后执行代码，看看在你的计算机上求解需要多久。在例8-12中，你可以看到该程序在一个普通笔记本电脑上的执行情况。
例8-12 多种难度值的工作量证明算法的运行输出

$ python proof-of-work-example.py*
Difficulty: 1 (0 bits)
[...]
Difficulty: 8 (3 bits)
Starting search...
Success with nonce 9
Hash is 1c1c105e65b47142f028a8f93ddf3dabb9260491bc64474738133ce5256cb3c1
Elapsed Time: 0.0004 seconds
Hashing Power: 25065 hashes per second
Difficulty: 16 (4 bits)
Starting search...
Success with nonce 25
Hash is 0f7becfd3bcd1a82e06663c97176add89e7cae0268de46f94e7e11bc3863e148
Elapsed Time: 0.0005 seconds
Hashing Power: 52507 hashes per second
Difficulty: 32 (5 bits)
Starting search...
Success with nonce 36
Hash is 029ae6e5004302a120630adcbb808452346ab1cf0b94c5189ba8bac1d47e7903
Elapsed Time: 0.0006 seconds
Hashing Power: 58164 hashes per second
[...]
Difficulty: 4194304 (22 bits)
Starting search...
Success with nonce 1759164
Hash is 0000008bb8f0e731f0496b8e530da984e85fb3cd2bd81882fe8ba3610b6cefc3
Elapsed Time: 13.3201 seconds
Hashing Power: 132068 hashes per second
Difficulty: 8388608 (23 bits)
Starting search...
Success with nonce 14214729
Hash is 000001408cf12dbd20fcba6372a223e098d58786c6ff93488a9f74f5df4df0a3
Elapsed Time: 110.1507 seconds
Hashing Power: 129048 hashes per second
Difficulty: 16777216 (24 bits)
Starting search...
Success with nonce 24586379
Hash is 0000002c3d6b370fccd699708d1b7cb4a94388595171366b944d68b2acce8b95
Elapsed Time: 195.2991 seconds
Hashing Power: 125890 hashes per second
[...]
Difficulty: 67108864 (26 bits)
Starting search...
Success with nonce 84561291
Hash is 0000001f0ea21e676b6dde5ad429b9d131a9f2b000802ab2f169cbca22b1e21a
Elapsed Time: 665.0949 seconds
Hashing Power: 127141 hashes per second

你可以看出，随着难度位一位一位地增加，查找正确结果的时间会呈指数级增长。如果你考虑整个256bit数字空间，每次 要求多一个0，你就把哈希查找空间缩减了一半。在例8-12中，为寻找一个nonce使得哈希值开头的26位值为0，一共尝试了8千多万次。即使家用笔记 本每秒可以达270,000多次哈希计算，这个查找依然需要6分钟。
在写这本书的时候，比特币网络要寻找区块头信息哈希值小于 000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7。可以看出，这个 目标哈希值开头的0多了很多。这意味着可接受的哈希值范围大幅缩减，因而找到正确的哈希值更加困难。生成下一个区块需要网络每秒计算1.5 x 10¹⁷次哈希。这看起来像是不可能的任务，但幸运的是比特币网络已经拥有100PH每秒（petahashes per second, peta-为 10¹⁵）的处理能力，平均每10分钟就可以找到一个新区块。

8.7.2 难度表示

在例8-3中，我们在区块中看到难度目标，其被标为”难度位”或简称”bits”。在区块277,316中，它的值为 0x1903a30c。这个标记的值被存为系数/指数格式，前两位十六进制数字为幂，接下来得六位为系数。在这个区块里，0x19为幂，而 0x03a30c 为系数。
计算难度目标的公式为：

 target = coefficient * 2^(8 * (exponent – 3))

由此公式及难度位的值 0x1903a30c，可得：

target = 0x03a30c * 2^(0x08 * (0x19 - 0x03))
=> target = 0x03a30c * 2^(0x08 * 0x16)
=> target = 0x03a30c * 2^0xB0

按十进制计算为：

=> target = 238,348 * 2^176
=> target =
22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328

转化为十六进制后为：

=> target =0x0000000000000003A30C00000000000000000000000000000000000000000000

也就是说高度为277,316的有效区块的头信息哈希值是小于这个目标值的。这个数字的二进制表示中前60位都是0。在 这个难度上，一个每秒可以处理1万亿个哈希计算的矿工（1 tera-hash per second 或 1 TH/sec）平均每8,496个区块才能找到一个正确结果，换句话说，平均每59天，才能为某一个区块找到正确的哈希值。

8.7.3 难度目标与难度调整

如前所述，目标决定了难度，进而影响求解工作量证明算法所需要的时间。那么问题来了：为什么这个难度值是可调整的？由谁来调整？如何调整？
比特币的区块平均每10分钟生成一个。这就是比特币的心跳，是货币发行速率和交易达成速度的基础。不仅是在短期内，而是在几十年内它都必须要保持恒 定。在此期间，计算机性能将飞速提升。此外，参与挖矿的人和计算机也会不断变化。为了能让新区块的保持10分钟一个的产生速率，挖矿的难度必须根据这些变 化进行调整。事实上，难度是一个动态的参数，会定期调整以达到每10分钟一个新区块的目标。简单地说，难度被设定在，无论挖矿能力如何，新区块产生速率都 保持在10分钟一个。
那么，在一个完全去中心化的网络中，这样的调整是如何做到的呢？难度的调整是在每个完整节点中独立自动发生的。每2,016个区块中的所有节点都会 调整难度。难度的调整公式是由最新2,016个区块的花费时长与20,160分钟（两周，即这些区块以10分钟一个速率所期望花费的时长）比较得出的。难 度是根据实际时长与期望时长的比值进行相应调整的（或变难或变易）。简单来说，如果网络发现区块产生速率比10分钟要快时会增加难度。如果发现比10分钟 慢时则降低难度。
这个公式可以总结为如下形式：

New Difficulty = Old Difficulty * (Actual Time of Last 2016 Blocks / 20160 minutes)

例8-13展示了比特币核心客户端中的难度调整代码。
例8-13 工作量证明的难度调整 源文件 pow.cpp 第43行函数 GetNextWorkRequired()

// Go back by what we want to be 14 days worth of blocks
const CBlockIndex* pindexFirst = pindexLast;
for (int i = 0; pindexFirst && i < Params().Interval()-1; i++)
    pindexFirst = pindexFirst->pprev;
assert(pindexFirst);
// Limit adjustment step
int64_t nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime(); LogPrintf(" nActualTimespan = %d before bounds\n", nActualTimespan);
if (nActualTimespan < Params().TargetTimespan()/4)
    nActualTimespan = Params().TargetTimespan()/4;
if (nActualTimespan > Params().TargetTimespan()*4)
    nActualTimespan = Params().TargetTimespan()*4;
// Retarget
uint256 bnNew;
uint256 bnOld;
bnNew.SetCompact(pindexLast->nBits);
bnOld = bnNew;
bnNew *= nActualTimespan;
bnNew /= Params().TargetTimespan();
if (bnNew > Params().ProofOfWorkLimit())
    bnNew = Params().ProofOfWorkLimit();

参数Interval(2,016区块)和TergetTimespan(1,209,600秒及两周) 的定义在文件chainparams.cpp中。
为了防止难度的变化过快，每个周期的调整幅度必须小于一个因子（值为4）。如果要调整的幅度大于4倍，则按4倍调整。由于在下一个2,016区块的 周期不平衡的情况会继续存在，所以进一步的难度调整会在下一周期进行。因此平衡哈希计算能力和难度的巨大差异有可能需要花费几个2,016区块周期才会完 成。

寻找一个比特币区块需要整个网络花费10分钟来处理，每发现2,016个区块时会根据前2,016个区块完成的时间对难度进行调整。

值得注意的是目标难度与交易的数量和金额无关。这意味着哈希算力的强弱，即让比特币更安全的电力投入量，与交易的数量完全无关。换句话说，当比特币 的规模变得更大，使用它的人数更多时，即使哈希算力保持当前的水平，比特币的安全性也不会受到影响。哈希算力的增加表明更多的人为得到比特币回报而加入了 挖矿队伍。只要为了回报，公平正当地从事挖矿的矿工群体保持足够的哈希算力，”接管”攻击就不会得逞，让比特币的安全无虞。
目标难度和挖矿电力消耗与将比特币兑换成现金以支付这些电力之间的关系密切相关。高性能挖矿系统就是要用当前硅芯片以最高效的方式将电力转化为哈希 算力。挖矿市场的关键因素就是每度电转换为比特币后的价格。因为这决定着挖矿活动的营利性，也因此刺激着人们选择进入或退出挖矿市场。

8.8 成功构建区块

前面已经看到，Jing的节点创建了一个候选区块，准备拿它来挖矿。Jing有几个安装了ASIC（专用集成电路）的矿机，上面有成千上万个集成电 路可以超高速地并行运行SHA256算法。这些定制的硬件通过USB连接到他的挖矿节点上。接下来，运行在Jing的桌面电脑上的挖矿节点将区块头信息传 送给这些硬件，让它们以每秒亿万次的速度进行nonce测试。
在对区块277,316的挖矿工作开始大概11分钟后，这些硬件里的其中一个求得了解并发回挖矿节点。当把这个结果放进区块头时，nonce 4,215,469,401 就会产生一个区块哈希值：

0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569

而这个值小于难度目标值：

0000000000000003A30C00000000000000000000000000000000000000000000

Jing的挖矿节点立刻将这个区块发给它的所有相邻节点。这些节点在接收并验证这个新区块后，也会继续传播此区块。当这 个新区块在网络中扩散时，每个节点都会将它作为区块277,316加到自身节点的区块链副本中。当挖矿节点收到并验证了这个新区块后，它们会放弃之前对构 建这个相同高度区块的计算，并立即开始计算区块链中下一个区块的工作。
下节将介绍节点进行区块验证、最长链选择、达成共识，并以此形成一个去中心化区块链的过程。

8.9 校验新区块

比特币共识机制的第三步是通过网络中的每个节点独立校验每个新区块。当新区块在网络中传播时，每一个节点在将它转发到其节点之前，会进行一系列的测 试去验证它。这确保了只有有效的区块会在网络中传播。独立校验还确保了诚实的矿工生成的区块可以被纳入到区块链中，从而获得奖励。行为不诚实的矿工所产生 的区块将被拒绝，这不但使他们失去了奖励，而且也浪费了本来可以去寻找工作量证明解的机会，因而导致其电费亏损。
当一个节点接收到一个新的区块，它将对照一个长长的标准清单对该区块进行验证，若没有通过验证，这个区块将被拒绝。这些标准可以在比特币核心客户端的CheckBlock函数和CheckBlockHead函数中获得，它包括：
▷ 区块的数据结构语法上有效
▷ 区块头的哈希值小于目标难度（确认包含足够的工作量证明）
▷ 区块时间戳早于验证时刻未来两个小时（允许时间错误）
▷ 区块大小在长度限制之内
▷ 第一个交易（且只有第一个）是coinbase交易
▷ 使用检查清单验证区块内的交易并确保它们的有效性，本书177页
▷ “交易的独立校验”一节已经讨论过这个清单。
每一个节点对每一个新区块的独立校验，确保了矿工无法欺诈。在前面的章节中，我们看到了矿工们如何去记录一笔交易，以获得在此区块中创造的新比特币 和交易费。为什么矿工不为他们自己记录一笔交易去获得数以千计的比特币？这是因为每一个节点根据相同的规则对区块进行校验。一个无效的coinbase交 易将使整个区块无效，这将导致该区块被拒绝，因此，该交易就不会成为总账的一部分。矿工们必须构建一个完美的区块，基于所有节点共享的规则，并且根据正确 工作量证明的解决方案进行挖矿，他们要花费大量的电力挖矿才能做到这一点。如果他们作弊，所有的电力和努力都会浪费。这就是为什么独立校验是去中心化共识 的重要组成部分。

==目录==

简介
前言
第1章 介绍
第2章 比特币的原理
第3章 比特币客户端
第4章 密钥、地址、钱包
第4章 高级密钥和地址
第5章 交易
第6章 比特币网络
第7章 区块链
第8章 挖矿与共识
第8章 区块链分叉、矿池、共识攻击
第9章 竞争币、竞争块链和应用程序
第10章 比特币安全
附录1 交易脚本的操作符、常量和符号
附录2 比特币改进协议
附录3 pycoin库、ku程序和tx交易程序
附录4 sx工具下一些的命令
本文原链接：http://zhibimo.com/read/wang-miao/Mastering-Bitcoin/Chapter08.html

第7章 区块链

7.1 简介

区块链是由包含交易信息的区块从后向前有序链接起来的数据结构。它可以被存储为flat file（一种包含没有相对关系记录的文件），或是存储在一个简单数据库中。比特币核心客户端使用Google的LevelDB数据库存储区块链元数据。区块被从后向前有序地链接在这个链条里，每个区块都指向前一个区块。区块链经常被视为一个垂直的栈，第一个区块作为栈底的首区块，随后每个区块都被放置在其他区块之上。用栈来形象化表示区块依次堆叠这一概念后，我们便可以使用一些术语，例如：“高度”来表示区块与首区块之间的距离；以及“顶部”或“顶端”来表示最新添加的区块。
对每个区块头进行SHA256加密哈希，可生成一个哈希值。通过这个哈希值，可以识别出区块链中的对应区块。同时，每一个区块都可以通过其区块头的“父区块哈希值”字段引用前一区块（父区块）。也就是说，每个区块头都包含它的父区块哈希值。这样把每个区块链接到各自父区块的哈希值序列就创建了一条一直可以追溯到第一个区块（创世区块）的链条。
虽然每个区块只有一个父区块，但可以暂时拥有多个子区块。每个子区块都将同一区块作为其父区块，并且在“父区块哈希值”字段中具有相同的（父区块）哈希值。一个区块出现多个子区块的情况被称为“区块链分叉”。区块链分叉只是暂时状态，只有当多个不同区块几乎同时被不同的矿工发现时才会发生（参见“8.10.1 区块链分叉”）。最终，只有一个子区块会成为区块链的一部分，同时解决了“区块链分叉”的问题。尽管一个区块可能会有不止一个子区块，但每一区块只有一个父区块，这是因为一个区块只有一个“父区块哈希值”字段可以指向它的唯一父区块。
由于区块头里面包含“父区块哈希值”字段，所以当前区块的哈希值因此也受到该字段的影响。如果父区块的身份标识发生变化，子区块的身份标识也会跟着变化。当父区块有任何改动时，父区块的哈希值也发生变化。父区块的哈希值发生改变将迫使子区块的“父区块哈希值”字段发生改变，从而又将导致子区块的哈希值发生改变。而子区块的哈希值发生改变又将迫使孙区块的“父区块哈希值”字段发生改变，又因此改变了孙区块哈希值，等等以此类推。一旦一个区块有很多代以后，这种瀑布效应将保证该区块不会被改变，除非强制重新计算该区块所有后续的区块。正是因为这样的重新计算需要耗费巨大的计算量，所以一个长区块链的存在可以让区块链的历史不可改变，这也是比特币安全性的一个关键特征。
你可以把区块链想象成地质构造中的地质层或者是冰川岩芯样品。表层可能会随着季节而变化，甚至在沉积之前就被风吹走了。但是越往深处，地质层就变得越稳定。到了几百英尺深的地方，你看到的将是保存了数百万年但依然保持历史原状的岩层。在区块链里，最近的几个区块可能会由于区块链分叉所引发的重新计算而被修改。最新的六个区块就像几英寸深的表土层。但是，超过这六块后，区块在区块链中的位置越深，被改变的可能性就越小。在100个区块以后，区块链已经足够稳定，这时coinbase交易（包含新挖出的比特币的交易）可以被支付。几千个区块（一个月）后的区块链将变成确定的历史，永远不会改变。

7.2 区块结构

区块是一种被包含在公开账簿（区块链）里的聚合了交易信息的容器数据结构。它由一个包含元数据的区块头和紧跟其后的构成区块主体的一长串交易组成。区块头是80字节，而平均每个交易至少是250字节，而且平均每个区块至少包含超过500个交易。因此，一个包含所有交易的完整区块比区块头的1000倍还要大。表7-1描述了一个区块结构。
表7-1 区块结构

7.3 区块头

区块头由三组区块元数据组成。首先是一组引用父区块哈希值的数据，这组元数据用于将该区块与区块链中前一区块相连接。第二组元数据，即难度、时间戳和nonce，与挖矿竞争相关，详见第8章。第三组元数据是merkle树根（一种用来有效地总结区块中所有交易的数据结构）。表7-2描述了区块头的数据结构。
表7-2 区块头结构

Nonce、难度目标和时间戳会用于挖矿过程，更多细节将在第8章讨论。

7.4 区块标识符：区块头哈希值和区块高度

区块主标识符是它的加密哈希值，一个通过SHA256算法对区块头进行二次哈希计算而得到的数字指纹。产生的32字节哈希值被称为区块哈希值，但是更准确的名称是：区块头哈希值，因为只有区块头被用于计算。例如:000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f是第一个比特币区块的区块哈希值。区块哈希值可以唯一、明确地标识一个区块，并且任何节点通过简单地对区块头进行哈希计算都可以独立地获取该区块哈希值。
请注意，区块哈希值实际上并不包含在区块的数据结构里，不管是该区块在网络上传输时，抑或是它作为区块链的一部分被存储在某节点的永久性存储设备上时。相反，区块哈希值是当该区块从网络被接收时由每个节点计算出来的。区块的哈希值可能会作为区块元数据的一部分被存储在一个独立的数据库表中，以便于索引和更快地从磁盘检索区块。
第二种识别区块的方式是通过该区块在区块链中的位置，即“区块高度（block height）”。第一个区块，其区块高度为0，和之前哈希值000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f所引用的区块为同一个区块。因此，区块可以通过两种方式被识别：区块哈希值或者区块高度。每一个随后被存储在第一个区块之上的区块在区块链中都比前一区块“高”出一个位置，就像箱子一个接一个堆叠在其他箱子之上。2014年1月1日的区块高度大约是278,000，说明已经有278,000个区块被堆叠在2009年1月创建的第一个区块之上。
和区块哈希值不同的是，区块高度并不是唯一的标识符。虽然一个单一的区块总是会有一个明确的、固定的区块高度，但反过来却并不成立，一个区块高度并不总是识别一个单一的区块。两个或两个以上的区块可能有相同的区块高度，在区块链里争夺同一位置。这种情况在“8.10.1 区块链分叉”一节中有详细讨论。区块高度也不是区块数据结构的一部分，它并不被存储在区块里。当节点接收来自比特币网络的区块时，会动态地识别该区块在区块链里的位置（区块高度）。区块高度也可作为元数据存储在一个索引数据库表中以便快速检索。

一个区块的区块哈希值总是能唯一地识别出一个特定区块。一个区块也总是有特定的区块高度。但是，一个特定的区块高度并不一定总是能唯一地识别出一个特定区块。更确切地说，两个或者更多数量的区块也许会为了区块中的一个位置而竞争。

7.5 创世区块

区块链里的第一个区块创建于2009年，被称为创世区块。它是区块链里面所有区块的共同祖先，这意味着你从任一区块，循链向后回溯，最终都将到达创世区块。
因为创世区块被编入到比特币客户端软件里，所以每一个节点都始于至少包含一个区块的区块链，这能确保创世区块不会被改变。每一个节点都“知道”创世区块的哈希值、结构、被创建的时间和里面的一个交易。因此，每个节点都把该区块作为区块链的首区块，从而构建了一个安全的、可信的区块链的根。
在chainparams.cpp里可以看到创世区块被编入到比特币核心客户端里。
创世区块的哈希值为：

0000000000 19d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

你可以在任何区块浏览网站搜索这个区块哈希值，如blockchain.info，你会发现一个用包含这个哈希值的链接来描述这一区块内容的页面：
https://blockchain.info/block/ 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
https://blockexplorer.com/block/ 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
在命令行使用比特币核心客户端：

$ bitcoindgetblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f{    "hash":"000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",    "confirmations":308321,    "size":285,    "height":0,    "version":1,    "merkleroot":"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",    "tx":["4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"],    "time":1231006505,    "nonce":2083236893,    "bits":"1d00ffff",    "difficulty":1.00000000,    "nextblockhash":"00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"}

创世区块包含一个隐藏的信息。在其Coinbase交易的输入中包含这样一句话“The Times 03/Jan/2009 Chancellor on brink of second bailout forbanks.”这句话是泰晤士报当天的头版文章标题，引用这句话，既是对该区块产生时间的说明，也可视为半开玩笑地提醒人们一个独立的货币制度的重要性，同时告诉人们随着比特币的发展，一场前所未有的世界性货币革命将要发生。该消息是由比特币的创立者中本聪嵌入创世区块中。

7.6 区块的连接

比特币的完整节点保存了区块链从创世区块起的一个本地副本。随着新的区块的产生，该区块链的本地副本会不断地更新用于扩展这个链条。当一个节点从网络接收传入的区块时，它会验证这些区块，然后链接到现有的区块链上。为建立一个连接，一个节点将检查传入的区块头并寻找该区块的“父区块哈希值”。
让我们假设，例如，一个节点在区块链的本地副本中有277,314个区块。该节点知道最后一个区块为第277,314个区块，这个区块的区块头哈希值为：00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249。
然后该比特币节点从网络上接收到一个新的区块，该区块描述如下：

{    "size":43560,    "version":2,    "previousblockhash":"00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249",    "merkleroot":"5e049f4030e0ab2debb92378f53c0a6e09548aea083f3ab25e1d94ea1155e29d",    "time":1388185038,    "difficulty":1180923195.25802612,    "nonce":4215469401,    "tx":["257e7497fb8bc68421eb2c7b699dbab234831600e7352f0d9e6522c7cf3f6c77",        #[...many more transactions omitted...]        "05cfd38f6ae6aa83674cc99e4d75a1458c165b7ab84725eda41d018a09176634"    ]}

对于这一新的区块，节点会在“父区块哈希值”字段里找出包含它的父区块的哈希值。这是节点已知的哈希值，也就是第277314块区块的哈希值。故这个区块是这个链条里的最后一个区块的子区块，因此现有的区块链得以扩展。节点将新的区块添加至链条的尾端，使区块链变长到一个新的高度277,315。图7-1显示了通过“父区块哈希值”字段进行连接三个区块的链。

图7-1 区块通过引用父区块的区块头哈希值的方式，以链条的形式进行相连

7.7 Merkle 树

区块链中的每个区块都包含了产生于该区块的所有交易，且以Merkle树表示。
Merkle树是一种哈希二叉树，它是一种用作快速归纳和校验大规模数据完整性的数据结构。这种二叉树包含加密哈希值。术语“树”在计算机学科中常被用来描述一种具有分支的数据结构，但是树常常被倒置显示，“根”在图的上部同时“叶子”在图的下部，你会在后续章节中看到相应的例子。
在比特币网络中，Merkle树被用来归纳一个区块中的所有交易，同时生成整个交易集合的数字指纹，且提供了一种校验区块是否存在某交易的高效途径。生成一棵完整的Merkle树需要递归地对哈希节点对进行哈希，并将新生成的哈希节点插入到Merkle树中，直到只剩一个哈希节点，该节点就是Merkle树的根。在比特币的Merkle树中两次使用到了SHA256算法，因此其加密哈希算法也被称为double-SHA256。
当N个数据元素经过加密后插入Merkle树时，你至多计算2*log2(N)次就能检查出任意某数据元素是否在该树中，这使得该数据结构非常高效。
Merkle树是自底向上构建的。在如下的例子中，我们从A、B、C、D四个构成Merkle树树叶的交易开始，如图7-2。起始时所有的交易都还未存储在Merkle树中，而是先将数据哈希化，然后将哈希值存储至相应的叶子节点。这些叶子节点分别是HA、HB、HC和HD：

H~A~ = SHA256(SHA256(交易A))

通过串联相邻叶子节点的哈希值然后哈希之，这对叶子节点随后被归纳为父节点。 例如，为了创建父节点HAB，子节点A和子节点B的两个32字节的哈希值将被串联成64字节的字符串。随后将字符串进行两次哈希来产生父节点的哈希值:

H~AB~=SHA256(SHA256(H~A~ + H~B~))

继续类似的操作直到只剩下顶部的一个节点，即Merkle根。产生的32字节哈希值存储在区块头，同时归纳了四个交易的所有数据。

图7-2 在Merkle树中计算节点

因为Merkle树是二叉树，所以它需要偶数个叶子节点。如果仅有奇数个交易需要归纳，那最后的交易就会被复制一份以构成偶数个叶子节点，这种偶数个叶子节点的树也被称为平衡树。如图7-3所示，C节点被复制了一份。

图7-3 复制一份数据节点，使整个树中数据节点个数是偶数

由四个交易构造Merkle树的方法同样适用于从任意交易数量构造Merkle树。在比特币中，在单个区块中有成百上千的交易是非常普遍的，这些交易都会采用同样的方法归纳起来，产生一个仅仅32字节的数据作为Merkle根。在图7-4中，你会看见一个从16个交易形成的树。需要注意的是，尽管图中的根看起来比所有叶子节点都大，但实际上它们都是32字节的相同大小。无论区块中有一个交易或者有十万个交易，Merkle根总会把所有交易归纳为32字节。

图7-4 一颗囊括了许多数据元素的Merkle树

为了证明区块中存在某个特定的交易，一个节点只需要计算log2(N)个32字节的哈希值，形成一条从特定交易到树根的认证路径或者Merkle路径即可。随着交易数量的急剧增加，这样的计算量就显得异常重要，因为相对于交易数量的增长，以基底为2的交易数量的对数的增长会缓慢许多。这使得比特币节点能够高效地产生一条10或者12个哈希值（320-384字节）的路径，来证明了在一个巨量字节大小的区块中上千交易中的某笔交易的存在。
在图7-5中，一个节点能够通过生成一条仅有4个32字节哈希值长度（总128字节）的Merkle路径，来证明区块中存在一笔交易K。该路径有4个哈希值（在图7-5中由蓝色标注）HL、HIJ、HMNOP和HABCDEFGH。由这4个哈希值产生的认证路径，再通过计算另外四对哈希值HKL、HIJKL、HIJKLMNOP和Merkle树根（在图中由虚线标注），任何节点都能证明HK（在图中由绿色标注）包含在Merkle根中。

图7-5 一条为了证明树中包含某个数据元素而使用的Merkle路径

例7-1中的代码借用libbitcoin库中的一些辅助程序，演示了从叶子节点哈希至根创建整个Merkle树的过程。
例7-1 构造Merkle树

#include bc::hash_digest create_merkle(bc::hash_digest_list& merkle){// Stop if hash list is empty.    if (merkle.empty())        return bc::null_hash;    else if (merkle.size() == 1)        return merkle[0];     // While there is more than 1 hash in the list, keep looping…    while (merkle.size() > 1)     {        // If number of hashes is odd, duplicate last hash in the list.        if (merkle.size() % 2 != 0)            merkle.push_back(merkle.back());        // List size is now even.        assert(merkle.size() % 2 == 0);        // New hash list.        bc::hash_digest_list new_merkle;        // Loop through hashes 2 at a time.        for (auto it = merkle.begin(); it != merkle.end(); it += 2)         {            // Join both current hashes together (concatenate).            bc::data_chunk concat_data(bc::hash_size * 2);            auto concat = bc::make_serializer(concat_data.begin());            concat.write_hash(*it);            concat.write_hash(*(it + 1));            assert(concat.iterator() == concat_data.end());            // Hash both of the hashes.            bc::hash_digest new_root = bc::bitcoin_hash(concat_data);             // Add this to the new list.            new_merkle.push_back(new_root);                    }        // This is the new list.        merkle = new_merkle;        // DEBUG output -------------------------------------        std::cout << "Current merkle hash list:" << std::endl;        for (const auto& hash: merkle)            std::cout << " " << bc::encode_hex(hash) << std::endl;        std::cout << std::endl;        // --------------------------------------------------    }    // Finally we end up with a single item.    return merkle[0]; }int main(){    // Replace these hashes with ones from a block to reproduce the same merkle root.    bc::hash_digest_list tx_hashes{        {            bc::decode_hash("0000000000000000000000000000000000000000000000000000000000000000"),            bc::decode_hash("0000000000000000000000000000000000000000000000000000000000000011"),            bc::decode_hash("0000000000000000000000000000000000000000000000000000000000000022"),        }    };    const bc::hash_digest merkle_root = create_merkle(tx_hashes);    std::cout << "Result: " << bc::encode_hex(merkle_root) << std::endl;    return 0;}

例7-2展示了编译以及运行上述代码后的结果。
例7-2 编译以及运行构造Merkle树代码

$ # Compile the merkle.cpp code$ g++ -o merkle merkle.cpp $(pkg-config --cflags --libs libbitcoin) $ # Run the merkle executable$ ./merkleCurrent merkle hash list:32650049a0418e4380db0af81788635d8b65424d397170b8499cdc28c4d2700630861db96905c8dc8b99398ca1cd5bd5b84ac3264a4e1b3e65afa1bcee7540c4Current merkle hash list:    d47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3Result: d47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3

Merkle树的高效随着交易规模的增加而变得异常明显。表7-3展示了为了证明区块中存在某交易而所需转化为Merkle路径的数据量。
表7-3 Merkle树的效率

依表可得，当区块大小由16笔交易（4KB）急剧增加至65,535笔交易（16MB）时，为证明交易存在的Merkle路径长度增长极其缓慢，仅仅从128字节到512字节。有了Merkle树，一个节点能够仅下载区块头（80字节/区块），然后通过从一个满节点回溯一条小的Merkle路径就能认证一笔交易的存在，而不需要存储或者传输大量区块链中大多数内容，这些内容可能有几个G的大小。这种不需要维护一条完整的区块链的节点，又被称作简单支付验证（SPV）节点，它不需要下载整个区块而通过Merkle路径去验证交易的存在。

7.8 Merkle树和简单支付验证（SPV）

Merkle树被SPV节点广泛使用。SPV节点不保存所有交易也不会下载整个区块，仅仅保存区块头。它们使用认证路径或者Merkle路径来验证交易存在于区块中，而不必下载区块中所有交易。
例如，一个SPV节点欲知它钱包中某个比特币地址即将到达的支付，该节点会在节点间的通信链接上建立起bloom过滤器，限制只接受含有目标比特币地址的交易。当节点探测到某交易符合bloom过滤器，它将以Merkle区块消息的形式发送该区块。Merkle区块消息包含区块头和一条连接目标交易与Merkle根的Merkle路径。SPV节点能够使用该路径找到与该交易相关的区块，进而验证对应区块中该交易的有无。SPV节点同时也使用区块头去关联区块和区块链中的区域区块。这两种关联，交易与区块、区块和区块链，证明交易存在于区块链。简而言之，SPV节点会收到少于1KB的有关区块头和Merkle路径的数据，其数据量比一个完整的区块（目前大约有1MB）少了一千倍有余。

第6章 比特币网络

6.1 P2P网络架构

比特币采用了基于国际互联网（Internet）的P2P（peer-to-peer）网络架构。P2P是指位于同一网络中的每台计算机都彼此对等，各个节点共同提供网络服务，不存在任何“特殊”节点。每个网络节点以“扁平（flat）”的拓扑结构相互连通。在P2P网络中不存在任何服务端（server）、中央化的服务、以及层级结构。P2P网络的节点之间交互运作、协同处理：每个节点在对外提供服务的同时也使用网络中其他节点所提供的服务。P2P网络也因此具有可靠性、去中心化，以及开放性。早期的国际互联网就是P2P网络架构的一个典型用例：IP网络中的各个节点完全平等。当今的互联网架构具有分层架构，但是IP协议仍然保留了扁平拓扑的结构。在比特币之外，规模最大也最成功的P2P技术应用是在文件分享领域：Napster是该领域的先锋，BitTorrent是其架构的最新演变。
比特币所采用的P2P网络架构不仅仅是选择拓扑结构这样简单。比特币被设计为一种点对点的数字现金系统，它的网络架构既是这种核心特性的反映，也是该特性的基石。去中心化控制是设计时的核心原则，它只能通过维持一种扁平化、去中心化的P2P共识网络来实现。
“比特币网络”是按照比特币P2P协议运行的一系列节点的集合。除了比特币P2P协议之外，比特币网络中也包含其他协议。例如Stratum协议就被应用于挖矿、以及轻量级或移动端比特币钱包之中。网关（gateway）路由服务器提供这些协议，使用比特币P2P协议接入比特币网络，并把网络拓展到运行其他协议的各个节点。例如，Stratum服务器通过Stratum协议将所有的Stratum挖矿节点连接至比特币主网络、并将Stratum协议桥接（bridge）至比特币P2P协议之上。我们使用“扩展比特币网络（extended bitcoin network）”指代所有包含比特币P2P协议、矿池挖矿协议、Stratum协议以及其他连接比特币系统组件相关协议的整体网络结构。

6.2 节点类型及分工

尽管比特币P2P网络中的各个节点相互对等，但是根据所提供的功能不同，各节点可能具有不同的分工。每个比特币节点都是路由、区块链数据库、挖矿、钱包服务的功能集合。一个全节点（full node）包括如图6-1所示的四个功能：

图6-1 一个包含四个完整功能的比特币网络节点：钱包、矿工、完整区块链、网络路由节点

每个节点都参与全网络的路由功能，同时也可能包含其他功能。每个节点都参与验证并传播交易及区块信息，发现并维持与对等节点的连接。在图6-1所示的全节点用例中，名为“网络路由节点”的橙色圆圈即表示该路由功能。
一些节点保有一份完整的、最新的区块链拷贝，这样的节点被称为“全节点”。全节点能够独立自主地校验所有交易，而不需借由任何外部参照。另外还有一些节点只保留了区块链的一部分，它们通过一种名为“简易支付验证（SPV）”的方式来完成交易验证。这样的节点被称为“SPV节点”，又叫“轻量级节点”。在如上图所示的全节点用例中，名为完整区块链的蓝色圆圈即表示了全节点区块链数据库功能。在图6-3中，SPV节点没有此蓝色圆圈，以示它们没有区块链的完整拷贝。
挖矿节点通过运行在特殊硬件设备上的工作量证明（proof-of-work）算法，以相互竞争的方式创建新的区块。一些挖矿节点同时也是全节点，保有区块链的完整拷贝；还有一些参与矿池挖矿的节点是轻量级节点，它们必须依赖矿池服务器维护的全节点进行工作。在全节点用例中，挖矿功能如图中名为“矿工”的黑色圆圈所示。
用户钱包也可以作为全节点的一部分，这在桌面比特币客户端中比较常见。当前，越来越多的用户钱包都是SPV节点，尤其是运行于诸如智能手机等资源受限设备上的比特币钱包应用；而这正变得越来越普遍。在图6-1中，名为“钱包”的绿色圆圈代表钱包功能。
在比特币P2P协议中，除了这些主要的节点类型之外，还有一些服务器及节点也在运行着其他协议，例如特殊矿池挖矿协议、轻量级客户端访问协议等。
图6-2描述了扩展比特币网络中最为常见的节点类型。

图6-2 扩展比特币网络的不同节点类型

6.3 扩展比特币网络

运行比特币P2P协议的比特币主网络由大约7000-10000个运行着不同版本比特币核心客户端（Bitcoin Core）的监听节点、以及几百个运行着各类比特币P2P协议的应用（例如BitcoinJ、Libbitcoin、btcd等）的节点组成。比特币P2P网络中的一小部分节点也是挖矿节点，它们竞争挖矿、验证交易、并创建新的区块。许多连接到比特币网络的大型公司运行着基于Bitcoin核心客户端的全节点客户端，它们具有区块链的完整拷贝及网络节点，但不具备挖矿及钱包功能。这些节点是网络中的边缘路由器（edge routers），通过它们可以搭建其他服务，例如交易所、钱包、区块浏览器、商家支付处理（merchant payment processing）等。
如前文所述，扩展比特币网络既包括了运行比特币P2P协议的网络，又包含运行特殊协议的网络节点。比特币P2P主网络上连接着许多矿池服务器以及协议网关，它们把运行其他协议的节点连接起来。这些节点通常都是矿池挖矿节点（参见第8章）以及轻量级钱包客户端，它们通常不具备区块链的完整备份。
图6-3描述了扩展比特币网络，它包括了多种类型的节点、网关服务器、边缘路由器、钱包客户端以及它们相互连接所需的各类协议。

图6-3 具有多种节点类型、网关及协议的扩展比特币网络

6.4 网络发现

当新的网络节点启动后，为了能够参与协同运作，它必须发现网络中的其他比特币节点。新的网络节点必须发现至少一个网络中存在的节点并建立连接。由于比特币网络的拓扑结构并不基于节点间的地理位置，因此各个节点之间的地理信息完全无关。在新节点连接时，可以随机选择网络中存在的比特币节点与之相连。
节点通常采用TCP协议、使用8333端口（该端口号通常是比特币所使用的，除8333端口外也可以指定使用其他端口）与已知的对等节点建立连接。在建立连接时，该节点会通过发送一条包含基本认证内容的version消息开始“握手”通信过程(见图6-4)。这一过程包括如下内容：
▷ PROTOCOL_VERSION
常量，定义了客户端所“说出”的比特币P2P协议所采用的版本（例如：70002）。
▷ nLocalServices
一组该节点支持的本地服务列表，当前仅支持NODE_NETWORK
▷ nTime
当前时间
▷ addrYou
当前节点可见的远程节点的IP地址
▷ addrMe
本地节点所发现的本机IP地址
▷ subver
指示当前节点运行的软件类型的子版本号（例如：”/Satoshi:0.9.2.1/”）
▷ BaseHeight
当前节点区块链的区块高度
（version网络消息的具体用例请参见GitHub）
网络中的对等节点通过对verack消息的响应进行确认并建立连接；有时候，如果接收节点需要互换连接并连回起始节点，也会传回该对等节点的version消息。
新节点是如何发现网络中的对等节点的呢？虽然比特币网络中没有特殊节点，但是客户端会维持一个列表，那里列出了那些长期稳定运行的节点。这样的节点被称为“种子节点（seed nodes）”。新节点并不一定需要与种子节点建立连接，但连接到种子节点的好处是可以通过种子节点来快速发现网络中的其他节点。在比特币核心客户端中，是否使用种子节点是通过“-dnsseed”控制的。默认情况下，该选项设为1，即意味着使用种子节点。另一种方式是，起始时将至少一个比特币节点的IP地址提供给正在启动的节点（该节点不包含任何比特币网络的组成信息）。在这之后，启动节点可以通过后续指令建立新的连接。用户可以使用命令行参数“-seednode”把启动节点“引荐”并连接到一个节点，并将该节点用作DNS种子。在初始种子节点被用于形成“引荐”信息之后，客户端会断开与它的连接、并与新发现的对等节点进行通信。

图6-4 对等节点之间的初始“握手”通信

当建立一个或多个连接后，新节点将一条包含自身IP地址的addr消息发送给其相邻节点。相邻节点再将此条addr消息依次转发给它们各自的相邻节点，从而保证新节点信息被多个节点所接收、保证连接更稳定。另外，新接入的节点可以向它的相邻节点发送getaddr消息，要求它们返回其已知对等节点的IP地址列表。通过这种方式，节点可以找到需连接到的对等节点，并向网络发布它的消息以便其他节点查找。图6-5描述了这种地址发现协议。

图6-5 地址广播及发现

节点必须连接到若干不同的对等节点才能在比特币网络中建立通向比特币网络的种类各异的路径（path）。由于节点可以随时加入和离开，通讯路径是不可靠的。因此，节点必须持续进行两项工作：在失去已有连接时发现新节点，并在其他节点启动时为其提供帮助。节点启动时只需要一个连接，因为第一个节点可以将它引荐给它的对等节点，而这些节点又会进一步提供引荐。一个节点，如果连接到大量的其他对等节点，这既没必要，也是对网络资源的浪费。在启动完成后，节点会记住它最近成功连接的对等节点；因此，当重新启动后它可以迅速与先前的对等节点网络重新建立连接。如果先前的网络的对等节点对连接请求无应答，该节点可以使用种子节点进行重启动。
在运行比特币核心客户端的节点上，您可以使用getpeerinfo命令列出对等节点连接信息：

$ bitcoin-cli getpeerinfo[    {        "addr" : "85.213.199.39:8333",        "services" : "00000001",        "lastsend" : 1405634126,        "lastrecv" : 1405634127,        "bytessent" : 23487651,        "bytesrecv" : 138679099,        "conntime" : 1405021768,        "pingtime" : 0.00000000,        "version" : 70002,        "subver" : "/Satoshi:0.9.2.1/",        "inbound" : false,        "startingheight" : 310131,        "banscore" : 0,        "syncnode" : true    },    {        "addr" : "58.23.244.20:8333",        "services" : "00000001",        "lastsend" : 1405634127,        "lastrecv" : 1405634124,        "bytessent" : 4460918,        "bytesrecv" : 8903575,        "conntime" : 1405559628,        "pingtime" : 0.00000000,        "version" : 70001,        "subver" : "/Satoshi:0.8.6/",        "inbound" : false,        "startingheight" : 311074,        "banscore" : 0,        "syncnode" : false    }]

用户可以通过提供-connect=<ip地址>选项来指定一个或多个IP地址，从而达到复写自动节点管理功能并指定IP地址列表的目的。如果采用此选项，节点只连接到这些选定的节点IP地址，而不会自动发现并维护对等节点之间的连接。
如果已建立的连接没有数据通信，所在的节点会定期发送信息以维持连接。如果节点持续某个连接长达90分钟没有任何通信，它会被认为已经从网络中断开，网络将开始查找一个新的对等节点。因此，比特币网络会随时根据变化的节点及网络问题进行动态调整，不需经过中心化的控制即可进行规模增、减的有机调整。

6.5 全节点

全节点是指维持包含全部交易信息的完整区块链的节点。更加准确地说，这样的节点应当被称为完整区块链节点”。在比特币发展的早期，所有节点都是全节点；当前的比特币核心客户端也是完整区块链节点。但在过去的两年中出现了许多新型客户端，它们不需要维持完整的区块链，而是作为轻量级客户端运行。在下面的章节里我们会对这些轻量级客户端进行详细介绍。
完整区块链节点保有完整的、最新的包含全部交易信息的比特币区块链拷贝，这样的节点可以独立地进行建立并校验区块链，从第一区块（创世区块）一直建立到网络中最新的区块。完整区块链节点可以独立自主地校验任何交易信息，而不需要借助任何其他节点或其他信息来源。完整区块节点通过比特币网络获取包含交易信息的新区块更新，在验证无误后将此更新合并至本地的区块链拷贝之中。
运行完整区块链节点可以给您一种纯粹的比特币体验：不需借助或信任其他系统即可独立地对所有交易信息进行验证。辨别您是否在运行全节点是十分容易的：只需要查看您的永久性存储设备（如硬盘）是否有超过20GB的空间被用来存储完整区块链即可。如果您需要很大的磁盘空间、并且同步比特币网络耗时2至3天，那么您使用的正是全节点。这就是摆脱中心化管理、获得完全的独立自由所要付出的代价。
尽管目前还有一些使用不同编程语言及软件架构的其他的完整区块链客户端存在，但是最常用的仍然是比特币核心客户端，它也被称为“Satoshi客户端”。比特币网络中超过90%的节点运行着各个版本的比特币核心客户端。如前文所述，它可以通过节点间发送的version消息或通过getpeerinfo命令所得到的子版本字符串“Satoshi”加以辨识，例如 /Satoshi: 0.8.6/。

6.6 交换“库存清单”

一个全节点连接到对等节点之后，第一件要做的事情就是构建完整的区块链。如果该节点是一个全新节点，那么它就不包含任何区块链信息，它只知道一个区块——静态植入在客户端软件中的创世区块。新节点需要下载从0号区块（创世区块）开始的数十万区块的全部内容，才能跟网络同步、并重建全区块链。
同步区块链的过程从发送version消息开始，这是因为该消息中含有的BestHeight字段标示了一个节点当前的区块链高度（区块数量）。节点可以从它的对等节点中得到版本消息，了解双方各自有多少区块，从而可以与其自身区块链所拥有的区块数量进行比较。对等节点们会交换一个getblocks消息，其中包含他们本地区块链的顶端区块哈希值。如果某个对等节点识别出它接收到的哈希值并不属于顶端区块，而是属于一个非顶端区块的旧区块，那么它就能推断出：其自身的本地区块链比其他对等节点的区块链更长。
拥有更长区块链的对等节点比其他节点有更多的区块，可以识别出哪些区块们是其他节点需要“补充”的。它会识别出第一批可供分享的500个区块，通过使用inv（inventory）消息把这些区块的哈希值传播出去。缺少这些区块的节点便可以通过各自发送的getdata消息来请求得到全区块信息，用包含在inv消息中的哈希值来确认是否为正确的被请求的区块，从而读取这些缺失的区块。
在下例中，我们假设某节点只含有创世区块。它收到了来自对等节点的inv消息，其中包含了区块链中后500个区块的哈希值。于是它开始向所有与之相连的对等节点请求区块，并通过分摊工作量的方式防止单一对等节点被批量请求所压垮。该节点会追踪记录其每个对等节点连接上“正在传输”（指那些它已经发出了请求但还没有接收到）的区块数量，并且检查该数量有没有超过上限（MAX_BLOCKS_IN_TRANSIT_PER_PEER）。用这种办法，如果一个节点需要更新大量区块，它会在上一请求完成后才发送对新区块的请求，从而允许对等节点控制更新速度，不至于压垮网络。每一个区块在被接收后就会被添加至区块链中，这一过程详见第7章。随着本地区块链的逐步建立，越来越多的区块被请求和接收，整个过程将一直持续到该节点与全网络完成同步为止。
每当一个节点离线，不管离线时间有多长，这个与对等节点比较本地区块链并恢复缺失区块的过程就会被触发。如果一个节点只离线几分钟，可能只会缺失几个区块；当它离线长达一个月，可能会缺失上千个区块。但无论哪种情况，它都会从发送getblocks消息开始，收到一个inv响应，接着开始下载缺失的区块库存清单和区块广播协议如图6-6所示。

图6-6 节点通过从对等节点读取区块来同步区块链

6.7 简易支付验证 （SPV）节点

并非所有的节点都有能力储存完整的区块链。许多比特币客户端被设计成运行在空间和功率受限的设备上，如智能电话、平板电脑、嵌入式系统等。对于这样的设备，通过简化的支付验证（SPV）的方式可以使它们在不必存储完整区块链的情况下进行工作。这种类型的客端被称为SPV客户端或轻量级客户端。随着比特币的使用热潮，SPV节点逐渐变成比特币节点（尤其是比特币钱包）所采用的最常见的形式。
SPV节点只需下载区块头，而不用下载包含在每个区块中的交易信息。由此产生的不含交易信息的区块链，大小只有完整区块链的1/1000。SPV节点不能构建所有可用于消费的UTXO的全貌，这是由于它们并不知道网络上所有交易的完整信息。SPV节点验证交易时所使用的方法略有不同，这个方法需依赖对等节点“按需”提供区块链相关部分的局部视图。
打个比方来说，每个全节点就像是一个在陌生城市里的游客，他带着一张包含每条街道、每个地址的详细地图。相比之下，SPV节点就像是这名陌生城市里的游客只知道一条主干道的名字，通过随机询问该城市的陌生人来获取分段道路指示。虽然两种游客都可以通过实地考察来验证一条街是否存在，但没有地图的游客不知道每个小巷中有哪些街道，也不知道附近还有什么其他街道。没有地图的游客在“教堂街23号”的前面，并不知道这个城市里是否还有其他若干条“教堂街23号”，也不知道面前的这个是否是要找的那个。对他来说，最好的方式就是向足够多的人问路，并且希望其中一部分人不是要试图抢劫他。
简易支付验证是通过参考交易在区块链中的深度，而不是高度，来验证它们。一个拥有完整区块链的节点会构造一条验证链，这条链是由沿着区块链按时间倒序一直追溯到创世区块的数千区块及交易组成。而一个SPV节点会验证所有区块的链（但不是所有的交易），并且把区块链和有关交易链接起来。
例如，一个全节点要检查第300,000号区块中的某个交易，它会把从该区块开始一直回溯到创世区块的300,000个区块全部都链接起来，并建立一个完整的UTXO数据库，通过确认该UTXO是否还未被支付来证实交易的有效性。SPV节点则不能验证UTXO是否还未被支付。相反地，SPV节点会在该交易信息和它所在区块之间用merkle路径（见“7.7 Merkle 树”）建立一条链接。然后SPV节点一直等待，直到序号从300,001到300,006的六个区块堆叠在该交易所在的区块之上，并通过确立交易的深度是在第300,006区块~第300,001区块之下来验证交易的有效性。事实上，如果网络中的其他节点都接受了第300,000区块，并通过足够的工作在该块之上又生成了六个区块，根据代理网关协议，就可以证明该交易不是双重支付。
如果一个交易实际上不存在，SPV节点不会误认为该交易存在于某区块中。SPV节点会通过请求merkle路径证明以及验证区块链中的工作量证明，来证实交易的存在性。可是，一个交易的存在是可能对SPV节点“隐藏”的。SPV节点毫无疑问可以证实某个交易的存在性，但它不能验证某个交易（譬如同一个UTXO的双重支付）不存在，这是因为SPV节点没有一份关于所有交易的记录。这个漏洞会被针对SPV节点的拒绝服务攻击或双重支付型攻击所利用。为了防御这些攻击，SPV节点需要随机连接到多个节点，以增加与至少一个可靠节点相连接的概率。这种随机连接的需求意味着SPV节点也容易受到网络分区攻击或Sybil攻击。在后者情况中，SPV节点被连接到虚假节点或虚假网络中，没有通向可靠节点或真正的比特币网络的连接。
在绝大多数的实际情况中，具有良好连接的SPV节点是足够安全的，它在资源需求、实用性和安全性之间维持恰当的平衡。当然，如果要保证万无一失的安全性，最可靠的方法还是运行完整区块链的节点。

完整的区块链节点是通过检查整个链中在它之下的数千个区块来保证这个UTXO没有被支付，从而验证交易。而SPV节点是通过检查在其上面的区块将它压在下面的深度来验证交易。

SPV节点使用的是一条getheaders消息，而不是getblocks消息来获得区块头。发出响应的对等节点将用一条headers消息发送多达2000个区块头。这一过程和全节点获取所有区块的过程没什么区别。SPV节点还在与对等节点的连接上设置了过滤器，用以过滤从对等节点发来的未来区块和交易数据流。任何目标交易都是通过一条getdata的请求来读取的。对等节点生成一条包含交易信息的tx消息作为响应。区块头的同步过程如图6-7所示。

图6-7 SPV节点同步区块头

由于SPV节点需要读取特定交易从而选择性地验证交易，这样就又产生了隐私风险。与全区块链节点收集每一个区块内的全部交易所不同的是，SPV节点对特定数据的请求可能无意中透露了钱包里的地址信息。例如，监控网络的第三方可以跟踪某个SPV节点上的钱包所请求的全部交易信息，并且利用这些交易信息把比特币地址和钱包的用户关联起来，从而损害了用户的隐私。
在引入SPV节点/轻量级节点后不久，比特币开发人员就添加了一个新功能：Bloom过滤器，用以解决SPV节点的隐私风险问题。Bloom过滤器通过一个采用概率而不是固定模式的过滤机制，允许SPV节点只接收交易信息的子集，同时不会精确泄露哪些是它们感兴趣的地址。

6.8 Bloom过滤器

Bloom过滤器是一个允许用户描述特定的关键词组合而不必精确表述的基于概率的过滤方法。它能让用户在有效搜索关键词的同时保护他们的隐私。在SPV节点里，这一方法被用来向对等节点发送交易信息查询请求，同时交易地址不会被暴露。
用我们之前的例子，一位手中没有地图的游客需要询问去特定地方的路线。如果他向陌生人询问“教堂街23号在哪里”，不经意之间，他就暴露了自己的目的地。Bloom过滤器则会这样问，附近有带‘堂’字的街道吗？”这样的问法包含了比之前略少的关键词。这位游客可以自己选择包含信息的多少，比如“以‘堂街’结尾”或者“‘教’字开头的街道”。如果他问得越少，得到了更多可能的地址，隐私得到了保护，但这些地址里面不乏无关的结果；如果他问得非常具体，他在得到较准确的结果的同时也暴露了自己的隐私。
Bloom过滤器可以让SPV节点指定交易的搜索模式，该搜索模式可以基于准确性或私密性的考虑被调节。一个非常具体的Bloom过滤器会生成更准确的结果，但也会显示该用户钱包里的使用的地址；反之，如果过滤器只包含简单的关键词，更多相应的交易会被搜索出来，在包含若干无关交易的同时有着更高的私密性。
首先，SPV节点会初始化一个不会匹配任何关键词的“空白”Bloom过滤器。接下来，SPV节点会创建一个包含钱包中所有地址信息的列表，并创建一个与每个地址相对应的交易输出相匹配的搜索模式。通常，这种搜索模式是一个向公钥付款的哈希脚本、，该脚本是一个会出现在每一个向公钥哈希地址付款的交易中的锁定脚本。如果SPV节点需要追踪P2SH地址余额，搜索模式就会变成P2SH脚本。然后，SPV节点会把每一个搜索模式添加至Bloom过滤器里，这样只要关键词出现在交易中就能够被过滤器识别出来。最后，对等节点会用收到的Bloom过滤器来匹配传送至SPV节点的交易。
Bloom过滤器的实现是由一个可变长度（N）的二进制数组（N位二进制数构成一个位域）和数量可变（M）的一组哈希函数组成。。这些哈希函数的输出值始终在1和N之间，该数值与二进制数组相对应。并且该函数为确定性函数，也就是说任何一个使用相同Bloom过滤器的节点通过该函数都能对特定输入得到同一个的结果。Bloom过滤器的准确性和私密性能通过改变长度（N）和哈希函数的数量（M）来调节。
在图6-8中，我们用一个小型的十六位数组和三个哈希函数来演示Bloom过滤器的应用原理。

图6-8 一个由16位数组和三个哈希函数组成的简易Bloom过滤

Bloom过滤器数组里的每一个数的初始值为零。关键词被加到Bloom过滤器中之前，会依次通过每一个哈希函数运算一次。该输入经第一个哈希函数运算后得到了一个在1和N之间的数，它在该数组（编号依次为1至N）中所对应的位被置为1，从而把哈希函数的输出记录下来。接着再进行下一个哈希函数的运算，把另外一位置为1；以此类推。当全部M个哈希函数都运算过之后，一共有M个位的值从0变成了1，这个关键词也被“记录”在了Bloom过滤器里。
图6-9显示了向图6-8里的简易Bloom过滤器添加关键词“A”。

图6-9 向简易Bloom过滤器中增加关键词“A”

增加第二个关键是就是简单地重复之前的步骤。关键词依次通过各哈希函数运算之后，相应的位变为1，Bloom过滤器则记录下该关键词。需要注意的是，当Bloom过滤器里的关键词增加时，它对应的某个哈希函数的输出值的位可能已经是1了，这种情况下，该位不会再次改变。也就是说，随着更多的关键词指向了重复的位，Bloom过滤器随着位1的增加而饱和，准确性也因此降低了。该过滤器之所以是基于概率的数据结构，就是因为关键词的增加会导致准确性的降低。准确性取决于关键字的数量以及数组大小（N）和哈希函数的多少（M）。更大的数组和更多的哈希函数会记录更多的关键词以提高准确性。而小的数组及有限的哈希函数只能记录有限的关键词从而降低准确性。
图6-10显示了向该简易Bloom过滤器里增加第二个关键词“B”。

图6-10 向简易Bloom过滤器中增加第二个关键词“B”

为测试某一关键词是否被记录在某个Bloom过滤器中，我们将该关键词逐一代入各哈希函数中运算，并将所得的结果与原数组进行对比。如果所有的结果对应的位都变为了1，则表示这个关键词有可能已被该过滤器记录。之所以这一结论并不确定，是因为这些字节1也有可能是其他关键词运算的重叠结果。简单来说，Bloom过滤器正匹配代表着“可能是”。
图6-11是一个验证关键词“X”是否在前述Bloom过滤器中的图例。相应的比特位都被置为1，所以这个关键词很有可能是匹配的。

图6-11 验证关键词“X”是否存在于Bloom过滤器中。若结果为或然正匹配，则表示“可能是”。

另一方面，如果我们代入关键词计算后的结果某位为0，说明该关键词并没有被记录在过滤器里。负匹配的结果不是可能，而是一定。也就是说，负匹配代表着“一定不是”。
图6-12是一个验证关键词“Y”是否存在于简易Bloom过滤器中的图例。图中某个结果字段为0，该字段一定没有被匹配。

图6-12 验证关键词“Y”是否存在于Bloom过滤器中。若结果为必然负匹配，则表示“一定不是”。

BIP0037里已经对Bloom过滤器的实现有所描述。请参见附录2或访问GitHub。

6.9 Bloom过滤器和存货更新

Bloom过滤器被用来过滤SPV节点从对等节点里收到的交易信息。SPV会建立一个只能和SPV节点钱包里的地址匹配的过滤器。随后，SPV节点会向对等节点发送一条包含需在该连接中使用的过滤器的filterload消息。当过滤器建好之后，对等节点将每个交易的输出值代入过滤器中验证。那些正匹配的交易会被传送回SPV节点。
为回应来自SPV节点的getdata信息，对等节点会发出一条只含有和过滤器匹配的区块的区块头信息，以及与之相匹配的交易的merkle树。这一对等节点还会发出一条相匹配的交易的tx消息。
这个节点能够通过发送一条filteradd信息来向它的Bloom过滤器增加关键词，也能够发送filterclear信息来清除整个过滤器。因为不能直接从过滤器里删除关键词，所以如果某关键词不再需要，节点必须通过清除和增加来替换原有的过滤器。

6.10 交易池

比特币网络中几乎每个节点都会维护一份未确认交易的临时列表，被称为内存池或交易池。节点们利用这个池来追踪记录那些被网络所知晓、但还未被区块链所包含的交易。例如，保存用户钱包的节点会利用这个交易池来记录那些网络已经接收但还未被确认的、属于该用户钱包的预支付信息。
随着交易被接收和验证，它们被添加到交易池并通知到相邻节点处，从而传播到网络中。
有些节点的实现还维护一个单独的孤立交易池。如果一个交易的输入与某未知的交易有关，如与缺失的父交易相关，该孤立交易就会被暂时储存在孤立交易池中直到父交易的信息到达。
当一个交易被添加到交易池中，会同时检查孤立交易池，看是否有某个孤立交易引用了此交易的输出（子交易）。任何匹配的孤立交易会被进行验证。如果验证有效，它们会从孤立交易池中删除，并添加到交易池中，使以其父交易开始的链变得完整。对新加入交易池的交易来说，它不再是孤立交易。前述过程重复递归寻找进一步的后代，直至所有的后代都被找到。通过这一过程，一个父交易的到达把整条链中的孤立交易和它们的父级交易重新结合在一起，从而触发了整条独立交易链进行级联重构。
交易池和孤立交易池（如有实施）都是存储在本地内存中，并不是存储在永久性存储设备（如硬盘）里。更准确的说，它们是随网络传入的消息动态填充的。节点启动时，两个池都是空闲的；随着网络中新交易不断被接收，两个池逐渐被填充。
有些比特币客户端的实现还维护一个UTXO数据库，也称UTXO池，是区块链中所有未支付交易输出的集合。“UTXO池”的名字听上去与交易池相似，但它代表了不同的数据集。UTXO池不同于交易池和孤立交易池的地方在于，它在初始化时不为空，而是包含了数以百万计的未支付交易输出条目，有些条目的历史甚至可以追溯至2009年。UTXO池可能会被安置在本地内存，或者作为一个包含索引的数据库表安置在永久性存储设备中。
交易池和孤立交易池代表的是单个节点的本地视角。取决于节点的启动时间或重启时间，不同节点的两池内容可能有很大差别。相反地，UTXO池代表的是网络的突显共识，因此，不同节点间UTXO池的内容差别不大。此外，交易池和孤立交易池只包含未确认交易，而UTXO池之只包含已确认交易。

6.11 警告消息

警告消息并不经常使用，但在大多数节点上都有此功能。警告消息是比特币的“紧急广播系统”，比特币核心开发人员可以借此功能给所有比特币节点发送紧急文本消息。这一功能是为了让核心开发团队将比特币网络的严重问题通知所有的比特币用户，例如一个需要用户采取措施的的严重bug。警告系统迄今为止只被用过几次，最严重的一次是在2013年，一个关键的数据库缺陷导致比特币区块链中出现了一个多区块分叉。
警告消息是通过alert消息来传播的。警告消息包含几个字段，包括：
▷ ID
警告消息序号，用于检测重复警告
▷ Expiration
警告到期的时间点
▷ RelayUntil
在此时间点之后，警告不再被中继
▷ MinVer,MaxVer
此警告所适用的比特币协议版本范围
▷ subVer
此警告适用的客户端软件版本
▷ Priority
警告消息的优先级（暂未使用）
警告通过公钥进行加密签名。对应的私钥是由核心开发团队的一些特定成员所持有。这样的数字签名可以确保虚假警告不会在网络中传播。
收到警告消息的节点会验证该消息，检查是否过期，并传播给其所有对等节点，从而保证了整个网络中的快速传播。除了传播警告之外，节点也可能会实现一个向用户推送警告的用户级接口函数。
在比特币核心客户端，警告是与命令行选项alertnotify一起设置的，该选项指定了收到警告时需要执行的命令。警告消息作为参数被传递给alertnotify命令。最常见的应用是，alertnotify命令被设置为生成一个包含该警告消息的电子邮件并发送给节点管理员。警告也会以弹出对话框的形式显示在图形用户界面（如有运行）上（bitcoin-Qt）。
其他比特币协议的实现可能以不同的方式来处理警告。许多硬件嵌入式比特币挖矿系统由于没有用户界面，并没有实现警告消息功能。我们强烈建议运行这类挖矿系统的矿工订阅警告消息，既可以通过矿池运营方来订阅、也可以通过运行一个单独以警告为目的的轻量级节点来订阅。

==目录==

简介
前言
第1章 介绍
第2章 比特币的原理
第3章 比特币客户端
第4章 密钥、地址、钱包
第4章 高级密钥和地址
第5章 交易
第6章 比特币网络
第7章 区块链
第8章 挖矿与共识
第8章 区块链分叉、矿池、共识攻击
第9章 竞争币、竞争块链和应用程序
第10章 比特币安全
附录1 交易脚本的操作符、常量和符号
附录2 比特币改进协议
附录3 pycoin库、ku程序和tx交易程序
附录4 sx工具下一些的命令本文原链接：http://zhibimo.com/read/wang-miao/Mastering-Bitcoin/Chapter06.html

第5章 交易

5.1 简介

比特币交易是比特币系统中最重要的部分。根据比特币系统的设计原理，系统中任何其他的部分都是为了确保比特币交易可以被生成、能在比特币网络中得以传播和通过验证，并最终添加入全球比特币交易总账簿（比特币区块链）。比特币交易的本质是数据结构，这些数据结构中含有比特币交易参与者价值转移的相关信息。比特币区块链是全球复式记账总账簿，每个比特币交易都是在比特币区块链上的一个公开记录。
在这一章，我们将会剖析比特币交易的多种形式、所包含的信息、如何被创建、如何被验证以及如何成为所有比特币交易永久记录的一部分。

5.2 比特币交易的生命周期

一笔比特币交易的生命周期起始于它被创建的那一刻，也就是诞生（origination）。 随后，比特币交易会被一个或者多个签名加密，这些签名标志着对该交易指向的比特币资金的使用许可。接下来，比特币交易被广播到比特币网络中。在比特币网络中，每一个节点（比特币交易参与者）验证、并将交易在网络中进行广播，直到这笔交易被网络中大多数节点接收。最终，比特币交易被一个挖矿节点验证，并被添加到区块链上一个记录着许多比特币交易的区块中。
一笔比特币交易一旦被记录到区块链上并被足够多的后续区块确认，便成为比特币总账簿的一部分，并被所有比特币交易参与者认可为有效交易。于是，被这笔交易分配到一个新所有者名下的比特币资金可以在新的交易中被使用——这使得所有权链得以延伸且再次开启一个新的比特币交易生命周期。

5.2.1 创建比特币交易

将一笔比特币交易理解成纸质支票或许有助于加深我们对它的理解。与支票相似，一笔比特币交易其实是一个有着货币转移目的的工具，这个工具只有在交易被执行时才会在金融体系中体现，而且交易发起人并不一定是签署该笔交易的人。
比特币交易可以被任何人在线上或线下创建，即便创建这笔交易的人不是这个账户的授权签字人。比如，一个负责应付账款的柜员在处理应付票据时可能会需要CEO签名。相似地，这个负责应付账款的柜员可以创建比特币交易，然后让CEO对它进行数字签名，从而使之有效。一张支票是指定一个特定账户作为资金来源的，但是比特币交易指定以往的一笔交易作为其资金来源，而不是一个特定账户。
一旦一笔比特币交易被创建，它会被资金所有者（们）签名。如果它是合法创建并签名的，则该笔交易现在就是有效的，它包含了转移这笔资金所需要的所有信息。最终，有效的比特币交易必须能接入比特币网络，从而使之能被传送，直至抵达下一个登记在公共总账薄（区块链）的挖矿节点。

5.2.2 将比特币交易传送至比特币网络

首先，一笔交易需要传递至比特币网络，才能被传播，也才能加入区块链中。本质上，一笔比特币交易只是300到400字节的数据，而且它们必须被发送到成千上万个比特币节点中的任意一个。只要发送者能使用多于一个比特币节点来确保这笔交易被传播，那么发送者并不需要信任用来传播该笔交易的单一节点。相应地，这些节点不需要信任发送者，也不用建立发送者的“身份档案”。由于这笔交易是经过签名且不含任何机密信息、私钥或密码，因此它可被任何潜在的便利网络公开地传播。信用卡交易包含敏感信息，而且依赖加密网络连接完成信息传输，但比特币交易可在任意网络环境下被发送。只要这笔交易可以到达能将它广播到比特币网络的比特币节点，这笔交易是如何被传输至第一个节点的并不重要。
比特币交易因此可以通过未加密网络（例如WiFi、蓝牙、NFC、ChirP、条形码或者复制粘贴至一个网页表格）被发送到比特币网络。在一些极端情况下，一笔比特币交易可以通过封包无线电、卫星或短波、扩频或跳频以避免被侦测或阻塞通信的方式进行传输。一笔比特币交易甚至可被编为文字信息中的表情符号并被发表到在线论坛，或被发送成一条短信或一条Skype聊天信息。因为比特币将金钱变成了一种数据结构，所以在本质上是不可能阻止任何人创建并执行比特币交易的。

5.2.3 比特币交易在比特币网络中的传播

一旦一笔比特币交易被发送到任意一个连接至比特币网络的节点，这笔交易将会被该节点验证。如果交易被验证有效，该节点将会将这笔交易传播到这个节点所连接的其他节点；同时，交易发起者会收到一条表示交易成功的返回信息。如果这笔交易被验证为无效，这个节点会拒绝接受这笔交易且同时返回给交易发起者一条表示交易被拒绝的信息。
比特币网络是一个点对点网络，这意味着每一个比特币节点都连接到一些其他的比特币节点（这些其他的节点是在启动点对点协议时被发现的）。整个比特币网络形成了一个松散地连接、且没有固定拓扑或任何结构的“蛛网”——这使得所有节点的地位都是同等的。比特币交易相关信息（包括交易和区块）被传播——从每一个节点到它连接的其他节点。一笔刚通过验证且并被传递到比特币网络中任意节点的交易会被发送到三到四个相邻节点，而每一个相邻节点又会将交易发送到三至四个与它们相邻的节点。以此类推，在几秒钟之内，一笔有效的交易就会像指数级扩散的波一样在网络中传播，直到所有连接到网络的节点都接收到它。
比特币网络被设计为能高效且灵活地传递交易和区块至所有节点的模式，因而比特币网络能抵御入侵。为了避免垃圾信息的滥发、拒绝服务攻击或其他针对比特币系统的恶意攻击，每一个节点在传播每一笔交易之前均进行独立验证。 一个异常交易所能到达的节点不会超过一个。”8.3 交易的独立校验“一节将详细介绍决定比特币交易是否有效的原则。

5.3 交易结构

一笔比特币交易是一个含有输入值和输出值的数据结构，该数据结构植入了将一笔资金从初始点（输入值）转移至目标地址（输出值）的代码信息。比特币交易的输入值和输出值与账号或者身份信息无关。你应该将它们理解成一种被特定秘密信息锁定的一定数量的比特币。只有拥有者或知晓这个秘密信息的人可以解锁。一笔比特币交易包含一些字段，如表5-1所示。
表5-1 交易结构

交易的锁定时间

锁定时间定义了能被加到区块链里的最早的交易时间。在大多数交易里，它被设置成0，用来表示立即执行。如果锁定时间不是0并且小于5亿，就被视为区块高度，意指在这个指定的区块高度之前的交易没有被包含在这个区块链里。如果锁定时间大于5亿，则它被当作是一个Unix纪元时间戳（从1970年1月1日以来的秒数），并且在这个指定时点之前的交易没有被包含在这个区块链里。锁定时间的使用相当于将一张纸质支票的生效时间予以后延。

5.4 交易的输出和输入

比特币交易的基本单位是未经使用的一个交易输出，简称UTXO。UTXO是不能再分割、被所有者锁住或记录于区块链中的并被整个网络识别成货币单位的一定量的比特币货币。比特币网络监测着以百万为单位的所有可用的（未花费的）UTXO。当一个用户接收比特币时，金额被当作UTXO记录到区块链里。这样，一个用户的比特币会被当作UTXO分散到数百个交易和数百个区块中。实际上，并不存在储存比特币地址或账户余额的地点，只有被所有者锁住的、分散的UTXO。“一个用户的比特币余额”，这个概念是一个通过比特币钱包应用创建的派生之物。比特币钱包通过扫描区块链并聚合所有属于该用户的UTXO来计算该用户的余额。

在比特币的世界里既没有账户，也没有余额，只有分散到区块链里的UTXO。

一个UTXO可以是一“聪”的任意倍。就像美元可以被分割成表示两位小数的“分”一样，比特币可以被分割成表示八位小数的“聪”。尽管UTXO可以是任意值，但只要它被创造出来了，就像不能被切成两半的硬币一样不可再分了。如果一个UTXO比一笔交易所需量大，它仍会被当作一个整体而消耗掉，但同时会在交易中生成零头。例如，你有20比特币的UTXO并且想支付1比特币，那么你的交易必须消耗掉整个20比特币的UTXO并且产生两个输出：一个是支付了1比特币给接收人，另一个是支付19比特币的找零到你的钱包。这样的话，大部分比特币交易都会产生找零。
想象一下，一位顾客要买1.5元的饮料。她掏出她的钱包并努力从所有硬币和钞票中找出一种组合来凑齐她要支付的1.5元。如果可能的话，她会选刚刚好的零钱（比如一张1元纸币和5个一毛硬币）或者是小面额的组合（比如3个五毛硬币）。如果都不行的话，她会用一张大面额的钞票，比如5元纸币。如果她把过多的钱，比如5元，给了商店老板，她会拿到3.5元的找零，并把找零放回她的钱包以供未来使用。
类似的，一笔比特币交易可以有任意数值，但必须从用户可用的UTXO中创建出来。用户不能再把UTXO进一步细分，就像不能把一元纸币撕开而继续当货币使用一样。用户的钱包应用通常会从用户可用的UTXO中选取多个可用的个体来拼凑出一个大于或等于一笔交易所需的比特币量。
就像现实生活中一样，比特币应用可以使用一些策略来满足付款需要：组合若干小的个体，算出准确的找零；或者使用一个比交易值大的个体然后进行找零。所有这些复杂的、由可支付的UTXO完成的组合，都是由用户的钱包自动完成，并不为用户所见。只有当你以编程方式用UTXO来构建原始交易时，这些才与你有关。
被交易消耗的UTXO被称为交易输入，由交易创建的UTXO被称为交易输出。通过这种方式，一定量的比特币价值在不同所有者之间转移，并在交易链中消耗和创建UTXO。一笔比特币交易通过使用所有者的签名来解锁UTXO，并通过使用新的所有者的比特币地址来锁定并创建UTXO。
对于输出和输入链来说，有一个例外，它是一种特殊的交易类型，称为coinbase交易。这是每个区块中的首个交易。这种交易存在的原因是作为对挖矿的奖励而产生全新的可用于支付的比特币给“赢家”矿工。这也就是为什么比特币可以在挖矿过程中被创造出来，我们将在第8章中进行详述。

输入和输出，哪一个是先产生的呢？先有鸡还是先有蛋呢？严格来讲，先产生输出，因为可以创造新比特币的coinbase交易没有输入，但它可以无中生有地产生输出。

5.4.1 交易输出

每一笔比特币交易创造输出，输出都会被比特币账簿记录下来。除特例之外（见“5.7.4 数据输出（OP_RETURN操作符）”），几乎所有的输出都能创造一定数量的可用于支付的比特币，也就是UTXO。这些UTXO被整个网络识别，并且所有者可在未来的交易中使用它们。给某人发送比特币实际上是创造新的UTXO，注册到那个人的地址，并且能被他用于新的支付。
UTXO被每一个全节点比特币客户端在一个储存于内存中的数据库所追踪，该数据库也被称为“UTXO集”或者“UTXO池”。新的交易从UTXO集中消耗（支付）一个或多个输出。
交易输出包含两部分：
▷ 一定量的比特币，被命名为“聪”，是最小的比特币单位；
一个锁定脚本，也被当作是“障碍”，提出支付输出所必须被满足的条件以“锁住”这笔总额。
在前面的锁定脚本中提到的这个交易脚本语言会在后面121页的“交易脚本和脚本语言”一节中详细讨论。表5-2列出了交易输出的结构。
表5-2 交易输出结构

在例5-1中，我们使用blockchain.info应用程序接口来查找特定地址的UTXO。
例5-1 一个调用blockchain.info应用程序接口来查找与一个地址有关的UTXO的脚本

# 从blockchain API中得到未花费的输出import jsonimport requests# 样例地址address = '1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX'# API网址是：https://blockchain.info/unspent?active=

运行脚本，我们将会得到“交易ID，冒号，特定UTXO的索引号，以及这个UTXO包含的聪的数额”的列表。在例5-2中，锁定脚本被省略了。
例5-2 运行 get-utxo.py脚本

$ python get-utxo.pyebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167:1 - 8000000 Satoshis6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf:0 - 16050000 Satoshis74d788804e2aae10891d72753d1520da1206e6f4f20481cc1555b7f2cb44aca0:0 - 5000000 Satoshisb2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4:0 - 10000000 Satoshis...

支付条件（障碍）

交易输出把用聪表示的一定数量的比特币，和特定的定义了支付输出所必须被满足的条件的障碍，或者叫锁定脚本，关联到了一起。在大多数情况下，锁定脚本会把输出锁在一个特定的比特币地址上，从而把一定数量的比特币的所有权转移到新的所有者上。当Alice在Bob的咖啡店为一杯咖啡付款时，Alice的交易创造了0.015比特币的输出，在咖啡店的比特币地址上成为一种障碍，或者说是被锁在了咖啡店的比特币地址上。那0.015比特币输出被记录到区块链中，并且成为UTXO的一部分，也就是作为可用余额出现在Bob的钱包里。当Bob选择使用这笔款项进行支付时，他的交易会释放障碍，通过提供一个包含Bob私钥的解锁脚本来解锁输出。

5.4.2 交易输入

简单地说，交易输入是指向UTXO的指针。它们指向特定的UTXO，并被交易哈希和在区块链中记录UTXO的序列号作为参考。若想支付UTXO，一个交易的输入也需要包含一个解锁脚本，用来满足UTXO的支付条件。解锁脚本通常是一个签名，用来证明对于在锁定脚本中的比特币地址拥有所有权。
当用户付款时，他的钱包通过选择可用的UTXO来构造一笔交易。比如说，要支付0.015比特币，钱包应用会选择一个0.01 UTXO和一个0.005 UTXO，使用它们加在一起来得到想要的付款额。
在例5-3中，我们展示了一种贪心算法来为了得到特定的付款额而选择可用的UTXO。在例中，可用的UTXO被提供在一个常数数组中。但在实际中，可用的UTXO被一个远程过程调用比特币核心，或者被一个如例5-1中的第三方应用程序接口，来检索出来。
例5-3 一个计算会被发送的比特币总量的脚本

# 使用贪心算法从UTXO列表中选择输出。from sys import argv class OutputInfo:     def __init__(self, tx_hash, tx_index, value):         self.tx_hash = tx_hash        self.tx_index = tx_index        self.value = value     def __repr__(self):        return "<%s:%s with %s Satoshis>" % (self.tx_hash, self.tx_index,                                             self.value) # 为了发送，从未花费的输出列表中选出最优输出。# 返回输出列表，并且把其他的改动发送到改变地址。def select_outputs_greedy(unspent, min_value):     # 如果是空的话认为是失败了。    if not unspent: return None     # 分割成两个列表。    lessers = [utxo for utxo in unspent if utxo.value < min_value]     greaters = [utxo for utxo in unspent if utxo.value >= min_value]     key_func = lambda utxo: utxo.value    if greaters:         # 非空。寻找最小的greater。        min_greater = min(greaters)        change = min_greater.value - min_value         return [min_greater], change     # 没有找到greaters。重新尝试若干更小的。    # 从大到小排序。我们需要尽可能地使用最小的输入量。    lessers.sort(key=key_func, reverse=True)    result = []    accum = 0    for utxo in lessers:         result.append(utxo)        accum += utxo.value        if accum >= min_value:             change = accum - min_value            return result, "Change: %d Satoshis" % change     # 没有找到。    return None, 0 def main():     unspent = [         OutputInfo("ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167", 1,  8000000),        OutputInfo("6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf", 0, 16050000),        OutputInfo("b2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4", 0,  10000000),        OutputInfo("7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1", 0, 25000000),        OutputInfo("55ea01bd7e9afd3d3ab9790199e777d62a0709cf0725e80a7350fdb22d7b8ec6", 17, 5470541),        OutputInfo("12b6a7934c1df821945ee9ee3b3326d07ca7a65fd6416ea44ce8c3db0c078c64", 0, 10000000),        OutputInfo("7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818", 0, 16100000),    ]     if len(argv) > 1:        target = long(argv[1])     else:        target = 55000000     print "For transaction amount %d Satoshis (%f bitcoin) use: " % (target, target/ 10.0**8)     print select_outputs_greedy(unspent, target) if __name__ == "__main__":     main()

如果我们不使用参数运行select-utxo.py脚本，它会试图为一笔五千五百万聪（0.55比特币）的付款构造一组UTXO。如果你提供一个指定的付款额作为参数，脚本会选择UTXO来完成指定的付款额。在例5-4中，我们运行脚本来试着完成一笔0.5比特币，或者说是五千万聪的付款。
例5-4 运行select-utxo.py

$ python select-utxo.py 50000000For transaction amount 50000000 Satoshis (0.500000 bitcoin) use:([<7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1:0 with 25000000Satoshis>, <7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818:0 with 16100000 Satoshis>,<6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf:0 with 16050000 Satoshis>], 'Change: 7150000 Satoshis')

一旦UTXO被选中，钱包会为每个UTXO生成包含签名的解锁脚本，由此让它们变得可以通过满足锁定脚本的条件来被支付。钱包把这些UTXO作为参考，并且连同解锁脚本一起作为输入加到交易中。表5-3展示了交易输入的结构。
表5-3 交易输入的结构

序列号是用来覆盖在交易锁定时间之前失效的交易，这是一项目前没有在比特币中用到的功能。大多数交易把这个值设置成最大的整数（0xFFFFFFFF）并且被比特币网络忽略。如果一次交易有非零的锁定时间，那么它至少需要有一个序列号比0xFFFFFFFF低的输入来激活锁定时间。

5.4.3 交易费

大多数交易包含交易费，这是为了在网络安全方面给比特币矿工一种补偿。在第8章中，对于挖矿、费用和矿工得到的奖励，有更详细的讨论。这一节解释交易费是如何被包含在日常交易中的。大多数钱包自动计算并计入交易费。但是，如果你编程构造交易，或者使用命令行接口，你必须手动计算并计入这些费用。
交易费可当作是为了包含（挖矿）一笔交易到下一个区块中的一种鼓励，也可当作是对于欺诈交易和任何种类的系统滥用，在每一笔交易上通过征收一笔小成本的税而造成的一种妨碍。交易费被挖出这个区块的矿工得到，并且记录在这个交易的区块链中。
交易费基于交易的尺寸，用千字节来计算，而不是比特币的价值。总的来说，交易费基于市场所设置，生效于比特币网络中。矿工依据许多不同的标准，按重要性对交易进行排序，这包括费用，并且甚至可能在某种特定情况下免费处理交易。交易费影响处理优先级，这意味着有足够费用的交易会更可能地被包含在下一个挖出的区块中；与此同时，交易费不足或者没有交易费的交易可能会被推迟，基于尽力而为的原则在几个区块之后被处理，甚至可能根本不被处理。交易费不是强制的，而且没有交易费的交易也许最终会被处理，但是，包含交易费将提高处理优先级。
随着时间的过去，交易费的计算方式和交易费在交易优先级上的影响一直在发展。起初，交易费是网络中的一个固定常数。渐渐地，交易费的结构被放宽了，以便被市场基于网络容量和交易量而强制影响。目前最小交易费被固定在每千字节0.0001比特币，或者说是每千字节万分之一比特币，最近一次改变是从千分之一比特币减少到这个数值的。大多数交易少于一千字节，但是那些包含多个输入和输出的交易尺寸可能更大。在未来的比特币协议修订版中，钱包应用预计会使用统计学分析，基于最近的几笔交易的平均费用，来计算最恰当的费用并附在交易上。
目前矿工使用的，对包含在一个区块中的交易，基于它们的费用划分优先顺序的算法，在第8章有详细解释。

5.4.4 把交易费加到交易中

交易的数据结构没有交易费的字段。相反地，交易费通过所有输入的总和，以及所有输出的总和之间的差来表示。从所有输入中扣掉所有输出之后的多余的量会被矿工收集走。
交易费被作为输入减输出的余量：
交易费 = 求和（所有输入） - 求和（所有输出）
对于交易来说，这是一个很让人摸不着头脑的元素，但又是很重要的问题。因为如果你要构造你自己的交易，你必须确认你没有疏忽地包含了一笔少于输入的、量非常大的费用。这意味着你必须计算所有的输入，如果必要的话进行找零，不然的话，结果就是你给了矿工一笔可观的劳动费！
举例来说，如果你消耗了一个20比特币的UTXO来完成1比特币的付款，你必须包含一笔19比特币的找零回到你的钱包。否则，那剩下的19比特币会被当作交易费，并且会被挖出你的交易到一个区块中的矿工收走。尽管你会受到高优先级的处理，并且让一个矿工喜出望外，但这很可能不是你想要的。

如果你忘记了在手动构造的交易中增加找零的输出，系统会把找零当作交易费来处理。“不用找了！”也许不是你想要的结果。

让我们来看看在实际中它如何工作，重温一下Alice在咖啡店的交易。Alice想为咖啡支付0.015比特币。为了确保这笔交易能立即被处理，Alice想支付一笔交易费，比如说0.001。这意味着总交易成本会变成0.016。因此她的钱包需要凑齐0.016或更多的UTXO。如果需要，还要加上找零。我们假设他的钱包有一个0.2比特币的UTXO可用。他的钱包就会消耗掉这个UTXO，创造一个新的0.015的输出给Bob的咖啡店，另一个0.184比特币的输出作为找零回到Alice拥有的钱包，并留下未分配的0.001比特币内含在交易中。
现在让我们换个例子。Eugenia，我们在菲律宾的儿童募捐项目主管，完成了一次为孩子购买教材的筹款活动。她在世界范围内接收到了好几千个小数额的捐款，总额是50比特币。所以她的钱包塞满了非常小的UTXO。现在她想用比特币从本地的一家出版商购买几百本的教材。
现在Eugenia的钱包应用想要构造一个单笔大额付款交易，它必须从可用的、由很多小数额构成的大的UTXO集合中寻求钱币来源。这意味着交易的结果是从上百个小数额的UTXO中作为输入，但只有一个输出用来付给出版商。输入数量这么巨大的交易会比一千字节要大，也许总尺寸会达到两至三千字节。结果是它需要更高的交易费来满足0.0001比特币的网络费。
Eugenia的钱包应用会通过测量交易的大小，乘以每千字节需要的交易费，来计算适当的交易费。很多钱包会通过多付交易费的方式来确保大交易被立即处理。高交易费不仅是因为Eugenia付的钱很多，还因为她的交易很复杂并且尺寸很大——交易费是与参加交易的比特币值无关的。

5.5 交易链条和孤立交易

正如我们之前所看到的那样，交易形成一条链，这条链的形式是一笔交易消耗了先前的交易（父交易）的输出，并为随后的交易（子交易）创造了输出。有的时候组成整个链条的所有交易依赖于他们自己——比如父交易、子交易和孙交易——而他们又被同时创造出来，来满足复杂交易的工作流程。这需要在一个交易的父交易被签名之前，有一个合法的子交易被签名。举个例子，这是CoinJoin交易使用的一项技术，这项技术可以让多方同时加入交易，从而保护他们的隐私。
当一条交易链被整个网络传送时，他们并不能总是按照相同的顺序到达目的地。有时，子交易在父交易之前到达。在这种情况下，节点会首先收到一个子交易，而不能找到他参考的父交易。节点不会立即抛弃这个子交易，而是放到一个临时池中，并等着接收它的父交易，与此同时广播这个子交易给其他节点。没有父交易的交易池被称作孤立交易池。一旦接收到了父交易，所有与这个父交易创建的UTXO有关的孤块会从池中释放出来，递归地重新验证，然后整条交易链就会被交易池包括进去，并等待着被区块所挖走。交易链可以是任意长度并且可以被任意数量的批次同时传走。在孤立池中保留孤块的机制保证了其他合法的交易不会只是因为父交易被耽误了而被抛弃，并且无论接收顺序，最终整个链会以正确的顺序重新构造出来。
内存中储存的孤立交易数量是有限制的，这是为了防止针对比特币节点的拒绝服务攻击（DoS）。这个限制被定义在比特币涉及到的客户端的源代码中的MAX_ORPHAN_TRANSACTIONS。如果池中的孤立交易数量达到了MAX_ORPHAN_TRANSACTIONS，一个或多个的、被随机选出的孤立交易会被池抛弃，直到池的大小回到限制以内。

5.6 比特币交易脚本和脚本语言

比特币客户端通过执行一个用类Forth脚本语言编写的脚本验证比特币交易。锁定脚本被写入UTXO，同时它往往包含一个用同种脚本语言编写的签名。当一笔比特币交易被验证时，每一个输入值中的解锁脚本被与其对应的锁定脚本同时（互不干扰地）执行，从而查看这笔交易是否满足使用条件。
如今，大多数经比特币网络处理的交易是以“Alice付给Bob”的形式存在的。同时，它们是以一种称为“P2PKH”（Pay-to-Public-Key-Hash）脚本为基础的。然而，通过使用脚本来锁定输出和解锁输入意味着通过使用编程语言，比特币交易可以包含无限数量的条件。当然，比特币交易并不限于“Alice付给Bob” 的形式和模式。
这只是这个脚本语言可以表达的可能性的冰山一角。在这一节，我们将会全面展示比特币交易脚本语言的各个组成部分；同时，我们也会演示如何使用它去表达复杂的使用条件以及解锁脚本如何去满足这些花费条件。

比特币交易验证并不基于一个不变的模式，而是通过运行脚本语言来实现。这种语言可以表达出多到数不尽的条件变种。这也是比特币作为一种“可编程的货币”所拥有的权力。

5.6.1 脚本创建（锁定与解锁）

比特币的交易验证引擎依赖于两类脚本来验证比特币交易：一个锁定脚本和一个解锁脚本。
锁定脚本是一个放在一个输出值上的“障碍”，同时它明确了今后花费这笔输出的条件。由于锁定脚本往往含有一个公钥（即比特币地址），在历史上它曾被称作一个脚本公钥代码。由于认识到这种脚本技术存在着更为宽泛的可能性，在本书中，我们将它称为一个“锁定脚本”。在大多数比特币应用源代码中，脚本公钥代码便是我们所说的锁定脚本。
解锁脚本是一个“解决”或满足被锁定脚本在一个输出上设定的花费条件的脚本，同时它将允许输出被消费。解锁脚本是每一笔比特币交易输出的一部分，而且往往含有一个被用户的比特币钱包（通过用户的私钥）生成的数字签名。由于解锁脚本常常包含一个数字签名，因此它曾被称作ScriptSig。在大多数比特币应用的源代码中，ScriptSig便是我们所说的解锁脚本。考虑到更宽泛的锁定脚本要求，在本书中，我们将它称为“解锁脚本”。但并非所有解锁脚本都一定会包含签名。
每一个比特币客户端会通过同时执行锁定和解锁脚本来验证一笔交易。对于比特币交易中的每一个输入，验证软件会先检索输入所指向的UTXO。这个UTXO包含一个定义了花费条件的锁定脚本。接下来，验证软件会读取试图花费这个UTXO的输入中所包含的解锁脚本，并执行这两个脚本。
在先前的比特币客户端中，解锁和锁定脚本是以连锁的形式存在的，并且是被依次执行的。出于安全因素考虑，在2010年比特币开发者们修改了这个特性——因为存在“允许异常解锁脚本推送数据入栈并且污染锁定脚本”的漏洞。在当今的比特币世界中，这两个脚本是随着堆栈的传递被分别执行的，后续将会详细介绍。
首先，使用堆栈执行引擎执行解锁脚本。如果解锁脚本在执行过程中未报错（没有悬空操作符），主堆栈（非其它堆栈）将被复制，然后脚本将被执行。如果采用从解锁脚本处复制而来的数据执行锁定脚本的结果为真，那么解锁脚本就成功地满足了锁定脚本所设置的条件，因而，该输入是一个能使用该UTXO的有效授权。如果在执行完组合脚本后的结果不是真，那么输入就不是有效的，因为它并未能满足UTXO中所设置的使用该笔资金的条件。注意，UTXO是永久性地记录在区块链中的，因此它不会因一笔新交易所发起的无效尝试而变化或受影响。只有一笔有效的能准确满足UTXO条件的交易才会导致UTXO被标记为“已使用”，然后从有效的（未使用）UTXO集中所移除。
图5-1是最为常见类型的比特币交易（向公钥哈希进行一笔支付）的解锁和锁定脚本样本，该样本展示了在脚本验证之前将解锁脚本和锁定脚本串联而成的组合脚本。

图5-1

5.6.2 脚本语言

比特币交易脚本语言，也成为脚本，是一种基于逆波兰表示法的基于堆栈的执行语言。如果这让您听起来似乎在胡言乱语，很有可能是您没学习过1960年的编程语言的缘故。脚本是一种非常简单的语言，这种语言被设计为能在有限的硬件上执行，这些硬件类似简单的嵌入式设备，如手持计算器。它仅需最少的处理即可，而且不能做许多现代编程语言可以做的事情。当涉及可编程的钱时，这是它的一个基于深思熟虑的安全特性。
比特币脚本语言被称为基于堆栈语言，因为它使用的数据结构被称为堆栈。堆栈是一个非常简单的数据结构，它可以被理解成为一堆卡片。一个堆栈允许两类操作：推送和弹出。推送是在堆栈顶部增加一个项目，弹出则是从堆栈顶部移除一个项目。
脚本语言通过从左至右地处理每个项目的方式执行脚本。数字（常数）被推送至堆栈，操作符向堆栈推送（或移除）一个或多个参数，对它们进行处理，甚至可能会向堆栈推送一个结果。例如，OP_ADD将从堆栈移除两个项目，将二者相加，然后再将二者相加之和推送到堆栈。
条件操作符评估一项条件，产生一个真或假的结果。例如，OP_EQUAL从堆栈移除两个项目，假如二者相等则推送真（表示为1），假如二者不等则推送为假（表示为0）。比特币交易脚本常含条件操作符，当一笔交易有效时，就会产生真的结果。

图5-2

在图5-2中，脚本“2 3 OP_ADD 5 OP_EQUAL”演示了算术加法操作符OP_ADD，该操作符将两个数字相加，然后把结果推送到堆栈，OP_EQUAL是验算之前的两数之和是否等于5。为了简化起见，前缀OP_在一步步的演示示例过程中将被省略。
以下是一个稍微有些复杂的脚本，它用于计算2+7-3+1。注意，当脚本包含多个操作符时，堆栈允许一个操作符的结果作用于下一个操作符。
2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL
请试着用纸笔自行演算脚本，当脚本执行完毕时，你会在堆栈得到正确的结果。
虽然大多数的解锁脚本都指向一个比特币地址或公钥，因而如果想要使用资金则需验证所有权，但脚本本身并不需要如此的复杂。任何解锁和锁定脚本的组合如果结果为真，则为有效。前面被我们用于说明脚本语言的简单算术运算同样也是一个有效的锁定脚本，该脚本能用于锁定交易输出。
使用部分算数运算示例脚本作用锁定脚本：
3 OP_ADD 5 OP_EQUAL
该脚本能被以解锁脚本为输入的一笔交易所满足，解锁脚本为：
2
验证软件将锁定和解锁脚本组合起来：
2 3 OP_ADD 5 OP_EQUAL
正如在图5-2中所看到的，当脚本被执行时，结果是OP_TRUE，从而使得交易有效。不仅该笔交易的输出锁定脚本有效，同时UTXO也能被任何知晓这个运算技巧（知道是数字2）的人所使用。

如果堆栈顶部的结果显示为真（标记为{0×01}），即为任何非零值或脚本执行后堆栈为空情形，则交易有效。如果堆栈顶部的结果显示为假（0字节空值，标记为{}）或脚本执行被操作符禁止，如OP_VERIFY、OP_RETURN，或有条件终止如OP_ENDIF，则交易无效。详见附录1。

5.6.3 图灵非完备性

比特币脚本语言包含许多操作，但都故意限定为一种重要的方式——没有循环或者复杂流控制功能以外的其他条件的流控制。这样就保证了脚本语言的图灵非完备性，这意味着脚本的复杂性有限，交易可执行的次数也可预见。脚本并不是一种通用语言，施加的这些限制确保该语言不被用于创造无限循环或其它类型的逻辑炸弹，这样的炸弹可以植入在一笔交易中，通过引起拒绝服务的方式攻击比特币网络。受限制的语言能防止交易激活机制被人当作薄弱环节而加以利用。

5.6.4 非主权验证

比特币交易脚本语言是无国家主权的，没有国家能凌驾于脚本之上，也没有国家会在脚本被执行后对其进行保存。所以需要执行脚本的所有信息都已包含在脚本中。可以预见的是，一个脚本能在任何系统上以相同的方式执行。如果您的系统对一个脚本进行验证，可以确信的是每一个比特币网络中的其他系统也将对其进行验证，这意味着一个有效的交易对每个人而言都是有效的，而且每一个人都明白这一点。这种对于结果的可预见性是比特币系统的一项重要良性特征。

5.7 标准交易

在比特币最初几年的发展过程中，开发者对可以经由客户端进行操作的脚本类型设置了一些限制。这些限制被编译为一个Standard（）函数，该函数定义了五种类型的标准交易。这些限制都是临时性的，当您阅读本书时或许已经更新。截至目前，五种标准交易脚本是仅有的被客户端和大多数运行客户端的矿工们所接受的脚本。虽然创设一个非标准交易（脚本类型非标准化）是有可能的，但前提是必须能找到一个不遵循标准而且能将该非标准交易纳入区块的矿工。
通过检索比特币核心客户端源代码，可以看到当前有哪些交易脚本是被认可的。
五大标准脚本分别为P2PKH、P2PK、MS（限15个密钥）、P2SH和OP_Return，后文将详细介绍这五大脚本。

5.7.1 P2PKH（Pay-to-Public-Key-Hash）

比特币网络上的大多数交易都是P2PKH交易，此类交易都含有一个锁定脚本，该脚本由公钥哈希实现阻止输出功能，公钥哈希即为广为人知的比特币地址。由P2PKH脚本锁定的输出可以通过键入公钥和由相应私钥创设的数字签名得以解锁。
例如，我们可以再次回顾一下Alice向Bob咖啡馆支付的案例。Alice下达了向Bob咖啡馆的比特币地址支付0.015比特币的支付指令，该笔交易的输出内容为以下形式的锁定脚本：
OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG
脚本中的Cafe Public Key Hash即为咖啡馆的比特币地址，但这个地址不是基于Base58Check编码的。事实上，大多数比特币地址都显示为十六进制码，而不是大家所熟知的以1开头的基于Bsase58Check编码的比特币地址。
锁定脚本的解锁版脚本是：

将两个脚本结合起来可以形成如下有效组合脚本：

  OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG

只有当解锁版脚本与锁定版脚本的设定条件相匹配时，执行组合有效脚本时才会显示结果为真（Ture）。即只有当解锁脚本得到了咖啡馆的有效签名，交易执行结果才会被通过（结果为真），该有效签名是从与公钥哈希相匹配的咖啡馆的私钥中所获取的。
图5-3和图5-4（分两部分）显示了组合脚本一步步检验交易有效性的过程。

图5-3

图5-4

5.7.2 P2PK（Pay-to-Public-Key）

与P2PKH相比，P2PK模式更为简单。与P2PKH模式含有公钥哈希的模式不同，在P2PK脚本模式中，公钥本身已经存储在锁定脚本中，而且代码长度也更短。P2PKH是由Satoshi创建的，主要目的一方面为使比特币地址更简短，另一方面也使之更方便使用。P2PK目前在Coinbase交易中最为常见，Coinbase交易由老的采矿软件产生，目前还没更新至P2PKH。
P2PK锁定版脚本形式如下：
OP_CHECKSIG
用于解锁的脚本是一个简单签名：

经由交易验证软件确认的组合脚本为：
OP_CHECKSIG
该脚本只是CHECKSIG操作符的简单调用，该操作主要是为了验证签名是否正确，如果正确，则返回为真（Ture）。

5.7.3 多重签名

多重签名脚本设置了这样一个条件，假如记录在脚本中的公钥个数为N，则至少需提供其中的M个公钥才可以解锁。这也被称为M-N组合，其中，N是记录在脚本中的公钥总个数，M是使得多重签名生效的公钥数阀值（最少数目）。例如，对于一个2-3多重签名组合而言，存档公钥数为3个，至少同时使用其中2个或者2个以上的公钥时，才能生成激活交易的签名，通过验证后才可使用这笔资金。最初，标准多重签名脚本的最大存档公钥数被限定为15个，这意味着可采用1-1乃至15-15的任意多重签名组合，或者组合的组合来激活交易。15个存档公钥数的限制也许在本书出版时已有所增加，读者通过检索Standard（）函数可以获得最新存档公钥数上限值的相关信息。
通用的M-N多重签名锁定脚本形式为：
M ... N OP_CHECKMULTISIG
其中，N是存档公钥总数，M是要求激活交易的最少公钥数。
2-3多重签名条件：
2 3 OP_CHECKMULTISIG
上述锁定脚本可由含有签名和公钥的脚本予以解锁：
OP_0
或者由3个存档公钥中的任意2个相一致的私钥签名组合予以解锁。

之所以要加上前缀OP_0，是因为最早的CHECKMULTISIG在处理含有多个项目的过程中有个小漏洞，CHECKMULTISIG会自动忽略这个前缀，它只是占位符而已。

两个脚本组合将形成一个验证脚本：
OP_0 2 3 OP_CHECKMULTISIG
当执行时，只有当未解锁版脚本与解锁脚本设置条件相匹配时，组合脚本才显示得到结果为真（Ture）。上述例子中相应的设置条件即为未解锁脚本是否含有与3个公钥中的任意2个相一致的私钥的有效签名。

5.7.4 数据输出（OP_RETURN操作符）

比特币的分发和时间戳账户机制（也即区块链），其潜在运用将大大超越支付领域。许多开发者试图充分发挥交易脚本语言的安全性和可恢复性优势，将其运用于电子公证服务、证券认证和智能协议等领域。比特币脚本语言的早期运用主要包括在区块链上创造出交易输出。例如，为文件记录电子指纹，则任何人都可以通过该机制在特定的日期建立关于文档存在性的证明。
运用比特币区块链存储与比特币支付不相关数据的做法是一个有争议的话题。许多开发者认为其有滥用的嫌疑，因而试图予以阻止。另一些开发者则将之视为区块链技术强大功能的有力证明，从而试图给予大力支持。那些反对非支付相关应用的开发者认为这样做将引致“区块链膨胀”，因为所有的区块链节点都将以消耗磁盘存储空间为成本，负担存储此类数据的任务。更为严重的是，此类交易仅将比特币地址当作自由组合的20个字节而使用，进而会产生不能用于交易的UTXO。因为比特币地址只是被当作数据使用，并不与私钥相匹配，所以会导致UTXO不能被用于交易，因而是一种伪支付行为。这样的做法将使得内存中的UTXO不断增加，而且这些不能被用于交易的数据同样也不能被移除，因此比特币节点将永久性地担负这些数据，这无疑是代价高昂的。
在0.9版的比特币核心客户端上，通过采用OP_Return操作符最终实现了妥协。OP_Return允许开发者在交易输出上增加40字节的非交易数据。然后，与伪交易型的UTXO不同，OP_Return创造了一种明确的可复查的非交易型输出，此类数据无需存储于UTXO集。OP_Return输出被记录在区块链上，它们会消耗磁盘空间，也会导致区块链规模的增加，但它们不存储在UTXO集中，因此也不会使得UTXO内存膨胀，更不会以消耗代价高昂的内存为代价使全节点都不堪重负。
OP_RETURN脚本的样式：
OP_RETURN
“data”部分被限制为40字节，且多以哈希方式呈现，如32字节的SHA256算法输出。许多应用都在其前面加上前缀以辅助认定。例如，电子公正服务的证明材料采用8个字节的前缀“DOCPROOF”，在十六进制算法中，相应的ASCII码为44f4350524f4f46。
请记住OP_RETURN不涉及可用于支付的解锁脚本的特点，OP_RETURN不能使用其输出中所锁定的资金，因此它也就没有必要记录在蕴含潜在成本的UTXO集中，所以OP_RETURN实际是没有成本的。OP_RETURN常为一个金额为0的比特币输出，因为任何与该输出相对应的比特币都会永久消失。假如一笔OP_RETURN遇到脚本验证软件，它将立即导致验证脚本和标记交易的行为无效。如果你碰巧将OP_RETURN的输出作为另一笔交易的输入，则该交易是无效的。
一笔标准交易（通过了isStandard()函数检验的）只能有一个OP_RETURN输出。但是单个OP_RETURN输出能与任意类型的输出交易进行组合。

5.7.5 P2SH（Pay-to-Script-Hash）

P2SH在2012年被作为一种新型、强大、且能大大简化复杂交易脚本的交易类型而引入。为进一步解释P2SH的必要性，让我们先看一个实际的例子。
在第1章中，我们曾介绍过Mohammed，一个迪拜的电子产品进口商。Mohammed的公司采用比特币多重签名作为其公司会计账簿记账要求。多重签名脚本是比特币高级脚本最为常见的运用之一，是一种具有相当大影响力的脚本。针对所有的顾客支付（即应收账款），Mohammed的公司要求采用多重签名交易。基于多重签名机制，顾客的任何支付都需要至少两个签名才能解锁，一个来自Mohammed，另一个来自其合伙人或拥有备份钥匙的代理人。这样的多重签名机制能为公司治理提供管控便利，同时也能有效防范盗窃、挪用和遗失。
最终的脚本非常长：
2 <mohammed's public="" key="">5 OP_CHECKMULTISIG
虽然多重签名十分强大，但其使用起来还是多有不便。基于之前的脚本，Mohammed必须在客户付款前将该脚本发送给每一位客户，而每一位顾客也必须使用特制的能产生客户交易脚本的比特币钱包软件，每位顾客还得学会如何利用脚本来完成交易。此外，由于脚本可能包含特别长的公钥，最终的交易脚本可能是最初交易脚本长度的5倍之多。额外长度的脚本将给客户造成费用负担。最后，一个长的交易脚本将一直记录在所有节点的随机存储器的UTXO集中，直到该笔资金被使用。所有这些都使得在实际交易中采用复杂输出脚本显得困难重重。
P2SH正是为了解决这一实际难题而被引入的，它旨在使复杂脚本的运用能与直接向比特币地址支付一样简单。在P2SH支付中，复杂的锁定脚本被电子指纹所取代，电子指纹为密码学哈希。当一笔交易试图支付UTXO时，要解锁支付脚本，它必须含有与哈希相匹配的脚本。P2SH的含义是，向与该哈希匹配的脚本支付，当输出被支付时，该脚本将在后续呈现。
在P2SH交易中，锁定脚本由哈希取代，哈希指代的是赎回脚本。因为它在系统中是在赎回时出现而不是以锁定脚本模式出现。表5-4列示了非P2SH脚本，表5-5列示了P2SH脚本。
表5-4 不含P2SH的复杂脚本

表5-5 P2SH复杂脚本

正如你在表中所看到的，在P2SH中，出现了花费该笔支出（赎回脚本）条件的复杂脚本，而这在锁定脚本中并未出现。取而代之，在锁定脚本中，只出现了哈希，而赎回脚本则在稍后输出被支付时才作为解锁脚本的一部分而出现。
让我们再看下Mohammed公司的例子，复杂的多重签名脚本和相应的P2SH脚本。
首先，Mohammed公司对所有顾客订单采用多重签名脚本：
2 <mohammed's public="" key="">5 OP_CHECKMULTISIG
如果占位符由实际的公钥（以04开头的520字节）替代，你将会看到的脚本会非常地长：

204C16B8698A9ABF84250A7C3EA7EE-DEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DA-DA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1EC-ED3C68D446BCAB69AC0A7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG

整个脚本都可由仅为20个字节的密码哈希所取代，首先采用SH256哈希算法，随后对其运用RIPEMD160算法。20字节的脚本为：
54c557e07dde5bb6cb791c7a540e0a4796f5e97
一笔P2SH交易运用锁定脚本将输出与哈希关联，而不是与前面特别长的脚本所关联。使用的锁定脚本为：
OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL
正如你所看到的，这个脚本比前面的长脚本简短多了。取代“向该5个多重签名脚本支付”，这个P2SH等同于“向含该哈希的脚本支付”。顾客在向Mohammed公司支付时，只需在其支付指令中纳入这个非常简短的锁定脚本即可。当Mohammed想要花费这笔UTXO时，附上原始赎回脚本（与UTXO锁定的哈希）和必要的解锁签名即可，如：
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG>
两个脚本经由两步实现组合。首先，将赎回脚本与锁定脚本比对以确认其与哈希是否匹配：
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 OP_EQUAL
假如赎回脚本与哈希匹配，解锁脚本会被执行以释放赎回脚本：
2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG

5.7.5.1 P2SH地址

P2SH的另一重要特征是它能将脚本哈希编译为一个地址（其定义请见BIP0013）。P2SH地址是基于Base58编码的一个含有20个字节哈希的脚本，就像比特币地址是基于Base58编码的一个含有20个字节的公钥。由于P2SH地址采用5作为前缀，这导致基于Base58编码的地址以“3”开头。例如，Mohammed的脚本，基于Base58编码下的P2SH地址变为“39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw”。此时，Mohammed可以将该地址发送给他的客户，这些客户可以采用任何的比特币钱包实现简单支付，就像这是一个比特币地址一样。以“3”为前缀给予客户这是一种特殊类型的地址的暗示，该地址与一个脚本相对应而非与一个公钥相对应，但是它的效果与比特币地址支付别无二致。
P2SH地址隐藏了所有的复杂性，因此，运用其进行支付的人将不会看到脚本。

5.7.5.2 P2SH的优点

与直接使用复杂脚本以锁定输出的方式相比，P2SH具有以下特点：
▷ 在交易输出中，复杂脚本由简短电子指纹取代，使得交易代码变短。
▷ 脚本能被编译为地址，支付指令的发出者和支付者的比特币钱包不需要复杂工序就可以执行P2SH。
▷ P2SH将构建脚本的重担转移至接收方，而非发送方。
▷ P2SH将长脚本数据存储的负担从输出方（存储于UTXO集，影响内存）转移至输入方（仅存储于区块链）。
▷ P2SH将长脚本数据存储的重担从当前（支付时）转移至未来（花费时）。
▷ P2SH将长脚本的交易费成本从发送方转移至接收方，接收方在使用该笔资金时必须含有赎回脚本。

5.7.5.3 赎回脚本和标准确认

在0.9.2版比特币核心客户端之前，P2SH仅限于标准比特币交易脚本类型（即通过标准函数检验的脚本）。这也意味着使用该笔资金的交易中的赎回脚本只能是标准化的P2PK、P2PKH或者多重签名，而非OP_RETURN和P2SH。
作为0.9.2版的比特币核心客户端，P2SH交易能包含任意有效的脚本，这使得P2SH标准更为灵活，也可以用于多种新的或复杂类型的交易。
请记住不能将P2SH植入P2SH赎回脚本，因为P2SH不能自循环。也不能在赎回脚本中使用OP_RETURN，因为OP_RETURN的定义即显示不能赎回。
需要注意的是，因为赎回脚本只有在你试图发送一个P2SH输出时才会在比特币网络中出现，假如你将输出与一个无效的交易哈希锁定，则它将会被忽略。你将不能使用该笔资金，因为交易中含有赎回脚本，该脚本因是一个无效的脚本而不能被接受。这样的处理机制也衍生出一个风险，你能将比特币锁定在一个未来不能被花费的P2SH中。因为比特币网络本身会接受这一P2SH，即便它与无效的赎回脚本所对应（因为该赎回脚本哈希没有对其所表征的脚本给出指令）。
P2SH锁定脚本包含一个赎回脚本哈希，该脚本对于赎回脚本本身未提供任何描述。P2SH交易即便在赎回脚本无效的情况下也会被认为有效。你可能会偶然地将比特币以这样一种未来不能被花费的方式予以锁定。

==目录==

简介
前言
第1章 介绍
第2章 比特币的原理
第3章 比特币客户端
第4章 密钥、地址、钱包
第4章 高级密钥和地址
第5章 交易
第6章 比特币网络
第7章 区块链
第8章 挖矿与共识
第8章 区块链分叉、矿池、共识攻击
第9章 竞争币、竞争块链和应用程序
第10章 比特币安全
附录1 交易脚本的操作符、常量和符号
附录2 比特币改进协议
附录3 pycoin库、ku程序和tx交易程序
附录4 sx工具下一些的命令本文原链接：http://zhibimo.com/read/wang-miao/Mastering-Bitcoin/Chapter05.html