I think it's great to disagree with Core. It's unfortunate that they chose to pursue this change because it doesn't seem to be necessary at all and it has caused a lot of chaos within the community, which was frankly the last thing we needed. Nevertheless, Bitcoin is made to survive adversity and it's up to node runners to guarantee its success in the long term.

As for Citrea, I'm not excusing them or anything. I think development on Bitcoin should be permissionless, so let them try build new stuff. They can turn Bitcoin into Ethereum only if the vast majority of users actually think that's valuable and start bridging their sats to their L2. I have no reason to believe this is going to happen.

The other unfortunate thing is that Citrea has developed its protocol in such a way as to require more than 80 bytes of arbitrary data, meaning they are going to publish it on the witness instead of as an OP_RETURN output. Had they been less careless with their technical choices, we would probably not be here. Hence my use of the term "unfortunate".

Reply to this note

Please Login to reply.

Discussion

And here is the key.

Core ALLOWED the spam that currently abuses Bitcoin by not fixing it with Luke's PR. So Citrea abusing Bitcoin is direct effect of malicious Core devs actions.

"The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining. Since the end of 2022, however, attackers have found a way to bypass this limit by obfuscating their spam inside OP_FALSE OP_IF patterns instead of using the standardized OP_RETURN. This remains under active exploitation to a degree very harmful to Bitcoin even today.

A straightforward way to address this is to simply fix the bug (#28408), but that was (inappropriately) closed due to social attacks."

https://github.com/bitcoin/bitcoin/pull/28408

https://github.com/bitcoin/bitcoin/issues/29187

nostr:nevent1qqsdk7fgvx6jdt5ss2sqa0wqxdu3v925m9ge5kwhxmca3nw4gtr3eqcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj77uzl0g

I'm familiar with these points. I am not sure that fixing the current instantiation of inscriptions via OP_FALSE OP_IF checks would be enough though. There are ways ways to embed arbitrary data and it seems to be the only option to remove the possibility entirely is to only allow a set of well known transaction types, much more restrictive than what Core currently categorizes as "standard".

They are already fixed in Bitcoin Knots. And Knots is working fine.

All legitimate transactions and use cases can be tested but as for monetary transactions that transfer value, its all fine.

Restrictions is when someone takes away your options - deprecations first, removal second.

One thing to notice is that Bitcoin Knots gives you the FREEDOM to put whatever value in OP_RETURN you like. Think about that too.