协议演进 / BIP/比特币改进提案 / BIP-74
BIP-74
提议让支付协议里的零值 OP_RETURN 输出不再被钱包忽略，好让商户不必为了附一条链上元数据而永久烧掉一笔大于粉尘的比特币。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-74 |
|---|---|
| 标题 | Allow zero value OP_RETURN in Payment Protocol |
| 作者 | Toby Padilla <[email protected]> |
| 指定日期 | 2016-01-29 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/74 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki |
二、放在哪一族
支付协议族里针对 BIP-70（Payment Protocol）的一条窄修正，与同族的 BIP-71、BIP-72、BIP-73 并列，都是围绕“商户构造 PaymentRequest、钱包照着执行”这套流程打转。
它同时牵扯 OP_RETURN 这一类数据承载输出：OP_RETURN 脚本被设计为可证明不可花费、可从 UTXO 集合中剪除，常被用来给交易附元数据。BIP-74 问的不是 OP_RETURN 本身合不合法，而是：当 OP_RETURN 出现在 PaymentRequest 里、且金额为零时，钱包该不该理它。
它的命运也写在档案里：状态 Closed，仓库附带的评论摘要为 “Unanimously Discourage for implementation”（一致不鼓励实现）。后文第六节会展开。
三、它要解决什么
3.1 零值输出被忽略，逼着人烧币
BIP-70 允许商户在 PaymentRequest 里序列化一个或多个输出，脚本可以是任意有效脚本——包括 OP_RETURN。但支付协议同时会忽略金额为零的输出。结果是：商户想在 PaymentRequest 里放一条 OP_RETURN，就必须给这个输出配一个大于粉尘（dust）的金额；交易成功执行后，这笔金额随 OP_RETURN 一起被永久销毁，再也花不回来。
换句话说，想附元数据，先烧币。这与 OP_RETURN “零值即可、本就不该承载价值”的原意正好拧着。
3.2 构造与执行被绑死，商户要碰私钥
原文还点了第二个问题：在本 BIP 之前，带零值 OP_RETURN 的交易通常要由同一套定制软件既构造又执行。若商户想在无密钥（keyless）环境里构造交易——服务器上不存公私钥——再交给顾客钱包执行，原有流程做不到。把“构造含 OP_RETURN 的 PaymentRequest”与“执行它”解耦，商户软件就不必为了签名而接触私钥，安全性更好。
设想的例子很具体：商户把一张明文发票的哈希放进 OP_RETURN，随 PaymentRequest 交给顾客钱包；钱包提交交易时把发票哈希一并上链，形成购买凭证，而钱包开发者事前完全不需要认识这家商户的应用。
四、规则本身
4.1 唯一的核心改动
规范只有一句要害，其余都是围绕它的边界条件：
脚本为 OP_RETURN 且金额为零的输出，应被钱包接受。
非 OP_RETURN 的零值脚本，继续按 BIP-70 的老规矩忽略。
4.2 多输出与零总额时怎么分钱
BIP-70 对多输出有既定处理：若各输出金额之和为零，就问顾客愿意付多少，客户端可从输出中任选若干来付款；若总和非零，顾客付总和，款项只在金额非零的输出之间分配，零值输出被忽略。
BIP-74 要求保留这套行为，只给 OP_RETURN 开例外：
- 总和为零、需由用户决定金额时，用户给的金额应分配到除 OP_RETURN 之外的输出上；
- 总和非零时，OP_RETURN 输出不应被忽略，但也不应给它分配任何金额。
4.3 至少要有一个可付输出
PaymentRequest 里必须至少含一个真正可付款的输出——不允许一份 PaymentRequest 里只有一条 OP_RETURN、没有任何收款输出。
4.4 理由（Rationale）
原文承认在链上存数据本身有争议、会带来链与网络膨胀，但认为 OP_RETURN 的折中价值在于：脚本可证明不可花费，可从 UTXO 池中剪除。若钱包不支持本 BIP，现状反而更浪费——人们会改用把大于粉尘的金额烧给一个假地址等更笨拙的编码方式。兼容性上，因为大于零的 OP_RETURN 仍受支持，原文称它与既有实现完全向后兼容。
五、谁必须动
普通持币人：不必主动做什么。若钱包实现本 BIP，付款时可能会执行带零值 OP_RETURN 的 PaymentRequest，用户付的总额不变，OP_RETURN 不分钱。
钱包开发者：这是主要动作方。要改 BIP-70 的输出处理：识别 OP_RETURN + 零值这一组合并予以保留执行，同时守住 4.2、4.3 的分配与下限规则；其余零值输出仍忽略。
商户与应用开发者：受益方。可在不存私钥的服务器上构造带 OP_RETURN 元数据的 PaymentRequest，交给钱包执行。
全节点与矿工：不涉及。OP_RETURN 输出的上链与剪除是既有行为，本 BIP 只改钱包如何处理 PaymentRequest，不改共识与转发规则。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭），且仓库记录的评论摘要是 “Unanimously Discourage for implementation”——一致不鼓励实现。也就是说，它停留在提案层：写清了一个真实存在的小别扭（为附元数据而烧币），给出了一句式的修正，但没有成为应照着实现的现行规范。读它应按“一段被留档、已被关掉的讨论”来读，不要拿它当钱包行为的依据。
常见误读：
“BIP-74 是在鼓励往区块链上塞数据。”
不对。原文的立场是折中而非鼓吹：它明说链上存数据有争议、膨胀是真实问题，主张的只是——既然 OP_RETURN 这条可剪除的通道已经存在，就不要让支付协议的零值忽略规则逼人改走烧币、假地址等更浪费的路子。提案最终被关闭、且评论一致不鼓励实现，也说明社区没有接受这条折中。