BIP 81：Colored Voting Pool 层级方案为何关闭

本文只讨论 Bitcoin 技术机制、工程实现和生态基础设施，不讨论炒币、交易策略或投资建议。

BIP 81 的官方标题是 Hierarchy for Colored Voting Pool Deterministic Multisig Wallets，作者是 Justus Ranvier, Jimmy Song，Layer 是 未单独标注 Layer，类型是 Informational，状态是 Closed，编号分配日期是 2014-08-11。官方状态是 Closed，说明它已经不应作为当前推荐实现，阅读价值主要在历史脉络和方案取舍。

这篇文章只从技术角度解读它的设计目标：描述带 Colored 场景的 Voting Pool 确定性多签层级，但该文档已关闭。

发生了什么

彩色 Voting Pool 层级 是 Bitcoin 协议或钱包生态中的具体工程问题。BIP 81 把这个问题整理成公开文档，让不同客户端、钱包、节点或工具可以围绕同一组术语讨论实现边界。

它的意义不在于编号顺序，而在于它记录了一个可验证的技术切面。对 Deployed 文档，要看它如何进入当前软件行为；对 Draft 文档，要强调草案状态；对 Closed 文档，要说明它的历史价值而不是误导实现。

技术机制是什么

它延续 BIP 80 的层级思路，并加入 Colored 资产语义。

这类应用层语义不会改变 Bitcoin 节点的基础验证规则。

Closed 状态说明它更多用于理解历史方案，而非当前推荐路径。

从实现视角看，BIP 81 的关键是分清层级。应用层文档主要影响钱包、地址、密钥和用户界面；Peer Services 文档影响节点间消息；共识层文档则会影响区块或脚本验证规则。不同层级的风险半径完全不同。

对开发者和节点运营者意味着什么

实现方不应把 BIP 81 当成现代钱包互操作标准。若处理特定资产语义，需要清楚区分链上脚本和应用层解释。

实际落地时，开发者还要回到官方原文，确认字段名称、编码要求、状态说明和替代关系。尤其是 Draft 和 Closed 文档，不能因为编号存在就自动进入新实现；Deployed 文档也不能脱离具体客户端版本和当前代码路径单独判断。

风险、限制和误区

误区是把应用层颜色语义当成节点共识。Bitcoin 节点验证的是脚本和 UTXO，不验证外部资产解释。

另一个常见误区，是把 BIP 当作强制命令。BIP 是公开技术文档，不同状态代表不同生命周期位置。是否需要实现、如何实现、是否仍然适用，都必须结合 Status、Layer、Type、后续替代文档和实际软件行为判断。

写公众号内容时还要避免把技术规范包装成情绪化结论。本文只讨论协议、接口、脚本、钱包或节点实现，不引导任何非技术判断。

接下来该看什么

建议回到当前钱包路径、PSBT 和多签规范，理解哪些语义是协议层，哪些只是应用层。

更实用的阅读方法，是先看 BIP 元数据，再看 Motivation 和 Specification，最后看它和相邻主题的关系。这样可以避免只按编号顺序阅读造成的误解。

本文结论只限技术讨论，不构成任何买卖、持仓或收益判断。