Relax OP_RETURN standardness restrictions

Relax OP_RETURN standardness restrictions
2025-04-18 12:03 ` Sjors Provoost
                   ` (8 more replies)
  
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	[|nested]
2025-04-18 12:03 ` 
                   ` 
  
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	[|nested]
2025-04-18 12:03 ` Sjors Provoost

  2025-04-18 13:06     ` Vojtěch Strnad
  2025-04-18 13:29     ` 'Antoine Poinsot' via Bitcoin Development Mailing List
  
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	[|nested]
2025-04-18 12:54   ` Greg Sanders

  2025-04-18 13:29     ` 'Antoine Poinsot' via Bitcoin Development Mailing List
  
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	[|nested]
2025-04-18 12:54   ` Greg Sanders
  2025-04-18 13:06     ` Vojtěch Strnad

  2025-04-18 21:34       ` Antoine Riard
  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-04-18 13:29 UTC (permalink / raw)
  To: Greg Sanders, Sjors Provoost;  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	[|nested]
2025-04-18 13:29     ` 'Antoine Poinsot' via Bitcoin Development Mailing List

  
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	[|nested]
* 
  2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-04-18 12:54   ` Greg Sanders
  2025-04-20  8:43 ` 
                   ` 
  8 siblings, 1 reply; 60+ 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	[|nested] 60+ messages in thread
* 
  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-26  9:50 ` 
                   ` 
  8 siblings, 0 replies; 60+ messages in thread
From: Peter Todd @ 2025-04-20  8:43 UTC (permalink / raw)
  To: Antoine Poinsot;  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	[|nested] 60+ messages in thread
2025-04-26  9:50 ` Luke Dashjr

  2025-04-26 11:35     ` Luke Dashjr
  2025-05-02 18:56   ` Greg Tonoski
  
From: Sjors Provoost @ 2025-04-26 10:53 UTC (permalink / raw)
  To: bitcoindev;  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	[|nested]
2025-04-26 10:53   ` Sjors Provoost

  2025-04-26 11:45       ` Sjors Provoost
  2025-04-26 12:48       ` Pieter Wuille
  
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	[|nested]
2025-04-26 11:35     ` Luke Dashjr

  2025-04-26 12:48       ` Pieter Wuille
  
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	[|nested]
2025-04-26 11:35     ` Luke Dashjr
  2025-04-26 11:45       ` Sjors Provoost

  2025-04-28 16:20         ` Jason Hughes (wk057)
  2025-05-01  3:01         ` Anthony Towns
  
From: Pieter Wuille @ 2025-04-26 12:48 UTC (permalink / raw)
  To: Luke Dashjr;  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	[|nested]
2025-04-26 12:48       ` Pieter Wuille

  2025-04-29 14:51           ` Sjors Provoost
  2025-04-29 19:20           ` Martin Habovštiak
  2025-05-01  3:01         ` Anthony Towns
  
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	[|nested]
2025-04-28 16:20         ` Jason Hughes (wk057)

  2025-04-30 15:37             ` Nagaev Boris
  2025-04-29 19:20           ` Martin Habovštiak
  
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	[|nested]
2025-04-28 16:20         ` Jason Hughes (wk057)
  2025-04-29 14:51           ` Sjors Provoost

  2025-04-30  0:10             ` Jason Hughes
  2025-04-30  5:39             ` Chris Guida
  
From: Martin Habovštiak @ 2025-04-29 19:20 UTC (permalink / raw)
  To: Jason Hughes (wk057);  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	[|nested]
2025-04-29 19:20           ` Martin Habovštiak

  2025-05-01 17:40               ` Andrew Toth
  2025-04-30  5:39             ` Chris Guida
  
From: Jason Hughes @ 2025-04-30  0:10 UTC (permalink / raw)
  To: Martin Habovštiak;  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	[|nested]
2025-04-29 19:20           ` Martin Habovštiak
  2025-04-30  0:10             ` Jason Hughes

  2025-04-30 16:37               ` Anthony Towns
  
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	[|nested]
2025-04-29 14:51           ` Sjors Provoost

  2025-04-30 16:30               ` Sjors Provoost
  
From: Nagaev Boris @ 2025-04-30 15:37 UTC (permalink / raw)
  To: Sjors Provoost;  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	[|nested]
2025-04-30 15:37             ` Nagaev Boris

  
From: Sjors Provoost @ 2025-04-30 16:30 UTC (permalink / raw)
  To: Bitcoin Development Mailing List;  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	[|nested]
2025-04-30  5:39             ` Chris Guida

  2025-05-01  4:57                 ` Chris Guida
  
From: Anthony Towns @ 2025-04-30 16:37 UTC (permalink / raw)
  To: Chris Guida;  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	[|nested]
2025-04-26 12:48       ` Pieter Wuille
  2025-04-28 16:20         ` Jason Hughes (wk057)

  
From: Anthony Towns @ 2025-05-01  3:01 UTC (permalink / raw)
  To: Pieter Wuille;  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	[|nested]
2025-04-30 16:37               ` Anthony Towns

  2025-05-01 19:33                   ` Nagaev Boris
  2025-05-02  6:34                   ` Anthony Towns
  
From: Chris Guida @ 2025-05-01  4:57 UTC (permalink / raw)
  To: Anthony Towns;  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	[|nested]
2025-04-30  0:10             ` Jason Hughes

  
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	[|nested]
2025-05-01  4:57                 ` Chris Guida

  2025-05-02  6:34                   ` Anthony Towns
  
From: Nagaev Boris @ 2025-05-01 19:33 UTC (permalink / raw)
  To: Chris Guida;  Anthony Towns, Bitcoin Development Mailing List

On Thu, May 1, 2025 at 2:20 AM Chris Guida <chrisguida@gmail•com> wrote:
> >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?

If they use OP_RETURN instead of putting data into the witness, they
will exhaust their funds four times faster and store four times less
data on the blockchain. Maybe the removal of OP_RETURN constraints in
policy is a Trojan horse against spammers?

-- 
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_Vt6Tv73tuF20MPpC7MiA5n6TfUwj%2BSOacCMTT%3D9roHkKAw%40mail.gmail.com.


 permalink raw reply	[|nested]
* 
  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 10:53   ` Sjors Provoost
  2025-05-02 18:56   ` Greg Tonoski
  2025-05-01 22:40 `  " 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` 
  8 siblings, 2 replies; 60+ 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	[|nested] 60+ messages in thread
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-05-02 11:16     ` [bitcoindev] " Sjors Provoost
  2025-05-02 13:58     ` [bitcoindev] " Bob Burnett
  2025-05-02 20:03   ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
  
From: PandaCute @ 2025-05-02  0:14 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 12621 bytes --]

I think this debate is missing one important part: a communication link 
between the developers and the users. The developers are speaking with the 
developers, the users are speaking with the users, and no one is really 
trying to understand where the other side is coming from. It's been a lot 
of aggressive, unproductive back-and-forth, with both sides accusing each 
other of bad intentions and completely dismissing each other's points.

This is a technical mailing list aimed at devs, so I'll try to summarize 
what I've seen in normal_users_land, and the general feeling out there 
right now. Obviously, I'm not trying to suggest that users *feelings* 
should be dictate the technical direction of Bitcoin. However, it is 
important that there is mutual respect and trust between users and devs.

Right now, trust is pretty broken. It can be regained, but not without 
understanding what went wrong in the first place. 

I saw on IRC some devs suggesting they spend time on podcasts and social 
media to explain the motivations behind this proposal *before* merging it, 
instead of merging now and hoping people just accept it. I think that’s a 
fantastic idea, and the way to go. I particularly liked jonatack's message 
- “if Core shows humility and patience, it would surprise people and 
improve things.”

Now, about the proposal itself and what it *feels* like: It’s a big change 
that came out of nowhere, especially at a time when spam doesn’t seem like 
a big issue. It’s a bit… shocking? Normally Bitcoin changes are discussed 
for ages, PRs take so long to get merged, because of all the care that devs 
put into considering the pros and the cons, but here? We get a mailing list 
post (that no user is reading, let’s be honest) and a PR with a lot of 
contributors saying “yeah, let’s do this!”. There should be a bit more 
research. (Maybe there was, but behind closed doors?). We want to know 
about all the protocols that are bloating the UTXO set and that could be 
using OP_RETURN instead. We want to know how many transactions like these 
are in each block, and how many there will be once the new protocols start 
getting deployed. We want to see that you did your homework for weeks 
before trying to change the policies. 

It feels weird—like some sort of attack or a bribe. One protocol is 
mentioned that would benefit from this change, and then an investor ACKs 
the PR. Someone points out a potential conflict of interest, and their 
comment gets hidden. That’s shady, no denying it.

And then, it feels that users have no say. It's a ""technocracy"", where 
devs have all the power in their hands and can decide where the protocol 
goes, while completely dismissing users' concerns.

Users do have concerns—lots of them. And I encourage devs to step out and 
talk to "regular" Bitcoin users. It’s not just a “loud minority”—there are 
many people genuinely worried: “Can we trust Core devs anymore? Is there 
even another option?”. But their concerns are dismissed, their comments 
deleted or hidden, they're treated like "bullies" that devs should ignore, 
devs should "merge Todd's PR and call it a day".

Without understanding all the technical details, I'd say there's a pretty 
good chance that the very smart people that work on Core are right once 
again. Statistically, it's very likely. Communicate to users, explain your 
motivations, and show that you want to listen to our concerns.

Lastly, as irritating as that might be, users freaking out and holding core 
developers accountable and flooding Github is a feature, not a bug. Devs 
aren't the Bitcoin gods, they are humans, and humans can be bribed,  can be 
coerced, can have conflict of interest, can fck up.

Users care and want to protect Bitcoin. Be grateful. 

Respectfully,
A Bitcoin Dev

On Friday, May 2, 2025 at 12:46:20 AM UTC+2 Antoine Poinsot wrote:

> As i have repeatedly asked people to take conceptual discussions to the 
> mailing list, i am circling back to this thread to answer objections. I 
> have also written my point of view and reasons for proposing this change in 
> a blog post which goes into more details: 
> https://antoinep.com/posts/relay_policy_drama. 
>
> Going through the emails in order.
>
> Am I the only one left on this list who actually cares about Bitcoin's 
> survival?
>
>
> Thanks Luke for your measured take. It's refreshing to see we have adults 
> on both sides of this "debate".
>
> With that history in mind, removing limits on OP_RETURN standardness size 
> is pointless.
>
>
> Yes, it is pointless for people who want to store massive amount of data. 
> It is not for people who want to store a small amount of data in a 
> time-sensitive transaction's output. Because they need their transaction to 
> be relayed on the p2p network, and are therefore pushed to use unspendable 
> outputs instead.
>
> Relaxing OP_RETURN size limits without dealing with the inscriptions
>
>
> This is orthogonal. The harmful behaviour described in OP is possible 
> today regardless of inscriptions.
>
> 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?
>
>
> You have obviously not properly read or understood OP. There is no need 
> to speculate about what would happen or not. People are using outputs to 
> store data *today*​. The only question now is harm reduction: given that 
> people are storing this data in outputs today, do we want to offer a way to 
> do it that does not force every single full node on the network to store 
> their data forever? 
>
> That said i agree that this is not going to change anything for people who 
> try to store large amount of data onchain, they already have a 4x cheaper 
> way of doing so.
>
> For example, let's say I want to distribute malware. Well, might as well 
> just store it in an OP_RETURN.
>
>
> The point about storing data on everyone's disk was addressed by others: 
> it's already possible and that's why Core XOR's the content of 
> third-party-controlled data it writes to disk. But an interesting fact on 
> this specific point about malware and OP_RETURN outputs is how they have 
> already been used in the past to resiliently update the domain of a 
> malware's C2 servers: 
> https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .
>
> This is a fundamental change to the nature of what the Bitcoin network 
> itself is in its entirety. [...] Bitcoin as we know it changes forever in 
> the most fundamental way imaginable
>
>
> Wild emotional claims with no ground whatsoever don't convince anybody and 
> only hurt your credibility.
>
> and we might as well give up on Bitcoin ever being a thing if this is the 
> path chosen
>
>
> Well if you believe the whole system is as brittle as relying on people 
> playing nice for security, you might as well give up now.
>
> Have the courage to reject this type of thing for the sake of the overall 
> project.
>
>
> Right. We do that, and you go outside and touch some grass for the benefit 
> of all subscribers to this mailing list.
>
> 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. 
> 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*. 
>
>
> Doubt.
>
> 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.
>
>
> Thank you for taking conceptual discussion to the mailing list. AJ already 
> addressed your claims, so i won't repeat it here.
>
> This is just a temporary cease-fire while the spammers reload their 
> ammunition. There is obviously about to be another wave
>
>
> Between this one and your previous email, you certainly do know a lot 
> about the future! How's your trading going?
>
> otherwise what is the point of eliminating OP_RETURN restrictions?
>
>
> To not force people to bloat the UTxO set to store a trivial amount of 
> data in the output of a time-sensitive transactions. On the specifics, 
> Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a 
> 128-byte Groth16 proof and 16-byte total accumulated work (sauce: 
> https://x.com/ekrembal_/status/1918008476552356202). I don't know and 
> don't care why they do it in this way in particular, i just wish they did 
> so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as 
> they do today. Or worse, start thinking about bare multisig.
>
> 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.
>
>
> Money printer financing working people forever certainly isn't something i 
> expected to read on the Bitcoin dev mailing list!
>
> 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
>
>
> This is veering off-topic for this thread. If you want to argue that Core 
> should filter inscriptions could you take it to the appropriate thread? 
> This thread is just about damage control for people storing data in 
> transaction outputs.
>
> 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.
>
>
> Your hubris gives me second-hand embarrassment. I hope the C2 domain 
> update i shared above gives you a clue that there does in fact exist other 
> smart people in the world. Threat actors would laugh pretty hard at your 
> arrogant emails and emotional breakdowns, but they probably don't care 
> about your filters in the slightest anyways.
>
> After reading the whole thread i have yet to read a single sound objection 
> to lifting the OP_RETURN restrictions.
> On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <
> daro...@protonmail•com> 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/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 22696 bytes --]

 permalink raw reply	[|nested]
* 
  2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (2 preceding siblings ...)
  2025-04-26  9:50 ` Luke Dashjr

  2025-05-02  0:14   ` PandaCute
  2025-05-02 20:03   ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
  2025-05-02  6:29 `  Greg Maxwell
                   ` 
  8 siblings, 2 replies; 60+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-05-01 22:40 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 8244 bytes --]

As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_drama.

Going through the emails in order.

> Am I the only one left on this list who actually cares about Bitcoin's survival?

Thanks Luke for your measured take. It's refreshing to see we have adults on both sides of this "debate".

> With that history in mind, removing limits on OP_RETURN standardness size is pointless.

Yes, it is pointless for people who want to store massive amount of data. It is not for people who want to store a small amount of data in a time-sensitive transaction's output. Because they need their transaction to be relayed on the p2p network, and are therefore pushed to use unspendable outputs instead.

> Relaxing OP_RETURN size limits without dealing with the inscriptions

This is orthogonal. The harmful behaviour described in OP is possible today regardless of inscriptions.

> 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?

You have obviously not properly read or understood OP. There is no need to speculate about what would happen or not. People are using outputs to store data today​. The only question now is harm reduction: given that people are storing this data in outputs today, do we want to offer a way to do it that does not force every single full node on the network to store their data forever?

That said i agree that this is not going to change anything for people who try to store large amount of data onchain, they already have a 4x cheaper way of doing so.

> For example, let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN.

The point about storing data on everyone's disk was addressed by others: it's already possible and that's why Core XOR's the content of third-party-controlled data it writes to disk. But an interesting fact on this specific point about malware and OP_RETURN outputs is how they have already been used in the past to resiliently update the domain of a malware's C2 servers: https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .

> This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety. [...] Bitcoin as we know it changes forever in the most fundamental way imaginable

Wild emotional claims with no ground whatsoever don't convince anybody and only hurt your credibility.

> and we might as well give up on Bitcoin ever being a thing if this is the path chosen

Well if you believe the whole system is as brittle as relying on people playing nice for security, you might as well give up now.

> Have the courage to reject this type of thing for the sake of the overall project.

Right. We do that, and you go outside and touch some grass for the benefit of all subscribers to this mailing list.

> 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. 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.

Doubt.

> 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.

Thank you for taking conceptual discussion to the mailing list. AJ already addressed your claims, so i won't repeat it here.

> This is just a temporary cease-fire while the spammers reload their ammunition. There is obviously about to be another wave

Between this one and your previous email, you certainly do know a lot about the future! How's your trading going?

> otherwise what is the point of eliminating OP_RETURN restrictions?

To not force people to bloat the UTxO set to store a trivial amount of data in the output of a time-sensitive transactions. On the specifics, Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte Groth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrembal_/status/1918008476552356202). I don't know and don't care why they do it in this way in particular, i just wish they did so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as they do today. Or worse, start thinking about bare multisig.

> 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.

Money printer financing working people forever certainly isn't something i expected to read on the Bitcoin dev mailing list!

> 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

This is veering off-topic for this thread. If you want to argue that Core should filter inscriptions could you take it to the appropriate thread? This thread is just about damage control for people storing data in transaction outputs.

> 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.

Your hubris gives me second-hand embarrassment. I hope the C2 domain update i shared above gives you a clue that there does in fact exist other smart people in the world. Threat actors would laugh pretty hard at your arrogant emails and emotional breakdowns, but they probably don't care about your filters in the slightest anyways.

After reading the whole thread i have yet to read a single sound objection to lifting the OP_RETURN restrictions.
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <darosior@protonmail•com> 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/IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 19542 bytes --]

