分叉后同一笔交易可能在两条链上都有效，账户余额被两边同时花掉。卢克·多什 2016 年提出 BIP-115，设计 OP_CHECKBLOCKATHEIGHT 操作码，把交易绑定到特定链上某个高度的区块哈希末段。提案最终关闭从未部署。本文拆解这条锁的机制、五万块回看窗口的取舍与它想解决的双击找回难题。

比特币的 OP_CHECKMULTISIG 有个出生自带的怪癖：要多弹一个栈上哑元素，里面装什么是自由变量，任何人都能改动它而不影响签名有效性。2016 年的 BIP147 用软分叉规定这个哑元素必须是空字节，从共识层拆掉这条可延展通道。本文还原缺陷来源、哑元素为什么会泄哈希、隔离见证时代为什么仍要补这一刀。

BIP114 把一笔输出的多条解锁条件组织成默克尔树：链上只承诺一个根哈希，花币时揭示所用分支加哈希路径，其余条件不上链。本文按体积账、隐私账、计费账拆解 MAST 默克尔化抽象语法树的机制，讲清单元素五百二十字节等脚本上限怎么逼出这套设计，BIP114 为何关闭，以及 Taproot 与 Graftroot 各自接过了哪一半。

默认 SIGHASH 把签名焊死在它引用的前序输出上，通道每更新一代就得为每笔历史状态预签惩罚交易。BIP118 提议把前序引用移出签名哈希承诺，让同一份签名可以合法附着在结构相同、资金来源不同的交易上，为 eltoo 的无状态通道更新铺路。本文拆解承诺清单的构成、松绑后 eltoo 的链上两步对抗、协议自身的纪律要求，以及它停在草案状态的现实原因。

比特币脚本里的数字不是无限大整数：多数算术操作码要求操作数不超过四字节，序列化上最少只用所需字节。本文拆解脚本数字的最小化编码规则、四字节上限与十一字节序列化的张力、超出后的报错行为，以及从 OP_0 到 OP_PUSHNUM16 这段省字节的捷径设计。

比特币脚本里管理时间的两组指令：CLTV看nLockTime的绝对时刻，CSV看被花输出的成熟深度。本文讲清刻度约定、nSequence陷阱、HTLC组合方式与Miniscript的部署现状。

Pay to Contract（P2C）是Greg Maxwell在2012年提出的输出构造技巧：用一个数据承诺的哈希微调公钥，让链上看起来只是普通付款，实际暗藏一份可事后验证的声明。本文拆解tweak的构造算术、它与OP_RETURN写数据的利弊差异，以及机密地址等现代系统对这一技巧的沿用。

一笔比特币转账凭什么被认可？答案藏在脚本引擎的机械执行里：解锁脚本与锁定脚本按顺序压栈、弹出，栈顶为真即通过。本文讲清这个类Forth栈机的执行模型、真值规则、执行限制与历史事故，以及为什么比特币的脚本被刻意设计成不做循环。

比特币核心 v30 给单交易 legacy 签名操作设下 2500 上限，为 BIP54 铺路。本文拆解计数口径、历史成因、可能受影响的极端脚本与政策演进节奏的读法。

2012 年的 P2SH（BIP16）用另一套激活机制：矿工在 Coinbase 输入里投出支持字符串，官方按 2012 年 2 月 1 日前七天约百分之五十五的支持率作数，到约定时间戳起全网强制验证。本文按 BIP16 原文复盘这次特殊的激活设计与其遗留教训。