* [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