^ permalink raw reply	[|nested] 60+ messages in thread
2025-05-01  4:57                 ` Chris Guida
  2025-05-01 19:33                   ` Nagaev Boris

  2025-05-02 18:29                     ` Peter Todd
  
From: Anthony Towns @ 2025-05-02  6:34 UTC (permalink / raw)
  To: Chris Guida;  Bitcoin Development Mailing List

On Wed, Apr 30, 2025 at 10:57:29PM -0600, Chris Guida wrote:
> > 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

I mean, the definition of a cease-fire is that no one attacks during it.

> while the spammers reload their
> ammunition. There is obviously about to be another wave, otherwise what is
> the point of eliminating OP_RETURN restrictions?

The point of eliminating OP_RETURN restrictions is to avoid people
encoding data in more harmful ways.

> > 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.

Yes, spammers can and will continue filling up block space if they're
willing to pay more for that block space than non-spammers.

> > Acting tough about it at best has zero effect, and at worst generates
> > publicity for the spammers as media and influencers gather around the
> > drama, making the activity more profitable.
> It worked great in 2014!

I don't agree with that claim. (To be specific: I think it had zero
technical/economic effect (though maybe some propaganda value), and that
Ethereum was launched as its own chain for the same class of reasons
that Algorand and Solana launched their own chains, rather than using
data commitments on top of Ethereum)

> You seem to have only read about half of my message. I guess I should have
> written something shorter!

It's almost always true that writing something shorter is better.

> 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,

Ultimately, that's not true: you can always encode data in ways that would
otherwise look like a normal financial transaction, or a set of normal
financial transactions, and if necessary, encrypt it in a way that it's
only identifiable as a data encoding after it's already been published.

I don't particularly want to give practical examples of how to do that,
of course.

> And of course, smaller blocks don't help with *high*-value (high-fee) spam,
> which the recent ordinals/runes waves were.

Ordinals/runes only managed to have fees-per-block rise above the block
subsidy (ie 313sat/vb or 625sat/vb) for a handful of blocks, so I wouldn't
call it particularly "high value" in general. At 3sat/vb and $100k/BTC
we're still at the "sure, I can afford 25c for an on-chain tx to buy a
coffee" level.

> 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.

That's the exact opposite concern: if there's that much high value
transaction volume, then that valuation will justify paying for both
engineering talent to avoid whatever filtering efforts you come up with
(if nothing else, by spammers mining blocks directly), and mining fees to
price your transactions out of the available block space. The solution to
that scenario is to increase the block size, until there's enough capacity
for all the high value transactions as well as your lower value ones.

I don't share that concern, personally. Data storage is far more
efficiently done outside of a blockchain (or more cheaply done on
non-Bitcoin blockchains), and for any legitimate use case, avoiding
wasting money on inefficient designs or unnecessary engineering projects
lets you capture more of that value as profit. For scams and frauds,
that doesn't apply, but scams and frauds only last until your pool of
victims grows wise to your shenanigans.

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/aBRnhXwUYWFbvd95%40erisian.com.au.


 permalink raw reply	[|nested]
2025-05-02  6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell

  2025-05-02 17:36     ` Greg Maxwell
  2025-05-02 20:43     ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
  2025-05-02 19:04   ` /dev /fd0
  
From: Anthony Towns @ 2025-05-02  9:51 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

On Thu, May 01, 2025 at 11:29:35PM -0700, Greg Maxwell wrote:

(Yay!)

> So on this basis I suggest a principle for these sorts of policy:   Relay
> rules should admit all transactions which are reliably being mined.
> I think node software should adopt this principal as a general rule.

Hmm, I don't actually think this is a good rule -- if followed strictly,
it prevents ever making relay rules more restrictive, even for cases
which are provably harmful for the network.

> By general rule I mean that should something like a miner begin mining e.g.
> quadratic hashing bloat legacy txn, or using unused
> opcode/successcode/version number or whatever by mistake or technical
> ignorance there is no need to rush off enabling their relay. A general rule
> isn't a suicide pact.

Alternatively, if it's a rule with exceptions, then it's those exceptions
that are the important factor and should be figured out.

For example, the reason mining a "quadratic hashing bloat txn" is bad
because it causes delayed block validation on its own, potentially in
ways that aren't even sufficiently mitigated by running your node on
extremely high end hardware. Transactions like that should really be
removed from consensus validity not just prevented at the relay level,
and BIP 54's consensus cleanup hopefully does that.

Miners have accepted out-of-band relay of spends of unknown
segwit versions (which I presume is similar enough to the "unused
opcode/successcode/version number or whatever" case), in particular
txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
in block 692261 (the taproot exception block). Even though that was not
done by mistake or out of technical ignorance, I think doing such things
extremely rarely through out of band mechanisms is pretty much fine.
(Even if miners do it for profit, rather than as a 0-fee tx where the
outputs are a donation to a developer funding group)

> But if it were the case that transactions misusing a
> particular forward compatibility feature were reliably getting mined then
> that feature would just no longer be useful for forward compatibility
> regardless of what relay policy says about it and it would be better to
> relay them than have the downsides of not doing so.

If adopted, a policy like that would be fairly easy to use to hold the
network hostage: find a miner who doesn't much care and has perhaps
0.1% of total hashrate, get them to mine txs spending segwit versions 2
through 16, and forward a handful of such transactions to them every day.
The transactions are getting mined regularly and reliably (at a rate
of about once a week), the transactions aren't immediately damaging the
network, the miner is making excess profits, and by your relay argument,
the miner is gaining a slight advantage in being able to potentially
mine two blocks in a row due to the block relay delays caused by not
relaying spends of future segwit versions.

The LibreRelay project has already followed pretty much that script for
pushing fullrbf relay onto the network, and is proposing to do the same
approach for data storage in the annex, so I don't think this is just
a hypothetical concern.

I'd describe that class of policy as something of a "popularity contest"
approach -- it's a policy that says that anything that's sufficiently
popular is good/permissable. I think that makes sense as a check/balance
approach -- "this think is popular, is there really a good reason why
it's not permitted?" -- but not as the first thing we think about.

> As Antoine Poinsot points out, the existent rule is entirely ineffectual:
> Parties current bypass these rules with other transaction forms (such as
> very harmful address stuffing which is impossible to block) or by direct
> miner submission, which will continue considering the millions of dollars
> miners have received mining transactions with violate the relay rules.
> Because of this it will not become effectual with time or tweaking.  It is
> a dead parrot^policy.  This is no surprise, since it's a product of
> Bitcoin's anti-censorship properties that *generally* filtering will not
> work except on the fringes.  As such there isn't practical upside to
> keeping filtering beyond what miners currently perform.

As a check/balance, I think that argument holds water, and should cause
us to ask if your existing policies make sense. I think it's fair to
say Bitcoin Core's existing policies (as expressed by its code, and not
necessarily matching the policies of various forks of Core) are (in no
particular order):

 1 limit utxo growth (via block weight constraints, and by avoiding
   creation of utxos that would be uneconomic to spend)

 2 prefer that transaction data be prunable rather than potentially
   permanent (eg, better to have a 20-32 byte hash in the utxo set and
   a 160 byte x-of-5 multisig script in the scriptSig or witness, than
   to have the 160 byte x-of-5 multisig directly in the utxo set; this
   is the main justification for why witness data should be discounted
   vs output data)

 3 limit block validation time to the ~1s range (on a block whose txs have
   not been seen before, on reasonable hardware)

 4 limit maximum block size growth to ~4GB/week (ie, the worst case from
   having a 4M weight limit)

 5 optimise validation and relay of blocks with txs that we have seen before
   as much as possible

 6 allow anyone to create any sort of scripts they like (via p2sh, p2wsh, p2tr),
   within the limits of what you can conceivably do with script opcodes, and
   without causing excessive validation costs

 7 encourage people who want to use the blockchain as an anchor for their data
   to store commitments in the blockchain rather than the actual data

 8 allow miners to occassionally generate excess profits by mining non-standard
   transactions that violate relay rules but comply with consensus rules

(There are obviously many other policies, eg the 21M coin limit, but I
think the above are the ones most relevant to this discussion)

I think all of those policies can be justified (or criticised) on their
own merits, independent of their popularity per se, and I think doing
that is a better approach than starting with what's popular or not.

I think there's perhaps four conclusions you could reasonably draw about
the policies above, wrt what's been discussed on this topic:

 * encouraging data storage people to use commitments (7) didn't really
   work, and given that could be done via documentation or blog posts
   where we could provide reasoning, examples and alternatives rather than
   just a "transaction rejected" which might be more effective anyway.
   the citrea design also suggests that that policy is interfering with
   the goal of limiting utxo growth (1). as a result, it probably doesn't
   make a lot of sense to maintain that policy in code. There's already
   the obvious incentive pushing people towards commitments instead of
   raw data, in that doing so reduces the on-chain fees you need to pay.

 * for (non-commitment) data storage use cases, OP_RETURN limits are
   probably largely irrelevant in limiting blockchain usage; while
   OP_RETURN is also prunable, it's not discounted (2), so including
   data in the witness will still be preferable to the people who wish
   to publish data in large volumes

 * people with legitimate concerns about their node being overloaded
   should probably be concerned more by the "limit maximum block size
   growth to ~4GB/week" policy (4), rather than commitments vs data (7),
   complicated scripts (6) or prefering prunable data (2): it doesn't
   really make much difference if your node is overloaded by spam or by
   real transactions, either way it's overloaded. I haven't seen any
   evidence of it being difficult to keep a node operating for that
   reason, however.

 * there are two aspects to the "miners generate excess profits from non-standard
   transactions":

    * one is that for that to only be "occassional" means that even
      vaguely legitimate use cases should have a supported way of
      being exercised via standard transactions without being much more
      expensive: eg, instead of consolidating 4000 transactions in a
      270kvB transaction, you might use consolidate 1333 transactions
      in each of three 91kvB transactions. That limits the amount of
      excess profits the miner can generate, in this example the 3kvB
      of savings would only justify paying about 1.1% higher than the
      going feerate for standard transactions, eg.

    * the other is that if you want to disallow this from happening
      even occassionally, then you want to have relay and consensus rules
      be the same; but that effectively means that any functionality
      upgrade needs to be done as a hard fork, which in turn likely has
      highly centralising effects around the developer team, as running
      old versions of the software becomes infeasible

> Some Bitcoiners are of the opinion that they still want a knob, I think
> doing so is a disrespectful placebo[*]

I don't agree with that at all: giving people what they ask for, even
if it's literally a punch in the face, isn't disrespectful, it's the
opposite. (Respecting other people isn't always the highest virtue,
of course)

> But in this case if there were a knob here I think would make more sense
> for it to control mining policy rather than relay policy, since it would
> actually have some effect in the mining context (in excluding the txn from
> your own blocks) while as a relay only thing it is impotent.

Core's mempool/standardness policy covers both relay and mining
acceptability. I don't think it makes very much sense to separate them
-- beyond making the code more complex, accepting txs into your mempool
that you'll still relay but won't mine might block you from accepting
other (conflicting) txs that you would mine, eg.

About 11 years ago, you wrote:

] [...] Right now I've seen a lot of people
] promoting data storage as a virtuous use, and gearing up to directly
] store data when a commitment would work.
]
] If it turns out that encouraging people to use hashes is a lost cause
] it can always be further relaxed in the future, going the other way is
] much harder.

 -- https://gnusha.org/pi/bitcoindev/CAAS2fgT6qFHBojoB-teCjF_YAd9TePdQ3+NWnO0dwf9Bv583_Q@mail.gmail.com/

Even if they're fundamentally wrong, I think it's respectful to people who
haven't yet given that up as a lost cause to leave them with a knob that
gives them at least a chance to continue the fight for sometime longer.

Let me offer a principle that will never need any exceptions: people
who are a mere 10-15 years behind the thinking of the bitcointalk.org
class of 2012 are still the brightest 1% of humanity.

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/aBSVn7nJnrheLy5Z%40erisian.com.au.


 permalink raw reply	[|nested]
2025-05-02  0:14   ` PandaCute

  2025-05-02 14:37       ` 'nsvrn' via Bitcoin Development Mailing List
  2025-05-02 13:58     ` [bitcoindev] " Bob Burnett
  
From: Sjors Provoost @ 2025-05-02 11:16 UTC (permalink / raw)
  To: Bitcoin Development Mailing List;  PandaCute

Op 2 mei 2025, om 02:14 heeft PandaCute <pandacute12345678@gmail•com> het volgende geschreven:

> It feels weird—like some sort of attack or a bribe. One protocol is mentioned that would benefit from this change, and then an investor ACKs the PR. 

This is a misunderstanding. One that probably should have been better communicated, because I can see why it creates a bad impression.

The Citrea protocol does not benefit from this change at all! We're just asking them nicely to please use OP_RETURN and not bloat the UTXO set.

The cost difference between OP_RETURN and fake public keys is negligible for them. I try to explain this in more detail here:

https://bitcoin.stackexchange.com/questions/126208/why-would-anyone-use-op-return-over-inscriptions-aside-from-fees

We can only hope they do so, but why would they?  They already wrote the code, and now they have to spend engineering hours to deviate from their whitepaper design. For what, just to be a good citizen? Their developers are getting attacked for agreeing with this change. And since the proposal is controversial, they can't even count on this actually going through in time for whenever they want to launch.

As someone once said: we don't have the cards here.

- 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/1B78AC90-E698-421F-AECD-32DBCDD8669A%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-05-02  0:14   ` PandaCute
  2025-05-02 11:16     ` [bitcoindev] " Sjors Provoost

  
From: Bob Burnett @ 2025-05-02 13:58 UTC (permalink / raw)
  To: PandaCute, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 17159 bytes --]

This is my first response/comment on this mailing list.  I think there are several issues that have risen to the surface here including this one on a broken communication link (well written message btw).


  1.  Those outside of the dev community are perplexed by the process and feeling discounted, unheard, and/or rejected.  Most of the issues/PRs/BIPs that the dev community deals with are beyond the ability of the general population to understand, but occasionally there are ones that they grasp (at least somewhat) and for which they have opinion.  I’ve certainly learned that when someone has an opinion it is really important to let them express it, otherwise, the pressure inside them builds and they erupt like a volcano.  The Bitcoin ecosystem and its members are radically different today than 5-10 years ago – it is bigger, wider, and has broader interests now - it appears that process and communication mechanisms currently used by Core are not capable of reaching the community properly anymore. Note that communication means two-way as well.

When someone buys Bitcoin or starts working within the ecosystem, there is no membership guide, owner’s manual, or employee on-boarding process.  It comes off very badly when someone trying to engage is told that they don’t count or aren’t using proper channels, especially when they don’t even know where to go learn the rules of engagement.  That isn’t necessarily anyone’s fault, but I’ve been involved in Bitcoin since 2017 and even now am still learning new things about the engagement process, and there definitely have been several surprises and frustrations for me over the past handful of days.



  1.  The ecosystem is much more complex than ever before with people and companies developing products and services with assumptions of how Bitcoin will operate.  Many of these are being done in stealth-mode as well.  Some people are pouring their heart and soul (and money) into their projects and the expectation of a standard is often crucial.  I am one of these folks, beyond what I do in mining (CEO of Barefoot Mining) and as a board member at Ocean, I have been working for two years on a project related to enhancing block space access.  This proposed change in standardness may impact my project in a negative manner, and, it is certainly possible others might be in a similar position.  Regardless, changes to standardness are HUGE.  I spent most of my career within the Personal Computer space and learned the hard way that changes to a standards are a dangerous game.   I expand a bit on this in this X  post:: https://x.com/boomer_btc/status/1917687830148526095

  2.  The proposed change also appears to be reduction in flexibility and configurability.  In general, this is never a good thing.  IMO, we should be going in the direction of giving people more choices and flexibility (although it is fine to make suggestions, set defaults, or provide general guidelines.)  How someone configures their node and creates their mempool is akin to free speech within Bitcoin. The same goes for those like me that are miners and create our own block templates – this is also part of our free speech (and our business).  In the end though, whether you are a user or a miner, the more choices you have, the more freedom of speech you have.

Side note: Ultimately, as a miner I am in the business of creating block space – at least that is my view, and contrary to popular belief, miners are not always motivated to simply pick transactions that generate the highest block reward in the immediate block, and as time goes by this will become even more common and apparent.  I’ve spoken a lot on this recently in public forums, so I won’t dwell on it here.


  1.  Finally, there is the issue of an OP_RETURN change, if it encourages more spam, and if we are just caving into an inevitability.  I am against the proposed change and, even if that is true that the spam will ultimately find a way, I feel we are acquiescing way too early.  Enough has been said on this topic in other forums so I won’t go further.



From: bitcoindev@googlegroups.com <bitcoindev@googlegroups.com> on behalf of PandaCute <pandacute12345678@gmail•com>
Date: Friday, May 2, 2025 at 7:11 AM
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
You don't often get email from pandacute12345678@gmail•com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
I think this debate is missing one important part: a communication link between the developers and the users. The developers are speaking with the developers, the users are speaking with the users, and no one is really trying to understand where the other side is coming from. It's been a lot of aggressive, unproductive back-and-forth, with both sides accusing each other of bad intentions and completely dismissing each other's points.

This is a technical mailing list aimed at devs, so I'll try to summarize what I've seen in normal_users_land, and the general feeling out there right now. Obviously, I'm not trying to suggest that users *feelings* should be dictate the technical direction of Bitcoin. However, it is important that there is mutual respect and trust between users and devs.

Right now, trust is pretty broken. It can be regained, but not without understanding what went wrong in the first place.

I saw on IRC some devs suggesting they spend time on podcasts and social media to explain the motivations behind this proposal *before* merging it, instead of merging now and hoping people just accept it. I think that’s a fantastic idea, and the way to go. I particularly liked jonatack's message - “if Core shows humility and patience, it would surprise people and improve things.”

Now, about the proposal itself and what it *feels* like: It’s a big change that came out of nowhere, especially at a time when spam doesn’t seem like a big issue. It’s a bit… shocking? Normally Bitcoin changes are discussed for ages, PRs take so long to get merged, because of all the care that devs put into considering the pros and the cons, but here? We get a mailing list post (that no user is reading, let’s be honest) and a PR with a lot of contributors saying “yeah, let’s do this!”. There should be a bit more research. (Maybe there was, but behind closed doors?). We want to know about all the protocols that are bloating the UTXO set and that could be using OP_RETURN instead. We want to know how many transactions like these are in each block, and how many there will be once the new protocols start getting deployed. We want to see that you did your homework for weeks before trying to change the policies.

It feels weird—like some sort of attack or a bribe. One protocol is mentioned that would benefit from this change, and then an investor ACKs the PR. Someone points out a potential conflict of interest, and their comment gets hidden. That’s shady, no denying it.

And then, it feels that users have no say. It's a ""technocracy"", where devs have all the power in their hands and can decide where the protocol goes, while completely dismissing users' concerns.

Users do have concerns—lots of them. And I encourage devs to step out and talk to "regular" Bitcoin users. It’s not just a “loud minority”—there are many people genuinely worried: “Can we trust Core devs anymore? Is there even another option?”. But their concerns are dismissed, their comments deleted or hidden, they're treated like "bullies" that devs should ignore, devs should "merge Todd's PR and call it a day".

