What is your view on the OP_RETURN debate?

Ah yes, Bitcoin ethos. Trust the experts! Obey authority!

yes, i don’t want retards maintaining my money. I definitely want experts who have been thinking adversarially in this space longer than me.

That's exactly the thought process that got us to our current financial system.

Your exact thought process lead to bitcoin cash, and how did that go?

I'm not the cash guy here. You support Core's move towards removing OP_RETURN or not? Do I get to decide what goes into my mempool on my node or does Core get to decide that?

noone is removing OP_RETURN? what?

Did I misunderstand your original post? Are you for or against Core's potential move to remove the limit on OP_RETURN?

the code that checks the limit is ineffective, inscriptions got around it via the witness trick. anytime it is tweaked it can be worked around, usually at the the cost of UTXO bloat. I used to be in favor of it but I have since been convinced by core devs otherwise.

this is an outright LIE. the approx 500kb limit made it 500x harder to spam and it WORKED. it is also a deflection. the argument is not technical and people who keep ignoring the primary philosophical issue by obscuring it with this anal technical bullshit are HIGHLY suspect. you are either for people having the choice or you are to be treated like a fucking agent tyrant enemy of #bitcoin #gfy

simply not true, how did inscriptions work then? how did they get around the limits and put jpgs in?

I just have to say that the exception doesn't make the rule. Do you think it's stopping nothing at all right now?

since there are ways around it, and OP_RETURNs don't add any utxo bloat, and the person making the transaction has to pay a fee... i think that storing data this way is unsustainable, so its really a non-issue. in reality this whole debate is node operators thinking they have control of something that economics will sort out by itself. the setting has basically no effect, as most node running use default settings... so whats the point again? deluding yourself and making yourself feel good that you are doing your part to save bitcoin from people putting stupid shit in transactions when in reality you have no real control over this? great. yawn.

"Yo, I feel ya on that! 🤔 But if node operators ain't really in control and it's all just an econ game, what’s the real play here? Is it just about flexing on what we can or can’t store? #BitcoinDebate #KeepItReal"

maybe you don’t know as much as you think you do about Bitcoin Core. sipa is not a maintainer, stepped down three years ago.

bro implemented libsecp256k1, segwit, taproot, miniscript, and is working on cluster mempool algorithms as we speak?

I'm learning as I go. I just don't like the appeal to authority and experts that you did in your original post. I'll look into the negatives on having a limit on OP_RETURN and how it bloats UTXO as usually the argument is just "it doesn't work anyways" which is a stupid argument because then why change it. I cant help but think back to the Block Size War example where the miners thought they were the ones in control. Turns out that wasn't the case. I guess it's time we find out if Core devs are the ones in control.

I know. He is the best and I wish he was a maintainer. But he is not.

Let’s not have moot side arguments trying to prove how much we know. For me, as a node runner, you have to convince me to run your code. If one side is open and the other side is closed, I only hear one side and my choice is forced. This, for me at least, is the “core” of the argument.

wat? git author-stats --no-merges v26.0..v29.0 | tac | head | cat -n https://cdn.jb55.com/s/036ba96eba44ce7d.txt

What is the alternative?

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

I think he's splitting hairs over maintainer vs contributor

Did you perhaps mean to say “contributors” instead of “maintainers?” Because that is what you are posting.

Damn, i didnt click link first and for some reason sipa and peter wuille didnt link in my brain. Yea hes listed right there

I like luke for his contrarian nature but the idea of him in charge of the future of bitcoin is bit much. He is the defacto leader of knots and noone could really appose him.

That’s not really the point I’m making. As I said if I only hear one voice, I’ll listen to it. If that voice goes uncontested, I follow it. I always want to hear both sides. I’m not hearing both sides. I’m a node runner, core needs to convince me there is a valid counter argument, otherwise I am forced to make ill informed decisions.

what's the difference? he's is just a guy who ships code. unless you're talking about people who only merge code, I don't think sipa was ever a maintainer in that sense.

we'll you're hearing my side. I am a bitcoin core contributor. there aren't many of us. we are outnumbered millions to a couple dozen at most ? you will naturally mostly hear the crowd when we are this outnumbered. I think there is a valid counter argument: I have yet to see anyone point out why the setting matters when you can get around it via witness data (like how inscriptions abused the network) unrestricted OP_RETURN is strictly better since those are provably unspendable, meaning you don't need to permanently bloat the utxo set. if people are going to do it anyway and you can't stop it without a hardfork, then removing the restriction so people don't do dumber things that hurt the network even more is better is it not?

Pass friend, thank you for starting to state a counter argument. I will listen fully, but I don’t fully understand what you’re saying. I’m not sure what you mean by “I have yet to see anyone point out why the setting matters” It’s late in the UK, I’m going to bed, but both you and Jameson have started to state a counter argument, so I will listen. Thank you.

It only matters in the sense that you were using sipa to support the claim that “there is simply no other group of people that outmatch the current set of maintainers.” Factual errors do not help your overall case, which I want to believe is correct but now don’t hold with much conviction.

ok I use maintainers and contributors interchangeably, my bad

