Soft Fork

假设安娜和帕维尔都用自己的电脑验证 Bitcoin。安娜已经更新软件，帕维尔还没有。此时出现一项类似 BIP66 的改动：用来证明有权花费某些比特币的数字签名，必须采用规定得更严格的格式。部分过去可以接受的编码方式不再被允许。 如果一笔付款的有效签名采用了新要求的格式，就能通过两台电脑的这项检查。但如果签名使用过去允许、现在禁止的编码方式，安娜会拒绝它，帕维尔却仍可能接受。这里假设付款满足其他全部规则。Soft Fork 的关键就在这里：新规则多禁止了一些情况，却没有放行旧规则原本禁止的情况。 只要矿工继续生成符合更严格规则的区块，两人就都能跟随这条链。但帕维尔并没有亲自检查新增条件。因此，Soft Fork 可以让 Bitcoin 在不要求所有节点同时更新的情况下发生改变。这并不代表旧软件和新软件检查得一样全面，也不会自行创造第二种货币。 [1] [6]

Full Node 是独立检查 Bitcoin 规则的计算机。在有效分支之间选择时，它比较的是挖矿所证明的累计工作量，而不是支持者的票数。旧全节点仍可跟随链，因为升级矿工通常生产它认可的区块，但它不会检查新增条件。如果一条累计工作更多的分支违反新规则，旧节点可能接受，而新节点拒绝。需要新保证的用户必须升级自己的验证软件。能接收付款、识别地址格式和完整执行共识规则并不是一回事。 [1] [12]

BIP 是带编号的技术提案。公布提案并不会改变网络：还需要开发和检查软件，再由用户决定是否运行。Mainnet 是实际转移比特币的主网。激活决定了已升级节点从什么时候开始要求遵守新规则。 因此，程序里已经有某段代码，并不代表检查区块时已经在使用它。在这里介绍的激活流程中，lock-in 表示后续激活的前提已满足，但规则本身可能还未执行。只有进入 ACTIVE 状态，节点才开始检查这条规则。节点根据自己所在分支的先前区块计算状态。如果激活边界附近发生重组，改变了这段历史，计算结果也可能变化。因此，采用不同激活参数的两个程序，在同一时刻可能接受不同的区块。 [2] [15]

矿工在前一个区块上构建新区块，前者也称父区块。如果不检查父区块，就可能把算力浪费在其他节点会拒绝的分支上。2015 年 7 月 BIP66 激活时，一些矿工发出新版本信号，却未充分验证所接父区块。他们延伸了无效区块，7 月 4 日形成六区块无效分支，次日又发生较短分叉。升级验证节点拒绝了它们。版本号或版本位只是矿工声明，不证明其独立验证了模板、父区块与交易。 [6] [14]

想确认自己的节点实际执行哪些规则，先看软件版本，再看节点自身返回的信息。根据所用版本，getdeploymentinfo 和 getblockchaininfo 会提供部署情况和链状态。结合该版本的文档、激活高度和日志，可以分清一条规则是已经准备好，还是已经生效。网页上的区块浏览器展示的是另一项服务的视角，不能证明你的电脑检查了什么。 Hashrate 衡量挖矿算力，却不赋予矿工绕过你所用规则的权力。在 ACTIVE 状态，已升级节点会拒绝违反新条件的区块，即使它背后是多数算力。分裂是否持续，还取决于各分支积累的工作量，以及人们在经济活动中使用哪条分支。直接取消已生效的限制，会重新允许当前无效的区块，因此属于 Hard Fork。激活前可以通过协调发布的新版本修改参数，但这种修改同样不会自行安装到别人的节点上。 [1] [15] [16]

V(旧) 是升级前规则接受的全部区块。只有当 V(新) 包含于其中时，变化才是Soft Fork：新节点多拒绝一些情况，而每个符合新规则的区块仍通过旧检查。这个名称描述有效性规则的兼容关系，不代表改动小、安全或已有社会共识。提高旧节点可见的上限，或允许过去无效的花费，会扩大集合，通常需要Hard Fork。 [1] [17]

收紧规则也能带来新功能。BIP66 严格规定了 DER 这一签名数据编码格式。BIP65 和 BIP112 为某些原先不强制执行任何条件的 NOP 指令，加入了花费时间限制。SegWit 引入了 witness 程序，以及称为 witness 的验证数据，例如签名。Taproot 后来使用了其中预留的版本 1。旧节点不检查相应的新条件；anyone-can-spend 描述的是这种有限视角，并不表示能绕过已升级节点、花掉别人的币。SegWit 还通过 witness commitment，把 witness 数据与区块进行密码学绑定。这一绑定记录在 coinbase 交易中，也就是包含矿工奖励的区块首笔交易，并保持了与旧有基础区块规则的兼容性。 [6] [5] [7] [8] [12]

