加密货币百科

BIP-442 提议给 tapscript 加入 OP_PAIRCOMMIT，用带标签的哈希把栈顶两个元素安全地绑成一个承诺。两个原语叠加就能承诺任意多个元素。本文解释它如何省字节、如何支撑闪电对称合约，以及它替代的关键梯方案贵在哪。

BIP-138 为描述符、钱包策略这类不含私钥的钱包元数据定义一套紧凑加密格式：密钥从描述符自身公钥推导，加密后仍可被任意持钥人解密。本文解释它防什么泄露、格式里的字段取舍，以及边界在哪。

BIP-449 想把 Taproot 输出密钥背后的椭圆曲线加法搬进 tapscript：给一把钥匙和一个标量，脚本自己算出调整后的公钥。本文解释曲线加法的性质、它的失败条件，以及密钥揭示与签名顺序证明这些新玩法。

BIP-33 在 2012 年提出分层节点：用 NODE_SERVICE 与 NODE_STRATIZED 两个新服务位，让轻量客户端将区块链查询委托给专职节点。本文回溯它与 BCCAPI、Electrum、Stratum 的承继关系，以及四个新查询消息的设计。

BIP-36 给 version 消息加了 service_count 与 service_list 字段，让节点用字符串名字申报自定义服务，避免抢占稀缺的 64 位 services 位图。本文拆解服务名、服务版本、service_data 三条规则，以及转正为 NODE_* 常数的路径。

BIP-46 为创建时间锁保真债券（fidelity bond）定义了 HD 钱包派生方案，让抗女巫身份的成本来自锁仓的时间价值。本文拆解它的派生路径设计、证书签名建议，以及冷存储下的找回边界。

BIP-37 把 relay 标志作为可选字段塞进 version 消息，BIP-60 则主张把每个协议版本的消息恢复成固定字段数。本文解释可选字段为什么破坏反序列化纪律，以及 relay 布尔值最终长在哪两个字段之间。

BIP-89 的链码委托让多签中的受托方保管 BIP32 链码,委托方只拿普通密钥加逐笔标量调整值即可签名,合作托管时一方查不到另一方的余额与派生活动。本文讲清角色定义、调整值交换与信任边界。

BIP-122 定义了 blockchain: 前缀的 URI 方案，用链 ID、对象类型和哈希三段引用区块、交易与地址，让钱包和帖子链接把选择浏览器的权利留给用户。本文拆解它的语法、链 ID 的创世块定义与现状。

BIP-132 在 2015 年尝试给 BIP 提案定一个通过流程：按客户端、矿工、商户、用户四个分段组委员会，各方代表至少百分之一生态份额，四段中三段达成七成共识才算接受。本文复盘它的流程设计与落选原因。