协议演进 / BIP/比特币改进提案 / BIP-300
BIP-300
提出“算力托管”：侧链从主链提币不再由联盟或固定公钥集合放行，而是打包成提现束，由工作量证明在数月尺度上缓慢投票批准。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-300 |
|---|---|
| 标题 | Hashrate Escrows (Consensus layer) |
| 作者 | Paul Sztorc <[email protected]>、CryptAxe <[email protected]> |
| 指定日期 | 2017-08-14 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/300 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki |
二、放在哪一族
侧链与 Drivechain（驱动链）族的核心文档。BIP-300 与 BIP-301 是一对：BIP-300 管“钱怎么进出”——主链为每条侧链托管一笔资金，进出都走主链共识；BIP-301 管“侧链的区块由谁出”——盲合并挖矿。两者合起来构成 Drivechain 方案。
在本 BIP 之前，侧链与主链之间的双向锚定通常要靠联盟或一组固定公钥多签放行。BIP-300 要把放行权换成算力本身：提现是否成立，由矿工在很长一段时间内逐块表态决定。
相关定位：
BIP-301：盲合并挖矿，与本 BIP 配套
BIP-118：SIGHASH_ANYPREVOUT；本 BIP 的提现束哈希借用了与之类似的“盲化”思路（见第四节）
三、它要解决什么
3.1 一种由工作量证明治理提现的二层
原文开宗明义：BIP-300 启用一种新型 L2，其“提现”（L2 到 L1 的交易）由工作量证明治理，而不是由联盟或一组固定公钥治理。
设计强调提现要慢、透明、可审计：让诚实用户容易做对，让不诚实的矿工难以滥用。
3.2 两条设计目标
原文列出两条主要目标：
- 分区（partitioning）：用户可以完全忽略 BIP-300 交易；验证全部、一部分或完全不验证这些交易，对 L1 没有区别。
- 安全（security）：L2 的用户应有信心——若某个 L2 网络支付了大量手续费，矿工就会希望它存续下去，提现也因此会被准确处理。
3.3 在 L1 与 L2 之间架桥
一旦 BIP-300 在 L1 与这些 L2 之间建起“桥”，用户就可以即时地把币换入换出，只在最终结算时才动用 BIP-300。原文由此主张：比特币可以承载世界上任何形状、任何规模的交易，而完全不必改动 L1 本身。其动机部分还追溯到侧链的早期愿景：让开发者在不修改 Bitcoin Core 代码的前提下为比特币宇宙添加功能，创新可以更快、更灵活、更分布式地发生，又不失去共同平台与单一货币的协同。
四、规则本身
4.1 总览：六条消息、两张表
规范由六条区块链消息组成：
- M1：提议新侧链（Propose New Sidechain）
- M2：确认侧链提议（ACK Proposal）
- M3：提议提现束（Propose Bundle）
- M4：确认提现束（ACK Bundle）
- M5：存款——BTC 从主链转入侧链
- M6：提现——BTC 从侧链转回主链
节点把相关数据组织进两张缓存表：D1“侧链列表”（记录各托管槽位是否激活、其资金 UTXO 的位置等）与 D2“提现列表”（记录每个提现束的哈希、已获确认数与剩余区块数）。
4.2 侧链的提议与激活（M1/M2）
M1、M2 都是 coinbase 中的 OP_RETURN 输出，带各自的消息头。M1 写入侧链的序列化信息（槽位号、版本、名称、描述与两个软件哈希，原文注明这两个哈希仅供人阅读、不由 BIP-300 强制）；M2 写入该序列化的 sha256D 哈希，表示本块为该提议记一次确认。
激活要过半数算力门槛：空槽位在接下来 2016 个区块内若累计 1008 次未确认则激活失败；在用槽位（可被覆盖）在 26,300 个区块内若累计 13,150 次未确认则失败。未失败者，侧链激活。
4.3 提现为什么要“打包成束”
侧链上的单笔提现请求会先在 L2 侧定期合并成一个类 CoinJoin 的提现束（bundle）：每束最多可支付 6,000 笔提现，且每条侧链同一时间只能有一束成功。束在 L1 上只以“盲化哈希”出现——对提现交易的双重 SHA256，但其中两个字段被置零，使哈希承诺了它自己的 L1 手续费、却不承诺它的第一个输入。矿工在 3–6 个月里缓慢确认的，是这个哈希，而不是 M6 本身、更不是任何侧链数据。一束要么全额付出（经 M6），要么失败、谁也不付。
4.4 提现束的确认与生死（M3/M4）
M3 同样是 coinbase 的 OP_RETURN 输出，把束哈希与侧链槽位号写入 D2，新条目初始确认数为 1、剩余区块数为 26,299。
M4 以一个“赞成向量”逐块表态：被确认的束每块最多 +1，未获票的束 −1；另有两个虚拟选项——弃权（票数不变）与警报（所有束一律 −1）。块中没有 M4 时，视为对全部侧链弃权。D2 的规则包括：剩余区块数逐块递减、归零即移除；确认数达到 13,150 或以上，束即成功，其 M6 可以进块；数学上已不可能成功的束立即移除；已付出的束也随之移除。
4.5 存款、提现与 OP_DRIVECHAIN（M5/M6）
每条侧链的资金始终由单个 UTXO 持有（原文称 CTIP），其位置缓存在 D1 中。每次存款或提现都花掉旧 UTXO、只生成一个新 UTXO，原文强调这样不会造成 UTXO 膨胀。
- M5（存款）：花费托管输出并使金额增加的交易。有效条件是恰好有一个 OP_DRIVECHAIN 输出（成为新 CTIP），且新 CTIP 的金额大于之前。
- M6（提现）：花费托管输出并使金额减少的交易。其盲化哈希必须与已获批准的束哈希一致（即先拿到 13,150 次赞成）；第一个输出必须是 OP_DRIVECHAIN（未提走的币付回侧链成为新 CTIP）；第二个输出必须是恰好 10 字节的零值 OP_RETURN，其中 8 字节序列化一个比特币金额，且 M6 的交易费必须恰好等于该金额——这样束哈希才能覆盖 L1 手续费。
本 BIP 新增一个操作码 OP_DRIVECHAIN：由 OP_NOP5（0xb4）重定义，且仅当整个脚本恰好是“OP_DRIVECHAIN＋单字节压入（侧链编号）＋OP_TRUE”、共 4 字节时才成立；末尾的 OP_TRUE 是为了让这一改动保持软分叉性质。花费 OP_DRIVECHAIN 输入时，必须执行上述 M5/M6 的附加规则。
4.6 部署方式
原文称该软分叉可以完全不修改 Bitcoin Core 而部署（经由 CUSF 方式）；其部署条件写为：当超过 51% 算力运行其 enforcer（执行器）客户端时部署。原文同时表示，理想情况下还应有相当规模的用户运行该客户端，以强烈抑制矿工日后停用它。
五、谁必须动
普通持币人：按“分区”设计，可以完全忽略 BIP-300 交易；不使用任何侧链时，主链体验不变。想用某条侧链时，才需要把币经 M5 存入该侧链的托管。
钱包开发者：若要支持侧链存取，需识别 OP_DRIVECHAIN 托管输出、构造 M5/M6 形态的交易，并向用户如实呈现提现的漫长确认期。
全节点与矿工：这是改动最重的一方。节点要维护 D1/D2 两张表并执行 M1–M6 的有效性规则；矿工要在 coinbase 中写入 M1/M2/M3/M4，并逐块对提现束表态——提现能否成立，最终取决于矿工长达数月的投票。
共识层：本 BIP 是共识层软分叉提案：新增 OP_DRIVECHAIN 并给托管资金的进出加共识规则。未升级者按原文的分区设计仍可留在网络中，但提现的执行依赖算力与用户运行其执行器客户端。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。它没有在比特币主网上激活，不构成现行共识规则；原文给出的部署路径（算力运行执行器客户端）也未成为主网事实。本页只陈述其草案状态与原文立场：提案方认为慢速、透明、可审计的工作量证明提现优于联盟放行；这一主张是否成立、是否应激活，属于社区争论，本站不替社区下结论。
常见误读：
“BIP-300 已经让比特币有了官方侧链。”
不对。它至今仍是 Draft，既没有激活，也没有哪条“官方侧链”经它在主网上运行。把草案当成已部署功能，会误判主链今天真实的规则边界。
七、延伸
- 阅读版：https://bips.dev/300
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki
- 相关：BIP-301 盲合并挖矿、BIP-118 SIGHASH_ANYPREVOUT
- 仓库总目录：https://github.com/bitcoin/bips