From: "'Russell O'Connor' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: TokyoBitcoiner <arthurmyer@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: Wed, 29 Oct 2025 11:03:40 -0400 [thread overview]
Message-ID: <CAMZUoK=uAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21+Dg+i3uA@mail.gmail.com> (raw)
In-Reply-To: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 4730 bytes --]
On Wed, Oct 29, 2025 at 5:45 AM TokyoBitcoiner <arthurmyer@gmail.com> wrote:
> Questions reacting to text in reply of Russell O'Connor:
>
> - *" there exist some protocols that require":*
> - Which protocols?
>
> Citrea’s Clementine bridge, which needs 144 bytes for zk-proofs. I don't
know anything about their protocol beyond that.
>
> -
> - Why does bitcoin need to cater to their needs?
>
> If we don't support these in OP_RETURNs, Citrea, and other folks like
them, will use something like bare multisigs instead, which will be a
little more expensive for them and much more expensive for every other
Bitcoin node operator on the planet because those (likely) unspendable UTXO
will have to remain in the UTXO set forever because they will be
indistinguishable from legitimate bare multisigs.
>
> -
> - Do we cater to any protocol that comes along?
> - How do we choose which to enable, and which to discourage?
>
> Clamping down on OP_RETURNs won't discourage the use of these Citrea-like
protocols. Instead it will encourage them to instead use uncensorable
publication channels such as bare multisigs, which will bloat the UTXO set
and drive up costs for every Bitcoin node operator on the planet.
>
> - *"the folks using these protocols will simply have no choice"*:
> - Did we *force* them to use bitcoin for their project?
> - 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?
>
> By "force" I mean in the sense that when a recent KDE upgrade dropped the
ability to specify some command to be run whenever the screen is locked,
KDE "forced" me to write a systemd service to run dbus-monitor to watch for
screen locking events instead. Fortunately, in the case of KDE, being
"forced" to work around their changes only makes my life worse. However in
the case of limiting OP_RETURNs, users who are "forced" to find workarounds
for their proof of publication protocols will ultimately lead to them
using the uncensorable data channel of bare-multisigs, or similar, which
have consequences not only for themselves but every other Bitcoin node
operator on the planet.
It is specifically the externalities caused by the bare-multisig workaround
that we need to address. If these externalities didn't exist, then I, and
presumably others, wouldn't care so much.
>
> - *"any attempt to cap OP_RETURN outputs will force those users"*:
> - Again, *force* is a form of coercion. Is the bitcoin code with
> it's current setting *forcing* anyone to do anything?
> - Are the external protocol designers the victims here?
>
> The victims will be every node operator on the planet who has to deal with
the unprunable UTXO bloat caused by users posting their
proof-of-publication data via the uncensorable bare-multisig avenue. This
collective cost will actually be much higher than the cost to the external
protocol designers who only have to pay a few more pennies for their
transactions.
>
> - *"Bitcoin Core 30 is *fixing* an existing problem"*:
> - What problem?
>
> The problem is a combination of protocols that require using
proof-of-publication choosing to use uncensorable bare-multisigs instead,
and/or, so long as this proposal isn't adopted, the problem of users
bypassing the network to get their OP_RETURN transactions mined which leads
to poor quality block reconstruction and poor quality fee estimates and the
like.
>
> -
> - Is the bitcoin code responsible for fulfilling the needs of an
> external project or protocol?
> - If yes, why?
>
> Again the victims here wouldn't be the external protocol designers. They
will just pay the extra pennies to publish using bare-multisig. The
victims would be every Bitcoin node operator on the planet. And while the
core developers have no warranties or responsibilities attached to their
open source code, I think we would agree that "costs borne by every Bitcoin
node operator on the planet", is something they ought to bear in mind in
their work.
>
> I hope you will take these questions seriously. I really want to
> understand your thinking.
>
Hope this helps.
--
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/CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6657 bytes --]
next prev parent reply other threads:[~2025-10-29 15:38 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
2025-10-29 9:39 ` TokyoBitcoiner
2025-10-29 15:03 ` 'Russell O'Connor' via Bitcoin Development Mailing List [this message]
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='CAMZUoK=uAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21+Dg+i3uA@mail.gmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=arthurmyer@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