-
@ yr
2025-05-05 14:49:02PR 32359：取消 OP_RETURN 字节限制提案深入分析
提案概述及代码变更内容
提案背景与意图：比特币核心当前对交易中的 OP_RETURN 输出（数据载体输出）有严格限制：默认最多允许单个 OP_RETURN 输出，且其
scriptPubKey大小不超过 83 字节（约80字节数据加上OP_RETURN和Pushdata前缀）groups.google.com。这一标准规则旨在轻度阻碍链上存储大量任意数据，鼓励将非金融数据以“更无害”的方式存入链上（比如用OP_RETURN而非可花费的UTXO输出）groups.google.com。然而随着时间推移，这一限制并未阻止用户将数据写入区块链，反而促使开发者设计各种变通方案绕过限制。例如，近期 Citrea Clementine 协议（闪电网络相关项目）因为OP_RETURN容量不足，而改用不可花费的Taproot输出来存储所需数据groups.google.com。这样的做法导致大量小额UTXO留存在UTXO集，对全节点造成负担，被视为比使用OP_RETURN更有害的副作用github.com。基于此背景，Bitcoin Core 开发者 Peter Todd（与 Chaincode 实验室的 Antoine Poinsot 等人）提出了 PR #32359，意在解除OP_RETURN的字节大小限制，以消除这种“适得其反”的限制策略groups.google.comgithub.com。**代码变更要点：**该PR主要修改了与标准交易校验和策略配置相关的代码，包括移除
script/standard.cpp中对OP_RETURN输出大小和数量的检查，以及删除策略配置选项-datacarrier和-datacarriersizegithub.com。具体而言：-
取消OP_RETURN大小限制：删除了判断OP_RETURN数据长度是否超过 MAX_OP_RETURN_RELAY（83字节）的标准性检查。此后，交易中的OP_RETURN输出脚本长度将不再被固定上限限制，只要满足区块重量等共识规则即可（理论上可嵌入远大于83字节的数据）github.comgroups.google.com。PR说明中明确提到移除了这些限制的执行代码github.com。相应地，
-datacarriersize配置参数被删除，因为其存在意义（设置OP_RETURN字节上限）已不复存在github.com。此前-datacarriersize默认为83，当用户调高该值时节点可接受更大数据载体输出；而现在代码中已无此参数，节点将无条件接受任意大小的OP_RETURN输出。 -
移除OP_RETURN输出数量限制：原先比特币核心默认策略还规定每笔交易最多只有一个OP_RETURN输出是标准的，多于一个即视为非标准交易（拒绝中继）bitcoin.stackexchange.com。该PR同样意在取消此“任意”限制groups.google.com。修改中移除了对
nDataOut（OP_RETURN输出计数）的检查，即允许一笔交易包含多个OP_RETURN输出而仍被视作标准交易。之前的代码若检测到nDataOut > 1会返回“multi-op-return”的拒绝原因github.com；PR删除了这一段逻辑，相应的功能测试也更新或移除了对“multi-op-return”非标准原因的断言github.com。 -
保留标准形式要求：值得注意的是，OP_RETURN输出的形式要求仍保留。PR描述中强调“数据载体输出的形式仍保持标准化：脚本以单个 OP_RETURN 开头，后跟任意数量的数据推字节；不允许非数据类的其他脚本操作码”github.com。也就是说，虽然大小和数量限制解除了，但OP_RETURN脚本内容只能是纯数据，不能夹带其他执行opcode。这保证了这些输出依然是“不可花费”的纯数据输出，不会改变它们对UTXO集的影响（不会增加UTXO）。
综上，PR #32359 的核心改动在策略层面放宽了对 OP_RETURN 的限制，删除了相关配置和检查，使节点默认接受任意大小、任意数量的 OP_RETURN 数据输出。同时维持其基本形式（OP_RETURN+数据）以确保此变更不会引入其它类型的非标准交易格式。
改动层级：策略规则 vs 共识规则
该提案属于策略层（policy-level）的更改，而非共识层规则的更改。也就是说，它影响的是节点对交易的_中继、存储和打包_策略，而不改变交易或区块在链上的有效性判定。OP_RETURN字节上限和数量限制从一开始就是标准性约束（Standardness），并非比特币共识协议的一部分groups.google.com。因此，移除这些限制不会导致旧节点与新节点产生区块共识分歧。具体理由如下：
-
无共识规则变动：原有的83字节上限只是节点默认_拒绝转发/挖矿_超限交易的规则，但如果矿工强行将超83字节的OP_RETURN交易打包进区块，所有遵循共识规则的节点（包括未升级的旧节点）依然会接受该区块。因为共识层并没有“OP_RETURN大小不得超过83字节”的规定github.com。正如开发者所指出的，现行的OP_RETURN限制属于“standardness rules”，其约束可以被轻易绕过，并不影响交易的最终有效性github.com。Peter Todd 在评论中强调，为真正禁止链上发布任意数据，必须修改比特币的共识协议，而这在现实中几乎不可能实施github.com。
-
**旧节点兼容性：**由于没有引入新的脚本opcode或共识验证规则，旧版本节点即使不升级，仍然会承认包含大OP_RETURN输出的区块为有效。换言之，不存在分叉风险。旧节点唯一的区别是仍会按照老策略拒绝中继此类交易，但一旦交易被打包进区块，它们仍会接受github.com。正因如此，这一提议不会引发硬分叉，只是改变默认策略。
-
**策略可自行定制：**另外，正如PR作者所言，这纯粹是默认策略的调整，用户依然可以选择运行修改版的软件继续实施先前的限制。例如，Peter Todd提到有替代实现（如 Bitcoin Knots）可以继续强制这些限制github.com。因此，这并非要“强制”所有节点解除限制，而是主流软件默认策略的演进。
需要澄清的是，有反对者担心解除限制可能扩大攻击面（下文详述），但这些都是针对节点资源和网络层面的影响，而非共识层安全性问题。总的来看，PR #32359 是策略层改进，与先前如RBF默认开启、逐渐弱化非标准交易限制等改变类似，其出发点在于网络行为而非协议规则本身。
对闪电网络节点和交易验证的影响
对链上验证的影响：由于这是策略层变更，交易和区块的验证规则并未改变，因此运行旧版本 Bitcoin Core 的闪电网络节点在共识上不会出现任何问题。闪电网络全节点通常依赖比特币全节点来跟踪链上交易，它们关心的是交易确认和共识有效性。解除OP_RETURN限制并不会使旧节点拒绝新区块，因而不会造成闪电通道关闭交易或HTLC交易在旧节点上验签失败等情况。换句话说，不升级Bitcoin Core软件的LN节点仍可正常参与链上共识，无需担心链上交易验证兼容性。
对节点中继和资源的影响：主要影响在于网络传播和资源占用。如果闪电网络节点所连接的Bitcoin Core没有升级，它将不会中继或存储那些含有超大OP_RETURN的未确认交易（因为旧版本视之为非标准交易）。这可能导致未升级节点的内存池与升级节点不一致：某些在新版节点中合法存在的交易，在旧版中被拒之门外。不过这通常不影响闪电网络的运行，因为闪电通道相关交易本身不会包含OP_RETURN数据输出。此外，当这些交易被矿工打包进区块后，旧节点依然会接收到区块并处理。所以，即便LN节点的后端Bitcoin Core未升级，最坏情形只是它在交易未打包时可能感知不到这些“大数据”交易，但这通常无碍于闪电网络功能（闪电网络主要关心的是通道交易的确认情况）。
升级的好处和必要性：从闪电网络生态来看，放宽OP_RETURN限制反而可能带来一些正面作用。正如前述，已有闪电网络周边项目因为83字节限制不足，转而使用不可花费输出存储数据groups.google.com。例如 Antoine Poinsot 在邮件列表中提到的 Clementine 协议，将某些watchtower挑战数据存进Taproot输出，因为OP_RETURN容量不够groups.google.com。解除限制后，此类应用完全可以改用更友好的OP_RETURN输出来存储数据，不再制造永久占据UTXO集的“垃圾”UTXOgithub.com。因此，闪电网络的watchtower、跨链桥等组件若需要在链上写入证据数据，将可直接利用更大的OP_RETURN输出，网络整体效率和健壮性都会提升。
需要注意的是，如果PR最终被合并并广泛部署，闪电网络节点运营者应该升级其Bitcoin Core后端以跟上新的默认策略。升级后，其节点将和大多数网络节点一样中继和接受大OP_RETURN交易，确保自己的内存池和网络同步，不会漏掉一些潜在相关交易（尽管目前来看，这些交易对LN通道本身并无直接关联）。总之，从兼容性看不升级没有致命问题，但从网络参与度和功能上看，升级是有益的。
潜在的间接影响：反对者提出，解除限制可能导致区块和内存池充斥更多任意数据，从而推高链上手续费、影响闪电通道关闭时所需的手续费估计。例如，如果大量大OP_RETURN交易占据区块空间，链上拥堵加剧，LN通道关闭需要支付更高费用才能及时确认。这其实是一般性拥堵问题，并非LN特有的兼容性问题。支持者则认为，这正是自由市场作用的体现，使用链上空间就该竞争付费github.com。无论如何，闪电网络作为二层方案，其优势在于减少链上交互频率，链上手续费市场的变化对LN有影响但不改变其运行逻辑。LN节点只需确保其Bitcoin Core正常运行、及时跟上链上状态即可。
开发者讨论焦点：支持与反对观点
PR #32359 在开发者社区引发了激烈讨论，支持者和反对者针锋相对，各自提出了有力的论据。以下总结双方主要观点：
-
支持方观点：
-
当前限制无效且适得其反：支持者强调83字节上限并未阻止人们在链上存数据，反而促使更有害的行为。Peter Todd指出，很多协议改用不可花费UTXO或在
scriptsig中藏数据来绕过OP_RETURN限制，结果增加了UTXO集膨胀，这是限制OP_RETURN带来的反效果github.com。与其如此，不如移除限制，让数据都写入可被丢弃的OP_RETURN输出，避免UTXO污染github.comgithub.com。正如一位支持者所言：“与其让尘埃UTXO永远留在UTXO集合，不如使用可证明不可花费的输出（OP_RETURN）”github.com。 -
**限制易被绕过，增添维护负担：**由于有些矿工或服务商（如MARA Slipstream私有广播）本就接受大OP_RETURN交易，这一限制对有心者来说形同虚设github.com。同时，存在维护这个限制的代码和配置选项，增加了节点实现复杂度。Todd认为，与其让Bitcoin Core承担维护“低效甚至有害”的限制，不如干脆取消，有需要的人可以使用其他软件实现自己的政策github.com。他提到有替代的Bitcoin Knots节点可自行过滤“垃圾”交易，但没必要要求Bitcoin Core默认坚持这些无效限制github.com。
-
尊重自由市场，拥抱链上数据用例：部分支持者从理念上认为，比特币区块空间的使用应交由手续费市场决定，而不应由节点软件做人为限制。著名开发者 Jameson Lopp 表示，是时候承认“有人就是想用比特币做数据锚定”，我们应当提供更优方式满足这种需求，而不是一味阻碍github.com。他认为用户既然愿意付费存数据，就说明这种行为对他们有价值，矿工也有动力处理；网络层不应进行过度的“父爱”式管制github.com。对于反对者所称“大数据交易会挤占区块、抬高手续费”，Lopp直言“这本来就是区块空间市场运作方式”，愿付高费者得以优先确认，无可厚非github.com。
-
统一与简化策略：还有支持者指出，既然限制容易绕过且逐渐没人遵守，那保留它只会造成节点之间策略不一致，反而增加网络复杂性。通过取消限制，所有核心节点一致地接受任意大小OP_RETURN，可避免因为策略差异导致的网络孤块或中继不畅（尽管共识不受影响，但策略不一致会带来一些网络层问题）。同时删除相关配置项，意味着简化用户配置，减少困惑和误用。Peter Todd在回应保留配置选项的建议时提到，Bitcoin Core在Full-RBF功能上也曾移除过用户可选项，直接默认启用，因为现实证明矿工最终都会朝盈利的方向调整策略，节点自行设置反而无济于事github.com。他以RBF为例：在Core开启默认Full-RBF之前，矿工几乎已经100%自行采用了RBF策略，因此保留开关意义不大github.com。类比来看，数据交易也是如此：如果有利可图，矿工终会打包，无论节点是否选择不转发。
-
反对方观点：
-
去除限制会放松对垃圾交易的防线：反对者担心，一旦解除OP_RETURN限制，链上将出现更多纯粹存储数据的“垃圾”交易，给网络带来DoS攻击和资源消耗风险。开发者 BrazyDevelopment 详细描述了可能被加剧的攻击向量github.com：首先，“Flood-and-Loot”攻击——攻击者构造带有巨大OP_RETURN数据的低价值交易（符合共识规则，多笔交易可达数MB数据），疯狂填充各节点的内存池。github.com这样会占满节点内存和带宽，延迟正常交易的传播和确认，并推高手续费竞争。github.com虽然节点有
maxmempool大小限制和最低中继费率等机制，但这些机制基于常规交易行为调校，面对异常海量的数据交易可能捉襟见肘github.com。其次，“RBF替换循环”攻击——攻击者可以利用无需额外费用的RBF替换，不断发布和替换包含大OP_RETURN的数据交易，在内存池中反复占据空间却不被确认，从而扰乱手续费市场和内存池秩序github.com。反对者认为，移除大小上限将使上述攻击更廉价、更容易实施github.com。他们主张即便要放宽，也应设定一个“高但合理”的上限（例如100KB），或在内存池压力大时动态调整限制，以保护较小资源节点的运行github.com。 -
用户丧失自定义策略的权利：一些开发者反对彻底删掉
-datacarrier和-datacarriersize选项。他们认为即使大势所趋是接受更多数据，也应保留用户自主选择的空间。正如开发者 BitcoinMechanic 所言：“矿工接受大数据交易不代表用户就不能选择自己的内存池装些什么”github.com。目前用户可以通过配置将-datacarrier设为0（不中继OP_RETURN交易）或者调低-datacarriersize来严格限制自己节点的策略。直接去除这些选项，会让那些出于各种考虑（如运营受限资源节点、防范垃圾数据）的用户失去控制权。从这个角度看，反对者认为限制应该由用户 opt-in 地解除，而不是一刀切放开。开发者 Retropex 也表示：“如果矿工想要更大的数据载体交易，他们完全可以自行调整这些设置…没有理由剥夺矿工和节点运营者做选择的权利”github.com。 -
此改动非必要且不符合部分用户利益：有反对意见认为当前83字节其实已经能覆盖绝大多数合理应用需求，更大的数据上链并非比特币设计初衷。他们担心放开限制会鼓励把比特币区块链当作任意数据存储层，偏离“点对点电子现金”主线，可能带来长期的链膨胀问题。这一阵营有人将此争议上升为理念之争：是坚持比特币作为金融交易为主，还是开放成为通用数据区块链？有评论形容这场拉锯“有点类似2017年的扩容之争”，虽然本质不同（一个是共识层区块大小辩论，一个是策略层数据使用辩论），但双方观点分歧同样明显99bitcoins.com99bitcoins.com。一些反对者（如Luke Dashjr等）长期主张减少非必要的数据上链，此次更是明确 Concept NACK。Luke-Jr 认为，其实完全可以通过引入地址格式变化等办法来识别并限制存数据的交易，而不需要动用共识层改动github.com（虽然他也承认这会非常激进和不现实，但以此反驳“除了改共识无计可施”的观点）。总之，反对者倾向于维持现状：代码里已有的限制无需移除，至少不应在无压倒性共识下贸然改变github.com。
-
社区共识不足：许多开发者在GitHub上给出了“Concept NACK”（概念上不支持）的评价。一位参与者感叹：“又来？两年前讨论过的理由现在依然适用”github.com。在PR的Review日志中，可以看到反对此提案的活跃贡献者数量明显多于支持者github.com。例如，反对阵营包括 Luke-Jr、BitcoinMechanic、CryptoGuida、1ma 等众多开发者和社区成员，而支持此提案的核心开发者相对少一些（包括Jameson Lopp、Sjöors、Sergio Demian Lerner等）github.com。这种意见分裂显示出社区对取消OP_RETURN限制尚未达成广泛共识。一些反对者还担忧这么大的改动可能引发社区矛盾，甚至有人夸张地提到可能出现新的链分叉风险99bitcoins.com99bitcoins.com（虽然实际上由于不涉及共识，硬分叉风险很小，但社区内部分歧确实存在）。
综上，支持者聚焦于提高链上效率、顺应实际需求和减轻UTXO负担，认为解除限制利大于弊；而反对者强调网络稳健、安全和用户自主，担心轻易放开会招致滥用和攻击。双方在GitHub上的讨论异常热烈，很多评论获得了数十个👍或👎表态，可见整个社区对此议题的关注度之高github.comgithub.com。
PR当前状态及后续展望
截至目前（2025年5月初），PR #32359 仍处于开放讨论阶段，并未被合并。鉴于该提案在概念上收到了众多 NACK，缺乏开发者间的明确共识，短期内合并的可能性不大。GitHub 上的自动统计显示，给予“Concept NACK”的评审者数量显著超过“Concept ACK”的数量github.com。这表明在Bitcoin Core维护者看来，社区对是否采纳此改动存在明显分歧。按照 Bitcoin Core 一贯的谨慎作风，当一个提案存在较大争议时，通常会被搁置或要求进一步修改、讨论，而不会仓促合并。
目前，该PR正等待进一步的评审和讨论。有开发者提出了替代方案或折中思路。例如，Bitcoin Core维护者 instagibbs 提交了相关的 PR #32406，提议仅取消默认的OP_RETURN大小上限（等效于将
-datacarriersize默认提高到极大），但保留配置选项，从而在不牺牲用户选择权的情况下实现功能开放github.com。这表明部分反对者并非完全拒绝放宽限制，而是希望以更温和的方式推进。PR #32359 与这些提案互相冲突，需要协调出统一的方案github.com。另外，也有开发者建议在测试网上模拟大OP_RETURN交易的攻击场景，以评估风险、说服怀疑者github.com。审议状态总结：综合来看，PR #32359 尚未接近合并，更谈不上被正式接受进入下一个Bitcoin Core版本。它既没有被关闭（拒绝），也没有快速进入最终review/merge阶段，而是停留在激烈讨论中。目前Bitcoin Core的维护者并未给出明确的合并时间表，反而是在鼓励社区充分讨论其利弊。未来的走向可能有几种：要么提案经过修改（例如保留配置项、增加安全机制等）逐渐赢得共识后合并，要么维持搁置等待更明确的社区信号。此外，不排除开发者转而采用渐进路线——例如先在测试网络取消限制试验，或先提高上限值而非彻底移除，以观察效果。也有可能此提案最终会因共识不足而长期悬而不决。
总之，OP_RETURN字节限制之争体现了比特币开发中策略层决策的审慎和平衡：需要在创新开放与稳健保守之间找到折衷。PR #32359 所引发的讨论仍在持续，它的意义在于促使社区重新审视链上数据存储的策略取舍。无论最终结果如何，这一讨论本身对比特币的发展具有积极意义，因为它让开发者和社区更加清晰地权衡了比特币作为数据载体和价值载体的定位。我们将持续关注该提案的进展，以及围绕它所展开的进一步测试和论证。github.comgroups.google.com
引用来源：
-
Bitcoin Core PR #32359 提案内容github.comgithub.com及开发者讨论（Peter Todd评论github.comgithub.com等）
-
Bitcoin Dev 邮件列表讨论帖：《Relax OP_RETURN standardness restrictions》groups.google.comgroups.google.com
-
GitHub 开发者评论摘录：支持意见（Jameson Loppgithub.com等）与反对意见（BitcoinMechanicgithub.com、BrazyDevelopmentgithub.com等）
-
Bitcoin Core PR 评论自动统计（Concept ACK/NACK 汇总）github.com
-