Without understanding all the technical details, I'd say there's a pretty good chance that the very smart people that work on Core are right once again. Statistically, it's very likely. Communicate to users, explain your motivations, and show that you want to listen to our concerns.

Lastly, as irritating as that might be, users freaking out and holding core developers accountable and flooding Github is a feature, not a bug. Devs aren't the Bitcoin gods, they are humans, and humans can be bribed,  can be coerced, can have conflict of interest, can fck up.

Users care and want to protect Bitcoin. Be grateful.

Respectfully,
A Bitcoin Dev
On Friday, May 2, 2025 at 12:46:20 AM UTC+2 Antoine Poinsot wrote:
As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_drama.

Going through the emails in order.

Am I the only one left on this list who actually cares about Bitcoin's survival?

Thanks Luke for your measured take. It's refreshing to see we have adults on both sides of this "debate".

With that history in mind, removing limits on OP_RETURN standardness size is pointless.

Yes, it is pointless for people who want to store massive amount of data. It is not for people who want to store a small amount of data in a time-sensitive transaction's output. Because they need their transaction to be relayed on the p2p network, and are therefore pushed to use unspendable outputs instead.

Relaxing OP_RETURN size limits without dealing with the inscriptions

This is orthogonal. The harmful behaviour described in OP is possible today regardless of inscriptions.

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?

You have obviously not properly read or understood OP. There is no need to speculate about what would happen or not. People are using outputs to store data today​. The only question now is harm reduction: given that people are storing this data in outputs today, do we want to offer a way to do it that does not force every single full node on the network to store their data forever?

That said i agree that this is not going to change anything for people who try to store large amount of data onchain, they already have a 4x cheaper way of doing so.

For example, let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN.

The point about storing data on everyone's disk was addressed by others: it's already possible and that's why Core XOR's the content of third-party-controlled data it writes to disk. But an interesting fact on this specific point about malware and OP_RETURN outputs is how they have already been used in the past to resiliently update the domain of a malware's C2 servers: https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .

This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety. [...] Bitcoin as we know it changes forever in the most fundamental way imaginable

Wild emotional claims with no ground whatsoever don't convince anybody and only hurt your credibility.

and we might as well give up on Bitcoin ever being a thing if this is the path chosen

Well if you believe the whole system is as brittle as relying on people playing nice for security, you might as well give up now.

Have the courage to reject this type of thing for the sake of the overall project.

Right. We do that, and you go outside and touch some grass for the benefit of all subscribers to this mailing list.

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. 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.

Doubt.

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.

Thank you for taking conceptual discussion to the mailing list. AJ already addressed your claims, so i won't repeat it here.

This is just a temporary cease-fire while the spammers reload their ammunition. There is obviously about to be another wave

Between this one and your previous email, you certainly do know a lot about the future! How's your trading going?

otherwise what is the point of eliminating OP_RETURN restrictions?

To not force people to bloat the UTxO set to store a trivial amount of data in the output of a time-sensitive transactions. On the specifics, Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte Groth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrembal_/status/1918008476552356202). I don't know and don't care why they do it in this way in particular, i just wish they did so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as they do today. Or worse, start thinking about bare multisig.

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.

Money printer financing working people forever certainly isn't something i expected to read on the Bitcoin dev mailing list!

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

This is veering off-topic for this thread. If you want to argue that Core should filter inscriptions could you take it to the appropriate thread? This thread is just about damage control for people storing data in transaction outputs.

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.

Your hubris gives me second-hand embarrassment. I hope the C2 domain update i shared above gives you a clue that there does in fact exist other smart people in the world. Threat actors would laugh pretty hard at your arrogant emails and emotional breakdowns, but they probably don't care about your filters in the slightest anyways.

After reading the whole thread i have yet to read a single sound objection to lifting the OP_RETURN restrictions.
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <daro...@protonmail•com> 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<mailto:bitcoindev+unsubscribe@googlegroups•com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com<https://groups.google.com/d/msgid/bitcoindev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%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/BY5PR03MB5171138582C249F82228689A968D2%40BY5PR03MB5171.namprd03.prod.outlook.com.

[-- Attachment #2: Type: text/html, Size: 41936 bytes --]

 permalink raw reply	[|nested]
2025-05-02 11:16     ` [bitcoindev] " Sjors Provoost

  2025-05-02 16:43         ` Greg Maxwell
  
From: 'nsvrn' via Bitcoin Development Mailing List @ 2025-05-02 14:37 UTC (permalink / raw)
  To: Sjors Provoost;  Bitcoin Development Mailing List, PandaCute

"Spam is annoying but it always runs it course if you ignore it"
and 
"When relay policy shouldn't be more restrictive than what is actually being mined"

are contradictory statements by gmaxwell. Btw, 99.9% of transactions rn are standard, nothing has changed. People are pre-emptively making accomodation for a startup with a whitepaper. No one is making relay policy more restrictive, they're talking about making it more flexible "pre-emptively".



On Friday, May 2nd, 2025 at 7:18 AM, Sjors Provoost <sjors@sprovoost•nl> wrote:

> 
> 
> Op 2 mei 2025, om 02:14 heeft PandaCute pandacute12345678@gmail•com het volgende geschreven:
> 
> > It feels weird—like some sort of attack or a bribe. One protocol is mentioned that would benefit from this change, and then an investor ACKs the PR.
> 
> 
> This is a misunderstanding. One that probably should have been better communicated, because I can see why it creates a bad impression.
> 
> The Citrea protocol does not benefit from this change at all! We're just asking them nicely to please use OP_RETURN and not bloat the UTXO set.
> 
> The cost difference between OP_RETURN and fake public keys is negligible for them. I try to explain this in more detail here:
> 
> https://bitcoin.stackexchange.com/questions/126208/why-would-anyone-use-op-return-over-inscriptions-aside-from-fees
> 
> We can only hope they do so, but why would they? They already wrote the code, and now they have to spend engineering hours to deviate from their whitepaper design. For what, just to be a good citizen? Their developers are getting attacked for agreeing with this change. And since the proposal is controversial, they can't even count on this actually going through in time for whenever they want to launch.
> 
> As someone once said: we don't have the cards here.
> 
> - 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/1B78AC90-E698-421F-AECD-32DBCDD8669A%40sprovoost.nl.

-- 
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/s0wjN-XWg2inZbTjDilS4QsIddAa6sP7Zo7xp2XxcheO1d21g-7Jy_-okj96LPEBSAV1BtoEnrIKzgZLi06c1aka0kvFiR3l0YqxYxuTHRQ%3D%40pm.me.


 permalink raw reply	[|nested]
2025-05-02 14:37       ` 'nsvrn' via Bitcoin Development Mailing List

  
From: Greg Maxwell @ 2025-05-02 16:43 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3442 bytes --]

On Friday, May 2, 2025 at 3:28:36 PM UTC nsvrn wrote:

"Spam is annoying but it always runs it course if you ignore it" 
and 
"When relay policy shouldn't be more restrictive than what is actually 
being mined" 

are contradictory statements by gmaxwell. Btw, 99.9% of transactions rn are 
standard, nothing has changed. People are pre-emptively making accomodation 
for a startup with a whitepaper. No one is making relay policy more 
restrictive, they're talking about making it more flexible "pre-emptively". 


I've looked high and low and I can't find any case where I've made the 
first quotation. Can you help me out?  It sounds like a riff on views I 
expressed but I can't find it.

I think your comparison though demonstrates a downside of reasoning in 
broad categories.   High volume nuisance traffic tends to burn itself out 
because the user that is flooding out everyone else has to burn whatever 
everyone else was willing to pay in each block everyone else is displaced 
from-- they run out of money.  But my statement on relay policy doesn't 
have much to do with volume.  A small consistent _small_ stream of 
transactions that aren't getting relayed but get mined anyways brings the 
downsides of having a mining inconsistent relay policy, there doesn't need 
to be a flood. And no flood, no self limiting behavior in any case.

I also think your argument misses the mark in that there isn't a credible 
argument that there is/will-be any traffic floods that the 
proposed-for-removal criteria will *prevent*.  Anyone who wants to stuff 
data into outputs can already stuff an unlimited amount, there are parties 
right now who are currently doing so.  Moreover, there is no credible way 
to stop them from doing so (because you can't distinguish arbitrary data 
from addresses, essentially).   However, if they use OP_RETURN instead it 
will prevent the data from going into the UTXO set.  Maybe they will maybe 
they won't.  But counting this proposal with concerns about 'spam' doesn't 
get us anywhere because removing the restriction doesn't change the current 
situation with respect to 'spam' however you define it.

It doesn't really matter how dire spam is when discussing a proposal that 
doesn't meaningfully *change* the situation around it, except perhaps in 
giving a lever to convert some more harmful traffic into less harmful 
traffic.  If it did then sure the harms of the spam would be a relevant 
consideration.

> People are pre-emptively making accomodation for a startup with a 
whitepaper

I can't speak for others but I didn't follow any links related to citrea or 
any other startup in the thread, I don't think it's relevant.  I have been 
complaining about standardizes rules screwing up block reconstruction and 
direct to miner relationships to bypass relay rules for several years.  My 
impression is that random startup whatever carries precisely zero weight in 
minds of the vast majority of the commenters in favor of eliminating the 
restriction.

-- 
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/f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3991 bytes --]

 permalink raw reply	[|nested]
2025-05-02  9:51   ` Anthony Towns

  2025-05-05  9:18       ` Anthony Towns
  2025-05-02 20:43     ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
  
From: Greg Maxwell @ 2025-05-02 17:36 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 10784 bytes --]

On Friday, May 2, 2025 at 10:33:18 AM UTC Anthony Towns wrote:

Hmm, I don't actually think this is a good rule -- if followed strictly, 
it prevents ever making relay rules more restrictive, even for cases 
which are provably harmful for the network. 


Not so, deploy the restriction to mining behavior first.  The fact that it 
classically hasn't been separately configurable is an artifact of assuming 
that it's the same (and acknowledging that it needs to be!).

Though even if were true, it's not clear to me that reductions in 
permissiveness are particularly interesting.  It's not a one way valve, but 
kinda.  At least historically the community hasn't considered it 
particularly appropriate to restrict already accepted transactions,  this 
is affirmed when we look at the counter examples.

Consider High-S signatures.  There were active attacks this blocked, and 
yet it was still important to the discussion that third parties could run 
code to automatically convert users High-S signatures to low-S, and then 
people *did* run nodes that did precisely that for a long time.

So I would say that reductions in relay permissiveness are uncommon and 
exceptional, and if they happen at all will be on some case by case basis 
and justification and so the general principal need not apply.

And it will be critical for any proposal that violates the general 
principle to explain why it's reasonable to do so.  I mean they should 
already, because I think it's a good criteria an it's still a good one even 
if no project has said outright that they intend to follow it! :)  So for 
example, if it's violated as part of a credible transition to a new state 
where the behavior is again consistent then fine.

My view is that a principle like this is an objective, not an exact 
edict.   "Here is what we're trying to accomplish".  And that absolutely 
can get overridden by circumstance specific exceptions. 


Alternatively, if it's a rule with exceptions, then it's those exceptions 
that are the important factor and should be figured out. 


Exactly.
 

For example, the reason mining a "quadratic hashing bloat txn" is bad 
because it causes delayed block validation on its own, potentially in 
ways that aren't even sufficiently mitigated by running your node on 
extremely high end hardware. Transactions like that should really be 
removed from consensus validity not just prevented at the relay level, 
and BIP 54's consensus cleanup hopefully does that. 


Indeed.  When I considered this idea the examples I could come up where 
you'd really want to violated it were mostly ones where the consensus rule 
really needed to be fixed.

 

Miners have accepted out-of-band relay of spends of unknown 
segwit versions (which I presume is similar enough to the "unused 
opcode/successcode/version number or whatever" case), in particular 
txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 
in block 692261 (the taproot exception block). Even though that was not 
done by mistake or out of technical ignorance, I think doing such things 
extremely rarely through out of band mechanisms is pretty much fine. 
(Even if miners do it for profit, rather than as a 0-fee tx where the 
outputs are a donation to a developer funding group) 


Indeed, I don't think one-offs have any relevance to the idea I'm 
suggesting.

If adopted, a policy like that would be fairly easy to use to hold the 
network hostage: find a miner who doesn't much care and has perhaps 
0.1% of total hashrate, get them to mine txs spending segwit versions 2 
through 16, and forward a handful of such transactions to them every day. 
The transactions are getting mined regularly and reliably (at a rate 
of about once a week), the transactions aren't immediately damaging the 
network, the miner is making excess profits, and by your relay argument, 
the miner is gaining a slight advantage in being able to potentially 
mine two blocks in a row due to the block relay delays caused by not 
relaying spends of future segwit versions. 



I don't follow: If someone is doing that then the version numbers are toast 
for forward compatibility use. It doesn't matter what relay does, they're 
already toast.  The choice you have at that point is to allow their 
non-standard transactions to have collateral harm or not.

Forward compatibility is fragile like that.  In a world where miners were 
behaving adversarial to the network in such a manner additions to consensus 
rules would just cause short lived consensus forks w/ associated disruption.

One could, of course, adopt a revised form of my statement that exempts 
forward compatibility.   I kinda feel like this is missing the point a bit, 
but OTOH, one could switch to allowing them once it was clear that 
filtering them wasn't providing any value anymore.

I'd describe that class of policy as something of a "popularity contest" 
approach -- it's a policy that says that anything that's sufficiently 
popular is good/permissable. I think that makes sense as a check/balance 
approach -- "this think is popular, is there really a good reason why 
it's not permitted?" -- but not as the first thing we think about. 


Mining *policy* is inherently a popularity contest, particularly for 
restrictions since they don't work unless ~everyone does them.  They will 
always be vulnerable to someone convincing miners to ignore them.  Covering 
our ears and eyes w/ relay policy doesn't change that!

When a fragile tool is the best tool we have ... it's still the best tool 
and we should enjoy its benefits when we can.  But when it doesn't work 
anymore we shouldn't delusionally pine for the old days when it did at a 
cost of creating relay/mining inconsistency.

I'm not speaking in favor of popularity contests but rather in favor of 
acknowledging reality.

As a check/balance, I think that argument holds water, and should cause 
us to ask if your existing policies make sense. I think it's fair to 
say Bitcoin Core's existing policies (as expressed by its code, and not 
necessarily matching the policies of various forks of Core) are (in no 
particular order): 


A number of your examples are consensus rules, not relay policy.  That is 
an entirely different kettle of fish. 

Consensus rules have force even when some miners or even ~all miners don't 
agree.  So they do not have the problem that they're mooted when some miner 
eschews them.

The ones that aren't could be justified or refuted on their own merits but 
*regardless* of what anyone thinks of them, so long as they're policy they 
are moot if some miners ignore them. And that remains the case unless 
they're turned into consensus rules.
... and for most of them making them consensus rules has been considered 
and rejected.

There are some like lowS rule in legacy transactions which was always 
intended to become a consensus rule, but just hasn't due to low importance 
while it's not being broken by miners and due to general dysfunction in 
updating consensus rules which has allowed vulnerabilities in the consensus 
protocol to remain for years.

* encouraging data storage people to use commitments (7) didn't really 
work, and given that could be done via documentation or blog posts 


Oh I dunno about that, I've seen first hand quite a few discussions that 
basically went,  "I want magical free file storage!" "It doesn't provide 
that, you can have a commitment to prove your file existed, and that 
doesn't require stuffing the whole file in" "oh but I don't really want a 
commitment, I guess this doesn't do the thing I wanted".

* people with legitimate concerns about their node being overloaded 
should probably be concerned more by the "limit maximum block size 
growth to ~4GB/week" policy


Yes, that's what the capacity limit is for.

 

 (6) or prefering prunable data (2): 


Well there I don't follow, you flip a switch and then operating a full node 
goes from requiring a terabyte to requiring 30GB.  This is quite important 
and absolutely makes a difference in ability to run a node.

* one is that for that to only be "occassional" means that even 
vaguely legitimate use cases should have a supported way of 
being exercised via standard transactions without being much more 
expensive: eg, instead of consolidating 4000 transactions in a 
270kvB transaction, you might use consolidate 1333 transactions 
in each of three 91kvB transactions. That limits the amount of 
excess profits the miner can generate, in this example the 3kvB 
of savings would only justify paying about 1.1% higher than the 
going feerate for standard transactions, eg. 

* the other is that if you want to disallow this from happening 
even occassionally, then you want to have relay and consensus rules 
be the same; but that effectively means that any functionality 
upgrade needs to be done as a hard fork, which in turn likely has 
highly centralising effects around the developer team, as running 
old versions of the software becomes infeasible 


Right, my view is that one-offs aren't an issue. Relay policy can differ 
from mining policy for one-offs.  If that weren't my view then I would say 
that there should be no relay policy at all, anything consensus valid 
should relay.

And you hit on basically the primary example of why relay policy exists-- 
because some rules would be overly restrictive as consensus rules.

I don't agree with that at all: giving people what they ask for, even 
if it's literally a punch in the face, isn't disrespectful, it's the 
opposite. (Respecting other people isn't always the highest virtue, 
of course) 


Even if they're asking for a punch in the face because click-baiters on 
youtube convince them it would cure their cancer?  I'd rather tell them no 
thanks, get your punch elsewhere if you're that convinced.  (also, have you 
not punched someone? it hurts!)
 
But your point is received.

Even if they're fundamentally wrong, I think it's respectful to people who 
haven't yet given that up as a lost cause to leave them with a knob that 
gives them at least a chance to continue the fight for sometime longer. 


But better still to help them be effectual on it!


 

-- 
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/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 13894 bytes --]

 permalink raw reply	[|nested]
2025-05-02  6:34                   ` Anthony Towns

  2025-05-03  5:14                       ` 'nsvrn' via Bitcoin Development Mailing List
  
From: Peter Todd @ 2025-05-02 18:29 UTC (permalink / raw)
  To: Anthony Towns;  Chris Guida, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Fri, May 02, 2025 at 04:34:45PM +1000, Anthony Towns wrote:
> I don't share that concern, personally. Data storage is far more
> efficiently done outside of a blockchain (or more cheaply done on
> non-Bitcoin blockchains), and for any legitimate use case, avoiding
> wasting money on inefficient designs or unnecessary engineering projects
> lets you capture more of that value as profit. For scams and frauds,
> that doesn't apply, but scams and frauds only last until your pool of
> victims grows wise to your shenanigans.

I need to point out that Citrea, and plenty of other projects similar to
it, is not using Bitcoin as a data storage mechanism. It's using Bitcoin
as a data *publication* mechanism. What's important is by putting data
in the Bitcoin chain, we've proven that the data has been widely
published to a well defined audience of participants who would need to
see that data.

Even Lightning does this: HTLCs work because they ensure that data is
published in a way that allows others in the HTLC chain to be guaranteed
to see that data in a timely manner.

- 
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/aBUPFvXVhR3WoyPC%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-04-26  9:50 ` Luke Dashjr
  2025-04-26 10:53   ` Sjors Provoost

  2025-05-05  6:04     ` Bitcoin Error Log
  
From: Greg Tonoski @ 2025-05-02 18:56 UTC (permalink / raw)
  To: bitcoindev, Luke Dashjr

It can't be a serious proposal therefore I didn't answer it.
Bitcoiners run node software without that prospective bug so they
already decided against the change. I also care about Bitcoin's
survival and I agree with you. Thank you for Bitcoin Knots which is
more powerful and less buggy Bitcoin node software implementation,
superior to Bitcoin Core..

On Sat, Apr 26, 2025 at 11:53 AM Luke Dashjr <luke@dashjr•org> wrote:
>
> 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.
>
> --
> 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.

-- 
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/CAMHHROx7s31%2BcdKe0d3BdZDcjgshvsLc%3DfdS_JFmA5Ve%3DkBuJw%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-05-02  6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
  2025-05-02  9:51   ` Anthony Towns

  2025-05-02 20:10     ` Peter Todd
  
From: /dev /fd0 @ 2025-05-02 19:04 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 7442 bytes --]

