I only saw your original note because I enjoy your content, and I assume a lot of other people will read the note and dismiss this controversy as pointless or that the Knots people are naive or crazy. I’m not trying to annoy you. I would like you and the people who follow you to understand this issue deeply enough to realize that the Knots folks are not as crazy as they seem. And even though Knots may not be a silver bullet, we all need to pay attention to this issue and take a stand against the unintended (and unnecessary) consequences from v30 that can damage Bitcoin.

One case in point: Core v30 benefits venture capitalists who want an “approved” way for their startups to store large amounts of arbitrary data on the blockchain so they don’t invest in a fragile business model that might get filtered out of existence if both nodes and miners choose not to accept their arbitrary data.

For example, Citrea, and their Clementine bridge which needs to store 144 bytes, so intends to span OP_RETURN and UTXOs to achieve that. Jameson Lopp’s arguments on this topic cannot be taken as unbiased because he invested in Citrea.

Antoine knows Citrea’s going to spam the network and could have adopted Adam Back’s suggestion of increasing the OP_RETURN datacarriersize default to 160 bytes (for now - revisit in the future if necessary) so Citrea wouldn’t need to spam the unpruneable UTXO set. Instead, Antoine opted for the much higher risk approach of removing the limit to accommodate ALL future use cases of arbitrary data in the blockchain without the risk of failing to make the case to the Core dev community next time. This controversial OP_RETURN change was proposed at least three times since 2023, and Core rejected it the first two times. It was pushed through in v30 despite disagreement within the Core dev mailing list and GitHub discussions.

Rhetorical question: If “filters don’t work” then why does the Clementine whitepaper proposal store 80 bytes in OP_RETURN and the rest in UTXOs? Surely they could have put it all in OP_RETURN and broadcast the transaction via Libre relays or directly to Marathon via slipstream?

My view is that we should very cautiously increase OP_RETURN and other defaults as use-cases that strengthen the core value proposition of Bitcoin come along. The OP_RETURN changes in v30 that remove the size limit are both reckless and unnecessary.

https://citrea.xyz/clementine_whitepaper.pdf?ref=blog.citrea.xyz

https://www.prnewswire.com/apac/news-releases/citrea-raises-14m-to-expand-bitcoin-beyond-digital-gold-302289029.html

https://citrea.xyz/

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