Stéphan, are you able to come out already and explain the format of the debate?
Yeah? Fantastic.
Okay, please welcome Stéphan Livera, the moderator for the first debate at Lugano's Plan B Forum, to the stage.
He's going to talk us through how it all works.
Yeah, Stéphane?
Yeah, sure. Thank you.
Thank you.
We'll just need the table set up.
But in the meantime, I'll just give a brief intro while we get everything set up and the table down here.
But yeah, we're going to be talking about Bitcoin ossification, our two debate participants.
Firstly, Jimmy Song.
Both of our debate participants are globally recognized Bitcoin speakers, educators.
Jimmy is well known for his authorship of various books, programming Bitcoin, and teaching people about Bitcoin.
And Jameson Lopp is known as the CTO and co-founder of Casa, and also is known in his own right for education about Bitcoin, contributing to Bitcoin governance discussions.
Now, I'm just going to ask if we...
Are we getting a table at...
Yeah.
Yeah.
Are we getting a table here?
Yeah.
Okay.
So just a few minutes while we get that started.
I guess I'll try to maybe offer a little bit of the context just while we're waiting.
So I'm sure Jimmy and Jameson will both have their own perspectives to share.
But a lot of the debate goes back and forth in terms of things like what kinds of risks should we take with Bitcoin?
Who are the right people to determine that?
As well as exactly how aggressive should those changes be?
Of course, there's been a long history of what changes were made to Bitcoin and, let's say, the crucible of 2017.
And so I think because of that, as you might have seen in the earlier panel with Samson and the other gentleman chatting about covenants,
that seems to have changed the pace at which protocol upgrades and changes are made.
So those are a couple examples that I think people may get into.
And what you could say is that soft forks have slowed down over time.
And so we'll also be talking a little bit about, you know, is that a good thing?
Is that a bad thing?
And yeah.
Yeah.
Sound guy is next to you.
This is the first time we've tried this.
So apologies while we set the room up correctly.
Okay.
All right.
That's fine.
Yeah, no worries.
Okay.
Yeah.
All right.
Well, let's get it started then.
Okay, he's good.
So, yeah, let's bring everybody out.
Jimmy and Jameson, let's come out.
All right.
So I'll just quickly explain the structure and then we'll get into it.
So we will have an opening statement from Jimmy for five minutes.
Jameson will have a five-minute opening statement on his side.
There'll be a five-minute rebuttal from Jimmy, a five-minute rebuttal from Jameson.
Then we'll have 15 minutes of roughly moderated conversation back and forth and then closing
statements, two minutes on each side.
So with that said, Jimmy, are you ready to go?
Yes, I am.
All right.
Let's go.
Your five-minute starts now.
All right.
Just so you know, the last time I did this was on a cruise with Roger Ver, so I'm glad that
this is a much better venue.
Thank you to Plan B, the city of Lugano, and everyone here for this opportunity for me to
speak about this very important issue.
It's an honor to be here and I hope to do my side justice.
Since the beginning, people have had two predominant and wrong views of Bitcoin.
The first is economic, that Bitcoin is not money for one reason or another.
This error is usually made by economists and their followers, some even of the Austrian school.
They reject Bitcoin because it does not fit their conception of what money is supposed to
be.
Bitcoin is obviously money, and the 15 years of history disproves their theory, so we don't
need to refute this error here.
The second error is that of Bitcoin primarily being a technology.
This error is usually made by technologists because the innovations that they've seen
in their lifetime are generally technical in nature.
They are the proverbial hammer wielder thinking that everything is a nail.
Like other technologies they've seen, say mobile phones or apps or websites or something like
that, they think that it's a race to build new features and to win is to beat the competition
through changes.
But this is a serious error and indeed is the main argument given by altcoiners and their
ignorant investors, thinking that a bitter mousetrap is what will win.
13 years of altcoin history also dispels this myth.
Faster block times, different proof-of-work algorithms, more expressive but buggy smart contract
languages, alternative consensus systems, and much more have been tried out, but none of these
features have gained much long-term traction, let alone threatened to dethrone Bitcoin.
More features are not what make money better.
To illustrate, let's go through a thought experiment.
Imagine that the Federal Reserve added technology features into the dollar.
For example, faster settlement times, expressive smart contracts, and even privacy.
Would those features make it better than Bitcoin?
For example, would you switch to it?
Probably not.
Because they can and do change the monetary policy all the time.
In other words, features are not what make Bitcoin better.
Bitcoin is better money, not just better technology.
Bitcoin is money first and technology second, and it neither needs centralized management nor
new features for adoption.
Indeed, it's better for money to not change.
The reason why the classical gold standard works so well was because gold didn't change.
In fact, the properties of gold are such that it's fairly hard to change it, either at a
macro level, where its supply expands at around 2% per year, or at the micro level, where it's
non-reactive and extremely durable.
Money that doesn't change is better because people who own it can plan more effectively for
the future.
Nobody likes a game where the rules keep changing, particularly if it's designed to pick winners
and losers.
This principle that money is better when it doesn't change is the basis of my stance in
this debate.
We want money to be predictable so that when the unpredictable happens, we can use the slack
afforded by our savings to get us out of unpleasant situations.
So my bias towards ossification is derived from this principle.
Bitcoin's value proposition is that it is sound money, and sound money works best when its properties
are known and predictable.
That's not to say that I don't want anything to change or be built.
Just do them on other layers.
It's for this reason that I don't like the word ossification.
Ossification is a weird word to be using because the mental picture you get is of a fossil, of
something old, worn, and no longer living.
I think a better picture is that of a house foundation.
We are building a new monetary system, and for that, it's important to have a trustworthy
and stable foundation to build on.
And indeed, that's how I view the layer one of the Bitcoin protocol.
It's the monetary foundation.
You can build other things on top, like Lightning, eCash, sidechains, ARC, statechains, and the
rest.
The foundation underneath all of these layers must be stable and predictable for those innovations
to mature.
We don't want to be changing the foundation because at this point, millions of people are
depending on it.
The threshold for changing a house's foundation should be fairly high because it is a very difficult
process, and you may be damaging things built on top.
Similarly, Bitcoin's foundation needs to be set so that other layers can have a chance to
be built to mature and to refine.
That said, I will concede that there are some really cool things from a technological perspective
that you can build if you add a new opcode, for example.
But that's not enough for me.
It's not enough for a feature to be interesting.
I need to see why a feature is imminent and necessary.
If some critical cryptographic primitive is broken, that would necessitate change because
the compromise of the system is imminent, and presumably there are no other ways to fix
the problem.
To further my analogy, such an event would be like a destabilizing crack in the house's
foundation.
And though it's an invasive and difficult task, a destabilizing crack would justify repairs.
But as I said, that's a massive cost to the entire ecosystem and should only be considered
in a situation where there's grave danger.
What is not enough is for something that's necessary but not imminent.
For example, we need to do something about the timestamp block header problem, but that's
not until 2106.
We don't have to solve that problem right now.
What's also not enough is something that's imminent but not necessary.
Some regulation that bans exchanges from sending to a certain address may be imminent but unnecessary.
For me, imminent and necessary are the criteria.
In conclusion, what I view as important are Bitcoin's properties as money, and the bar for
changing at this point, given how much value the network has, is pretty high.
And I get the developer's perspective.
They want new toys to play with, new primitives to work with.
But the design space that hasn't been close to being explored yet with what we already have.
Between SegWit and Taproot, we have a crazy array of possibilities as shown by BitBM and others.
Changing things to satisfy the developers is the wrong motive, just as changing things to satisfy
the Bitcoin businesses during the block size wars of 2017 was the wrong move.
Our priority should be Bitcoin as money, not Bitcoin as art gallery or decentralized exchange
or digital archive.
I mentioned earlier that the error of many people that approach Bitcoin from an economics
angle is to dismiss Bitcoin because of the loyalty to an economic belief.
Such an attitude comes not just from wrong economic beliefs, but also technical ignorance.
I would implore you not to make the opposite error, which is to dismiss the economic and monetary
reality of Bitcoin in favor of perceived technical progress.
Thank you.
Okay.
Thank you, Jimmy.
Okay.
Thank you.
Yeah.
Okay.
Great.
So I'm good.
Thank you.
Yeah.
So Jimmy did go one minute over, so you'll get an extra minute as well.
So Jameson, you've got six minutes.
Great.
Good to be here.
And interestingly enough, my last Bitcoin debate was also with Roger Verer.
It's funny how that works out.
So I pose to you that Bitcoin can only remain vibrant, relevant, and secure in the long run
through the willingness to implement sensible and broadly beneficial protocol improvements
in a careful, consensus-driven manner.
And ossification to freeze progress at our current point is arrogant, it is ahistorical, and it
is a rejection of the same visionary foresight that created Bitcoin in the first place.
Thoughtful, continued evolution is key to Bitcoin's long-term value proposition.
Now, digital gold is superior to physical gold precisely because it is not inert.
It can be improved.
Now, Bitcoin today is only 15 years old.
It has undergone many consensus changes and upgrades.
And I believe it is premature to assume that at this particular point in time, it's an ideal
stopping point.
Protocols must adapt over time in order to remain viable.
We should learn lessons from other popular network protocols like SMTP, the email protocol.
If Bitcoin ossifies, we should expect that developers will build increasingly complex and risky layers
on top of it to add the missing functionality that is desired.
And I actually find BitVM to be an excellent example of that.
This is not throwing shade on the BitVM developers by any means.
They are doing the best that they can working with what they have.
So, the problem that I have here is that complexity tends to introduce bugs and exploits.
Now, I don't think any of us are going to argue that Bitcoin should become a kitchen sink protocol.
We don't want to add low-level functions that have high expressivity, for example, like EVM chains.
But, at the base layer, certain basic functionality can make sense if it reduces the complexity required
to build that functionality at higher layers.
Many desirable features, like covenants, vaults, and payment pools, require base layer upgrades.
And building these in a clean way on top of the protocol, I believe, is superior to doing hacky overlays.
A base layer with more building blocks unlocks an entirely new design space for Bitcoin, as Jimmy said.
Careful, well-tested upgrades that have been thoughtfully debated, as we're doing today,
and have reached community consensus do not undermine the property rights of Bitcoin's core and stable monetary proposition.
I believe that the upgrade process that we've seen play out for the past 15 years,
in fact, enshrines the will of the users.
It does not override them at the behest of some cabal of shady elitist developers.
I believe that Bitcoin has far greater potential than what we've achieved thus far.
And I believe that the Bitcoin blockchain should be seen as a cryptographic accumulator
for a wide variety of systems that can anchor into it.
And we've barely scratched the surface today of what is possible.
By ossifying today, we are going to make it extremely difficult to build permissionless second layers.
And we're hamstringing developers, limiting them from experimenting to find the most valuable uses of block space.
But we don't have all those primitive building blocks that make it easy to roll out the second layers that we want.
And I should note that we implemented three different forks to help enable the lightning network.
And without the functionality that was enabled by those forks, lightning network would be far clunkier and the game theory not as sound.
There are plenty of soft forks we could do, like any pre-vout that would supercharge lightning and allow channel factories, giving us orders of magnitude more efficiency.
There are forks we could do like cross-input signature aggregation that would enhance privacy.
And there are forks like OpCat that would increase security of self-custody with covenants and vaults.
Now, in 2015, Gregory Maxwell said the following.
If the system is too costly, people will be forced to trust third parties rather than independently enforcing the system's rules.
If the Bitcoin blockchain's resource usage relative to the available technology is too great, then Bitcoin will lose its competitive advantage compared to legacy systems.
And validation will be too costly, pricing out many users and forcing trust back into the system.
If capacity is too low, then our methods for transacting to inefficient, then access to the chain for dispute resolution will be too costly, once again pushing trust back into the system.
So, point being, the decentralization of verification that won the block size war is only one part of the story.
And decentralization of economic actors is at least important to the long-term success of Bitcoin.
So we should remember it's not just the people that run the nodes that matter, but rather the economic majority of the nodes.
So we want there to be as many economic actors running nodes as possible.
With today, we could maybe have 100 million on-chain entities, if you have the right assumptions.
But we can in no way get to having 8 billion people that are self-custodied on-chain without some sort of changes.
And this will, I think, extremely make a difference in the landscape of the value of Bitcoin over the long run.
I don't want to see us in a position where only the elite OGs can afford to be sovereign on-chain.
Otherwise, we may just create another cycle of prosperity that ends up leading to bread and circuses due to centralization.
So for the first time in history, Bitcoin has the potential to do more than merely shift power from one elitist group to another.
But I believe this is only if we continue working towards maximum decentralization by improving the protocol and making Bitcoin's fundamental properties accessible to as many people around the world.
Great.
Thank you very much, Jameson.
So, Jimmy, you've got five minutes for rebuttal.
Yeah.
So thank you for your considered speech.
You mentioned that you wanted protocol improvements and that they were necessary.
Necessary for what?
And I think you sort of let the cat out of the bag a little bit when you said that you wanted to be useful for lots of other things.
Besides, in my reading of, or if I heard you correctly, the, you know, other than cases of money, basically.
I would ask why those cases are relevant at all, given that Bitcoin's main property and the current usage that it's using is as digital gold, as you said.
Why would that, why would other thing, use cases have priority over the thing that most people use it for?
Second, you said it would be arrogant to not have continued evolution.
I actually think it's the opposite, that to continuously change something that's working for a lot of people,
especially with something like money, which benefits from not changing and is beneficial when you're not constantly having to upgrade things, is better.
You also said that the main benefit to digitization versus something physical like gold is that you have the ability to make changes to it.
And I would completely disagree with that point, the main benefit of digitization is that there's no physical thing to carry around.
You can instantly send Bitcoin halfway across the world without having to settle by sending gold or delivering gold and so on.
There was also something about complexity and cleanness and having a larger design space, experimenting, ease, and efficiency.
These are all sort of from the technical side.
Could you make any arguments from the economic side on why those things are necessary from a monetary standpoint?
Because the argument that I gave was that the technical has to be balanced with the monetary, and Bitcoin is money first.
And whatever things make it easier for the developer, that isn't the point of Bitcoin.
It's to make sure that it's good money for everybody.
And if you're making changes so that it's a little bit more efficient for the developer or a little bit better for some corporation to make changes and so on,
I don't think that's a strong enough argument to change the protocol.
You also mentioned that it won't scale properly if you currently can have something like 100 million transactions.
I think Peter Todd put out a paper saying something like,
you can get, you know, half a billion to a billion using sort of optimized lightning channels that opens and closes sort of made in optimized transactions.
You can get up to about a billion.
Why do we need to, you know, take care of that now?
It seems like we should give the market a chance to figure out some other ways to do things.
We have lightning, we have batching, we have lots of other technologies.
It sounds like a classic example of premature optimization to me.
And lastly, you mentioned there's sort of like an elitism that's brewing if you're allowed to transact on-chain and others are not.
We don't actually know that yet, right?
Like, as far as it currently stands, we've seen that a lot of people can make transactions on-chain.
Now, they can't necessarily pay for coffee, but, you know, like a $10 fee isn't insurmountable and is better than the current system in any case.
So, I'm curious to know, you know, at what point, like, why do you think that's going – what evidence do you have that that's necessarily going to happen and that there won't be innovations on other layers that are sort of decentralized like lightning is?
So, those would be the points that I would have on yours.
I'm sure you have a lot on mine, so please.
Thank you.
Okay.
Well, thank you, Jimmy, for some great rebuttal.
Now, we're going to go to Jameson for five minutes of rebuttal.
Right.
So, I find that the steel man argument for ossification basically posits that, you know, Bitcoin has achieved its core functionality as sound money and as a store of value and that further changes, even if well-intentioned, could introduce unnecessary risks.
And these risks could undermine the very properties that make Bitcoin valuable.
And so, by ossifying the protocol, we ensure that Bitcoin remains trustworthy, decentralized, and an immutable monetary system for the long term.
There's a number of issues at play here.
And, actually, I like the point that you made about, like, the house and the foundation and making changes to a house can have unintended consequences.
My own personal history, when I was growing up, I lived in a house and had a small stream that went by that house.
Now, over the decades that I was living in that house, the rest of the economic infrastructure in that small town started booming.
We had a lot of development.
We had a lot of asphalt put down, a lot of drainage systems that changed.
And every year, little by little, that stream started having more and more runoff.
And after about 15 years, we got to the point where my house started flooding every time that there was a rainstorm because of these changing conditions in the environment.
And the point that I'm trying to make here that I've also made with SMTP and other protocols is that you can ossify the protocol, but you cannot ossify the rest of the world, the environment within the protocol, and how it has to exist.
So, there's always going to be more problems, and I think the real question here, and what we're all kind of grasping at, because we can't predict the future, is how are these problems going to get solved?
It's entirely possible, and I cannot disprove that we will be able to solve a lot of problems, even if Bitcoin ossifies where it is right now.
What I'm interested in, though, is us getting to the point where we can see development and acceleration and experimentation outside of the Bitcoin-based chain to really fulfill the vision that we were promised 10 years ago.
And that vision was an ecosystem blossoming with numerable different side chains where people could spool up permissionless second layers, do whatever they want with them,
And then if it failed, no big deal, the base chain keeps running on its own.
Now, as to whether or not these things should be monetary versus other, it's not that I think monetary versus non-monetary should be prioritized.
I think people should be free to experiment with both monetary other layers and non-monetary other layers, because, and this, I think, answers one of your questions, is, like, why do we care about these uses of block space?
It's all about thermodynamic security.
One thing that is overhanging that I think, once again, none of us really know the answer to, is how do we continue to assure that Bitcoin's thermodynamic security, the hash rate that keeps the blockchain immutable and difficult to rewrite, is going to continue working over the long run?
We get closer and closer to having to figure out this answer with every having, and we have not figured it out yet.
It looks like we might be headed in the right direction, but we have by no means gotten to a sustainable point of being able to pay miners more to offset the subsidy.
So, I would say that improving the monetary usage of Bitcoin is one of the main benefits, but it's not necessarily the only benefit, that we should look to explore the total design space and find the highest value use cases for block space.
So, it is a race against time.
I find that, you know, taking the wait-and-see approach, while obviously Bitcoin development should be careful and considered and methodical, and we should not, and I don't think it's even possible to do things spontaneously.
So, if we just keep dragging our feet and waiting and seeing, we could get to a point where it becomes problematic, and we don't have enough block space to go around, we don't have the tools that allow the developers to build these escape hatches and these secondary layers that don't come with a lot of trade-offs and centralization.
Thank you, Jameson.
Okay, so now we're going to have a little bit of, let's say, 15 minutes of back and forth, and I may throw in a few challenge questions to both of you.
So, Jimmy, I'm going to start with you.
I'm going to challenge you.
Do you have a threshold on which you would change your view?
I'll give you a few examples.
Now, you touched on something earlier about if there were to be some, you know, as you said, the timestamp bug.
It's a well-known bug that needs to be fixed, so I think everybody agrees we ought to fix that.
But as some other examples, what if, in the future, a shitcoin got, you know, more users, more market cap than Bitcoin?
Or what if, you know, there is a, like in 2017, there was a very high sustained fee market?
In those situations, you know, where would you consider, okay, actually, I need to rewind or I need to change my view on ossification?
I think I made my, you know, criteria on that pretty clear.
It needs to be imminent and necessary.
So, certain things are imminent.
So, high fees might be imminent, but I don't think that's necessary.
It means that a lot of people are using it, in fact.
And being necessary, something like the timestamp bug or, you know, something else, but if it's not imminent,
then I don't think it's something that we should consider, at least at that moment, until it becomes much more imminent.
And the reason why I say that is because we've seen in this space, we've had two softworks, and the last two softworks, segwit and taproot, significantly changed a lot of things.
And Jameson points out that we needed three different softworks for Lightning.
I assume he means check, lock, time, verify, check, sequence, verify, and segwit, in order to get that done.
But let's look at how taproot affected Lightning, because before you had all these ECDSA 2 of 2 signatures.
Now that Schnoor is introduced, now everything's kind of being changed again, right?
And this is one of my frustrations as an educator, actually, is that Lightning hasn't actually matured, because they're now going back to the drawing table, thinking about, okay, let's do 2 of 2 music for the funding transaction and all this other stuff.
So the entire system is not able to solidify because of the layer underneath that's changing.
And that's something that I think we didn't really consider that much when we were doing that last one.
In fact, I don't think I heard anybody talking about sort of the maturation of Lightning being, you know, stopped a little bit as a result of the softwork.
But those are the kinds of things that we need to be considering, because now there are layers on top.
And if you keep changing things at the bottom to make things a little more efficient or whatever, I mean, even think about, like, different types of addresses.
How many wallets have paid to taproot right now?
Very few.
And, like, the design space of what's possible right now is enormous.
To add to that, I think, is completely unnecessary at this point.
It's not something that we necessarily, that we need.
And there's a lot of other things.
Let things cook a little bit.
Let people do things.
And the more you switch things out from under them, the less chance they have of actually maturing.
And this affects layer 2s as well.
Okay.
So let me throw a challenge at Jameson now.
Is it possible that some of these protocol changes might be nice but not necessary, right?
So as we were talking about, now there's some debate about the numbers.
Is it 10 million or 100 million?
Or, as Jimmy was quoting, I think a Peter Todd paper, maybe even higher than that.
As an example, let's just take 100 million.
What if there were 100 million lightning banks in the world today?
We could argue that Bitcoin could still be money with 100 million lightning banks as opposed to, you know, one federal reserve and, let's say, 30,000 banks.
So how do you respond to that idea that some of these changes might be nice but not necessary?
Right.
I don't see any of these improvements that are currently being discussed as being necessary, at least for the short to medium term existence continuation of the system.
I see this as a question of pathfinding, of exploring the total design space of Bitcoin to maximize the value of the system.
You could even make a freedom argument of, we want to give people more freedom to encumber and transact their Bitcoins as they wish.
We wish to give developers more freedom to create other layers that don't require, you know, centralized intermediaries to manage pegs, for example.
Now, to be clear, we could ossify Bitcoin right now, and I think we would be fine probably for decades until we hit a critical issue.
I just gave a talk about quantum computing a few weeks ago, and that is something that may be on the horizon in a few decades.
But, you know, the issue here is that I think if we ossify Bitcoin, the nature of Bitcoin itself is going to evolve differently over the decades than if we have more options for developers to create other systems and functionality.
And I would agree with your statement that it will evolve differently.
I think it would go much more in a sort of like unstable direction rather than a stable one.
The point of ossification or having a good foundation is that the rest of the ecosystem can adjust to it and not have rules sort of change out under them.
And I think for the maturation of the entire ecosystem, you need stability and not things changing all the time.
That, like, I get that developers want more freedom, more efficiency, and all of that.
But, again, there's a tradeoff.
You might be calling it freedom for developers, but that means that there's less maturation of the technologies that are already in place, all the tools that are built on top of these things.
Not everyone has to go in now.
Like, since Taproot, every wallet has to, you know, add support for pay-to-Taproot addresses or maybe even implement them and so on.
That's not necessarily a bad thing, but it does sort of, like, make it so that they're uncertain as to what address format that they'll be using five years from now if you keep adding things.
You want predictability with money, and I can't emphasize this enough because this is what makes money good.
You want predictability.
You want stability.
You want to be able to do things that, you know, you want to be able to plan so you can build stuff.
So, for that reason, you know, I disagree that adding more features would be good.
Okay.
So, let me throw another challenge at Jameson, but we'll get Jimmy's response on this also.
So, in terms of, let's call it a stopping point.
So, let's say that could be the question or the challenge to you, Jameson.
People might say, well, is it, where exactly is your stopping point?
Are Covenant's okay, but a ZKP verifier is too far?
Or is GreatScript restoration okay, but simplicity is too far?
Do you have a stopping point, or is it just you're still, we don't have a stopping point?
So, I think that one thing that Jimmy and I and pretty much all Bitcoin developers agree upon is that ossification is inevitable.
It's kind of funny that we're debating ossification because I consider this to be essentially a law of physics of network protocols.
A network protocol, it tends to grow as it adopts until it essentially collapses under its own weight.
because there are too many individual actors to effectively coordinate changes of the protocol.
Now, one thing that I'll push back on with Jimmy of making too many changes and making it too complicated and difficult for developers to be building software in the system is that no one is forcing you to use the latest new technology.
You can still use an older, this is true at Casa, like we haven't added taproot support yet, we have ideas and visions for why we eventually want to do that, but you know, nothing has forced us to do so, and if you actually, if you look at the rate of Bitcoin improvement proposals since 2017, they've really dropped off a cliff.
So, like from that perspective, ossification is happening, soft forking is definitely slowing down, we've averaged less than one bit per month since 2017, and even the proposals that are coming down the pipeline generally do not come with any activation guidance or parameters, and why is that?
Why is that? It's because the developers have PTSD. They don't want to run the gauntlet of championing a proposal to change Bitcoin consensus.
So, there's an argument to be made that part of this ossification that is already happening has resulted in some brain drain, and we've lost a decent amount of talent from the developer protocol pool over the past few years as a result.
And I would say that, yeah, that might be true, and there are certainly developers that rage quit because their change doesn't get in or whatever.
But I think that's okay. Like, that's always been the case with Bitcoin. There have been many developers that went on to do altcoin projects, for example.
But consensus should be hard, and I agree with Jameson that there is sort of like a law of physics that is trending towards ossification or having this foundation more or less set.
And that's because we're a growing community, right? Like, the community back in 2017 was significantly smaller, and getting a consensus of a smaller group is a lot easier than getting a consensus of a larger group.
So, to that end, I do think it is inevitable, and in a sense, I suspect that this, you know, it's entirely possible that we don't have any sort of long-term, nice-to-have soft works that we did in the last two rounds with SegWit and Taproot.
It's entirely possible we don't get any more of those.
Now, Jimmy, let me try to challenge you. I've challenged Jameson a little bit. Let me try to push you a little bit.
What about a scenario where a shitcoin or an altcoin were to become, hypothetically, if it were to become more popular than Bitcoin, or hypothetically more users or, let's say, more transactions on-chain or higher value than Bitcoin, would you still hold to your, let's say, ossification or whatever we're calling it view, even in that scenario?
I mean, it depends on the shitcoin, right? Like, if it's a CBDC, and they have more market cap, then I'm not going to care very much.
That's a different story.
Say there's another altcoin, and, you know, it seems decentralized or something, and it has more market cap, then great.
I guess the market found something that's better than Bitcoin, and it's probably going to have to be at least, like, an order of magnitude better.
Like, do you attempt to change Bitcoin to do that?
I mean, I suppose that's maybe reasonable, but the fact that that shitcoin exists doesn't necessarily mean that, you know, it did so in a way that's, like, that the market finds legitimate or if it wasn't manipulated.
It would really depend on the circumstance and what features they bring.
So, if it is, like, a very critical feature that ends up making things an order of magnitude better, I think it would be worth considering.
But short of something like that, I really don't see a reason why that would affect Bitcoin in any way.
Yeah.
Jameson, one other question.
You mentioned in some of your talks, you mentioned thermodynamic security.
Now, I'm curious, is it possible that with a lot of software that it kind of gets over-optimized and then people start bringing up the security budget question that, you know,
I know, it became a meme, but in past cycles there was the meme of unfairly cheap.
Yes.
Is that a possibility with Bitcoin that maybe it becomes so efficient that there's not enough for the miners, per se?
Right.
I'll actually be talking about this extensively tomorrow on block space economics.
And, you know, there's actually a meme and essentially it is, you know, low on-chain fees result in inefficient uses of block space.
Inefficient uses of block space result in high on-chain fees.
High on-chain fees result in more efficient uses of block space.
And so there is a cyclical nature to that.
And I think that it's something that we should consider.
But it's going to be, I think, more difficult for us to continue making block space more efficient if we don't have some of the fundamental building blocks that I'm hearing developers would like.
Okay, fair enough.
Now, this is something that's come up in the discussion as well that soft forks used to be much more frequent, right?
Historically there were so many soft forks going through and now in recent years it's slowed down a lot.
So, question, open discussion.
Is that a good thing?
A bad thing is it just a reality we all have to accept that the bar is rising over time for a Bitcoin soft fork?
Well, I think it's funny.
If you go back to 2017, I probably don't remember what BIP it is.
It may have been involved with SegWit, but I remember being in Hong Kong and Peter Willa was telling us that, oh, we're changing our flagging mechanism for activating soft forks.
And the reason they did it is they wanted to be able to run more soft forks in parallel.
So as of today, we could theoretically be doing, I think, 32 soft forks in parallel.
So it's kind of funny to look back on that and then see what has happened as a result.
It was totally unnecessary.
But I do think it's basically, it's part of the physics of ossification.
Yeah, that was, I think, 29 in parallel because the top three bits have to be 001 or something like that.
And the idea back then was because we had so many block size proposals, right, BIP 102, 103.
And this was part of the explosion of BIPs was everyone had their own way of increasing block size and schedules for increasing it and why they should do it and different justifications.
So I think the idea back then was, okay, I support this particular BIP or this particular BIP, something like that.
Now, obviously, that didn't come to pass.
And now we've gone through, I think, four or five, I can't remember, different soft forks since then.
I think the solidification is a good thing.
And I've basically said this before, but it's allowed a lot of other layers to sort of solidify.
Again, if you change out too many things, like we did with Lightning, you know, it's hard for me to write a book on Lightning because now we're going to get Schnorr Music 2 for the payment transaction, funding transaction and so on.
And that makes the resources harder to write and create.
And I even have to, like, go update my older book, Programming Bitcoin, at some point, because there's so many new things that have come up.
It makes teaching harder.
It makes, you know, the act of getting in more difficult because as you increase the design space and so on.
I think solidifying at this point and allowing the second layers to do the innovation I think is perfectly fine.
And if it's a little more difficult, just suck it up.
Whatever.
Like, you know, people don't complain about IPv4 and say, oh, you know what, if only we had, you know, an extra couple of bytes to work with so we can have more addressable.
And they came up with IPv6 and no one uses it.
It's a lot better just to let everything else, you know, change and let the protocol be stable because, in a sense, that's what allows the ecosystem to grow.
So, last kind of open discussion, maybe take a minute each before we go to the final statement.
So, just if each of you could paint us the likely scenario that the Bitcoin ecosystem, let's say the economic nodes of Bitcoin, what is the likely scenario, in your view, that would cause the ecosystem to support and push through a soft fork?
Jameson, maybe we'll start with you.
Well, the most likely is going to be something where it appears to be a critical issue.
You know, whether that is because quantum computing is deemed to start to become a real threat or one of the known issues in the future where we may actually break consensus, you know, some sort of emergency that comes forward.
Other than that, I think it's going to need to be a very comprehensive and persuasive argument that we can improve the system for everyone.
I mean, I think that, in general, the way that Bitcoin governance and consensus works is that we're basically looking for changes that are not necessarily beneficial to everyone, but are not harmful to existing users, and hopefully beneficial to many, if not most, existing users.
Yeah, I think I agree with Jameson, that the most likely scenario is some sort of cryptographic primitive being broken and there needing to be some sort of emergency fix or something like that.
Short of that, it's hard for me to think of anything that will get consensus because, like I said, the consensus has grown significantly since 2017 and 2020.
Or 21, I forget when Taproot activated.
But those two times are, and it's only growing even more, so I have a hard time thinking that a soft fork will necessarily make it through.
The ecosystem's just a little too big for that to be smooth sailing, and even the last two incurred significant battles over, you know, in the case of Taproot, it was the activation mechanism, and in the case of SegWit, it was over which soft fork or hard fork to do.
So, yeah, I don't see that sort of thing playing out again, and, you know, Jameson mentioned that a lot of developers have PTSD.
I think whatever next battle is, it's going to pale in comparison to the last two.
Okay.
All right, well, we're coming to our time, so we've just got enough time for two minutes each.
We'll be strict here, so two minutes each on your closing statement.
Jimmy, two minutes.
Yeah, so Jameson earlier said that we were given this vision of sidechains that would be able to do all the things that altcoins did.
That was never really, for me, the vision that I subscribed to anyway.
There were certainly a lot of people that wanted to sort of discredit altcoins by saying, "Okay, we can do this on Bitcoin."
But what we found over the last 13 years is that they just run on scams, right?
They're not adding anything interesting or new.
They're just figuring out new ways to scam people.
And I don't think that's a direction that Bitcoin wants to go in.
Yeah, we can make it a digital archive or a place to hang digital art or something like that.
But its usage as money is far, far more important.
This is how most people use it, and that should be the priority.
We don't need Bitcoin to be everything for everyone.
Have it be money for the people that are using it, and that's it.
I don't see this need for Bitcoin to be something else.
And that's really the message that I want you to take away from me today, is that Bitcoin is first money and then technology.
All of the improvements that Jameson's talking about, all the different things that he wants to do, are really sort of from a technological angle.
It's not really from a monetary one.
And for money, it is better if it doesn't change.
It is better if it's stable.
It is better if you can plan with it.
And that's ultimately what I hope Bitcoin ends up being, is that we get a thriving ecosystem because we have a solid foundation.
And that's predictable, whose rules are known, and that hardware wallets aren't updating every software to support something new and so on.
Instead, it's just, you know, you can hold things for 20 years using the same hardware and not be worried about something happening.
All right.
Well, thank you, Jimmy.
Okay, Jameson, you've got two minutes.
Yeah, I think it's the very nature of money, capitalism, finance, and permissionless development that scams happen.
It's also just the result of experimentation, that many experiments will fail.
And so I want to see more experiments.
I want to see more experiments fail.
This is how we learn.
And we can learn from altcoins.
I would prefer that we learn from other layers that are tied to Bitcoin, so they're not siphoning value away that could be put into Bitcoin.
I think that we should strive to make changes to Bitcoin that will strengthen it and allow for more permissionless systems to be anchored to it.
I see ossification as complacency.
And yes, we all agree that Bitcoin is great, but I do not agree that Bitcoin has reached its pinnacle.
I think that complacency is one of the greatest threats to Bitcoin in the long term, and that we must not rest upon our laurels.
So technology is deflationary by nature, and Bitcoin's consensus rules should keep the system decentralized in as many aspects as possible.
This includes not only the node operators, but the users of block space.
Because, after all, if someone is priced out from using block space, they are most assuredly not going to run a full node.
So, as I see it, you're either optimistic that Bitcoin's game theory is sound and the network is anti-fragile, or you're pessimistic that Bitcoin's governance is brittle and the network itself is fragile.
I'll leave you with a quote from Napoleon Bonaparte:
"The torment of precautions often exceeds the dangers to be avoided."
The world is never going to stop evolving, and we have to ask ourselves:
Do we want Bitcoin to evolve with it, or do we want it to get left behind?
Thank you.
Fantastic.
And with that, that's all we've got time for.
Of course, everybody, please put your hands together for a great debate with Jimmy and Jameson.