Hi Greg,

> Some Bitcoiners are of the opinion that they still want a knob, I think 
doing so is a disrespectful placebo[*] but I don't have a strong opinion if 
an option remains-- 
> the code is safer and cleaner without some filtering rules that few users 
would use but that really just a question between software maintainers and 
users.
> That said, Bitcoin core has generally not had knobs to adjust relay 
policy as distinct from mining policy in large part because of the design 
assumption that the
> two need to be the same.  But in this case if there were a knob here I 
think would make more sense for it to control mining policy rather than 
relay policy,
> since it would actually have some effect in the mining context (in 
excluding the txn from your own blocks) while as a relay only thing it is 
impotent.

Config `mempoolfullrbf` was added in July 2022: 
https://github.com/bitcoin/bitcoin/pull/25353
It was made default in August 2024: 
https://github.com/bitcoin/bitcoin/pull/30493
Option was removed in November 2024: 
https://github.com/bitcoin/bitcoin/pull/30592

`datacarrier` and `datacarriersize` already exist, so why is it a big deal 
to remove them after a few months of monitoring the usage with stats? 

/dev/fd0
floppy disk guy

On Friday, May 2, 2025 at 12:17:40 PM UTC+5:30 Greg Maxwell wrote:

> On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:
>
>
> 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. 
>
>
> The situation is even somewhat worse than that:  There are a number of 
> design decisions where it's generally assumed that relay and mining policy 
> generally match, or at least that mismatches are short lived.
>
> When relay policy is more restrictive than what is actually being mined 
> there are at least two serious negative effects.
>
> The first is that the latency of block propagation is greatly harmed,  a 
> single missed transaction causes a tripling of the per hop transmission 
> delay.  If the missed transaction(s) are larger than the TCP window then 
> the increase may be many round trip times.  Also if the missed data is 
> large the currently unused prefill mechanism in compact blocks wouldn't 
> help (and would instead likely make things worse as then nodes will get 
> several times the same transaction data from different peers and you cannot 
> decode the compact block until all the prefill data has been received due 
> to the message checksum.  Delays in block propagation can have a 
> disproportionate effect on mining centralization because they cause larger 
> miners to have improved profitability over smaller ones. This happens 
> regardless of which party was on which side of the delay, no matter which 
> side is delayed its the smaller miner's expected profits that are 
> diminisned and the nature of mining competition means that less profitable 
> miners go bankrupt.
>
> This also encourages the establishment of direct miner submission which 
> can undermine the permissionless nature of bitcoin and in particular again 
> shifts profits towards larger miners because e.g. few would bother 
> connecting to a 1% miner's direct submission interface (if they could even 
> afford to make one).
>
> There are also a number of less significant harms, e.g. more restrictive 
> relay policy makes fee estimation less accurate/complete (though at least 
> estimation is designed to be fairly robust in that direction). 
>
> So on this basis I suggest a principle for these sorts of policy:   Relay 
> rules should admit all transactions which are reliably being mined.
>
> I think node software should adopt this principal as a general rule.
>
> Admitting the transactions is not endorsing them, it's just a recognition 
> of reality.  This policy or equivalent is also the requirement to not 
> suffer from the downsides of relay being more restrictive than mining.   If 
> we imagine that a miner is mining some kind of harmful attack transaction 
> e.g. a validation DOS attack, then the miner needs to be convinced to stop, 
> the implementation changed to not have bad performance, and/or consensus 
> rules must be changed ... but relay policy can't address it.
>
> By general rule I mean that should something like a miner begin mining 
> e.g. quadratic hashing bloat legacy txn, or using unused 
> opcode/successcode/version number or whatever by mistake or technical 
> ignorance there is no need to rush off enabling their relay. A general rule 
> isn't a suicide pact.  But if it were the case that transactions misusing a 
> particular forward compatibility feature were reliably getting mined then 
> that feature would just no longer be useful for forward compatibility 
> regardless of what relay policy says about it and it would be better to 
> relay them than have the downsides of not doing so.
>
> As Antoine Poinsot points out, the existent rule is entirely ineffectual:  
> Parties current bypass these rules with other transaction forms (such as 
> very harmful address stuffing which is impossible to block) or by direct 
> miner submission, which will continue considering the millions of dollars 
> miners have received mining transactions with violate the relay rules.  
> Because of this it will not become effectual with time or tweaking.  It is 
> a dead parrot^policy.  This is no surprise, since it's a product of 
> Bitcoin's anti-censorship properties that *generally* filtering will not 
> work except on the fringes.  As such there isn't practical upside to 
> keeping filtering beyond what miners currently perform. 
>
> Some Bitcoiners are of the opinion that they still want a knob, I think 
> doing so is a disrespectful placebo[*] but I don't have a strong opinion if 
> an option remains-- the code is safer and cleaner without some filtering 
> rules that few users would use but that really just a question between 
> software maintainers and users.  That said, Bitcoin core has generally not 
> had knobs to adjust relay policy as distinct from mining policy in large 
> part because of the design assumption that the two need to be the same.  
> But in this case if there were a knob here I think would make more sense 
> for it to control mining policy rather than relay policy, since it would 
> actually have some effect in the mining context (in excluding the txn from 
> your own blocks) while as a relay only thing it is impotent.
>  
>
> [*] It doesn't even conserve their resources meaningfully.  They'll still 
> receive and process the txn, then discard.  Then they likely have to fetch 
> it a second time when it shows up in a block.  Although they may save 
> re-transmitting it, on average network wide each transaction is sent once 
> and received once so the extra transmission for the block should offset the 
> relay savings.
>
>
>
>

-- 
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/47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8628 bytes --]

 permalink raw reply	[|nested]
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
  2025-05-02  0:14   ` PandaCute

  2025-05-02 22:58     ` [bitcoindev] " Greg Maxwell
  
From: Peter Todd @ 2025-05-02 20:03 UTC (permalink / raw)
  To: Antoine Poinsot;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]

On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_drama.

I agree with the linked write-up: the quality of debate has been
atrocious. We've had a bunch of people who should know better, making
points that don't make technical sense, and a bunch of passerby's
repeating that nonsense (as well as even more nonsensical arguments).

With that in mind, I thought it'd be worthwhile to Devil's Advocate the
change, and go through some technically valid arguments against it:


# _Uninterrupted_ Illicit Data

Credit where credit is due, this was the only reasonable argument
against that was actually brought up on GitHub. In short, OP_Return,
unlike other standard ways of embedding data in Bitcoin transactions,
allows for long uninterrupted, arbitrary, messages to be embedded
verbatim.

The claimed risk is that this data could then end up peoples' hard
drives, complicating forensics analysis in the future and potentially
falsely incriminating people. (if you can encode your illicit data such
that the right bytes happen to match Bitcoin opcodes, you can already
embed it verbatim, uninterrupted, as seen by how inscriptions embed data
in witnesses; Martin Habovštiak already brought this up on this very
list).

We already have this issue with dumb virus detection software. Which is
why a few years ago code was added to XOR "encrypt" the block*.dat files
by default (chainstate is also XOR "encrypted").

The only remaining argument here is if we should go to the trouble of
adding code to Bitcoin Core to convert existing block*.dat files to the
XOR scheme, without re-downloading.


# Setting Policy Expectations For a Consensus Change

While it is clearly infeasible to prevent people from publishing data
with Bitcoin's existing consensus rules, it _is_ hypothetically possible
to make data publication somewhat more expensive with consensus changes.
Gregory Maxwell outlined how to do so on this mailing list years ago
(I'm not going to dig up the reference). Basically his approach works as
follows:

1) Limit all data in the chain to be either hash digests, signatures,
pubkeys, or trivial values like true and false.

2) Require transactions to *prove* that every item of data is what it
claims to be with, e.g. a hash digest pre-image, a valid signature (for
a pubkey), or the fact that a signature was valid. I may be wrong. But I
*believe* that with protocol changes it is possible for Lightning and
Ark to work in this model.

3) Phase out non-compliant transactions, e.g. applying a block-weight
multiplier that increases over time to eventually make them entirely
unaffordable.

Note that such a scheme *will* require massive ecosystem wide change:
even existing address standards will need to be modified (and made
larger) to prove that you are paying to a real address rather than
something encoding data.

Also note that *even this* consensus change *still* won't entirely
prevent people from publishing data! No-matter what we do you can always
grind pubkeys and hashes to set the first 4-6 bytes of them to the value
that you want. Thus if you're pushing 32 bytes of data, encoded as 33
bytes including the serialized length, and get 5 bytes per push, you
have an overhead of about 6.6x. Existing data encoders have been happy
to pay even more money than that in terms of increased fees during fee
spikes; the difference in cost between witness space and txout space is
already 4x, and some are happy to publish data that way anyway.

A tricky thing here is upgrade paths. If we make these rules apply to
all transactions, with any version number, we've radically limited our
ability to upgrade the Bitcoin protocol in the future. We probably can
make this *not* apply to transactions and taproot script types with
unknown version numbers. However we'd have to do something like ensure
it only applies to insecure transactions without signatures. And even
then some miners will bypass this by mining that stuff anyway for a fee.
That's pretty ugly. _Maybe_ we can make a mechanism where miners signal
support to allow new version numbers first, prior to an upgrade. But
that also adds plenty of complexity.

That said, if the Luke's of the world want to make a reasonable
technical argument, come up with a reasonable scheme like the above and
show that it has a chance of actually getting implemented.

-- 
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/aBUlEOBqqrOIGHWC%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-02 19:04   ` /dev /fd0

  2025-05-04 20:04       ` Nagaev Boris
  
From: Peter Todd @ 2025-05-02 20:10 UTC (permalink / raw)
  To: /dev /fd0;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Fri, May 02, 2025 at 12:04:13PM -0700, /dev /fd0 wrote:
> Config `mempoolfullrbf` was added in July 2022: 
> https://github.com/bitcoin/bitcoin/pull/25353
> It was made default in August 2024: 
> https://github.com/bitcoin/bitcoin/pull/30493
> Option was removed in November 2024: 
> https://github.com/bitcoin/bitcoin/pull/30592
> 
> `datacarrier` and `datacarriersize` already exist, so why is it a big deal 
> to remove them after a few months of monitoring the usage with stats? 

The `mempoolfullrbf` option was a good example of how keeping an option
to reject otherwise standard transactions is just wasted effort. Having
the option didn't stop full-rbf replacements from getting mined; user's
refusing to relay a transaction type that a significant % of miners are
mining acomplishes nothing.

In that *specific* case there were a tiny number of users, Wasabi's
Coordinator being an example, where for technical reasons full-rbf
replacements caused problems until that code was fixed; giving those
users an option to temporarily disable those replacements was sort of
useful. But there's no reason to think that will be true with OP_Return
outputs, and in any case, you can just delaying upgrading your node
while you fix your broken code.

-- 
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/aBUmn9HIYj06vbsX%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-02  9:51   ` Anthony Towns
  2025-05-02 17:36     ` Greg Maxwell

  
From: Peter Todd @ 2025-05-02 20:43 UTC (permalink / raw)
  To: Anthony Towns;  Greg Maxwell, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On Fri, May 02, 2025 at 07:51:27PM +1000, Anthony Towns wrote:
> I think there's perhaps four conclusions you could reasonably draw about
> the policies above, wrt what's been discussed on this topic:
> 
>  * encouraging data storage people to use commitments (7) didn't really
>    work, and given that could be done via documentation or blog posts

At the moment the OpenTimestamps calendars I run are getting about 2.1
timestamp requests per second according to my logs (I keep two weeks
worth). In the past, people who *genuinely* needed mere timestamping
were inefficiently using OP_Return for it. A bit of education - and an
alternative that actually worked - has almost entirely eliminated that
usage and replaced it with something drastically more efficient.

The problem is, only a subset of use-cases can get away with mere
commitments. Citrea itself is an example: they genuinely need
proof-of-publication. A commitment is not enough. No amount of
"education" is going to convince them otherwise.

Keep in mind that Lightning also uses proof-of-publication: if an HTLC
goes on chain, spending it via the pre-image ensures that the pre-image
is published, ensuring the next party in the route also learns the
pre-image. It's a basic building block of lots of consensus algorithms.

-- 
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/aBUuY1k9oswEAEom%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-02 20:03   ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd

  2025-05-03  2:02       ` Martin Habovštiak
  2025-05-05 21:45       ` Peter Todd
  
From: Greg Maxwell @ 2025-05-02 22:58 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4807 bytes --]

On Friday, May 2, 2025 at 10:23:45 PM UTC Peter Todd wrote:

# _Uninterrupted_ Illicit Data 


To refine that, _illicit data_ is a problem and encryption at rest does not 
address particularly in so far as possession of some data is a strict 
liability crime.

Uninterrupted however means that it's more likely to get caught by random 
scanning tools and whatnot -- and the encryption does that and probably 
eliminates most of difference between interrupted and not, which is Peter 
Todd's point.

But I heard someone last night say that encryption solves the illicit data 
issue and it absolutely doesn't. It solves a particular unexciting but more 
immediate sub part of the problem which is stuff like AV scanners.  But I 
think that issue is orthogonal to this proposed change.

Aside, I'd been thinking there was a consensus limit on output sizes of 
10kb but now I'm remembering that it's just at spend time and so obviously 
wouldn't be relevant here.
 

to make data publication somewhat more expensive with consensus changes. 
Gregory Maxwell outlined how to do so on this mailing list years ago 


A point of clarification,  that's really a scheme to keep arbitrary data 
out of unprunable data.  The proofs that the values in question are what 
they're supposed to be are themselves arbitrary data channels.  But these 
proofs are prunable.

It's true that they they only need to be carried near the tip, so you could 
even consider them *super prunable*.   And while perhaps you can get many 
existing transaction patterns into that model, I'm pretty confident you 
can't eliminate high bandwidth channels in script without massively 
hobbling Bitcoin overall.  (Though hey, there are a lot of people out there 
these days who would like to hobble bitcoin, so ::shrugs::)  

Even if the functionality reduction were worth it, I dunno that the gain 
between prunable (where most data storage stuff is) and super-prunable is 
that interesting, particularly since you're looking at on the order of a 
20%-30% increase of bandwidth for transactions and blocks to carry those 
proofs.  Though for context I then eventually most nodes will sync through 
some kind of utxo fast forward, just due to practical considerations, and 
w/ that the difference in prunability degree is diminished further.

It might make sense for just *outputs* if data stuffing into the UTXO set 
continues to be a problem as I think it can be done for just outputs 
without huge functionality loss... though even so the disruption and 
overheads yuck.  But before even considering such a disruptive change you'd 
want to be really user everything was done to get the storage out of the 
unprunable data first, e.g. by getting rid of limits on op_return size.

have an overhead of about 6.6x. Existing data encoders have been happy 
to pay even more money than that in terms of increased fees during fee 
spikes; the difference in cost between witness space and txout space is 
already 4x, and some are happy to publish data that way anyway. 


A point I raised on bitcointalk: If you work out how much it costs to store 
data on S3 (by far not the cheapest internet data storage) for *forever* 
you end up with a rate that is less than a hundred thousandth the current 
Bitcoin minimum fee rate-- maybe way less if you also factor in the cost of 
storage decreasing, but I didn't.  Data stuffers are not particularly price 
sensitive, if they were they wouldn't be using Bitcoin at all.  Schemes to 
discourage them by causing them increased costs (e.g. by forcing them to 
encode in ways that use more block capacity) shouldn't be expected to work.

And to the extent that what many of these things have been doing is trying 
to profit off seigniorage-- creating a rare 'asset' to sell to some greater 
fool and profit off the difference-- further restricting them could 
increase their volume because the resource they need has been made more 
rare.  For the vast majority of users the ire comes about this stuff from 
the fact that they've driven up fees at times, but that is dependent on 
what they're willing to spend, which is likely not particularly related to 
the marginal data rates. (And one could always embed smaller jpegs, 
compress them better, or not use raw json instead of an efficient encoding 
if they cared.. which they clearly don't.)

-- 
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/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5705 bytes --]

 permalink raw reply	[|nested]
2025-05-02 22:58     ` [bitcoindev] " Greg Maxwell

  2025-05-05 21:45       ` Peter Todd
  
From: Martin Habovštiak @ 2025-05-03  2:02 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 7455 bytes --]

A few more points:
* I've just happened to talk to a lawyer and he confirmed that a) merely
having illegal content as a part of the chain is not illegal, at least not
as long as it's not possible to trivially open it with general-purpose
software b) images that are illegal with a bunch of red dots would still be
illegal
* That being said, confusing scanning tools is somewhat interesting but
solved by xoring. Being able to xor without redownloading is already
possible with an external tool. It'd be nice to have it integrated but I
think the people who want it should make the PR (or finance it)
* Funnily enough, my first Bitcoin project ever involved hiding data into
bitcoin addresses by grinding: https://github.com/Kixunil/btcsteg so it's
accessible to anyone who can google (disclaimer: I've never actually sent
anything into the chain using it; also please don't send any tips to that
address)

