From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Oct 2025 09:10:02 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDmGo-00030i-82 for bitcoindev@gnusha.org; Tue, 28 Oct 2025 09:10:02 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-651c934828dsf9385938eaf.0 for ; Tue, 28 Oct 2025 09:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761667796; x=1762272596; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Q5PbceYJhaRa7SqDwGU3XoUpBrve6I31BT4Piaaprpw=; b=MLHrsfWv6ADPIL9RH+Nn6A+hhx9M+HmKVre0OAglJtmnyEtxtD4pWUse3Hsq90GQCA zY5cE4wIIT3qBHp0yTnpCi8Ee1ReuHwcgJjxflWXvq0PRGl0KNN3KRJbaCtwkolMmHdo 4w6O1guxgRCIkWvTQCjUMZHfzNGh8Vz5KxT16mLEm8mnhH9Fy6YEBQ+LZZ55qvf06om0 ujhGI5xJD3QLBJ22SrHhxMdLcuXDZBvSjl0GYPsbT0hVliGUd5U/HJ1eZNEAZx97Rqsn ln82eBjKH3TeEDU/IpAsvKfFgkSRop/uX20MT+gd0VFjIdaBshBIJegSyigeIsAUAjsy HyEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761667796; x=1762272596; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=Q5PbceYJhaRa7SqDwGU3XoUpBrve6I31BT4Piaaprpw=; b=ZW/dDpKyFD3b5HxOWjR8TQmv+ZcM5aUjpq1+Q50MW31lzWD0NqMy16Vg7j/fTHH/2J gaBSETHV5PL7XwFR4G8bVqRNkS7SdvBLVcE2PTQcUSmurDrDhtjJURHe2QmnSowg4uNo nywauAu3/FU0l5hSdQ5Q9ps2e6R80tOAOip/AxdlyEj44egwm7Y/Llbw4WtePzMKojUf 1rLZ/E59jMZIfdyLZ/9W8eOS0Jy63llcwWQG8hwrBge/Taxg2GH7wHQS33W1sbcdNA5b vi8Jka3zQpbBoZtrpNa9tk4PU+44v2JAgFHjZM77HUSIU8LvmI+5tKjcW1E7TNWpO68v minQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761667796; x=1762272596; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Q5PbceYJhaRa7SqDwGU3XoUpBrve6I31BT4Piaaprpw=; b=DxC1evcLBlFlgUmc4HXnTN6doavvSRUXigDMisZF2uABa0pgl93NmSpZjOwhbwzipu DZQjgKbsPf604J/gD0urz35JkPxbhUZA+RWiV2UTF0FANEu4O/gr0zTZ5S7j9GO4PQPO 14I7fASzQI3IB5/VI+DeuaMtuRyNDBKt5t9N+66cvZSNu9O4iM7O4N8xddBYJMc3japD QUzN99sftFnT6YsEGviqEL+K5cmJSh1ErikWc/1XZzUuTEeZeSfo0frBdb6Exj5FNWb2 ibnjaGph2fr9tEr1Z+PFDQ7tWhp9i6sQ+8gJvsW1iQwHukyftFtsGL6Q54C5j5wENY+3 4Jkg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWEbCLmge7TMc+gVqpWAtQ7CWOBzn4LVe2xfNDR9mDADKiM55tVP6zVChV6e+IXtWTf8Es2XtDBmjk4@gnusha.org X-Gm-Message-State: AOJu0YyE6bgXLKCV0gzKtBdrqhEI+AXho6oB7FcfwEC1T6ZsrwUbCUBV BEHKgxkdP75ye+NCiCGpo57dxPgv14MbewKxcbK2jtIn6yBL742Mya/n X-Google-Smtp-Source: AGHT+IFptJGSk9uL9Hot7DuxD6GYr0QJ4M1dg2geub3KpPVoloW++Hhfs4bvI+euJUxP9v3RK0kaTA== X-Received: by 2002:a05:6870:256:b0:3d3:2fa6:e162 with SMTP id 586e51a60fabf-3d5d6bba19emr1439335fac.1.1761667795773; Tue, 28 Oct 2025 09:09:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Zx4k3ZCNqwEDO5XfZdgZrWUtQu6GDtd9+MY6X1ukpgdg==" Received: by 2002:a05:6871:3a11:b0:3d1:fb8f:5574 with SMTP id 586e51a60fabf-3d1fb8f599els1258738fac.2.-pod-prod-02-us; Tue, 28 Oct 2025 09:09:51 -0700 (PDT) X-Received: by 2002:a05:6808:1a29:b0:441:8f74:f38 with SMTP id 5614622812f47-44f6bb7bf1cmr1635621b6e.66.1761667791781; Tue, 28 Oct 2025 09:09:51 -0700 (PDT) Received: by 2002:a05:690c:38d:b0:74f:1486:e2a9 with SMTP id 00721157ae682-785daab994dms7b3; Tue, 28 Oct 2025 09:01:44 -0700 (PDT) X-Received: by 2002:a05:690c:74c2:b0:785:ff54:29b3 with SMTP id 00721157ae682-78617f2b30emr41933707b3.39.1761667303529; Tue, 28 Oct 2025 09:01:43 -0700 (PDT) Date: Tue, 28 Oct 2025 09:01:43 -0700 (PDT) From: Majorian To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_82558_1681283617.1761667303022" X-Original-Sender: majorianbtc@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_82558_1681283617.1761667303022 Content-Type: multipart/alternative; boundary="----=_Part_82559_1402731036.1761667303022" ------=_Part_82559_1402731036.1761667303022 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 who= =20 has seen Bitcoin evolve over the years and wants to see it thrive without= =20 unnecessary division. I'm writing today to propose a simple compromise that I believe could help= =20 bridge the gap between the various sides in the ongoing controversies in=20 the Bitcoin community following Core 30's release. As many of you know, these debates have created a rift in the community. My= =20 proposal isn't aimed at fully solving broader issues=E2=80=94that's a bigge= r=20 challenge requiring more comprehensive solutions. Instead, it seeks to=20 return Bitcoin to the de facto operational state it has maintained for over= =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 historical= =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 Proposal:= =20 OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft fork that=20 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 th= at=20 OP_RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes for = the=20 data push, and 80 bytes of data. By enforcing this at consensus, we simp= ly=20 make permanent the relay standards that nodes have followed in practice = for=20 much of Bitcoin's history. - Limit to 1 OP_RETURN output per transaction: This ensures transactions= =20 adhere to traditional patterns, reducing potential abuse without disrupt= ing=20 standard usage. This approach codifies the proven, historical relay policies into consensus= =20 rules, preserving Bitcoin's operational heritage.Why This 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 agnost= ic=20 on 'spam.' - Apolitical and Restorative: This proposal is deliberately apolitical,= =20 aiming simply to return Bitcoin to the state it was in roughly a few wee= ks=20 ago, before recent debates intensified. It takes no sides regarding=20 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 capping= =20 them, we principally address concerns about OP_RETURN being used as an= =20 attack vector on Bitcoin, codifying the relay norms that have kept such= =20 usage in check. - Plausible Deniability: Enforcing these limits provides plausible=20 deniability, declaring firmly that Bitcoin is not designed or intended a= s a=20 peer-to-peer file sharing and storage protocol in the context of OP_RETU= RN.=20 This might be somewhat controversial, but I am including this anyway. - Community Healing: By focusing on a modest, consensus-building change,= =20 we can hopefully repair the current rift and refocus on bitcoin's future= . If this idea gains traction on the list, I'd love to see it formalized as a= =20 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 there= =20 technical pitfalls I'm missing? Feedback from experts like you would be=20 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 "= 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/= f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegroups.com. ------=_Part_82559_1402731036.1761667303022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Bitcoi= n Development Mailing List,

