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.

Reply to this note

Please Login to reply.

Discussion

🎯👏👏👏

GM,

As a nobody with no say and having contributed nothing, I'm self certifying this is important please read:

nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7ct4w35zumn0wd68yvfwvdhk6tcqyp60l3gucvq4pnmekm9nzmf6zh8nx24jngu0aj0tfp9tz4gad5v9v94ulq2 nostr:nprofile1qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz8thwden5te0dehhxarj9e3xjarrda5kuetj9eek7cmfv9kz7qpq7u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrquyd27a nostr:nprofile1qyt8wumn8ghj7ct5d3shxtnwdaehgu3wd3skueqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqqgxv4fvwxlyeepdute65q298rz75vjz7t57txdzkj8k2hq782h2ges3dvnqp

nostr:nevent1qvzqqqqqqypzp6pmv65w6tfhcp73404xuxcqpg24f8rf2z86f3v824td22c9ymptqyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyp7axf5lgvgckfg6dwm022ch7f5p703ek7ewhqc526zdfk3zwdthvykmv9h

This is a respectful response in an interesting conversation. Nostr is the place for this!

nevent1qqs8m5exnap3rze9rf4mdaftzlexs8e78xmm96urz3tgf4x6yfe4waslrrh4u

GM☕️☕️🌅💜😱Man this is very impressive reply to the current kerfuffle! I am a nobody, no coder, bitcoin monetary maximalist. Any changes to core should be made to improve this one function which underlies any other protocol function.🫡

Thank you

I see both sides here.

Taproot had unintended consequences — one of which is Nostr. Nostr identity is based on the Taproot BIP, and it's given Bitcoin the beginnings of a social layer.

There’s a difference between maintenance and renovation.

You maintain a school by mopping the floors; you renovate it by adding a new door to a corridor.

In any system or standard, there’s always a grey area between minor maintenance changes and behaviour-altering changes.

At the W3C, we have something called “class 2” changes — used for typos, improved examples, and other edits that don’t affect behaviour. They follow a lightweight process. Larger changes are “class 3” and go through wider review.

It’s common to see people try to pass class 3 changes off as class 2 — but the rule is: if there’s disagreement, it’s not class 2. (Of course, who defines disagreement is a whole other problem.)

Bitcoin might benefit from a similar distinction: separating maintenance from behavioural changes, and handling them with different levels of review and process. Discussion is always good in these situations.

Thank you for your insight.

For me there is one “core” question.

Why do we need to de-restrict the OP_RETURN field?

Is there any benefit?

Do you have any insight into this question?

Hi Mike,

You are asking the wrong question. Why do we need to restrict the op_return field?

Restricting it is not preventing anyone from using large op_returns.

Also, you are not a customer of core and running 3 nodes doesn't give you any votes.

If you want to run knots, go ahead. The disadvantage will only be yours because you won't get accurate fee predictions and you just be a part of a silo'd sub-network of the Bitcoin network with limited knowledge of the rest of the network.

Nobody needs to convince you because your nodes don't matter to anyone but you, especially if they won't relay valid transactions.

Nodes don't matter!

Are you a BCH or BSV guy? 😂

Some nodes matter. Economic nodes and miner nodes.

Other nodes are only good for the node runner's privacy and for relaying transactions. Since your node won't do the latter, it is useless to everyone else.

Ah BSV 👍

How’s Craig doing these days?

Also I presume you started out with BCH, give Roger my regards when you next see him.

I’ve just bought a house on St. Kitts, I’m sure he misses the old place 😂

I'm not involved in any of that. BTC only since 2017.

If you think I'm wrong, just explain why you think so, instead of ad hominem.

No, my predecessors did that between 2015 - 2017.

Fine, I'll fuck off, then.

The right question is always "why make a change?" When Bitcoin code starts changing because "why not?," things can go south quickly.

I don't see the argument against larger op returns because nobody will track down small miners / pools to have their custom block mined being particularly strong as this is what happens already. Centralization in that regard is the current status quo, whoever wants crazy blocks mined can do it with our without opreturns changes.

I could turn the argument around saying that larger op returns would make those custom blocks unnecessary because the goal to host data on the blockchain can be achieved now without such manipulation.

But then again, as stated by gmaxwell, there are interest groups who just like to have a block for themselves printing MARA in the mempool.space thumbnail and whatnot and they will AND CAN do it no matter the op return field.

How does a larger op return field change that in any way?

Im very happy these discussions are happening on nostr.

I tend to agree with nostr:nprofile1qqswswmx4rkj6d7q05dtafhpkqq2z42fc62s37jvtp642m2jkpfxc2cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3wamnwvaz7tmwdae8g6tn9ehx7um5wgcjucm0d5q3wamnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5nrafuh.

We don't know what people will do with this added freedom. If they abuse it in some other new way, would we just regularise that too?

What is the most sustainable direction here? That is usually what defines my principle.

Thank you all. nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzdmhxw309aex2mrp0yhx5c34x5hxxmmdqyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnvv9hxgpywa92 too.

nostr:nevent1qqs8m5exnap3rze9rf4mdaftzlexs8e78xmm96urz3tgf4x6yfe4waspzdmhxue69uhhwmm59e6hg7r09ehkuef0qgswswmx4rkj6d7q05dtafhpkqq2z42fc62s37jvtp642m2jkpfxc2crqsqqqqqpm5r25f

nostr:nevent1qqs8dgv2y5mezcrxs3fh0ujgfcfp3tq7jl8vq6jrjr5syyw5dtxqwxgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyr7fapjge95ustzly50ttxh3fucgn40dpaee9htmt5ke498wtjwt6qcyqqqqqqgyk76fh

#nostr #Bitcoin

GM good read

Good morning 🌞🫂

GM 🫂

“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.”

🎯

CULTURAL ISSUE, NOT TECHNICAL.

And the Core people don’t care.

nevent1qqs8m5exnap3rze9rf4mdaftzlexs8e78xmm96urz3tgf4x6yfe4waslrrh4u

Why make out they want this for cat JPEGs. It's about contracts for bridges right?

What option is going to limit the ability to have permissionless money the most?

If bridges need to contact miners directly, then only bridges that are in the interest of the majority of mining power get in. Other things, like privacy chains that are banned by the state will be rejected out of fear of prosecution.

Cat JPEGs are already there with a segwit witness discount. They don't need this to bloat the chain and put pressure on decentralisation of node running.

As the OP points out, currently large miners are being contacted directly to include these transactions, this works against mining decentralisation.

By all means think through the consequences, but be honest when weighing up the positives and negatives.

The current state of play limits bridges to white listed entities and mining centralisation. Appealing to the boogie man what if and cat JPEGs is not a strong argument.

Thank you for this contribution.

Sadly, I don't understand anything your saying and you seem to be agreeing with my point while telling me I'm wrong.

Forget the cat JPEGs, we do want to stop these, but we are agreed that OP_RETURN makes no difference to this.

Why does Core want to eliminate the OP_RETURN limit (libre relay already has) and what are bridges and what have bridges got to do with this.

I would appreciate understanding this if you are able to explain and have the time.

The utxoset size is *permanent* it can’t be pruned like other block data unless you consolidate the spend into a smaller set of utxos

basically think of them as a coin purse where if you put two coins in, the only way to shrink the bag is to spend to coins with no change.

JPEGs in witness data means that they will likely be unspendable, meaning that there is a permanent storage increase requirement on all nodes. But they are no provably unspendable so you can’t discard them from the coin purse. This is really bad.

OP_RETURNs are *provably* unspendable, meaning they can be ignored from the utxoset perspective (never goes in the coin purse)

By trying to stop both witness jpegs and large OP_RETURN pushes, it will push people to do even worse things like large multisigs that stores data in the signatures. This is how the whitepaper is permanently stored in the utxoset. This is even worse for utxo bloat.

At this point the censor proponents would say well thats not economically viable… but none of these methods really is. Some are cheaper than others, sure, but overall it’s still the most expensive data storage out there. People have to burn the hardest money on the planet if they want to play stupid games.

The point is people are going to store data anyway, the *least bad* is OP_RETURN, because it minimizes the *permanent* storage burden on pruned nodes.

Thank you for this explanation. I think there is a lot of misunderstanding around this PR and it seems many are fearful of the change.

What stops them from doing both?

What stops them today is this default. What stops them after is desire and incentives and sunk costs. The more apps that build around this, the worse it is to get them to fix it.

Which way, Western man? Lolbertarians would prefer to allow degens to poop in the park bc "muh cOnsTiTooshun" and "muh hUmAn rights". We live in a society (for now)

No, libertarians who don't operate in cartoon would advocate that park shitting be regulated by something other than a centralized authority funded by theft, with a monopoly on force, using arbitrary and observability ineffective measures for doing so. (At the exclusion of other innovative solutions.)

It's not economically viable in a one dimensional profit narrative. But these keynesians always fail to recognize dynamic system complexity, human action, irrational actors, bad faith actors. It only takes one buyer to make a sale.

Thanks for this explanation. That is very helpful for a newb

I understand that OP_RETURN is a garbage dump, but the question is whether to remove the "limitation" of OP_RETURN, and are you saying that we should give up on full nodes like Ethereum and use pruned nodes instead?

Surely, I also think that if the network can be resilient from a pruned node that is left *only one* in the world, that would be one direction of "evolution". And that might be already possible if we gave up on past history and continued only with future payments.

This is wrong. Witness data is not stored in the UTXO set. Witness data is revealed when spending a UTXO, removing it from the UTXO set. Witness data is only in blocks and can be pruned.

oh yeah I didn't mean to imply the witness data itself is stored in the utxo set, but utxos are created

This OP_RETURN change has nothing to do with JPEGs. It is 4x cheaper to store JPEGs in the witness data, and the witness data is *not* stored in the UTXO set.

This change is for protocols that need some small amount of data but bigger than 40 bytes to be in an output before being spent. Witness data is not suitable for this because the tx has to be spent to reveal the data.

the jpegs were just an example, I'm not saying people would be using jpegs in OP_RETURN instead

I wish Rodarmor was active on nostr instead of being a little bitch about it, but the way I understand it is the witness data doesn't actually add to the utxo set and you'd likely consolidate your ordinals just like your regular bitcoin, but BRC-20s broke this by exploding the utxoset. This was why runes were made and use OP_RETURN. A larger OP_RETURN would be good for more use cases like this, but jpegs would likely still be in the witness data because of the discount.

Totalmene de acuerdo.

On the one hand, relaxing policy to incentivize usage that does not bloat the utxoset sounds reasonable. Yet, it would still be cheaper to store data in the witness? And isn’t the present situation a natural experiment showing that filters do have an impact? Finally, how does this help deal with actors like Mike in Space, who has publicly stated that he designed his shitcoin-on-bircoin protocol to bloat the utxoset?

Entao desceram os amalequitas e os cananeus, que habitavam na montanha, e os feriram, derrotando-os ate Horma.

#Entao #desceram #os #amalequitas #e #os #cananeus, #que #habitavam #na #montanha, #e #os #feriram, #derrotando-os #ate #Horma.

Luego descendieron a los amalequitas y a los cananeos, que habitaban la montaa, y los hirieron, derrotndolos a Horma.

#Luego #descendieron #a #los #amalequitas #y #a #los #cananeos, #que #habitaban #la #montaa, #y #los #hirieron, #derrotndolos #a #Horma.

Ensuite, ils sont descendus les Amalequites et les Cananens, qui habitaient la montagne, et les ont blesss, les battant Horma.

#Ensuite, #ils #sont #descendus #les #Amalequites #et #les #Cananens, #qui #habitaient #la #montagne, #et #les #ont #blesss, #les #battant # #Horma.

Quindi scendettero gli Amalequiti e i Cananei, che abitavano la montagna e li ferirono, sconfiggendoli con Horma.

#Quindi #scendettero #gli #Amalequiti #e #i #Cananei, #che #abitavano #la #montagna #e #li #ferirono, #sconfiggendoli #con #Horma.

Then they descended the Amalequites and the Canaanites, who inhabited the mountain, and wounded them, defeating them to Horma.

#Then #they #descended #the #Amalequites #and #the #Canaanites, #who #inhabited #the #mountain, #and #wounded #them, #defeating #them #to #Horma.

Dann stiegen sie die Amalquiten und die Kanaaniter ab, die den Berg bewohnten, und verwundeten sie und besiegten sie zu Horma.

#Dann #stiegen #sie #die #Amalquiten #und #die #Kanaaniter #ab, #die #den #Berg #bewohnten, #und #verwundeten #sie #und #besiegten #sie #zu #Horma.

Kisha wakashuka Waamalequites na Wakanaani, ambao walikaa mlima, na kuwajeruhi, wakawashinda kwa Horma.

#Kisha #wakashuka #Waamalequites #na #Wakanaani, #ambao #walikaa #mlima, #na #kuwajeruhi, #wakawashinda #kwa #Horma.

Kemudian mereka turun ke Amalequites dan orang Kanaan, yang mendiami gunung, dan melukai mereka, mengalahkan mereka untuk Horma.

#Kemudian #mereka #turun #ke #Amalequites #dan #orang #Kanaan, #yang #mendiami #gunung, #dan #melukai #mereka, #mengalahkan #mereka #untuk #Horma.