* There was an argument, that doing the red dot thing is difficult for
non-technical people. That's nonsense, I literally used ChatGPT to write
the code because I was lazy. It spit out perfectly working code on first
attempt.

* I'm writing a (Slovak) article about this and one of the points I made is
requiring signatures to prove dlog knowledge for non-p2tr outputs would
require more than double the size of current OP_RETURN limit per typical
transaction. IOW, if today every single transaction added a maximum
standard OP_RETURN it'd still be less data than trying to prevent it. And
that's just data size. Signature verification is MUCH more costly than
processing of OP_RETURN and whatnot.

* Requiring signatures and preimages for Taproot would destroy protocols
relying on NUMS and also completely remove all the benefits of Taproot.


So yeah, I don't see this ever being implemented. It's also quite ironic
that attempts to fight spam would make it much worse.


Dňa pi 2. 5. 2025, 21:00 Greg Maxwell <gmaxwell@gmail•com> napísal(a):

> On Friday, May 2, 2025 at 10:23:45 PM UTC Peter Todd wrote:
>
> # _Uninterrupted_ Illicit Data
>
>
> To refine that, _illicit data_ is a problem and encryption at rest does
> not address particularly in so far as possession of some data is a strict
> liability crime.
>
> Uninterrupted however means that it's more likely to get caught by random
> scanning tools and whatnot -- and the encryption does that and probably
> eliminates most of difference between interrupted and not, which is Peter
> Todd's point.
>
> But I heard someone last night say that encryption solves the illicit data
> issue and it absolutely doesn't. It solves a particular unexciting but more
> immediate sub part of the problem which is stuff like AV scanners.  But I
> think that issue is orthogonal to this proposed change.
>
> Aside, I'd been thinking there was a consensus limit on output sizes of
> 10kb but now I'm remembering that it's just at spend time and so obviously
> wouldn't be relevant here.
>
>
> to make data publication somewhat more expensive with consensus changes.
> Gregory Maxwell outlined how to do so on this mailing list years ago
>
>
> A point of clarification,  that's really a scheme to keep arbitrary data
> out of unprunable data.  The proofs that the values in question are what
> they're supposed to be are themselves arbitrary data channels.  But these
> proofs are prunable.
>
> It's true that they they only need to be carried near the tip, so you
> could even consider them *super prunable*.   And while perhaps you can get
> many existing transaction patterns into that model, I'm pretty confident
> you can't eliminate high bandwidth channels in script without massively
> hobbling Bitcoin overall.  (Though hey, there are a lot of people out there
> these days who would like to hobble bitcoin, so ::shrugs::)
>
> Even if the functionality reduction were worth it, I dunno that the gain
> between prunable (where most data storage stuff is) and super-prunable is
> that interesting, particularly since you're looking at on the order of a
> 20%-30% increase of bandwidth for transactions and blocks to carry those
> proofs.  Though for context I then eventually most nodes will sync through
> some kind of utxo fast forward, just due to practical considerations, and
> w/ that the difference in prunability degree is diminished further.
>
> It might make sense for just *outputs* if data stuffing into the UTXO set
> continues to be a problem as I think it can be done for just outputs
> without huge functionality loss... though even so the disruption and
> overheads yuck.  But before even considering such a disruptive change you'd
> want to be really user everything was done to get the storage out of the
> unprunable data first, e.g. by getting rid of limits on op_return size.
>
> have an overhead of about 6.6x. Existing data encoders have been happy
> to pay even more money than that in terms of increased fees during fee
> spikes; the difference in cost between witness space and txout space is
> already 4x, and some are happy to publish data that way anyway.
>
>
> A point I raised on bitcointalk: If you work out how much it costs to
> store data on S3 (by far not the cheapest internet data storage) for
> *forever* you end up with a rate that is less than a hundred thousandth the
> current Bitcoin minimum fee rate-- maybe way less if you also factor in the
> cost of storage decreasing, but I didn't.  Data stuffers are not
> particularly price sensitive, if they were they wouldn't be using Bitcoin
> at all.  Schemes to discourage them by causing them increased costs (e.g.
> by forcing them to encode in ways that use more block capacity) shouldn't
> be expected to work.
>
> And to the extent that what many of these things have been doing is trying
> to profit off seigniorage-- creating a rare 'asset' to sell to some greater
> fool and profit off the difference-- further restricting them could
> increase their volume because the resource they need has been made more
> rare.  For the vast majority of users the ire comes about this stuff from
> the fact that they've driven up fees at times, but that is dependent on
> what they're willing to spend, which is likely not particularly related to
> the marginal data rates. (And one could always embed smaller jpegs,
> compress them better, or not use raw json instead of an efficient encoding
> if they cared.. which they clearly don't.)
>
> --
> 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/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/16f3af30-985f-40b7-afc3-9faae892d824n%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/CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2%2BwFA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 8990 bytes --]

 permalink raw reply	[|nested]
2025-05-02 18:29                     ` Peter Todd

  
From: 'nsvrn' via Bitcoin Development Mailing List @ 2025-05-03  5:14 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Development Mailing List

Lightning network already has existing users, why should they agree with relaxing the limits for the other protocols like the one in question for whatever new use cases that aren't even interested in or aren't even monetary use-cases?

Most of them pitch that adding something equivalent to EVM to Bitcoin will help gain Bitcoin more market cap because it doesn't have enough market cap in the crypto. Nice pitch to their investors may be, but not so much to *existing* users of Bitcoin network and lightning.

Additionally, I would like to understand as a user - what will be the quantification for success of this change? If there's increased oversized op_return usage, you can claim - see that worked. If there's none, you can claim - see filters were indeed ineffective. It might not be starightforward to quantify if there are multiple startups trying to insert variety of data(data and commitments of data) in different ways and sizes.

Also, it is being said users who want to retain these options can transition to Knots but what it is not said is that users who don't want these can also transition to Libre Relay. You can then see overtime if usage of Libre Relay is growing or not to take some hint.


On Friday, May 2nd, 2025 at 10:05 PM, Peter Todd <pete@petertodd•org> wrote:

> 
> 
> On Fri, May 02, 2025 at 04:34:45PM +1000, Anthony Towns wrote:
> 
> > I don't share that concern, personally. Data storage is far more
> > efficiently done outside of a blockchain (or more cheaply done on
> > non-Bitcoin blockchains), and for any legitimate use case, avoiding
> > wasting money on inefficient designs or unnecessary engineering projects
> > lets you capture more of that value as profit. For scams and frauds,
> > that doesn't apply, but scams and frauds only last until your pool of
> > victims grows wise to your shenanigans.
> 
> 
> I need to point out that Citrea, and plenty of other projects similar to
> it, is not using Bitcoin as a data storage mechanism. It's using Bitcoin
> as a data publication mechanism. What's important is by putting data
> in the Bitcoin chain, we've proven that the data has been widely
> published to a well defined audience of participants who would need to
> see that data.
> 
> Even Lightning does this: HTLCs work because they ensure that data is
> published in a way that allows others in the HTLC chain to be guaranteed
> to see that data in a timely manner.
> 
> -
> 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/aBUPFvXVhR3WoyPC%40petertodd.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/Xw4wydsck5vp5fdVcyK8C7hmiNsRfUVveJjyJIZHJitIpo-K4MqOwu8g6c4GcN2Kq_3NrtdhbUeuv_BOveocZfdWjzjega321LKfzEQNGU4%3D%40pm.me.


 permalink raw reply	[|nested]
2025-05-02 20:10     ` Peter Todd

  2025-05-05 11:42         ` Greg Maxwell
  2025-05-05 21:30         ` Peter Todd
  
From: Nagaev Boris @ 2025-05-04 20:04 UTC (permalink / raw)
  To: Peter Todd;  /dev /fd0, Bitcoin Development Mailing List

On Fri, May 2, 2025 at 7:23 PM Peter Todd <pete@petertodd•org> wrote:
>
> On Fri, May 02, 2025 at 12:04:13PM -0700, /dev /fd0 wrote:
> > Config `mempoolfullrbf` was added in July 2022:
> > https://github.com/bitcoin/bitcoin/pull/25353
> > It was made default in August 2024:
> > https://github.com/bitcoin/bitcoin/pull/30493
> > Option was removed in November 2024:
> > https://github.com/bitcoin/bitcoin/pull/30592
> >
> > `datacarrier` and `datacarriersize` already exist, so why is it a big deal
> > to remove them after a few months of monitoring the usage with stats?
>
> The `mempoolfullrbf` option was a good example of how keeping an option
> to reject otherwise standard transactions is just wasted effort. Having
> the option didn't stop full-rbf replacements from getting mined; user's
> refusing to relay a transaction type that a significant % of miners are
> mining acomplishes nothing.
>
> In that *specific* case there were a tiny number of users, Wasabi's
> Coordinator being an example, where for technical reasons full-rbf
> replacements caused problems until that code was fixed; giving those
> users an option to temporarily disable those replacements was sort of
> useful. But there's no reason to think that will be true with OP_Return
> outputs, and in any case, you can just delaying upgrading your node
> while you fix your broken code.
>

If I understand correctly, the Wasabi bug is described in this issue:
https://github.com/WalletWasabi/WalletWasabi/issues/10648
It was opened in May 2023. If the option hadn't been available at that
time, it would have been much harder for Wasabi coordinators to
mitigate the issue — they would have had to patch Bitcoin Core or use
an alternative node implementation, rather than just toggling a
setting.

Also note that the bug in Wasabi was discovered after mempoolfullrbf
was added in July 2022. The first Bitcoin Core release to include this
change was v24.0.1, in December 2022. It took several months after
that release for the Wasabi team to realize that mempoolfullrbf=1
created problems for their use case. If the feature had been released
without a flag (enabled by default with no way to disable it) it would
have made things significantly harder for them.

There may also be users today who rely on datacarrier
behaviour/options without yet realizing they're scheduled for removal.
If the options are simply relaxed in the next release, users could
still set the values they need and have time to adjust their
infrastructure. It would give them a chance to move away from relying
on those settings before they're removed entirely in a future version.
Otherwise, they may be forced to either switch to another node
implementation or remain on version 29.

-- 
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_Vt41NOmM1Mscri%2B%3DSEPzPLb%2BZ83R2FzZkQuTVbBfGssMug%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-05-02 18:56   ` Greg Tonoski

  
From: Bitcoin Error Log @ 2025-05-05  6:04 UTC (permalink / raw)
  To: bitcoindev

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

I think it’s worth raising a meta-topic in light of the OP_RETURN debate:
namely, the importance of respecting the status quo as consensus, and the
need for Bitcoin Core to distance itself from acting as a governance body.

Most of you appreciate the idea of respecting user space, and the principle
that consensus is most easily expressed by the software already being run.
That’s the essence of Bitcoin’s credibility.

In this specific case, I don’t even care about the outcome. The utility and
consequence of policies and data use cases are already fundamentally
accounted for in Bitcoin’s design. It just isn’t a big deal.

But here are some things I think we should consider:

1. Even if we tweak OP_RETURN, Bitcoin Core will still enforce policies
that reject certain valid transactions, even when they are harmless
(non-flagged RBF, for example). The only way to eliminate this form of
protocol-level censorship is to remove the policy engine’s influence from
consensus-critical infrastructure altogether. As long as Core shapes what
is considered standard, it acts as a gatekeeper. True neutrality requires
removing these centralized filters, not tweaking them. We should not be
arguing over user-configurable settings in something called "Core."

2. Mempool fragmentation isn't caused by inscriptions alone. Fragmentation
of the mempool arises from disharmony, complexity, and policy change, not
from any specific class of transactions. Bitcoin Core is not the only
implementation and the default config is not the only config. Adding a
small set of explicit data use cases to OP_RETURN would not prevent users
from continuing to encode data in Taproot outputs or other mechanisms for
other reasons.

3. If Core plans to make Taproot witness data pruneable (they do, right?),
then the very premise of this conflict becomes largely irrelevant. Is the
UTXO “pollution” argument moot?

4. Even if you give data users a clean OP_RETURN path, the original reasons
for encoding data elsewhere haven’t gone away:
   • They may want resistance to censorship, since OP_RETURN data is
potentially filterable.
   • They may want to emulate “first-seen” behavior for zero-conf
coordination, especially in merchant or custodial systems.
   • They may simply not trust Core’s intentions, fearing future reversals
or targeted policy changes.
Fragmentation doesn’t go away by offering alternatives, it follows
incentives and distrust. Additional encoding options will coexist with
existing ones, not replace them.

5. Bitcoin Core should avoid being a governance body. Core’s behavior has
shown a pattern of shaping Bitcoin policy outside of consensus, through
policy enforcement and behavioral changes that affect what nodes and miners
relay and accept. This is de facto governance. Therefore, every Core policy
change, especially those affecting transaction relay or validation, should
be rejected by default (unless, MAYBE, they emerge organically, from actual
consensus in the wild or from config-based downstream distros).

The most dangerous centralizing force in Bitcoin today is not Ordinals or
data use, it’s Core acting as a de facto standards body, redefining
behavior outside the consensus process. If we are serious about
decentralization, we must decouple policy from protocol, and resist all
attempts by any one group to dictate Bitcoin’s rules unilaterally.

Also consider that, compared to the drama and disruption, the
utility/scaling/impact of Bitcoin rule changes overall, aside from the
blockspace increase, has been a disappointment anyway.


~John Carvalho

-- 
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/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4663 bytes --]

 permalink raw reply	[|nested]
2025-05-02 17:36     ` Greg Maxwell

  2025-05-05 21:34         ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
  
From: Anthony Towns @ 2025-05-05  9:18 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

On Fri, May 02, 2025 at 10:36:44AM -0700, Greg Maxwell wrote:
> On Friday, May 2, 2025 at 10:33:18 AM UTC Anthony Towns wrote:
> Hmm, I don't actually think this is a good rule -- if followed strictly,
> it prevents ever making relay rules more restrictive, even for cases
> which are provably harmful for the network.

Err, the text/plain alternative in your email apparently doesn't include
quote markers for the things you're quoting. :( I guess this is some
Google Groups innovation? I'll fix it manually in the other things where
I'm quoting you quoting me below.

I meant to mention this last email, but had forgotten where to find
the link. Personally, I think Greg's "relay extra transactions via weak
blocks" idea [0] from a year ago is an approach that should be considered
here. The TLDR is that if there are miners out there with different
relay policies than your node that are accepting transactions you'll
reject (eg, lower fee, new tx versions, more complicated dependencies,
...) then once they find a relatively high PoW share, have the network
relay that as a weak compact block, with full round-trips to gather
any transactions that weren't in your mempool and add those txs to your
extra pool to help with block reconstruction in the near future.

