Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions

From: Luke Dashjr <[email-masked]>
Date: Sat, 26 Apr 2025 07:35:44 -0400

On 4/26/25 06:53, Sjors Provoost wrote:
>
> Op 26 apr 2025, om 11:50 heeft Luke Dashjr <[email-masked]> 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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/d18b4149-5523-44bd-8332-2b7962f4b674%40dashjr.org.