From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 02:45:42 -0700 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vE2kP-0002Jc-5X for bitcoindev@gnusha.org; Wed, 29 Oct 2025 02:45:42 -0700 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-44dabe580ebsf943337b6e.3 for ; Wed, 29 Oct 2025 02:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761731135; x=1762335935; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=xZu1uJslXJdfWXz2+MPE+yHyECVlFbVW3oVSPEioeFs=; b=M6j56YpOHfjSU1PxkzECI4Y9S4ZulDxTrlH7nfi80bXj3k988GQa4zmoINjajqrns6 gbKmW6Wm0dHpY/gg/D0YFLxB++3GRcyouig0jscMXK0fO4W7ZKa3Hp0ZyRS/ybBRTQiU AAfcyKl/b6TfoKIZFg0HV3qfgN6hkr3cfVMMUgftoVNnM9llDlgDQthyEtKMBH5dnl2J GCKXFnrvtm9UmV7j8zOG3hF/ydc2dn+HVnEmY0rtEAK8dIOcKLNqxw6Ypx7pjF2xynbR l6wwfGkgrLeESH7MGG19OtLy4OHyvo3d9PFuDVSdyeNkRufbiGVwDHKUr+AX7OurYdf3 ztkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761731135; x=1762335935; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=xZu1uJslXJdfWXz2+MPE+yHyECVlFbVW3oVSPEioeFs=; b=HAn1LUJer6hh8JH9OHWoIOHEkZ+yeR8iVW+SYY/Dm2oWhjuMJSSQyckjWWO3Z4C7ub kTIYpTtGTs2kwAXl2wUBre8d/ky7stTSa3bL/jpsWAb4+62JphDzkKJ0m3SGwSpgogc/ 5Zy2Q3gWy6nRmaEHDIKd/ag9tCnQv+4DnAKXLreq3WNv1OL7yFntJ7TiYnavA6uD/MKX dP5n7fqsQEaRKz9FVSyB/1RzjMinyG14j1/oI2omM5VPoH8QUQseldTwDxr80eaMUag8 ER1oQyzHVEyurVeaehLm/jrZ280zsdu5SqENJJojhzp8wANpykse2Oons0M/PtOY4/nl 1ZkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761731135; x=1762335935; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=xZu1uJslXJdfWXz2+MPE+yHyECVlFbVW3oVSPEioeFs=; b=Id7ERATayJMXqz95imYNRq/tN+YatBmiUguTR3v3Wmo2s5AgqSbPR+gO7ANKd0Tn4H ASF9j51M9TsMxFx1KTzodjnjiDBwld24irVTKoNIiELv1sluPaWpBCKcxG+wQz+fXuJ1 u++oYNekHQxPU8VEe7LxJnLh5nT0hGD9rqIb09RgY1Png2ASg+jlu3fHsNBUgH3gF67k A7VB1/0M5zaNqM99azH+r0sLpX5YGBZfNJSk1ffGZlO5Cq91eqT1ySJRKIYi7Xpw3RK4 YuHdaoS8jvlZl6rDl+yTKpfUuID/78Xjd6pYEiPv0xt7oawP+F2yP0ovpT6Pg0wX/TLk B4EQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUUh2RS+sC1nccEANKWT4nujpiS5BVGKmL4lpexVcTyjqz5Ap3qmPlVIDcqaVy8hR087PDD4urpsHaV@gnusha.org X-Gm-Message-State: AOJu0Yx5Ie+/UwNXqxItU+0ETMTWNbh9hFadTI65Q//nYgBGBXKI9OPZ eg6RiF0J5E4dGe4KXMsk6I+IdoZbLe8ek9Bbr+JUYo+VazNppuMCNBJr X-Google-Smtp-Source: AGHT+IEk0p8gs0XGLCcsxCGMD7oTKyUHxagIqJ8b7aKUZyOEXX3xvY/MH7ItQ9mcJ1FbyWeEL8waUQ== X-Received: by 2002:a05:6808:2113:b0:44d:a783:db9b with SMTP id 5614622812f47-44f7a4251f2mr1318909b6e.12.1761731134365; Wed, 29 Oct 2025 02:45:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Z91ku0T5DTO0VejY2LJ82HuXrsKOh2YBCOJJRgXmnrRQ==" Received: by 2002:a05:6871:3a11:b0:3d1:fb8f:5574 with SMTP id 586e51a60fabf-3d1fb8f599els1556176fac.2.-pod-prod-02-us; Wed, 29 Oct 2025 02:45:29 -0700 (PDT) X-Received: by 2002:a05:6808:13c4:b0:441:8f74:f34 with SMTP id 5614622812f47-44f7a542f00mr1151195b6e.62.1761731129455; Wed, 29 Oct 2025 02:45:29 -0700 (PDT) Received: by 2002:a05:690c:6d91:b0:780:f7eb:fdf with SMTP id 00721157ae682-786295b01cdms7b3; Wed, 29 Oct 2025 02:39:38 -0700 (PDT) X-Received: by 2002:a05:690c:6c8b:b0:780:f8b7:c177 with SMTP id 00721157ae682-78628e42c72mr22382007b3.16.1761730777251; Wed, 29 Oct 2025 02:39:37 -0700 (PDT) Date: Wed, 29 Oct 2025 02:39:36 -0700 (PDT) From: TokyoBitcoiner To: Bitcoin Development Mailing List Message-Id: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_60120_1919609431.1761730776755" X-Original-Sender: arthurmyer@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_60120_1919609431.1761730776755 Content-Type: multipart/alternative; boundary="----=_Part_60121_1861785479.1761730776755" ------=_Part_60121_1861785479.1761730776755 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Questions reacting to text in reply of Russell O'Connor: - *" there exist some protocols that require":*=20 - Which protocols?=20 - Why does bitcoin need to cater to their needs?=20 - Do we cater to any protocol that comes along? - How do we choose which to enable, and which to discourage? - *"the folks using these protocols will simply have no choice"*:=20 - Did we *force* them to use bitcoin for their project?=20 - It sounds like "if you don't change the code to enable my project,= =20 I will be forced to trash your project." Is this wrong? - *"any attempt to cap OP_RETURN outputs will force those users"*:=20 - Again, *force* is a form of coercion. Is the bitcoin code with it's= =20 current setting *forcing* anyone to do anything?=20 - Are the external protocol designers the victims here? - *"Bitcoin Core 30 is *fixing* an existing problem"*:=20 - What problem?=20 - Is the bitcoin code responsible for fulfilling the needs of an=20 external project or protocol?=20 - If yes, why? =20 I hope you will take these questions seriously. I really want to understand= =20 your thinking. On Wednesday, October 29, 2025 at 4:18:06=E2=80=AFAM UTC+9 Russell O'Connor= wrote: > This proposal isn't a compromise at all. > > The entire problem was kicked off by noting that there exist some=20 > protocols that require the revealing of data that is somewhat longer than= =20 > 80 bytes long (on the order of hundreds of bytes if I recall correctly). = =20 > If we cap the OP_RETURN outputs to 80 bytes and 1 per transaction, the=20 > folks using these protocols will simply have no choice but to instead pla= ce=20 > their data for publication into bare multisig outputs. This outcome woul= d=20 > be objectively worse for everyone involved. The protocol users will have= =20 > to pay someone higher fees. Everyone's UTXO sets will be bloated with=20 > these unspendable transactions, and, unlike with OP_RETURN, there will be= =20 > no way to decide which bare multisigs are being used as a poor man's=20 > bulletin board, and which ones are legitimate. > > In fact, any attempt to cap OP_RETURN outputs will force those users to= =20 > use bare multisigs instead, or perhaps use non OP_RETURN methods, such as= =20 > OP_O OP_VERIFY, or whatever, which would be just worse for everyone=20 > involved. > > Bitcoin Core 30 is *fixing* an existing problem, and trying to roll thing= s=20 > back would unsolve the problem. In fact, such a softfork would make the= =20 > problem much worse by transforming a block reconstruction problem into a= =20 > deliberate push towards having user who need to publish data into using= =20 > uncensorable bare multisig outputs instead. > > On Tue, Oct 28, 2025 at 12:09=E2=80=AFPM Majorian wr= ote: > >> Dear Bitcoin Development Mailing List, >> >> I hope this email finds you well. I am Majorian, and I've been active in= =20 >> the bitcoin space since 2017.=20 >> >> I'm not a programmer or technical expert by any means; I'm just someone= =20 >> who has seen Bitcoin evolve over the years and wants to see it thrive=20 >> without unnecessary division. >> >> I'm writing today to propose a simple compromise that I believe could=20 >> help bridge the gap between the various sides in the ongoing controversi= es=20 >> in the Bitcoin community following Core 30's release. >> >> As many of you know, these debates have created a rift in the community.= =20 >> My proposal isn't aimed at fully solving broader issues=E2=80=94that's a= bigger=20 >> challenge requiring more comprehensive solutions. Instead, it seeks to= =20 >> return Bitcoin to the de facto operational state it has maintained for o= ver=20 >> a decade, where OP_RETURN has been used sparingly and responsibly for=20 >> metadata. The core goal is to codify at the consensus level the historic= al=20 >> node relay norms that have guided Bitcoin's operation effectively for=20 >> years, elevating these longstanding practices from policy to enforceable= =20 >> rules to ensure consistency and stability across the network.The=20 >> Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft= =20 >> fork that introduces the following consensus rules: >> =20 >> - Cap OP_RETURN data size at 83 bytes: This aligns closely with=20 >> historical norms (e.g., the 80-byte standard relay policy) This means= that=20 >> OP_RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes f= or the=20 >> data push, and 80 bytes of data. By enforcing this at consensus, we s= imply=20 >> make permanent the relay standards that nodes have followed in practi= ce for=20 >> much of Bitcoin's history. >> - Limit to 1 OP_RETURN output per transaction: This ensures=20 >> transactions adhere to traditional patterns, reducing potential abuse= =20 >> without disrupting standard usage. >> >> This approach codifies the proven, historical relay policies into=20 >> consensus rules, preserving Bitcoin's operational heritage.Why This=20 >> Compromise? >> =20 >> - Simplicity: The rules are straightforward to implement and verify,= =20 >> with minimal code changes required. >> - Bridging the Divide: It addresses concerns of new attack vectors by= =20 >> tightening OP_RETURN usage to match historical norms, while being agn= ostic=20 >> on 'spam.' >> - Apolitical and Restorative: This proposal is deliberately=20 >> apolitical, aiming simply to return Bitcoin to the state it was in ro= ughly=20 >> a few weeks ago, before recent debates intensified. It takes no sides= =20 >> regarding specific implementations like Core, Knots, or others. While= large=20 >> OP_RETURNs have been possible at the consensus level for a long time,= =20 >> they've seldom been used in this manner until very recently. By cappi= ng=20 >> them, we principally address concerns about OP_RETURN being used as a= n=20 >> attack vector on Bitcoin, codifying the relay norms that have kept su= ch=20 >> usage in check. >> - Plausible Deniability: Enforcing these limits provides plausible=20 >> deniability, declaring firmly that Bitcoin is not designed or intende= d as a=20 >> peer-to-peer file sharing and storage protocol in the context of OP_R= ETURN.=20 >> This might be somewhat controversial, but I am including this anyway. >> - Community Healing: By focusing on a modest, consensus-building=20 >> change, we can hopefully repair the current rift and refocus on bitco= in's=20 >> future. >> >> If this idea gains traction on the list, I'd love to see it formalized a= s=20 >> a Bitcoin Improvement Proposal (BIP). I'm not equipped to write the code= =20 >> myself, but I can contribute to the discussion and help rally community= =20 >> support. What do you all think? Is this a viable middle ground? Are=20 >> there technical pitfalls I'm missing? Feedback from experts like you wou= ld=20 >> be invaluable.=20 >> >> Thank you for your time and dedication to Bitcoin. >> >> Best regards, >> Majorian >> >> --=20 >> > You received this message because you are subscribed to the Google Groups= =20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df5= 5760674dan%40googlegroups.com=20 >> >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 0f35a624-92bd-4bdb-933b-a6fb28b91bd0n%40googlegroups.com. ------=_Part_60121_1861785479.1761730776755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Questions reacting to text in reply of Russell O'Connor:
  • "= =C2=A0there exist some protocols that require":=C2=A0
    • Which prot= ocols?=C2=A0
    • Why does bitcoin need to cater to their needs?=C2=A0
    • Do we cater to any protocol that comes along?
      • How do we choos= e which to enable, and which to discourage?
  • = "the folks using these protocols will simply have no choice":=C2=A0
      =
    • Did we force them to use bitcoin for their project?=C2=A0
      • It sounds like "if you don't change the code to enable my project, I will= be forced to trash your project." Is this wrong?
  • "any= attempt to cap OP_RETURN outputs will=C2=A0force=C2=A0those users":=C2= =A0
    • Again, force is a form of coercion. Is the bitcoin code w= ith it's current setting forcing anyone to do anything?=C2=A0
      • Are the external protocol designers the victims here?
  • <= b>"Bitcoin Core 30 is *fixing* an existing problem":=C2=A0
    • What = problem?=C2=A0
    • Is the bitcoin code responsible for fulfilling the n= eeds of an external project or protocol?=C2=A0
      • If yes, why?