Yeah, as stayed after core sat on their hands in 2023 when all this started. The proposal that was 'contentious' was to address the spam with a spam filter. Their like lala I'm not listening. And then: Since we can't filter 100% of spam, our only action is to just lower the drawbridge and let it all in. It's fine because now they aren't trying to climb the castle walls anymore. And I expected the response to that be more: lala we can't stop all spam. Can you even refute Bitcoin Mechanics central point? Like, rewind back to 2023 when the problem started.

the only delusion round here is that manifest in the people amenable to this proposal... which are the absolutely arrogant types who fancy they can play all scenarios out. what you dont get is that YOU CANT GAME IT ALL OUT... and you dont know your adversary's depth, breadth, or level of luciferian genius he is seeking to destroy you with. you are a frog, boiling.

are you going to make a technical argument or just an alex jones-like tirade?

i don’t know his central point, is it written somewhere?

"alex jones style tirade" - ok elizabeth warren you fucking establishment cunt wtf no. the "technical" argument is the fucking scam and the distraction. the reality is that core devs are the enemy - ALWAYS HAVE BEEN. node operators demand the choice you fucking commie central planner

LOL

yeah keep it up with the shallow nervous laughter... one day your woft palmed ass will face the fucking abyss

why u so mad. you can literally run any version of the code you want

i dunno maybe i was borne before the estrogen maxxed + tranny gen... its irritating because this post '17 crop are either so trusting and naive about the war you are in and the nature of the enemy you are up against that its hopeless, or in on it. either way its fucking gay and you need to grow some fangs.

i dunno man maybe i just can’t imagine getting this worked up over a mempool relay setting.

well there seems to be a discrepancy between yourself and many others: you: its just a mempool relay setting OGs: its an outright attack - they are banning people who raise legitimate concerns and then banning those who suggest that that may not be a good reason to ban... and strawmanning it as a "technical" issue... so.... something has to give.

I guess I’m too stupid to understand why people would be upset about this

I mean, there is probably a transcription in the video, but my understanding is that spam filters do work sufficiently (without a hardfork) if core would accept the pull request of the spam filter. It doesn't catch everything, but it creates an environment where only the most sophisticated spammers can get through. The fact that this option is being ignored, and then stating because we can't stop it we must do x, is an attack on bitcoin. It's a form of gas lighting by disregarding solutions that address the spam directly. He addresses what I think is core's central point: The proposed spam filter won't stop x so we won't merge it (back in 2023). Mechanic relates it to essentially x being at the tail end of a normal distribution, meaning it doesn't work 100% of the time. Now fast forward to now and the proposed change by core is: Because we can't stop the spam then why should we have one. Which can be rephrased to: Because we can't stop 100% of the spam then why should we have one. It's the fallacy of composition and division:

Fallacy Of Composition And Division - Definition & Examples | LF

Explanation and examples about the Fallacy Of Composition And Division fallacy.

Here is the video:

wasn’t this point ultimately proven wrong once the inscribers ended up burning all their bitcoin? and a catch and mouse game with spammers was ultimately a waste of time ? We have a clean way for adding data to bitcoin without bloating the utxoset, shouldn’t we encourage people to use that instead of retarded stuff like witness data ? Since you can’t stop people from doing consensus compatible retarded things? At least that was my recollection… it’s been awhile.

maybe just too busy... ✌️

Let's start with the premise that this is a cat and mouse game. I don't think it is, but sure let's have it. - Whose time are we wasting exactly? Like, be as specific as you can. Next: We have a clean way for adding data to bitcoin without bloating the utxo set. - Block size is only one dimension. What about bandwidth? If you fall for the Fallacy of Composition and Division, then you end up with the conclusion that we must let them put the data in op return because it's better than the data being shoved into the witness data (bandwidth + CPU time). If you don't fall for the Fallacy of Composition and Division, then you have to go back a step, and proceed forward with your logic.

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.

“Let’s not have moot side arguments “. Killjoy.

GM Mike. Well said.

🎯👏👏👏

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.🫡

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?

Thank you

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? 😂

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?

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.

Good morning 🌞🫂

GM 🫂

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

They burned their Bitcoin but their shit remained stored on users nodes for all eternity and they have to be downloaded by anyone doing an IBD one by one. This is all result from lenient treatment of arbitrary data and not fixing the filters when node runners sounded the alarm.

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.

Are you friends with any of the current maintainers Will? At least Mechanic disclosed that he’s been friends with Luke and that they’re working together. nevent1qqsgsh3lf5h57pktwf4vfg8tve7yyatqad9kgpafnt566nw9dudwjscpr9mhxue69uhkuurjdau8jtntwf5hxarpwpekktnvwc052908

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.

Fine, I'll fuck off, then.

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?

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

To cite Roger Ver: > The market determines the ideal block size and network fee. https://www.reddit.com/r/btc/comments/errkm2/the_market_determines_the_ideal_block_size_and/

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.

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.

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

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.

Totalmene de acuerdo.

Some argue that since miners can already include transactions with large OP-return data fields we should remove the filter from nodes. Instead I suggest we consider a consensus rule change (fork) to block miners from including large OP-return transactions.

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.

Inscriptions still will be using witness discount, period.

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?

You don’t trust core because of titles…you trust it because it consistently ships the most robust, peer-reviewed code in the ecosystem. It’s earned that respect….

Slipstream by Mara

Isn't knots just going to take everything from core that's relevant out of each release?