On 4/26/25 06:53, Sjors Provoost wrote:
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?
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 protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/d18b4149-5523-44bd-8332-2b7962f4b674%40dashjr.org.