I hope you will take these= questions seriously. I really want to understand your thinking.

On= Wednesday, October 29, 2025 at 4:18:06=E2=80=AFAM UTC+9 Russell O'Conn= or wrote:
This proposal isn't a compromise at all.
<= br>
The entire problem was kicked off by noting that there exist = some protocols that require the revealing of data that is somewhat longer t= han 80 bytes long (on the order of hundreds of bytes if I recall correctly)= .=C2=A0 If we cap the OP_RETURN outputs to 80 bytes and 1 per transaction, = the folks using these protocols will simply have no choice but to instead p= lace their data for publication into bare multisig outputs.=C2=A0 This outc= ome would be objectively worse for everyone involved.=C2=A0 The protocol us= ers will have to pay someone higher fees.=C2=A0 Everyone's UTXO sets wi= ll be bloated with these unspendable transactions, and, unlike with OP_RETU= RN, there will be no way to decide which bare multisigs are being used as a= poor man's bulletin=C2=A0board, and which ones are legitimate.

=
In fact, any attempt to cap OP_RETURN outputs will=C2=A0force=C2= =A0those users to use bare multisigs=C2=A0instead, or perhaps use non OP_RE= TURN methods, such as OP_O OP_VERIFY, or whatever, which would be=C2=A0just= worse for everyone involved.

