From: "Martin Habovštiak" <martin.habovstiak@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Greg Maxwell <gmaxwell@gmail.com>,
yes_please <caucasianjazz12@gmail.com>,
"Russell O'Connor" <roconnor@blockstream.com>,
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: Thu, 30 Oct 2025 20:35:44 +0100 [thread overview]
Message-ID: <CALkkCJYEQAnj4MVVXnr5ufNz_SXFTg5s4JW5Uud2wipzzfQrXQ@mail.gmail.com> (raw)
In-Reply-To: <CAKaEYh+D9y6r0RZJPAGY08KSc1s+xUZ9UY4fR2f=dDc0joXEfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12295 bytes --]
"Honest" only refers to miners not trying to reverse the transactions by
making an alternative chain. It has nothing to do with your subjective
evaluation of the transactions worth trying to censor the "bad ones".
Bitcoin was specifically designed to prevent censorship of transactions
that follow the consensus rules. Trying to go against it makes you a fool
at best or an attacker at worst.
Dňa št 30. 10. 2025, 18:37 Melvin Carvalho <melvincarvalho@gmail.com>
napísal(a):
>
>
> čt 30. 10. 2025 v 3:16 odesílatel Greg Maxwell <gmaxwell@gmail.com>
> napsal:
>
>> I searched for the source of your quotation and am unable to find it, but
>> its author appears to be confused or missing a complete understanding.
>>
>> The particular size isn't motivated by application but because major
>> miners had already removed the rule completely. As such no lesser setting
>> would achieve the goal of matching relay to what will actually get mined
>> and completely solve the bad situation created by the mismatch.
>>
>> If you consider this regrettable it's worthwhile to consider that a
>> failure to increase it previously (on several prior proposals) and even a
>> failure to discuss and evaluate it was likely due to the unprofessional and
>> relentless harassment of Luke-jr. Had that not occurred perhaps the limit
>> would have been incrementally increased previously before major miners on
>> their own found it to be in their interest to simply remove it (as removing
>> it is much easier than twiddling it). The consequence of failing to be
>> pragmatic is the loss of that nudge.
>>
>> That said, the economics and incentives of bitcoin are such that the
>> removal was inevitable once people were willing to pay for it-- and I would
>> have happily told you this in 2014 or whenever back when op_return was
>> reallowed for relay. Beyond the current situation with the rule completely
>> bypassed this inevitably favors removal once the policy has started
>> eroding. Even if miners had only bypassed to a few kilobytes or whatnot
>> moving to match that would only result in repeated cycles of transactions
>> that will get mined failing to relay, each cycle favoring private
>> submission mechanisms and promoting mining centralization. Policy is only
>> at best a nudge and a fragile one.
>>
>> I think in many people's view-- certainly in mine-- cirtia or whatever
>> was irrelevant to the discussion except as a concrete example of a fake
>> pubkey user that would rather not do that-- and one that wasn't some random
>> NFT thing that we'd all rather not be using Bitcoin at all. In other words,
>> that the benefit of avoiding more utxo bloat wasn't speculative.
>>
>
> While much of this discussion has focused on policy, there’s also an
> incentive perspective.
>
> Section 11 of the white paper notes that consensus holds *iff* honest
> nodes outpace dishonest ones.
>
> If we interpret *honest* as mining blocks consistent with standard
> monetary use, excluding large OP_RETURN payloads, then miners who do so are
> likely to earn more.
>
> When fees from arbitrary data are smaller than roughly half the block
> reward, standard ("honest") miners are effectively producing
> *double-value* blocks each epoch: they gain both the reward and a more
> secure, stable fee market over time.
> That economic feedback alone could be enough to restore convergence back
> to standard size OP_RETURNs. Of course, setting back the default helps here
> too.
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 30, 2025 at 1:15 AM yes_please <caucasianjazz12@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Perhaps we can find a meeting point if we focus on the max size of
>>> OP_return ?
>>> The increase from 83 to 100'000 bytes has been motivated as "probably we
>>> will have to increase it again in the future, it requires energy and time
>>> for code maintenance, so we'd rather increase it now to 100'000 bytes and
>>> be done with it". While these are valid points, the unknown consequences
>>> that might manifest with such a drastic increase all at once may not be the
>>> most prudent approach.
>>> Considering also that "the canary in the coal mine", namely Citrea use
>>> case, requires only 144 bytes to utilize op_return instead of more harmful
>>> ways, the increase to 100'000 bytes appears disproportionate given the
>>> circumstances, and again non-prudent enough (which is what I suspect is
>>> creating most of the debate at hand).
>>>
>>> caucasianjazz12
>>>
>>> On Wed, Oct 29, 2025 at 4:38 PM 'Russell O'Connor' via Bitcoin
>>> Development Mailing List <bitcoindev@googlegroups.com> wrote:
>>>
>>>> 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
>>>> <https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.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/CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D1q6-72UJHvzMPoTau7A7g%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/bitcoindev/CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D1q6-72UJHvzMPoTau7A7g%40mail.gmail.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/CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%40mail.gmail.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/CAKaEYh%2BD9y6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2BD9y6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%40mail.gmail.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/CALkkCJYEQAnj4MVVXnr5ufNz_SXFTg5s4JW5Uud2wipzzfQrXQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15983 bytes --]
next prev parent reply other threads:[~2025-10-30 20:41 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
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 [this message]
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=CALkkCJYEQAnj4MVVXnr5ufNz_SXFTg5s4JW5Uud2wipzzfQrXQ@mail.gmail.com \
--to=martin.habovstiak@gmail.com \
--cc=arthurmyer@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=caucasianjazz12@gmail.com \
--cc=gmaxwell@gmail.com \
--cc=melvincarvalho@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