From: "'Russell O'Connor' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Majorian <majorianbtc@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
Date: Tue, 28 Oct 2025 13:38:40 -0400 [thread overview]
Message-ID: <CAMZUoKmi8VUrpjggJ7GmmiV=p114NuY8vWQdFnw99ppK++Ptaw@mail.gmail.com> (raw)
In-Reply-To: <f513d0af-90d1-43ee-ac8e-df55760674dan@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 6452 bytes --]
This proposal isn't a compromise at all.
The entire problem was kicked off by noting that there exist some protocols
that require the revealing of data that is somewhat longer than 80 bytes
long (on the order of hundreds of bytes if I recall correctly). 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 place their data
for publication into bare multisig outputs. This outcome would be
objectively worse for everyone involved. The protocol users will have to
pay someone higher fees. Everyone's UTXO sets will be bloated with these
unspendable transactions, and, unlike with OP_RETURN, there will be no way
to decide which bare multisigs are being used as a poor man's
bulletin board, and which ones are legitimate.
In fact, any attempt to cap OP_RETURN outputs will force those users to use
bare multisigs instead, or perhaps use non OP_RETURN methods, such as OP_O
OP_VERIFY, or whatever, which would be just worse for everyone involved.
Bitcoin Core 30 is *fixing* an existing problem, and trying to roll things
back would unsolve the problem. In fact, such a softfork would make the
problem much worse by transforming a block reconstruction problem into a
deliberate push towards having user who need to publish data into using
uncensorable bare multisig outputs instead.
On Tue, Oct 28, 2025 at 12:09 PM Majorian <majorianbtc@gmail.com> wrote:
> Dear Bitcoin Development Mailing List,
>
> I hope this email finds you well. I am Majorian, and I've been active in
> the bitcoin space since 2017.
>
> 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
> 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 controversies in
> the Bitcoin community following Core 30's release.
>
> As many of you know, these debates have created a rift in the community.
> My proposal isn't aimed at fully solving broader issues—that's a bigger
> challenge requiring more comprehensive solutions. Instead, it seeks to
> return Bitcoin to the de facto operational state it has maintained for over
> a decade, where OP_RETURN 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 longstanding practices from policy to enforceable
> rules to ensure consistency and 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 bytes: This aligns closely with
> historical 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
> data push, and 80 bytes of data. By enforcing this at consensus, we simply
> 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: This ensures
> transactions adhere to traditional patterns, reducing potential abuse
> without disrupting standard usage.
>
> This approach codifies the proven, historical relay policies into
> consensus rules, preserving Bitcoin's operational heritage.Why This
> Compromise?
>
> - Simplicity: The rules are straightforward to implement and verify,
> with minimal code changes required.
> - Bridging the Divide: It addresses concerns of new attack vectors by
> tightening OP_RETURN usage to match historical norms, while being agnostic
> on 'spam.'
> - Apolitical and Restorative: This proposal is deliberately
> apolitical, aiming simply to return Bitcoin to the state it was in roughly
> a few weeks ago, before recent debates intensified. It takes no sides
> regarding specific implementations like Core, Knots, or others. While large
> OP_RETURNs have been possible at the consensus level for a long time,
> they've seldom been used in this manner until very recently. By capping
> them, we principally address concerns about OP_RETURN being used as an
> attack 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 sharing and storage protocol in the context of OP_RETURN.
> This might be somewhat controversial, but I am including this anyway.
> - Community Healing: By focusing on a modest, consensus-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 love to see it formalized as
> a Bitcoin Improvement Proposal (BIP). I'm not equipped to write the code
> myself, but I can contribute to the discussion and help rally community
> support. 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.
>
> Thank you for your time and dedication to Bitcoin.
>
> Best regards,
> Majorian
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAMZUoKmi8VUrpjggJ7GmmiV%3Dp114NuY8vWQdFnw99ppK%2B%2BPtaw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15370 bytes --]
next prev parent reply other threads:[~2025-10-28 19:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 16:01 Majorian
2025-10-28 16:37 ` Martin Habovštiak
2025-10-28 16:50 ` Erik Aronesty
2025-10-28 17:38 ` 'Russell O'Connor' via Bitcoin Development Mailing List [this message]
2025-10-29 9:39 ` TokyoBitcoiner
2025-10-29 15:03 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-10-29 16:10 ` yes_please
2025-10-30 2:10 ` Greg Maxwell
2025-10-30 15:04 ` Melvin Carvalho
2025-10-30 19:35 ` Martin Habovštiak
2025-10-31 6:31 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZUoKmi8VUrpjggJ7GmmiV=p114NuY8vWQdFnw99ppK++Ptaw@mail.gmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=majorianbtc@gmail.com \
--cc=roconnor@blockstream.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox