* [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
@ 2025-10-28 16:01 Majorian
2025-10-28 16:37 ` Martin Habovštiak
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Majorian @ 2025-10-28 16:01 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4318 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 13280 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-28 16:01 [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies 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
2 siblings, 0 replies; 11+ messages in thread
From: Martin Habovštiak @ 2025-10-28 16:37 UTC (permalink / raw)
To: Majorian; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]
Hi,
Since you seem to be respectful, I decided to reply to you. Unfortunately,
doing this would make things worse by forcing data longer than 83B to go
into unspendable outs - that means it'd be never possible to remove them,
including in case of pruned nodes.
If the contiguous data argument was valid then restricting it to something
like 200B would make some sense, but even that is invalid for several
reasons.
I hope you find this message helpful.
Martin
Dňa ut 28. 10. 2025, 17:09 Majorian <majorianbtc@gmail.com> napísal(a):
> 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/CALkkCJa1uswSje_mm9h3FOhSaa7Ff8MGupMt9Xc9%3DGr5SmDJzw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 14614 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-28 16:01 [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies 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
2 siblings, 0 replies; 11+ messages in thread
From: Erik Aronesty @ 2025-10-28 16:50 UTC (permalink / raw)
To: Majorian; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6101 bytes --]
OP_RETURN is strictly better than any other mechanism for spamming the
chain. Why would I, as a node runner, prefer spammers to waste UTXOs when
OP_RETURN would suffice? Nearly half the UTXOs are now spam, and this is
the main expense for running a node.
Lets look at root causes for this problem,
- Block space is cheap, allowing for trivial wastes of space
- OP_RETURN doesn't relay well over 83 bytes, so its easier for me to spam
with OP_PUSH (inscriptions)
If we're seriously considering a soft fork for spam, lets consider a block
size reduction coupled with UTXO-sharing opcodes, like CTV.
- UTXO sharing is good for node runners and decentralization
- Smaller blocks are good for node runners and decentralization
- Smaller blocks make Bitcoin strictly less useful for spammers
- UTXO sharing doesn't help spammers at all
- If spammers want to store data somewhere else and use Bitcoin to
represent ownership, there's nothing we can do to stop them. But at least
this gets the spam off the chain.
On Tue, Oct 28, 2025 at 9:09 AM 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/CAJowKgJoB%3DbDXtY8k%2BHJnA35bOTg5ZLabw5VQ3X4WnXDFs%3DEDw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15085 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-28 16:01 [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies 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
2 siblings, 1 reply; 11+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-10-28 17:38 UTC (permalink / raw)
To: Majorian, Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
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
0 siblings, 1 reply; 11+ messages in thread
From: TokyoBitcoiner @ 2025-10-29 9:39 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7916 bytes --]
Questions reacting to text in reply of Russell O'Connor:
- *" there exist some protocols that require":*
- Which protocols?
- Why does bitcoin need to cater to their needs?
- 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"*:
- 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?
- *"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?
- *"Bitcoin Core 30 is *fixing* an existing problem"*:
- What problem?
- Is the bitcoin code responsible for fulfilling the needs of an
external project or protocol?
- 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 AM 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
> 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 <major...@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+...@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/0f35a624-92bd-4bdb-933b-a6fb28b91bd0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17560 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
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
0 siblings, 1 reply; 11+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-10-29 15:03 UTC (permalink / raw)
To: TokyoBitcoiner, Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
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
0 siblings, 1 reply; 11+ messages in thread
From: yes_please @ 2025-10-29 16:10 UTC (permalink / raw)
To: Russell O'Connor; +Cc: TokyoBitcoiner, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6429 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 8742 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-29 16:10 ` yes_please
@ 2025-10-30 2:10 ` Greg Maxwell
2025-10-30 15:04 ` Melvin Carvalho
0 siblings, 1 reply; 11+ messages in thread
From: Greg Maxwell @ 2025-10-30 2:10 UTC (permalink / raw)
To: yes_please
Cc: Russell O'Connor, TokyoBitcoiner, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 9320 bytes --]
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.
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.
[-- Attachment #2: Type: text/html, Size: 12123 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-30 2:10 ` Greg Maxwell
@ 2025-10-30 15:04 ` Melvin Carvalho
2025-10-30 19:35 ` Martin Habovštiak
0 siblings, 1 reply; 11+ messages in thread
From: Melvin Carvalho @ 2025-10-30 15:04 UTC (permalink / raw)
To: Greg Maxwell
Cc: yes_please, Russell O'Connor, TokyoBitcoiner,
Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10981 bytes --]
č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.
[-- Attachment #2: Type: text/html, Size: 14256 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-30 15:04 ` Melvin Carvalho
@ 2025-10-30 19:35 ` Martin Habovštiak
2025-10-31 6:31 ` Melvin Carvalho
0 siblings, 1 reply; 11+ messages in thread
From: Martin Habovštiak @ 2025-10-30 19:35 UTC (permalink / raw)
To: Melvin Carvalho
Cc: Greg Maxwell, yes_please, Russell O'Connor, TokyoBitcoiner,
Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies
2025-10-30 19:35 ` Martin Habovštiak
@ 2025-10-31 6:31 ` Melvin Carvalho
0 siblings, 0 replies; 11+ messages in thread
From: Melvin Carvalho @ 2025-10-31 6:31 UTC (permalink / raw)
To: Martin Habovštiak
Cc: Greg Maxwell, yes_please, Russell O'Connor, TokyoBitcoiner,
Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 13893 bytes --]
čt 30. 10. 2025 v 20:35 odesílatel Martin Habovštiak <
martin.habovstiak@gmail.com> napsal:
> "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".
>
Hi Martin,
Small clarification per the white paper: "honest" isn’t only about
reversing transactions. Section 8 of the white paper also discusses honest
nodes and which transactions are accepted into blocks.
Satoshi further clarified standardness:
"The design supports a broad range of transaction types that are possible,
but not all are standard. Standard transactions are the ones that are
designed to be used for the common case."
-- June 2010
Per Section 11, the white paper's security model shows honest miners (e.g.
following standard operation) outpacing alternatives. In practice, miners
following a standardness agreement or soft fork for OP_RETURN would, on
affected blocks, earn around $100,000 more, than under a mixed policy,
making prioritizing standard transactions the economically optimal strategy.
This is because there are a finite number of blocks before each halving, so
the opportunity cost of non-standard payloads is half the subsidy, which is
more than enough economic upside to offset fees. A standardness agreement
soft fork is therefore economically compelling for miners: it aligns with
long-standing practice and provides long-term incentives.
Best,
Melvin
>
> 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/CAKaEYhKdhJ1vP5BBYNAMF7557M9dSoQx8_uqjdAzRM3DgA6ajg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 17882 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-10-31 6:34 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-28 16:01 [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies 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
2025-10-31 6:31 ` Melvin Carvalho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox