* [bitcoindev] Relax OP_RETURN standardness restrictions
@ 2025-04-17 18:52 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-04-17 18:52 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
Hi,
Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.
Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.
Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
Antoine Poinsot
[^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clementine_whitepaper.pdf
--
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/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 3508 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2 siblings, 1 reply; 23+ messages in thread
From: Sjors Provoost @ 2025-04-18 12:03 UTC (permalink / raw)
To: Antoine Poinsot, Bitcoin Development Mailing List
> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> het volgende geschreven:
> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
>
> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
It might be better to do both, if only to avoid repeating the discussion in a year.
From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.
1. Regarding size
The current ~80 byte limit was based on Counterparty needing it [0], and otherwise using bare multisig. A similar argument would apply here. At the time there was discussion about how much space Counterparty really needed if their protocol was well implemented.
The 144 bytes consist of a Groth16 proof and the total chain work. Along similar lines we could pick a number based on various cryptographic commitment schemes, and then only raise the limit by that much.
But that just guarantees repeating the argument in a year when some protocol needs a slightly higher limit. In a post-inscription world that seems pointless. My preference is to drop the size limit entirely.
2. Regarding count
IIUC there's no consensus limit on the size of an OP_RETURN [1] and there's also no standardness rule on the size of a scriptPubKey. The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.
Without a size restriction on individual OP_RETURN outputs, there's no point in limiting their number.
That said, it would be interesting to know if any protocols are thinking of using multiple OP_RETURN outputs.
3. Reminder why we didn't do this earlier
In the August 2023 discussion [2] Murch wrote, in response to John Light:
>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space
>
> Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:
[...]
> we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.
Since we're discussing raising the limit to at least 144 bytes, the above argument would no longer be relevant.
And from what I recall at the time that was the only remaining reason to keep the OP_RETURN restrictions around a bit longer, despite heavy use of inscriptions.
4. PS - on liveliness assumptions
The paper [3] states the following assumption:
> We consider a secure ledger, i.e., a ledger that is safe and live. Safety and liveness are defined as follows:
>
> ...
>
> Definition 2 (Liveness). A distributed ledger protocol is live with liveness parameter u if all transactions written by any correct party at round r, appear in the ledgers of all correct parties by round r + u.
For standard transactions this already not trivially true. See all of Lightning pinning discussions.
For non-standard transactions, does BitVM2 keep all its transactions under 100 kvB?
Otherwise your liveness assumption requires a direct connection to at least one miner / pool that is trusted to not censor (though you can shop around until the deadline).
Conversely, having actively used protocols that frequently require going over some standardises limit puts pressure on that limit for the reasons Antoine outlined. So for anyone working on such protocols, please let this list know, since these discussions can take a while.
- Sjors
[0] https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
[1] https://bitcoin.stackexchange.com/a/117595/4948
[2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t (click on the html attachment)
[3] https://citrea.xyz/clementine_whitepaper.pdf
--
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/C7E2D805-E70A-455C-BDA1-224024BE93B3%40sprovoost.nl.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-18 12:03 ` Sjors Provoost
@ 2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
0 siblings, 2 replies; 23+ messages in thread
From: Greg Sanders @ 2025-04-18 12:54 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6305 bytes --]
> From perusing the Citrea paper (page 18) it seems a single output is
enough, and they only need 144 bytes.
From discussion in person it seems as though they could adapt their use to
batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with
each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps,
but if we can derive additional efficiency and don't want to revisit this
conversation again later, may be worth doing.
The only drawback I can see to the second step would be that we *could
have* reserved multi-output as some sort of signaling mechanism since it's
previously not relayable on Bitcoin Core, even with knob fiddling, though I
can't imagine what that would be. Additional OP_RETURNs would be an
expensive signal.
Greg
On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development
> Mailing List <bitco...@googlegroups•com> het volgende geschreven:
>
> > Developers are now designing constructions that work around these
> limitations. An example is Clementine, the recently-announced Citrea
> bridge, which uses unspendable Taproot outputs to store data in its
> "WatchtowerChallenge" transaction due to the standardness restrictions on
> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years
> that the nudge is ineffective to deter storing data onchain.
> >
> > Since the restrictions on the usage of OP_RETURN outputs encourage
> harmful practices while being ineffective in deterring unwanted usage, i
> propose to drop them. I suggest to start by lifting the restriction on the
> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to
> stop encouraging harmful behaviour, and to then proceed to lift the
> restriction on the number of OP_RETURN outputs per transactions.
>
> It might be better to do both, if only to avoid repeating the discussion
> in a year.
>
> From perusing the Citrea paper (page 18) it seems a single output is
> enough, and they only need 144 bytes.
>
> 1. Regarding size
>
> The current ~80 byte limit was based on Counterparty needing it [0], and
> otherwise using bare multisig. A similar argument would apply here. At the
> time there was discussion about how much space Counterparty really needed
> if their protocol was well implemented.
>
> The 144 bytes consist of a Groth16 proof and the total chain work. Along
> similar lines we could pick a number based on various cryptographic
> commitment schemes, and then only raise the limit by that much.
>
> But that just guarantees repeating the argument in a year when some
> protocol needs a slightly higher limit. In a post-inscription world that
> seems pointless. My preference is to drop the size limit entirely.
>
> 2. Regarding count
>
> IIUC there's no consensus limit on the size of an OP_RETURN [1] and
> there's also no standardness rule on the size of a scriptPubKey. The size
> of a single OP_RETURN is limited only by the maximum transaction size, i.e.
> 100 kvB.
>
> Without a size restriction on individual OP_RETURN outputs, there's no
> point in limiting their number.
>
> That said, it would be interesting to know if any protocols are thinking
> of using multiple OP_RETURN outputs.
>
> 3. Reminder why we didn't do this earlier
>
> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>
> >> is there ever a case where using OP_RETURN to embed data actually
> results in fewer bytes onchain than embedding the same data using the
> segwit/taproot witness space
> >
> > Yes, a back-of-the-envelope calculation has me thinking that only
> payloads of 135 bytes would be cheaper with transcriptions than with
> nulldata outputs. In detail:
> [...]
> > we learn that nulldata outputs are cheaper up to a payload size of 134
> bytes, only above that inscriptions become a more blockspace efficient data
> carrier.
>
> Since we're discussing raising the limit to at least 144 bytes, the above
> argument would no longer be relevant.
>
> And from what I recall at the time that was the only remaining reason to
> keep the OP_RETURN restrictions around a bit longer, despite heavy use of
> inscriptions.
>
> 4. PS - on liveliness assumptions
>
> The paper [3] states the following assumption:
>
> > We consider a secure ledger, i.e., a ledger that is safe and live.
> Safety and liveness are defined as follows:
> >
> > ...
> >
> > Definition 2 (Liveness). A distributed ledger protocol is live with
> liveness parameter u if all transactions written by any correct party at
> round r, appear in the ledgers of all correct parties by round r + u.
>
> For standard transactions this already not trivially true. See all of
> Lightning pinning discussions.
>
> For non-standard transactions, does BitVM2 keep all its transactions under
> 100 kvB?
>
> Otherwise your liveness assumption requires a direct connection to at
> least one miner / pool that is trusted to not censor (though you can shop
> around until the deadline).
>
> Conversely, having actively used protocols that frequently require going
> over some standardises limit puts pressure on that limit for the reasons
> Antoine outlined. So for anyone working on such protocols, please let this
> list know, since these discussions can take a while.
>
> - Sjors
>
> [0]
> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
> [1] https://bitcoin.stackexchange.com/a/117595/4948
> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t
> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t>
> (click on the html attachment)
> [3] https://citrea.xyz/clementine_whitepaper.pdf
--
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/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8152 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-18 12:54 ` Greg Sanders
@ 2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
1 sibling, 0 replies; 23+ messages in thread
From: Vojtěch Strnad @ 2025-04-18 13:06 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7797 bytes --]
Hi all,
Regarding the size of an OP_RETURN output, I made a calculation [0] a while
ago to compare it to the all too commonly used "inscription envelope"
(<pubkey> OP_CHECKSIG OF_FALSE OP_IF <data> OP_ENDIF). The result was that
OP_RETURN is cheaper for data smaller than 143 bytes or 158 bytes,
depending on whether you count the overhead of the transaction revealing
the inscription.
Personally, I've never been a fan of the OP_RETURN standardness rules. They
could always be easily bypassed in more or less harmful ways with only a
small loss of data encoding efficiency (the most harmful being adding many
unspendable outputs to a transaction, which some protocols do even today).
[0] https://bitcoin.stackexchange.com/q/122321/121614
On Fri, Apr 18, 2025 at 2:58 PM Greg Sanders <gsanders87@gmail•com> wrote:
> > From perusing the Citrea paper (page 18) it seems a single output is
> enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use to
> batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with
> each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps,
> but if we can derive additional efficiency and don't want to revisit this
> conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could
> have* reserved multi-output as some sort of signaling mechanism since it's
> previously not relayable on Bitcoin Core, even with knob fiddling, though I
> can't imagine what that would be. Additional OP_RETURNs would be an
> expensive signal.
>
> Greg
>
> On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
>>
>> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin
>> Development Mailing List <bitco...@googlegroups•com> het volgende
>> geschreven:
>>
>> > Developers are now designing constructions that work around these
>> limitations. An example is Clementine, the recently-announced Citrea
>> bridge, which uses unspendable Taproot outputs to store data in its
>> "WatchtowerChallenge" transaction due to the standardness restrictions on
>> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years
>> that the nudge is ineffective to deter storing data onchain.
>> >
>> > Since the restrictions on the usage of OP_RETURN outputs encourage
>> harmful practices while being ineffective in deterring unwanted usage, i
>> propose to drop them. I suggest to start by lifting the restriction on the
>> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to
>> stop encouraging harmful behaviour, and to then proceed to lift the
>> restriction on the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion
>> in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is
>> enough, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and
>> otherwise using bare multisig. A similar argument would apply here. At the
>> time there was discussion about how much space Counterparty really needed
>> if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along
>> similar lines we could pick a number based on various cryptographic
>> commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some
>> protocol needs a slightly higher limit. In a post-inscription world that
>> seems pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and
>> there's also no standardness rule on the size of a scriptPubKey. The size
>> of a single OP_RETURN is limited only by the maximum transaction size, i.e.
>> 100 kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no
>> point in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking
>> of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>>
>> >> is there ever a case where using OP_RETURN to embed data actually
>> results in fewer bytes onchain than embedding the same data using the
>> segwit/taproot witness space
>> >
>> > Yes, a back-of-the-envelope calculation has me thinking that only
>> payloads of 135 bytes would be cheaper with transcriptions than with
>> nulldata outputs. In detail:
>> [...]
>> > we learn that nulldata outputs are cheaper up to a payload size of 134
>> bytes, only above that inscriptions become a more blockspace efficient data
>> carrier.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the above
>> argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to
>> keep the OP_RETURN restrictions around a bit longer, despite heavy use of
>> inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>> > We consider a secure ledger, i.e., a ledger that is safe and live.
>> Safety and liveness are defined as follows:
>> >
>> > ...
>> >
>> > Definition 2 (Liveness). A distributed ledger protocol is live with
>> liveness parameter u if all transactions written by any correct party at
>> round r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of
>> Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions
>> under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at
>> least one miner / pool that is trusted to not censor (though you can shop
>> around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going
>> over some standardises limit puts pressure on that limit for the reasons
>> Antoine outlined. So for anyone working on such protocols, please let this
>> list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0]
>> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t
>> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t>
>> (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
> 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/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%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/CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg%2Bgxo4Vvw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9326 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
@ 2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
1 sibling, 1 reply; 23+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-04-18 13:29 UTC (permalink / raw)
To: Greg Sanders, Sjors Provoost; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7676 bytes --]
> IIUC [..] The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.
Yes.
>>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space> Yes, a back-of-the-envelope calculation [..]
>
For reference Vojtěch Strnad also has a good StackExchange answer with details about this here: https://bitcoin.stackexchange.com/a/122322/101498. TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't think this is sufficient reason not to drop the limit.
> we *could have* reserved multi-output as some sort of signaling mechanism [..] though I can't imagine what that would be. Additional OP_RETURNs would be an expensive signal.
Exactly, and it's not like we would be running out of upgrade hooks anytime soon.
On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsanders87@gmail•com> wrote:
>> From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use to batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps, but if we can derive additional efficiency and don't want to revisit this conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could have* reserved multi-output as some sort of signaling mechanism since it's previously not relayable on Bitcoin Core, even with knob fiddling, though I can't imagine what that would be. Additional OP_RETURNs would be an expensive signal.
>
> Greg
> On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
>>> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development Mailing List <bitco...@googlegroups•com> het volgende geschreven:
>>
>>> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
>>>
>>> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and otherwise using bare multisig. A similar argument would apply here. At the time there was discussion about how much space Counterparty really needed if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along similar lines we could pick a number based on various cryptographic commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some protocol needs a slightly higher limit. In a post-inscription world that seems pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and there's also no standardness rule on the size of a scriptPubKey. The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no point in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>>
>>>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space
>>>
>>> Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:
>> [...]
>>> we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the above argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to keep the OP_RETURN restrictions around a bit longer, despite heavy use of inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>>> We consider a secure ledger, i.e., a ledger that is safe and live. Safety and liveness are defined as follows:
>>>
>>> ...
>>>
>>> Definition 2 (Liveness). A distributed ledger protocol is live with liveness parameter u if all transactions written by any correct party at round r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at least one miner / pool that is trusted to not censor (though you can shop around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going over some standardises limit puts pressure on that limit for the reasons Antoine outlined. So for anyone working on such protocols, please let this list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0] [https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592](https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/)
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] [https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t](https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t) (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
> 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/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.
--
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/8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 11815 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2025-04-18 21:34 ` Antoine Riard
0 siblings, 0 replies; 23+ messages in thread
From: Antoine Riard @ 2025-04-18 21:34 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9971 bytes --]
Hello Darosior,
Generally, I'm +1 on relaxing OP_RETURN standardness restrictions.
Few links that can be relevant for the discussions:
- https://github.com/petertodd/bitcoin/pull/6
- https://github.com/ordinals/ord/issues/2405
For adding a `-datacarrierenum`, this might be re-considered, e.g if you're
running a bitcoin full-node with an extended number of op_return outputs,
and
you have callback action when you're seeing said snarg proofs is in the
op_return.
This is assuming that of course additional software is running on top of
the full-node, e.g a custom block explorer, though it could be a source of
DoS, if callbacks are triggered before inclusion in op_return outputs (--
and some might do before inclusion, just for latency gains in their
use-cases).
I think there is one downside I can see of relaxing OP_RETURN standardness
restrictions, namely that a single transaction output "exogeneous" value
might be worth more than the block reward yields in fees (`blockReward`).
That could be an issue where a single transaction output owner with an
"exogeneous" value braodcast a tx for a double-spend where this condition
can only be included if the block is reorged-out (e.g a bridge where 2
withdrawal are valid at the same time to different owners). Somehow
linearity of chain advances is a good property to have.
One can have a look on the ordinals markets at the last halving blocks,
to see it's already can be a concern, as something like ordinals mined
by the coinbase pubkey was trading for a high price.
This is not a problem for now with multi-party transactiosn or contracting
protocols (e.g coinjoins or lightning), as it's always a coin exchanged, or
fees that must be committed to settle an off-chain state.
Best,
Antoine
OTS hash: a3264eaedf79b15d5e9cd32a20d1d82c6981f49a34256d6c961fd39c976ff2c2
Le vendredi 18 avril 2025 à 14:52:03 UTC+1, Antoine Poinsot a écrit :
> IIUC [..] The size of a single OP_RETURN is limited only by the maximum
> transaction size, i.e. 100 kvB.
>
> Yes.
>
> >> is there ever a case where using OP_RETURN to embed data actually
> results in fewer bytes onchain than embedding the same data using the
> segwit/taproot witness space
>
> > Yes, a back-of-the-envelope calculation [..]
>
> For reference Vojtěch Strnad also has a good StackExchange answer with
> details about this here: https://bitcoin.stackexchange.com/a/122322/101498.
> TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't think
> this is sufficient reason not to drop the limit.
>
> we *could have* reserved multi-output as some sort of signaling mechanism
> [..] though I can't imagine what that would be. Additional OP_RETURNs would
> be an expensive signal.
>
> Exactly, and it's not like we would be running out of upgrade hooks
> anytime soon.
> On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsand...@gmail•com>
> wrote:
>
> > From perusing the Citrea paper (page 18) it seems a single output is
> enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use to
> batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with
> each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps,
> but if we can derive additional efficiency and don't want to revisit this
> conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could
> have* reserved multi-output as some sort of signaling mechanism since it's
> previously not relayable on Bitcoin Core, even with knob fiddling, though I
> can't imagine what that would be. Additional OP_RETURNs would be an
> expensive signal.
>
> Greg
>
> On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
>>
>> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin
>> Development Mailing List <bitco...@googlegroups•com> het volgende
>> geschreven:
>>
>> > Developers are now designing constructions that work around these
>> limitations. An example is Clementine, the recently-announced Citrea
>> bridge, which uses unspendable Taproot outputs to store data in its
>> "WatchtowerChallenge" transaction due to the standardness restrictions on
>> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years
>> that the nudge is ineffective to deter storing data onchain.
>> >
>> > Since the restrictions on the usage of OP_RETURN outputs encourage
>> harmful practices while being ineffective in deterring unwanted usage, i
>> propose to drop them. I suggest to start by lifting the restriction on the
>> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to
>> stop encouraging harmful behaviour, and to then proceed to lift the
>> restriction on the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion
>> in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is
>> enough, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and
>> otherwise using bare multisig. A similar argument would apply here. At the
>> time there was discussion about how much space Counterparty really needed
>> if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along
>> similar lines we could pick a number based on various cryptographic
>> commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some
>> protocol needs a slightly higher limit. In a post-inscription world that
>> seems pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and
>> there's also no standardness rule on the size of a scriptPubKey. The size
>> of a single OP_RETURN is limited only by the maximum transaction size, i.e.
>> 100 kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no
>> point in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking
>> of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>>
>> >> is there ever a case where using OP_RETURN to embed data actually
>> results in fewer bytes onchain than embedding the same data using the
>> segwit/taproot witness space
>> >
>> > Yes, a back-of-the-envelope calculation has me thinking that only
>> payloads of 135 bytes would be cheaper with transcriptions than with
>> nulldata outputs. In detail:
>> [...]
>> > we learn that nulldata outputs are cheaper up to a payload size of 134
>> bytes, only above that inscriptions become a more blockspace efficient data
>> carrier.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the above
>> argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to
>> keep the OP_RETURN restrictions around a bit longer, despite heavy use of
>> inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>> > We consider a secure ledger, i.e., a ledger that is safe and live.
>> Safety and liveness are defined as follows:
>> >
>> > ...
>> >
>> > Definition 2 (Liveness). A distributed ledger protocol is live with
>> liveness parameter u if all transactions written by any correct party at
>> round r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of
>> Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions
>> under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at
>> least one miner / pool that is trusted to not censor (though you can shop
>> around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going
>> over some standardises limit puts pressure on that limit for the reasons
>> Antoine outlined. So for anyone working on such protocols, please let this
>> list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0]
>> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
>> <https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/>
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t
>> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t>
>> (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
>
> 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/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com
> .
>
>
--
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/0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 14639 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
@ 2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2 siblings, 0 replies; 23+ messages in thread
From: Peter Todd @ 2025-04-20 8:43 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On Thu, Apr 17, 2025 at 06:52:34PM +0000, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> Hi,
>
> Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.
>
> Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.
>
> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
>
> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
I would suggest removing both limits at the same time.
While multiple OP_Return outputs are more expensive than a single one
for the same amount of total data. In some cases they're necessary for
technical reasons, e.g. if signing with SIGHASH_SINGLE.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/aASzwkFfGFBYudK_%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-20 8:43 ` Peter Todd
@ 2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2 siblings, 1 reply; 23+ messages in thread
From: Luke Dashjr @ 2025-04-26 9:50 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3142 bytes --]
It should be needless to say, but this idea is utter insanity.
Disappointing to see positive responses, and not one sensible reply
calling it out yet. The bugs should be fixed, not the abuse embraced. If
attackers continue to bypass filters, we can go back to a full whitelist
approach. We're now 2+ years into this wave of attacks, and the damage
it has already done should be more than enough to prove the hands-off
attitude is not viable. Am I the only one left on this list who actually
cares about Bitcoin's survival?
On 4/17/25 14:52, 'Antoine Poinsot' via Bitcoin Development Mailing List
wrote:
> Hi,
>
> Standardness rules exist for 3 mains reasons: mitigate DoS vectors,
> provide upgrade hooks, or as a nudge to deter some usages.
>
> Bitcoin Core will by default only relay and mine transactions with at
> most a single OP_RETURN output, with a scriptPubKey no larger than 83
> bytes. This standardness rule falls into the third category: it aims
> to mildly deter data storage while still allowing a less harmful
> alternative than using non-provably-unspendable outputs.
>
> Developers are now designing constructions that work around these
> limitations. An example is Clementine, the recently-announced Citrea
> bridge, which uses unspendable Taproot outputs to store data in its
> "WatchtowerChallenge" transaction due to the standardness restrictions
> on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent
> years that the nudge is ineffective to deter storing data onchain.
>
> Since the restrictions on the usage of OP_RETURN outputs encourage
> harmful practices while being ineffective in deterring unwanted usage,
> i propose to drop them. I suggest to start by lifting the restriction
> on the size of the scriptPubKey for OP_RETURN outputs, as a first
> minimal step to stop encouraging harmful behaviour, and to then
> proceed to lift the restriction on the number of OP_RETURN outputs per
> transactions.
>
> Antoine Poinsot
>
> [^0]: See section 6.1 of their whitepaper here
> https://citrea.xyz/clementine_whitepaper.pdf
> --
> 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/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk%3D%40protonmail.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/03be4934-f0ff-4b58-880d-861d63a4f970%40dashjr.org.
[-- Attachment #2: Type: text/html, Size: 5065 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 9:50 ` Luke Dashjr
@ 2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
0 siblings, 1 reply; 23+ messages in thread
From: Sjors Provoost @ 2025-04-26 10:53 UTC (permalink / raw)
To: bitcoindev; +Cc: Luke Dashjr
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
Op 26 apr 2025, om 11:50 heeft Luke Dashjr <luke@dashjr•org> het volgende geschreven:
> It should be needless to say, but this idea is utter insanity. Disappointing to see positive responses, and not one sensible reply calling it out yet. The bugs should be fixed, not the abuse embraced. If attackers continue to bypass filters, we can go back to a full whitelist approach.
>
Are you proposing a whitelist of authorised public keys? Or a transaction size increase?
Your earlier proposal [0] to whitelist certain script forms is not relevant here, because the Citrea white paper uses unspendable public keys to encode the data that doesn't fit in OP_RETURN.
To stop that, you'd have to introduce a rule that only allows spendable public keys to be put on chain. Afaik, the only way to do that is to require a signature. That would dramatically increase the size of all output scripts.
And that won't fix "spam" either, because you can still grind the first N bits of every public key and/signature, maybe encode things in the nonce, etc.
The cost of that would be trivial for a bridge system. And "art" systems mightly actually like the extra scarcity.
As for your earlier proposals (Ordisrespector, etc), they were not useful in general, because they rely too heavily on having standardness rules go against financial incentives. Only consensus changes can work, but so far you haven't proposed those. Since "spam" is a cat-and-mouse game, and consensus changes take ages to design, implement and roll out, it's also not a viable solution.
Increasing the OP_RETURN limit reduces harm compared to the two alternatives:
1. UTXO set bloating with fake public keys
2. Large scale bypassing of the (default) mempool, which leads to
a) compact block relay failures (mempool fragmentation)
b) centralisation
Custom-but-public relay networks like Libre Relay don't cause (2b), but (likely) do cause (2a). So it's not good if Bitcoin Core default policy heavily incentives such an alternative network. That's one reason why -mempoolfullrbf is now a default.
You're also not specifying what problem you're trying to solve. Nor what "damage" is done. If blocks are too big in your opinion, then why not simply propose a block size decrease (again)? I would not expect meaningful support for that either, but at least it's simple.
- Sjors
[0] https://github.com/bitcoin/bitcoin/issues/29187
--
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/CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl.
[-- Attachment #2: Type: text/html, Size: 3720 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 10:53 ` Sjors Provoost
@ 2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
0 siblings, 2 replies; 23+ messages in thread
From: Luke Dashjr @ 2025-04-26 11:35 UTC (permalink / raw)
To: Sjors Provoost, bitcoindev
On 4/26/25 06:53, Sjors Provoost wrote:
>
> Op 26 apr 2025, om 11:50 heeft Luke Dashjr <luke@dashjr•org> het
> volgende geschreven:
>>
>> It should be needless to say, but this idea is utter insanity.
>> Disappointing to see positive responses, and not one sensible reply
>> calling it out yet. The bugs should be fixed, not the abuse embraced.
>> If attackers continue to bypass filters, we can go back to a full
>> whitelist approach.
>>
> Are you proposing a whitelist of authorised public keys?
Scripts, of course, not specific keys. Just like we had early on. But
that is only necessary if the simpler filter steps are insufficient,
which is unlikely.
> Your earlier proposal [0] to whitelist certain script forms is not
> relevant here, because the Citrea white paper uses unspendable public
> keys to encode the data that doesn't fit in OP_RETURN.
>
> To stop that, you'd have to introduce a rule that only allows
> spendable public keys to be put on chain. Afaik, the only way to do
> that is to require a signature. That would dramatically increase the
> size of all output scripts.
Only during flood relay. They don't need to be included in blocks. Even
a softfork, should it become necessary, could potentially get away with
pruning them after being buried a certain depth.
> And that won't fix "spam" either, because you can still grind the
> first N bits of every public key and/signature, maybe encode things in
> the nonce, etc.
It's sufficient to make spam unwelcome and costly. No spam filtration
solution needs to be perfect. Every little bit helps.
> As for your earlier proposals (Ordisrespector, etc), they were not
> useful in general, because they rely too heavily on having
> standardness rules go against financial incentives. Only consensus
> changes can work, but so far you haven't proposed those.
That's nonsense. They were and continue to be very effective, even with
only a small amount of adoption. Further, mining centralization and
pools denying miners options has been the biggest barrier to that
adoption. There is no significant financial impact either, that's just
FUD; miners using the fixed and improved spam filters have in fact
earned significantly more than miners using Core.
> Since "spam" is a cat-and-mouse game, and consensus changes take ages
> to design, implement and roll out, it's also not a viable solution.
It would be a pain, but it is definitely viable. Thankfully, policy
works just fine for spam filtration, and can be adapted much quicker.
> Increasing the OP_RETURN limit reduces harm compared to the two
> alternatives:
> 1. UTXO set bloating with fake public keys
> 2. Large scale bypassing of the (default) mempool, which leads to
> a) compact block relay failures (mempool fragmentation)
The entire reason compact blocks were acceptable, is that miners are
incentivized to conform to non-miner node policies. Now you're trying to
bait-and-switch it to nodes conforming to malicious miner policies instead.
> b) centralisation
No, this is more FUD.
> Custom-but-public relay networks like Libre Relay don't cause (2b),
> but (likely) do cause (2a). So it's not good if Bitcoin Core default
> policy heavily incentives such an alternative network. That's one
> reason why -mempoolfullrbf is now a default.
>
> You're also not specifying what problem you're trying to solve. Nor
> what "damage" is done. If blocks are too big in your opinion, then why
> not simply propose a block size decrease (again)? I would not expect
> meaningful support for that either, but at least it's simple.
>
> - Sjors
>
> [0] https://github.com/bitcoin/bitcoin/issues/29187
>
--
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/d18b4149-5523-44bd-8332-2b7962f4b674%40dashjr.org.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 11:35 ` Luke Dashjr
@ 2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
1 sibling, 0 replies; 23+ messages in thread
From: Sjors Provoost @ 2025-04-26 11:45 UTC (permalink / raw)
To: Luke Dashjr, 'Bitcoin Development Mailing List'
> >> As for your earlier proposals (Ordisrespector, etc), they were not
>> useful in general, because they rely too heavily on having
>> standardness rules go against financial incentives. Only consensus
>> changes can work, but so far you haven't proposed those.
>
> That's nonsense. They were and continue to be very effective, even with
> only a small amount of adoption.
Further, mining centralization and
> pools denying miners options has been the biggest barrier to that
> adoption. There is no significant financial impact either, that's just
> FUD; miners using the fixed and improved spam filters have in fact
> earned significantly more than miners using Core.
I'll reply to your arguments when Ocean Pool reorgs a competitor block with inscriptions in it.
- Sjors
--
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/f348e4bf-ccc4-48e3-9745-ac72b1b131f5%40app.fastmail.com.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
@ 2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-05-01 3:01 ` Anthony Towns
1 sibling, 2 replies; 23+ messages in thread
From: Pieter Wuille @ 2025-04-26 12:48 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Sjors Provoost, bitcoindev
On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <luke@dashjr•org> wrote:
> That's nonsense. They were and continue to be very effective, even with
> only a small amount of adoption. Further, mining centralization and
Standardness rules have definitely been effective in the past, if we go far enough back in time. But back then:
* There were far less financial incentives to bypass them. Standardness adds inconvenience to people developing infrastructure on top, which can nudge in another direction. But I don't see how million-dollar (or more) business incentives would be thwarted by the need to communicate with miners directly (see below). These incentives will only increase as the subsidy dwindles.
* There was far more reason for rules of this kind; the network was small and far less valuable, and there were significant concerns about increased node operation cost with a quickly-growing blockchain. With blocks consistently full for most of the time for years now, even at times without so-called "spam", that concern just does not exist; nodes will be processing the same amount of transaction data anyway. I think I share Luke's feelings around non-financially-relevant transactions on-chain, but given sufficient demand for block space anyway, there just is no need to discriminate.
> pools denying miners options has been the biggest barrier to that
> adoption. There is no significant financial impact either, that's just
> FUD; miners using the fixed and improved spam filters have in fact
> earned significantly more than miners using Core.
I am doubtful of this claim, and would like to see evidence of it.
> It would be a pain, but it is definitely viable. Thankfully, policy
> works just fine for spam filtration, and can be adapted much quicker.
Nobody is required to adopt policy, and I think you're burying your head in the sand if you believe even in a world with more decentralized hashpower, miners/hashers would voluntarily choose to disregard transactions that pay a significant fee, if the potential gains from accepting them exceed the cost of building infrastructure to bypass whatever policy exists.
Bitcoin users do have a means to deny usage of the chain to truly damaging use: consensus changes. Those are not optional, apply to everyone equally, do not create incentives for bypass, and - and I believe that is a good thing - can only be adopted with very wide agreement.
> > b) centralisation
>
> No, this is more FUD.
The **entire** reason why Bitcoin uses PoW, as opposed to using a traditional consensus system with a federation of block-builders, is to avoid censorship. If anyone dislikes the choices current miners make in what transactions they accept, they can - without asking anyone for permission - join the set of miners, and earn a proportional piece of the pie. While it is the case that today mining power is quite concentrated in a number of businesses, the set of such businesses can, and has, changed over time. This is a very valuable property.
Part of the puzzle to make that permissionlessness of mining work is access to fee-paying transactions from the public. If sufficient economic demand exist for transactions that the public network denies, miners and creators of such transaction will develop transaction rails that bypass that network.
If it comes to a point where that economic demand is so high that miners need to rely on private transaction rails to realistically compete, I feel we'd be giving up on one of the most valuable properties the network has. I realize this is a slipstreamery-slope argument, but it is already happening, and once the rails are ubiquitous, it will be very hard to go back to a public network.
---
Because of all these reasons, Concept ACK on relaxing the OP_RETURN limits, including removing them entirely. I have been a strong proponent of these limits in the past, and I'm not happy with seeing the demand for those transactions. But I also recognize the reality that that demand exists, and the alternative of pushing that demand to bypass the public network is far more damaging.
I will add that I am not in favor of relaxing many other standardness rules in Bitcoin Core, such as transaction sizes and other resource limitations. These have significant impact on the public's ability to verify and relay transactions, and reason about incentive compatibility while doing so. Significant and sustained economic demand for such transactions may at some point too mean the policy needs to be revised to avoid an even worse outcome, but I'm hopeful that is not the case. However, these arguments do not apply to OP_RETURN limits, which don't serve an objective harm reduction beyond a subjective "that isn't what you should be using the chain for".
--
Pieter
--
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/QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs%3D%40wuille.net.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 12:48 ` Pieter Wuille
@ 2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-05-01 3:01 ` Anthony Towns
1 sibling, 2 replies; 23+ messages in thread
From: Jason Hughes (wk057) @ 2025-04-28 16:20 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 11151 bytes --]
I was asked to take my comments to the mailing list, so here we go.
First, see my comments on Github PR #32359:
- https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
- https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
- https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
Next, I'll once again point out relevant history for those just tuning in:
OP_RETURN was only made standard in a limited size to encourage less
harmful data carrying in Bitcoin. Attackers were using harmful methods of
data carrying in unspendable UTXOs, and so a way to inject a small amount
of data was TOLERABLE over this harmful UTXO bloat that. That mostly
worked, and such practices were quickly minimized. This remained the case
for about a decade without significant issue. Bitcoin is not file storage,
and this was known to developers at that time. Sadly, eventually an
exploit called 'inscriptions' happened which blew the cap off of the size
limitation of arbitrary data storage... and to make matters worse,
developers refused to patch the exploit or otherwise enforce the decade old
limit on arbitrary data size. If that wasn't bad enough, exploiters get a
75% discount on transaction fees.
With that history in mind, removing limits on OP_RETURN standardness size
is pointless. Relaxing OP_RETURN size limits without dealing with the
inscriptions exploit means no one will use this for anything besides
attacking the network with the worst possible data. There's little to no
incentive to use OP_RETURN for data storage when using the 'inscriptions'
exploit costs 4x less in transactions. What's the point of having a
"standard" way to store arbitrary data if the exploit method is 4x cheaper?
And the nonstandard version of the exploit allows 4x the data?
Further, the inscriptions exploit currently requires chunking the data
between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
reveal the underlying data the injector intended. I can still run
something like "photorec" on my system and not have to sift through
thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
this happenstance obfuscation that has saved us to-date. After this change,
when data is recovered from a full node system, whatever some anonymous
person decided to stuff into an OP_RETURN will be serialized in plaintext
directly on disk. For the low price of a few sats per byte, an attacker can
now directly poison the storage of every full node runner.
If you can't imagine the harm this will do to the ecosystem, let me paint
some pictures for you:
First, there's the obvious. Everyone running a node will now be guaranteed
to "posses and distribute" content that is likely illegal in their
jurisdiction. Not only are you storing this as a full node runner, you're
serving it to others. Hooray. /s
Next, there's less obvious abuses. For example, let's say I want to
distribute malware. Well, might as well just store it in an OP_RETURN.
Then, any time I compromise a system with a Bitcoin node I know my malware
is directly on their system in a mostly predetermined spot already and I
don't even need to retrieve it from elsewhere! And, even better, my malware
can use the Bitcoin P2P network itself to distribute itself. Just find a
willing full node, grab the block it's in. Thanks for the boost, node
runners!
Worse, in order to actually participate in the network, everyone MUST
download all of this data from others (who must host it for you), process
it, and generally must host it for others to do the same. The network can't
survive with 100% pruned nodes. I think too many users nowadays don't
understand that running a full node is the ONLY way to actually participate
in Bitcoin.
It's bad enough that chunked partly-obfuscated things exist on the systems
of full node runners today. It'll be even worse if that's unrestricted with
the removal of such limits.
As I said in my Github comment: This is far more than a small technical
change. This is a fundamental change to the nature of what the Bitcoin
network itself is in its entirety. Ten years ago, developers of the
reference implementation knew this, and acted in the best interest of
Bitcoin itself. Today, too many developers don't understand this duty.
That may sound like hyperbole, but it really isn't. If this change is
merged into Bitcoin Core, and Bitcoin Core then continues to be the
reference implementation... Bitcoin as we know it changes forever in the
most fundamental way imaginable: The reference implementation explicitly
turning the Bitcoin network into an arbitrary data storage system, instead
of evolving it as a decentralized currency.
That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
being a thing if this is the path chosen. There are very few paths that
lead to a worthless Bitcoin, and this is probably in the top 3 worst
options.
I can't understate this. It's one thing to refuse to act when faced with an
attack/exploit/etc. That takes actual courage and conviction to do what's
right for the ecosystem... and I _almost_ can't fault the current batch of
devs for not having that courage. However, it's another to openly make
sweeping changing to the ecosystem in an effort to make such things
acceptable.
Have the courage to reject this type of thing for the sake of the overall
project.
JH
aka wk057
aka wizkid057
On Saturday, April 26, 2025 at 8:50:59 AM UTC-4 Pieter Wuille wrote:
> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr•org>
> wrote:
>
> > That's nonsense. They were and continue to be very effective, even with
> > only a small amount of adoption. Further, mining centralization and
>
> Standardness rules have definitely been effective in the past, if we go
> far enough back in time. But back then:
>
> * There were far less financial incentives to bypass them. Standardness
> adds inconvenience to people developing infrastructure on top, which can
> nudge in another direction. But I don't see how million-dollar (or more)
> business incentives would be thwarted by the need to communicate with
> miners directly (see below). These incentives will only increase as the
> subsidy dwindles.
>
> * There was far more reason for rules of this kind; the network was small
> and far less valuable, and there were significant concerns about increased
> node operation cost with a quickly-growing blockchain. With blocks
> consistently full for most of the time for years now, even at times without
> so-called "spam", that concern just does not exist; nodes will be
> processing the same amount of transaction data anyway. I think I share
> Luke's feelings around non-financially-relevant transactions on-chain, but
> given sufficient demand for block space anyway, there just is no need to
> discriminate.
>
> > pools denying miners options has been the biggest barrier to that
> > adoption. There is no significant financial impact either, that's just
> > FUD; miners using the fixed and improved spam filters have in fact
> > earned significantly more than miners using Core.
>
> I am doubtful of this claim, and would like to see evidence of it.
>
> > It would be a pain, but it is definitely viable. Thankfully, policy
> > works just fine for spam filtration, and can be adapted much quicker.
>
> Nobody is required to adopt policy, and I think you're burying your head
> in the sand if you believe even in a world with more decentralized
> hashpower, miners/hashers would voluntarily choose to disregard
> transactions that pay a significant fee, if the potential gains from
> accepting them exceed the cost of building infrastructure to bypass
> whatever policy exists.
>
> Bitcoin users do have a means to deny usage of the chain to truly damaging
> use: consensus changes. Those are not optional, apply to everyone equally,
> do not create incentives for bypass, and - and I believe that is a good
> thing - can only be adopted with very wide agreement.
>
> > > b) centralisation
> >
> > No, this is more FUD.
>
> The **entire** reason why Bitcoin uses PoW, as opposed to using a
> traditional consensus system with a federation of block-builders, is to
> avoid censorship. If anyone dislikes the choices current miners make in
> what transactions they accept, they can - without asking anyone for
> permission - join the set of miners, and earn a proportional piece of the
> pie. While it is the case that today mining power is quite concentrated in
> a number of businesses, the set of such businesses can, and has, changed
> over time. This is a very valuable property.
>
> Part of the puzzle to make that permissionlessness of mining work is
> access to fee-paying transactions from the public. If sufficient economic
> demand exist for transactions that the public network denies, miners and
> creators of such transaction will develop transaction rails that bypass
> that network.
>
> If it comes to a point where that economic demand is so high that miners
> need to rely on private transaction rails to realistically compete, I feel
> we'd be giving up on one of the most valuable properties the network has. I
> realize this is a slipstreamery-slope argument, but it is already
> happening, and once the rails are ubiquitous, it will be very hard to go
> back to a public network.
>
> ---
>
> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
> limits, including removing them entirely. I have been a strong proponent of
> these limits in the past, and I'm not happy with seeing the demand for
> those transactions. But I also recognize the reality that that demand
> exists, and the alternative of pushing that demand to bypass the public
> network is far more damaging.
>
> I will add that I am not in favor of relaxing many other standardness
> rules in Bitcoin Core, such as transaction sizes and other resource
> limitations. These have significant impact on the public's ability to
> verify and relay transactions, and reason about incentive compatibility
> while doing so. Significant and sustained economic demand for such
> transactions may at some point too mean the policy needs to be revised to
> avoid an even worse outcome, but I'm hopeful that is not the case. However,
> these arguments do not apply to OP_RETURN limits, which don't serve an
> objective harm reduction beyond a subjective "that isn't what you should be
> using the chain for".
>
> --
> Pieter
>
>
--
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/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11781 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-28 16:20 ` Jason Hughes (wk057)
@ 2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-29 19:20 ` Martin Habovštiak
1 sibling, 1 reply; 23+ messages in thread
From: Sjors Provoost @ 2025-04-29 14:51 UTC (permalink / raw)
To: Bitcoin Development Mailing List
Hi Jason,
> OP_RETURN was only made standard in a limited size to encourage less harmful data carrying in Bitcoin.
That's correct.
> and this was known to developers at that time. Sadly, eventually an exploit called 'inscriptions' happened which blew the cap off of the size limitation of arbitrary data storage... and to make matters worse, developers refused to patch the exploit or otherwise enforce the decade old limit on arbitrary data size.
If you look at the actual pull requests that implement such patches you'll discover the various reasons why they were rejected. This mailinglist thread has also re-iterated the futility of this cat-and-mouse game. It contains the relevant links, so I'm not going to repeat them here.
> If that wasn't bad enough, exploiters get a 75% discount on transaction fees.
At the time SegWit was proposed it was clear that the worst case block size would increase to 4 MB. It took a few years for people to figure out how to take advantage of that. Somewhere between 2015 and early 2017 would have been good time to object to the SegWit discount, but removing it now would be a hard fork. Fwiw I think the discount was a good idea.
> What's the point of having a "standard" way to store arbitrary data if the exploit method is 4x cheaper? And the nonstandard version of the exploit allows 4x the data?
What you call "nonstandard" is actually standard. Inscriptions follow standardness rules.
In general you're reasoning the wrong around imo. There is no point in restricting transactions that are 4x more expensive than the alternative. And as was explained earlier in this thread by me and others, if we don't drop this limit then the UTXO set will get bloated. Just as you point out was the historical issue.
Bitcoin Core used to have a whitelist model where only a few transaction blessed by Satoshi were standard. I think it's good that we moved away from that to where you typically don't have to lobby for your transaction type to be included. But others disagree, e.g. Luke Dashr in this thread proposed going back to that model.
> Further, the inscriptions exploit currently requires chunking the data between PUSH opcodes
The issue of consecutive byte sequences stored on disk is intestering. But imo it has been fully addressed on the Github PR now: https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2838068278
In summary:
1. The mempool is encrypted at rest
2. The blockchain is encrypted at rest for (relatively) new users, but not for everyone. However, it is already trivial to inject arbitrary data into the blockchain.
This change does not make the problem worse.
> That may sound like hyperbole, but it really isn't.
It's irrelevant because this PR does not change the threats you are worried about.
> Today, too many developers don't understand this duty.
If you don't have confidence in the Bitcoin Core developers, instead of insulting them, you could also just (help) maintain a fork of the project. Working on Knots seems the easiest way to do that. I obviously think you're misguided here, but at least it's better to channel this distrust into something constructive. Given the number of people who share your sentiment, such a project should be perfectly viable.
- Sjors
--
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/4DAF69CE-2AA6-4429-9F3C-91030C88A88B%40sprovoost.nl.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
@ 2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-04-30 5:39 ` Chris Guida
1 sibling, 2 replies; 23+ messages in thread
From: Martin Habovštiak @ 2025-04-29 19:20 UTC (permalink / raw)
To: Jason Hughes (wk057); +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 13514 bytes --]
Hi,
I have a little demo for you.
Firstly, I think the kind of illegal content most people have in mind are
images. So let's start with a question: if one takes an illegal picture and
sets every 173th pixel to a red dot will it become legal?
If you have trouble imagining it, here's an example for you:
https://imgur.com/a/J7RTPL7
If you believe it would, we can end this conversation and my point is moot.
However, I think you'll agree the image would still be illegal.
Next, I think it's obvious that an attacker seeking to harm bitcoin users
would choose an any image format he likes. So for this example I'm picking
BMP.
If you encode the image above to BMP, which is uncompressed, the red pixels
turn into bytes 253, 7, 2 which happen to encode witness element length
519. The header size is 54 bytes, so stick the byte 54 at the front and you
have a valid serialization of a sequence of witness elements.
Do you see what this means?
...
Yes, it's too late to fix this. It's already trivially possible to make
your node store a sequence of bytes that is considered illegal. If you're
worried about it you have to resync the chain right now.
Disclaimer: the numbers above might be a bit off, I did most computation in
my head. Still, the point stands even if the pixels have a bit different
spacing/color.
Same thing with malware distribution, except you can easily skip the
invalid bytes using jump instructions or other techniques, so that might be
even worse.
Happy syncing!
Martin
Dňa ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizkid057@gmail•com>
napísal(a):
> I was asked to take my comments to the mailing list, so here we go.
>
> First, see my comments on Github PR #32359:
> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
>
> Next, I'll once again point out relevant history for those just tuning in:
>
> OP_RETURN was only made standard in a limited size to encourage less
> harmful data carrying in Bitcoin. Attackers were using harmful methods of
> data carrying in unspendable UTXOs, and so a way to inject a small amount
> of data was TOLERABLE over this harmful UTXO bloat that. That mostly
> worked, and such practices were quickly minimized. This remained the case
> for about a decade without significant issue. Bitcoin is not file storage,
> and this was known to developers at that time. Sadly, eventually an
> exploit called 'inscriptions' happened which blew the cap off of the size
> limitation of arbitrary data storage... and to make matters worse,
> developers refused to patch the exploit or otherwise enforce the decade old
> limit on arbitrary data size. If that wasn't bad enough, exploiters get a
> 75% discount on transaction fees.
>
> With that history in mind, removing limits on OP_RETURN standardness size
> is pointless. Relaxing OP_RETURN size limits without dealing with the
> inscriptions exploit means no one will use this for anything besides
> attacking the network with the worst possible data. There's little to no
> incentive to use OP_RETURN for data storage when using the 'inscriptions'
> exploit costs 4x less in transactions. What's the point of having a
> "standard" way to store arbitrary data if the exploit method is 4x cheaper?
> And the nonstandard version of the exploit allows 4x the data?
>
> Further, the inscriptions exploit currently requires chunking the data
> between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
> reveal the underlying data the injector intended. I can still run
> something like "photorec" on my system and not have to sift through
> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
> this happenstance obfuscation that has saved us to-date. After this change,
> when data is recovered from a full node system, whatever some anonymous
> person decided to stuff into an OP_RETURN will be serialized in plaintext
> directly on disk. For the low price of a few sats per byte, an attacker can
> now directly poison the storage of every full node runner.
>
> If you can't imagine the harm this will do to the ecosystem, let me paint
> some pictures for you:
>
> First, there's the obvious. Everyone running a node will now be guaranteed
> to "posses and distribute" content that is likely illegal in their
> jurisdiction. Not only are you storing this as a full node runner, you're
> serving it to others. Hooray. /s
>
> Next, there's less obvious abuses. For example, let's say I want to
> distribute malware. Well, might as well just store it in an OP_RETURN.
> Then, any time I compromise a system with a Bitcoin node I know my malware
> is directly on their system in a mostly predetermined spot already and I
> don't even need to retrieve it from elsewhere! And, even better, my malware
> can use the Bitcoin P2P network itself to distribute itself. Just find a
> willing full node, grab the block it's in. Thanks for the boost, node
> runners!
>
> Worse, in order to actually participate in the network, everyone MUST
> download all of this data from others (who must host it for you), process
> it, and generally must host it for others to do the same. The network can't
> survive with 100% pruned nodes. I think too many users nowadays don't
> understand that running a full node is the ONLY way to actually participate
> in Bitcoin.
>
> It's bad enough that chunked partly-obfuscated things exist on the systems
> of full node runners today. It'll be even worse if that's unrestricted with
> the removal of such limits.
>
> As I said in my Github comment: This is far more than a small technical
> change. This is a fundamental change to the nature of what the Bitcoin
> network itself is in its entirety. Ten years ago, developers of the
> reference implementation knew this, and acted in the best interest of
> Bitcoin itself. Today, too many developers don't understand this duty.
>
> That may sound like hyperbole, but it really isn't. If this change is
> merged into Bitcoin Core, and Bitcoin Core then continues to be the
> reference implementation... Bitcoin as we know it changes forever in the
> most fundamental way imaginable: The reference implementation explicitly
> turning the Bitcoin network into an arbitrary data storage system, instead
> of evolving it as a decentralized currency.
>
> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
> being a thing if this is the path chosen. There are very few paths that
> lead to a worthless Bitcoin, and this is probably in the top 3 worst
> options.
>
> I can't understate this. It's one thing to refuse to act when faced with
> an attack/exploit/etc. That takes actual courage and conviction to do
> what's right for the ecosystem... and I _almost_ can't fault the current
> batch of devs for not having that courage. However, it's another to openly
> make sweeping changing to the ecosystem in an effort to make such things
> acceptable.
>
> Have the courage to reject this type of thing for the sake of the overall
> project.
>
> JH
> aka wk057
> aka wizkid057
> On Saturday, April 26, 2025 at 8:50:59 AM UTC-4 Pieter Wuille wrote:
>
>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr•org>
>> wrote:
>>
>> > That's nonsense. They were and continue to be very effective, even with
>> > only a small amount of adoption. Further, mining centralization and
>>
>> Standardness rules have definitely been effective in the past, if we go
>> far enough back in time. But back then:
>>
>> * There were far less financial incentives to bypass them. Standardness
>> adds inconvenience to people developing infrastructure on top, which can
>> nudge in another direction. But I don't see how million-dollar (or more)
>> business incentives would be thwarted by the need to communicate with
>> miners directly (see below). These incentives will only increase as the
>> subsidy dwindles.
>>
>> * There was far more reason for rules of this kind; the network was small
>> and far less valuable, and there were significant concerns about increased
>> node operation cost with a quickly-growing blockchain. With blocks
>> consistently full for most of the time for years now, even at times without
>> so-called "spam", that concern just does not exist; nodes will be
>> processing the same amount of transaction data anyway. I think I share
>> Luke's feelings around non-financially-relevant transactions on-chain, but
>> given sufficient demand for block space anyway, there just is no need to
>> discriminate.
>>
>> > pools denying miners options has been the biggest barrier to that
>> > adoption. There is no significant financial impact either, that's just
>> > FUD; miners using the fixed and improved spam filters have in fact
>> > earned significantly more than miners using Core.
>>
>> I am doubtful of this claim, and would like to see evidence of it.
>>
>> > It would be a pain, but it is definitely viable. Thankfully, policy
>> > works just fine for spam filtration, and can be adapted much quicker.
>>
>> Nobody is required to adopt policy, and I think you're burying your head
>> in the sand if you believe even in a world with more decentralized
>> hashpower, miners/hashers would voluntarily choose to disregard
>> transactions that pay a significant fee, if the potential gains from
>> accepting them exceed the cost of building infrastructure to bypass
>> whatever policy exists.
>>
>> Bitcoin users do have a means to deny usage of the chain to truly
>> damaging use: consensus changes. Those are not optional, apply to everyone
>> equally, do not create incentives for bypass, and - and I believe that is a
>> good thing - can only be adopted with very wide agreement.
>>
>> > > b) centralisation
>> >
>> > No, this is more FUD.
>>
>> The **entire** reason why Bitcoin uses PoW, as opposed to using a
>> traditional consensus system with a federation of block-builders, is to
>> avoid censorship. If anyone dislikes the choices current miners make in
>> what transactions they accept, they can - without asking anyone for
>> permission - join the set of miners, and earn a proportional piece of the
>> pie. While it is the case that today mining power is quite concentrated in
>> a number of businesses, the set of such businesses can, and has, changed
>> over time. This is a very valuable property.
>>
>> Part of the puzzle to make that permissionlessness of mining work is
>> access to fee-paying transactions from the public. If sufficient economic
>> demand exist for transactions that the public network denies, miners and
>> creators of such transaction will develop transaction rails that bypass
>> that network.
>>
>> If it comes to a point where that economic demand is so high that miners
>> need to rely on private transaction rails to realistically compete, I feel
>> we'd be giving up on one of the most valuable properties the network has. I
>> realize this is a slipstreamery-slope argument, but it is already
>> happening, and once the rails are ubiquitous, it will be very hard to go
>> back to a public network.
>>
>> ---
>>
>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
>> limits, including removing them entirely. I have been a strong proponent of
>> these limits in the past, and I'm not happy with seeing the demand for
>> those transactions. But I also recognize the reality that that demand
>> exists, and the alternative of pushing that demand to bypass the public
>> network is far more damaging.
>>
>> I will add that I am not in favor of relaxing many other standardness
>> rules in Bitcoin Core, such as transaction sizes and other resource
>> limitations. These have significant impact on the public's ability to
>> verify and relay transactions, and reason about incentive compatibility
>> while doing so. Significant and sustained economic demand for such
>> transactions may at some point too mean the policy needs to be revised to
>> avoid an even worse outcome, but I'm hopeful that is not the case. However,
>> these arguments do not apply to OP_RETURN limits, which don't serve an
>> objective harm reduction beyond a subjective "that isn't what you should be
>> using the chain for".
>>
>> --
>> Pieter
>>
>> --
> 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/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%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/CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15560 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-29 19:20 ` Martin Habovštiak
@ 2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
1 sibling, 1 reply; 23+ messages in thread
From: Jason Hughes @ 2025-04-30 0:10 UTC (permalink / raw)
To: Martin Habovštiak; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 14698 bytes --]
I believe you greatly overestimate the skill and competence of the people
who would do this type of thing. You could accomplish what you've laid out.
I could accomplish it. But the people who will actually do this to Bitcoin
once there's unrestricted OP_RETURN likely can not accomplish it today.
What you've laid out is a more technical attack than this variant of attack
is capable of... and what will actually happen is that once unlimited
OP_RETURN is a thing, people willing to, but not currently able, will take
the easy route for such attacks after someone with technical knowledge
makes the "Connect your wallet, upload your data" button for them.
All of that said, you make excellent points for ridding Bitcoin of
arbitrary data completely. :)
On Tue, Apr 29, 2025 at 3:20 PM Martin Habovštiak <
martin.habovstiak@gmail•com> wrote:
> Hi,
>
> I have a little demo for you.
>
> Firstly, I think the kind of illegal content most people have in mind are
> images. So let's start with a question: if one takes an illegal picture and
> sets every 173th pixel to a red dot will it become legal?
>
> If you have trouble imagining it, here's an example for you:
> https://imgur.com/a/J7RTPL7
>
> If you believe it would, we can end this conversation and my point is moot.
> However, I think you'll agree the image would still be illegal.
>
> Next, I think it's obvious that an attacker seeking to harm bitcoin users
> would choose an any image format he likes. So for this example I'm picking
> BMP.
>
> If you encode the image above to BMP, which is uncompressed, the red
> pixels turn into bytes 253, 7, 2 which happen to encode witness element
> length 519. The header size is 54 bytes, so stick the byte 54 at the front
> and you have a valid serialization of a sequence of witness elements.
>
> Do you see what this means?
>
>
> ...
>
>
> Yes, it's too late to fix this. It's already trivially possible to make
> your node store a sequence of bytes that is considered illegal. If you're
> worried about it you have to resync the chain right now.
>
> Disclaimer: the numbers above might be a bit off, I did most computation
> in my head. Still, the point stands even if the pixels have a bit different
> spacing/color.
>
> Same thing with malware distribution, except you can easily skip the
> invalid bytes using jump instructions or other techniques, so that might be
> even worse.
>
> Happy syncing!
>
> Martin
>
>
> Dňa ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizkid057@gmail•com>
> napísal(a):
>
>> I was asked to take my comments to the mailing list, so here we go.
>>
>> First, see my comments on Github PR #32359:
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
>>
>> Next, I'll once again point out relevant history for those just tuning in:
>>
>> OP_RETURN was only made standard in a limited size to encourage less
>> harmful data carrying in Bitcoin. Attackers were using harmful methods of
>> data carrying in unspendable UTXOs, and so a way to inject a small amount
>> of data was TOLERABLE over this harmful UTXO bloat that. That mostly
>> worked, and such practices were quickly minimized. This remained the case
>> for about a decade without significant issue. Bitcoin is not file storage,
>> and this was known to developers at that time. Sadly, eventually an
>> exploit called 'inscriptions' happened which blew the cap off of the size
>> limitation of arbitrary data storage... and to make matters worse,
>> developers refused to patch the exploit or otherwise enforce the decade old
>> limit on arbitrary data size. If that wasn't bad enough, exploiters get a
>> 75% discount on transaction fees.
>>
>> With that history in mind, removing limits on OP_RETURN standardness size
>> is pointless. Relaxing OP_RETURN size limits without dealing with the
>> inscriptions exploit means no one will use this for anything besides
>> attacking the network with the worst possible data. There's little to no
>> incentive to use OP_RETURN for data storage when using the 'inscriptions'
>> exploit costs 4x less in transactions. What's the point of having a
>> "standard" way to store arbitrary data if the exploit method is 4x cheaper?
>> And the nonstandard version of the exploit allows 4x the data?
>>
>> Further, the inscriptions exploit currently requires chunking the data
>> between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
>> reveal the underlying data the injector intended. I can still run
>> something like "photorec" on my system and not have to sift through
>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
>> this happenstance obfuscation that has saved us to-date. After this change,
>> when data is recovered from a full node system, whatever some anonymous
>> person decided to stuff into an OP_RETURN will be serialized in plaintext
>> directly on disk. For the low price of a few sats per byte, an attacker can
>> now directly poison the storage of every full node runner.
>>
>> If you can't imagine the harm this will do to the ecosystem, let me paint
>> some pictures for you:
>>
>> First, there's the obvious. Everyone running a node will now be
>> guaranteed to "posses and distribute" content that is likely illegal in
>> their jurisdiction. Not only are you storing this as a full node runner,
>> you're serving it to others. Hooray. /s
>>
>> Next, there's less obvious abuses. For example, let's say I want to
>> distribute malware. Well, might as well just store it in an OP_RETURN.
>> Then, any time I compromise a system with a Bitcoin node I know my malware
>> is directly on their system in a mostly predetermined spot already and I
>> don't even need to retrieve it from elsewhere! And, even better, my malware
>> can use the Bitcoin P2P network itself to distribute itself. Just find a
>> willing full node, grab the block it's in. Thanks for the boost, node
>> runners!
>>
>> Worse, in order to actually participate in the network, everyone MUST
>> download all of this data from others (who must host it for you), process
>> it, and generally must host it for others to do the same. The network can't
>> survive with 100% pruned nodes. I think too many users nowadays don't
>> understand that running a full node is the ONLY way to actually participate
>> in Bitcoin.
>>
>> It's bad enough that chunked partly-obfuscated things exist on the
>> systems of full node runners today. It'll be even worse if that's
>> unrestricted with the removal of such limits.
>>
>> As I said in my Github comment: This is far more than a small technical
>> change. This is a fundamental change to the nature of what the Bitcoin
>> network itself is in its entirety. Ten years ago, developers of the
>> reference implementation knew this, and acted in the best interest of
>> Bitcoin itself. Today, too many developers don't understand this duty.
>>
>> That may sound like hyperbole, but it really isn't. If this change is
>> merged into Bitcoin Core, and Bitcoin Core then continues to be the
>> reference implementation... Bitcoin as we know it changes forever in the
>> most fundamental way imaginable: The reference implementation explicitly
>> turning the Bitcoin network into an arbitrary data storage system, instead
>> of evolving it as a decentralized currency.
>>
>> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
>> being a thing if this is the path chosen. There are very few paths that
>> lead to a worthless Bitcoin, and this is probably in the top 3 worst
>> options.
>>
>> I can't understate this. It's one thing to refuse to act when faced with
>> an attack/exploit/etc. That takes actual courage and conviction to do
>> what's right for the ecosystem... and I _almost_ can't fault the current
>> batch of devs for not having that courage. However, it's another to openly
>> make sweeping changing to the ecosystem in an effort to make such things
>> acceptable.
>>
>> Have the courage to reject this type of thing for the sake of the overall
>> project.
>>
>> JH
>> aka wk057
>> aka wizkid057
>> On Saturday, April 26, 2025 at 8:50:59 AM UTC-4 Pieter Wuille wrote:
>>
>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr•org>
>>> wrote:
>>>
>>> > That's nonsense. They were and continue to be very effective, even
>>> with
>>> > only a small amount of adoption. Further, mining centralization and
>>>
>>> Standardness rules have definitely been effective in the past, if we go
>>> far enough back in time. But back then:
>>>
>>> * There were far less financial incentives to bypass them. Standardness
>>> adds inconvenience to people developing infrastructure on top, which can
>>> nudge in another direction. But I don't see how million-dollar (or more)
>>> business incentives would be thwarted by the need to communicate with
>>> miners directly (see below). These incentives will only increase as the
>>> subsidy dwindles.
>>>
>>> * There was far more reason for rules of this kind; the network was
>>> small and far less valuable, and there were significant concerns about
>>> increased node operation cost with a quickly-growing blockchain. With
>>> blocks consistently full for most of the time for years now, even at times
>>> without so-called "spam", that concern just does not exist; nodes will be
>>> processing the same amount of transaction data anyway. I think I share
>>> Luke's feelings around non-financially-relevant transactions on-chain, but
>>> given sufficient demand for block space anyway, there just is no need to
>>> discriminate.
>>>
>>> > pools denying miners options has been the biggest barrier to that
>>> > adoption. There is no significant financial impact either, that's just
>>> > FUD; miners using the fixed and improved spam filters have in fact
>>> > earned significantly more than miners using Core.
>>>
>>> I am doubtful of this claim, and would like to see evidence of it.
>>>
>>> > It would be a pain, but it is definitely viable. Thankfully, policy
>>> > works just fine for spam filtration, and can be adapted much quicker.
>>>
>>> Nobody is required to adopt policy, and I think you're burying your head
>>> in the sand if you believe even in a world with more decentralized
>>> hashpower, miners/hashers would voluntarily choose to disregard
>>> transactions that pay a significant fee, if the potential gains from
>>> accepting them exceed the cost of building infrastructure to bypass
>>> whatever policy exists.
>>>
>>> Bitcoin users do have a means to deny usage of the chain to truly
>>> damaging use: consensus changes. Those are not optional, apply to everyone
>>> equally, do not create incentives for bypass, and - and I believe that is a
>>> good thing - can only be adopted with very wide agreement.
>>>
>>> > > b) centralisation
>>> >
>>> > No, this is more FUD.
>>>
>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a
>>> traditional consensus system with a federation of block-builders, is to
>>> avoid censorship. If anyone dislikes the choices current miners make in
>>> what transactions they accept, they can - without asking anyone for
>>> permission - join the set of miners, and earn a proportional piece of the
>>> pie. While it is the case that today mining power is quite concentrated in
>>> a number of businesses, the set of such businesses can, and has, changed
>>> over time. This is a very valuable property.
>>>
>>> Part of the puzzle to make that permissionlessness of mining work is
>>> access to fee-paying transactions from the public. If sufficient economic
>>> demand exist for transactions that the public network denies, miners and
>>> creators of such transaction will develop transaction rails that bypass
>>> that network.
>>>
>>> If it comes to a point where that economic demand is so high that miners
>>> need to rely on private transaction rails to realistically compete, I feel
>>> we'd be giving up on one of the most valuable properties the network has. I
>>> realize this is a slipstreamery-slope argument, but it is already
>>> happening, and once the rails are ubiquitous, it will be very hard to go
>>> back to a public network.
>>>
>>> ---
>>>
>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
>>> limits, including removing them entirely. I have been a strong proponent of
>>> these limits in the past, and I'm not happy with seeing the demand for
>>> those transactions. But I also recognize the reality that that demand
>>> exists, and the alternative of pushing that demand to bypass the public
>>> network is far more damaging.
>>>
>>> I will add that I am not in favor of relaxing many other standardness
>>> rules in Bitcoin Core, such as transaction sizes and other resource
>>> limitations. These have significant impact on the public's ability to
>>> verify and relay transactions, and reason about incentive compatibility
>>> while doing so. Significant and sustained economic demand for such
>>> transactions may at some point too mean the policy needs to be revised to
>>> avoid an even worse outcome, but I'm hopeful that is not the case. However,
>>> these arguments do not apply to OP_RETURN limits, which don't serve an
>>> objective harm reduction beyond a subjective "that isn't what you should be
>>> using the chain for".
>>>
>>> --
>>> Pieter
>>>
>>> --
>> 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/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
*Jason Hughes*
--
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/CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 17010 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
@ 2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
1 sibling, 1 reply; 23+ messages in thread
From: Chris Guida @ 2025-04-30 5:39 UTC (permalink / raw)
To: Martin Habovštiak
Cc: Jason Hughes (wk057), Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 20261 bytes --]
Good morning devs!
It was suggested in two different PRs ([0] and [1]) that the conceptual
discussion take place in this thread, so I am submitting my comments here.
We are under a spam attack. This is not the first time this has happened.
Bitcoin has endured several spam attacks in the past. They subside when
bitcoin core devs show that they are serious about countering the attacks.
This excellent summary from BitMEX[2] illustrates how altcoin-Ponzi
spammers simply went elsewhere when the core maintainers at the time
demonstrated a willingness to filter every new abusive transaction format
until the spammers were exhausted.
We should not give up this time around! We should send the spammers back to
Ethereum where they belong. This battle is worth fighting, in order to
preserve bitcoin's status as the best medium of exchange and store of value
the world has ever seen.
As history shows, the battle is winnable. Filter authors can keep writing
new filters long after the VCs funding these abusive ventures have become
insolvent.
Unfortunately, the bitcoin core project made a misstep when it rejected
this PR[3] from Luke-jr to filter transactions using the op_false op_if
envelope to exploit the witness discount. This signaled to the community
that bitcoin core was no longer willing to merge filters for new kinds of
spam, even if filter authors were perfectly willing to write them. This, of
course, also had the effect of signaling to the altcoin Ponzi creators that
it was open season to spam the blockchain.
What followed next was the most massive wave of spam we've ever seen.
Onboarding of new users to bitcoin ground to a halt as fees soared. Users
in poor countries were, of course, impacted the most[4].
I've seen lots of comments from anti-filter activists that "we shouldn't
filter transaction types that have significant economic demand", but what
these always fail to point out is that bitcoin core itself created this
demand, by its ambivalence toward countering the spam. If Luke's PR had
been merged, that would have been the end of it. Perhaps there would have
been one or two copycats trying to get around the filters, but swift action
by bitcoin core would have nipped those in the bud. At that point, funding
for altcoin Ponzis built on bitcoin would have shriveled up or moved to
other chains, just as it did in 2014.
Instead, we saw a sudden rush of new Ponzi schemes, all promising something
new and innovative, because Ponzis on bitcoin, which were once treated with
hostility, were now tacitly approved. Bitcoin core continued to double down
on its "no more filters" policy[5], and the feeding frenzy of Ponzis
reached a fever pitch.
Another trope from the anti-filter crowd I keep seeing is that spam
protection is a "cat-and-mouse" game. Well, the cat won in 2014 and the
mouse didn't come back until 2023. The cat has seemingly forgotten how to
chase away the mouse, even though neither it nor the mouse has changed. The
spammers have a bit more of a headstart than they did in 2014, perhaps, but
that doesn't mean filter authors couldn't absolutely crush the entire
"Ponzis on top of bitcoin spam" industry if the core maintainers would
simply allow the filter authors to do their job. This isn't a matter of
lack of will or manpower. There are plenty of devs willing to write filters
for new spam formats as soon as they are announced, myself included. The
problem is that core has signaled that, even if the filters are written, it
will reject them, and that valuable labor will be lost. This is
understandably demoralizing and has a chilling effect on devs who would
otherwise be doing this important work.
We don't need to make sure no spam ever reaches the blockchain. That is, of
course, impossible. All we need to do is show active hostility to the
spammers, and the worst schemes (the ones that rely on a consistent
transaction format) will be impossible to maintain, and will therefore lose
funding. Of course there will be hobbyist spammers here and there, but
that's much less damaging.
We are at a crossroads. Because of bitcoin core's hostility toward filter
devs, the "economic demand" that everyone cites as the reason to allow more
spam has steadily grown larger and is now crushingly huge. The firehose of
spam that will be unleashed if we continue to appease the Ponzi spammers
will eventually make bitcoin unusable as a trustless medium of exchange,
and being a great medium of exchange is, of course, the main reason bitcoin
has any value at all.
If we boldly rise to the challenge and fight back against the Ponzi
spammers, then bitcoin has a bright future, perhaps becoming the dominant
global medium of exchange and even the reserve asset. The Lightning Network
is awe-inspiring and game-changing, and the devs who built it and finally
made it a great UX are heroes. I can't wait to see where it takes us in the
coming years!
However, if we instead cower in the corner and let fiat VCs trick us into
thinking their spammy Ponzis are scary and not just silly mice we can chase
away, then bitcoin's future is not so bright. We need only look at Ethereum
to see what's waiting for us down that road.
It's up to us, and I'm confident that we will prevail, because history
shows that bitcoiners are resourceful and never give up.
Sincerely,
--Chris Guida
[0]: https://github.com/bitcoin/bitcoin/pull/32359
[1]: https://github.com/bitcoin/bitcoin/pull/32381
[2]:
https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/
[3]: https://github.com/bitcoin/bitcoin/pull/28408
[4]: https://x.com/AnitaPosch/status/1732722398359638414
[5]: https://github.com/bitcoin/bitcoin/pull/28217
On Tue, Apr 29, 2025 at 1:24 PM Martin Habovštiak <
martin.habovstiak@gmail•com> wrote:
> Hi,
>
> I have a little demo for you.
>
> Firstly, I think the kind of illegal content most people have in mind are
> images. So let's start with a question: if one takes an illegal picture and
> sets every 173th pixel to a red dot will it become legal?
>
> If you have trouble imagining it, here's an example for you:
> https://imgur.com/a/J7RTPL7
>
> If you believe it would, we can end this conversation and my point is moot.
> However, I think you'll agree the image would still be illegal.
>
> Next, I think it's obvious that an attacker seeking to harm bitcoin users
> would choose an any image format he likes. So for this example I'm picking
> BMP.
>
> If you encode the image above to BMP, which is uncompressed, the red
> pixels turn into bytes 253, 7, 2 which happen to encode witness element
> length 519. The header size is 54 bytes, so stick the byte 54 at the front
> and you have a valid serialization of a sequence of witness elements.
>
> Do you see what this means?
>
>
> ...
>
>
> Yes, it's too late to fix this. It's already trivially possible to make
> your node store a sequence of bytes that is considered illegal. If you're
> worried about it you have to resync the chain right now.
>
> Disclaimer: the numbers above might be a bit off, I did most computation
> in my head. Still, the point stands even if the pixels have a bit different
> spacing/color.
>
> Same thing with malware distribution, except you can easily skip the
> invalid bytes using jump instructions or other techniques, so that might be
> even worse.
>
> Happy syncing!
>
> Martin
>
>
> Dňa ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizkid057@gmail•com>
> napísal(a):
>
>> I was asked to take my comments to the mailing list, so here we go.
>>
>> First, see my comments on Github PR #32359:
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
>>
>> Next, I'll once again point out relevant history for those just tuning in:
>>
>> OP_RETURN was only made standard in a limited size to encourage less
>> harmful data carrying in Bitcoin. Attackers were using harmful methods of
>> data carrying in unspendable UTXOs, and so a way to inject a small amount
>> of data was TOLERABLE over this harmful UTXO bloat that. That mostly
>> worked, and such practices were quickly minimized. This remained the case
>> for about a decade without significant issue. Bitcoin is not file storage,
>> and this was known to developers at that time. Sadly, eventually an
>> exploit called 'inscriptions' happened which blew the cap off of the size
>> limitation of arbitrary data storage... and to make matters worse,
>> developers refused to patch the exploit or otherwise enforce the decade old
>> limit on arbitrary data size. If that wasn't bad enough, exploiters get a
>> 75% discount on transaction fees.
>>
>> With that history in mind, removing limits on OP_RETURN standardness size
>> is pointless. Relaxing OP_RETURN size limits without dealing with the
>> inscriptions exploit means no one will use this for anything besides
>> attacking the network with the worst possible data. There's little to no
>> incentive to use OP_RETURN for data storage when using the 'inscriptions'
>> exploit costs 4x less in transactions. What's the point of having a
>> "standard" way to store arbitrary data if the exploit method is 4x cheaper?
>> And the nonstandard version of the exploit allows 4x the data?
>>
>> Further, the inscriptions exploit currently requires chunking the data
>> between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
>> reveal the underlying data the injector intended. I can still run
>> something like "photorec" on my system and not have to sift through
>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
>> this happenstance obfuscation that has saved us to-date. After this change,
>> when data is recovered from a full node system, whatever some anonymous
>> person decided to stuff into an OP_RETURN will be serialized in plaintext
>> directly on disk. For the low price of a few sats per byte, an attacker can
>> now directly poison the storage of every full node runner.
>>
>> If you can't imagine the harm this will do to the ecosystem, let me paint
>> some pictures for you:
>>
>> First, there's the obvious. Everyone running a node will now be
>> guaranteed to "posses and distribute" content that is likely illegal in
>> their jurisdiction. Not only are you storing this as a full node runner,
>> you're serving it to others. Hooray. /s
>>
>> Next, there's less obvious abuses. For example, let's say I want to
>> distribute malware. Well, might as well just store it in an OP_RETURN.
>> Then, any time I compromise a system with a Bitcoin node I know my malware
>> is directly on their system in a mostly predetermined spot already and I
>> don't even need to retrieve it from elsewhere! And, even better, my malware
>> can use the Bitcoin P2P network itself to distribute itself. Just find a
>> willing full node, grab the block it's in. Thanks for the boost, node
>> runners!
>>
>> Worse, in order to actually participate in the network, everyone MUST
>> download all of this data from others (who must host it for you), process
>> it, and generally must host it for others to do the same. The network can't
>> survive with 100% pruned nodes. I think too many users nowadays don't
>> understand that running a full node is the ONLY way to actually participate
>> in Bitcoin.
>>
>> It's bad enough that chunked partly-obfuscated things exist on the
>> systems of full node runners today. It'll be even worse if that's
>> unrestricted with the removal of such limits.
>>
>> As I said in my Github comment: This is far more than a small technical
>> change. This is a fundamental change to the nature of what the Bitcoin
>> network itself is in its entirety. Ten years ago, developers of the
>> reference implementation knew this, and acted in the best interest of
>> Bitcoin itself. Today, too many developers don't understand this duty.
>>
>> That may sound like hyperbole, but it really isn't. If this change is
>> merged into Bitcoin Core, and Bitcoin Core then continues to be the
>> reference implementation... Bitcoin as we know it changes forever in the
>> most fundamental way imaginable: The reference implementation explicitly
>> turning the Bitcoin network into an arbitrary data storage system, instead
>> of evolving it as a decentralized currency.
>>
>> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
>> being a thing if this is the path chosen. There are very few paths that
>> lead to a worthless Bitcoin, and this is probably in the top 3 worst
>> options.
>>
>> I can't understate this. It's one thing to refuse to act when faced with
>> an attack/exploit/etc. That takes actual courage and conviction to do
>> what's right for the ecosystem... and I _almost_ can't fault the current
>> batch of devs for not having that courage. However, it's another to openly
>> make sweeping changing to the ecosystem in an effort to make such things
>> acceptable.
>>
>> Have the courage to reject this type of thing for the sake of the overall
>> project.
>>
>> JH
>> aka wk057
>> aka wizkid057
>> On Saturday, April 26, 2025 at 8:50:59 AM UTC-4 Pieter Wuille wrote:
>>
>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr•org>
>>> wrote:
>>>
>>> > That's nonsense. They were and continue to be very effective, even
>>> with
>>> > only a small amount of adoption. Further, mining centralization and
>>>
>>> Standardness rules have definitely been effective in the past, if we go
>>> far enough back in time. But back then:
>>>
>>> * There were far less financial incentives to bypass them. Standardness
>>> adds inconvenience to people developing infrastructure on top, which can
>>> nudge in another direction. But I don't see how million-dollar (or more)
>>> business incentives would be thwarted by the need to communicate with
>>> miners directly (see below). These incentives will only increase as the
>>> subsidy dwindles.
>>>
>>> * There was far more reason for rules of this kind; the network was
>>> small and far less valuable, and there were significant concerns about
>>> increased node operation cost with a quickly-growing blockchain. With
>>> blocks consistently full for most of the time for years now, even at times
>>> without so-called "spam", that concern just does not exist; nodes will be
>>> processing the same amount of transaction data anyway. I think I share
>>> Luke's feelings around non-financially-relevant transactions on-chain, but
>>> given sufficient demand for block space anyway, there just is no need to
>>> discriminate.
>>>
>>> > pools denying miners options has been the biggest barrier to that
>>> > adoption. There is no significant financial impact either, that's just
>>> > FUD; miners using the fixed and improved spam filters have in fact
>>> > earned significantly more than miners using Core.
>>>
>>> I am doubtful of this claim, and would like to see evidence of it.
>>>
>>> > It would be a pain, but it is definitely viable. Thankfully, policy
>>> > works just fine for spam filtration, and can be adapted much quicker.
>>>
>>> Nobody is required to adopt policy, and I think you're burying your head
>>> in the sand if you believe even in a world with more decentralized
>>> hashpower, miners/hashers would voluntarily choose to disregard
>>> transactions that pay a significant fee, if the potential gains from
>>> accepting them exceed the cost of building infrastructure to bypass
>>> whatever policy exists.
>>>
>>> Bitcoin users do have a means to deny usage of the chain to truly
>>> damaging use: consensus changes. Those are not optional, apply to everyone
>>> equally, do not create incentives for bypass, and - and I believe that is a
>>> good thing - can only be adopted with very wide agreement.
>>>
>>> > > b) centralisation
>>> >
>>> > No, this is more FUD.
>>>
>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a
>>> traditional consensus system with a federation of block-builders, is to
>>> avoid censorship. If anyone dislikes the choices current miners make in
>>> what transactions they accept, they can - without asking anyone for
>>> permission - join the set of miners, and earn a proportional piece of the
>>> pie. While it is the case that today mining power is quite concentrated in
>>> a number of businesses, the set of such businesses can, and has, changed
>>> over time. This is a very valuable property.
>>>
>>> Part of the puzzle to make that permissionlessness of mining work is
>>> access to fee-paying transactions from the public. If sufficient economic
>>> demand exist for transactions that the public network denies, miners and
>>> creators of such transaction will develop transaction rails that bypass
>>> that network.
>>>
>>> If it comes to a point where that economic demand is so high that miners
>>> need to rely on private transaction rails to realistically compete, I feel
>>> we'd be giving up on one of the most valuable properties the network has. I
>>> realize this is a slipstreamery-slope argument, but it is already
>>> happening, and once the rails are ubiquitous, it will be very hard to go
>>> back to a public network.
>>>
>>> ---
>>>
>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
>>> limits, including removing them entirely. I have been a strong proponent of
>>> these limits in the past, and I'm not happy with seeing the demand for
>>> those transactions. But I also recognize the reality that that demand
>>> exists, and the alternative of pushing that demand to bypass the public
>>> network is far more damaging.
>>>
>>> I will add that I am not in favor of relaxing many other standardness
>>> rules in Bitcoin Core, such as transaction sizes and other resource
>>> limitations. These have significant impact on the public's ability to
>>> verify and relay transactions, and reason about incentive compatibility
>>> while doing so. Significant and sustained economic demand for such
>>> transactions may at some point too mean the policy needs to be revised to
>>> avoid an even worse outcome, but I'm hopeful that is not the case. However,
>>> these arguments do not apply to OP_RETURN limits, which don't serve an
>>> objective harm reduction beyond a subjective "that isn't what you should be
>>> using the chain for".
>>>
>>> --
>>> Pieter
>>>
>>> --
>> 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/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%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/CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw%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/CAAANnUy08NBOq3B%2B%2B80Rpna2qkD6NJV9RdV9v0Oi8c3G8eq_4g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 23392 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-29 14:51 ` Sjors Provoost
@ 2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
0 siblings, 1 reply; 23+ messages in thread
From: Nagaev Boris @ 2025-04-30 15:37 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Development Mailing List
On Tue, Apr 29, 2025 at 12:13 PM Sjors Provoost <sjors@sprovoost•nl> wrote:
> > If that wasn't bad enough, exploiters get a 75% discount on transaction fees.
>
> At the time SegWit was proposed it was clear that the worst case block size would increase to 4 MB. It took a few years for people to figure out how to take advantage of that. Somewhere between 2015 and early 2017 would have been good time to object to the SegWit discount, but removing it now would be a hard fork. Fwiw I think the discount was a good idea.
Can you elaborate on why removing the SegWit discount now would be a
hard fork, please? This would be a tightening of consensus rules -
blocks that are valid under the current rules become invalid under new
rules, but not vice versa.
(I'm not proposing this, just a technical question.)
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt7TP3YKcnQzZaAkJMQ8zHTVoLwgByx9bU8pt7e2fMT9Cw%40mail.gmail.com.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-30 15:37 ` Nagaev Boris
@ 2025-04-30 16:30 ` Sjors Provoost
0 siblings, 0 replies; 23+ messages in thread
From: Sjors Provoost @ 2025-04-30 16:30 UTC (permalink / raw)
To: Bitcoin Development Mailing List; +Cc: Nagaev Boris
> Op 30 apr 2025, om 17:37 heeft Nagaev Boris <bnagaev@gmail•com> het volgende geschreven:
>
> On Tue, Apr 29, 2025 at 12:13 PM Sjors Provoost <sjors@sprovoost•nl> wrote:
>>> If that wasn't bad enough, exploiters get a 75% discount on transaction fees.
>>
>> At the time SegWit was proposed it was clear that the worst case block size would increase to 4 MB. It took a few years for people to figure out how to take advantage of that. Somewhere between 2015 and early 2017 would have been good time to object to the SegWit discount, but removing it now would be a hard fork. Fwiw I think the discount was a good idea.
>
> Can you elaborate on why removing the SegWit discount now would be a
> hard fork, please? This would be a tightening of consensus rules -
> blocks that are valid under the current rules become invalid under new
> rules, but not vice versa.
>
> (I'm not proposing this, just a technical question.)
Good point. It might indeed be a soft fork: https://bitcoin.stackexchange.com/a/121185/4948
It just has to be combined with a block size decrease.
I think it would boil down to reducing MAX_BLOCK_WEIGHT from 4 million to 1 million, while at the same time reducing WITNESS_SCALE_FACTOR from 4 to 1.
So it undoes the block size increase created by SegWit. From the perspective of pre-segwit nodes, they would see that typical blocks got smaller, because they don't see the witness data.
I also can't think of a vice-versa example. One could start by adjusting all the tests in Bitcoin Core to verify if there really isn't one.
It would however be a confiscatory soft fork. E.g. if you have a pre-signed 1.1 MB transaction, it won't fit in a block. Similarly, though less severe, a 101 KB pre-signed transaction would no longer be standard, so you'd have to find a miner or accelerator.
Those transactions may sound silly, but soft fork proposals have been criticised for far less likely confiscatory surface. See e.g. the original Great Consensus Cleanup thread from 2010.
Note that a similar, albeit temporary, block size decrease has been proposed before, see [0].
> The initial size limit upon activation depends on when it is activated: for example, if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.
It kept the SegWit discount intact, though it added a byte based ceiling:
> The weight of a block may not exceed double the size limit in bytes.
It was never assigned a BIP number, so I'm not sure how serious this proposal was. In any case, it got no traction, nor did any other block size decrease proposal.
So even if there was support for removing the witness discount, since you can't do that without also decreasing the block size, I don't think this avenue is worth exploring.
- Sjors
[0] https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
--
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/613DAEA9-4911-4C32-8300-C6D8C87DD92E%40sprovoost.nl.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-30 5:39 ` Chris Guida
@ 2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
0 siblings, 1 reply; 23+ messages in thread
From: Anthony Towns @ 2025-04-30 16:37 UTC (permalink / raw)
To: Chris Guida; +Cc: Bitcoin Development Mailing List
On Tue, Apr 29, 2025 at 11:39:01PM -0600, Chris Guida wrote:
> We are under a spam attack.
Fees are under 3sat/vb; there's no attack. Excess block space is being
filled by low-value spam, but that's expected and, in a permissionless
system, unavoidable.
> This is not the first time this has happened.
> Bitcoin has endured several spam attacks in the past. They subside when
> bitcoin core devs show that they are serious about countering the attacks.
They subside when the people creating the spam realise they're wasting
money paying for fees.
Acting tough about it at best has zero effect, and at worst generates
publicity for the spammers as media and influencers gather around the
drame, making the activity more profitable.
> Unfortunately, the bitcoin core project made a misstep when it rejected
> this PR[3] from Luke-jr to filter transactions using the op_false op_if
> envelope to exploit the witness discount.
Encoding data into random protocols is a standard exercise, and doing
so in ways that are undetectable to third parties is also standard,
albeit more complicated. In a permissionless system, attempting to
filter encoded data is a losing proposition.
Well, I guess if you can convince someone to pay you by the hour to write
the filters, you've got yourself a job that will never be finished,
so really it's only a losing proposition if you ever hope to actually
succeed at it.
> Another trope from the anti-filter crowd I keep seeing is that spam
> protection is a "cat-and-mouse" game. Well, the cat won in 2014 and the
> mouse didn't come back until 2023.
Not every form of transaction spam is about jpegs or altcoins. There
were significant spam attacks on the network in 2015, see
https://en.bitcoin.it/wiki/July_2015_flood_attack
https://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981
https://nyuscholars.nyu.edu/en/publications/stressing-out-bitcoin-stress-testing
eg. The spam during that time was particularly harmful, because most
wallets failed to calculate fees on a per-vbyte basis and replace-by-fee
was rarely supported, leading to many transactions getting stuck in the
mempool for weeks or months as a result.
The only sustainable way to avoid low value spam appearing on the
blockchain (whatever form that spam might take) is to prevent low value
*transactions* from appearing on the blockchain. I don't think that's
particularly desirable at this time; but it's something that could be
achieved (even on a temporary basis) by lowering the block size.
Cheers,
aj
--
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/aBJR3YHgHrycPfAp%40erisian.com.au.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
@ 2025-05-01 3:01 ` Anthony Towns
1 sibling, 0 replies; 23+ messages in thread
From: Anthony Towns @ 2025-05-01 3:01 UTC (permalink / raw)
To: Pieter Wuille; +Cc: bitcoindev
On Sat, Apr 26, 2025 at 12:48:00PM +0000, Pieter Wuille wrote:
> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > pools denying miners options has been the biggest barrier to that
> > adoption. There is no significant financial impact either, that's just
> > FUD; miners using the fixed and improved spam filters have in fact
> > earned significantly more than miners using Core.
> I am doubtful of this claim, and would like to see evidence of it.
As far as I can tell, the claim is mostly justified by FPPS pools not
distributing all the fee component from block rewards (eg, [0]). This
reportedly reduces miner income by a larger factor than the occassional
block that collects significantly less fees (eg, [1]). I haven't seen
any hard evidence to back those claims up, but I also haven't tried
creating any accounts with FPPS mining pools to get access to any of
their APIs. Ocean/Datum also currently sets a 1% pool fee, compared to
some FPPS pools setting a 4% pool fee, so that would also be a bigger
impact on earnings than tx selection policy per se.
Ocean's block template page [2] usually seems to have core templates
gathering the most fees, followed by core-antispam, followed by ocean,
followed by datafree, as far as I can see. The differences are usually
pretty trivial though. Those differences would probably increase
substantially if a more significant proportion of hashpower adopted
filtering policies though.
[0] https://x.com/MarkArtymko/status/1826970076605481367
[1] https://mempool.space/block/0000000000000000000055167ff46b33e39e25510a096360a185d7e757595b0e
forgoing 530k sats, or ~0.27% of the block reward
[2] https://ocean.xyz/blocktemplate
Cheers,
aj
--
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/aBLj-73MIbWFe-DB%40erisian.com.au.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-30 16:37 ` Anthony Towns
@ 2025-05-01 4:57 ` Chris Guida
0 siblings, 0 replies; 23+ messages in thread
From: Chris Guida @ 2025-05-01 4:57 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6891 bytes --]
Hi AJ, thanks for the feedback.
>Fees are under 3sat/vb; there's no attack. Excess block space is being
filled by low-value spam, but that's expected and, in a permissionless
system, unavoidable.
This is just a temporary cease-fire while the spammers reload their
ammunition. There is obviously about to be another wave, otherwise what is
the point of eliminating OP_RETURN restrictions?
>They subside when the people creating the spam realise they're wasting
money paying for fees.
Yes, and then the money printer makes sure that there is always enough easy
money sloshing around in the economy so that more pop up where the old ones
dropped out. This can and will continue indefinitely if we do nothing.
>Acting tough about it at best has zero effect, and at worst generates
publicity for the spammers as media and influencers gather around the
drame, making the activity more profitable.
It worked great in 2014!
>Encoding data into random protocols is a standard exercise, and doing
so in ways that are undetectable to third parties is also standard,
albeit more complicated. In a permissionless system, attempting to
filter encoded data is a losing proposition.
>Well, I guess if you can convince someone to pay you by the hour to write
the filters, you've got yourself a job that will never be finished,
so really it's only a losing proposition if you ever hope to actually
succeed at it.
You seem to have only read about half of my message. I guess I should have
written something shorter!
I'll repeat the relevant part here in case you missed it:
"We don't need to make sure no spam ever reaches the blockchain. That is,
of course, impossible. All we need to do is show active hostility to the
spammers, and the worst schemes (the ones that rely on a consistent
transaction format) will be impossible to maintain, and will therefore lose
funding. Of course there will be hobbyist spammers here and there, but
that's much less damaging."
My proposal is not to counter literally every type of spam. Just the ones
that have protocols relying on consistent transaction formats. Creating
specific filters against just these worst offenders should be a strong
deterrent against creating more of them. This class of spam requires
coordination among a lot of people to choose and promote a stable format,
so disrupting their formats with targeted filters should have them fleeing
to other chains in no time. Conveniently for us, this class of spam is also
the riskiest to create, since it usually involves investing money upfront
to launch the Ponzi. If the launch goes poorly because bitcoiners were not
accommodating, then the investors lose their money. The financial pain this
causes teaches a lesson that is usually remembered. Namely: to spam
somewhere else!
>Not every form of transaction spam is about jpegs or altcoins.
Thanks for pointing this out! Of course the strategy outlined above does
not apply to spam attacks that look like real financial activity. To
prevent utxoset/blockchain bloating in those cases, we will need something
more drastic, such as smaller blocks as you mentioned.
And of course, smaller blocks don't help with *high*-value (high-fee) spam,
which the recent ordinals/runes waves were. My worry with high-value spam
is that if it keeps growing, it could make it practically impossible for
people to just use bitcoin to pay for stuff. (Lightning helps somewhat with
this if you already have a channel, but if you don't it's very painful, and
onboarding new bitcoiners to Lightning during these fee spikes is terrible.)
Best regards,
--Chris
On Wed, Apr 30, 2025 at 10:37 AM Anthony Towns <aj@erisian•com.au> wrote:
> On Tue, Apr 29, 2025 at 11:39:01PM -0600, Chris Guida wrote:
> > We are under a spam attack.
>
> Fees are under 3sat/vb; there's no attack. Excess block space is being
> filled by low-value spam, but that's expected and, in a permissionless
> system, unavoidable.
>
> > This is not the first time this has happened.
> > Bitcoin has endured several spam attacks in the past. They subside when
> > bitcoin core devs show that they are serious about countering the
> attacks.
>
> They subside when the people creating the spam realise they're wasting
> money paying for fees.
>
> Acting tough about it at best has zero effect, and at worst generates
> publicity for the spammers as media and influencers gather around the
> drame, making the activity more profitable.
>
> > Unfortunately, the bitcoin core project made a misstep when it rejected
> > this PR[3] from Luke-jr to filter transactions using the op_false op_if
> > envelope to exploit the witness discount.
>
> Encoding data into random protocols is a standard exercise, and doing
> so in ways that are undetectable to third parties is also standard,
> albeit more complicated. In a permissionless system, attempting to
> filter encoded data is a losing proposition.
>
> Well, I guess if you can convince someone to pay you by the hour to write
> the filters, you've got yourself a job that will never be finished,
> so really it's only a losing proposition if you ever hope to actually
> succeed at it.
>
> > Another trope from the anti-filter crowd I keep seeing is that spam
> > protection is a "cat-and-mouse" game. Well, the cat won in 2014 and the
> > mouse didn't come back until 2023.
>
> Not every form of transaction spam is about jpegs or altcoins. There
> were significant spam attacks on the network in 2015, see
>
> https://en.bitcoin.it/wiki/July_2015_flood_attack
>
> https://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981
>
> https://nyuscholars.nyu.edu/en/publications/stressing-out-bitcoin-stress-testing
>
> eg. The spam during that time was particularly harmful, because most
> wallets failed to calculate fees on a per-vbyte basis and replace-by-fee
> was rarely supported, leading to many transactions getting stuck in the
> mempool for weeks or months as a result.
>
> The only sustainable way to avoid low value spam appearing on the
> blockchain (whatever form that spam might take) is to prevent low value
> *transactions* from appearing on the blockchain. I don't think that's
> particularly desirable at this time; but it's something that could be
> achieved (even on a temporary basis) by lowering the block size.
>
> Cheers,
> aj
>
>
--
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/CAAANnUxnEfO7VexaK_V%2BRc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8805 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoindev] Relax OP_RETURN standardness restrictions
2025-04-30 0:10 ` Jason Hughes
@ 2025-05-01 17:40 ` Andrew Toth
0 siblings, 0 replies; 23+ messages in thread
From: Andrew Toth @ 2025-05-01 17:40 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 15352 bytes --]
FWIW I've written a tool to xor your blocks dir without having to resync.
https://github.com/andrewtoth/blocks-xor/
On Thursday, May 1, 2025 at 5:24:22 AM UTC-4 Jason Hughes wrote:
> I believe you greatly overestimate the skill and competence of the people
> who would do this type of thing. You could accomplish what you've laid out.
> I could accomplish it. But the people who will actually do this to Bitcoin
> once there's unrestricted OP_RETURN likely can not accomplish it today.
> What you've laid out is a more technical attack than this variant of attack
> is capable of... and what will actually happen is that once unlimited
> OP_RETURN is a thing, people willing to, but not currently able, will take
> the easy route for such attacks after someone with technical knowledge
> makes the "Connect your wallet, upload your data" button for them.
>
> All of that said, you make excellent points for ridding Bitcoin of
> arbitrary data completely. :)
>
> On Tue, Apr 29, 2025 at 3:20 PM Martin Habovštiak <martin.h...@gmail•com>
> wrote:
>
>> Hi,
>>
>> I have a little demo for you.
>>
>> Firstly, I think the kind of illegal content most people have in mind are
>> images. So let's start with a question: if one takes an illegal picture and
>> sets every 173th pixel to a red dot will it become legal?
>>
>> If you have trouble imagining it, here's an example for you:
>> https://imgur.com/a/J7RTPL7
>>
>> If you believe it would, we can end this conversation and my point is
>> moot.
>> However, I think you'll agree the image would still be illegal.
>>
>> Next, I think it's obvious that an attacker seeking to harm bitcoin users
>> would choose an any image format he likes. So for this example I'm picking
>> BMP.
>>
>> If you encode the image above to BMP, which is uncompressed, the red
>> pixels turn into bytes 253, 7, 2 which happen to encode witness element
>> length 519. The header size is 54 bytes, so stick the byte 54 at the front
>> and you have a valid serialization of a sequence of witness elements.
>>
>> Do you see what this means?
>>
>>
>> ...
>>
>>
>> Yes, it's too late to fix this. It's already trivially possible to make
>> your node store a sequence of bytes that is considered illegal. If you're
>> worried about it you have to resync the chain right now.
>>
>> Disclaimer: the numbers above might be a bit off, I did most computation
>> in my head. Still, the point stands even if the pixels have a bit different
>> spacing/color.
>>
>> Same thing with malware distribution, except you can easily skip the
>> invalid bytes using jump instructions or other techniques, so that might be
>> even worse.
>>
>> Happy syncing!
>>
>> Martin
>>
>>
>> Dňa ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizk...@gmail•com>
>> napísal(a):
>>
>>> I was asked to take my comments to the mailing list, so here we go.
>>>
>>> First, see my comments on Github PR #32359:
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
>>>
>>> Next, I'll once again point out relevant history for those just tuning
>>> in:
>>>
>>> OP_RETURN was only made standard in a limited size to encourage less
>>> harmful data carrying in Bitcoin. Attackers were using harmful methods of
>>> data carrying in unspendable UTXOs, and so a way to inject a small amount
>>> of data was TOLERABLE over this harmful UTXO bloat that. That mostly
>>> worked, and such practices were quickly minimized. This remained the case
>>> for about a decade without significant issue. Bitcoin is not file storage,
>>> and this was known to developers at that time. Sadly, eventually an
>>> exploit called 'inscriptions' happened which blew the cap off of the size
>>> limitation of arbitrary data storage... and to make matters worse,
>>> developers refused to patch the exploit or otherwise enforce the decade old
>>> limit on arbitrary data size. If that wasn't bad enough, exploiters get a
>>> 75% discount on transaction fees.
>>>
>>> With that history in mind, removing limits on OP_RETURN standardness
>>> size is pointless. Relaxing OP_RETURN size limits without dealing with the
>>> inscriptions exploit means no one will use this for anything besides
>>> attacking the network with the worst possible data. There's little to no
>>> incentive to use OP_RETURN for data storage when using the 'inscriptions'
>>> exploit costs 4x less in transactions. What's the point of having a
>>> "standard" way to store arbitrary data if the exploit method is 4x cheaper?
>>> And the nonstandard version of the exploit allows 4x the data?
>>>
>>> Further, the inscriptions exploit currently requires chunking the data
>>> between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
>>> reveal the underlying data the injector intended. I can still run
>>> something like "photorec" on my system and not have to sift through
>>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
>>> this happenstance obfuscation that has saved us to-date. After this change,
>>> when data is recovered from a full node system, whatever some anonymous
>>> person decided to stuff into an OP_RETURN will be serialized in plaintext
>>> directly on disk. For the low price of a few sats per byte, an attacker can
>>> now directly poison the storage of every full node runner.
>>>
>>> If you can't imagine the harm this will do to the ecosystem, let me
>>> paint some pictures for you:
>>>
>>> First, there's the obvious. Everyone running a node will now be
>>> guaranteed to "posses and distribute" content that is likely illegal in
>>> their jurisdiction. Not only are you storing this as a full node runner,
>>> you're serving it to others. Hooray. /s
>>>
>>> Next, there's less obvious abuses. For example, let's say I want to
>>> distribute malware. Well, might as well just store it in an OP_RETURN.
>>> Then, any time I compromise a system with a Bitcoin node I know my malware
>>> is directly on their system in a mostly predetermined spot already and I
>>> don't even need to retrieve it from elsewhere! And, even better, my malware
>>> can use the Bitcoin P2P network itself to distribute itself. Just find a
>>> willing full node, grab the block it's in. Thanks for the boost, node
>>> runners!
>>>
>>> Worse, in order to actually participate in the network, everyone MUST
>>> download all of this data from others (who must host it for you), process
>>> it, and generally must host it for others to do the same. The network can't
>>> survive with 100% pruned nodes. I think too many users nowadays don't
>>> understand that running a full node is the ONLY way to actually participate
>>> in Bitcoin.
>>>
>>> It's bad enough that chunked partly-obfuscated things exist on the
>>> systems of full node runners today. It'll be even worse if that's
>>> unrestricted with the removal of such limits.
>>>
>>> As I said in my Github comment: This is far more than a small technical
>>> change. This is a fundamental change to the nature of what the Bitcoin
>>> network itself is in its entirety. Ten years ago, developers of the
>>> reference implementation knew this, and acted in the best interest of
>>> Bitcoin itself. Today, too many developers don't understand this duty.
>>>
>>> That may sound like hyperbole, but it really isn't. If this change is
>>> merged into Bitcoin Core, and Bitcoin Core then continues to be the
>>> reference implementation... Bitcoin as we know it changes forever in the
>>> most fundamental way imaginable: The reference implementation explicitly
>>> turning the Bitcoin network into an arbitrary data storage system, instead
>>> of evolving it as a decentralized currency.
>>>
>>> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
>>> being a thing if this is the path chosen. There are very few paths that
>>> lead to a worthless Bitcoin, and this is probably in the top 3 worst
>>> options.
>>>
>>> I can't understate this. It's one thing to refuse to act when faced with
>>> an attack/exploit/etc. That takes actual courage and conviction to do
>>> what's right for the ecosystem... and I _almost_ can't fault the current
>>> batch of devs for not having that courage. However, it's another to openly
>>> make sweeping changing to the ecosystem in an effort to make such things
>>> acceptable.
>>>
>>> Have the courage to reject this type of thing for the sake of the
>>> overall project.
>>>
>>> JH
>>> aka wk057
>>> aka wizkid057
>>> On Saturday, April 26, 2025 at 8:50:59 AM UTC-4 Pieter Wuille wrote:
>>>
>>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr•org>
>>>> wrote:
>>>>
>>>> > That's nonsense. They were and continue to be very effective, even
>>>> with
>>>> > only a small amount of adoption. Further, mining centralization and
>>>>
>>>> Standardness rules have definitely been effective in the past, if we go
>>>> far enough back in time. But back then:
>>>>
>>>> * There were far less financial incentives to bypass them. Standardness
>>>> adds inconvenience to people developing infrastructure on top, which can
>>>> nudge in another direction. But I don't see how million-dollar (or more)
>>>> business incentives would be thwarted by the need to communicate with
>>>> miners directly (see below). These incentives will only increase as the
>>>> subsidy dwindles.
>>>>
>>>> * There was far more reason for rules of this kind; the network was
>>>> small and far less valuable, and there were significant concerns about
>>>> increased node operation cost with a quickly-growing blockchain. With
>>>> blocks consistently full for most of the time for years now, even at times
>>>> without so-called "spam", that concern just does not exist; nodes will be
>>>> processing the same amount of transaction data anyway. I think I share
>>>> Luke's feelings around non-financially-relevant transactions on-chain, but
>>>> given sufficient demand for block space anyway, there just is no need to
>>>> discriminate.
>>>>
>>>> > pools denying miners options has been the biggest barrier to that
>>>> > adoption. There is no significant financial impact either, that's
>>>> just
>>>> > FUD; miners using the fixed and improved spam filters have in fact
>>>> > earned significantly more than miners using Core.
>>>>
>>>> I am doubtful of this claim, and would like to see evidence of it.
>>>>
>>>> > It would be a pain, but it is definitely viable. Thankfully, policy
>>>> > works just fine for spam filtration, and can be adapted much quicker.
>>>>
>>>> Nobody is required to adopt policy, and I think you're burying your
>>>> head in the sand if you believe even in a world with more decentralized
>>>> hashpower, miners/hashers would voluntarily choose to disregard
>>>> transactions that pay a significant fee, if the potential gains from
>>>> accepting them exceed the cost of building infrastructure to bypass
>>>> whatever policy exists.
>>>>
>>>> Bitcoin users do have a means to deny usage of the chain to truly
>>>> damaging use: consensus changes. Those are not optional, apply to everyone
>>>> equally, do not create incentives for bypass, and - and I believe that is a
>>>> good thing - can only be adopted with very wide agreement.
>>>>
>>>> > > b) centralisation
>>>> >
>>>> > No, this is more FUD.
>>>>
>>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a
>>>> traditional consensus system with a federation of block-builders, is to
>>>> avoid censorship. If anyone dislikes the choices current miners make in
>>>> what transactions they accept, they can - without asking anyone for
>>>> permission - join the set of miners, and earn a proportional piece of the
>>>> pie. While it is the case that today mining power is quite concentrated in
>>>> a number of businesses, the set of such businesses can, and has, changed
>>>> over time. This is a very valuable property.
>>>>
>>>> Part of the puzzle to make that permissionlessness of mining work is
>>>> access to fee-paying transactions from the public. If sufficient economic
>>>> demand exist for transactions that the public network denies, miners and
>>>> creators of such transaction will develop transaction rails that bypass
>>>> that network.
>>>>
>>>> If it comes to a point where that economic demand is so high that
>>>> miners need to rely on private transaction rails to realistically compete,
>>>> I feel we'd be giving up on one of the most valuable properties the network
>>>> has. I realize this is a slipstreamery-slope argument, but it is already
>>>> happening, and once the rails are ubiquitous, it will be very hard to go
>>>> back to a public network.
>>>>
>>>> ---
>>>>
>>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
>>>> limits, including removing them entirely. I have been a strong proponent of
>>>> these limits in the past, and I'm not happy with seeing the demand for
>>>> those transactions. But I also recognize the reality that that demand
>>>> exists, and the alternative of pushing that demand to bypass the public
>>>> network is far more damaging.
>>>>
>>>> I will add that I am not in favor of relaxing many other standardness
>>>> rules in Bitcoin Core, such as transaction sizes and other resource
>>>> limitations. These have significant impact on the public's ability to
>>>> verify and relay transactions, and reason about incentive compatibility
>>>> while doing so. Significant and sustained economic demand for such
>>>> transactions may at some point too mean the policy needs to be revised to
>>>> avoid an even worse outcome, but I'm hopeful that is not the case. However,
>>>> these arguments do not apply to OP_RETURN limits, which don't serve an
>>>> objective harm reduction beyond a subjective "that isn't what you should be
>>>> using the chain for".
>>>>
>>>> --
>>>> Pieter
>>>>
>>>> --
>>> 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/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>
> --
> *Jason Hughes*
>
>
--
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/1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 18447 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2025-05-01 18:08 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 3:01 ` Anthony Towns
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox