I was describing a principle here, but as you know, we are choosing Knots as an alternative.

GM, It's 639am UK time, and I didn't sleep much last night. I got up to write this, then I'm going back to bed, I still won't sleep much. First of all, thank you Will, for all you do, both on Core and on NOSTR. I don't do much myself, but I have done my fair share to change the world in my life. I am mostly a passenger now, but I promise I have earned my position at the top table for oversight of the world as it changes. Once again, I deeply respect and admire you and everything you do. My understanding of your statement is you can do this anyway via another method, so what’s the problem allowing this to happen via OP_RETURN. This is bad, please allow me to set out my stall. I don’t want to store cat JPEGs or inscribed love letters on my nodes. Bitcoin is a financial transaction system, that is all. I appreciate it has always been possible to inscribe data on the blockchain from the genesis blocks “Banks on Brink of second collapse” to Len Sassaman’s ASCII art image. But taproot, in an effort to optimise storage and move closer towards a Turing complete engine by creating and combining scripts within Merkle trees, gave an unintended consequence. Cat JPEGs stored natively on the blockchain. This exists, we can’t stop it, many parties, including miners and NFT artists want this. I don’t. Let Ethereum have the monopoly on cat JPEGs, I’m not looking to compete with Ethereum. That is my 3 - 5 votes out of 20,000+ active nodes at any time. So, we are here, we have cat JPEGs and we have love poems stored on the blockchain, so allowing love poems in the OP_RETURN doesn’t matter because we can do this anyway. I disagree. For me we need to be making it harder to store cat JPEGs and love poems, not easier and continue to do this granularly until it is eliminated. That is the direction I want to head in. So my question is, what can’t we do with the blockchain that we would be able to do with an unrestricted OP_RETURN. If you don’t know the answer, that’s fine, just because you’re a core developer doesn’t give you the ability to read somebody else’s mind. The other argument I’ve seen from Lopp is that he has a lot of Bitcoin and not much shareholding in Citrea, the company pushing for this change. Why would he damage his Bitcoin for such a small company. This argument also, doesn’t hold water. Nobody expected Taproot would allow anybody to store cat JPEGs, the unintended consequences of change is always there. I am in no way a developer, but I did code back in the 1980’s to early 90’s. I built, ran and maintained a Hungarian mainframe called a VT6000 based on Bull Mitre architecture for our global public electronics company, “Densitron”, which my father founded and still exists today inside one of my other companies. The machine ran MMT2 O/S and COBOL compiler. I was one of two people extending the functionality of a global accounting, stock control and ordering system called RelAcs (Real Time Accounting System). My colleague, a Hungarian called Charlie Lugosi was highly skilled, way beyond my limited abilities. We both broke the system in every conceivable way countless times trying to improve or maintain either the machines micro-code, the OS or the applications.The machine had 2 x 300MB CDC disks, 1MB RAM and a 2MB cache. It supported up to 16 dumb terminals. By comparison, modern code like Bitcoin is unimaginably more complex, but the principles still apply. You never fully understand the consequences of a change until it is in production and being used in the real world. Jameson Lopp would absolutely break Bitcoin if it benefitted him, somebody broke Bitcoin to allow cat JPEGs, probably unintentionally. Somebody let a virus out of a lab in China, probably unintentionally. Unless there is a very good reason to reduce the restriction on OP_RETURN size, then we don’t do it, because nobody knows what the consequences of this is, and Bitcoin core developers have no special insights that non core devs don’t. And Bitcoin code, by nature is very conservative. Which is why Taproot caused more problems than it fixed. As a core developer, if you are now involving yourself directly. If you don’t know “why” we want to remove the OP_RETURN limit, you should be finding out, not discussing “well it’s broken anyway, what harm can it do” with idiots like me. I am a voter and a customer and a user of your Core software, I can vote with my node and give my "free" business to other Bitcoin suppliers like Knots. I and my colleagues are who you are working for, albeit selflessly and unpaid. I am the one you are your core colleagues are accountable to. If you are fully open and honest with us, you have our respect, support and admiration, if you treat us like we don't matter, we all leave and you are left in an empty ivory tower.