bro implemented libsecp256k1, segwit, taproot, miniscript, and is working on cluster mempool algorithms as we speak?
Discussion
I know. He is the best and I wish he was a maintainer. But he is not.
wat?
git author-stats --no-merges v26.0..v29.0 | tac | head | cat -n
I think he's splitting hairs over maintainer vs contributor
Damn, i didnt click link first and for some reason sipa and peter wuille didnt link in my brain. Yea hes listed right there
Did you perhaps mean to say “contributors” instead of “maintainers?” Because that is what you are posting.
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.
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
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.
What is the alternative?
I was describing a principle here, but as you know, we are choosing Knots as an alternative.
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.
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.
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.
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.🫡
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 😂
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?
GM good read
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.
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.
i don’t know his central point, is it written somewhere?
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: https://www.logicalfallacies.org/fallacy-of-composition-and-division.html
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.
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.
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.
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.
“Let’s not have moot side arguments “.
Killjoy.