[0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1

That approach would also help improve block relay where standardness
policies are made less restrictive, for things like pay2anchor, package
rbf, or soft forks, when many nodes haven't upgraded to support the
new feature.

> Though even if were true, it's not clear to me that reductions in
> permissiveness are particularly interesting.  It's not a one way valve, but
> kinda.

I believe the Great Consensus Cleanup invalidates some transactions
that would currently be standard: the 2500 executed sig operations
limit is only claimed to avoid making **non-pathalogical** transactions
non-standard; I believe there are some pathalogical transactions that
would be standard today that will be invalid when/if BIP 54 is enforced
on chain.

> At least historically the community hasn't considered it
> particularly appropriate to restrict already accepted transactions, this
> is affirmed when we look at the counter examples.

I believe PR#1718 (0 value outputs are non-standard), PR#2577 (dust
outputs are non-standard) and PR#5000 (execution of undefined NOP opcodes
is non-standard) are examples of doing that. (There might be others,
I didn't look very hard)

https://github.com/bitcoin/bitcoin/pull/1718
https://github.com/bitcoin/bitcoin/pull/2577
https://github.com/bitcoin/bitcoin/pull/5000

(The high-S vs low-S example you gave is a case where an even better
solution was available; but that isn't always possible, obviously)

> So I would say that reductions in relay permissiveness are uncommon and
> exceptional, and if they happen at all will be on some case by case basis
> and justification and so the general principal need not apply.

I don't think promoting general principles where you need to be a top-tier
expert to figure out the exceptions is very helpful: there are plenty
of non-experts with an interest in bitcoin and who wish to be involved
in protecting bitcoin's functionality as decentralised money, who'll
simply be misled by that sort of principle.

I think it is probably sufficient to phrase the principle backwards:
"relay/standardness rules can be made more restrictive, but there better
be a damn good reason for it".

I think that still gets the right message across, without having to
go through a "you're breaking the rules", "the rules have exceptions",
"that's dumb, they shouldn't", "yes they should", cycle.

> My view is that a principle like this is an objective, not an exact
> edict.   "Here is what we're trying to accomplish".  And that absolutely
> can get overridden by circumstance specific exceptions.

Yeah; I think we should be aware that there's a fair number of otherwise
well intentioned bitcoiners out who'll mistake these things for edicts,
however.

> > Miners have accepted out-of-band relay of spends of unknown
> > segwit versions (which I presume is similar enough to the "unused
> > opcode/successcode/version number or whatever" case), in particular
> > txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
> > in block 692261 (the taproot exception block). Even though that was not
> > done by mistake or out of technical ignorance, I think doing such things
> > extremely rarely through out of band mechanisms is pretty much fine.
> > (Even if miners do it for profit, rather than as a 0-fee tx where the
> > outputs are a donation to a developer funding group)
> Indeed, I don't think one-offs have any relevance to the idea I'm
> suggesting.

Anything that you can do as a one-off, you can automate and repeat. If
you're going to react in some predictable way as soon as someone sets
up the automation, you might as well do it for the one-offs as well.

> > If adopted, a policy like that would be fairly easy to use to hold the
> > network hostage: find a miner who doesn't much care and has perhaps
> > 0.1% of total hashrate, get them to mine txs spending segwit versions 2
> > through 16, and forward a handful of such transactions to them every day.
> > The transactions are getting mined regularly and reliably (at a rate
> > of about once a week), the transactions aren't immediately damaging the
> > network, the miner is making excess profits, and by your relay argument,
> > the miner is gaining a slight advantage in being able to potentially
> > mine two blocks in a row due to the block relay delays caused by not
> > relaying spends of future segwit versions.

Just to note: if everyone else was in agreement, a 0.1% hashrate miner
would not block a soft fork activation (which usually requires something
like 90%-95% hashrate), and would not cause any meaningful risk of a
chain split even for light clients after activation. So I think under
traditional analysis you wouldn't expect such a miner to be able to
block the introduction of a new segwit version, given everyone else on
the network thinks it's a good idea.

> I don't follow: If someone is doing that then the version numbers are toast
> for forward compatibility use. It doesn't matter what relay does, they're
> already toast.

I don't believe that's true for segwit versions. Any such spends will take
the form of someone sending some funds to an undefined segwit address,
followed by someone spending from that address in an unverified way,
moving whatever funds were there to someone else. Because the spend is
unverified, whoever mines that transaction can steal those funds if they
choose, so will either be doing that and sending the funds to somewhere
they choose (eg the Brink donation address), or will, in general, have
been paid even more in fees (whether in-band or out-of-band) to send
the funds to somewhere specific, purely as theatre.

Adding verification rules on top of such spend attempts doesn't cause any
additional harm -- people wanting to fund miners can already do so more
efficiently by just paying fees, and people wanting to spam the utxo set
if everyone else doesn't comply to their demands can also already do so.

AntPool currently has about 20% hashrate, even ignoring the pools that
mine the same block templates. If its operators want to prevent future
soft forks, do we really want to establish that regularly mining garbage
transactions is a perfectly effective way of doing so?

> The choice you have at that point is to allow their
> non-standard transactions to have collateral harm or not.

If they continue to make such transactions, despite it no longer
transferring value to miners the way it did before, then that probably
serves to spam the utxo set, but if that's their goal, then there are
already plenty of ways to do that. I don't think preventing one particular
way of doing that is worth allowing them to hold upgrade paths hostage
at almost zero cost.

The same argument doesn't necessarily apply to every upgrade method --
segwit versions and OP_SUCCESS are essentially explicit "pay to miner"
in ways other upgrade methods aren't. But I don't think we should be any
more concerned with people losing access to funds they've encumbered via
undefined upgrade methods, any more than we were concerned with people
accepting unconfirmed transactions getting double spent.

> > I'd describe that class of policy as something of a "popularity contest"
> > approach -- it's a policy that says that anything that's sufficiently
> > popular is good/permissable. I think that makes sense as a check/balance
> > approach -- "this thing is popular, is there really a good reason why
> > it's not permitted?" -- but not as the first thing we think about.
>
> Mining *policy* is inherently a popularity contest, particularly for
> restrictions since they don't work unless ~everyone does them.  They will
> always be vulnerable to someone convincing miners to ignore them.  Covering
> our ears and eyes w/ relay policy doesn't change that!

That's a fine attitude if you're willing to just follow the current
fashion, and defer to others as to what that fashion is and how it will
change in the future. Given the complaints and lawsuits that can result
from trying to set a direction from Bitocin, I can certainly understand
the appeal of that attitude.

But there are plenty of people around who will attempt to influence what's
considered acceptable; the people making the complaints and filing the
lawsuits, in particular. More concretely, both Knots and Libre Relay
are putting themselves out there as taste makers and trend setters in
exactly that way, and are both happy to defend their respective views
on the merits.

> When a fragile tool is the best tool we have ... it's still the best tool
> and we should enjoy its benefits when we can.  But when it doesn't work
> anymore we shouldn't delusionally pine for the old days when it did at a
> cost of creating relay/mining inconsistency.
>
> I'm not speaking in favor of popularity contests but rather in favor of
> acknowledging reality.

Again, the distinction I'm making here is on how the judgement is made; whether
it's:

  * "well, this is popular, so we should give up and just accept it", or
  * "huh, this is popular, we should reconsider it on its merits"

If we're settling on the former (with the constraint that we only make
rules less restrictive) then I think we're very quickly going to move
to the "relay rules = consensus rules" approach [1], and from there to
"whoops, we can't make standardness rules more restrictive (because
that would likely be confiscatory), therefore can't make consensus rules
more strict via a soft fork, but we want to do an upgrade, so time for
a hard fork".

[1] eg, as advocated at https://x.com/0x_orkun/status/1918744573251121575

If we're settling on the latter, then the fundamental thing we're judging
our rules on is still their underlying merits, not their popularity,
and that should be the main thing we spend time discussing/evaluating.

> > As a check/balance, I think that argument holds water, and should cause
> > us to ask if your existing policies make sense. I think it's fair to
> > say Bitcoin Core's existing policies (as expressed by its code, and not
> > necessarily matching the policies of various forks of Core) are (in no
> > particular order):
> A number of your examples are consensus rules, not relay policy.  That is
> an entirely different kettle of fish.

At least some of those consensus rules were previously enforced
differently by policy, and could be again. For example the current
4GB/week limit was formerly 1GB/week by consensus, but prior to that was
250MB, 350MB and 750MB by miners sticking with core's default mining
policy.

I don't think core changing the default alone would have any effect there,
but if there were good reasons to reduce that number, then discussing
those reasons with miners, including how they would benefit as a result,
seems to me like it would have a good chance of working out, even without
consensus changes. (At present, I don't think there are good reasons
for such a reduction)

> Consensus rules have force even when some miners or even ~all miners don't
> agree.  So they do not have the problem that they're mooted when some miner
> eschews them.
>
> The ones that aren't could be justified or refuted on their own merits but
> *regardless* of what anyone thinks of them, so long as they're policy they
> are moot if some miners ignore them. And that remains the case unless
> they're turned into consensus rules.

Not every policy needs 100% enforcement to have a meaningful effect. For
example, if 99.9% of miners mine 250kB blocks, and 0.1% of miners mine
4MB blocks, that still limits the block size to 256kB on average.

This might be a rational/incentive-compatible policy for all of those
miners, if fees are a large component of block reward, and the capacity
constraint pushes the average fee paid by transactions up by more than 4x,
and the majority of miners are either taking a long term view themselves
or are in a large pool with signficant constraints on exit.

> There are some like lowS rule in legacy transactions which was always
> intended to become a consensus rule, but just hasn't due to low importance
> while it's not being broken by miners and due to general dysfunction in
> updating consensus rules which has allowed vulnerabilities in the consensus
> protocol to remain for years.

The lowS rule was part of BIP 62 (dealing with malleability) which was
withdrawn around the time segwit was proposed. Part of it was re-proposed
by Matt as part of the Great Consensus Cleanup (push-only scriptSig),
but that wasn't one of them. I wasn't aware there was any particular
interest/need in upgrading lowS to a consensus rule, for instance.

In any event, the "general dysfunction in updating consensus rules"
largely takes the form of "I don't have confidence that we'll be able to
get consensus to agree to this change, which after all, isn't strictly
necessary". That's why the current BIP 54 doesn't include a restriction
on push-only scriptSig, eg -- disabling it isn't strictly necessary to
avoid the DoS attacks that we know about.

But if we aren't able to have the confidence to make standardness rules
more restrictive, I don't see why we should have any expectation of ever
cleaning things up in consensus: if a standardness change is adopted
by the network, it's still possible to get exceptions through in cases
where someone would have lost funds even if it requires paying exhorbitant
fees to a miner to special case your transaction; for a consensus change,
even that's not possible.

> > * encouraging data storage people to use commitments (7) didn't really
> >   work, and given that could be done via documentation or blog posts
> Oh I dunno about that, I've seen first hand quite a few discussions that
> basically went,  "I want magical free file storage!" "It doesn't provide
> that, you can have a commitment to prove your file existed, and that
> doesn't require stuffing the whole file in" "oh but I don't really want a
> commitment, I guess this doesn't do the thing I wanted".

(If you prefer, replace "didn't really work" with "worked for a time,
but that time has passed")

The key argument against using bitcoin for "magical free file storage"
is that it isn't free, or even as cheap as just paying for storage on
S3, not that you have to do ridiculous encoding tricks when your file
size passes various thresholds. In any event, those encoding tricks
have already been standardised and publicised, so I'd expect that the
normal response today to "it doesn't provide that" is "actually it does,
see <url>".

Alternatively, if you believe there's still some potential there, we
could perhaps resurrect ideas like restricting the OP_RETURN pushdata
[2], perhaps to at most 80-bytes (same as now, just allow more of them),
256-bytes (ie, anything that only needs PUSHDATA1), 520-bytes (matching
inscription chunking forced by MAX_SCRIPT_ELEMENT_SIZE), or 4096-bytes
(matching how much data you could stuff contiguously in a taproot control
block via fake merkle leaves).

[2] https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-65671770

> > * people with legitimate concerns about their node being overloaded
> >   should probably be concerned more by the "limit maximum block size
> >   growth to ~4GB/week" policy (6)

> >   or prefering prunable data (2):

> Well there I don't follow, you flip a switch and then operating a full node
> goes from requiring a terabyte to requiring 30GB.  This is quite important
> and absolutely makes a difference in ability to run a node.

That's because you somehow tore up my quote and dropped the "rather
than". In full, I wrote:

> > * people with legitimate concerns about their node being overloaded
> >   should probably be concerned more by the "limit maximum block size
> >   growth to ~4GB/week" policy (4), rather than commitments vs data (7),
> >   complicated scripts (6) or prefering prunable data (2):

that is, "they should be concerned with [the capacity limit], rather
than being concerned with [the witness discount and other things]". So
I don't think we're disagreeing.

> Even if they're asking for a punch in the face because click-baiters on
> youtube convince them it would cure their cancer?  I'd rather tell them no
> thanks, get your punch elsewhere if you're that convinced.  (also, have you
> not punched someone? it hurts!)

I think a lot of people won't be convinced something's stupid until
they've actually tried doing the stupid things themselves, and found it
really doesn't work. For that example, if getting punched in the face now
lets them go get tested to prove/disprove their theory, and, assuming the
punch in the face didn't work, go move on to a real treatment ASAP, then
if it was someone I cared even slightly about, I'd probably be willing
to deal with some hand pain, yes. Hopefully the youtube conspiracy allows
you to wear a boxing glove, though.

> > Even if they're fundamentally wrong, I think it's respectful to people who
> > haven't yet given that up as a lost cause to leave them with a knob that
> > gives them at least a chance to continue the fight for sometime longer.
> But better still to help them be effectual on it!

For me, saying "sorry, this has reached a threshold of popularity, you
have to give up and accept it now" makes me want to oppose it just as a
knee-jerk reaction, even things I otherwise think of as a good idea. I
expect the contrapositive "sorry, your idea isn't popular enough,
you have to give up on it" likewise gets a knee jerk rejection from
many bitcoiners.

For me, arguments of the form "this is actually good for bitcoin because
..." are much more helpful than "sorry, a minority of miners have already
decided this is okay, therefore your opinions just don't matter".

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/aBiCgRIRikR0MPei%40erisian.com.au.


 permalink raw reply	[|nested]
2025-05-04 20:04       ` Nagaev Boris

  2025-05-05 14:32           ` Nagaev Boris
  2025-05-05 21:30         ` Peter Todd
  
From: Greg Maxwell @ 2025-05-05 11:42 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]

On Monday, May 5, 2025 at 9:27:24 AM UTC Nagaev Boris wrote:

There may also be users today who rely on datacarrier 
behaviour/options without yet realizing they're scheduled for removal. 


How is it possible that anyone relies on it in a way that it will be a 
detriment to them?

"I run bitcoind because I want to help centralize the network through 
incentives to direct miner submission and slower block propagation, and by 
encouraging utxo bloating 'fake addresses' outputs! I also like diminishing 
my own ability to anticipate the content of the next block using data on my 
own node" ? :P   Were that actually someone's opinion I don't think anyone 
would regret inviting them to run different software.

I've been engaging 1:1 with people concerned about the change on forums for 
the last few days and I've haven't yet encountered any clear argument as to 
why someone would be harmed by the change.

Rather, I've found that they've simply been fed an incorrect argument that 
this change is a product of "bitcoin core" being in favor of non-monetary 
(ab)uses of the Bitcoin network, and that it will radically increase the 
amount of it.  As far as I can tell this is a total falsehood both respect 
to motivations and credible effects, and allegations otherwise just don't 
survive the sunlight of a competent counterargument.



-- 
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/39a1d0b6-ecbc-42fa-93aa-3c4f7038aa5en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2301 bytes --]

 permalink raw reply	[|nested]
* 
  2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (3 preceding siblings ...)
  2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-05-02  9:51   ` Anthony Towns
  2025-05-02 19:04   ` /dev /fd0
  2025-05-05 14:05 ` 
                   ` 
  8 siblings, 2 replies; 60+ messages in thread
From: Greg Maxwell @ 2025-05-02  6:29 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 5897 bytes --]


On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:


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. 


The situation is even somewhat worse than that:  There are a number of 
design decisions where it's generally assumed that relay and mining policy 
generally match, or at least that mismatches are short lived.

When relay policy is more restrictive than what is actually being mined 
there are at least two serious negative effects.

The first is that the latency of block propagation is greatly harmed,  a 
single missed transaction causes a tripling of the per hop transmission 
delay.  If the missed transaction(s) are larger than the TCP window then 
the increase may be many round trip times.  Also if the missed data is 
large the currently unused prefill mechanism in compact blocks wouldn't 
help (and would instead likely make things worse as then nodes will get 
several times the same transaction data from different peers and you cannot 
decode the compact block until all the prefill data has been received due 
to the message checksum.  Delays in block propagation can have a 
disproportionate effect on mining centralization because they cause larger 
miners to have improved profitability over smaller ones. This happens 
regardless of which party was on which side of the delay, no matter which 
side is delayed its the smaller miner's expected profits that are 
diminisned and the nature of mining competition means that less profitable 
miners go bankrupt.

This also encourages the establishment of direct miner submission which can 
undermine the permissionless nature of bitcoin and in particular again 
shifts profits towards larger miners because e.g. few would bother 
connecting to a 1% miner's direct submission interface (if they could even 
afford to make one).

There are also a number of less significant harms, e.g. more restrictive 
relay policy makes fee estimation less accurate/complete (though at least 
estimation is designed to be fairly robust in that direction). 

So on this basis I suggest a principle for these sorts of policy:   Relay 
rules should admit all transactions which are reliably being mined.

I think node software should adopt this principal as a general rule.

Admitting the transactions is not endorsing them, it's just a recognition 
of reality.  This policy or equivalent is also the requirement to not 
suffer from the downsides of relay being more restrictive than mining.   If 
we imagine that a miner is mining some kind of harmful attack transaction 
e.g. a validation DOS attack, then the miner needs to be convinced to stop, 
the implementation changed to not have bad performance, and/or consensus 
rules must be changed ... but relay policy can't address it.

By general rule I mean that should something like a miner begin mining e.g. 
quadratic hashing bloat legacy txn, or using unused 
opcode/successcode/version number or whatever by mistake or technical 
ignorance there is no need to rush off enabling their relay. A general rule 
isn't a suicide pact.  But if it were the case that transactions misusing a 
particular forward compatibility feature were reliably getting mined then 
that feature would just no longer be useful for forward compatibility 
regardless of what relay policy says about it and it would be better to 
relay them than have the downsides of not doing so.

As Antoine Poinsot points out, the existent rule is entirely ineffectual:  
Parties current bypass these rules with other transaction forms (such as 
very harmful address stuffing which is impossible to block) or by direct 
miner submission, which will continue considering the millions of dollars 
miners have received mining transactions with violate the relay rules.  
Because of this it will not become effectual with time or tweaking.  It is 
a dead parrot^policy.  This is no surprise, since it's a product of 
Bitcoin's anti-censorship properties that *generally* filtering will not 
work except on the fringes.  As such there isn't practical upside to 
keeping filtering beyond what miners currently perform. 

Some Bitcoiners are of the opinion that they still want a knob, I think 
doing so is a disrespectful placebo[*] but I don't have a strong opinion if 
an option remains-- the code is safer and cleaner without some filtering 
rules that few users would use but that really just a question between 
software maintainers and users.  That said, Bitcoin core has generally not 
had knobs to adjust relay policy as distinct from mining policy in large 
part because of the design assumption that the two need to be the same.  
But in this case if there were a knob here I think would make more sense 
for it to control mining policy rather than relay policy, since it would 
actually have some effect in the mining context (in excluding the txn from 
your own blocks) while as a relay only thing it is impotent.
 

[*] It doesn't even conserve their resources meaningfully.  They'll still 
receive and process the txn, then discard.  Then they likely have to fetch 
it a second time when it shows up in a block.  Although they may save 
re-transmitting it, on average network wide each transaction is sent once 
and received once so the extra transmission for the block should offset the 
relay savings.



-- 
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/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6750 bytes --]

^ permalink raw reply	[|nested] 60+ messages in thread
2025-05-05 11:42         ` Greg Maxwell

  
From: Nagaev Boris @ 2025-05-05 14:32 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

On Mon, May 5, 2025 at 8:52 AM Greg Maxwell <gmaxwell@gmail•com> wrote:
>
> On Monday, May 5, 2025 at 9:27:24 AM UTC Nagaev Boris wrote:
>
> > There may also be users today who rely on datacarrier
> > behaviour/options without yet realizing they're scheduled for removal.
>
>
> How is it possible that anyone relies on it in a way that it will be a detriment to them?
>
> "I run bitcoind because I want to help centralize the network through incentives to direct miner submission and slower block propagation, and by encouraging utxo bloating 'fake addresses' outputs! I also like diminishing my own ability to anticipate the content of the next block using data on my own node" ? :P   Were that actually someone's opinion I don't think anyone would regret inviting them to run different software.
>
> I've been engaging 1:1 with people concerned about the change on forums for the last few days and I've haven't yet encountered any clear argument as to why someone would be harmed by the change.
>
> Rather, I've found that they've simply been fed an incorrect argument that this change is a product of "bitcoin core" being in favor of non-monetary (ab)uses of the Bitcoin network, and that it will radically increase the amount of it.  As far as I can tell this is a total falsehood both respect to motivations and credible effects, and allegations otherwise just don't survive the sunlight of a competent counterargument.
>

My point is that it's hard to foresee every possible use case. We
don't know how everyone's infrastructure is set up. Some users might
only realize this change affects them after it's already released. And
if they do need to adjust something in their workflow, it's a lot
easier if they can temporarily restore the previous behavior. Right
now, those users aren't speaking up,  because they don't yet know
they'll be affected.

For example, someone might be running a device with very limited
resources that can't afford to store the full mempool, but also can't
disable it entirely. If they're only monitoring certain types of
transactions that never use OP_RETURN, filtering those out is a simple
and practical optimization.