Bitcoin Core 30 is *= fixing* an existing problem, and trying to roll things back would unsolve t= he problem.=C2=A0 In fact, such a softfork would make the problem much wors= e by transforming a block reconstruction problem into a deliberate push tow= ards having user who need to publish data into using uncensorable bare mult= isig outputs instead.

On Tue, Oct 28,= 2025 at 12:09=E2=80=AFPM Majorian <major...@gmail.com> wrote:
Dear Bitcoin Development Mailing List,

= I hope this email finds you well. I am Majorian, and I'v= e been active in the bitcoin space since 2017.=C2=A0
<= span style=3D"background-color:transparent">
I'= ;m not a programmer or technical expert by any means; I'm just someone = who has seen Bitcoin evolve over the years and wants to see it thrive witho= ut unnecessary division.

= I'm writing today to propo= se a simple compromise that I believe could help bridge the gap between the= various sides in the ongoing controversies in the Bitcoin community follow= ing Core 30's release.

= As many of you know, these deb= ates have created a rift in the community. My proposal isn't aimed at f= ully solving broader issues=E2=80=94that's a bigger challenge requiring= more comprehensive solutions. Instead, it seeks to return Bitcoin to the d= e facto operational state it has maintained for over a decade, where OP_RET= URN has been used sparingly and responsibly for metadata. The core goal is = to codify at the consensus level the historical node relay norms that have = guided Bitcoin's operation effectively for years, elevating these longs= tanding practices from policy to enforceable rules to ensure consistency an= d stability across the network.The Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft= fork that introduces the following consensus rules:
  • Cap OP_RETURN data size at 83 by= tes: This aligns closely with hi= storical norms (e.g., the 80-byte standard relay policy) This means that OP= _RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes for the d= ata push, and 80 bytes of data. By enforcing this at consensus, we simply m= ake permanent the relay standards that nodes have followed in practice for = much of Bitcoin's history.
  • Limit to 1 OP_RETURN output per tr= ansaction: This ensures transact= ions adhere to traditional patterns, reducing potential abuse without disru= pting standard usage.