I hope this email finds you well. I am Majorian, and I've been active i= n the bitcoin space since 2017.=C2=A0

I'm not a programmer or technical expert by any means; I'm ju= st someone who has seen Bitcoin evolve over the years and wants to see it t= hrive without unnecessary division.

I'm writing today to propose a simple compromise that I believe= could help bridge the gap between the various sides in the ongoing controv= ersies in the Bitcoin community following Core 30's release.<= /span>

As many of you know, these debates hav= e created a rift in the community. My proposal isn't aimed at fully solving= broader issues=E2=80=94that's a bigger challenge requiring more comprehens= ive solutions. Instead, it seeks to return Bitcoin to the de facto operatio= nal state it has maintained for over a decade, where OP_RETURN has been use= d 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 longstanding practices fr= om policy to enforceable rules to ensure consistency and stability across t= he network.= The Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatibl= e soft fork that introduces the following consensus rules:
  • Cap OP_RETURN data size at 83 by= tes: This aligns closely wit= h historical norms (e.g., the 80-byte standard relay policy) This means tha= t OP_RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes for t= he data push, and 80 bytes of data. By enforcing this at consensus, we simp= ly make permanent the relay standards that nodes have followed in practice = for much of Bitcoin's history.
  • Limit to 1 OP_RETURN= output per transaction: Thi= s ensures transactions adhere to traditional patterns, reducing potential a= buse without disrupting standard usage.
This approach codifies the= proven, historical relay policies into consensus rules, preserving Bitcoin= 's operational heritage.Why This Compromise?
  • <= span style=3D"background-color: transparent;">Simplicity= : The rules are straightforward to implement and verify, with minimal code = changes required.
  • Bridging the Divide= : It addresses concerns of new attack vect= ors by tightening OP_RETURN usage to match historical norms, while being ag= nostic on 'spam.'
  • Apolitical and Restorative= : This proposal is deliberately apo= litical, aiming simply to return Bitcoin to the state it was in roughly a f= ew weeks ago, before recent debates intensified. It takes no sides regardin= g specific implementations like Core, Knots, or others. While large OP_RETU= RNs have been possible at the consensus level for a long time, they've seld= om been used in this manner until very recently. By capping them, we princi= pally address concerns about OP_RETURN being used as an attack vector on Bi= tcoin, codifying the relay norms that have kept such usage in check.=
  • <= span style=3D"background-color: transparent;">Plausible Deniability: Enforcing these limits provides plausible deniability, declari= ng firmly that Bitcoin is not designed or intended as a peer-to-peer file s= haring and storage protocol in the context of OP_RETURN. This might be some= what controversial, but I am including this anyway.
  • Community Healing: By focus= ing on a modest, consensus-building change, we can hopefully repair the cur= rent rift and refocus on bitcoin's future.
If this idea gains trac= tion on the list, I'd love to see it formalized as a Bitcoin Improvement Pr= oposal (BIP). I'm not equipped to write the code myself, but I can contribu= te to the discussion and help rally community support.=C2=A0<= /span>What do = you all think? Is this a viable middle ground? Are there technical pitfalls= I'm missing? Feedback from experts like you would be invaluable.=C2=A0
=
Thank you for your time and= dedication to Bitcoin.
<= span style=3D"background-color: transparent;">
= Best regards,
<= span style=3D"background-color: transparent;">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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegroups.com.
------=_Part_82559_1402731036.1761667303022-- ------=_Part_82558_1681283617.1761667303022--