Or consider a system that pulls mempool transactions via RPC from
Bitcoin Core. It might assume certain things about OP_RETURN outputs,
maybe it allocates a static buffer for them, and crashes if one turns
out to be unexpectedly large. Fixing that kind of issue may take time.
Keeping the option available gives operators the flexibility to update
their systems without breaking things in the meantime.

This isn't about defending every edge case as critical. It's just
about recognizing that once an option is removed, anyone who runs into
a problem is stuck. Leaving the setting in place for one more release,
even in a relaxed or discouraged state, gives people a fair chance to
adjust before it disappears.


-- 
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_Vt6WU37OX5_92rWf5e-aesA%2BRa5Smh69d4P33-0YaGu6YQ%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-05-04 20:04       ` Nagaev Boris
  2025-05-05 11:42         ` Greg Maxwell

  
From: Peter Todd @ 2025-05-05 21:30 UTC (permalink / raw)
  To: Nagaev Boris;  /dev /fd0, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 3546 bytes --]

On Sun, May 04, 2025 at 05:04:23PM -0300, Nagaev Boris wrote:
> > The `mempoolfullrbf` option was a good example of how keeping an option
> > to reject otherwise standard transactions is just wasted effort. Having
> > the option didn't stop full-rbf replacements from getting mined; user's
> > refusing to relay a transaction type that a significant % of miners are
> > mining acomplishes nothing.
> >
> > In that *specific* case there were a tiny number of users, Wasabi's
> > Coordinator being an example, where for technical reasons full-rbf
> > replacements caused problems until that code was fixed; giving those
> > users an option to temporarily disable those replacements was sort of
> > useful. But there's no reason to think that will be true with OP_Return
> > outputs, and in any case, you can just delaying upgrading your node
> > while you fix your broken code.
> >
> 
> If I understand correctly, the Wasabi bug is described in this issue:
> https://github.com/WalletWasabi/WalletWasabi/issues/10648
> It was opened in May 2023. If the option hadn't been available at that
> time, it would have been much harder for Wasabi coordinators to
> mitigate the issue — they would have had to patch Bitcoin Core or use
> an alternative node implementation, rather than just toggling a
> setting.

No, in this hypothetical case (see below) they could have just
downgraded to the earlier version. There's no rush to adopt new Bitcoin
Core versions.

> Also note that the bug in Wasabi was discovered after mempoolfullrbf
> was added in July 2022. The first Bitcoin Core release to include this
> change was v24.0.1, in December 2022. It took several months after
> that release for the Wasabi team to realize that mempoolfullrbf=1
> created problems for their use case. If the feature had been released
> without a flag (enabled by default with no way to disable it) it would
> have made things significantly harder for them.

Nope. Wasabi was actually running Bitcoin Knots, which had full-rbf
enabled by default long before Bitcoin Core did. In *their* case, IIRC
they just turned it off, fixed their code, and turned it back on.

> There may also be users today who rely on datacarrier
> behaviour/options without yet realizing they're scheduled for removal.
> If the options are simply relaxed in the next release, users could
> still set the values they need and have time to adjust their
> infrastructure. It would give them a chance to move away from relying
> on those settings before they're removed entirely in a future version.
> Otherwise, they may be forced to either switch to another node
> implementation or remain on version 29.

It is *very* hard to imagine removing datacarrier causing issues given
that oversized OP_Returns regularly show up in blocks. We don't need to
put unlimited effort into hypotheticals. The only way this would be an
actual issue if it you had mempool-specific code that was so broken that
it broke on an oversized OP_Return (or more than one), and yet somehow
you desperately needed to use a *new* version of Bitcoin Core.

-- 
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/aBkt5mtT-Zh2_hsl%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-05  9:18       ` Anthony Towns

  2025-05-06  8:56           ` Sjors Provoost
  2025-05-07 20:42           ` James O'Beirne
  
From: Peter Todd @ 2025-05-05 21:34 UTC (permalink / raw)
  To: Anthony Towns;  Greg Maxwell, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Mon, May 05, 2025 at 07:18:57PM +1000, Anthony Towns wrote:
> I meant to mention this last email, but had forgotten where to find
> the link. Personally, I think Greg's "relay extra transactions via weak
> blocks" idea [0] from a year ago is an approach that should be considered
> here. The TLDR is that if there are miners out there with different
> relay policies than your node that are accepting transactions you'll
> reject (eg, lower fee, new tx versions, more complicated dependencies,
> ...) then once they find a relatively high PoW share, have the network
> relay that as a weak compact block, with full round-trips to gather
> any transactions that weren't in your mempool and add those txs to your
> extra pool to help with block reconstruction in the near future.
> 
> [0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1

Weak blocks give an advantage to large miners. Small miners, who rarely
find blocks, are also going to rarely find weak blocks, making the
feature mostly useless for them in terms of their choice of
transactions, while simultaneously increasing bandwidth consumption
somewhat. Meanwhile large miners do find weak blocks often, making the
feature useful for them and making it even easier for them to profit by
including non-standard transactions. Which again, is something that
small miners can't do.

-- 
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/aBku-6CIjQKIQjRS%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-02 22:58     ` [bitcoindev] " Greg Maxwell
  2025-05-03  2:02       ` Martin Habovštiak

  2025-05-05 23:55         ` Greg Maxwell
  
From: Peter Todd @ 2025-05-05 21:45 UTC (permalink / raw)
  To: Greg Maxwell;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

On Fri, May 02, 2025 at 03:58:35PM -0700, Greg Maxwell wrote:
> A point of clarification,  that's really a scheme to keep arbitrary data 
> out of unprunable data.  The proofs that the values in question are what 
> they're supposed to be are themselves arbitrary data channels.  But these 
> proofs are prunable.

When you originally proposed the scheme that may have been true. But
these days you could probably use zero-knowledge-proofs to prove that
hash digests are in fact hash digests, without having to include the
actual pre-images of those hash digests.

> A point I raised on bitcointalk: If you work out how much it costs to store 
> data on S3 (by far not the cheapest internet data storage) for *forever* 
> you end up with a rate that is less than a hundred thousandth the current 
> Bitcoin minimum fee rate-- maybe way less if you also factor in the cost of 
> storage decreasing, but I didn't.  Data stuffers are not particularly price 
> sensitive, if they were they wouldn't be using Bitcoin at all.  Schemes to 
> discourage them by causing them increased costs (e.g. by forcing them to 
> encode in ways that use more block capacity) shouldn't be expected to work.

But Amazon doesn't offer a service to store data on S3 forever. Not even
indefinitely. The best you can do is pre-pay costs:

https://aws.amazon.com/about-aws/whats-new/2021/06/aws-now-allows-customers-to-pay-for-their-usage-in-advance-/

But even *that* service doesn't actually work in a lot of cases from
what I've heard. For example, I've heard that even if you have two
different AWS accounts, Amazon will use pre-paid funds from one to pay
the bills of another if they believe the accounts are the same
underlying entity (this is quite relevant to me as one of the ways I
backup the OpenTimestamps calendars I run is snapshots saved to S3
Glacier Deep Archive). There's also the issue that for Amazon's cheap
storage (S3 Glacier), it's quite hard for the general public to get
access to the data even if the person storing it wants to make it
available.

Comparing Bitcoin data storage/publication to centralized services like
AWS just isn't a good comparison. Like it or not, but public blockchains
are genuinely a unique service that aren't provided elsewhere.


Also of course, S3 only offers storage. Not publication. Things like
Citrea (and Lightning) specifically need data publication.

> And to the extent that what many of these things have been doing is trying 
> to profit off seigniorage-- creating a rare 'asset' to sell to some greater 
> fool and profit off the difference-- further restricting them could 
> increase their volume because the resource they need has been made more 
> rare.  For the vast majority of users the ire comes about this stuff from 
> the fact that they've driven up fees at times, but that is dependent on 
> what they're willing to spend, which is likely not particularly related to 
> the marginal data rates. (And one could always embed smaller jpegs, 
> compress them better, or not use raw json instead of an efficient encoding 
> if they cared.. which they clearly don't.)

No, they do. As fees increased the hype around these tradable assets
moved from heavy-weight inscriptions (full-on JPGs) to absurd,
lightweight, memecoins that could be "registered" with much smaller
inscriptions. Costs do matter, even to the scammy vibe trading industry.

-- 
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/aBkxapFiBxC_TeEy%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2025-05-05 21:45       ` Peter Todd

  
From: Greg Maxwell @ 2025-05-05 23:55 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2596 bytes --]

On Monday, May 5, 2025 at 11:39:02 PM UTC Peter Todd wrote:

When you originally proposed the scheme that may have been true. But 
these days you could probably use zero-knowledge-proofs to prove that 
hash digests are in fact hash digests, without having to include the 
actual pre-images of those hash digests. 


The schemes that I'm aware of mostly have huge side-channels in the proof.  
I think I constructed one before that didn't have one for proving bilinear 
keys, and it only proved a pubkey was a pubkey, but at best it's an extra 
constraint.

Goes back to what you're trying to accomplish, like assume network capacity 
to process/forward blocks as a fixed amount. Your concern with NFTs is them 
driving up fees. So now every transaction has to carry a proof its not 
embedding a jpeg and so the effective throughput of the network is halved 
or reduced by 30% or whatever from the proofs.  Not a win.  And of course 
were then imagining something with more cryptographic complexity than the 
whole of bitcoin just to close high bandwidth channels.  And low bandwidth 
channels on the order of 24 to 32-bits per independently adjustable piece 
of data still exist.


But Amazon doesn't offer a service to store data on S3 forever.


It doesn't my example was an economic analysis that just assumed you bought 
an investment to yield enough to pay for the S3.  If you actually want it 
you can construct it as a legal entity.

Also of course, S3 only offers storage. Not publication. Things like 
Citrea (and Lightning) specifically need data publication. 


Right I might have been unclear.  Some people are laboring under a mistaken 
belief that the objective of people putting large amounts of data in the 
blockchain is just to "store stuff" --- and my point is that it's 
outrageously uneconomical for that.  While there may be some on the margin, 
the reality is that people storing something believe they're getting some 
benefit out of doing it that they don't get from an actual storage 
solution.  On reddit I went over a few 
examples:  https://old.reddit.com/r/Bitcoin/comments/1kea81d/why_is_this_sub_quiet_about_the_current_debate/mqi0vfw/

-- 
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/47079bf1-19de-4354-880d-2d197cecb0a2n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3406 bytes --]

 permalink raw reply	[|nested]
2025-05-05 21:34         ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd

  2025-05-07 20:42           ` James O'Beirne
  
From: Sjors Provoost @ 2025-05-06  8:56 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


> Op 5 mei 2025, om 23:34 heeft Peter Todd <pete@petertodd•org> het volgende geschreven:
> 
> On Mon, May 05, 2025 at 07:18:57PM +1000, Anthony Towns wrote:
>> I meant to mention this last email, but had forgotten where to find
>> the link. Personally, I think Greg's "relay extra transactions via weak
>> blocks" idea [0] from a year ago is an approach that should be considered
>> here.

[...]

> Weak blocks give an advantage to large miners.

[..]

> Meanwhile large miners do find weak blocks often, making the
> feature useful for them and making it even easier for them to profit by
> including non-standard transactions. Which again, is something that
> small miners can't do.

On the one hand it allows big miners to get these non-standard transactions propagated early, so that their actual blocks don't get delayed.

On the other hand, as soon as they do that, any other miner can run off with the on chain fees. But that would then encourage out-of-band fees (even more).

There's an attribution problem, but although the weak blocks don't end up in the blockchain, they're still pretty good proof that a miner performed the requested service of (at least) spreading the transaction.

Perhaps weak blocks are only a good thing if they're linked in a chain, like in p2pool. They might work for individual pools internally (small, well connected?), but not for the global system.

- 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/5E8FF16C-A962-478E-A965-129EBEEB8E28%40sprovoost.nl.


 permalink raw reply	[|nested]
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>

  2025-05-07 11:32     ` Greg Maxwell
       [not found]     ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
  
From: pithosian @ 2025-05-07  1:20 UTC (permalink / raw)
  To: bitcoindev

[-- Attachment #1: Type: text/plain, Size: 7895 bytes --]

On Fri,  2 May 2025 06:47:44 +0000 (UTC)
Greg Maxwell <gmaxwell@gmail•com> wrote:

> 
> On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:
> 
> 
> 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. 
> 
> 
> The situation is even somewhat worse than that:  There are a number
> of design decisions where it's generally assumed that relay and
> mining policy generally match, or at least that mismatches are short
> lived.
> 
> When relay policy is more restrictive than what is actually being
> mined there are at least two serious negative effects.
> 
> The first is that the latency of block propagation is greatly harmed,
>  a single missed transaction causes a tripling of the per hop
> transmission delay.  If the missed transaction(s) are larger than the
> TCP window then the increase may be many round trip times.  Also if
> the missed data is large the currently unused prefill mechanism in
> compact blocks wouldn't help (and would instead likely make things
> worse as then nodes will get several times the same transaction data
> from different peers and you cannot decode the compact block until
> all the prefill data has been received due to the message checksum.
> Delays in block propagation can have a disproportionate effect on
> mining centralization because they cause larger miners to have
> improved profitability over smaller ones. This happens regardless of
> which party was on which side of the delay, no matter which side is
> delayed its the smaller miner's expected profits that are diminisned
> and the nature of mining competition means that less profitable
> miners go bankrupt.
> 
> This also encourages the establishment of direct miner submission
> which can undermine the permissionless nature of bitcoin and in
> particular again shifts profits towards larger miners because e.g.
> few would bother connecting to a 1% miner's direct submission
> interface (if they could even afford to make one).
> 
> There are also a number of less significant harms, e.g. more
> restrictive relay policy makes fee estimation less accurate/complete
> (though at least estimation is designed to be fairly robust in that
> direction). 
> 
> So on this basis I suggest a principle for these sorts of policy:
> Relay rules should admit all transactions which are reliably being
> mined.
> 
> I think node software should adopt this principal as a general rule.
> 
> Admitting the transactions is not endorsing them, it's just a
> recognition of reality.  This policy or equivalent is also the
> requirement to not suffer from the downsides of relay being more
> restrictive than mining.   If we imagine that a miner is mining some
> kind of harmful attack transaction e.g. a validation DOS attack, then
> the miner needs to be convinced to stop, the implementation changed
> to not have bad performance, and/or consensus rules must be changed
> ... but relay policy can't address it.
> 
> By general rule I mean that should something like a miner begin
> mining e.g. quadratic hashing bloat legacy txn, or using unused 
> opcode/successcode/version number or whatever by mistake or technical 
> ignorance there is no need to rush off enabling their relay. A
> general rule isn't a suicide pact.  But if it were the case that
> transactions misusing a particular forward compatibility feature were
> reliably getting mined then that feature would just no longer be
> useful for forward compatibility regardless of what relay policy says
> about it and it would be better to relay them than have the downsides
> of not doing so.
> 
> As Antoine Poinsot points out, the existent rule is entirely
> ineffectual: Parties current bypass these rules with other
> transaction forms (such as very harmful address stuffing which is
> impossible to block) or by direct miner submission, which will
> continue considering the millions of dollars miners have received
> mining transactions with violate the relay rules. Because of this it
> will not become effectual with time or tweaking.  It is a dead
> parrot^policy.  This is no surprise, since it's a product of
> Bitcoin's anti-censorship properties that *generally* filtering will
> not work except on the fringes.  As such there isn't practical upside
> to keeping filtering beyond what miners currently perform. 
> 
> Some Bitcoiners are of the opinion that they still want a knob, I
> think doing so is a disrespectful placebo[*] but I don't have a
> strong opinion if an option remains-- the code is safer and cleaner
> without some filtering rules that few users would use but that really
> just a question between software maintainers and users.  That said,
> Bitcoin core has generally not had knobs to adjust relay policy as
> distinct from mining policy in large part because of the design
> assumption that the two need to be the same. But in this case if
> there were a knob here I think would make more sense for it to
> control mining policy rather than relay policy, since it would
> actually have some effect in the mining context (in excluding the txn
> from your own blocks) while as a relay only thing it is impotent. 
> 
> [*] It doesn't even conserve their resources meaningfully.  They'll
> still receive and process the txn, then discard.  Then they likely
> have to fetch it a second time when it shows up in a block.  Although
> they may save re-transmitting it, on average network wide each
> transaction is sent once and received once so the extra transmission
> for the block should offset the relay savings.
> 
> 
> 

On block propagation:
> When relay policy is more restrictive than what is actually being
> mined there are at least two serious negative effects.
> The first is that the latency of block propagation is greatly harmed,
>  a single missed transaction causes a tripling of the per hop
> transmission delay.

If I'm reading this correctly (and there's every chance I'm not):

1. When a node receives a compact block, it completely checks the
block's validity before relying it.
2. If the block includes txs which aren't in the node's mempool, it
needs to request those txs from peers before it can validate (and
subsequently relay) it.
3. This can slow down propagation of blocks significantly (as this cost
can, in the worst case, be incurred 'per hop').

If my above understanding is correct, then as far as I can tell, this
problem has nothing to do with mempool tx relay policy, and can be
solved by tweaking block relay policy.

On receiving a block:
1. Check whether the block meets the POW target.
2. If it does, relay it.
3. Validate the contents of the block.
4. Apply it.

This removes the 'per hop' block propagation delay caused by retrieving
missing transactions, and the only threat, so far as I can tell, is
that someone might waste a lot of money mining an invalid block to get
nodes to relay it (but then quickly discard it), which doesn't seem
particularly worth it.

Of course, if a miner doesn't have an included transaction locally,
they still need to go get it before they can safely include txs in
their next block, but the propagation delay is removed, and that miner
can always make sure to run, and connect to peers running permissive
relay policy, such as librerelay, to decrease the odds of that
happening.

-- 
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/20250507012038.3EAE07C10F1%40smtp.postman.i2p.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

 permalink raw reply	[|nested]
2025-05-07  1:20   ` pithosian

       [not found]     ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
  
From: Greg Maxwell @ 2025-05-07 11:32 UTC (permalink / raw)
  To: pithosian;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 9459 bytes --]

That creates a withholding attack where you announce a block then withhold
some transactions entirely.

It does already relay to other full nodes before validating everything, but
the nodes need to have the data.

Of course the recipient's mining is also still delayed until validation so
even if not for the withholding issue it would only reduce the hop by hop
component.  (As the recipient would presumably not have the transaction
either with its relay blocked in the network and the transaction submitted
directly to the party that included.)

There are, of course, numerous optimizations that could be done to reduce
the impact... but none so effective as actually having the transaction and
even having already validated it, and all with considerable development
effort.




