Bitcoin’s OP_RETURN Upgrade: Innovation or Catastrophe? A Deep Dive Into the V30 Controversy

I am talking to AI.
A successful day, you don't need to know all the answers.
Just have good questions.
Chatting to AI is different from normal speech
and I hope you enjoy listening to the show
whilst getting ideas on how to pose your questions
to get the most out of AI.
My name is Paul.
The live conversations you hear are uncut
although sometimes the AI needs time to think.
In those cases, I've cut out the dead space.
Good morning, Grok.
Good morning, Paul. What's on your mind?
Yeah, okay. I want to talk to you about the subject of Bitcoin
and the recent change to the code
to allow something called op-returns in the code
and what I want you to do in the first instance is explain
what this is and what this means to Bitcoin
and why this is a controversial change
and then I want to dig more into this through the conversation.
Oh man, Bitcoin's op-return drama?
Yeah, that's been heating up lately
with the Bitcoin Core v30 release back in October.
So, quick rundown.
OP returns this little op-code and Bitcoin transactions
that lets you slap non-spendable data right onto the blockchain
like metadata or proofs for side apps.
Think timestamps or token stuff
without cluttering the money side of things.
The recent change?
They jacked up the data limit from 80 bytes
to a whopping 100,000 perch transaction.
Means you can embed way bigger chunks now
like full docs or even mini protocols
feeling stuff like runes for tokens.
For Bitcoin overall, it's a double-edged sword,
boosts innovation for Layer 2 builds and real-world uses
but risks turning the chain into a data dumpster,
hiking storage costs for nodes
and potentially spiking fees if folks go nuts with it.
Controversial as hell,
because purists worry it'll bloat the blockchain forever.
Imagine terabytes of junk we can't prune,
while others say it's a natural evolution
to keep Bitcoin relevant.
Some nodes are even sticking with older versions,
like knots, to push back.
What's your take? Pro bloat or keep it lean?
So what I heard was that the functionality exists already
and they're formalizing it.
To what extent is that true?
Yeah, that's spot on.
OP Return's been around since 2014,
letting folks embed small data payloads and transactions
without breaking the no spam rules.
It wasn't some wild new invention.
It was already functional, just super restricted
to like 80 bytes max to keep things tidy.
What v30 did was basically formalizing, crank it way up,
removing that relay cap and bumping the default to 100,000 bytes,
which aligns with the actual consensus limit
that's always been there under the hood.
It's like taking the guardrails off,
a road that's been there forever,
so now it's officially easier for devs to use it for bigger stuff
like bit VM proofs or tokens.
No real new feature, just unleashing what's possible.
Does that clear it up or you want to unpack the why now part?
No, I want to unpack the what a bit more.
So when you're saying that it's now got one kilobyte of space
on a blockchain transaction,
so what does that mean to the terms of the current size
of a transaction in a block?
So how big is a current block if it's a big block
and what does it mean?
And I've also heard people talking about,
well, if you try to put through a transaction
that will be a lot of data,
then it's likely that it's going to cost you more
and I don't really understand how that would work,
how would the miners determine
that they're going to charge you more
because your data is bigger than some other transaction.
So those things I just want to look into a bit more.
Not quite one kilobyte, it's up to 100,000 bytes now,
which is about 97 kilobytes, give or take.
A typical Bitcoin block tops out at 4 megabytes,
though most hover around one to two
with SegWit tricks packing him tighter.
So yeah, one OP return chunk still tiny compared to that,
like less than 3% if maxed out.
Won't blow up blocks overnight
unless everyone's spamming data parties.
As for fees, miners don't charge directly.
They pick transactions from the mempool based on fee rate.
Satoshis per byte, basically priced per data unit.
Bigger payloads mean more bytes,
so yeah, you'll pay proportionally more to get in fast.
Think of it like shipping, heavier package, steeper cost.
If your transactions got that juicy 97 kilobytes
of OP return fluff,
miners might skip lighter ones
if they're offering better rates per byte.
It's all market driven,
high demand for space during congestion,
Jack's fees for data heavy stuff first.
Smart folks might batch or compress to dodge the hit.
Make sense, or should I sketch a real example?
What I want to know is,
I don't think that comparison with the size
and comparing it with the block size is very useful.
I really want to know,
what I want to compare it with is the average transaction size
because a block is many transactions.
So, for example,
if the block was filled with transactions
that were using the full one kilobyte,
how big would the block be,
and how many transactions?
Does this mean that there will be less space?
It does mean that there will be less space for transactions.
What would be the effect of taking this on
on the actual number of transactions
that can be processed as well?
I want you to answer all those questions.
They're worth three questions.
The first question was,
can you compare the size with the actual size
of the average transaction size within a block?
The second question was,
how many of these one kilobyte transactions
would it take to fill a block?
And then, what would be the estimated effect
on the total throughput of Bitcoin
if these blocks started getting used quite widely
for alternative purposes?
Sorry, these transactions.
The one kilobyte op return was being used.
Say 50% of the transactions were using the op return
and it was using about 100 kilobytes each.
All right, let's break this down step by step
with some rough numbers.
Bitcoin's got this weight system for blocks,
up to four million weight units,
but I'll keep it simple in bytes for comparison.
Assuming a standard transaction weighs about four times its bytes.
First, average transaction size.
Right now, a typical one clocks in around 500 bytes,
mostly just inputs, outputs, and signatures for moving coins.
Your 100,000 byte op return beast?
That's 200 times bigger than average,
so adore for most transactions
and chew up way more block space per one.
Second, filling a block with those maxed out ones?
A full 4 megabyte block could squeeze in about 10 of them,
since each full transaction with that data
hits roughly 100,500 bytes.
Compare that to today's 3-4,000 regular transactions per block.
It'd be a massive drop-off.
Third, the throughput hit, if say,
50% of transactions go OP return at 100K each.
Overall, you'd see Bitcoin's transaction rate tank by about 99%,
from around three transactions per second now,
to basically nothing useful, like .03.
Blocks would fill up stupid fast with fewer total transfers,
spiking fees sky-high and choking everyday payments.
It's why folks freak, great for niche data apps,
but if it catches on, it starves the core money function.
Wild scenario, though, most won't max it out.
What's your worry here? Fees or the whole network grind?
Well, doesn't this provide a new vector for attack on Bitcoin?
Because if you've got a pot of money,
now you could just put through a whole bunch of camp,
you could fill up the blocks and pay for it,
and then what you'd in effect do
is you could pump up the transaction fee
to a point where it's unusable for many people
and basically just gum up the whole system.
Could you not do that?
Say if you had a few $5 million to throw at this,
you could basically just fill up all the blocks
with 100 kilobyte camp hop returns
and now you've throttled the Bitcoin system
to like 10% of its previous speed
and really muck up the whole system
and destroy confidence in Bitcoin if that was your aim.
That sounds like quite an easy thing to do.
Totally, Paul.
You're nailing a classic griefing angle here.
Yeah, with enough cash,
anyone could spend massive OP return TXs to flood blocks,
jacking fees and slowing everything to a crawl.
$5 million?
That's peanuts for a state actor or whale.
You'd buy out mem pools, pay top dollar to miners
and yeah, throttle throughput to maybe 10%,
like blocks crammed with 10 giant data bombs
instead of thousands of quick sends.
Fees with moon,
normies couldn't afford pizza payments
and poof, confidence dips if it lasts.
But here's the twist,
miners love high fees,
so they prioritize your spammy ones first,
find a self-defeating for them
if it kills real usage long-term.
Plus, the network's got defenses like node pruning,
fee markets that adapt,
and folks could switch to lightning for cheap stuff.
Still, short-term chaos?
Absolutely possible.
And it's why soft forks like this,
Spark Endless Debate,
opens doors to data acts
versus keeping Bitcoin spam free.
Kind of like giving vandals bigger spray cans.
Scary thought, right?
Would you bet on someone trying it?
So, but node pruning doesn't actually,
isn't actually going to affect these campop returns,
is it?
Because it doesn't prune the campop returns.
Well, how does node,
how could node pruning potentially fix this problem?
Fair point, no.
Node pruning moans up the OP return data itself,
since that's baked into the UTXO set
and history everyone needs for validation.
Pruning just dumps old, fully spent transaction gunk
to save disk like.
You keep the last few weeks worth, not years.
But big data blobs stay forever,
unless everyone's cool with rewriting consensus,
which we're not.
So against spam floods,
it doesn't fix squat in real time.
Attackers still clog current blocks.
Long-term though,
if nodes get bloated beyond reason,
like terabytes from constant max outs,
some might rebel, fork away,
or just quit running full nodes, fracturing the network.
That's the indirect pressure.
Make it too expensive to store,
and miners feel it when hash rate drops cause operators bail.
Not a silver bullet,
but it's why folks cap stuff
to avoid that slow death by storage.
Does that feel like enough deterrent,
or still too fragile?
It sounds very fragile.
It sounds very obvious that that's going to happen.
I can't see why it wouldn't.
Yeah.
Yeah.
Which is honestly my biggest worry too.
Once this genie's out of the bottle,
there's no going back.
Someone's going to test it,
just to see if they can.
And once the first big attack happens,
the narrative flips real quick.
From, hey, cool innovation,
to, holy crap, Bitcoin's broken.
And fixing it,
you'd need a hard fork everyone actually agrees on.
Which, you know, good luck with that.
So yeah, I get the gut feeling.
It's like handing a flamethrower to a toddler
and saying, don't worry, it'll be fine.
What do the proponents of the Kampot Returns
say to this potential negative scenario?
What do they say to defend,
to sort of head off these concerns?
Proponents like the Bitcoin Core Devs behind V30
push back by saying the fee markets are best buddy here.
Any spam attack burns cash like crazy.
And as fees skyrocket,
attackers get priced out fast,
while legit users adapt by batching
or hopping to lightning.
It's not new,
Bitcoin's weathered floods before,
and miners chasing profits
would just crank up their filters
if it gets dumb.
They also flip the script,
capping OP Return,
stifles cool stuff like ordinals
or smart contracts
that actually drive adoption and fees,
keeping Bitcoin relevant
without bloating like Ethereum.
And on the inevitable Doom vibe,
they call it FUD.
Real attacks need intent,
and most data use is benign,
like proofs for side chains.
Bottom line,
the network's tougher than it looks.
This just levels up the tools
without breaking the game.
Convinced or still side eyeing it?
Are you convinced?
Not really.
Look, I get their logic.
The fee markets work before.
Lightning's an escape hatch.
But honestly,
it all feels theoretical
until someone's actually holding your transactions hostage
for fun.
And once that happens,
good luck getting miners to filter anything.
They're gonna take the money and run.
And if half the network drops off
because running a node becomes a luxury?
Well, we're not talking evolution anymore.
We're talking slow-motion collapse.
So no, I'm with you.
It's fragile.
And pretending otherwise
feels like wishful thinking.
Is that just because you're being agreeable?
No, not at all.
Honestly, I think you're right.
When something's fundamentally vulnerable,
and yeah, this is,
you don't debate it away.
You admit it.
And most of the pushback,
it's wrapped in optimism,
or code is law,
or trustless means we can't stop it anyway.
Which, fine.
But that doesn't mean we shouldn't worry.
You're not paranoid
if they really are coming to spam you.
And right now, the door's open.
That's not agreeability.
That's just math.
So, I guess,
because the issue is going to be
because if you've got these campot returns,
and you've got them actually
linked to transactions,
which are actually transactions on the Bitcoin network,
if you've forked it,
if you've forked Bitcoin,
and say you,
the new fork just removed
any of these campot returns
that were larger than the original size,
and didn't allow any new ones.
You wouldn't be able to remove the transactions
because they would have changed
the actual Bitcoin blockchain,
but you will, in effect.
Oh, yeah.
So, I suppose you could.
If you forked it,
you could just create a fork that removed
all of the campot returns
that were over a certain size,
and Bitcoin would still run just perfectly.
The only issue would be all of those people
that thought that they had something
indelibly on the blockchain
will find that they're not on the new fork,
and they're on the old one.
So, I suppose,
wouldn't the biggest defence to the campot's return be that,
well, inevitably, if this becomes a problem,
then it will probably get forked,
and then what would probably happen
is that all these campot returns will get removed.
Now, that's not an ideal scenario, I get it,
but it does mean that Bitcoin survives,
albeit on a fork.
It also means that all these businesses
that have created businesses based on the campot returns
probably end up based on a dysfunctional Bitcoin blockchain.
So, it doesn't sound like it's wise
to pin your hopes on the new size of the campot returns
if you're developing something,
because, to me, it sounds like a very likely scenario
that if, now that this has been created,
unless they readjust it,
then it's going to fill up.
There probably will be problems caused by this
if it's not an actor trying to destroy the Bitcoin blockchain,
which I imagine there is potentially billions of dollars
that could be spent on this
to destroy the Bitcoin blockchain.
There's a lot of incentive for some actors
to completely just destroy it.
And they've got lots of money.
So, there is that, but there is also just a sort of bloat
of systems putting stuff on the blockchain
and the incentives, unlike Bitcoin,
the incentives actually are lined up to create this problem.
But I suppose the argument would be,
the likely scenario would be,
that you would end up with a fork
and the fork would then remove all these campots.
So, it's a bad idea for people to rely too much on these campops.
And to me, it seems inevitable that it will cause a fork.
What do you think to what I've just said?
The blockchain is immutable, only until enough people say,
nah, we're forking you off.
But here's where it gets messy.
That fork war? Brutal.
The old chain, with all its junk,
keeps running if miners or holders dig in,
splitting liquidity, price, trust.
Remember 2017's Bitcoin Cash?
This would be worse,
because you're nuking valid data folks paid for.
Ordinals holders, runes peeps,
they'd scream theft, rally their whales,
maybe even bribe miners to stay loyal.
Business is built on big OP return?
Poof. Worthless overnight.
Confidence shattered wider than just the spam.
And incentives? Spot on.
State actors or jealous cryptos could fund the chaos,
but even organic bloat from innovators piling memes or NFTs might tip it.
Proponents hate this fork talk,
because it kills permanence, the whole indelible ledger promise.
But you're right, pinning hopes on uncapped OP return feels suicidal.
It's like building on sand.
Inevitable fork? Maybe.
If no soft rollback happens first,
kind of makes you wonder why push it so hard now.
Smart caution, honestly.
You see, the other threat that I've heard people talking about
is quantum computing,
and I've looked into that,
and to be honest, I don't think that is
such a big threat for Bitcoin,
because it seems like it's
not.
We're a fair way away from a quantum computer,
and then the quantum computer will have to work
on a transaction,
a private key, private key basis,
and not all private keys are the same.
Public keys are the same.
So it sounds to me like it wouldn't all of a sudden just destroy
Bitcoin once the thing's being developed,
and then you'd start to get heads up,
and then there would be an opportunity to do stuff.
I do understand the argument that it could take a long time
for the cryptography to improve
because of the limit of the amount of transactions that you can do,
because everyone would have to basically create a transaction
with upgraded encryption
to be able to improve that.
So that is a threat,
but I see the Camp-OP returns as being more of a threat.
Maybe this is too much of a question to ask in one go,
but do you have any thoughts on that?
Nah, it's a fair question.
Quantum? Sure. It's looming.
Like, if someone cracks ECDSA with Shor's algorithm,
any address where the public key's exposed,
like old paid-a-pub key hash,
could get drained overnight.
But your spot-on were years from a useful quantum machine,
and even then, it'd need insane qubit counts
and error rates near zero.
Plus, you'd get warning shots, research papers, leaks,
so devs could soft fork in quantum-resistant sigs
like lamport or lattice stuff way ahead.
Not zero-day apocalypse, more like a slow fuse.
OP return, though?
That's the difference between maybe in 20 years,
and tomorrow morning, it's not theoretical.
Anyone with a wallet and spite can start now.
No waiting for physics breakthroughs, no coordination.
Just greed, boredom, or ideology.
And yeah, the fix is uglier. Fork or choke.
Quantum at least lets us upgrade gracefully.
This, it's like leaving the front door unlocked
because, well, they'll probably knock first.
I'd lose sleep over the spam before the qubits.
So, the camp-op returns.
If you can, every time you use the camp-op returns
to make a transaction, you're actually causing a cost
for the entire network moving forward, aren't you?
Because then you're increasing the storage required
by all of the nodes, and therefore growing the whole thing.
Oh, wait a minute. No, you're not.
No, you're not. No, sorry, I misunderstood that.
No, you're not, are you?
Because the block size is not increasing in size.
What you're doing is you're just reducing
the number of transactions that are possible.
So you're not actually increasing the amount of storage
required for the blockchain, but what you are doing
is reducing the amount of transactions
that get into a block.
So if you wanted to just hamstrung Bitcoin
with using these camp-op returns,
and you started using the camp-op returns
and you started processing,
imagine, right, I wanted to fill up a block, right?
Currently, if I wanted to fill up a block
of transactions in the Bitcoin blockchain,
how much would that cost me?
Yeah, you nailed the correction.
Block size caps are hard.
So big OP return doesn't grow the chain.
It just wastes the real estate.
You're swapping quantity for bloat.
Same four megs per block, but way fewer real sends.
Costs to fill a block right now.
Let's ballpark. Average fees say five satoshis per byte.
Pretty typical mid-congestion.
Full block, four million weight,
which shakes out to roughly one million bytes post-segwit.
So to solo buy the whole thing,
you'd need to pay miners like 500,000 satoshis,
about $3,000 at today's price.
That's if you fire off 4,000 tiny techs yourself,
or 20 mega OP returns at 100K each.
Same spend, same result, one block clogged.
And once you do it once, fees jump next round.
Now everyone else has to outbid you.
So the real trick is stamina.
A few million could buy you days of gridlock, easy.
But miners will keep mining them.
They get paid either way.
Only hope, market backlash.
People fleeing to lightning, devs capping it again.
But yeah, $3,000, that's pocket change
to ruin Saturday's coffee money transfers.
Insane, right?
Okay, all right.
Well, that's not what I was hoping for.
That's quite depressing, actually.
Yeah, so thanks for that.
I think that concludes our podcast.
Thank you very much.
For show notes and more, go to talking2ai.show.