From: Luke Dashjr <luke@dashjr•org>
To: Sjors Provoost <sjors@sprovoost•nl>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Sat, 26 Apr 2025 07:35:44 -0400 [thread overview]
Message-ID: <d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org> (raw)
In-Reply-To: <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl>
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.
next prev parent reply other threads:[~2025-04-26 11:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr [this message]
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox