Op 26 apr 2025, om 11:50 heeft Luke Dashjr <[email protected]> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl.
