一个区块大小为1MB,比特币对每笔交易的大小没有限制, 一个区块一般可包含2000~3000笔交易。10分钟产生一个块 每秒可处理4、5比交易 采矿奖励每经过210,000个减半。由于每个块10分钟，因此四年发生一次减半 下一个减半将在2020年4月/ 5月的半年左右进行，励将从目前的12.5降至6.75/块。 2140年将开采比特币的2100万比特币的总供应量 现在每个币大概1万美元 比特币可以被分割成八位小数的“聪”（satoshi）。 在数字世界中，想要创造一种去中介化、去中心化的“电子现金”，要设计一套完整的系统。这一系统要能解决以下一系列问题： * 这种“现金”如何公平、公正地发行出来，不被任何中心化的机构或个人控制？ * 如何实现像在物理世界中一样，一个人可以直接把现金递给另一个人，无须任何中介的协助？ * 这种电子现金如何“防伪”？在数字世界中，这个问题可转换为，一笔电子现金如何不被花费两次？ 【疑惑处】 见证隔离 第一章 介绍.31 1.1 什么是比特币？ 比特币这四个创新包括： 去中心化的对等网络（比特币协议） 公共交易总帐（区块链） 独立交易确认和货币发行的一套规则（共识规则） 实现有效的区块链全球去中心化共识的机制（工作量证明算法） 1.2 比特币历史 2008 Satoshi Nakamoto “Bitcoin： A Peer-to-Peer Electronic Cash System” 1.3 比特币使用，用户和他们的故事 有各种不同的角色在构建bitcion系统 1.4 入门 1.4.1 选择比特币钱包 1.4.2 快速开始 1.4.3 得到你的第一个比特币 找一个有比特币的朋友， 直接从他或她那里买一些 通过卖比特币的产品或服务赚取比特币 交易所 1.4.4 查找比特币当前价格 1.4.5 发送和接收比特币 当交易通过对等协议传输时， 它会快速传播到比特币网络。在不到一秒钟内，网络中大多数连接良好的节点都 会首次接收到交易，并且首次看到 Alice 的地址。 同时，Alice 的钱包不断地“倾听”在比特币网络上发布的交易，寻找与她的钱包中 的地址匹配的任何内容。在 Joe 的钱包发送交易几秒钟后，Alice 的钱包将显示它 正在接收 0.10 BTC。 确认起初，Alice 的地址将把 Joe 的交易显示为“未确认”。这意味着交易已传播到 网络，但尚未记录在比特币交易账簿即区块链中。要确认，一个交易必须包含在 一个区块中，并被添加到区块链，这样的情况平均每 10 分钟发生一次。在传统 的财务术语中，这被称为清算。 第二章 比特币原理 2.1 交易，块，挖矿和区块链 取代中央信任机构的是，信任是通过比特币系统中不同参与者的相互作用达成的 将通过较高层面跟踪比特币系统单笔交易， 观察交易如何通过比 特币分布式共识机制变得可信， 被接受， 并且最终记录在区块链 2.1.1 比特币概述 blockchain explorer 是一个作为比特币搜索引擎运行的 Web 应用程 序，它允许您搜索地址，交易和块，并查看它们之间的关系和资金流动。 https://blockexplorer.com/ 2.1.2 买咖啡 2.2 比特币交易 2.2.1 交易输入输出 2.2.3 交易链 交易形成了一条链， 最近交易的输入对应以前交易的输出。 2.2.4 找零 许多比特币交易都会包括新所有者的地址（买方地址） 和当前所有者的地址（称为找零地址） 的输出 2.2.5 常见的交易形式 一对一 一对多 多对一 多对多 2.3 交易的构建 2.3.1 获取正确的输入 2.3.2 创建交易输出 2.3.3 将交易放到总账簿中 2.3.3.1 交易的传送 2.3.3.2 如何传播 2.4 比特币挖矿 作用有二：1.验证所有交易 2.创造新的比特币 2.5 区块中的挖矿交易记录 当比特币网络上的节点看到这 些交易时，会先将它们放到各自节点维护的一个临时的未经验证的交易池中。当 矿工构建一个新区块时， 会将这些交易从这个交易池中拿出来放到这个新区块 中，然后通过尝试解决一个非常困难的问题（也叫工作量证明）以证明这个新区 块的合法性。 这些交易被加进新区块时，以交易费用高的优先以及其它的一些规则进行排序。 矿工一旦从网络上收到一个新区块时，会意识到在这个区块上的解题竞赛已经输 掉了，会马上开始下一个新区块的挖掘工作。它会立刻将一些交易和这个新区块 的数字指纹放在一起开始构建下一个新区块，并开始给它计算工作量证明。 每个矿工会在他的区块中包含一个特殊的交易，将新生成的比特币 作为报酬支付到他自己的比特币地址，再加上块中所有交易的交易费用 的总和作为自己的报酬。 一个区块获得六次以上“确认”时就被认为是不可撤销的了 2.6 消费这笔交易 轻量级客户端通过确认一个交易在区块链中且在它 后面有几个新区块来确认一个支付的合法性。 这种方式叫做简易支付验证(spv) 第三章 比特币核心(BitcoinCore ) 比特币核心是比特币系统的参考实现， 这意味着它是如何实施的权威参考 BitcoinCore 实现了比特币的所有方面， 包括钱包， 交易和区块验证引擎， 以及 P2P 网络中的完整网络节点 警示 即使 Bitcoin Core 包含钱包的参考实现， 但这并不意味着可以用作用户或应 用程序的生产钱包。 建议应用程序开发人员使用现代标准（如 BIP-39 和 BIP-32） 构建钱包。 BIP 就是比特币改进提案（Bitcoin Improvement Proposal） 。 3.1 比特币开发环境 3.2 从源码编译比特币核心 3.2.1 选择比特币核心版本 3.2.2 配置构建比特币核心 ./autogen.sh ./configure 3.2.3 构建 Bitcoin 核心可执行文件 make && make install 确认 bitcoin 是否安装成功 $ which bitcoind /usr/local/bin/bitcoind $ which bitcoin-cli /usr/local/bin/bitcoin-cli 3.2.4 运行比特币核心节点 3.2.5 首次运行比特币核心 当你第一次运行 bitcoind 时， 它会提醒你用一个安全密码给 JSON-RPC 接口创建一 个配置文件。 该密码控制对 Bitcoin Core 提供的应用程序编程接口（API） 的访问。 3.2.6 配置比特币核心节点 配置文件放在/home/ubuntu/.bitcoin/bitcoin.conf rpcuser 和 rpcpassword 也在这个配置文件中 除了 rpcuser 和 rpcpassword 选项， Bitcoin Core 还提供了 100 多个 配置选项， 可以修改网络节点的行为， 区块链的存储以及其操作的许多其他方面。 交易数据库索引和 txindex 选项 3.3 通过命令行使用比特币核心的 JSON-RPC API 接口 bitcoin core实现了 JSON-RPC 接口，这个接口也可以通过命令行帮助程序 bitcoin-cli访问,bitcoin-cli只是一个负责请求json rpc的程序 3.3.1 获得比特币核心客户端状态的信息 bitcoin-cli getinfo 3.3.1.1 探索和解码交易 命令： getrawtransaction， decodeawtransaction gettransaction 3.3.2 探索区块 bitcoin-cli getblockhash 277316 bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b3 3.3.3 使用比特币核心的编程接口 Bitcoin Core 的 API 是一个 JSON-RPC 接口 bitcoin-cli helper 对于探索 Bitcoin Core API 和测试功能非常有用 大多数编程语言中都使用库， 以“包装”比特币核心 API 的方式使其简单得 多。 我们将使用 python-bitcoinlib 库来简化 API 访问。 请记住， 这需要您有一个 运行的 Bitcoin Core 实例， 将用于进行 JSON-RPC 调用。 3.4 其他替代客户端、 资料库、 工具包 第四章 秘钥和地址 4.1 简介 用于支出资金的数字签名也称为见证（witness） 密钥是成对出现的， 由一个私钥和一个公钥所组成。 公钥就像银行的帐号， 而私 钥就像控制账户的 PIN 码或支票的签名。 钱包地址在没有交易之前是不被节点知道的，有了交易后才能成为网络中已知地址的一部分 4.1.1 公钥加密和加密货币 4.1.2 私钥和公钥 非对称密码学的有用属性是生成数字签名的能力。 可以将私钥应用于交易 的数字指纹以产生数字签名。 该签名只能由知晓私钥的人生成。 4.1.3 私钥 生成一个比特币私钥在本质上与“在 1 到 2^256 之间选一个数字 只要选取的结果是不可预测或不可重复的 比特币软件使用操作系统底层的随机数生成器来产生 256 位的熵 （随机性） 。 通常情况下， 操作系统随机数生成器由人工的随机源进行初始化， 这就是为什么也可能需要不停晃动鼠标几秒钟。 getnewaddress 生成私钥和地址 dumpprivkey 打印私钥 4.1.4 公钥 通过私钥产生公钥 4.1.5 椭圆曲线密码学（Elliptic Curve Cryptography） 解释 todo：参考《图解密码学》来搞明白 4.2 比特币地址 由公钥产生 A = RIPEMD160(SHA256(K)) 注：K 是公钥， A 是生成的比特币地址 通常用户见到的比特币地址是经过“Base58Check”编码的 4.2.1 Base58 和 Base58Check 编码 为了增加防止打印和转录错误的安全性， Base58Check 是一种常用在比特币中的 Base58 编码格式，格式为：prefix + data + checksum prefix “版本字节”的前缀， 这个前缀用来识别编码的数据的类 型。 例如， 比特币地址的前 缀是 0（十六进制是 0x00，base58是1）， 而对私钥编码时前缀是 128（十六进制是 0x80，base58是5，K or L） checksum = SHA256(SHA256(prefix+data)).substr(0,4) 去hash后的前4位 4.2.2 密钥的格式 私钥可以以许多不同的格式表示， 所有这些都对应于相同的 256 位的数字。表 4-2 展示了私钥的三种常见格式。 不同的格式用在不同的场景下。 十六进制和原始的 二进制格式用在软件的内部， 很少展示给用户看。 WIF 格式用在钱包之间密钥的 输入和输出，也是人看到的格式， 也用于代表私钥的二维码 4.2.3 从 Base58Check 解码 4.3 用 Python 实现密钥和比特币地址 todo：之下的没细看 4.4 高级密钥和地址 4.4.1 加密私钥（BIP0038） 4.4.2 P2SH (Pay-to-Script Hash)和多重签名地址 4.4.3 比特币靓号地址 4.4.4 纸钱包 纸钱包是打印在纸张上的比特币私钥 第五章 钱包.108 广义上，钱包是一个应用程序，为用户提供交互界面。 狭义上，即从程序员的角度来看，“钱包”是指用于存储和管理用户密钥的数据结构。 本章中钱包是私钥的容器，一般是通过结构化文件或简单数据库来实现。 5.1 钱包技术概述 108 5.1.1 非确定性(nondeterministic wallet）)（随机） 钱包. 109 现在较少使用，对于备份和使用来说太麻烦了 5.1.2 确定性(deterministic wallet)（种子） 钱包 110 所有的密钥都是从一个主 密钥派生出来，这个主密钥即为种子（seed）。该类型钱包中所有密钥都相互关 联，如果有原始种子，则可以再次生成全部密钥。 为了便于使用，种子被编码为英文单词，也称为助记词。 5.1.3 分层确定性钱包（HD Wallets (BIP-32/BIP-44)） 110 HD 钱包包含以树状结构衍生的密钥， 使得父密钥可以衍生一系列子密钥，每个子密钥 又可以衍生出一系列孙密钥 5.1.4 种子和助记词（BIP-39） 111 5.1.5 钱包最佳实践 112 由于比特币钱包技术已经成熟，出现了一些常见的行业标准，使得比特币钱包具 备广泛互操作，易于使用，安全和灵活的特性。这些常用的标准是： 助记码，基于 BIP-39 HD 钱包，基于 BIP-32 多用途 HD 钱包结构，基于 BIP-43 多币种和多帐户钱包，基于 BIP-44 5.1.6 使用比特币钱包 112 5.2 钱包技术细节 114 钱包也是比特币的一大块东西 5.2.1 助记码词汇（BIP-39） .114 5.2.2 创建助记词 115 5.2.3 从助记词生成种子. 116 5.2.4 BIP-39 中的可选密码短语118 5.2.5 使用助记符代码 119 5.3 从种子中创造 HD 钱包 120 5.3.1 私有子密钥的衍生. 121 5.3.2 使用衍生的子密钥. 122 5.3.3 扩展密钥. 123 5.3.4 公共子密钥推导 123 5.3.5 在网店中使用扩展公钥（xpub） .125 5.3.6 硬化子密钥的衍生. 126 5.3.7 正常衍生和强化衍生的索引号码. 127 5.3.8HD 钱包密钥识别符（路径） . 127 5.3.9HD 钱包树状结构的导航 127 第六章 交易.128 在这一章，我们将会剖析比特币交易的多种形式、所包含的信息、如何被创建、 如何被验证以及如何成为所有比特币交易永久记录的一部分。 6.1 简介128 6.2 交易细节129 6.2.1 交易 - 幕后细节. 129 用gettransaction展示了交易的结构 6.3 交易的输入输出 131 当我们说用户的钱包已经“收到”比特币时，我们的意思是，钱包已经检测到了可用的 UTXO。 用户的比特币“余额”是指用户钱包中可用的 UTXO 总和，而他们可能分散在数百个交易和区块中 大多数钱包维护一个数据库或使用数据库服务来存储所有 UTXO 的快速参考集 一笔比特币交易通过使用所有者的签名来解锁UTXO，并通过使用新的所有者的比特币地址来锁定并创建 UTXO 6.3.1 交易输出 132 交易输出包含两部分：  一定量的比特币，面值为“聪”（satoshis） ，是最小的比特币单位；  确定花费输出所需条件的加密难题（cryptographic puzzle）， 加密难题使用被支付者的地址生成的，只能通过其私钥解密 这个加密难题也被称为锁定脚本(locking script), 见证脚本(witness script), 或脚本公钥 (scriptPubKey)。 6.3.2 交易输入. 134 1.指向UTXO的引用，即：哪个交易的第几个 2.解锁脚本， 用支付者的私钥产生的数字签名 3.sequence ？？ 若验证交易的话，程序得找到UTXO的引用 检索以前的交易和未花费的交易输出的函数是非常普遍的，并且存在于几乎每个比特币函数库和 API 中 6.3.3 交易费 137 交易费作为矿工打包（挖矿）一笔交易到下一个区块中的一种激励；同时作为一 种抑制因素，通过对每一笔交易收取小额费用来防止对系统的滥用。成功挖到某 区块的矿工将得到该区内包含的矿工费， 并将该区块添加至区块链中。 大多数钱包自动计算并计入交易费。但是， 如果你以编程方式构造交易，或者使用命令行界面，你必须 手动计算并计入这些费用。 交易费是基于交易的千字节规模来计算的，而不是比特币交易的价值。 矿工会依据许多不同的标准对交易进行优先级排序，包括费用，他们甚至可能在某些特定 情况下免费处理交易。 交易费影响处理优先级，这意味着有足够费用的交易会更可能被打包进下一个挖出的区块中 大多数服务为用户提供高、中、低优先费用的选择 交易的数据结构没有交易费的字段。相替代地，交易费是指输入和输出之间的差值 警告 ：找零 如果你忘记了在手动构造的交易中增加找零的输出，系统会 把找零当作交易费来处理。“不用找了！”也许不是你的真实意愿。 举例来说，如果你消耗了一个 20 比特币的 UTXO 来完成 1 比特币的付款，你必须 包含一笔 19 比特币的找零回到你的钱包。否则，那剩下的 19 比特币会被当作交 易费，并将由挖出你交易的矿工收走。尽管你会得到高优先级的处理，并且让一 个矿工喜出望外，但这很可能不是你想要的。 6.3.4 把交易费加到交易中 140 如果你忘记了在手动构造的交易中增加找零的输出，系统会把找零当作交易费来处理。 6.4 比特币交易脚本和脚本语言 141 类似Forth的逆波兰表达式的基于堆栈的执行语言 他们被放置在 UTXO 上的锁定脚本 和解锁脚本都以此脚本语言编写。 当一笔比特币交易被验证时，每一个输入值中 的解锁脚本与其对应的锁定脚本同时 （互不干扰地）执行，以确定这笔交易是否 满足支付条件。 6.4.1 图灵非完备性. 142 比特币脚本语言包含许多操作码，但没有条件流控制，以保证脚本有限的复杂性和可预见的执行次数 6.4.2 去中心化验证. 142 所有节点都会验证 6.4.3 脚本构建（锁定与解锁） . 142 比特币的交易验证引擎依赖于两类脚本来验证比特币交易：锁定脚本和解锁脚本。 UTXO 被永久地记录在区块链中，因此是不变的，并且不受在新交易中 引用失败的尝试的影响。 只有正确满足输出条件的有效交易才能将输出视为“开 销来源”，继而该输出将被从未花费的交易输出集（UTXO set）中删除。 6.4.4 P2PKH（Pay-to-Public-Key-Hash） .146 比特币的脚本语言被称为基于堆栈的语言 比特币网络处理的大多数交易花费的都是由“付款至公钥哈希” （或P2PKH）脚本锁定的输出 6.5 数字签名（ECDSA） .149 6.5.1 数字签名如何工作. 149 6.5.2 验证签名. 151 6.5.3 签名哈希类型（SIGHASH） 151 6.5.4 ECDSA 数学153 6.5.5 随机性在签名中的重要性 154 6.6 比特币地址， 余额和其他摘要 155 比特币浏览器中显示的地址是从锁定脚本中提取出来的 余额是从UTXO集中提取出来 总之，通过钱包应用程序、区块链浏览器和其他比特币用户界面呈现给用户的信 息通常源于更高层次的，通过搜索许多不同的交易，检查其内容以及操纵其中包 含的数据而的抽象而构成。 第七章 高级交易和脚本.157 7.1 介绍.157 7.2 多重签名157 7.3 P2SH（Pay-to-Script-Hash） 159 7.3.1 P2SH 地址 161 7.3.2 P2SH 的优点. 162 7.3.3 赎回脚本和标准确认. 162 7.4 数据记录输出（RETURN 操作符） 163 7.5 时间锁（Timelocks） . 164 7.5.1 交易锁定时间（nLocktime） . 164 7.5.2 检查锁定时间验证 Check Lock Time Verify (CLTV). 165 7.5.3 相对时间锁 167 7.5.4 nSequence 相对时间锁 167 7.5.5 带 CSV 的相对时间锁 168 7.5.6 中位时间过去 Median-Time-Past 169 7.5.7 针对费用狙击（Fee Sniping） 的时间锁定. 169 7.6 具有流量控制的脚本（条件子句 (Conditional Clauses)） 170 7.6.1 带有 VERIFY 操作码的条件子句171 7.6.2 在脚本中使用流控制. 172 7.7 复杂的脚本示例 173 第八章 比特币网络175 8.1 P2P 网络架构. 175 “比特币网络”是按照比特币 P2P 协议运行的一系列节点的集合。除了比特币 P2P 协议之外，比特币网络中也包含其他协议。例如 Stratum 协议就被应用于挖矿、 以及轻量级或移动端比特币钱包之中。 8.2 节点类型及角色. 175 尽管比特币 P2P 网络中的各个节点相互对等，但是根据所提供的 功能不同，各节点可能具有不同的角色。每个比特币节点都是： 路由、区块链数据库、挖矿、钱包服务的功能集合。 每个节点都参与全网络的路由功能，同时也可能包含其他功能。每个节点都参与 验证并传播交易及区块信息，发现并维持与对等节点的连接。 一些节点保有一份完整的、最新的区块链拷贝，这样的节点被称为“全节点”。全 节点能够独立自主地校验所有交易，而不需借由任何外部参照。另外还有一些节 点只保留了区块链的一部分，它们通过一种名为“简易支付验证（SPV）”的方 式 来完成交易验证。这样的节点被称为“SPV 节点”，又叫“轻量级节点”。 8.3 扩展比特币网络 8.4 比特币传播网络 180 -->主要为挖矿服务 比特币传播网络是一种尝试最小化**矿工**之间传输块的延迟的网络。原始的比特币 传播网络是由核心开发商 Matt Corallo 于 2015 年创建的，以便能够以非常低的延 迟在矿工之间快速同步块。 传播网络不是比特币的 P2P 网络的替代品。相反，它们是覆盖网络，在具有特殊 需求的节点之间提供额外的连接像高速公路不是农村道路的替代品，而是交通繁 忙的两点之间的快捷方式，您仍然需要小路连接高速公路。 8.5 网络发现.181 当新的网络节点启动后，为了能够参与协同运作，它必须发现网络中的其他比特币节点。 在新节点连接时，可以随机选择网络中存在的比特币节点与之相连。 版本消息始终是任何对等体发送给另一个对等体的第一条消息。接收版本消息的 本地对等体将检查远程对等体报告的 nVersion，并确定远端对等体是否兼容。 如 果远程对等体兼容，则本地对等体将确认版本消息，并通过发送一个 verack 建立 连接。 然后再向连接的节点发送获取节点列表的消息。 使用 bitcoin-cli getpeerinfo获取所有连接的节点 8.6 全节点.185 尽管目前还有一些使用不同编程语言及软件架构的其他的完整区块链客户端存 在，但是最常用的仍然是比特币核心客户 端，它也被称为“Satoshi 客户端”。比 特币网络中超过 90%的节点运行着各个版本的比特币核心客户端。如前文所述， 它 可以通过节点间发送的version消息或通过getpeerinfo命令所得到的子版本字 符串“Satoshi”加以辨识，例如 /Satoshi: 0.8.6/ 8.7 交换“库存清单” 186 我们假设某节点只含有创世区块。它收到了来自对等 节点的 inv 消息，其中包含了区块链中后 500 个区块的哈希值。于是它开始向所 有与之相连的对等节点请求区块，并通过分摊工作量的方式防止单一对等节点被 批量请求所压垮。 每当一个节点离线，不管离线时间有多长，这个与对等节点比较本地区块链并恢 复缺失区块的过程就会被触发。如果一 个节点只离线几分钟，可能只会缺失几个 区块；当它离线长达一个月，可能会缺失上千个区块。但无论哪种情况，它都 会 从发送 getblocks 消息开始，收到一个 inv 响应， 8.8 简易支付验证（Simplified Payment Verification (SPV) ）节点189 主要验证两步：1.本次交易是否存在 2.验证之后是否有足够多的块支持 getheaders --> header <-- SPV 节点只需下载区块头，而不用下载包含在每个区块中的交易信息。由此产生 的不含交易信息的区块链，大小只有完整区块链的 1/1000。 SPV需要向其他全节点来询问，请求数据，具体来说有：SPV节点交易的数据和次交易的markle路径 简易支付验证可以验证某个交易存在，而不能证明不存在，这是因为 SPV 节点没有一份关于所有交易的记录。 若怕其他全节点作假，可也向多个节点请求，以增加与至少一个可靠节点相连接的概率。 这种随机连接的需求意味着SPV节点也容易受到网络分区攻击或Sybil攻击。即连接的错了一个伪造的虚拟网络中。 8.9 Bloom 过滤器. 192 由于SPV节点需要读取特定交易从而选择性地验证交易，这样就又产生了隐私风险。 Bloom过滤器允许SPV节点接收交易的一个子集，通过使用概率而不是固定模式的 过滤机制无需精确地揭示他们感兴趣的地址。 Bloom 过滤器是一个允许用户描述特定的关键词组合而不必精确表述的基于概率 的过滤方法。它能让用户在有效搜索关键词的同时保护他们的隐私。 8.9.1 Bloom 过滤器如何工作192 Bloom 过滤器的实现是由一个可变长度（N）的二进制数组（N 位二进制数构成一 个位域）和数量可变（M）的一组哈希函数组成 验证关键词“X”是否在前述 Bloom 过滤器中，如果相应的比特位都被置为 1，所以这个关键词很有可能是匹配的。 验证关键词“Y”是否存在于简易 Bloom 过滤器中，如果某个结果字段为 0，该字段一定没有被匹配。 8.10 SPV 节点如何使用 Bloom 过滤器195 Bloom 过滤器用于过滤SPV节点从其对等体接收的交易（和包含它们的块），仅 选择SPV节点感兴趣的交易，而不会泄露其感兴趣的地址或密钥。 SPV节点将初始化“过滤器”为“空”;在该状态下，bloom 过滤器将不匹配任何模式。 然后，SPV 节点将列出所有感兴趣的地址，密钥和散列，它将通过从其钱包控制 的任何 UTXO 中提取公钥哈希和脚本哈希和交易ID来实现。SPV节点然后将其中 的每一个添加到Bloom过滤器，以便如果这些模式存在于交易中，则 Bloom 过滤 器将“匹配”，而不会自动显示模式。 然后，SPV 节点将向对等体发送一个过滤器加载消息，其中包含在连接上使用的 bloom 过滤器。在对等体上，针对每个传入交易检查 Bloom 过滤器。完整节点根 据 bloom 过滤器检查交易的几个部分，寻找匹配 在建立过滤器之后，对等体然后将针对 bloom 过滤器测试每个交易的输出。只有 与过滤器匹配的交易才会发送到节点。 响应于来自节点的 getdata 消息，对等体将发送一个 merkleblock 消息，该消息仅 包含与过滤器匹配的块和每个匹配交易的 merkle 路径（参见[merkle_trees]）的块 头。然后，对等体还将发送包含由过滤器匹配的交易的 tx 消息。 8.11 SPV 节点和隐私. 196 8.12 加密和认证连接 196 8.12.1Tor 运输 197 Tor 代表洋葱路由网络，是一个软件项目和网络，通过提供匿名，不可追踪和隐 私的随机网络路径提供数据的加密和封装。 Bitcoin Core 提供了多种配置选项，允许您运行通过 Tor 网络传输的流量的比特币 节点。此外，Bitcoin Core 还可以提供 Tor 隐藏服务，允许其他 Tor 节点通过 Tor 直接连接到您的节点。 8.12.2 对等认证和加密 197 8.13 交易池198 比特币网络中几乎每个节点都会维护一份未确认交易的临时列表，被称为内存池 或交易池。节点们利用这个池来追踪记录那些被网络所知晓、但还未被区块链所 包含的交易。 有些比特币客户端的实现还维护一个 UTXO 数据库，也称 UTXO 池，是区块链中 所有未支付交易输出的集合。“UTXO 池”的名字听上去与交易池相似，但它代表 了不同的数据集。UTXO 池不同于交易池和孤立交易池的地方在于，它在初始 化 时不为空，而是包含了数以百万计的未支付交易输出条目，有些条目的历史甚至 可以追溯至 2009 年。UTXO 池可能会被安置在本地内存，或者作为一个包含索引 的数据库表安置在永久性存储设备中。 第九章 区块链198 9.1 简介.199 区块链的数据结构是由包含交易信息的区块按照从远及近的顺序有序链接起来 的。它可以被存储为平面文件（flat file），或是存储在一个简单数据库中。比特 币核心客户端使用 Google 的 LevelDB 数据库存储区块链元数据。 虽然每个区块只有一个父区块，但可以暂时拥有多个子区块。每个子区块都将同 一区块作为其父区块，并且在“父区块哈希值”字段中具有相同的（父区块）哈希值。 一个区块出现多个子区块的情况被称为“区块链分叉”。区块链分叉只是暂时 状态，只有当多个不同区块几乎同时被不同的矿工发现时才会发生。最终， 只有一个子区块会成为区块链的一部分，同时解决了“区块链分叉”的问题。 9.2 区块结构.200 一个包含元数据的区块头和紧跟其后的构成区块主体的一长串交易列表组成。 9.3 区块头.200 描述了区块头中的字段 9.4 区块标识符： 区块头哈希值和区块高度. 201 通过区块头哈希值和区块高度两个字段能唯一地识别出一个特定区块 区块哈希值实际上并不包含在区块的数据结构里 区块的哈希值可能会作为区块元数据的一部分被存储在一个独立的数据库表中， 以便于索 引和更快地从磁盘检索区块。 9.5 创世区块.201 9.6 区块链接成为区块链 203 9.7 Merkle 树 206 提供了一种校验区块是否存在某交易的高效途径。 它只能验证存在交易，没法验证不存在交易 首先，是SPV收到最新消息，获知关于自身地址的一个交易上链了，它需要向全节点求证此事， 于是向全节点(保存了所有数据的node)发出请求（带有隐私保护的请求方式），全节点返回必要信息给SPV，足够SPV快速验证其存在性。 好了，关键点来了，全节点返回的主要信息为某区块所有交易对应的Merkle树（虚拟的哦，并没有做存储）上的 一些Hash值。 SPV收到Merkle树层高数个的Hash值后，就可以本地模拟Merkle树制造过程，最终产出的Merkle根值， 和SPV本地保存的Merkle根做比较，一致的话，则认为全节点返回的数据全部都正确，对应交易确实存在。 否则不可能临时捏造出一系列hash值，最终还刚好和本地Merkle跟相等。 SPV钱包节点无需下载区块链完整数据，而只需下载区块链的每块不包含交易的头部数据； 在验证某一个交易真实性的时候，SPV钱包节点只需要把该交易哈希值向网络中连接的全节点发起询问 网络里面的全节点只需要回复最小量必要数据给SPV钱包，即可验证交易真实性； 如果SPV钱包不信任提供交易验证数据的全节点，还可以同时发起多个全节点的询问，来确保交易验证的最大可靠性。 具体参考： 区块链中merkle树是如何验证的，它的具体运行机制是？ https://www.zhihu.com/question/62844713 9.8 Merkle 树和简单支付验证（SPV） .210 Merkle 树被 SPV 节点广泛使用。SPV 节点不保存所有交易也不会下载整个区块， 仅仅保存区块头。它们使用认证路径或者 Merkle 路径来验证交易存在于区块中， 而不必下载区块中所有交易。 9.9 比特币的测试区块链. 210 9.9.1 Testnet——比特币的试验场 210 任何打算在比特币主干网上用于生产的软件开发都应该首先在 testnet 上用测试 币进行测试。这样可以保护开发人员免受由于软件错误而导致的金钱损失，也可 以保护网络免受由于软件错误导致的意外攻击 使用testnet： bitcoind -testnet 这样是直接连接的测试网 9.9.2 Segnet—隔离见证测试网络. 212 由于 已经将 segwit 添加到 testnet3 中，因此后来不再使用 segnet 来测试 segwit功能。 在将来，我们可能会看到其他专门用于测试单个功能或主要架构更改（如 segnet） 的测试网络区块链。 9.9.3 Regtest--本地区块链.213 bitcoind -regtest 就像使用 testnet 一样，Bitcoin Core 将在 bitcoind 默认目录的 regtest 子目录下初 始化一个新的区块链： bitcoind: Using data directory /home/username/.bitcoin/regtest 要使用命令行工具，还需要指定 regtest 标志。 我们来试试 getblockchaininfo 命 令来检查 regtest 区块链： $ bitcoin-cli -regtest getblockchaininfo $ bitcoin-cli -regtest generate 500 产生块 $ bitcoin-cli -regtest getbalance 9.10 使用测试块链进行开发 214 Bitcoin 的各种区块链（regtest，segnet，testnet3，以及主干网）为比特币开发提 供了一系列测试环境。先在测试网通过了才能在主干网通过 第十章 挖矿和共识214 10.1 简介.214 挖矿的目的：1.记账 2.发行货币 10.1.1 比特币经济学和货币创造. 216 介绍了比特币的总发行量和如何发行的 因发行量有限，而可能导致的通货紧缩的问题 10.2 去中心化共识. 217 去中心化共识由所有网络节点的4种独立过程相互作用而产生： ▷ 每个全节点依据综合标准对**每个交易**进行独立验证 ▷ 通过完成**工作量证明**算法的验算，挖矿节点将交易记录独立**打包**进新区块 ▷ 每个节点独立的对**新区块进行校验**并组装进区块链 ▷ 每个节点对区块链进行独立选择，在工作量证明机制下选择累计**工作量最大的区块链**。 一下部分为详细叙述。 10.3 交易的独立校验 218 checklist： 交易的语法和数据结构必须正确。 输入与输出列表都不能为空。 交易的字节大小是小于 MAX_BLOCK_SIZE 的。 交易的字节大小是大于或等于 100 的。 每一个输出值，以及总量，必须在规定值的范围内 （小于 2,100 万个币，大于0）。 解锁脚本（ scriptSig ）只能够将数字压入栈中，并且锁定脚本（ scriptPubkey ）必须要符合 isStandard 的格式 （该格式将会拒绝非标准交易） 对于每一个输入，引用的输出是必须存在的，并且没有被花费，且是自己能解锁的。 对于每一个输入，在主分支和交易池中寻找引用的输出交易。如果输出交易缺 少任何一个输入，该交易将成为一个孤 立的交易。如果与其匹配的交易还没有出 现在池中，那么将被加入到孤立交易池中。 这些条件能够在比特币标准客户端下的 AcceptToMemoryPool 、 CheckTransaction 和 CheckInputs 函数中获得更详细的阐述。 请注意，这些条件 会随着时间发生变化 在收到交易后， 每一个节点都会在全网广播前对这些交易进行独立校验， 并以 接收时的相应顺序， 为有效的新交易建立一个验证池（还未确认） ， 这个池可以 叫做交易池， 或者 memory pool 或者 mempool 10.4 挖矿节点.220 一些节点被称为专业节点“矿工”。 10.5 打包交易至区块. 220 在上一个 10 分钟内， 当 Jing 的节点正在寻找区块 277,315 的解的同时， 它也在收 集交易记录为下一个区块做准备。 目前它已经收到了几百笔交易记录，并将它们 放进了内存池。 直到接收并验证区块277,315后， Jing 的节点会检查内存池中 的 全部交易， 并移除已经在区块 277,315 中出现过的交易记录，确保任何留在内存 池中的交易都是未确认的， 等待被记录到新区块中。 ​ Jing的节点立刻构建一个新的空区块，做为区块277,316的候选区块。 称作候 选区块是因为它还没有包含有效的工作量证明， 不是一个有效的区块，而只有在 矿工成功找到一个工作量证明解之后， 这个区块才生效。 10.5.1 创币交易 222 区块中的第一笔交易是笔特殊交易，称为创币交易或者 coinbase 交易。 与常规交易不同，创币交易没有输入，不消耗 UTXO。它只包含一个被称作 coinbase 的输入，仅仅用来创建新的比特币。 10.5.2 Coinbase 奖励与矿工费 223 如果 Jing 的挖矿节点把 coinbase 交易写入区块，那么如何防止 Jing 奖励自 己 100 甚至 1000 比特币？ 答案是，不正确的奖励将被其他人视为无效，浪费了 Jing 用于工作证明的投入。 只有这个区块被大家认可，Jing 才能得到报酬。 10.5.3 创币交易的结构 224 在 Coinbase 交易中，“交易哈希”字段 32 个字节全部填充 0，“交易输出索引”字段 全部填充 0xFF(十进制的 255)，这两个字段的值表示不引用 UTXO。“解锁脚本”由 coinbase 数据代替，数据可以由矿工自定义。 10.5.4 Coinbase 数据.225 10.6 构造区块头. 227 为了构造区块头，挖矿节点需要填充六个字段。 分别是Version，Previous Block Hash，Merkle Root，Timestamp，Difficulty Target 和Nonce 区块头完成全部的字段填充后，挖矿就可以开始进行了。挖矿的目标是找到一 个使区块头哈希值小于难度目标的 nonce。挖矿节点通常需要尝试数十亿甚至数 万亿个不同的 nonce 取值，直到找到一个满足条件的 nonce 值。 10.7 构建区块.228 10.7.1 工作量证明算法 228 10.7.2 难度表示 233 10.7.3 难度目标与难度调整 234 难度是一个动 态的参数，会定期调整以达到每10分钟 一个新区块的目标。简单地说，难度被设定在，无论挖矿能力如何，新区块产生 速 率都保持在 10 分钟一个。 10.8 成功构建区块. 236 10.9 校验新区块. 236 验证函数在CheckBlock()和CheckBlockHead()中 ▷ 区块的数据结构语法上有效 ▷ 区块头的哈希值小于目标难度（确认包含足够的工作量证明） ▷ 区块时间戳早于验证时刻未来两个小时（允许时间错误） ▷ 区块大小在长度限制之内 ▷ 第一个交易（且只有第一个）是 coinbase 交易 ▷ 使用检查清单验证区块内的交易并确保它们的有效性 10.10 区块链的组装与选择 237 如果节点收到了一个有效的区块，而在现有的区块链中却未找到它的父区块， 那么这个区块被认为是**孤块**。 孤块会被保存在**孤块池**中， 直到它们的父区块被 节点收到。 一旦收到了父区块并且将其连接到现有区块链上，节点就会将孤块从 孤块池中取出，并且连接到它的父区块，让它作为区块链的一部分。 10.10.1 区块链分叉. 238 因为同时打包的节点可能有多个，所有就会出现分叉，解决的办法是， 每一个节点总是选择并尝试延长代表累计了最大工作量证明的区块链，也就是最 长的或最大累计工作的链 若同时来了两个快，先来的X入链，后来的不丢弃，而是形成备用链。虽然节点 X 认为 自己已经正确选择了获胜链，但是它还会保存“丢失”链，使得“丢失”链如果可能 最终“获胜”，它还具有重新打包的所需的信息。 分叉问题几乎总是在一个区块内就被解决了。 比特币将区块间隔设计为 10 分钟，是在更快速的交易确认和更低的分叉概率间作出的妥协。 更短的区块产生间隔会让交 易清算更快地完成，也会导致更加频繁地区块链分 叉。与之相对地，更长的间隔会减少分叉数量，却会导致更长的清算时间 10.11 挖矿和算力竞赛 245 现在的竞争已经不再是比较单一芯片的能力，而是一个矿场能塞进 多少芯片，并处理好散热和供电问题。 10.11.1 随机值升位方案(the extra nonce solution) 246 在比特币的早期，矿工可以通过遍历随机数 (Nonce)获得符合要求的 hash 来挖出一个块。 但难度增长后，nonce的长度就不够了。 区块头需要信息来源的一个新的“变革”。解决方案是使用 coinbase 交易作为额外的随机值来源，因为 coinbase 脚本可以储存 2-100 字节的数据，矿 工们开始使用这个空间作为额外随机值的来源，允许他们去探索一个大得多的区 块头值范围来找到有效的块。这个 coinbase 交易包含在 merkle 树中，这意味着任 何 coinbase 脚本的变化将导致 Merkle 根的变化。 10.11.2 矿池 247 在这个激烈竞争的环境中，个体矿工独立工作（也就是 solo 挖矿）没有一点机会。 现在矿工们合作组成矿池，汇集数以千计参与者们的算力并分享奖励。通 过参加 矿池，矿工们得到整体回报的一小部分，但通常每天都能得到，因而减少了不确定性。 矿池通过专用挖矿协议协调成百上千的矿工。 个人矿工在建立矿池账号后，设置他们的矿机连接到矿池服务器。 他们的 挖矿设备在挖矿时保持和矿池服务器的连接，和其他矿工同步各自的工 作。这样，矿池中的矿工分享挖矿任务，之后分 享奖励。成功出块的奖励支付到 矿池的比特币地址，而不是单个矿工的。一旦**奖励达到一个特定的阈值**，矿池服 务器便会定期支 付奖励到矿工的比特币地址。 通常情况下，矿池服务器会为提供矿池服务收取一个百分比的费用。参加矿池的 矿工把搜寻候选区块的工作量分割，并根据他们挖矿的贡献赚取“份额”。矿池为 赚取“份额”设置了一个低难度 的目标，通常比比特币网络难度低 1000 倍以上。 10.11.2.1 托管矿池 大部分矿池是“托管的”，意思是有一个公司或者个人经营一个矿池服务器。矿池 服务器的所有者叫矿池管理员，同时他 从矿工的收入中收取一个百分比的费用。 矿池服务器运行专业软件以及协调池中矿工们活动的**矿池采矿协议**。矿池服务器 同时也连接到一个或更多比特币完全节 点并直接访问一个块链数据库的完整副本。 这使得矿池服务器可以代替矿池中的矿工验证区块和交易， 缓解他们运行一 个完整节点的负担。 矿工连接到矿池服务器使用一个采矿协议比如 Stratum (STM)或者GetBlockTemplate (GBT)。 10.11.2.2 P2P矿池 托管矿池存在管理人作弊的可能，管理人可以利用矿池进行双重支付或使区块无 效。（参见“10.12 共识攻击”） 此外，中 心化的矿池服务器代表着单点故障。 如果因为拒绝服务攻击服务器挂了或者被减慢，池中矿工就不能采矿。 在 2011 年， 为了解决由中心化造成的这些问题，提出和实施了一个新的矿池挖 矿方法。P2Pool 是一个点对点的矿池，没有中心管理 人。P2Pool 通过将矿池服 务器的功能去中心化，实现一个并行的类似区块链的系统，名叫份额链（sharechain）。 作为多样化采矿生态系统的一部分，P2Pool 整体使得比特币更加强大。 10.12 共识攻击. 250 1. **区块链分叉/双重支付攻击**指的是攻击者通过 不承认最近的某个交易， 并在这个 交易之前重构新的块，从而生成新的分叉，继而实现双重支付。 2.**拒绝服务攻击**就是拒绝对某个特定的比特币地址提供服务。 一个拥有 了系统中绝 大多数算力的攻击者， 可以轻易地忽略某一笔特定的交易。 如果这笔 交易存在于另一个矿工所产生的区块中， 该攻击者可以故意分叉， 然后重新产生 这个区块， 并且把想忽略的交易从这个区块中移除。 这种攻击造成的结果就是， 只要这名攻击者拥有系统中的绝大多数算力，那么他就可以持续地干预某一个或 某一批特定钱包地址产生的所有交易， 从而达到拒绝为这些地址服务的目的。 共识攻击也不会影响用户的私钥以及加密算法（ECDSA） 共识攻击也 不能从其他的钱包那里偷到比特币、不签名地支付比特币、重新分配 比特币、改变过去的交易或者改变比特币持有纪录。 共识攻击能够造成的唯一影 响是影响最近的区块（最多 10 个）并且通过拒绝服务来影响未来区块的生成。 算力达到全网的 30%就足以发动 51%攻击了。 10.13 改变共识规则 252 虽然共识规则在短期内是不变的，并且在所有节点之间必须一致，但长期来看它 们并不总是不变的。 为了演进和开发比特币系统，规则必须随时改变以适应新功 能，改进或修复错误。 然而，与传统软件开发不同，升级到共识系统要困难得多， 需要所有参与者之间的协调。 10.13.1 硬分叉. 253 双花问题怎么解决？？？ 由于共识规则的变化，网络也可能会分叉到两条链条，网络不会重新收敛到单个链路上。 当新旧节点共识机制不同时，新的将拒绝该笔交易和区块，并且不会传播它们 分叉币往往在名字上与比特币沾亲带故，比如比特币现金（BCH），比特币黄金（BTG），比特币钻石（BCD）等， 一般情况下，正牌比特币的持有者都会获得相应的**分叉币**，直接就成了分叉币的初始用户。 最成功的比特币硬分叉案例当属比特币现金（BCH），自2017年8月1日进行硬分叉，至今已稳踞全球加密货币 第四名的位置，可见其受欢迎程度。 分叉币的影响－消极： 短期来看，硬分叉使新链和旧链同时出现，互为竞争关系。 分叉后短期内，由于市场上同时出现比特币及其分叉币，发币总量翻倍（比如BCH，BTG等，与BTC发币总量一样， 均是2100万个），甚至更多（比如BCD，发币总量2.1亿个）。从而导致币的价格稀释。 10.13.2 硬分叉： 软件， 网络， 采矿和链.254 10.13.3 分离矿工和难度. 255 随着矿工们被分裂开始开采两条不同的链条，链上的哈希算力也被分裂。两个链 之间的挖矿能力可以分成任意比例。新的规则可能只有少数人跟随，或者也可能 是绝大多数矿工。 10.13.4 有争议的硬叉 255 任何没有被所有人支持的硬分叉建议也被认为是“有争议”的， 不愿冒险分裂系统。 10.13.5 软分叉. 256 并非所有共识规则的变化都会导致硬分叉。只有**向前不兼容**的共识规则的变化才会导致分叉。 实际上软分叉不是分叉。软分叉是与共识规则的前向兼容并作些变化，允许未升级的客户端程序继续与新规则同时工作。 即旧的能往新的发，新的也能往旧的发。 软分叉级只能用于增加共识规则约束，而不是扩展它们。 因为如果扩展了，旧的节点就会不承认。 而增加约束的话，旧的肯定会承认新的，而新的可以增加根据版本验证的功能。 10.13.5.2 其他方式软分叉升级 Segwit 是一个交易结构的体系结 构变化，它将解锁脚本（见证）从交易内部移动到外部数据结构（将其隔离）。 Segwit 最初被设想为硬分叉升级，因为它修改了一个基本的结构（交易）。后来一从业者想了个法子弄成不用硬分叉了。 因此，可以引入 segwit 就是软分叉，而不需要每个节点必须从链上升级或拆分网 络。有可能还有其他尚未被发现的机制，通过这种机制可以以向前兼容的方式进 行升级，都作为软分叉。 10.13.6 对软分叉的批评. 257 对软分叉更改的常见批评包括：技术性债务由于软叉在 技术上比硬叉升级更复杂，所以引入了技术性债务，这是指由于过去的设计权衡 而增加代码维护的未来成本。代码复杂性又增加了错误和安全漏洞的可能性。 10.14 使用区块版本发出软分叉信号. 257 ？？？具体如何分叉机制还不太明白。 “激活”软分叉的机制是通过向矿工发出信号准备：大多数矿工必须同意他们准备并愿意执行新的共识规则。 10.14.1 BIP-34 信号和激活257 10.14.2 BIP-9 信号和激活258 10.15 共识软件开发 260 作为一个去中心 化的制度，不存在将权力强加于网络参与者的“权威”。权力分散在多个支持者， 如矿工，核心开发商，钱包开发商，交易所，商家和最终用户之间。这些支持者 不能单方面做出决定。例如，矿工在理论上可以通过简单多数（51％）来改变规 则，但受到其他支持者的同意的限制。 如果他们单方面行事，其他参与者可能会拒绝遵守，将经济活动保持在少数链条 上。没有经济活动（交易，商人，钱包，交易所），矿工们将用空的块开采一个 无价值的货币。这种权力的扩散意味着所有参与者必须协调，或者不能做出任何 改变。现状是这个制度的稳定状态，只有在很大程度上达成一致的情况下，才能 有几个变化。软分叉的 95％门槛反映了这一现实。 重要的是要认识到，对于共识发展没有完美的解决办法。硬分叉和软分叉都涉及 权衡。对于某些类型的更改，软分叉可能是一个更好的选择;对于别人来说，硬分 叉可能是一个更好的选择。没有完美的选择，都带有风险。共识软件开发的一个 不变特征是变革是困难的，是共识力量的妥协。 第十一章 比特币安全.260 11.1 安全准则.260 比特币的去中心化安全模型很大程度上将权力移交到用户手上，随之而来的是用 户们保管好密钥的责任。 11.1.1 比特币系统安全开发 261 如果你想利用好比特币的安全 性，你需要确保自己处于比特币的安全模型 里。简而言之，不要将用户的密钥控制权拿走，不要接受非区块链交易信息。 例如，许多早期的比特币交易所将所有用户的资金集中在一个包含着私钥的“热钱 包”里，并存放在服务器上。 要想充分利用比特币特有的去中心化安全模 型，你必须避免中心化架构的常见诱惑，因它最终将摧毁比特币的安全性。 11.1.2 信任根 262 传统的安全体系基于一个称为信任根（ROOT OF TRUST）的概念，它指的总体系 统或应用程序中一个可信赖的安全核心。 比特币的安全体系与这不同，比特币系统可以使用区块链作为它们的信任根。 11.2 用户最佳安全实践 262 现代通用的操作系统并不是十分安全，亦不特别适合用来存储数字货币。 随着比特币不断被接纳，一个直接的结果是， 我们已经看到信息安全领域取得了巨大创新，例如硬件 加密，密钥存储和硬件钱 包，多重签名技术和数字托管。 11.2.1 比特币物理存储 263 我个人将大部分（99％以上）的比特币存储在纸钱包上，并用 BIP0038 加密，复制了多份并锁在保险箱里。 将比特币离线保存的方法被称为冷存储，它是最有效的安全技术之一。 冷存储系统是在一个离线系统（一个从来没有连接过互联网的系统）上生成密钥，并 离线存储到纸上或者 U 盘等电子媒介上。 所以不存在通过网络而泄漏的问题。 11.2.2 硬件钱包 263 从长远来看，比特币安全将越来越多地以硬件防篡改钱包的形式出现。与智能手 机或台式电脑不同，一个比特币硬件钱包只有一个目的，安全地存储比特币。不 像容易受害的常用软件那样，硬件钱包只提供了有限的接口，从而可以给非专业 用户提供近乎万无一失的安全等级。 11.2.3 平衡风险 264 虽然大多数用户都非常关注比特币防盗，其实还有一个更大的风险存在。数据文 件丢失的情况时有发生。如果比特币的数据也在其中，损失将会让人痛苦不堪。 为了保护好比特币钱包，用户必须非常注意不要剑走偏锋，这样不至于会搞丢比 特币。在 2011 年 7 月，一个著名的比特币认知教育项目损失了近 7,000 枚比特币。 为了防止被盗窃，其主人曾之前采取了一系列复杂的操作去加密备份。结果他们 不慎丢失了加密的密钥，使得备份变得毫无价值，白白失去了一大笔财富。如果 你保护比特币的方式太过了，这好比于把钱藏在沙漠里，你可能不能再把它找回 来了 11.2.4 分散风险 264 审慎的用户应该只留一小部分（或许低于 5%） 的 比特币在一个在线的或手机钱包，就像零用钱一样，其余的部分应该采用不同存 储机制分散开来，诸如电脑钱包和离线（冷存储）钱包。 11.2.5 多重签名管理. 264 当一个公司或个人持有大量比特币时，他们应该考虑采用多重签名的比特币地址。 多重签名比特币地址需要多个签名才能支付，从而保证资金的安全。多重签名的 密钥应存储在多个不同的地方，并由不同的人掌控。打个比方，在企业环境中， 密钥应该分别生成并由若干公司管理人员持有，以确保没有任何一个人可以独自 占有资金。多重签名的地址也可以提供冗余，例如一个人持有多个密钥，并将它 们分别存储在不同的地方。 11.2.6 存活能力 264 如果比特币的持有人挂了，而其家人有不知道私钥怎么办？ 你应该考虑与一个值得信赖的亲 属或律师分享解密的细节。可以搞一个更复杂的比特币恢复 计划，可以通过设置 多重签名，做好遗产规划，并通过专门的“数字资产执行者”律师处理后事。 第十二章 比特币应用（区块链的应用）.265 12.1 介绍265 比特币系统被设计为一个分布式的货币及支付系统。 然而，它的大部分功能源于 可用于更广泛应用中的较低级别的结构（区块链）。 12.2 构建块（原语） 265 12.3 源于构建区块的应用. 267 12.4 染色币（Colored Coins） 267 12.4.1 使用染色币 268 12.4.2 发行染色币 268 12.4.3 染色币交易 269 12.5 合约币（Counterparty） .272 12.6 支付通道和状态通道. 272 12.6.1 状态通道基本概念和术语 273 12.6.2 简单支付通道示例. 273 12.6.3 制造无需信任的通道. 277 12.6.4 不对称可撤销承诺. 279 12.6.5 哈希时间锁合约（Hash Time Lock Contracts， HTLC） 282 12.7 可路由的支付通道（闪电网络） . 283 12.7.1 闪电网络示例 284 12.7.2 闪电网络传输和路由. 287 12.7.3 闪电网络优势 288 12.8 结论289