Hi Jason, > OP_RETURN was only made standard in a limited size to encourage less harmful > data carrying in Bitcoin.
That's correct. > and this was known to developers at that time. Sadly, eventually an exploit > called 'inscriptions' happened which blew the cap off of the size limitation > of arbitrary data storage... and to make matters worse, developers refused to > patch the exploit or otherwise enforce the decade old limit on arbitrary data > size. If you look at the actual pull requests that implement such patches you'll discover the various reasons why they were rejected. This mailinglist thread has also re-iterated the futility of this cat-and-mouse game. It contains the relevant links, so I'm not going to repeat them here. > If that wasn't bad enough, exploiters get a 75% discount on transaction fees. At the time SegWit was proposed it was clear that the worst case block size would increase to 4 MB. It took a few years for people to figure out how to take advantage of that. Somewhere between 2015 and early 2017 would have been good time to object to the SegWit discount, but removing it now would be a hard fork. Fwiw I think the discount was a good idea. > What's the point of having a "standard" way to store arbitrary data if the > exploit method is 4x cheaper? And the nonstandard version of the exploit > allows 4x the data? What you call "nonstandard" is actually standard. Inscriptions follow standardness rules. In general you're reasoning the wrong around imo. There is no point in restricting transactions that are 4x more expensive than the alternative. And as was explained earlier in this thread by me and others, if we don't drop this limit then the UTXO set will get bloated. Just as you point out was the historical issue. Bitcoin Core used to have a whitelist model where only a few transaction blessed by Satoshi were standard. I think it's good that we moved away from that to where you typically don't have to lobby for your transaction type to be included. But others disagree, e.g. Luke Dashr in this thread proposed going back to that model. > Further, the inscriptions exploit currently requires chunking the data > between PUSH opcodes The issue of consecutive byte sequences stored on disk is intestering. But imo it has been fully addressed on the Github PR now: https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2838068278 In summary: 1. The mempool is encrypted at rest 2. The blockchain is encrypted at rest for (relatively) new users, but not for everyone. However, it is already trivial to inject arbitrary data into the blockchain. This change does not make the problem worse. > That may sound like hyperbole, but it really isn't. It's irrelevant because this PR does not change the threats you are worried about. > Today, too many developers don't understand this duty. If you don't have confidence in the Bitcoin Core developers, instead of insulting them, you could also just (help) maintain a fork of the project. Working on Knots seems the easiest way to do that. I obviously think you're misguided here, but at least it's better to channel this distrust into something constructive. Given the number of people who share your sentiment, such a project should be perfectly viable. - Sjors -- 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/4DAF69CE-2AA6-4429-9F3C-91030C88A88B%40sprovoost.nl.