This approach codifies the proven, historical relay po= licies into consensus rules, preserving Bitcoin's operational heritage.= Why This Compromise?
  • = Simplicity: The rules are straightforward to im= plement and verify, with minimal code changes required.
  • Bridging = the Divide: It addresses concern= s of new attack vectors by tightening OP_RETURN usage to match historical n= orms, while being agnostic on 'spam.'
  • Apolitical and Rest= orative: This proposal is delibe= rately apolitical, aiming simply to return Bitcoin to the state it was in r= oughly a few weeks ago, before recent debates intensified. It takes no side= s regarding specific implementations like Core, Knots, or others. While lar= ge OP_RETURNs have been possible at the consensus level for a long time, th= ey've seldom been used in this manner until very recently. By capping t= hem, we principally address concerns about OP_RETURN being used as an attac= k vector on Bitcoin, codifying the relay norms that have kept such usage in= check.
  • Plausible Deniability: Enforcing these limits provides plausible deniability, declaring = firmly that Bitcoin is not designed or intended as a peer-to-peer file shar= ing and storage protocol in the context of OP_RETURN. This might be somewha= t controversial, but I am including this anyway.
    • <= li style=3D"margin-top:0.5em;background-color:transparent"><= span style=3D"background-color:transparent">Community Healin= g<= span style=3D"background-color:transparent">: By focusing on a modest, cons= ensus-building change, we can hopefully repair the current rift and refocus= on bitcoin's future.
If this idea gains traction on the list, I'd l= ove to see it formalized as a Bitcoin Improvement Proposal (BIP). I'm n= ot equipped to write the code myself, but I can contribute to the discussio= n and help rally community support.=C2=A0What do you all think? Is this a viab= le middle ground? Are there technical pitfalls I'm missing? Feedback fr= om experts like you would be invaluable.=C2=A0<= /div>

Thank you f= or your time and dedication to Bitcoin.

Best regards,
Majorian=

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df55760674d= an%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/0f35a624-92bd-4bdb-933b-a6fb28b91bd0n%40googlegroups.com.
------=_Part_60121_1861785479.1761730776755-- ------=_Part_60120_1919609431.1761730776755--