All Episodes
Previous Next
Sept. 14, 2025 - Freedomain Radio - Stefan Molyneux
01:35:21
BITCOIN UPGRADE WAR!
| Copy link to current segment

Time Text
Good morning, everybody.
Hope you're doing well.
14th of September.
Ooh, it's 10 days until it's my birthday.
You know, you're supposed to stop caring about your birthday as a man about the age of 13.
I don't.
I'm thrilled as somebody who had a mortal illness.
I'm thrilled to have every birthday, and I hope that you enjoys yours as well.
So I have been following this, and James has done the research.
And the Bitcoin under attack is the topic of the morning.
We're going to talk about this, and then we'll go private for donors.
If you want to join the private conversation, fdrurl.com slash locals or just go to freedomain.com slash donate and create the old subscription.
Seriously, they start at like three bucks.
I haven't raised these prices in like forever and ever.
So they're like, it's a buck from when I started 20 years ago.
But if you could help me out, freedomain.com slash donate.
All right.
So the question that's facing Bitcoin and it's next month that the core, the next core is slated to be released.
Should Bitcoin be restricted to financial transactions or should the market decide?
So this is the technical details.
What's changing the arguments from Bitcoin Core and their opposition and what's going on down at the root of the debate.
Okay.
So Bitcoin Core 30 is slated to release October 2025.
That's next month and contains policy changes that relax limits on the OP return transaction.
OP return is not Ron Howard returning to his child acting roots.
Oh, that's so obscure.
It's crazy.
All right.
OP return transaction.
So these changes were merged on June 10th, 2025.
Currently, OP return is limited to 83 bytes.
A byte is a simple one or zero.
You know what?
I'm just going to keep James's notes up here in case I get something wrong.
James is better at the technical stuff than I am.
So only one OP return output is allowed.
So 83 bytes, that's just enough to confirm financial transactions.
The new default limit of OP return will be 100,000 bytes and multiple OP return outputs will be allowed.
Nodes can be configured to accept return values up to the transaction weight limit, which is currently around 4 million bytes.
So it is the difference between text and graphics.
Text is very simple.
I mean, the first computer I worked on was a PET with 2K of memory, a PET, and 40 by 25 was the character limits and so on.
And it didn't do graphics.
I remember trying to program missile command using ASCII graphics.
It was quite exciting.
But text is simple for computers.
Graphics are complicated and difficult, which is why when you have a lot of graphics going on, or I guess you want to run an AI, you need a separate coprocessor or separate processor called the GPU, graphical processing unit, focused just on that.
So if it's financial transactions, has it gone through yes or no?
What's the amount?
All of that can be stored in 83 bytes.
But if you jam it up, then you can get a whole bunch of other stuff in there.
Now, when I first did the truth about Bitcoin, which is, I think it was more than it was about 10 years ago, there was this idea that Bitcoin was going to be used for things like a document verification of validation, that you would set up the blockchain with your will and then have the, then the Bitcoin was going to scan and find your death notice and then release your will and release the Bitcoins.
And so there was this whole, and then that didn't really come to pass.
And so it really did focus more on just finances, not documents, not other kinds of things.
So basically going from 83 bytes to 4 million bytes is, well, obviously it's not a small change.
You could either win $83 or you can win $4 million, right?
That would be a big change.
So this does not change consensus rules, as nodes can be configured to accept these kinds of transactions currently.
No change to consensus means that this is not a fork.
A fork occurs, a fork in Bitcoin occurs when consensus rules are changed for transactions.
All, right?
Forks can be hard or soft.
Soft forks are backwards compatible, meaning that old nodes will still accept new blocks.
For example of this is SegWit from 2017.
Hard forks are not, such as Bitcoin Cash, BCH in 2017.
Bitcoin Cash was a hard fork where I think Bitcoins are replicated and put into the Bitcoin Cash environment.
The effect of this change, the one that's coming up in October, the effect of this change is that with Bitcoin Core 30, if you submit a transaction to the public mempool, the mempool is the publicly available list of transactions that are candidates to be mined, the nodes will view these transactions as valid.
Now, all technical stuff, I'll get into the meat of the matter in a second, but we just have to square away some of this technical side.
There is not insignificant vocal opposition to this change.
So people say that this moves Bitcoin away from its primary purpose as a financial transaction network.
Opponents say this will also open the doors to bloating the blockchain and allow for spam and illegal content, malware, ransomware, CP, CSAM, et cetera, to be disseminated.
The implications of bloat reduce the ability for people to run nodes.
There are also potential legal ramifications for node operators if their systems host illegal content merely by participating in the network.
Opponents advocate for running competing node software like NOTS or avoiding upgrading to Bitcoin Core 3.
Sorry, Bitcoin Core 30.
Now, I mean, that's a big deal.
That's a big deal.
You can't jam a whole lot of illegal stuff into 83 bytes.
However, 100,000 or 4 million bytes, you can put a whole lot of nasty, ugly, illegal stuff in there, and that is not good.
I obviously am personally in favor of Bitcoin remaining as a financial network.
I don't think it needs to run all of this other stuff.
There are tons of ways of disseminating high-byte whatever's, right?
I mean, if you want to disseminate videos and photos, there's about a bazillion ways you can do that already.
You don't need a blockchain.
I think that the blockchain, I mean, as the internet gets faster, blockchain speed is going to increase.
But I've never really liked the idea.
You know what happens with traffic, right?
Why is traffic always bad?
Well, I mean, part of it's mass immigration.
And also part of it is that every time you build more roads, people just move further away.
Or, oh, wow, traffic is light.
I guess I'll switch from bus to car.
And so whatever you build, people will just fill.
It'll just fill it up, right?
And so I would rather the increased speeds of the internet around the world be devoted to processing more and more financial transactions rather than sending bloated bits and bytes all over the planet and embedding it in the blockchain in perpetuity.
My concern, of course, also would be that if this, and you know, there are trolls.
There are trolls on the planet.
There are sadists and petty people and nasty people.
And there are competing monetary systems.
There is, of course, a zillion coins out there on some sort of blockchain.
There's proof of work, there's proof of stake, there's, you know, we can go through the list.
I mean, the top ones, of course, there's Bitcoin, of course.
There's Bitcoin Cash, there's Ethereum, there is Monero for your sort of privacy coin.
I mean, you sort of go on and on.
Doge and so on.
And so to create a situation where competing coins can sabotage Bitcoin by putting terrible stuff on the blockchain seems to me entirely unwise.
If you want to attach things to Bitcoin, then what you should do is build a separate layer that references the blockchain but is not embedding things in the blockchain, if that makes sense.
It's sort of like don't bake the salt in the food.
Have a salt shaker on the table so people can add whatever salt they want, but don't bake it into the actual food.
Okay, so what is an OP return transaction?
OP return is one of the op codes in the Bitcoin scripting language.
An op code is one of many instructions that are understood by nodes when processing transactions.
Bitcoin scripting is called a Bitcoin.
When you send funds from your wallet to an address, two basic scripts come into play.
One script unlocks, this is a quote, unlocks the funds from your address or addresses, and another locks the funds to the recipients.
As a regular user, you don't need to create or maintain those scripts.
They're just part of your wallet and the overhanging code.
Sent funds become the unspent transaction output or at XO.
Boy, they're not great at acronyms.
UTXO.
I love Unreal Tournament.
UTXO, there we go.
Send funds become the unspent transaction output of a given transaction.
These funds remain locked until the owner of the address decides to do something with them.
Bitcoin's scripting language is also highly customizable.
The rules that govern the transaction are represented in code and can either be public on-chain or agreed upon off-chain.
Off-chain rules allow for greater complexity as well as ensuring sensitive information is kept private and are represented with a hash on the transactions.
So what are we talking about here?
Well, some examples of these rules are transactions that require multiple signatures before funds are sent.
Transactions that require partial agreement from responsible parties, say two out of three, people must approve time-based approaches valid only until X time or valid only after X time or shared passwords and so on.
These scripts are typically included in wallet applications, so users do not need to know how to do scripting to perform these kinds of transactions.
The OP return script is another variant that renders the transaction output as unspendable, right?
So you want to always prevent double spending on a blockchain and a lot of effort and energy is spent in, by most cryptos, to make sure you can't double spend, right?
To send your, because it takes a while to verify transactions on the blockchain, you don't want to say, I'm going to buy 10 things with all of that, right?
I want to buy 10 things and then you can only pay for one.
So the OP return script is another variant that renders the transaction output as unspendable.
These transactions are typically submitted with zero Bitcoin and are used to send arbitrary data to the blockchain.
Once confirmed by miners, the miners are the ones who process the blockchain in return for the reward of possibly getting Bitcoin, this transaction is then available to the rest of the network and relayed accordingly.
The OP return script contains an arbitrary value set by the person who created the transaction.
There can only be one OP return output per transaction.
Right.
So it's, you know, if you've ever sent something by mail, registered, you get a message when it's been sent or signed for or something like that.
Or you send something to someone and you call them and say, hey, did you get that thing?
So this is the kind of thing.
At present, the value allowed, as we said, by the OP return opcode is 83 bytes.
That's 83 ones and zeros.
That's pretty small.
This limitation was put in place starting in 2014.
After developers on the Bitcoin network started using it to include significant amounts of data as part of their applications.
So when library or LBRY was running, I would put WAV files on their blockchain.
And I got messages saying, hey, can you replace those with FLAC files?
In other words, FLAC off with your web files.
Totally fair.
Totally fair.
There was, I can't remember the name of it now.
There was a video service that I used for quite some time.
I actually spoke with the CEO for a while, but there was a video service that I used for a while where they were putting video in a blockchain.
And that did not sadly last.
Well, for reasons of sort of we can understand, right?
Okay.
So why did they put this limitation in 2014?
Well, they wanted to keep transactions on the blockchain small to maintain efficiency and avoid bloat.
Discourage non-financial data storage to keep Bitcoin focused as a decentralized payment system, right?
I mean, can you imagine if your Visa transactions, all of them included a selfie, you know, or a five-minute video of you singing, hey, Matt Arena?
Well, I mean, that would completely kill the speed of the Visa network, right?
So they wanted to mitigate spam and abuse, and they wanted to standardize data inclusion to ensure predictable behavior across the network.
All right, now let me just pause here and let me just make sure this makes sense.
Thank you.
Think clearly.
I appreciate that.
And just hit me with a why if all of this is making glorious sense to you so far, if it's too obvious or whatever, then you can mention that as well.
But I want to make sure we're going at a good pace and that it's comprehensible.
Trying to keep spam, CP, bloatware, and sabotage, right?
I mean, if you're in a sailing race and you get to determine how much weight your enemy sailboat has to carry, then you would sabotage them that way.
Oh, here's, you know, 12 anvils and I don't have to, right?
So every system that exists has to be resistant to say this and so on, right?
Oh, we have some software engineers in the audience.
Well, here's hoping I don't mess it up too bad.
There we go.
So, excuse me, what are the motivations of the Bitcoin Core team?
So they want to reduce harmful data storage.
The 83-byte limit of OP return does not prevent users from misusing the Bitcoin network.
People can attempt to store larger items on the blockchain by submitting multiple OP return transactions.
I assume that they just daisy chain it and then reassemble it later, right?
The miners do get paid, but this is quite inefficient in terms of storage.
The public mempool is where transactions can be found by both nodes and miners alike.
It is possible to bypass the mempool by sending transactions directly to miners.
Concerns here include a lack of transparency and centralization, right?
So Bitcoin is slow because it's decentralized.
And you can't speed up Bitcoin except by making computers and the internet faster, which is happening, of course.
But you can't speed up a decentralized network by definition.
One of the reasons why Visa can handle so many more transactions per second than Bitcoin is because Visa is centralized.
It's all right, all in a bunch of servers on the Visa, on the Visa property or wherever, right?
But the problem with centralized is it is no longer for the people.
It is controlled within a small group of people.
And Bitcoin, of course, is aiming to decentralize so that there's no one central area of attack.
There's no one central group that is in control of it and can impose their will on others.
So people are, oh, it's kind of slow.
And it's like, but that's by design.
That's not because it's inefficient.
It's by design that Bitcoin is slow.
Say, well, it should be faster.
It's like, well, but if you make it faster, then it's got to be centralized on a couple of computers and that's way too much power for people to handle.
Then we kind of end up in a central banking situation where the people who run those computers, oh, it's fast.
And to me, it's kind of like driving on ice.
If you've ever done this, I live in Canada.
So I remember a couple of new years ago, my family and I were heading out to a New Year's Eve celebration, and it was insane ice.
It was like truly mental ice on the road.
And so when it's icy, when it's foggy and so on, you drive slowly.
And if you've ever been in a car where people are driving too fast, like it's horrible.
And so to me, let's truly analogize this.
The cold hearts of sociopaths, of sadists, of evildoers, their cold hearts ice the road.
And if you don't drive taking into account the ice, you're going to crash into a fiery death.
So things have to be slow because of the ice of human corruption.
Don't go fast, you're just going to crash.
Or the fog of misrepresentation, lying and fraud.
Ice is the cold heart.
Fog is the falsehoods, lying, manipulation, propaganda.
These are constant factors in human life.
So you have to drive slowly because it's dangerous to drive fast.
And it's the same thing with Bitcoin.
It's so slow, man.
It's like, yes, but it's icy and foggy out there because there's a lot of corrupt people in the world.
We'll fix that over time with peaceful parenting.
But right now, that's the way that it is.
Go faster and crash.
That's all we got.
All right.
So the following transactions involve bypassing the mempool as they're non-standard according to Bitcoin Core Core's policies.
They work by encoding data in fields that bypass the limits imposed by OP return.
So here's an example.
The first method is to create a transaction that contains multiple recipient addresses encoding the data you want to send in these addresses.
These addresses will almost certainly be fake, meaning there's no private key associated with these addresses.
So you're just putting a bunch of stuff in a bunch of fake transactions and then reassembling it later and so on, right?
The other method creatively hashes data into the witness field to similar effect.
The witness data hack has less of a burden on the I want to get back to UTXO, make sure I've got the right acronym here.
Oh, the unspent transaction output, right?
So the unspent transaction output.
So the witness data hack has less of a burden on the unspent transaction output set, but it still contains, contributes to this kind of bloat.
So either way, doing so requires burning Bitcoin.
Nobody will ever unlock the funds.
And these unspent funds are then stored in this UTXO set.
The size of the UTXO set impacts memory and storage requirements on nodes.
So again, everything gets hacked.
Everything gets used against its purpose.
And this is what they're trying to deal with.
So these transactions are effectively unspendable, right?
Because they're just bookmarks so that people can reassemble data somewhere else.
And hence are expected to remain in the UTXO set indefinitely.
It would be possible to mitigate this by implementing custom pruning, but this opens up a whole other can of worms.
Worms.
If nodes were to inadvertently or deliberately prune a UTXO to a valid address, right?
So there's a whole bunch of stuff that's in limbo that's never designed to be out of limbo.
But you don't want to trim limbo because some of the stuff that's in limbo is going someplace else, right?
Let's take an example from, sorry if these analogies are imprecise, but I think they're very helpful.
Let's take an example from a bus station, right?
I mean, if you've ever been to a bus station, right, you go in, there's a bunch of waiting areas, you buy your bus ticket, you wait for your bus, and away you go.
So in the bus station, there are legitimate travelers, right?
They're coming in, they're going to go somewhere, they're just buying their ticket, right?
So those are the valid transactions on the blockchain.
There are also bums, there are also panhandlers, and there may be the occasional thief and maybe a terrorist once in a while, right?
He's going to hijack a bus or something, right?
So the bus station doesn't work if it's overrun with people who aren't going anywhere.
They're just coming to panhandle, to beg, to threaten, to borrow, to steal, right?
Then nobody wants to take the bus anymore because it's just full of people who they're not going anywhere.
So what you have to do as the guy who runs the bus terminal is you have to get rid of the people who aren't going anywhere.
Out you go, off you go, out you go, off you go.
So it's tricky though, right?
Because you want to get rid of the people who aren't going anywhere, but you don't want to drive out the people who actually have a bus ticket, right?
So it's tricky, right?
So hopefully that makes sense.
So given the nature of the blockchain, the impact is challenging to estimate.
So the ranges are fairly wide.
Estimates of inaccessible funds in the UTXO set range from 0.1% to 1%.
Witness data hacks are estimated to account for 5 to 20% of all transactions from 2023 to 2025.
So that's a lot.
So that would be like 15 to 20% of the people in the bus station are hassling other people.
That's not, if it's, you know, 0.1%, that's one in a thousand.
That's not too bad.
So the short of it is people want to be able to store data to the blockchain.
If the valid methods are inadequate to meet their goals, they will just find ways to do so that kind of clogs up the bus chain.
By relaxing the defaults on the OP return limit, developers are attempting to mitigate these workarounds.
Now, miners already accept transactions with larger data, creating a mismatch with Bitcoin Core's restricted policy.
Excuse me, the new limit aligns node policies with what miners reliably mine, reducing centralization pressure.
It also encourages transparency by reducing private submissions directly to miners.
So it's just workarounds to get miners to process stuff.
So this enables new use case scenarios.
So the increased limit supports applications like decentralized identity systems, layer two solutions which would get their Web3 projects anchored to Bitcoin by allowing more data on chain.
So let's look at the plus of these things before we look at the inevitable sociopathic horror of how it can be corrupted and sabotaged.
So we're back to what I was talking about in 2014.
So on blockchain, legal documents and certificates, such as legal deeds, contracts, or diplomas, right?
So I graduated from this place.
You can check under the Bitcoin, it's been signed by the university, it's valid, right?
Which reduces fraud.
Enhanced NFT, freedomainnft.com, freedomainnft.com.
Enhanced NFT in digital collectible media, which would include not only the asset itself, but metadata about the asset, the title, the author that they created, and descriptions.
Decentralized identity or DID and credential verification, enabling verification without storing docs-ready materials in publicly available databases, e.g.
Google, Firebase, as was seen with the T-App leaks.
Supply chain tracking with detailed logs, on-chain oracles and data feeds, decentralized social media or content publishing, right?
You can't use the blockchain.
I mean, some people have, of course, built stuff on blockchains for social media.
I'm looking at Nostra and things like that.
So decentralized social media or content publishing, medical and health records, anchoring, and so on.
So developers argue that restricting OP return data is a form of transaction censorship.
No, it's not.
I mean, censorship is just something that is constantly used as a lever against people in the public square.
Basically, what happens is people claim censorship because they want to use your platform to spread their bad ideas, right?
So they say, well, if you don't let me use your platform to spread my bad ideas, that's censorship.
It's like, no, censorship is when I prevent you from building your own platform, not when I refuse to let you use my platform.
It's a whole different thing, right?
It's violent to prevent you from building a swimming pool in your backyard.
It's not violent or it's not immoral to stop you from using my pool in my backyard if I don't want you to.
So yes, it's censorship to restrict OP return data, which conflicts with Bitcoin's ethos of neutrality and permissionless block space.
The change ensures nodes-related transactions likely to be mined, reflecting economic realities.
So that's the pro case.
What does the opposition have to say?
Those who oppose the changes readily acknowledge that the workarounds that contribute to UTXO set bloating need to be addressed.
Where they disagree stems from their view on the purpose of Bitcoin as a currency, first and foremost.
Blockchain bloat.
Right.
So there's no question that non-financial data storage is already occurring on the Bitcoin blockchain through workarounds like the Ordinance Witness data hacks and fake addresses.
The strongest version of the opposition's argument is that expanding OP return limits would not mitigate this harm, but instead amplify it, leading to exponential blockchain bloat, higher operational costs for nodes, and a fundamental erosion of Bitcoin's decentralized monetary first design.
Not to mention potential legal exposure if you're running a node that processes illegal images or I mean, imagine if some criminals decide to upload some sort of It wouldn't be obviously direct plans for criminality, but some sort of encoded plan for criminality and you're processing it and so on.
Are you a could you be considered some sort of um accessory?
I mean, I don't know.
I'm not a lawyer, but it just seems risky.
And even if it only happens once and it's prosecuted once, but the prosecution fails, people are like, eh, you can beat the rap, but you can't beat the ride.
So they may hesitate to do that.
It is the old question: do you accommodate bad actors and reduce their incentive for bad actions by accommodating what they want to do or not?
In general, I'm on the not side as a whole.
That's like saying, well, we have shoplifters, so let's just let people take stuff.
That way, we don't have shoplifting.
It's like, you kind of do.
Just don't call it that, right?
So, one, existing workarounds are detrimental, but expansion would normalize and accelerate abuse.
Luke Dashter and Jimmy Song conceived that data storage via hacks like ordinals or fake addresses is already bloating the UTXO set and bypassing public mempools, contributing to centralization as users submit non-standard transactions directly to miners.
So process this, but it's not part of the general transaction.
However, they argue that this current abuse is self-limiting due to its inefficiency and higher costs.
Hacks require burning small Bitcoin amounts or complex scripting, deterring casual use.
I mean, yes, very few people know how to do this effectively or efficiently, and so on, right?
So expanding OP return as planned would remove these barriers, making spam cheaper and more accessible.
Yes.
Thus inviting a flood of non-essential data, e.g., NFTs, images, or arbitrary files, that overwhelms block space.
So when I was first writing in my late teens, I started writing novels.
And my mother was highly insistent that I get things copyrighted.
Like, boom, get it copyrighted, register it, do this, do that.
And that way you're protected.
So, what I did was I mailed the novels to myself, registered, and left them unopened.
And that would be right, but she was that's not enough.
And she was very, very, because her family were all writers.
Her brother was a writer.
Her father was a writer, and so on.
Two of her brothers, three of her brothers were writers.
So we got some writing in the gene wiring.
And it was kind of a hassle to print everything out.
This is back when I would write, you know, 500-page novels at three cents a page.
You know, it was a lot of money for me back then.
And then I'd have to go and register, mail it, and so on, and then store it and make sure I took it in the 18 different places I moved to in my teens and 20s.
And it's a lot of work.
Now, imagine if I could just upload it to a blockchain.
Oh, I think I've done.
Oh, I've got some edits.
I'll upload the new one.
So things that are too easy get overutilized.
You need to have a barrier to using things poorly.
And I've sort of often talked about this, which is people say, well, the internet was developed by the government.
It's like, well, yes, the internet was developed by the government.
And that's one of the reasons why there's so much spam.
You know, it's really inefficient and so on.
Right.
And I mean, I remember I used to have a boss who fell for every scam known to man, God, and devil.
Right.
So he'd get an email which says that, well, the government's going to start charging or internet service providers are going to start charging one penny per email that you send.
Right.
Now, wouldn't that be great?
It would be fantastic if you could pay a penny for every email that you sent.
That would eliminate spam.
I mean, that would be fantastic, right?
Anyway, he would send me these things and I'd look it up and it'd be like, no, no, no.
And then the next week, this Nigerian guy.
Anyway, so if you make it super simple to jam a bunch of data on the blockchain, if you make it just automatic, you just hit your upload or, you know, because there's going to be, you won't even need to upload.
You know, I guarantee you that there will be, if this is technically possible, I think it would be, there'll be programs that, you know, you've got a folder on your computer with your sensitive files or whatever, and it's going to encrypt and upload them to the blockchain automatically.
Like it won't, you won't even need to do it by manually or whatever, right?
So anyway.
So Luke Dasher has emphasized that while data publishing is already an exploit, sanctioning larger OP return would effectively endorse it, turning a niche problem into a systemic one by normalizing what should remain discouraged.
Yeah, so the fact that you can't solve the actions of bad people doesn't mean that you should reinforce it by doing what they want, right?
So the fact that you can't catch every shoplifter doesn't mean that you shouldn't try and catch any shoplifters and you should, in fact, tell people that they can take whatever they want.
I mean, you've technically gotten rid of shoplifting, but it's not going to work, right?
So let me just get back to the right spot here.
Song reinforces this by noting that accommodating demand for junk data doesn't solve the issue, it perpetuates it, as seen in historical precedents like the block-size wars, where easing constraints led to unintended bloat without improving core functionality.
All right, let me just stop by, check in with your fine listeners, and this already makes sense.
Oh, a byte is 0 to 255 and consists of eight bits.
Sorry, you're absolutely right.
Abyte is 0 to 255 consists of eight bits.
You're absolutely correct.
Bytes and bits.
Thank you.
I should know that.
I should remember that, but oopsie.
Thank you for the correction.
I really, really appreciate that.
David.
David.
Yeah.
Okay.
Bits is 1-0.
So bytes is 0 to 255.
Tanky, tanky, tanky.
All right.
Let's move on.
So blockchain bloat would escalate exponentially threatening decentralization.
So a core strength of their argument is the quantitative risk.
So Bitcoin's blockchain is already about 600 gigabytes.
And workarounds like Ordinals have spiked block usage up to 20% of space in 2023 peaks.
Dasher has warned that this is utterly destructive, as higher costs would price out hobbyist node operators, leading to centralization where only well-resourced entities, corporations, and governments, run full nodes.
Yes.
That is important.
The fellow Song builds on this and highlights sustainability.
The fee market alone can't self-regulate spam if data is made too easy to include, as low-value data transactions could still outbid during low-demand periods, gradually inflating the chain and making Bitcoin less accessible for everyday financial users.
See, here's the thing too.
Like, so Bitcoin has become the fastest-growing asset, the fastest value-increasing asset in all of human history, and it's had a very small OP return.
Why do people want to mess with something that's working?
So, Bitcoin Mechanic claims that an increased OP return would roll out the red carpet for scammers, normalizing what was once exceptional abuse.
Jason Hughes echoes this, saying that the shift prioritizes short-term convenience over sustainability, as increased data floods blocks.
Sorry, that was very badly phrased.
As increased data floods blocks, raises fees for financial users and burdens nodes with gigabytes of non-essential content.
Yes.
Critics point to empirical evidence from Ordinal 2023 search, which temporarily drove fees up 10 times and slowed nodes.
Expanding the OP return could normalize such events, eroding Bitcoin's resilience as a decentralized network.
So critics also argue that Bitcoin's white paper envisions it as electronic cash, not a general purpose data store, and accommodating non-financial data dilutes this focus, potentially harming its value as money.
The fact that people store data is a bug, not a feature.
Expanding OP return legitimizes data storage, effectively steering Bitcoin away from its financial focus.
Yes, as I said, the fastest growing, quickest increase in value in any asset in human history.
Let's mess with it.
No.
Dasher proposes stricter filters to reinforce financial primacy, arguing that ignoring demand preserves Bitcoin's niche as a secure monetary network.
Yes.
We need Bitcoin for when fiat fails.
We don't need Bitcoin because people want to share their holiday photos.
Song adds that this shift could fragment the community as seen in past debates and undermine Bitcoin's scarcity narrative by filling blocks with low utility data.
Jason Hughes has warned that the update could transform Bitcoin into a useless altcoin as it encourages storing images, documents, or NFTs on chain, commoditizing block space for non-value transfer activities and eroding its scarcity as money.
Yes.
Bitcoin Mechanic adds that while data spam, like ordinals, already harms the network, actively endorsing larger OP return makes such abuse commonplace, turning Bitcoin into a junk drawer for gross media or malware.
And, you know, I gotta...
OP return is pronounced op, like opportunity.
Thank op return.
Thank you.
I appreciate that.
Great summary, Leff, that you're covering this.
I appreciate that.
And also thank James.
If you would.
If you've ever read, sorry, if you've ever run a it used to be called a BBS, but way back in the day, we used community server.
And James and I, we still have facial twitches from this.
We would use community server and there would just be a bunch of spam.
Even it's funny because even in the locals live streams, there's a guy who just spams memes.
Like when we're trying to have a discussion, he just spams memes.
It is just some people, it is graffiti.
It's graffiti.
Just look at any city, there's going to be a-holes out there who just graffiti up things.
So that's, yeah.
Okay.
In summary, and of course, this is, it's not just people who want to have a compulsive, like think of hoarders.
Like there's, if you want to hoard something, there's no better place to put it on the blockchain.
It'll literally be available until the end of time, right?
And so just think of hoarders.
They're just going to store everything.
They just have a compulsion.
They have a mental illness and they just want to store everything on the blockchain.
Oh, I never want to lose my kids' drawings.
I'm going to take pictures of them and put them on the blockchain.
People will absolutely do that.
Now, they won't do that if you've got to jump through all these tech hoops to do it, but they'll do it if it's automatic or if it's real easy.
So in summary, Bitcoin's edge lies in specializing as a monetary network.
Expanding data capabilities risks fragmenting its user base, making it less competitive against specialized data chains like Ethereum, ultimately harming its store of value proposition.
Right.
The store of data serves the store of value.
The store of value is served by decentralization.
The more data you put on the blockchain, the less decentralized it can be, which is really its primary focus and value.
Critics contend that broadening op return, see, I just integrated the anyway, op return invites scrutiny by making illicit or harmful data easier to embed plainly, potentially triggering regulatory crackdowns or cloud provider shutdowns for nodes.
Right.
And it won't just be the people who purvey these illegal and ghastly images.
It will be people who want to attack Bitcoin and the blockchain.
So they will insert these images in, they'll have legal teams ready to go, and it's just going to be horrible.
Bitcoin Mechanic warns that, quote, no one is going to run nodes if archival data contains tons of gross media slash malware, as forensic tools could extract such content from raw blockchain data, damaging Bitcoin's reputation and exposing users to legal risks.
He concedes that current workarounds already allow data storage, but their inefficiency makes harmful content harder to embed and detect in a coherent form.
Expanding op return would allow contiguous, easily reconstructable files, enabling bad actors to upload illegal material directly on chain.
He highlights empirical precedents.
Cloud providers already scan for malware or illegal content using AI tools.
And if nodes relay such data as raw blockchain blobs, automated forensics could flag it, leading to account suspensions or forced shutdowns.
And what if somebody uploads something wildly defamatory?
So if you broadcast, I mean, again, I'm no lawyer, right?
Obviously, but if you broadcast or process or spread wildly defamatory information, does that expose you to legal liability?
And of course, one of the things that's required in defamation suits is that the defamatory information be taken down from public view.
But the blockchain, you can't go back and change it, right?
So it's a problem.
And I don't think it's well worth it at all.
So exchanges or pools could face immediate takedowns as seen in past crypto incidents where platforms were penalized for hosting illicit data.
He posits that this scales catastrophically with thousands of nodes affected.
Bitcoin's network could fragment overnight, reducing hash rate and validation capacity, all because the change lowers the barrier for abuse without safeguards.
While full nodes do run on personal hardware, a significant portion, 30 to 50% based on node surveys, are run in the cloud.
Mechanic argues, Bitcoin Mechanic argues, that bad actors could upload compressed files that, when extracted, trigger provider scans, leading to catastrophic shutdowns of hosted nodes, exchanges, and pools.
He draws on real risks.
If even 20% of nodes go offline due to violations, it could spike fees, slow confirmations, and erode trust, cascading to minor disruptions and hash rate drops.
This isn't a hypothetical.
Similar issues have plagued other chains, and Mechanic's warning is a call to prioritize network stability over accommodating data demands, preventing a self-inflicted vulnerability that workarounds alone haven't yet triggered at scale.
Yeah, if it requires a significant amount of technological expertise to extract the data that is put in through these fake address mempool things, I don't think you'd be particularly held liable.
But if you can see it clearly, you know, with some viewing software, then probably more so, right?
Again, I'm no lawyer, but that's my guess.
So Bitcoin Mechanic extends the argument beyond technical shutdowns to broader consequences.
By facilitating easier data storage, Bitcoin Core 30 could invite regulatory scrutiny as governments increasingly target chains hosting illegal content.
If nodes are seen as relaying malware or illicit materia via op return, it could lead to legal actions against operators further incentivizing shutdowns to avoid liability.
In a steel-manned form, Mechanic underscores Bitcoin's franchise opposition.
Unlike Ethereum, which embraces data-heavy apps, Bitcoin's strength is its simplicity and monetary focus.
Diluting this risks reputational harm, sorry, deterring institutional adoption and fragmenting the community, right?
So, I mean, there's, of course, you know, I did a whole series on this last year and the year before about how the institutional investors are investing in Bitcoin, ETFs, and so on, are all investing in Bitcoin.
It's one of the things that's driven its value up so much.
They're not going to want to have the kind of regulatory exposure that could occur if illicit material is on the blockchain and easy to view and see.
So, shutdowns wouldn't be isolated.
They could trigger a death spiral where fewer nodes lead to more centralization, higher costs, and reduced security, ultimately betraying Bitcoin's decentralized promise for short-term utility gains.
All right, let me just check in here.
Thank you for subscribing, Billy.
I appreciate that.
It just sounds like saboteurs to take down Bitcoin by increasing data size.
Yeah, I think that's quite true.
Like back in the day, leftists would make bad comments under videos and tell the media buddies about the bad comments they posted themselves.
Yeah, I don't have any proof of this, but it would not at all surprise me if reporters created alt accounts, posted really bad stuff under the accounts of people they wanted to take down, and then screenshotted this really bad stuff and said, you see what kind of fans this guy has?
Like, nobody knows, right?
So, yeah, it's a very good point, Joe.
I appreciate that.
Thank you.
Could have happened to me, theoretically.
All right, what about lack of community consensus?
So, critics of the change, such as one David Diaz and Marty Bent, claim that there was a lack of community consensus regarding the changes to OpReturn, with some describing it as coercive.
Regarding the lack of community consensus, Diaz and Bent concede that the OpReturn change underwent review, but argue this process was insufficient for consensus, as it primarily involved a handful of Bitcoin core contributors rather than a representative cross-section of the ecosystem.
Yeah, it is often the case that people have wild overreactions to relatively minor problems, and it's really bad, right?
So, if you've ever driven with kids, right?
If you've ever faced this, you drive to the country often in the country, right?
And so, you're driving with kids, and they say, there's a frog on the road, right?
Or there's a toad on the road.
Don't hit it, daddy.
And you don't want to hit the frog in the road, but you also don't want to drive dangerously.
You don't swerve and God knows what happens, right?
And so occasionally, I mean, often you can, if it's not busy, right?
If you're on some empty, lonely road or whatever, you can slow down if it's safe and drive around or whatever.
You can even park by the side of the road if it's really not busy.
It's some dirt road and you get the frog and take it to safety.
But there's times when you can't.
Traffic's moving fast, it's tight, and you have to drive over the frog.
Like, sorry, right?
Because the solution to not driving over the frog, I know crazy analogy, right?
But the solution to not driving over the frog is potentially crashing the car.
So, you know, you drive over the frog and you're, maybe you can lie.
Hey, I missed it.
But if they look back and they see a squished frog, they're going to be upset and be like, yeah, that was really sad.
I wish I could have, right?
And you have to deal with the upset of your kids.
But I think in general, they're less upset with a squished frog than they would be if you crashed the car.
So sometimes you just have to grit your teeth and deal with problems rather than, you know, I mean, I could get rid of all trolls by shutting down everything I do online.
I could eliminate all spam by not having a single email address.
All right.
So there is often the case that there's an irritant, right?
There's an irritant in your mind, a splinter in the mind's eye, as the old book was called, or, you know, the sand that turns into the pearl.
So there is an irritant, and you focus on that irritant.
And it sort of gets larger in your mind.
I sort of noticed this on coming back to X. So if I happen to be searching or scrolling past mentions, right?
Then I'm seeing a comment.
Let's say the comment is really annoying, right?
Not that I would ever be annoyed.
I'm far too Zen.
But imagine if I was the kind of guy who could theoretically break out of his platonic Zen indifference and be annoyed by something, Steph Mark II.
So there's a comment that's annoying and it's right there in front of you.
And, you know, you have to remind yourself that it's like three pages down on some tweet.
No one's going to read it.
Now you read it because you're scrolling through your mentions, but almost nobody else is going to read it.
And when you have this, oh, we've got this problem, 5% of blogs, this is an issue.
We've got to fix this.
We've got to solve it.
It's like, but why?
But why?
Are you driving over a toad or are you crashing the car?
And so when you are, and it's sort of the same thing when you're running a community service board or message board or something like that.
You know, there could be a couple of people who are like, this guy's driving me crazy.
And then you kind of look and it's like, nobody else is really bothered.
Nobody else is really reading his stuff.
So you really have to be careful when you're running something that you take the outside view of a problem, not the inside view of a problem.
So for instance, I was not particularly aware of all of this daisy chaining injection false address stuff.
I was not aware of it, really.
I mean, I sort of heard vague things about it, but I didn't.
So most people don't even know about this stuff.
And is it the Streisand effect?
Well, we've got this huge problem.
We've got to fix it.
Here's how we're going to fix it.
And it's like, is it a huge problem?
And is the fix better than the problem?
Now, no fix which legitimizes the problem is going to work, right?
No fix which legitimizes the problem.
Because this is not just about this.
I always think of down the road, right?
So people, bad actors, have wanted to use the blockchain for storing non-financial data, let's just say, right?
Okay.
All right.
So if the Bitcoin Core community says we're going to do what they want, they're encouraging other people to misuse the blockchain in order to get the core developers to do what they want.
You're giving the people who are spamming and scamming, or let's just say charitably not using the blockchain for its intended purpose.
If you adapt to give them what they want, you are encouraging future misuses of the blockchain in the hopes of swaying the developers to give the future misusers exactly what they want.
Ah, think about it down the road.
Don't just think of second order, third order effects.
Let's appease these bad actors because that will be the end of bad actors.
No, you've just appeased them.
You're encouraging more bad actors.
So regarding the lack of community consensus, Diaz and Ben concede that the op return change underwent review, but argue this process was insufficient for consensus, right?
It was just this handful of Bitcoin core contributors rather than a representative cross-section of the ecosystem.
So as Bitcoin gets bigger, you need more consensus for changes.
I get it.
And it was very early days.
You know, there were 12 nodes or whatever it is, right?
I'm sure you've seen this famous, there was a StarCraft II competition from way back in the day.
They're like, first prize, $100, second prize, $50, third prize, $25.
Fourth prize, 25 Bitcoin, right?
So back in that, yeah, when it's you and a buddy, sure, I get that.
That's fine.
But now it's massive.
You have a huge number of interested parties.
Because the whole point of Bitcoin was to avoid centralization.
So you need a representative cross-section of the ecosystem, as Diaz and Bent say, because you want to decentralize decisions made about Bitcoin, because Bitcoin is all about decentralization.
And why would you say, well, it's really bad for Bitcoin processing to be centralized on just a few servers, but it's really great that the massive decisions about Bitcoin are centralized in a few, a small number of core developers.
Diaz has explicitly stated that, quote, there was no clear consensus on this, and therefore it should have never, should have never, should have been never merged.
Sorry, that's a bit awkward.
He said there was no clear consensus on this, and therefore it should have been never merged, adding that while some devs supported it, vocal opposition from node operators, educators, and users was dismissed.
They cite historical changes such as the SegWit upgrade in 2017, as it required extensive signaling from miners and users via BIP9 activation, ensuring buy-in so you can do a vote pretty easily.
They also note that opposition to this upgrade wasn't a fringe element.
It included prominent voices such as Luke Dasher, Jimmy Song, community feedback on Acts, forums, and petitions with concerns about bloat centralization and deviation from Bitcoin's monetary focus going unaddressed.
Bent has criticized the process as lacking transparency, noting that the change was pushed through despite unresolved debates on mailing lists and GitHub, where alternatives weren't fully explored.
All right, let me just.
Let me just double check here in case I got something wrong.
All right.
Can't they just store a hash on the blockchain and just reference the data elsewhere?
Yes.
I mean, yes.
Yes, they could, and that's what should happen.
What's the crake with the developers promoting this?
Are they on the flight lust or something?
Right, maybe, yeah, probably not.
No, I'm sure they're not.
Making changes to the system in order to appease means the original intent may be lost.
Yeah.
Yeah, the current intent of the 83-byte limit on op-return is to allow for a hash that could reference a file somewhere else, right?
Because if there's a file somewhere else and you're not processing it on your node, it doesn't pass through your computer.
And therefore, you wouldn't be liable, right?
So let's say, let's take a silly example, right?
What do I have?
I have a little data card here, right?
So let's say that Somebody puts a hash in that points to a data card on his computer.
So you're processing the hash, but you're not processing the data file that's on his computer.
Let's say there's an illegal image on the data file on the card on his computer.
But you're not accessing or processing that.
You have no idea what the hash points to.
Let's just say it's a file path, right?
So you're just processing a file path.
You're not processing the actual image.
And so you wouldn't be as far, again, I'm no lawyer, but I don't think you'd be liable for that.
But if the actual image gets embedded in the blockchain and it's in the legal image and you're processing it and it's stored where you are and elsewhere and you're making sure it gets promulgated and so on, yoikes.
Yoikes.
It doesn't take a lot of threats to have people change, right?
We know that from deplatforming, right?
How many people are talking about what I was deplatformed for?
All right.
So sorry, let me get back to this and continue.
And I just double check if there's people who have comments and so on.
Somebody says, to steal man the core side, restricting how people can use the blockchain opens it up to censorship attacks down the road.
The nature of an open system is that some people will use it in a way you disagree with.
The nature of an open system is some people will use it in a way you disagree with.
Well, sure.
But that's already the case.
You don't need to embed illegal images in the blockchain because there are already people who use, I mean, it's a very small number of people statistically, but we're pretty sure that there are already people who use cryptocurrency to buy drugs, buy illegal drugs, right?
So I don't agree with that.
I think that's not a good use of the system.
So that's already happening.
That doesn't, right?
That's already baked into Bitcoin.
That's not a new thing.
I mean, people use American dollars to buy arms for terrorists.
So that's sort of baked into the system.
On their use of the term coercive, Diaz and Bent used coercive to describe a form of procedural and economic coercion with the structure of Bitcoin's development and network effects compels adoption without voluntary agreement.
In their view, coercive means maintainers leveraging their control over the dominant Bitcoin core repository to merge changes that force users into a binary choice, upgrade to the new version or fork and run older software, which could isolate them from the network due to compatibility issues or reduced security.
So that's, yeah, I mean, that's an issue, right?
Bent has implied this by calling the process coercive, arguing that once merged, economic incentives pressure the ecosystem to follow, sidelining dissenters without their explicit consent.
Well, I mean, it's an interesting question, a moral question, which is that people have poured a decade, decade and a half into Bitcoin.
They have thrown their entire net worth in to Bitcoin.
They are heavily invested in Bitcoin and emotionally, professionally, from a resource standpoint, they're all in.
Now, if it is the case that if this upgrade 30 goes through and the opportunity is increased and it harms the holders of Bitcoin, it harms the miners of Bitcoin, it harms the Bitcoin network as a whole, who's liable?
I mean, it doesn't matter because the people who are developing this don't have the resources to cover everyone's losses anyway.
So who's liable?
If you push something that reduces the value of other people's assets, so in the business world, it's called fiduciary responsibility.
Again, none of this is legal advice.
It's just my amateur idiot opinion, although I certainly have been in this world for quite a long time.
So, fiduciary responsibility.
If you do something as a CEO that harms the value of the shares, you can be sued for fiduciary misconduct.
You have a fiduciary responsibility to act with reasonable caution and preference to maintain or increase the value of your shares.
So, if you as a CEO want to do X, right, you want to do something, and everyone warns you against it, and everyone says here's going to be, or a significant portion of the board warns you against it, says a bad idea, says exactly all the negative things that are going to happen, and you go ahead and force it through anyway, you can be liable, not just for losing your job, but you can be liable.
So it is a what happens if they're wrong, right?
I don't respect people who don't have skin in the game.
Now, you could say, well, but they have, maybe they have Bitcoin too, these core developers, blah, blah, blah.
But that's not the same thing as harming other people's, right?
It's one thing if you want to gamble with your own money, I think it's stupid, but if you want to gamble with your own money, but don't gamble with other people's money, right?
That's that's the challenge.
So what skin in the game do they have with regards to the negative effects of their actions if their actions turn out to be negative?
They can't recompense anyone, right?
So Diaz echoes this by noting the lack of clear consensus implies a top-down imposition where network effects coerce alignment, akin to how soft forks can, quote, force non-upgraders into obsolescence without violence, but through systemic leverage.
Yeah, if there turns out to be a security hole and it's patched in the new version, but not patched in the old version, you've got to upgrade to the new version, right?
Some critics have speculated that Bitcoin core developers may have been compromised by third parties.
Whether those agendas are to co-opt Bitcoin for their own usage or destroy it as a competing currency, there are those out there who have a vested interest in changing Bitcoin from a currency to something else.
Sure, of course.
It's not Peter Schiff, though, guaranteed.
All right, responses to criticisms.
Let me just double check in here, make sure we're still adding value.
All right.
Bum, bum.
I think we're good.
I think we're good.
Makes sense.
Yeah, of course, the mainstream media headlines will be appalling.
And fiat currency, I mean, obviously, it's not going down without a fight, right?
So Bitcoin should remain focused on finance, is one argument.
Bitcoin Core maintainers and contributors like Gloria Zhao, Greg Sanders, and Antoine Passant have responded by framing the change as a practical adjustment to align with existing network behavior, reduce harm from workarounds, and uphold Bitcoin's censorship-resistant ethos.
Well, but some stuff should be censored, right?
I mean, illegal images should be censored.
I mean, I don't know why that's particularly, I mean, defamatory articles should be censored, right?
I mean, lies that are economically destructive, right?
Where something has been won in a lawsuit, right?
I mean, censorship-resistant, some stuff should be taken down.
Some stuff should be removed.
So they argue that Bitcoin isn't designed to enforce subjective financial only rules and restricting op return has inadvertently caused more problems than it solved.
One, Bitcoin is permissionless and neutral on data types.
Developers emphasize that Bitcoin's protocol doesn't distinguish between financial and non-financial data.
It's a decentralized ledger for any valid transaction.
Zhao stated that the existing op return limit was an arbitrary policy, not a consensus rule, and removing it promotes neutrality.
Quote, Bitcoin should not censor based on content.
The fee market should arbitrate block space.
Now, the fee market is, I assume, related.
I thought this is a type of a free market earlier because I'm just so used to seeing a free market, but fee market is, will the miners be willing to process it?
Sanders has added that critics' view of Bitcoin as solely for money ignores its programmable nature, noting that demand for data storage exists.
Yeah, but why does it have to be Bitcoin?
Just promote something else.
Or if you want to store stuff, as far as I understand it, Ethereum allows you to store more.
At least that sort of was mentioned before.
Tell me if I'm wrong.
But there are other blockchains that will allow you.
A fee market is what the miners receive.
Now, that's not your, I think I got that, but I appreciate that.
Somebody says, so it'll be another BTC cash situation.
I agree that it might slow down new adoption, but it's pretty well established now.
I have a hard time believing that many people would abandon it.
I'm not sure, obviously.
I remain optimistic.
Well, it's not that people would just abandon it because the blob size is bigger.
It's because they might undergo legal threats or consequences for running nodes, and therefore they'll stop running nodes.
And if enough people stop running nodes, it gets centralized, and then it's completely corrupted from its original purpose.
Two, the change reduces harm from workarounds, not encourages spam.
A core argument is that the 83-byte limit has failed to prevent non-financial data.
Instead, it forces users into harmful alternatives, which bloat the UTXO set, bypass public mempools, and increase centralization.
Zhao has responded that the update corrects a mismatch between the harmfulness and standardness of data storage techniques, making op return the cleaner option to keep data prunable, not stored in the UTXO set.
Remember, that's where you create a bunch of fake addresses in order to store data, which is never going to be processed.
The transactions in the public mempool, Poisson, sorry, and transactions in the public mempool.
Poisson has echoed this, arguing that aligning relay policies with what miners already accept prevents a shift away from the public mempool, preserving decentralization.
Three, economic incentives, fee market will self-regulate.
Developers counter that Bitcoin's fee market, not artificial limits, should govern block space.
High fee data transactions will compete with financial ones.
And if data spam becomes excessive, fees will rise naturally, discouraging it.
Zhao has noted, quote, the demand for these use cases exists and the restricting OP return pushes data to less efficient methods, harming the network.
This view aligns with Bitcoin's design as a permissionless system where users decide value, not developers imposing financial-only rules.
So if data spam becomes excessive, fees will rise naturally, discouraging it.
That is a very interesting objection.
I'd love to know what you guys think of that as a whole.
So the argument is that if somebody's trying to send a store and send a zillion emails through the blockchain, I'm just making up a sort of scenario here, then the fees will rise, making that economically inefficient.
So will miners charge more for processing a video than they would for processing a financial transaction?
Well, I would assume so, because it requires more bandwidth and more processing power to process a video than it would be to process a financial transaction.
So maybe their case is that it's going to prevent people from using these other tweaks.
And I don't know.
Sorry, James, if you didn't get to this or not.
I'm not sure the degree to which this bypasses all of that other stuff.
Is it no longer possible to use those other tweaks?
Because if the price gets too high for high-fee data transactions, if the price gets too high, like you can't send a 4 gig video over email because the email servers won't process it, won't do it, right?
and won't store it.
Or at least they won't pass it through.
So if people use a bunch of blobs, blobs being just a whole bunch of data because the op return has widened, if people then try and process a whole bunch of stuff and then the fees rise, won't they just go back to using the prior hacks?
And then you have kind of the worst of both worlds because the prior hacks are still being used.
But now you have this big blob thing that's also available for people.
So, yeah, I assume, and sorry if I got this wrong, please tell me, but I assume that they have closed off these other avenues for doing data.
Because if you have both and the fees get too high to discourage the big blob with a higher OP return, op return, sorry, then people would just go back to the other hacks and workarounds.
No fundamental shift, just a policy cleanup.
Proponents describe the change as a harmless cleanup of outdated policy, not a redefinition of Bitcoin's purpose.
In a joint statement by 31 core developers, they addressed the debate by stressing improved network health and communication, rejecting claims of coercion and affirming that the update enhances censorship resistance without altering consensus rules.
Right, but you don't need censorship resistance with a smaller op return because you can't store images and so on in this very small number of bytes, right?
Rejecting claims of coercion and affirming that the update enhances censorship resistance without altering consensus rules.
Critics' fears of a junk draw blockchain are dismissed as overblown, with devs pointing to Bitcoin's history of evolving to support broader utility while maintaining its monetary core.
Yeah, well, I'm not so sure about that, because that smallness has been around for a long time.
So, let's move on.
Catastrophic node shutdowns.
Peter Todd, a Bitcoin developer and vocal supporter of the op return expansion, dismisses mechanics of Bitcoin Mechanics catastrophic shutdown warnings as overblown and unlikely, arguing that blockchain data is stored as raw bytes, not interpretable files, making automatic detection by cloud providers improbable.
I'm not sure about that.
All pictures are stored as raw bytes.
All videos are stored as raw bytes.
VLC takes the bits and bytes, which you can look at on the hard drive if you want to scan on the hard drive or SSD.
Everything is stored as raw bytes.
My video is raw bytes.
It's just ones and zeros and matrix style going across the pipes.
Don't quite understand that.
He reasons that cloud providers don't routinely scan blockchain blobs for content as it's computationally expensive and not targeted at decentralized protocols.
Past incidents, e.g.
IPFS pinning illegal data, haven't led to widespread Bitcoin Bitcoin node bans.
What's because it was rare and so on, right?
Todd views the concern as fear-mongering, noting that illegal data risks exist regardless of OP return size, and the update actually reduces harm by shifting to prunable standard outputs rather than UTXO bloating alternatives.
He emphasizes that Bitcoin's permissionless design means users, not developers, bear content responsibility.
And Mechanics Signario ignores practical mitigations like encrypted or hashed data.
Bitcoin's permissionless design means users, not developers, bear content responsibility.
But he's not talking about the node runners, right?
And so here's the thing, right?
So human beings are corruptible.
Human beings are greedy.
Human beings are, at least in their current iteration, amoral at best.
So the question is, let's say that Bitcoin starts to really take over and displace a fear currency.
Then a government faces a catastrophic reduction in size and power.
What do you think the government's going to do?
It's going to use any excuse possible to shut down Bitcoin.
Don't give them excuses.
Idiots, don't give them excuses.
They're going to fight and fight hard to do that.
People are like, well, but the law is like, but the law is going to be used to preserve power.
That's what the law is.
The law is used in general to preserve power.
And if Bitcoin starts to threaten nation states and fiat currencies, don't expose their soft flank to inevitable incoming arrows.
It just doesn't make any sense to me.
Bitcoin developers dismissed concerns.
It's important to understand how Bitcoin Core developers responded to these concerns raised.
To say these concerns were dismissed implies they were waved away.
Is this true?
Well, the merge followed open source process with sufficient review.
This is the rebuttal.
Developers like Gloria Zhao and Antoine Poisson, Antoine Poisson, argue that the op return limit increase was thoroughly debated through Bitcoin Core's open source process with pull request hashtag 29769 open for months.
Wasn't that a good yes album?
Anyway, receiving feedback from contributors, node operators and community members via GitHub mailing lists and X discussions.
They dismiss claims of lack of consensus as misrepresenting how Bitcoin development works.
Consensus doesn't require unanimous agreement, but rather a lack of sustained valid objections from active contributors.
Zhao says that the process was transparent and inclusive with no critical technical flaws raised that warranted blocking the merge.
The pull request underwent extensive review with 31 developers signing a joint statement affirming that the process followed established norms and that dissent was considered but not deemed sufficient to halt progress.
I don't know, man.
If you're not getting feedback from people who've experienced a lot of political blowback, I'm not sure that you're going to be getting valid, right?
So, well, technically this, that, the other, but you want to talk to dissidents who've experienced significant blowback for free speech.
Those are the people you want, not the nerds, not the technical guys.
I'm sorry.
But that is who you need to consult with.
People who've been unjustly persecuted by the state, those are the people you need to talk to, right?
Maybe people who've had blowback from the SEC, like the library guys and so on.
Those are the people that you need to talk to because it is a political issue when you are potentially hosting fairly transparent illegal content on a blockchain.
It becomes a political issue.
So you need to talk to those people.
Go talk to Julian Assange.
Go talk to Julian Assange and ask him how the law is used to silence dissent.
So the pull request underwent extensive review with 31 developers signing a joint statement affirming that the process followed established norms and that dissent was considered but not deemed sufficient to halt progress.
They argue that critics like Diaz, who called for a clear consensus, misunderstood that Bitcoin core decisions rely on rough consensus among maintainers, not universal community approval, as Bitcoin is not a democracy but a meritocratic open source project.
Sanders adds that Bitcoin's permissionless nature means users can store data regardless of limits, so aligning policy with reality is pragmatic, not a betrayal of purpose.
Developers view the lack of consensus claim as overstated because active dissenters didn't propose viable alternatives that addressed the harm of workarounds.
They see the opposition as ideological rather than technical and thus not a blocker for a policy change that doesn't alter consensus rules.
Ideological.
If you look at how, say, the Jan 6ers were treated versus the BLM riots in the summer of 2020 and say, well, it's just ideology to think that rules might be applied differently based upon your position relative to power.
Anyway, the change suggests real network harm outweighing speculative concerns.
Developers like Greg Sanders and Zhao dismiss concerns about blockchain bloat as speculative compared to the tangible harm of current workarounds.
They point to evidence like the Ordinals 2023 to 2024 surge, 5 to 20% of block space, and Counterparty's 2014 fake address burns, about 2,100 Bitcoin, which added thousands of UTXOs as proof that restrictive limits cause harm.
By contrast, larger OP return outputs are prunable, and their inclusion in the mempool ensures transparency.
Developers dismiss bloat fears by noting that the fee market will regulate data usage, high-fee financial transactions will out-compete low-value data during congestion as seen historically.
Critics like Bent and Dasher warn of exponential bloat, but developers argue this is hypothetical and manageable.
It's not hypothetical.
You're literally increasing what you can store on the blockchain.
They view the criticism as ignoring the status quo's worst outcomes, prioritizing a purest vision of a practical network health.
Developers also reject the term coercive as used by Diaz and Bent, Poisson and others.
Sorry, Poisson and others argue that Bitcoin's open source model is inherently voluntary.
No one is compelled to upgrade and users can run older versions, fork the software, or reject the update entirely.
The joint developer statement emphasizes that, quote, Bitcoin Core is open source.
No one is forced to run any version and network effects are a natural outcome of community alignment, not coercion.
They point out that Bitcoin Core's development process allows anyone to contribute or object.
And dissenters like Dasher actively participated but didn't sway the majority.
The merge was a policy change requiring no mandatory update like a soft fork.
Developers argue that coercion implies intent to force, whereas the update reflects a reasoned decision after debate with users free to opt out.
They dismiss the term as emotionally charged, noting that economic incentives are a feature of Bitcoin's design, not a flaw.
All right, let me go back to you guys in case I've made any errors.
Chris says, without a doubt, governments will pivot against Bitcoin if it's in their interest of retaining centralized power.
Yeah, for sure.
Well, imagine that there is a hyperinflation that is revealed by Bitcoin.
I mean, Bitcoin is already, I don't know if the value of Bitcoin is going up or the value of feared currency is going down, right?
It's obviously a little from column A, a little from column B. But imagine that Bitcoin is going to be the first warning signal of hyperinflation.
And governments want to cover up hyperinflation because they want to spend their money and so on.
So imagine that governments, What is their relationship going to be to people who are jumping the Titanic to get on Bitcoin?
They're getting on the lifeboats.
And the hyperinflation is the result of that.
Lower demand for the currency means lower currency value, which means higher prices.
You get this hyperinflation cycle, right?
So what are they?
They're going to want to get rid of the lifeboats.
They want to remove the lifeboats and keep people on.
Or rather, they want to get to the lifeboats, the lifeboats being the first spending of inflated fiat currency, not Bitcoin.
So they're going to do anything.
And oh, the laws.
Like, come on, man.
You can't be that naive.
Okay.
So, what other solutions were suggested that were rejected by Bitcoin Core?
Implement better filtering and spam detection.
This was proposed both by Luke Dasher and Jimmy Song.
Dasher suggested objectively distinguishing legitimate data from spam via relay filters, rejecting the latter and less obfuscated.
Song shared statistics on filters, implying enhanced filtering mechanisms to block non-financial data.
G Maxwell argued that Dasher's distinction between legitimate data and spam is subjective and ineffective, as users can disguise data.
Filtering requires consensus changes, and policy-based filters like data carrier size won't work because miners can mine non-standard transactions anyway.
This would increase maintenance costs, testing complexity, and user confusion without benefit.
Anti-spam advocates haven't proposed viable consensus-level solutions, sticking to ineffective policies that push users to worse hacks.
Maintain or tighten current limits.
Luke Dasher argued for reducing the operation limit to 40 bytes, less than half, saying that allowing more data is utter insanity.
Jimmy Song and Bitcoin Mechanics supported keeping the current limits in place.
Zhao and Sanders stated that keeping the 83-byte cap or reducing it is arbitrary and ineffective, as it doesn't prevent data storage, it maintains a status quo of immediate harm to the network.
Critics recommend that people avoid Bitcoin 30, either by running older versions or running software forks such as Bitcoin NOTs.
Nots ships with a default opera of 42 bytes, which means these nodes will not relay transactions that exceed this limit.
Zhao and Sanders noted that while users can run NOTs, this doesn't prevent miners from including larger data transactions, as the change is a policy, not consensus rule.
Nots, the software users, risk forking from the main network or seeing their transactions ignored, increasing fragmentation without fixing UTXO bloat.
It also encourages a two-tier network where stricter nodes become isolated and doesn't reduce harmful workarounds.
Todd implied such alternatives are paternalistic, lifting, sorry, limiting permissionless block space without broad buy-in.
Considering claims of third-party compromise, there's no substance of these claims based upon available information.
They appear to be unsubstantiated speculations from critics of the operation change, often framing it as deliberate sabotage or corruption, possibly by competing interests, but without concrete evidence, such as financial links or internal leaks.
Conclusion.
Confusion.
All right.
I can understand the concerns of those objecting.
I think that there is some degree of alarmism in coercive warnings about illegal content, as well as the claims of third-party compromise on the part of Bitcoin Core.
But the core developers have a point about the nature of Bitcoin development, which is to consider feedback and objections from the community, but that it's a meritocratic open source project that does not require universal democratic acceptance for changes that were made.
Bitcoin Core developers also note that those objecting to these changes did not provide alternative solutions to the problem the Bitcoin Core team was attempting to solve.
While those objecting are not strictly required to advance solutions, it is certainly more valuable if you provide an intelligent possible solution.
Now, here's what I need to know.
James says, as far as I can tell, they've not made changes to actually block the workarounds or hacks.
Well, that seems a huge problem.
That's a huge problem.
So, and if you can just double check and verify this, I obviously don't want to make unsubstantiated claims, but if they have not found ways to deal with the UTXO, the mempool stuff, if they've not found ways to deal with the fake addresses and the daisy chaining of data with smaller transactions that are assembled later, if they've not dealt with that or stopped that, then they've simply created a second problem.
And if the market fees become high enough to dissuade people from jamming the blockchain with junk data because of the higher op return, then people will simply go back to the old thing.
And now you have two problems, whereas before you only had one.
So if it becomes too expensive to use this new op return size, people will simply go back to the prior hacks.
And now you have two problems rather than one.
So I can't believe that they haven't found a way to deal with that.
I understand it's a challenge, right?
Because it's an open blockchain, which you can put just about anything you want into.
But the problem of pruning the mempool and so on, if that's not solved going forward, then your mempool is simply going to continue to bloat with unresolvable transactions because the transactions are only faked to create a daisy chain of data.
I think I have that right.
Tell me if I haven't.
And let me get your thoughts on it.
I'm sorry, I think, of course, we've gone an hour and a half almost.
I hope this finds this valuable.
I've had a lot of requests to deal with this, and I hope I've done it some justice, and I hope I haven't gotten things particularly wrong.
Of course, if I have, please let me know.
And let me know this.
Somebody says, okay, I don't know the practicality of this, but couldn't a KID car, a CP image be included in a Bitcoin transaction with this change?
I believe that is the fear.
I believe that is the fear.
So somebody says, we do know that Peter Todd accepted $6,000 to tweet about a Solana meme coin, so he's open to sponsorships.
I don't know that.
This is your statement.
I don't know that.
If it's true, that's not great, unless you said it openly.
Well, we had a call, what was it, on Friday night's show?
We had a call with somebody who was like, will you sponsor my meme coin?
And I was like, if I give you some of the meme coin, and I was like, nope, nope, nope, nope.
Somebody, Graham says, am I off base here?
The spam filters can be used to freeze wallets.
One of the first things you'll get is a count blacklist in every node.
Get on that list and you're cooked.
I don't know.
The problem of fighting spam, of course, is big and would be resolved with an email that charged you a penny for sending an email.
So, but that's not how the internet works because it was government.
Oh, somebody says it was 5K.
Yeah, again, I can't confirm whether Peter Todd accepted money to tweet about a Solana meme coin.
Of course, I do know that there were a bunch of, I think it was a bunch of conservative people who were receiving money to promote narratives from India, I think it was, without revealing it.
And I think that's terrible.
Just so you know, I'll never do that.
I'll never do that.
And after 20 years, I hope that you'll accept it.
I hope that you'll accept it, that I'm not going to do that.
I've been offered money for stuff, but it's not even remotely tempting.
So, yeah, in summary, it certainly is true that you don't have to run the new software.
And if the new software causes bloat, that's a problem.
And it will.
It seems almost inevitable that it will if the new software causes bloat and causes people to potentially process brutally horrifying and illegal images or documents and so on.
That seems like that issue.
James says, it doesn't look like Bitcoin Core has an approach to prevent these workarounds.
But when I asked Rock, it just talked about the Bitcoin Core 30 update.
Okay.
So that doesn't seem to be any evidence.
And certainly another research that we've done has indicated that they've closed off these other ways.
So it seems to me that you're going to end up with the bloat when the network is not super congested and the fees are low.
And then when the fees are high, people will simply go to these other hacks to get the data in that they want.
It's not like to break past the 83 byte limit.
So I vote thumbs down on this update.
I don't see any reason why you need to fix something that isn't broken.
Is it perfect?
No.
Every system can be hacked and exploited.
And making the data process, sorry, making the system process more data does not deal with the problem of hacks and exploits.
There are, you know, here's the thing.
So when you're around a lot of reasonable, rational people, it's easy to forget just how many ugly, nasty, sadistic, and compromised in evil people there are in the world.
And it's sort of like, you know, people are like, well, we're going to have this, this government structure is going to protect us.
And then just about every single time, those government structures end up being inhabited by the enemies of freedom who use it to hold down the population.
It's sort of the growth of totalitarianism that we've seen throughout history as a whole.
So I am not a fan of this update.
If the update bloats and it's very quickly seen to be negative, hopefully people will downgrade and hopefully a solution will be found.
It is democratic in that you do have to do the upgrade in order to process all of this, but you still have to process all of the data.
If I understand it correctly, you still have to process all of the new data that's going to be injected into the blockchain as a result of raising the op-return limit.
So you are not immune from the consequences of this upgrade, even if you don't personally upgrade it.
And maybe versions will come out where you only upgrade, sorry, you only process the small op-return stuff, not the large op-return stuff.
And in which case, I don't know how that's, I mean, it would just mean that the large stuff will take forever to process, I assume, and the small stuff will process well.
And if the large stuff takes too long to process or is too expensive, then people will stop using it.
And maybe there'll be a downgrade or maybe only processing the smaller op return transactions will become the norm.
And then, right, so somebody says, that's correct.
Like it when that happens.
You can only filter your own meme pool.
Once they're mined, then it all ends up in your blockchain.
Yes.
And maybe people will have to have clients that only process the old op return size transactions.
I mean, if I were running a company that was running nodes, I would only want to process the smaller transactions.
Why would I want to have a whole bunch of blobs stored on my server?
But again, it's one blockchain, right?
So again, I'm not technically savvy enough to know how that works.
But I would certainly give, let me put it this way.
I would give a massively high priority to the financial transactions because that's where the real value of Bitcoin is.
And raising the limit so high is also a little nuts in my view, right?
But it could be the case that these big blob files are going to be so expensive and so low priority that they're functionally somewhat unusable or less usable.
But then people would just go back to the old hacks and right.
So somebody says, I mean, somebody, let me just see here.
Somebody says, I mean, if you can't really spam, you can let all transactions through.
If you have spam, you need spam filters.
You either scan everything and or use a wallet blacklist.
That wallet blacklist will not be used to reject all transactions on an address, just like an email being rejected based on a from address.
will be used to reject all transactions from an address.
You'll get a centralized blacklist where one does not exist now.
Yeah, I think that's true.
James says, and to be fair, it's a really, really challenging problem to address since miners can accept transactions submitted directly to them.
And how would a miner know that the transaction contained these data hacks?
Fake addresses look real.
Technically, the witness data hack is also not readily distinguishable either.
Yes, but they would look at the size of the transaction.
And if it was a miner and it were to say, okay, the size of this transaction is five megs or whatever it is, as opposed to 83 bytes, they would know that it would be part of the new sort of blob stuff and they might really, I mean, they'd have to be processed at some point, I suppose.
You can't just not have a transaction processed, but maybe it's so slow and so expensive that only it'll only be used for legal documents.
You know, if you're posting a will, let's say it takes a week to end up on the blockchain for whatever reason, it costs you 50 bucks.
It's still cheaper than going to a lawyer, maybe, and so on.
So maybe those things will work.
It's, yeah, the size submitted would be immediately suspect, right?
Yeah, for sure.
Yeah.
I mean, it's like it's a difference between you get a little envelope and then you've ordered a 3D printer.
If you get a little envelope, you know it's not in there.
If you get a big box, it could be in there, right?
If the majority of nodes don't upgrade, they can ignore the new bloated blocks that would force the miners who run the new version to downgrade.
Is that right?
They could ignore them?
Okay.
Mara, who knows Slipstream, the tools to submit directly to the miners, has some incentive to inspect or censor the data.
Yeah.
And there's the cloud stuff, right?
It's the cloud stuff.
Well, the cloud stuff is going to be scanned for illegal images.
I mean, because the governments will just make them do it, because governments may be opposed to Bitcoin.
It depends.
I mean, because some of the politicians have Bitcoin, don't want to reduce its value.
Some of them don't, and are reliant on FIA to want to maintain that value, which means attacking Bitcoin.
So the cloud service will be done.
But then the problem is who owns, who's responsible for the data being on the cloud?
They may be liable.
If you're running something locally, you may be liable.
So yeah, it just seems, it seems like a bad, I mean, keeping it focused on monetary transactions is important.
I don't know the answer as to pruning the, was it UTXO?
I don't have the answer.
I mean, I'm not.
It's been a long time since I programmed.
I did program decentralized nodes way, way back in the day.
I remember working for a giant company and they had data in four different continents.
And I had to write programs overnight to reconcile all the data because it was too slow to run it in one central database.
So everyone did it locally.
And then I had to merge all of the data in a central.
So I've done some data merging stuff and it is a challenge, but I don't know the technical side of Bitcoin to that degree.
Might be fun to learn, but I'm getting old.
All right.
Well, listen.
If you find what it is that James and I do helpful, valuable, if this form of communication is helpful or valuable, if my technical knowledge and good ability to communicate things is helpful, freedomain.com slash donate.
Now taking Monero.
So freedomain.com slash donate, I would absolutely, no, I'm not going to do the origins of evil.
So, we'll do that in a private stream later.
You've certainly learned a lot about how Bitcoin worked by doing this.
Yeah, I think it was very interesting.
And I hope, of course, I've done justice to the topic.
I'm sure I have not.
Perfectly, no doubt.
And anything that I got wrong or anything that needs to be expanded, please email support at freedomain.com.
Support at freedomain.com and we'll work to set things straight.
I appreciate your patience.
I love your support.
Freedomaine.com/slash denate.
Have yourself a glorious, wonderful, beautiful evening or Sunday afternoon, and we will talk soon.
Take care, everyone.
▲
Export Selection