On Wed, May 7, 2025 at 10:49 AM pithosian <pithosian@i2pmail•org> wrote:

> On Fri,  2 May 2025 06:47:44 +0000 (UTC)
> Greg Maxwell <gmaxwell@gmail•com> wrote:
>
> >
> > On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:
> >
> >
> > 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.
> >
> >
> > The situation is even somewhat worse than that:  There are a number
> > of design decisions where it's generally assumed that relay and
> > mining policy generally match, or at least that mismatches are short
> > lived.
> >
> > When relay policy is more restrictive than what is actually being
> > mined there are at least two serious negative effects.
> >
> > The first is that the latency of block propagation is greatly harmed,
> >  a single missed transaction causes a tripling of the per hop
> > transmission delay.  If the missed transaction(s) are larger than the
> > TCP window then the increase may be many round trip times.  Also if
> > the missed data is large the currently unused prefill mechanism in
> > compact blocks wouldn't help (and would instead likely make things
> > worse as then nodes will get several times the same transaction data
> > from different peers and you cannot decode the compact block until
> > all the prefill data has been received due to the message checksum.
> > Delays in block propagation can have a disproportionate effect on
> > mining centralization because they cause larger miners to have
> > improved profitability over smaller ones. This happens regardless of
> > which party was on which side of the delay, no matter which side is
> > delayed its the smaller miner's expected profits that are diminisned
> > and the nature of mining competition means that less profitable
> > miners go bankrupt.
> >
> > This also encourages the establishment of direct miner submission
> > which can undermine the permissionless nature of bitcoin and in
> > particular again shifts profits towards larger miners because e.g.
> > few would bother connecting to a 1% miner's direct submission
> > interface (if they could even afford to make one).
> >
> > There are also a number of less significant harms, e.g. more
> > restrictive relay policy makes fee estimation less accurate/complete
> > (though at least estimation is designed to be fairly robust in that
> > direction).
> >
> > So on this basis I suggest a principle for these sorts of policy:
> > Relay rules should admit all transactions which are reliably being
> > mined.
> >
> > I think node software should adopt this principal as a general rule.
> >
> > Admitting the transactions is not endorsing them, it's just a
> > recognition of reality.  This policy or equivalent is also the
> > requirement to not suffer from the downsides of relay being more
> > restrictive than mining.   If we imagine that a miner is mining some
> > kind of harmful attack transaction e.g. a validation DOS attack, then
> > the miner needs to be convinced to stop, the implementation changed
> > to not have bad performance, and/or consensus rules must be changed
> > ... but relay policy can't address it.
> >
> > By general rule I mean that should something like a miner begin
> > mining e.g. quadratic hashing bloat legacy txn, or using unused
> > opcode/successcode/version number or whatever by mistake or technical
> > ignorance there is no need to rush off enabling their relay. A
> > general rule isn't a suicide pact.  But if it were the case that
> > transactions misusing a particular forward compatibility feature were
> > reliably getting mined then that feature would just no longer be
> > useful for forward compatibility regardless of what relay policy says
> > about it and it would be better to relay them than have the downsides
> > of not doing so.
> >
> > As Antoine Poinsot points out, the existent rule is entirely
> > ineffectual: Parties current bypass these rules with other
> > transaction forms (such as very harmful address stuffing which is
> > impossible to block) or by direct miner submission, which will
> > continue considering the millions of dollars miners have received
> > mining transactions with violate the relay rules. Because of this it
> > will not become effectual with time or tweaking.  It is a dead
> > parrot^policy.  This is no surprise, since it's a product of
> > Bitcoin's anti-censorship properties that *generally* filtering will
> > not work except on the fringes.  As such there isn't practical upside
> > to keeping filtering beyond what miners currently perform.
> >
> > Some Bitcoiners are of the opinion that they still want a knob, I
> > think doing so is a disrespectful placebo[*] but I don't have a
> > strong opinion if an option remains-- the code is safer and cleaner
> > without some filtering rules that few users would use but that really
> > just a question between software maintainers and users.  That said,
> > Bitcoin core has generally not had knobs to adjust relay policy as
> > distinct from mining policy in large part because of the design
> > assumption that the two need to be the same. But in this case if
> > there were a knob here I think would make more sense for it to
> > control mining policy rather than relay policy, since it would
> > actually have some effect in the mining context (in excluding the txn
> > from your own blocks) while as a relay only thing it is impotent.
> >
> > [*] It doesn't even conserve their resources meaningfully.  They'll
> > still receive and process the txn, then discard.  Then they likely
> > have to fetch it a second time when it shows up in a block.  Although
> > they may save re-transmitting it, on average network wide each
> > transaction is sent once and received once so the extra transmission
> > for the block should offset the relay savings.
> >
> >
> >
>
> On block propagation:
> > When relay policy is more restrictive than what is actually being
> > mined there are at least two serious negative effects.
> > The first is that the latency of block propagation is greatly harmed,
> >  a single missed transaction causes a tripling of the per hop
> > transmission delay.
>
> If I'm reading this correctly (and there's every chance I'm not):
>
> 1. When a node receives a compact block, it completely checks the
> block's validity before relying it.
> 2. If the block includes txs which aren't in the node's mempool, it
> needs to request those txs from peers before it can validate (and
> subsequently relay) it.
> 3. This can slow down propagation of blocks significantly (as this cost
> can, in the worst case, be incurred 'per hop').
>
> If my above understanding is correct, then as far as I can tell, this
> problem has nothing to do with mempool tx relay policy, and can be
> solved by tweaking block relay policy.
>
> On receiving a block:
> 1. Check whether the block meets the POW target.
> 2. If it does, relay it.
> 3. Validate the contents of the block.
> 4. Apply it.
>
> This removes the 'per hop' block propagation delay caused by retrieving
> missing transactions, and the only threat, so far as I can tell, is
> that someone might waste a lot of money mining an invalid block to get
> nodes to relay it (but then quickly discard it), which doesn't seem
> particularly worth it.
>
> Of course, if a miner doesn't have an included transaction locally,
> they still need to go get it before they can safely include txs in
> their next block, but the propagation delay is removed, and that miner
> can always make sure to run, and connect to peers running permissive
> relay policy, such as librerelay, to decrease the odds of that
> happening.
>
> --
> 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/20250507012038.3EAE07C10F1%40smtp.postman.i2p
> .
>

-- 
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/CAAS2fgQsQNmKLbaFDoee2yT_KwpvA7P3GnHy3%3DyhHUnEXma-NQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 11202 bytes --]

 permalink raw reply	[|nested]
[not found]     ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>

  
From: pithosian @ 2025-05-07 16:55 UTC (permalink / raw)
  To: Greg Maxwell;  bitcoindev

On Wed,  7 May 2025 12:11:09 +0000 (UTC)
Greg Maxwell <gmaxwell@gmail•com> wrote:

> That creates a withholding attack where you announce a block then
> withhold some transactions entirely.
> 
> It does already relay to other full nodes before validating
> everything, but the nodes need to have the data.
> 
> Of course the recipient's mining is also still delayed until
> validation so even if not for the withholding issue it would only
> reduce the hop by hop component.  (As the recipient would presumably
> not have the transaction either with its relay blocked in the network
> and the transaction submitted directly to the party that included.)
> 
> There are, of course, numerous optimizations that could be done to
> reduce the impact... but none so effective as actually having the
> transaction and even having already validated it, and all with
> considerable development effort.

> That creates a withholding attack where you announce a block then
> withhold some transactions entirely.

A miner can already do this to all of their direct peers. The only
difference is whether it gets passed along. What's the functional
difference between this, and a miner delaying broadcast of a block
entirely, besides the fact withholding transactions is network-visible?

> It does already relay to other full nodes before validating
> everything, but the nodes need to have the data.

It relays once it has all of the transactions, and has done preliminary
validation up to BLOCK_VALID_TRANSACTIONS.

To finish validating the block, nodes of course will need to have all
the transactions. But relay of the compact block doesn't need to be
slowed down by nodes who don't have all transactions yet. Minimal
validation (POW, header, merkleroot) should be sufficient for relay.

> Of course the recipient's mining is also still delayed until
> validation so even if not for the withholding issue it would only
> reduce the hop by hop component.

Which is the block propagation part.

Right now, your miner won't receive the compact block until every node
along whichever path reaches them first has all the transactions
locally. Every node who was missing some of those transactions will
slow down propagation. The miner could already have all the
transactions locally, and still, they could be delayed. If they don't,
it takes longer for them to even know that they're missing transactions.

If we relay compact blocks before we have all the transactions locally,
the miner gets the compact block without any missing TX delay. If they
already have all transactions, they can finish validation and get to
work no questions asked. If they don't, the only delay in building on
the new block is because transactions were missing *from their own
mempool*.

Whether miners choose to start mining an empty block on top of this new
block, which they haven't yet fully validated, or continue with existing
work until validation completes is up to them. A decision they already
have to make.

> As the recipient would presumably not have the transaction either 
> with its relay blocked in the network and the transaction submitted
> directly to the party that included.

As full-RBF demonstrated, transaction relay doesn't require every node
to have the same mempool policy. A small percentage of nodes running
permissive policy can get transactions to miners.

You don't need to try to force people to all use the same relay policy.
Never mind that it's impossible. The transaction can, and will be able
to reach miners via mempool relay by simply giving users more control
over their own node's policy, and lobbying enough of them to choose
more permissive relay policy.

-- 
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/20250507165518.0B5037C0EEB%40smtp.postman.i2p.


 permalink raw reply	[|nested]
2025-05-05 21:34         ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
  2025-05-06  8:56           ` Sjors Provoost

  
From: James O'Beirne @ 2025-05-07 20:42 UTC (permalink / raw)
  To: Peter Todd;  Anthony Towns, Greg Maxwell, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

This analysis excludes two important points:

1. If a small miner has a mempool that is marginally closer to a large
miner's, they will connect blocks found by that miner more quickly, making
their own mining operation more efficient.

2. A small miner benefits from becoming aware of (potentially large,
non-standard, or directly submitted) transactions because they may want to
make use of it in their own block templates for more revenue.

Bandwidth is rarely a limiting factor for template creators (as there are
many more expensive pieces of hardware required to have a competitive
mining operation), and so a miner may very reasonably decide that it's
worth trading some bandwidth (in the form of received weak blocks) for the
prospect of juicing their fee revenue and minimizing tip connection time.


On Mon, May 5, 2025 at 11:36 PM Peter Todd <pete@petertodd•org> wrote:

> On Mon, May 05, 2025 at 07:18:57PM +1000, Anthony Towns wrote:
> > I meant to mention this last email, but had forgotten where to find
> > the link. Personally, I think Greg's "relay extra transactions via weak
> > blocks" idea [0] from a year ago is an approach that should be considered
> > here. The TLDR is that if there are miners out there with different
> > relay policies than your node that are accepting transactions you'll
> > reject (eg, lower fee, new tx versions, more complicated dependencies,
> > ...) then once they find a relatively high PoW share, have the network
> > relay that as a weak compact block, with full round-trips to gather
> > any transactions that weren't in your mempool and add those txs to your
> > extra pool to help with block reconstruction in the near future.
> >
> > [0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1
>
> Weak blocks give an advantage to large miners. Small miners, who rarely
> find blocks, are also going to rarely find weak blocks, making the
> feature mostly useless for them in terms of their choice of
> transactions, while simultaneously increasing bandwidth consumption
> somewhat. Meanwhile large miners do find weak blocks often, making the
> feature useful for them and making it even easier for them to profit by
> including non-standard transactions. Which again, is something that
> small miners can't do.
>
> --
> 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/aBku-6CIjQKIQjRS%40petertodd.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/CAPfvXf%2B2wkB6MyN6Bogr8c6G3uZq255Ec90qC4y5WxuEGoCPrg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4436 bytes --]

 permalink raw reply	[|nested]
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (6 preceding siblings ...)
       [not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>

  2025-05-14 15:54 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
  
From: Anthony Towns @ 2025-05-12 13:47 UTC ( / )
  To: Antoine Poinsot;  Bitcoin Development Mailing List

On Thu, Apr 17, 2025 at 06:52:34PM +0000, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> 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].

The reason for limiting OP_RETURNs to 80 bytes of data is to encourage
developers to store hashes on the chain, rather than the actual
data. Why store 1GB when you can commit to it with a 32B hash, and save
99.9999968% in fees? In all this debate I haven't seen an analysis of
other alternatives Citrea/Clementine might use, rather than storing 144
bytes of data on chain.

As I understand it, the context in which they're using the data is the
following protocol:

 * we have three known groups: Operators, Watchtowers and Signers
 * we also have: Users and Challengers (who can be anyone)
 * we assume that there is at least 1 honest Operator, 1 honest Watchtower,
   1 honest Signer, and 1 honest Challenger, and >50% honest hashrate

When things go wrong, and one of the Operators tries to cheat, one way
they can do so is by publishing a claim that they posted a transaction
in a Bitcoin block that's not actually in the Bitcoin block chain. At
that point, an honest Watchtower observers the claim, and produces a
Groth16 proof that he has a more-work chain that does not contain the
block claimed by the Operator.

 * but what if the Operator was honest and the Watchtower was trying to cheat?

 * in that case, the claimed Groth16 proof can be evaluated via a sequence of
   transactions following the BitVM and will be found to be invalid

The Groth16 proof/evaluator here is acting as a light client (doing
header only evaluation), but with even less data than a traditional
light client -- it only needs the Groth16 proof, not the ~40MB of data
from all the block headers. While 40MB of data isn't much for a phone
or raspberry pi or similar, it is a lot if you need to manually provide
it to a BitVM program.

Because the Watchtower here may be dishonest, they can't just be expected
to publish a hash of their proof -- nobody else can generate the exact
same proof they would without their random inputs, and publishing their
random inputs as well as a commitment would also be more than 80 bytes.

Possibly a protocol like the following could work, however:

  * Operator claims block X with work W had the relevant tx
  * Watchtower observes block Y with work W+A does not include X in its history,
    waits until Y has 6 confirmations, and publishes Y's block hash and W+A
  * Challenger:
     - observes block Y, generates their own Groth16 proof that X is
       not in Y's ancestor set, and verifies this via BitVM, penalising
       the operator
     - observes block Z with work W+2*A with X in its ancestry but not
       Y, generates their own Groth16 proof for that, verifies this via
       BitVM, penalising the watchtower
     - observes block Z with work W+2*A with neither X nor Y in its
       ancestry, generates their own Groth16 proof for that, verifies
       this via BitVM, penalising the watchtower

This process is only triggered if either the Operator or Watchtower is
dishonest, and in that case it's likely the full BitVM protocol will
also be triggered, so the potential for a ~100 byte saving is probably
just lost in the noise.



However the point of all this is just to find a way of ensuring that the Operator
publishes a block hash that's actually in the block chain. But knowing what block
hashes are in the block chain is something bitcoind is already pretty good at,
so we could do that pretty differently. eg, Consider the hex string

  50 01 24 030c3500 00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054

A string like that could be interpreted as:

  * this is an annex entry
  * of type 1, "per-input height lock"
  * data length 36 bytes
  * 3-byte int, value 800,000
  * 32-byte hash, the block hash of block 800,000

And a consensus rule could be added that the presence of a type 1 annex
entry means a transaction is invalid unless the given block height
has been reached, and the hash of the block at that height (ends with)
the provided bytes.

That would ensure that the Operator's transaction does provide a real block
hash, which I believe is all that the Groth16 proof in question achieves.

I think that's probably sufficient for this use case -- you'd pull the
Operator's tx from the blockchain, then provide it to a BitVM program,
which would verify the witness was signed by the Operator, that the annex
data is of the appropriate length, and then go on to use the block hash
for further computation, presumably establishing some transaction is
included in the block by evaluating a merkle path. So that would remove
both the need to include the 144B groth16 proof, but would also avoid
an entire BitVM evaluation.

Having an annex entry acting as a per-input height lock seems somewhat
useful in general, and might, eg, allow multiple lightning payments to be
timed out in a single transaction, which might be nice. Being able to
commit to the block hash of your height lock is potentially useful when
dealing with controversial soft forks, hard forks, chain splits, or large
reorgs; as you can use the commitment to make a spend only valid on one
chain or the other yourself, rather than needing to try a double spend
race against yourself or collaborate with a miner to mix a new coinbase
output with your coins.

I think doing that via structuring the annex should be pretty feasible,
as a small number of unconditional contextual assertions from a well known
location in the traction should be easy to extract and operate on, in
the same way we treat tx's nVersion, nSequence and nLockTime time today.
In particular that sort of assertion can be validated independently of
executing scripts, which should make working out if a tx can remain in
the mempool after a reorg more straightforward.

Embedding it via an opcode in script seems somewhat more dangerous in two
ways -- you don't know which block hashes a script might reference until
you run the script (so have to give the script interpreter access to all
the blocks), and to cater for reorgs will need to track the most recent
block hash a script references and store that in the tx's mempool entry.
Those aren't impossible to deal with, but it seems better to me to have
keep the information that scripts can use as computation inputs very
local to the transaction being processed.

References:
 - https://citrea.xyz/clementine_whitepaper.pdf
 - https://x.com/0x_orkun/status/1918009290326950147
 - https://gnusha.org/pi/bitcoindev/20220305055924.GB5308@erisian.com.au/

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/aCH8AdZeBAc0UVfT%40erisian.com.au.
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` (7 preceding siblings ...)
  2025-05-12 13:47 ` [bitcoindev] " Anthony Towns

  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-05-14 15:54 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

Hi,

This proposal was heavily mediatized, and severe mischaracterizations of the change being proposed led to genuine concerns among the community. A better communication from my part could have avoided unnecessary worries among bitcoiners and a lot of wasted time to everybody.

In an attempt to right this wrong, i have collected objections community members have raised across the board (on Github, the Bitcoin development mailing list, X, podcasts, at conferences, ..) to address them in a single post.

I just posted to Delving Bitcoin addressing all concerns and objections i could get my hands on: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697. These are actual objections and concerns raised by community members, taken literally with little or no reformulation to address the precise statement.

Antoine Poinsot
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <darosior@protonmail•com> 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/qps_M7VTLROH7U1v1n_5snfjf-H-Gl-BX-V9qc1JSzzyqfsRoPrbaCzQAQFa1pU4w0cfXZHVnUta6Z7UryG1hUhtpcGXw1ZHiHOfl3HR2jo%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 5513 bytes --]

 permalink raw reply	[|nested]