协议演进 / BIP/比特币改进提案 / BIP-199
BIP-199
为链下合约协商定义一种哈希时间锁定合约（HTLC）脚本：出示哈希原像即可收款，超时未出示则可退款。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-199 |
|---|---|
| 标题 | Hashed Time-Locked Contract transactions |
| 作者 | Sean Bowe <[email protected]>、Daira Hopwood <[email protected]> |
| 指定日期 | 2017-03-27 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/199 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki |
二、放在哪一族
脚本合约族，处在“用脚本条件换取原子性”的源头位置。BIP-199 把哈希时间锁定合约（Hashed Time-Locked Contract，HTLC）写成一份可复用的脚本模板：同一个哈希条件串起多笔支付，秘密一经公开，所有环节同时结算；秘密不公开，则各笔资金按超时各自退回。
它依赖的时间锁原语来自更早的提案：
BIP-65：OP_CHECKLOCKTIMEVERIFY，绝对时间锁
BIP-112：OP_CHECKSEQUENCEVERIFY，相对时间锁
原文明确点出的两大应用场景，是闪电网络的跨通道支付与零知识或有支付（Zero-knowledge contingent payments）。今天谈闪电网络的路由支付、原子交换时反复出现的 HTLC，脚本骨架正出自这一族。理解 BIP-199，是理解“为什么链下支付可以做到要么全成、要么全退”的起点。
三、它要解决什么
3.1 用秘密换钱，需要一条安全的结算通道
许多链下协议把“披露秘密”当作结算机制的一部分；在另一些协议里，秘密本身就是有价值的商品。问题在于：买方先付钱，卖方不交秘密怎么办？卖方先交秘密，买方不付钱又怎么办？
原文的回答是：HTLC 交易提供了一种安全而廉价的“以链换秘密”的方法——持有秘密的一方能在退款发生之前先拿到资金；对方不配合时，付款方也能把资金收回。交易不必做大、验证成本也不必做高。
3.2 闪电网络中的原子交换
原文以闪电网络为例：通道之间用 HTLC 脚本做原子交换。Alice 构造秘密 K 并哈希得到 L，她向 Bob 发起一笔“凭 L 的原像领取”的 HTLC 支付；Bob 再向 Carol 发起同一原像、同一金额的 HTLC 支付。
只有当 Alice 释放原像 K 时，价值交换才真正发生；秘密在每一跳被披露，各方随之得到补偿。任何一环不配合，流程都可以经由退款条件中止。
3.3 零知识或有支付
原文还举了零知识证明的用法：用零知识证明保证某个哈希原像确实能解出有价值的信息——例如，它是某个加密数独题解的解密密钥。HTLC 可以无风险地把这类解密密钥换成钱，且不需要体积大、验证昂贵的交易。
四、规则本身
4.1 脚本模板
HTLC 允许指定的一方（“卖方”）通过披露某个哈希的原像来花费资金；也允许第二方（“买方”）在超时到达后花费资金，即退款情形。脚本形式为：
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
其中两个占位符可替换：
- [HASHOP]：OP_SHA256 或 OP_HASH160；
- [TIMEOUTOP]：OP_CHECKSEQUENCEVERIFY 或 OP_CHECKLOCKTIMEVERIFY。
两个分支最终汇合到同一段公钥哈希校验与 OP_CHECKSIG：无论走哪条路，花费者都必须是对相应公钥有签名权的人，区别只在附加条件——出示原像，或等到超时。
4.2 交互流程
原文以 Victor（买方）与 Peggy（卖方）为例：
- 双方交换公钥，共同商定超时阈值；Peggy 给出哈希摘要。双方据此构造脚本与 P2SH 地址；
- Victor 把资金打入该 P2SH 地址；
- 接下来二选一：Peggy 花费资金，并在交易中把原像揭示给 Victor；或者 Victor 在超时阈值到达后收回资金。
4.3 超时取值的博弈
超时长短对双方利益相反，原文专门点明：Victor 希望超时短一些，缩短 Peggy 不揭示原像时资金被占用的时间；Peggy 希望超时长一些，降低自己来不及在阈值前花费资金的风险——更糟的情形是，她的花费交易没能赶在 Victor 的退款之前上链，却已经把原像泄露给了 Victor。
4.4 实现
原文给出的实现指向 Bitcoin Core 的一笔合并请求（bitcoin/bitcoin#7601）。脚本本身只用到既有操作码与 P2SH，不新增共识规则。
五、谁必须动
普通持币人：不直接接触脚本模板。使用闪电网络或原子交换产品时，由钱包与协议软件代为构造 HTLC。
钱包开发者：若要支持 HTLC 类协议，需能按模板构造 P2SH 脚本、处理原像的生成与保管，并正确设置超时分支；超时参数直接关系到资金被占用的时长与被抢先退款的风险，须给用户留出安全余量。
全节点与矿工：无需改动。脚本只组合既有操作码，按现有共识与标准性规则验证即可。
共识层：本 BIP 不修改共识规则。它是一份脚本规范，把 CLTV/CSV 等既有原语组装成通用合约形状。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。这表示这份文档在 BIP 仓库中的流程已经关闭，不再作为一份推进中的规范维护；它不表示 HTLC 这种机制“被否决”或“不能用”——恰恰相反，HTLC 的思想已成为闪电网络等链下协议的基础构件，只是具体的脚本构造在各协议内部有各自的规范与演进，不再回指这一份文档。读它应作历史与原理读本：看清“哈希锁＋时间锁”如何拼出原子性。
常见误读：
“BIP-199 状态是 Closed，所以 HTLC 已经被淘汰了。”
不对。Closed 说的是文档流程的终点，不是技术的判决。原文自己就把闪电网络列为首要应用场景；HTLC 作为机制长期存续，只是后续实现各有自己的规范文本，本 BIP 不再承担“现行标准”的角色。
七、延伸
- 阅读版：https://bips.dev/199
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki
- 相关：BIP-65 OP_CHECKLOCKTIMEVERIFY、BIP-112 OP_CHECKSEQUENCEVERIFY
- 仓库总目录：https://github.com/bitcoin/bips