比特的值是 0 或 1。在记录区块版本的头部字段 nVersion 中，各个比特可以用来表示矿工已准备好。BIP9 为每次部署指定名称、特定比特、开始时间和截止时间。 最初的主网流程按每 2016 个区块评估。在 STARTED 阶段，如果至少 1916 个区块发出信号，即达到 95%，下一个周期就进入 LOCKED_IN。再等待一个周期后进入 ACTIVE。如果未在截止前满足条件，流程可能以 FAILED 结束。开始之前的初始状态称为 DEFINED。 每个节点都根据先前的区块计算这套状态。因此，某个区块自身的 nVersion 并不决定新规则是否对它生效。信号用于协调过渡，不是对单个区块有效性的投票。一旦达成 lock-in，后续信号就不再改变这一流程的结果。 [2]

Versionbits 让矿工表达准备情况，但不赋予他们改写其他节点规则的权力。BIP8 使用区块高度而不是时间边界。如果 lockinontimeout 为 true，且部署尚未达到 lock-in，最后一个周期可以进入 MUST_SIGNAL，强制要求发出信号。BIP148 要求参与节点拒绝未为 SegWit 发出信号的区块；BIP91 采用较低的矿工信号阈值来协调这一过渡。如果规则执行、hashrate 和经济接受情况发生分歧，链就可能分裂。因此，激活方式的选择也涉及安全权衡。 [11] [9] [10] [17]

P2SH (BIP16) 允许把资金发往一个脚本的哈希；脚本是规定今后如何花费这些资金的程序。2012 年引入 P2SH 时，coinbase 交易中的信号帮助判断矿工是否准备好。但新的检查规则是从规定的区块时间戳边界开始执行的，信号并不代替验证。Coinbase 是区块的首笔交易，其中包含矿工报酬。 后来的升级使用区块版本和信号门槛。BIP34 要求把区块高度，也就是它在链中的位置，写入 coinbase。BIP66 收紧了 DER 签名格式，BIP65 则引入 CHECKLOCKTIMEVERIFY，检查允许花费的最早时间或高度。不断增加版本号，让相互独立的升级难以并行部署，因此 BIP9 引入了单独的比特。 2016 年，BIP68、BIP112 和 BIP113 在高度 419328 共同激活，但处理的是不同的时间条件。BIP68 引入从被花费输出获得确认起计算的相对等待期。BIP112 允许脚本通过 CHECKSEQUENCEVERIFY，简称 CSV，要求这段等待。BIP113 改变的则是绝对时间锁的时间依据：不用正在评估的区块时间戳，而采用 Median Time Past，即前 11 个区块时间戳的中位数。因此，共同激活并不意味着三项提案都在引入同一种相对时间锁。 [3] [4] [5] [6] [7] [18] [19] [20]

SegWit 于 2017 年 8 月在高度 481824 激活。它把签名等 witness 验证数据与用于计算交易标识符 txid 的部分分开。为什么这很重要？在旧编码中，有人可以改变签名的表示方式，从而改变交易标识符，却不改变收款人和金额。这种可能性称为交易延展性。仅改变 witness 数据不会改变 txid；但这种方式不会修复仍在使用旧格式的输入。 旧节点看到没有 witness 数据的交易，并把 witness v0 程序视为 anyone-can-spend。升级节点还会验证 witness 和签名摘要，也就是待签名数据的指纹。记录在 coinbase 输出中的 witness commitment 把 witness 数据与区块进行密码学绑定，让完整验证能够发现修改或遗漏。Weight 是计算区块容量占用时给数据赋予的权重；这种计算方式提高了有效容量，而旧节点能看到的基础区块仍在原来的一兆字节上限内。 [8]

Key-path 通过与输出密钥对应的签名花费，script-path 则要求满足公开脚本中的条件。Schnorr 是签名方案，Tapscript 是这些脚本使用的语言。BIP341 和 BIP342 为原生 SegWit 输出中长度为 32 字节的 witness v1 程序，定义了使用 Schnorr 签名和 Tapscript 的密钥路径与脚本路径支出规则。旧节点仍把它视为 anyone-can-spend，因此保持兼容却不完整验证。Speedy Trial 使用修改后的 BIP9，阈值 1815/2016（90%），最低激活高度 709632；Taproot 于 2021 年 11 月 14 日在该高度激活。规则内容与激活机制应分别审查。 [12] [13] [16]