From: Sjors Provoost <sjors@sprovoost•nl>
To: bitcoindev@googlegroups.com
Cc: Luke Dashjr <luke@dashjr•org>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Sat, 26 Apr 2025 12:53:18 +0200 [thread overview]
Message-ID: <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl> (raw)
In-Reply-To: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org>
[-- 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 --]
next prev parent reply other threads:[~2025-04-26 10:57 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 [this message]
2025-04-26 11:35 ` Luke Dashjr
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=CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--cc=luke@dashjr$(echo .)org \
/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