You don't have to download, store, or otherwise process some data, if you don't want to. You can process it once, and then forget about it, and only keep some lightweight proofs on your side. Or: if your security model allows for that, you can just download the proof from another node, and don't bother with downloading the original data at all.
I agree that a different IBD/storage solution would be the probably part of the solution. But the problem remains: How does a full node distinguish a "fake" public key from a "real" public key?
AFAIK SwiftSync (I have only read the OP of the SwiftSync mailing list discussion and the Delving Bitcoin OP, so I may be wrong) only checks for already spent UTXOs, so it would never see anything in the "fake public keys" which they could ignore. Instead, the more fake public keys exist, the less efficient SwiftSync would be.
Relevant quote from Delving Bitcoin:
The idea is to only ever add coins to the UTXO set if we know that they will still be unspent at a certain block height N.
Source:
https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562I'm just intrigued that, even though there is obvious exploitation and a known fix for one of the ways the network can be is spammed, [...]
Exactly, there's a fix for
one of the ways. But this way is not the most harmful one. Highly likely that if Ordinals got "closed" by such a filter like the one in Knots, the NFT crowd would switch to Stampchain, and then we would have a "real" spam problem.
So what's the point of "fixing" a script with a quite questionable method (a heuristic filter which only matches an exact combination of opcodes) if then the problem could get even worse, even if spam halves (measured in kB/block) as a consequence of the "switch" to Stampchain, 50% of the spam on Stampchain-like "fake public keys" would be probably still more resource-demanding to full nodes in the long run (and worse -- it increases with time!) than the current Ordinals data volume.
Your conclusion about Bitcoin consensus thus is simply wrong. Over & Out ;P
I'm not tech savvy enough to make an opinion on the changes to OP_RETURN, but I do see a problem with the way these changes are being approached. Peter Todd's pull request was revived precisely after Citrea's whitepaper release which indicates a need for at least 144 bytes on OP_RETURN.
Citrea was indeed what started the discussion in the developer mailing list. Just because their "workaround" around the OP_RETURN limit is currently spamming the UTXO set with "fake public keys" in their transactions (although on a very small scale compared to
Ordinals
Stampchain). The idea was to nudge them to use OP_RETURN instead (removing the limits), which would be less resource-hungry for full nodes.
That's the whole "Citrea issue". Building a "Core corruption story" around that is quite lame, I think.
And thus I'm very disappointed from those developers who are now fueling this anti-Core shitstorm. Because they should know better.