Everything You Don't Understand About Bitcoin Development - MURCH (THE Bitcoin Podcast) - THE Bitcoin Podcast

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
So software doesn't really break.

(00:02):
If you had a piece of perfect software,
it would continue to work forever
if it were kept in the same environment.
The problem is in computers that the entire environment keeps
changing around the software that has been written.
So when a new chipset comes out, there'll
be new drivers for the chipset.
Operating systems get new features.

(00:23):
They might eventually deprecate some old interfaces,
create new interfaces, and so forth.
So a lot of the maintenance work is, for example,
just keeping up with the environment changes
around the piece of software and making sure
that it continues to work.
A couple of Bitcoin Core releases ago, for example,

(00:44):
we had there was a change in Mac OS.
And the new version of Mac OS couldn't start Bitcoin Core
anymore.
It would just crash immediately.
And it was just that they had some system call,
had a subtle change, and that led to some crash bug.
This is sort of the maintenance work

(01:05):
where I think it would just be a death sentence
to stop making changes to the software.
Because while we don't live on an island,
we don't live isolated and can keep the whole world staying
the same forever.
Greetings and salutations, my fellow plebs.

(01:30):
My name is Walker, and this is the Bitcoin Podcast.
The Bitcoin time chain is 860187, and the value of one Bitcoin
is still one Bitcoin.
Two days episode is Bitcoin Talk,
where I talk with my guest about Bitcoin
and whatever else comes up.
And today, that guest is Merch.
Merch is a computer scientist, engineer at ChainCode Labs,

(01:52):
co-host of BitDevs and the ChainCode Podcast,
and moderator of Bitcoin Stack Exchange,
answering literally thousands of questions about Bitcoin
over the years.
So he is the perfect person to talk to about what's
happening with Bitcoin development
and why it does or doesn't matter for you.
Merch and I cover a ton of different topics,

(02:13):
ranging from the Bitcoin development process,
the difference between changing Bitcoin
versus maintaining Bitcoin, talk about ossification
and what the hell that actually means.
Privacy trade-offs, address reuse, and potential improvements
like silent payments.
We also dig into quantum resistance, Bitcoin,
tail emissions, ZK rollups, covenants,

(02:35):
and layer two scalability solutions,
like lightning, eCash, Fedement, et cetera,
plus their trade-offs.
Merch also reviews the upcoming Bitcoin Core 28 release
and what it means for you.
Merch is an extremely knowledgeable dude,
and while this conversation does get a little bit technical
at times, I tried to pause and ask for clarification

(02:55):
or definitions as much as possible
so you can make sure that you understand
what we're talking about, even if you're not
a super technical person yourself.
This conversation should be a great introduction
for anybody who wants to better understand
how Bitcoin protocol development actually works.
So I think you're gonna love it.
Before we dive in, do me a favor and subscribe

(03:16):
to the Bitcoin podcast, wherever you are listening
or watching, and check out my sponsor, Bitbox,
in the show notes, or just go directly to bitbox.swiss
slash walker, and use the promo code walker
to get yourself 5% off the fully open source
Bitcoin-only Bitbox O2 hardware wallet
or anything else in their store.

(03:37):
You can also grab links to protect yourself
from sim swap attacks using a Fani and cloaked wireless.
I am a one man show, so when you use my partner links,
it genuinely helps me keep this show running
and I really appreciate it.
If you'd rather watch this show than listen,
head to the show notes for links to watch on YouTube,
Rumble, and on Nostervia, highlighter and flare.pub,
but if you're like me and you prefer to just listen

(03:59):
to your podcasts, I highly recommend you check out
fountain.fm.
Not only can you send Bitcoin to your favorite podcasters
to give value for value, but you can earn Bitcoin
just for listening to this fucking podcast.
Finally, if you are a Bitcoin-only company,
interested in sponsoring another fucking Bitcoin podcast,
hit me up on social media or through the website,
BitcoinPodcast.net, or shoot me an email.

(04:21):
It's hello at BitcoinPodcast.net.
Without further ado, let's get into this Bitcoin talk
with Merch.
["Mirch"]
Merch, welcome.
Thanks for coming on another fucking Bitcoin podcast.
It's a treat to have you here.

(04:42):
Thank you for having me.
We got talking in Nashville over some drinks,
and this came to be.
The first time we met, was it TabConf?
Like 2022?
Does that sound right?
That would sound right insofar that I've been at a lot of TabConf
lately.
I think I haven't missed one in a few years.

(05:03):
OK.
We haven't been able to go the last two years,
so it must have been 2022.
I liked that conference a lot.
A smaller group, incredibly high signal.
A lot of things that went over my head from a technical level,
but I felt like I was getting smarter during it,
so it was enjoyable.
Yeah, it's sort of a sweet spot.
So about 400 people, I think, is usually the crowd.

(05:26):
And it means that you have enough people there
to get good conversations going.
But a lot of devs, a bunch of power users,
maybe people that are invested in the space.
It's also coming up soon.
It's end of October, I think.
I'm going to talk about ClusterMemple there,
and we'll contribute to the Socratic Village.

(05:47):
So come on out, people.
Yeah, for anyone listening, if you haven't been to TabConf,
you don't have to be a developer to go.
It certainly is a developer-focused conference,
which is really good.
But you can certainly go there as a non-dev
and learn a heck of a lot, and have a very good time.
There was karaoke to be found, chess tournaments,

(06:10):
all manner of shenanigans to get into.
It was a well-run show.
Some of the participants in the karaoke really surprised me,
like coming up with their own lyrics,
surprisingly good singing voices.
Bitcoiners are full of surprises, I've found that.
I've also found that bitcoiners like karaoke a lot.

(06:31):
When we were in Nashville, it somehow ended up,
didn't plan on it, but just jumped in an Uber
and ended up at a karaoke bar called Santa's
before you know it.
I wasn't singing, I leave the singing to Carla.
But yeah, bitcoiners apparently congregate
around karaoke watering holes, which is nice.
There's probably some sort of insight to draw there.

(06:52):
I don't know what it is, though.
Maybe.
I certainly heard that a lot of people
went to Nashville, must have been a good.
It was a tiny little bar, too, so that makes it even better,
because you're just packed in there.
It was also cash only, which I like in a bar.
It would have been nice if it was like cash and bitcoin,
but maybe next time.

(07:13):
Someday, someday.
Yeah.
Merch, I'm glad to have you on here, because again,
we got talking in Nashville and just I
was picking your brain about Bitcoin development
and just we went a lot of different ways.
Some of it got a little foggy towards the end,
because I did have a lot of beers.
So what a perfect way to rekindle that conversation.

(07:35):
But I want to start out just for folks who may not
be familiar with you and what you do.
Can you just say who you are?
How did you get here today to be doing the quite wide variety
and depth of things that you're doing?
Right.
Yeah, I've been around the block once or twice.
I got interested in Bitcoin over 10 years ago

(07:55):
and have been contributing, especially to Bitcoin's tech
exchange early on.
It was sort of the first source of information that I found.
And really stuck with me.
And so I've been I've worked at Chain Code Labs in New York
City today.
We're a research lab, research and development center

(08:18):
that contributes to Bitcoin.
And I co-host BitDev's New York.
And we record an OPTECH recap from the OPTECH, Bitcoin OPTECH
newsletter, every week, mostly.
I think we're at like 90 episodes in now.
And yeah, so I do a bunch of education through, for example,

(08:42):
I proofread mastering Bitcoin.
Third edition last year, I have been a moderator on Stack
Exchange for 10 years.
I've written some about 2,000 posts there.
And yeah, just I think been working full time on Bitcoin
companies or open source projects for seven years now,

(09:02):
open source for almost four years now.
Before that, I was at Bitco for a few years.
Yeah, I have a keen interest in wallet and coin selection.
And through Stack Exchange, especially,
I'm exposed to all sorts of topic around the technicalities
of Bitcoin.
So I think I'm pretty well, broadly

(09:24):
versed on how Bitcoin works under the hood.
Yeah, and I think, first of all, that's
an incredible amount of basically pieces of education
gold out on Stack Exchange.
That's a lot.
And I know if folks have been on Bitcoin Stack Exchange,

(09:48):
they're probably familiar with you.
I'd hope so.
Yeah, I mean, I would hope so.
But I think that that's so fantastic.
That's why I've liked being able to pick your brain,
luckily in person a few times too.
Now we're separated by these damn screens,
but they can't keep us apart forever.
But I wanted a chance to talk to you today,

(10:09):
because I think for folks who are maybe either one
have not been around Bitcoin for a while.
Maybe they got in.
Myself, I didn't buy Bitcoin until 2020.
I'd heard about it much to my despair several times
before that, going back a number of years,

(10:30):
but thought it was magic internet nerd money and ignored it.
As I think most people do, and so I got what I deserved.
Same story, a little earlier.
Yeah, a little bit earlier.
But I think that's the case for a lot of people, right?
It's a very rare thing that somebody, the first time
they hear about Bitcoin, they dive in headfirst.
And to those people, I say, wow, kudos to you.

(10:51):
That's incredible that you got it.
That was not me.
That's not most people.
So if you're not that person, don't feel bad.
But for those people that are non-technical,
I think that Bitcoin and Bitcoin development
can seem like this ferre de bag, that nothing is getting in,
nothing is getting out.
They don't really understand.

(11:11):
And a lot of times, maybe they won't admit it.
They're too scared to ask questions
because they don't want to seem stupid.
And that's OK.
Luckily, I am fully OK with feeling or seeming stupid
and asking stupid questions if it helps other people
to understand things.
And I think you're a great person to ask these questions,
too, because you've answered probably all of them,
probably many times before, or referenced back

(11:33):
to previous answers.
Yeah, thanks.
Yeah, no.
And so I've got a number of things
I want to get into with you today.
And I know you had wanted to dive into also some of the Bitcoin
Core 28 release stuff, which I would love to get into as well.
If it's of interest, I mean, we'll
have to see where we get in this conversation.
But yeah, it's coming up.

(11:54):
It's on our mind.
Yeah, no, I definitely want to get into that.
I think a good place to start for people, though, is maybe,
I think that there is some myths.
Like let's talk about Bitcoin base layer right now,
layer one Bitcoin.
I think there's a lot of misconceptions about Bitcoin,
Bitcoin Core, Bitcoin Core maintainers.

(12:17):
There are various conspiracy theories
floated around things like that.
Can you talk about that a little bit?
Maybe just actually walk people through like,
how do changes happen in Bitcoin at a very high level?
OK, because people are worried about,
don't change Bitcoin, but there's also
a difference between, quote, changing Bitcoin

(12:38):
and maintaining Bitcoin.
And I think that that's a really important distinction to make.
Can you talk about that at kind of a high level?
Just to give people a picture of what does this actually
look like in terms of what's going on behind the scenes?
Right.
Yeah, I think I would even distinguish it further.
So there's changing the Bitcoin protocol.
There's making changes to Bitcoin implementations.

(13:01):
There's maintenance work.
There's a lot of changes that are just
changing how things work under the hood
without changing the behavior.
For example, in the upcoming 29 release,
it's not the one that comes out now, but the one after.
We just merged a new build system.
Nobody will ever notice unless they compile Bitcoin Core

(13:24):
from the source code, but it will hopefully make it
a lot more future proof to link up
with different operating systems and build systems.
And so yeah, I think the one that people are mostly worried
about are protocol changes, Bitcoin protocol.

(13:44):
Development is notoriously slow.
There is a lot of people that are sort of in a Mexican stand
off with each other there.
I think it's always the kernel of any such change
is a small, committed crowd.
Just some people that want to see a change in the world

(14:07):
and are making it happen.
But what is maybe more unique to Bitcoin
is that none such change will get
adopted against the adversity of the network.
So if someone wants to change Bitcoin in a way that
is detrimental to even a minority of the Bitcoin users,
they are probably going to be unsuccessful

(14:28):
because there's going to be vehement pushback.
So I think every change starts with an idea,
often that those ideas are discussed on mailing lists
or in-person meetings, conferences.
Someone just talks to you and you're like, hey, wait,
this would be brilliant or whatever.
And I think one of the critical steps then

(14:51):
is that there is some sort of attainable goal, something
that we can do so much better with this protocol change
to really bubble up this idea to a broad audience
to get a lot of buy-in across the ecosystem
so that people feel that we've achieved something

(15:13):
that we call rough consensus.
So rough consensus is a term that is lent from internet
protocol development.
The IETF has an RFC that defines how
to achieve rough consensus in a working group.
They have the huge advantage that these working groups actually
meet in person.
They hum, and the chair will decide whether or not

(15:34):
all of the open concerns have been sufficiently addressed,
not necessarily resolved but addressed,
and whether there seems to be a rough consensus
to go forward in that way.
We picked the hard way of doing this
by not all meeting in person.
It's really hard to get the entire Bitcoin community
into a room.

(15:54):
And so one of the big open questions
is how do you even determine whether something
has rough consensus?
And I guess the old adage goes, I know it when I see it.
But yeah, so basically, you have to have an idea.

(16:16):
You have to have a group of people, preferably,
that really wants to work on this idea.
Overengineer it, really test out what the implications are,
what the second order effects are, advocate for it,
maybe also advertise it to the Bitcoin community
in a way that the Bitcoin community says,

(16:39):
we absolutely should do this.
And then probably after some time,
you would achieve a protocol update.
The other ones are easier, like changing an implementation.
Well, we do that all the time when, I don't know,
we fix a small off by one error, or we say, hey,
this would be so much easier if this worked slightly different.

(17:01):
This function call should use the new feature
of the programming language that just came out.
Maybe to put that in context, so software doesn't really
break.
If you had a piece of perfect software,
it would continue to work forever if it
were kept in the same environment.

(17:22):
The problem is in computers that the entire environment
keeps changing around the software that has been written.
So when a new chipset comes out, there
will be new drivers for the chipset.
Operating systems get new features.
They might eventually deprecate some old interfaces,
create new interfaces, and so forth.

(17:44):
So a lot of the maintenance work is, for example,
just keeping up with the environment changes
around the piece of software and making sure
that it continues to work.
A couple of Bitcoin Core releases ago, for example,
we had there was a change in Mac OS.
And the new version of Mac OS couldn't start Bitcoin Core
anymore.

(18:04):
It would just crash immediately.
And it was just that they had some system call,
had a subtle change, and that led to some crash bug.
So that was discovered during the release process,
and it was fixed before or right after release
before really the version was adopted.

(18:25):
But it's, yeah, this is sort of the maintenance work
where I think it would just be a death sentence to stop
making changes to the software.
Because while we don't live on an island,
we don't live isolated and can keep the whole world staying
the same forever.

(18:46):
I think that that's a really great way of framing it
in terms of even if the software is absolutely perfect,
theoretically perfect, the environment still changes.
And you don't have control over that environment
and all the externalities that it presents.
Thus, some changes are going to be
required in order to keep things functioning

(19:07):
for the vast majority of users.
That would not be good if Mac OS users were unable to run
core, right?
Exactly.
And I think that some people, especially
if they're not familiar with software development,
haven't even worked tangentially with a software company.
They think changing Bitcoin, like, oh, well, why don't you just

(19:31):
stop fiddling with it?
It's fine the way it is.
They're missing the context of when we talk about,
need to separate, quote, changing Bitcoin.
Like, we're not talking about hard forks here.
We're not talking about soft forks even.
We're just talking about maintaining the code
so that it is as widely usable as possible
without things breaking for users, which then people say,

(19:53):
when something does break, that's when people get angry.
It's like, well, why didn't you see this coming?
It's like, well, you told us just to leave it alone.
So thank you for that context.
Because again, I want to make that very clear for people
that we need to separate the conversation of, quote,
changing Bitcoin with maintaining Bitcoin.
Those are two different things and serve different purposes.

(20:17):
And just kind of on top of that, this idea of ossification
is talked about a lot.
And tell me what you think of this.
But it seems to me that ossification
is less of a discrete destination point.
It is more of a journey, a process that sort of happens

(20:40):
naturally.
Like, it's not like people decide, OK, everyone,
today we'll ossify.
It's just that it sort of happens, right?
I mean, am I missing something there?
Is there more nuance that you can provide?
Yeah, I think, well, there's on the one hand
that some people have different understanding of what

(21:00):
to term ossification actually means.
There's the people that say, just stop fiddling with the software
altogether.
And they call that ossification.
There's people that use it as a way of stepping on the break
regarding protocol changes.
And they're concerned that their use cases may not

(21:21):
continue to work in the future.
I think we could probably be a little faster or a little slower
in protocol development.
And things would continue.
I don't think that we want to stop completely.
People predict that a lot more users are going to be interested

(21:44):
in Bitcoin in the future.
And if they want that future to happen,
I don't think that what we have right now
is going to be able to facilitate that sort of adoption.
And on the one hand, so for example,
we got a new set of shareholders in this process

(22:06):
with the ETFs.
I think they might be related to the sailor camp, where
they may be most interested in the number go up use case
of Bitcoin.
And we just have a bunch of people.
A lot of people are interested in multiple different aspects
of Bitcoin.
And there is many of them.

(22:26):
There is the digital cash aspect, the ability
to send payments all around the globe.
There's the number go up savings technology.
There is a privacy technology, of course.
And so many are interested in multiple of these,
but to varying degrees.
And with the ETFs now, we have yet another part

(22:51):
of the community that has different interests,
potentially eventually a lot of money
to throw behind some ideas or development.
By the way, I think it would be absolutely brilliant
if they would hire some Bitcoin developers that
work on Bitcoin, hopefully with some sort of self-directed
direction.

(23:11):
But if they make money off of Bitcoin,
they should also hopefully contribute to Bitcoin
development down the road.
But hopefully they don't dominate Bitcoin development,
because no one use case should dominate Bitcoin development.
It's sort of, well, we have to find something

(23:32):
that works for most or all, hopefully.
And what was your question again?
No, no, no, no.
Just around that ossification as a process, a journey,
or just this discrete destination,
or I should say maybe instead of a destination,
a conscious choice at a moment in time.

(23:54):
Yeah, well, go ahead on that.
And then I have a couple of follow-ups for you just
on what you just said as well.
I think that ossification will happen naturally
by the ecosystem becoming more complex
and getting more participants that
have partially contrary interests.
And I would there interpret ossification

(24:18):
as just it getting harder to make changes,
to evolve the ecosystem, because people
are more invested in things working as they are already.
Every system sort of prevents changes to itself.
The stronger the system, the harder it becomes to change.
I don't think that we actually want to go and say, OK,

(24:38):
that's it.
We have everything we'll ever need.
Because that just seems a little naive to me.
Who knows what the world will look like in 50 years,
or 100 years?
I sincerely doubt that a Bitcoin protocol that
was invented in the early 2000s would
be the system of choice in 2100.

(25:02):
And as well, I became a BIP editor in April.
And so I've been going a lot through the BIP repository,
which is the Bitcoin improvement proposals that
deal with mostly ideas around protocol changes
or protocols or standards for interact when

(25:31):
two pieces of software interact.
So for example, you can use backups from one wallet
and another wallet.
That's a good use case for a BIP.
And if you look, for example, at the BIP process from,
I think it's eight years old, so 2016,
obviously, people that then contributed to this document

(25:52):
were extremely concerned with soft forks and hard forks.
Because that was the topic everybody talked about,
oh, should we do a block size increase?
How should we do a block size increase?
Should we do that?
All sorts of soft forks proposals
floated around forward blocks, weak blocks, whatever.
And the whole BIP process document

(26:14):
is sort of cast in that light.
And even just eight years later, this is not
our main concern.
Soft forks are coming up as a topic right now, again,
a little bit.
But for many years in between, that was certainly not
the thing that was most on our mind.
It was maybe the fight about governance between users,

(26:35):
developers, and miners, who sort of has a leading role
or how do they contribute to governance.
Maybe in the last couple of years,
privacy has been more of a topic where people had concerns.
So all of these things, the software, the processes,
they have to adapt to the challenges of the day.

(26:57):
So if we just stop developing it,
I think it'll just age away and not
be interesting to people anymore.
So we have to keep abreast of what's
going on in the world around us and adapt to it.
So a couple of things just on, and I appreciate
the explanation, a couple of things
on your previous points regarding,

(27:19):
so everything has trade-offs, right?
Oh, yeah.
We want to, like privacy, for example,
there's a lot of trade-offs that we as individuals make
every day.
We trade our privacy for convenience quite often.
Some of us are conscious of it.
Some of us are not.
I think also with Bitcoin, at least the way that I see it,

(27:39):
is Bitcoin was fundamentally pseudonymous or anonymous.
You can debate which one in terms of how it is actually built.
The privacy concerns that exist today
are really a function of the on-ramps to Bitcoin.
Nobody was getting KYC'd when there weren't exchanges

(28:00):
for Bitcoin.
Nobody was getting KYC'd when exchanges weren't
KYC'ing people for Bitcoin.
There was no real world, quote, identity tied to your UTXO
set before KYC came into effect.
So that's an externality.
Again, if we want to talk about the changing world around us,
that's not a technical externality, per se,

(28:21):
but a legal or social externality.
So that's something where it's like,
you're not going to solve for KYC at the, or maybe you can,
but should you solve for KYC issues at the Bitcoin base
layer?
Or can some of those privacy concerns
be better addressed with solutions that are on layer 2s

(28:44):
or 3s or however many layers you want to go?
Lightning is better for privacy in that regard,
just because it's a bit of a slush fund, liquid even.
LBTC goes into that federation, and it's like,
unless the federation is required to hand that over,
it's kind of a black box. FETI is incredibly private
within that federation.

(29:05):
Not even the guardians have the ability to go in there
and see who's doing what.
So you have the ability to increase your privacy,
move along that scale on these other layers.
And you can do that as well.
Like if you're earning Bitcoin, for example,
and getting paid to a wallet that you just spun up,
that nobody knows about, and you are a NIMM online,
and you got paid for doing some design work, let's say,

(29:28):
there is no way anybody can know who that is attached to.
I mean, without some intense forensic digging,
but if you're a NIMM online and getting paid to a fresh wallet,
one can fairly safely assume that you're using a VPN,
you're doing other things that would also mask
any potential inroads to your personal real-world life.
So my point here being that,

(29:50):
I think that a lot of these conversations around,
we need to increase Bitcoin base layer privacy,
it's trying to hit a moving target
because there are so many of these externalities
from the legal world.
And first, I'll just pause there
to fair or unfair assessment?

(30:10):
I think it's a constant fight.
Maybe, I assume you, like I remember in the early 2000s,
we would wait an hour to download an MP3 or whatever.
And today, everybody is streaming gigabytes of movies
over the internet.
I think that Bitcoin is growing in a similar way

(30:32):
in that it keeps being a moving target.
We keep shooting for a higher goal
because we've solved other issues.
Privacy, I think, is one of those things
that are very hard to fundamentally improve
because a lot of people, well, as you said,
it usually contradicts convenience

(30:53):
and people care different varying amounts about privacy.
So for example, address reuse is still incredibly rampant
on the network, even though it's known to be one
of the biggest privacy issues.
It's such an easy thing to fix too.

(31:14):
Yeah, so absolutely fair.
For anyone listening who's like,
what does address reuse mean and am I doing it right now?
Can you just give the TLDR on that
so folks who are listening can say,
oh, great, I don't need to do this again.
I was doing that before.
Right, so Bitcoin addresses are reusable indefinitely.

(31:34):
Addresses don't exist at the protocol layer either.
It's really a short hand for an output script
that locks up your coins when you receive them
and you can reuse them.
However, when you do, those outputs are very clearly
controlled by the same entity because the same key,

(31:55):
usually if it's a single-sig setup,
the same key can spend them.
So by reusing the same address,
you are heavily hinting at funds being owned
by the same entity and there is some users,
especially exchanges, tend to give one deposit address
per user and then users that don't explicitly search

(32:18):
for getting new deposit addresses each time.
They just keep seeing that same deposit address
and paying to it or even in private wallets,
some people just are like, oh, this is my address
and there are slight benefits to that.
Like you'll see the address and you're like,
oh yeah, this is my address,
so it's easy for you to check whether you gave out

(32:39):
the right thing.
It's terrible for privacy and not only your own privacy,
also the privacy of any counterparty
because anyone that sends to you knows
that all of these other payments have also gone to you
and even if they don't know who the sender was
in the respective transaction,
they know just to ask you for that information

(33:02):
because you'll very likely be able to tell them
and it has a clustering effect on chain analytics.
So the easy fix is to just use them more
as an invoice identifier rather than an address.
It's a little unfortunate that the term address
became the moniker for these payment identifiers.

(33:25):
And so yeah, the best practice would be
to use a new address or to generate a new payment identifier
for each payment, giving it out, using it only a single time.
And that way, at least all of your funds

(33:45):
are held in separate UTXOs.
And if you don't spend them exactly together
in a transaction, you're not hinting at them
being owned by the same entity.
And even if you're spending them in the same transaction,
it could be a transaction created by multiple users together.
So there's a little bit of wiggle room.
However, if you're spending from the same script

(34:06):
multiple times, there's very little wiggle room.
Well, right.
And that's the thing that while it's,
I'm sure it was maybe more manual back in the day,
but since I've been around wallets make this very easy to do.
Like you can just, okay, a lot of them will have a list of,
okay, here's, they'll generate however many addresses for you.
Okay, just use a different one for each time.

(34:28):
Like it's something that folks should absolutely do
because it is not difficult.
You do not need to be technical to do it.
I promise whatever wallet you're using
has this built into their UI.
It is a simple thing.
So just wanted to point that out for folks
because I think this is a really practical and easy way
to at least make it slightly more private.
Again, moving along that spectrum.

(34:52):
There's one thing that I'm very excited about in this context.
So there's been a lot of work on silent payments recently.
And the idea here is that you do have actually
for the first time a Bitcoin address
in the sense that you have a silent payments address.
And when people use that to send you a payment

(35:12):
under the hood, it always uses a new Bitcoin address.
But it derives that from the silent payment address
in a reusable fashion.
So you can post that on your Twitter profile
or in your podcast description.
And every time people pay to you,
it still looks like a completely distinct UTXO.

(35:35):
That's actually incredibly slick.
And again, like that's just a better user experience, right?
It's more private by default
without the user needing to do any extra effort.
Right, exactly.
And so one of the other things I wanted to bring up
and then we can jump off to some other topics,
but around like the sailor camp, let's say that,

(35:59):
you mentioned earlier about don't mess with this.
And I think on the one hand, let me say it this way,
I think that sailor understands perfectly well
what ossification and software means.
Because he has run a software company for 30 some years.

(36:21):
I think he understands it very well.
I think he also, he is very good at distilling things down
to simple terms that non-technical folks can understand.
And I believe that's what he's doing here.
Like I would, maybe I'll, don't think I can tell you.
I'm not trying to put words in the mouth or anything,

(36:42):
but just as an example for the way we associate
with the number go up technology.
And it is a fair example.
If I had to guess and I'd love to ask him this,
I would guess that if you said,
do you, when you say that that question change,
what are you talking about specifically?
Are we talking about not increasing the block size,
not implementing tail emissions?

(37:03):
Those would, I would guess probably be his two big things
to maintain scarcity.
But I'm guessing that if you asked him,
do you believe that Bitcoin should still be maintained
on an ongoing basis?
He would say, yes, of course,
because it's software, it needs to be maintained.
So I think, but so just hopefully,
maybe I'm wrong, maybe I'm, you know, this is me assuming
I can make an ass of you and me here,

(37:25):
but this is just my assumption.
But so, you know, another thing I wanted to kind of,
I guess, dig into is, you know,
this idea that Bitcoin doesn't have like a roadmap
in the same sense that, for example, Ethereum does,
where they've got the merge and the purge and the splurge

(37:47):
and the scourge and whatever other urge words that they have.
I don't know if they have, maybe there's an urge
just by itself too, I'm not sure, Vitalik's urge.
But I think that that's kind of maybe confusing for people.
It's like, well, what happens next?
And, you know, maybe this is a good time
to kind of talk about what's happening next
for Bitcoin specifically in this next release.

(38:10):
And just kind of dig into that.
Cause I think a lot of people, again,
if they're non-technical, if they're, or they're newer
and they're still just kind of going down this rabbit hole,
figuring out how stuff works,
they may not really know like what changes are happening,
what changes are going to happen on that kind of the short term.
And then what does that actually mean for them?
Like how does that improve their experience with Bitcoin?

(38:32):
Can we talk, I think now's a,
now's maybe a perfect time to dig into,
to dig into 28 a little bit.
Sure. Maybe let me answer your first,
just which was how do changes happen?
Yeah. Okay.
So, Bitcoin Core, for example,

(38:53):
has one implementation of the Bitcoin protocol
does not have a hierarchy, right?
There's no team lead, there's no benevolent dictator for life.
There is not even working groups or anything
where you might have a working group leader
or project manager or anything.
It's a loosely associated group of people

(39:13):
that happen to care to work on Bitcoin Core.
And a few of those people
have the title of maintainer,
which means that they have right access to the repository.
What they do is they assess
whether something has had sufficient review
and is supported by the contributors.

(39:36):
And once this is achieved, they will merge it.
They don't decide what goes into Bitcoin Core.
They don't set goals for the next release cycle.
They don't hog features or anything like that.
They're basically janitors.
They look, oh, is this ready to go?

(39:58):
Let me rubber stamp it and wrap the box and here it is.
And sure, they also do a lot of review.
They tend to be people that have been around the project
for a long time, that are trusted.
They do have some responsibilities,
like facilitating the release process.

(40:18):
But there are people that facilitate the process
rather than lead or decide the content of the process.
So what is in Bitcoin Core?
We don't know what is gonna be in the next release yet.
We'll find that out in the next release cycle
as people work on the things that they are scratching
their own itches, they're working on the things
that they deem important or interesting.

(40:42):
And whatever is done by the feature freeze
is in the next release.
And then if we do a release cycle, we branch off,
we fix a few bugs, whatever we discover
during the release process.
So that's the release candidates.
And once the release candidate has no known issues,

(41:03):
it gets tagged and shipped.
That's how a release gets together.
So it's really just someone decided to work on something,
found a few people that felt that it was important enough
to review and contribute to,
and they got it done before the release.
And that's in the Bitcoin Core release.
So if you want a feature in Bitcoin Core,

(41:24):
be the change you want to see in the world.
I love it.
I think people too, it's like,
even folks within Bitcoin sometimes adopt the trope
of like the Elizabeth Warren types who call
Bitcoin developers like shadowy super coders.
But really this is, there's nothing shadowy at all.

(41:46):
I mean we're working in the public.
Yeah, as public as you could get,
like compare that to how the Federal Reserve
of the United States makes decisions behind closed doors
and lets you know like a month later
what their meeting notes were redacted, we can be sure.
But like it is all in public.
Like there's nothing shadowy about it.
You can come to our repository, read every single issue,

(42:07):
every single pull request that,
which is the proposals at what to change in the code base.
You can read the review comments.
You can come to our IRC meetings on Thursday,
10 a.m. New York time.
You can read the mailing list, developing Bitcoin.
I mean you can't come to our office every day
and listen to what we talk about during the day.

(42:28):
But I mean most of our collaborators live on the internet.
So we eventually put the stuff out there for them to read
and then you can read it too.
Cause it's not in a secret channel or anything.
It's right in our public IRC channel, in our code base.
Sorry, repository.
So yeah, we're working in public.
That itself is a strange experience at times

(42:51):
because really if someone cares enough,
they can just go and look what you did the last year
and have opinions on that.
The great thing about Bitcoin is it doesn't matter
if you're a highly technical developer
or a tech illiterate boomer.
You can still keep your Bitcoin safe for the long haul

(43:11):
when you have an easy to use hardware wallet
like the Bitbox 02.
Go to bitbox.swiss slash walker
and use the promo code walker for 5% off
the fully open source Bitcoin only
Bitbox 02 hardware wallet.
Then get your Bitcoin off the exchange
and into your own self-custody.

(43:31):
The Bitbox team is honestly awesome.
I'm super proud to be working with them
and to have them as a long time sponsor.
And they build easy to use, secure open source solutions
to keep your Bitcoin safe.
Not only is the Bitcoin in your Bitbox safe
from say government confiscation,
but Bitbox is one of the only two wallets
to actually address the dark skippy vulnerability as well.

(43:53):
So you're in luck if you have one.
And if you don't, you can pick one up.
I just had Staticus from Bitbox on the show recently.
So check out that episode
if you want to learn more about Bitbox
and take a deep dive into self-custody best practices.
Plus, and I cannot emphasize this part enough,
the Bitbox 02 is truly easy as hell to use.
And that's whether you are brand new to Bitcoin.

(44:15):
It's your very first time setting up a hardware wallet
or you are a well-seasoned psychopath.
It is Bitcoin only.
And again, it is fully open source.
You can head to their GitHub and verify that for yourself.
There's no need to trust me or to trust Bitbox.
When you go to bitbox.swiss slash walker
and use the promo code Walker,

(44:37):
not only do you get 5% off,
but you also help support this fucking podcast.
So thank you.
Good or bad opinions, I'm sure.
Yeah.
I appreciate that primer for people
because again, for non-technical folks,
the technical folks already understand this.
And for any technical folks listening

(44:57):
who are like, get on with it already, I'm sorry.
But I think that this is not something
that the more technical people need to understand,
they already get how this works.
But for people who are putting more and more of their wealth,
their time and their energy saving in Bitcoin,
I think it's really important for them to understand
this is all being done in the public.
It's also being done by people who really, really care

(45:19):
about this and that's such an important thing like this.
You know, these people aren't hired.
There's some grants and things that go around, right?
And hopefully more of those types of grants
that people can still do this development work
without strings attached,
but they're doing it because they really care about Bitcoin.

(45:39):
And that's a beautiful thing to me.
It's just an interesting thing to work on
for many of us.
Yep.
Yeah.
Well, so let's dive into the release 28 a little bit,
just to give people an idea of what's coming here
because I'm guessing that many folks, myself included,
don't know.
Right.

(46:01):
I think one thing that people have maybe heard
a little bit about was that Testnet 3,
which has been around for almost a decade,
has had these block storms
where blocks would move extremely quickly
because people were fiddling with the difficulty.
So there's going to be support for a new Testnet
in this release.

(46:21):
Testnet 4 is launched in April.
There's already a few faucets and so forth.
And most notably, the issue that caused the block storms
is fixed in this release.
And so in this release, it only has support for Testnet 4,
but the default is still Testnet 3.
And but probably most people that have infrastructure

(46:45):
on Testnet will want to look at Testnet 4.
And so for example, industry business to business companies,
they often have test wallets on Testnet
where you can get some test coins and test your integration
before you use it on Mainnet.
So Testnet 4 is coming out with this release.

(47:07):
There is an initial, I assume, UGXO release in this one.
So there will be a commitment to the BlockHeight 840,000
or rather the UGXO set at Block 840,000,
which was having in April, of course.
And so if you download the Concord,

(47:27):
you can also download this UGXO set snapshot
and then use Assume UGXO to just sync up from April
to the current chain tip.
And then in the background, sync the rest
and catch up to April this year again.
And then it puts it all together.
So you still sync the whole history,
but you start, you do a jumpstart.

(47:49):
And the nice thing is, of course,
we have a cryptographic commitment in the release.
So if you verify that you built the release
from the source code or get it through a package manager
on your operating system or some other way
that you can trust that you're running
a legit version of Bitcoin Core,

(48:10):
you'll be able to have a functioning wallet much quicker,
but still get the full validation eventually
after a couple of days, maybe depending on the speed of you.
A few hours to a few days, depending on your hardware.
Yeah, so far so good, more questions.
So far so good.
Okay, cool.
No, no, no, keep on rolling.

(48:31):
There's a couple of things that concern the mempool.
Of course, it is the waiting room
for unconfirmed transactions.
We generally propagate transactions
best effort.
Like there's no guarantee that you'll see
every unconfirmed transaction,

(48:52):
but on best effort basis, we're forward everything.
And now, so far we have not been able to do package relay
in the sense that we can't send a set of transactions
that belong together as a group.
We could only propagate transactions
in single transactions by themselves.
And that led to some issues.

(49:14):
For example, last week, or maybe a couple of weeks ago,
by now, Babylon had the staking on chain
and suddenly for six blocks or so,
fee rates went to 1,000 sets per VBite.
And then this week, they had the unbonding
for the 400 or so Bitcoin that overpaid
their target of 1,000 Bitcoin stake.

(49:37):
And these were forced to be at 200 sets per VBite,
these transactions.
And then the mempool, or the block minimum fee rate,
went to 200.
So at these points, we saw some issues
where lightning nodes would talk to each other
and be like, hey, I would like to increase the fee rate

(49:59):
of the commitment transaction,
our channel state on the lightning network.
And the other node goes like, are you crazy?
That's really high.
I'll close the channel.
And so there's a bit of a consensus mechanism
between two lightning channel partners.
They have to agree on the commitment transaction.
And if they disagree, usually they just choose

(50:19):
to broadcast the old version.
So a bunch of lightning channels closed due to disagreements
between lightning nodes of different implementations.
Or just different fee estimations,
because they couldn't agree on what an appropriate fee rate
would be for the commitment transaction.
Okay, that's hopefully gonna get fixed

(50:42):
with one of the new features that are shipping in 28
down the road once it's adopted more across the network.
So in 28, it will be possible to opportunistically propagate
one parent, one child packages.
So packages of two transactions
where you have a low fee rate parent
and a high fee rate child,

(51:03):
which uses the child pays for parent mechanism.
So miners want to include the juicy child,
but it is only valid after the parent creates the output
that is spent by the child.
So they're forced to include the parent before the child
to get the fee of the child, right?
So what happened so far would be, for example,

(51:24):
the lightning channel was committed to a specific fee rate
the last time the nodes agreed.
And if that fee rate is now drastically below
what fits in the mempool,
because when too many transactions are added,
submitted to the mempool,
eventually we kick out the ones with the lowest fee rates.

(51:44):
So you might not be able to broadcast your commitment
transaction to the mempool.
And then even when you try to bump it,
the child is also invalid because the parent is missing.
You can't spend an output that isn't there.
And then both of those transactions would just not exist
on the network and couldn't get included in our blog.

(52:06):
So what happens now is if we get the child first,
we don't know what fee rate it has at all
because we don't know the input.
So we don't know how much money came in on the input side,
because that information lives in the parent transaction.
So we put it in our orphanage, right?
Child without parent.
Which is a data structure.

(52:29):
So when we now get a broadcast of the parent transaction,
we evaluate it.
Oh, the fee rate is too low.
It doesn't fit in our mempool.
And we used to just throw it away at that point
because we don't want it.
Now we go and check, hey, do we have a child in the orphanage
that belongs with this parent?
And we try to do as a group together.

(52:51):
Now if the child pays enough to get the parent into the mempool,
they both go in together.
And that is a non-rebust but somewhat working way
how we can get rid of this whole issue
where channels close suddenly because the fee spike.
Because if the commitment transaction is low,
you can just attach a high fee rate child,

(53:12):
a higher fee rate child than you would have otherwise,
and the two will propagate on the network together.
So hopefully we will not see all these unnecessary channel closures
down the road.
Like when 28 is out and it's somewhat broadly adopted across the network,
then the lightning implementations have to change
how they think about the channel closing process and so forth.

(53:34):
So hopefully maybe a year or so, but this problem is going to go away.
So if you had channels close unexpectedly in the last week or so,
this was why?
Yes.
Oh, well, okay.
You might have heard about the channels closing, but yeah, that's the reason why.
I had some channels closing, so this explains things.

(53:55):
Hopefully that's just not going to be an issue in about a year.
Okay.
Wow, for some reason this gave me the mental image
of a parent loses their kid at the supermarket
and the supermarket attendant has the kid up at the front.
They're like, does anyone own this child?
For some reason that came into my head is the image there,

(54:16):
but it's a child made of Bitcoin.
I digress.
And a child is raised to parent as poor.
Right, right.
The child is paying for the parent.
Right.
Yeah.
Okay, cool.
So yeah, this has been, so my colleague is on me.
Oh, sorry.
Good.

(54:37):
Just an alarm.
Okay.
So my colleague, Gloria is now, she's been working on package relay for a few years.
And there's a sort of one of the first parts that will actually change the user
experience that's finally shipping.
And a lot of that is hopefully going to come in the next couple of releases with
cluster mempool, which fundamentally changes how we think about groups of

(55:03):
transactions and confirmed groups of transactions.
Hopefully not in a way that changes the user experience of people creating
transaction much, but it'll make it way easier to do package relay with more
transactions.
And then hopefully the outcomes will be more expected and stupid issues like

(55:25):
channels just randomly closing won't happen like that anymore.
So that's again, in terms of like, what does this mean for the average non-
technical user?
That's actually like a very real thing.
Like you hopefully yes, channels shutting down for no reason where you're trying
to figure out what the hell is going on.
Like this will just be something you don't have to worry about.
Hopefully again, well, it'll take some time.

(55:47):
I don't want to overhype it.
So the strips in 28, which is end of September, then we need probably 10,
20% of the nodes on the network to run this so that the transactions somewhat
reliably propagate and then the lightning implementations have to change how they
negotiate commitment transactions.

(56:09):
But that's, I think they can unilaterally just not tell that they want to increase
fee rates.
So hopefully that'll be somewhat quick to adopt.
But probably, I'm saying probably a year or so, so as not to overpromise.
It's not going to happen the day after.
Yeah.

(56:30):
Yeah.
So there's a closely related change called track transactions.
This was described as BIP 431.
And this is basically a opt-in restriction on your transactions topology.
It can either have one parent or have one child and not exceed a certain weight.

(56:51):
But then in that case, the parent can have a fee of zero.
And now with what we just discussed with the one parent, one child opportunistic
package relay, we can actually have commitment transactions that pay zero fees.
So you will not need a channel reserve, for example, on your lightning channel
anymore.
And even if your commitment transaction pays zero fees, it'll be able to get

(57:14):
into the mempool.
That's kind of wild then.
Yes.
Right?
So wait, maybe if we can dig into that one a little bit deeper.
So I'm opening a new channel.
And I'm actually not needing to pay anything at the start.

(57:36):
It's only once that is given.
Or like, yeah, can you break that down a little bit?
So yeah.
When you have a channel right now, you do have to make a transaction at first
to create the output, right?
A lightning channel on chain looks like a transaction output.
It is just owned by two people together, both of the channel participants.

(58:01):
And so far, most commonly, the channel is opened by one side.
So they pay for the transaction and they negotiate with the other party,
hey, give me something so I can get my money back in case this fails.
And then they send money to this collaboratively owned UTXO.

(58:22):
And all of the funds are on one side.
And after that, the money in the channel can move back and forth on chain.
Nothing ever happens.
All of that is just negotiating how this channel will get paid out eventually.
And to guarantee that you will be able to pay for the unilateral channel closing,

(58:43):
the commitment transaction, there's a channel reserve.
So you actually do not get to use all of the money that you put in a channel.
But there's like, I think it's a percent or 2% that is restricted from being used
once the other side has gotten a little bit.
You can't send all of your money.
Every side needs to keep a little bit.

(59:04):
And this is A, to be able to pay for the commitment transaction and B,
so if they cheat that they always have to lose something, right?
If they have a past state where, or if they get to a state where they own zero of the channel,
they wouldn't have a financial disincentive, not to cheat, right?
So with the commitment transaction, at least this first concern goes away where

(59:30):
you don't have to pay for the commitment, sorry, with track transactions,
TRUC, which stands for topologically restricted until confirmation.
The parent transaction can have a fee rate of zero, so you can have a channel
that has a zero fee rate and pay fully with the child for the confirmation.

(59:51):
So you bring your own fees to close the channel, which means you can decide
when you want to close, how much fees you want to pay,
and you don't have to have a reserve in the channel itself in order to be able to send the transaction.
You still want probably the reserve actually because you want to be able to
punish the other side reliably for the people that like Ellen penalty.

(01:00:16):
Maybe one day we'll get Ellen symmetry, but we can get into that on another podcast.
That sounds good. I appreciate you doing that.
That's up any prevout.
So again, I think these are, maybe for folks who aren't running a lightning node,
this may sound a little bit Greek to them, but for folks that are,

(01:00:40):
I think this is like very again, like experience improving stuff.
Is there anything else coming in the release that is of note?
Yeah, one last that belongs to this family, which has pay to anchor outputs
become standard in Bitcoin Core 28, and there is an improvement of estimate smart fee.

(01:01:04):
So the fee rate estimation in Bitcoin Core is extremely conservative as is often espoused on Twitter.
What you're actually saying is when you say, I want to target a two block target,
I want to be in the next two blocks with a 95% reliability.
So it tends to be extremely conservative.

(01:01:26):
My recommendation is if you're relying on Bitcoin Core's fee estimation,
pick a higher block target, you probably don't want needed in the next two blocks.
Probably you're fine if you get it in the next hour.
So go for six or maybe even 12 blocks.
Those tend to not shoot up as brutally.
And by default, Bitcoin Core will now run in economical mode instead of conservative mode.

(01:01:51):
So that means that the likelihood of getting into that block is a little less.
So for example, if there's a very slow block, you might need to bump it in order to achieve your confirmation target.
But given that RBF is getting a lot easier and more common,

(01:02:13):
we think that an active observer can very easily bump.
And someone that is not actively watching the transaction probably also doesn't need to do that.
Or hopefully.
And I forgot one that is very important.
So in Bitcoin Core 24.0.1, which is a release from two years ago,

(01:02:38):
we shipped a new startup option called Mempool for RBF.
I'm sure you have heard about this one.
I was literally going to ask you about that next as far as, yeah, perfect.
Yeah, so we have observed now that about 95% of the hash rate is using Mempool for RBF.
And what that means is when RBF first got introduced about eight years ago, we fashioned it as an opt-in flag.

(01:03:08):
You declared a transaction to be replaceable.
And only if the original transaction had declared replaceability would you accept replacements for it as a node.
Like it was sort of a gentleman's agreement where nodes would say,
I have seen something else already that tries to spend the same UTXOs.
I will not accept the replacement because it didn't say that it was allowed.

(01:03:32):
And so for a very long time, people have been thinking that that is an unstable equilibrium.
Because if someone is offering a lot of fees to mine a replacement,
miners should take the replacement in order to maximize their fee revenue.
So there had been people asking for a startup flag that allows you to always accept replacements,

(01:04:01):
even if the original had not signaled replaceability.
So this was added to Bitcoin Core 24 and was turned off by default.
But it looks like this year that almost all the hash rate has actually turned it on.
They accept any transactions that replace other transactions.

(01:04:24):
So we just especially in the context of ordinal marketplaces where they sort of have a PSBT based bidding scheme where you can sort of have part of a transaction.
Here's the thing that I'm offering. This is the amount of money that I want to get paid to my own address.

(01:04:46):
And then the buyer can just fill in their input.
I send the money I'm bringing and I send the thing that I bought to myself over here.
And the mechanism with which these bids get exchanged is the buyer just fills out the rest of the transaction and broadcasts it.

(01:05:07):
And then if other people see it, they can overbid it with RBF.
So some people were like, oh, I'm going to totally send a transaction that's not replaceable.
So my bid will be seen first and nobody else can overbid it.
And miners notice that there is money to be collected.
So I think this to a large part contributed towards RBF being not relying on this original replaceability.

(01:05:34):
So in 28, it's turned on by default.
And this also solves a UX issue, a big UX issue where a lot of people, especially when fee rates were fluctuating brutally,
see, for example, the entire last year, you would send a transaction if your wallet didn't mark the original as replaceable.

(01:05:58):
You'd just be stuck. Either you have to make a second transaction pay even more in order to CPFP it, which we discussed earlier,
or you'd be stuck. You might have to pay out of ban for some miner to include it, which usually is even more expensive than bidding on chain.
And yeah, so all transactions will be replaceable.

(01:06:22):
So any wallet can replace it. You're not going to be stuck like that, where you're just staring at your transaction.
It's sitting there. It's not confirming.
It's also not falling out of the mem pool or becoming invalid or anything.
Yeah, so I think that's like the big cornerstones of the next release.

(01:06:44):
There's a few small things too, of course.
No, I love it because now anyone who's just listened to this is now up to date with this.
And I appreciate the full RBF explanation too.
Because that was fairly hotly debated at the time for a while.
I remember talking to John Carvalho about this in detail for a while.

(01:07:07):
And John, if you're listening to this at some point, hello.
And I thought he had some really excellent points about it. I know it obviously ended up going through.
Now it's kind of one of those things with, I guess, the rough consensus where it's just there now.
And in a way, I'm a little unhappy with how it went because being able to signal that you do not intend to replace a transaction

(01:07:36):
provides more information than not being able to say that anymore.
So we inherently have less information from the sender to the recipient here anymore.
Which I think goes a little towards what John liked about the opt-in flag.
The other thing is we might get rid of a fingerprint because some software always creates replaceable transaction.

(01:08:04):
A lot of software creates always transactions that are not replaceable.
So this fingerprint will hopefully eventually go away.
And everybody can replace it. So in our way more dynamic mempo where fee rates suddenly spike a factor 300,
people will remain flexible and be able to push their payment through,

(01:08:28):
even if they didn't anticipate originally that they would have to expedite it.
Okay. I appreciate the explanation there because again, these are some of those things where I think people see these discussions on X
or at that point Twitter, I think, and wonder like, there's always the question is like, do I need to care about this?

(01:08:51):
And that's kind of where I want to get into next a little bit is,
so first question is, what do you think are the hot debates within Bitcoin right now that people do not really need to care about?
Or that aren't really consequential versus what are the ones that you think are very consequential, very important, that do need to be discussed more?

(01:09:20):
Ooh, I hope nobody will crucify me for my answers in a moment. So I think people concerned about quantum are a little caught too far in the future.
I hope that we don't have to care about that for a couple of decades at least.
I think I sometimes have the impression we will never have to care about it, but we'll have to see about that one.

(01:09:45):
It's good to have a bit out that makes some proposals and there was a NIST standard recently with quantum resistant signatures.
One concern is of course that all of that is immensely bigger, right?
So where transaction now would start at 65? Well, a standard payment transaction can be slightly less than 100 VB, virtual bytes.

(01:10:11):
And most of these quantum resistant signatures are in the several kilobytes by itself.
So for each signature, you'd have a few kilobytes.
So that would drastically reduce the number of payments, the payment capacity of the network if we adopted that today.
And even then, I think it would be hard to argue that it fixes the issue because everybody has to move their funds into a quantum secure output

(01:10:38):
in order for them not to be able to be stoned when quantum is, or sorry, when a quantum computer reaches the capability to break ECGSA.
So something like a third of all, Bitcoin is in addresses that had been reused or addresses that where the public key is generally available like pay to public key or tabloid outputs.

(01:11:05):
And if quantum computers break ECGSA, all of those can be spent directly.
Hopefully we don't have to care about that for at least a few decades.
The other one that I think we have a little time on is people are concerned about the fees not being high enough.
You mentioned tail emission a couple times already.

(01:11:27):
So one proposal is let's do away with the 21 million limit and create new coins on each block because then we can guarantee that miners will always have revenue,
even if the fees do not make up for it.
And I think that's also a little premature.
We don't have to worry today about the fees paying the miners because the fees right now are in the single digit percent of the total revenue.

(01:11:55):
Even when the fee rates explode, it's just a small part of the total block reward.
We have a couple more halvings at least, if not maybe I'd say two or three before it even becomes interesting where I would expect fees to more often be on a similar range as the block subsidy.

(01:12:18):
And if fees go up anyway, then we don't have to worry in the long run. If the fees do not reach the subsidy, then we should revisit maybe start burying some of the existing coins from the existing rewards to future rewards
or do at least fees moving where a miner can't take the entire block reward, but it has to be spread with the next few blocks.

(01:12:44):
There's people talking about it, having good thoughts on it.
Very clearly, we do not need it today and we should do more research.
A quick note on that because I find the tail emission discussion, like anybody raising this and very seriously saying, we need to be thinking about tail emissions.

(01:13:07):
I find it to be generally a bad faith argument because first of all, it's presupposing that all of the conditions which exist today are going to be the same conditions which we operate at at a time in the future,
which we know, first of all, humans are terrible at predicting the future.
Second of all, from past experience, we know that is not going to be the case.

(01:13:29):
Even though we are bad at predicting the future, we know it's probably not going to be what we think it looks like and it's going to be something more extreme than that in one way or another.
The other thing is, I always find that the Bitcoin, it's like this oscillation between we need tail emissions because the fees won't be able to incentivize miners to secure the network enough

(01:13:53):
and then going back to the other side of the fees are too high, we need to do something to bring down fee and it's like, and it's back and forth this ping pong and it's like, maybe we don't need to do anything there because this is going to work itself out
and this is a free market for block space and people have the right to pay as much as they want or as little as they want to not be included in the block, but that is going to work itself out.

(01:14:16):
And I think I find that to be, let's say, potential quantum vulnerabilities aside when we talk about block size, because obviously one could probably make the argument that we should increase block size because the size of these signatures is going to need to be so much larger that you need to change the block size in order to account for the decreased amount of transactions that can be in there due to the increased size of the signatures.

(01:14:42):
I find that to also be a similar kind of slightly flawed argument where it's like, well, okay, but at that time that would be a fork, right, as it was previously, as it was when Bitcoin cash was created.
Yeah, increasing the block size is a hard fork.
That's a hard fork, so okay, in that event then, people are the free market will again decide which version of Bitcoin do I want? Do I want big block allegedly more quantum resistant Bitcoin or do I want same size block, still quantum resistant Bitcoin, but with a lot less transactions going through?

(01:15:24):
Right.
And so maybe it will fork at that point, like that's a very real possibility that could happen. Very likely in our past experience, every time there's a hard fork proposal, it did fork.
Yeah, right.
But so I wanted to, I'm digressing into block size, but on the tail emission specifically, I just, I think that when people say that we're going to need to increase or add tail emissions or whatever or make some sort of a changes to the distribution mechanism of Bitcoin, it just, it's a failure to see the future that

(01:15:54):
we're going toward, like the first of all, the required fees are going to increase in Bitcoin terms, which I would call real terms.
They're also going to increase in nominal fiat terms.
So when you're talking about your energy inputs going into that, maybe they'll all be priced in Bitcoin by the time this is a problem, who knows.
But it's missing both sides of that. So it's missing the fact that these are going to keep increasing because usage is going to keep increasing.

(01:16:24):
Even if a lot of that usage is offloaded to ETFs, let's say, for very large amounts, which I think it is right now, we're seeing that.
Even so, I don't see usage decreasing.
If that happens, then boy, I think we have bigger problems.
So so far, actually, fee rates denominated in Bitcoin have been surprisingly stable, less so in the last year.

(01:16:48):
But so we didn't have the mempool clear completely since last April, which is now, I think, 16 months is should be the longest period of time that this has ever been the case.
And before that, there was basically at least once per week, you could get transactions through at any fee rate, which was the minimum relay transaction fee rate of one side per VB.

(01:17:16):
So right now you can get transactions through at three sets per VB.
In terms of Bitcoin, sure, that's a three hex, but it's not that much of an increase in terms of other in terms of wealth or value.
This is a higher value, but also the amount of purchasing power that's been flowing with each Bitcoin transaction has drastically increased in the last few years.

(01:17:44):
So in relative terms, I think it's even cheaper to send money with Bitcoin than it used to be for the amount of money that is being transferred or purchasing power or whatever.
But if you want to call real money, you know, now we're in a whole other sidebar.
Real money, money, I'd say money. Yes, real money we can fight more on, but we don't have to solve that today.

(01:18:10):
But yeah, I think given that the block space demand was so high in the last year and the mempool never cleared out completely in the last 16 months,
I would not be surprised that it also pushes up as new use cases, new layer choose compete for block space.

(01:18:31):
If people come and do rollups where they want to write several megabytes of data in a short sequence of blocks in order to have their zero knowledge proof in there.
That'll also create demand for block space.
So one thing that I think maybe especially a lot of people that are doing DCA today and DCA in small amounts should keep in mind is every input that you when you receive an output, you commit to a specific input type.

(01:19:06):
So you'll always have to purchase a certain amount of block space.
And generally, it's been true that block space doesn't get cheaper.
So if you are sitting on a $5 you take so from each day of the last year.
First, may I suggest that you first aggregate a few of those purchases before you withdraw it into bigger chunks.

(01:19:31):
But also please consider currently the mempool is as cheap as it hasn't been for 16 months.
So maybe consider consolidating into fewer pieces if you're sitting on thousands of tiny amount you take so it's just I don't know if that's your audience but no I think it is because I was talking with with Wicked Smart Bitcoin about this just a couple days ago.

(01:19:57):
Oh really always very pushing very hard like consolidate your UTXOs.
And I think that there was you know there's been various companies that built out like first of all automatic withdrawals to cold storage to a reused address so flag one in the reused address.
Second flag automatic withdrawals of daily DCA, which is just creating a bunch of potentially dust UTXOs that you may not be able to spend in a high fee environment that is persist.

(01:20:29):
And so you know I don't like to tell anyone what to do with their money but it behooves you to wait to withdraw your DCA until you have a decent sized output like UTXO that you're going to receive like please for the love of God don't withdraw them and if you're DCing $5 a day please or more than that like unless you're DCing a really fat chunk a day like you are rolling it you really should not be withdrawing that every day that is not.

(01:20:56):
Well but if you're DCing a fat chunk every day probably you should also keep a little more with with your exchange because you can afford a little more risk tolerance.
Yeah that's a fair point as well so either way you should probably just wait until you build up a larger stack in your exchange don't keep it on there forever but at least wait until you can make it a large sized UTXO which is going to cost you a lot.

(01:21:22):
You're a stack with your brokerage or exchange but let it accumulate a little bit so you can withdraw decent chunks so you don't pay yourself silly.
Like you'll just imagine fees never go below 10 sets per VBIT or 50 who knows you'll have tens of thousands of sets that just where 60-80% of the value goes towards buying the block space to spend it so yeah just run the numbers look at it a little bit and if you had an episode with Wicked Smart then probably he had.

(01:22:03):
I think he had all the details.
Yeah but it's a really good practical thing that like I didn't fully understand until I was doing a collaborative multi-sig to raise some money for a charity in El Salvador and all of a sudden we were like wow why are fees so high when we're trying to transfer this out to the charity and it was like oh because we've got a bunch of tiny UTXOs.

(01:22:25):
And so like sometimes you don't understand these things until you actually run into the wall but luckily there are a lot of people who have been like Wicked and yourself who shout about this very loudly so please listen and please utilize low fee environments to consolidate UTXOs send them to yourself to a new address please.
And also recognize that there are privacy trade-offs with that of course because you are basically putting all those UTXOs together into one new one.

(01:22:54):
You're heavily hinting that all of that money is controlled by one entity.
That's a fair shout out too.
Yeah maybe just to give a stat here the UTXOs has increased from 80 million to 180 million in the last one and a half years or so.
And a lot of that is people trading in on-chain graffiti but some of this is also DCA so if you're in that boat please think about the future block space that you have committed to buy.

(01:23:32):
Yeah that's a very good piece of advice.
So we digress slightly but this is a show for digressions.
Wonderful.
Other things that you either are overblown people are kind of distractions or actually I guess underblown, not talked about enough people should pay attention to.

(01:23:53):
Where does ZK Rollups fall on that?
Maybe can you explain that at a high level what that means for folks?
We got to go deep.
I guess what you're basically trying to do is you prove that a payment has happened as it was intended outside of the blockchain and you just write that proof to the chain.

(01:24:17):
And so you can think of it as sort of a layer two or side chain mechanism.
I don't think I can actually explain any of the ZK Rollup things.
One of the problems is so this is a scaling mechanism that is popular on Ethereum.

(01:24:38):
And in Ethereum we have a different philosophy here.
In Ethereum all of the calculations happen on chain.
When you have a smart contract, the smart contract is written out in the Ethereum transaction and executed by every single node that validates the blocks.
In Bitcoin we tend to work with a witness and we already have essentially the mechanism that people use to build ZK proofs.

(01:25:07):
We already just proved that it was done right.
We don't tell you all of the details that had to happen.
For the most part, for example, I don't want to get too deep into mechanisms, but the philosophy of Bitcoin is essentially to just prove that it went right rather than sharing all the details of the contract that you made.

(01:25:34):
When you have a music input, for example, it might under the hood be a three of three or a 20 of 20.
But nobody will ever know because you just provided a valid signature that resolved for anyone to see that you were allowed to spend this.
And how you achieve that under the hood, whether there was an oracle whose signature had to be tweaked in, whether there was a single signer or 15 signers, that's nobody's damn business.

(01:26:03):
With the ZK roll up, getting this, I proved that I did it wrong.
I proved that I did it right, hopefully.
You get a scalability because you don't have to write all of the smart contract on chain.
But in Bitcoin we don't do that so much.
In Ethereum it's a huge scaling effect.

(01:26:25):
In Bitcoin what I've seen I think is like a two and a half X or so maybe that we would be able to achieve versus just on chain transactions.
Maybe I'm not up to date to the latest proposals, but I think it is a slightly less powerful mechanism for us than for other blockchains.

(01:26:47):
I appreciate the context there. Other things that either you think people should pay attention to or things that are overblown.
Ordinals, who cares?
It's like Abraham Lincoln, vampire slayer on what is that, a 20.

(01:27:13):
Yes, this $20 bill might be valued more than $20 by whoever it has.
They might put it into a frame under in their living room because it's really cool and all.
And they take a bit out of circulation, big whoop.
Turns out that people have different things that excite them for some people. This is what allows them to send funds into their family across the planet or the only way that they can even pay for services because their country is sanctioned or just a brilliant idea.

(01:27:56):
For other people, they have a different approach. They want to have art, they buy block space.
So we have a somewhat fair marketplace. We have exactly strict rules how transaction weight counts towards the block space limit.
And they are paying to use this block space in a different way.

(01:28:20):
It's not one that I really care much about, but also as long as they're paying for it, it just...
If you want to get a transaction through, pay a little more than them. They're paying less than three sets per VBite for it right now.
If you can't pay three sets per VBite, I don't know if your transaction was that important. I mean, it's... I don't want to... Like, if you have very little money, on-chain transactions are prohibitively expensive.

(01:28:54):
But that is mostly because the cost for a transaction scales with the amount of block space that you buy, which scales in the number of inputs and outputs you create.
And it doesn't scale with the amount of money you're sending.
So I don't want to sound cruel or dismissive, but if you're trying to put coffee payments on the blockchain, it is natural that you will be priced out.

(01:29:22):
Because someone that is pushing a million bucks into an ETF or out of an ETF, they can pay more than you in absolute terms, because for them in relative terms, it'll be way less than your $5 coffee payment.
And that's just how the framework of how block space is priced, how this network works, how every single node on the network has to verify every piece of data that goes onto the blockchain,

(01:29:53):
propagated and validated and stored if they want to keep an entire archive of the blockchain.
So, I mean, none of this comes as a surprise. I believe I've written answers about this nine years ago when Lightning first came up as an idea.
While Lightning might be a valve for that, because small payments naturally, on Lightning, they pay relative to the amount of money they are sending.

(01:30:19):
On-chain, they pay for the block space they're using.
So, small payments are favorable on Lightning or other layered tools, really. And large payments win on-chain, and it's just the circle of life.
I don't find that to be in any way callous, I find that to be realistic, because that's the thing. It is supposed to be a free market for block space, and that should be a competitive market.

(01:30:52):
And that competitive market for block space ultimately benefits everyone who uses Bitcoin on any layer, because it means that our base, our foundation is more sound, right?
Now, this is also the whole point of layers on top of Bitcoin. You've got the other extreme, which is the Solana, which says we're going to do however many, you know, 69 million transactions, I don't know how many transactions they do,

(01:31:13):
but however many transactions, you know, a second, we're going to scale it at the base chain. Well, but again, we talked about trade-offs earlier.
Then you trade-off. You're always going to have trade-offs with decentralization or security. Solana, I think, lost both of those, given how often their devs, you know, have to actually do something to stop the chain.
But I think this is...

(01:31:34):
Yeah, famously they had multiple outages, some of them several days. That's not a live system.
No, yeah. I mean, it's a cute project, but that's not base layer money for the future of humanity.
They're solving a different problem. They're solving a smart contract resolution platform. And, well, we're not trying to put all the smart contracts on the blockchain.

(01:32:02):
We're just trying to put the proofs that we resolved the smart contract correctly on the blockchain. And we will be able to have complex smart contracts, preferably out of band.
Like if we look at simplicity, mini-script, discrete log contracts, various layer two proposals, in a way, even Feddyman, Cashew, and all of those, they allow us to have very different trade-offs, more complex smart contracts,

(01:32:33):
partially oracle-based or just in a tab-root script path that never has to hit the chain because all of the participants agreed that it would be valid to broadcast it,
and just sign off on the key path and you never see that there was complex conditions that could be enforced, but didn't have to be enforced because they could be enforced.

(01:32:54):
So I think we chose to do it the difficult way, but I think we might be able to go way further than alternative approaches.
That's why one of the reasons I'm still excited about Bitcoin after, well, 12 years now, is it, I read it, when I finally read the white paper, I was like, this will actually work. And this is exciting because we don't have a cash on the internet.

(01:33:28):
It looks like we can have smart contracts, we can build all sorts of really cool stuff here, and yeah, we don't have to show everyone what we agreed upon, and we can still use the blockchain as an unbiased judge of what actually was valid to broadcast and get those smart contracts resolved in the way they were written.

(01:33:54):
And I think, I'd love to just ask a little bit because you led me in perfectly because I wanted to ask your thoughts just on eCash, like the cashew implementation, and then you have Fedement, which is also, it's a federated eCash,
you've got FedE, which is obviously a company building on top of that, but is also committed now to their source fuelable now and will go fully open source soon. I don't know, I don't remember exactly when, but I think to me these, okay, so eCash and federated eCash, Fedement plus Lightning,

(01:34:30):
these are the solutions that people who are trying to pay for a coffee, like that whole trope of like, well, you should be able to pay for your coffee on the base chain. No, you shouldn't.
If you can pay for your coffee on the base chain, well, that's probably not a very well, like not a very used base chain, like that's okay, you know, go to Solana and pay for your coffee in the base chain and nobody's going to want your shit coin.

(01:34:53):
Sorry to be harsh to any Solanians out there or whatever you call yourselves, but like eCash and Fedement and Lightning, these solutions built on top of Bitcoin, they work and of course there's going to be, there's always going to be things that need to be ironed out, improvements that can be made,
like in, you know, Fedement's like, you know, having auto sweeps, for example, to make sure because the risk there is you could get rugged, right, the same with an eCash mint, non federated eCash mint, you could get rugged.

(01:35:23):
So do an auto sweep, have a bunch of different mints, like, you know, but again, trade offs, but for somebody who wants to buy a coffee, or transact locally in their community, or transact with near perfect privacy, these are the solutions.
It doesn't, not, the base chain doesn't need to do everything, the base chain needs to be the most solid foundation we can possibly have, because without that, none of these other amazing things that we can build and layers on top that matter at all.

(01:35:51):
And I guess that wasn't really a question, that was just me starting to rant.
I fully agree so far. I mean, if someone claims there's no trade offs, either they haven't thought deeply about it, or they are lying to you, there's always trade offs.
Very specifically here, the fediment is a federation, as it's named, and the cash you service are custodial, as we know. So you have a very heavy trade off here, you're trusting them with your money.

(01:36:29):
Well, but it might be possible to trust them with your, with the money you would carry around in your wallet, and you can make a bunch of payments from that, that never need to hit the base chain.
You have perfect privacy against the mint, against the center and recipient have, I believe, also perfect privacy to each other.

(01:36:51):
So yeah, there's a bunch of trade offs. It is really exciting how, so Tramion eCash came up, I think it was late 90s, and then was famously tried at company by David Chom, DigiCash.
And the problem was that it had a central point of failure. This company was first regulated, and then I think that shut down. Someone else go check the history exactly.

(01:37:24):
But the main point was, it didn't succeed because it was trying to have a central service that was adding a lot of privacy for a government money.
And with Bitcoin as our base money, these mints can operate across country borders. Yes, you should probably keep in mind that it's custodial and they can run away with all of your money, but none of them can censor you because nobody knows, they can't distinguish their customers, at least if they properly implemented.

(01:37:59):
So yeah, super interesting trade off. This is scaling tech that I'm excited about. Yes, you have custodial risk, but if it's for a small amount of money, like an amount of money that you might spend in two days, it's probably not going to break your bank for most people.

(01:38:20):
And the privacy trade offs are cool. And you don't have to buy on chain space. So it's super cheap, right? So if you're not excited about it, at least from a theoretical standpoint, you should appreciate the options and the trade offs and just the possibilities that we've gotten in the recent years.

(01:38:46):
So the lightning network sort of acts as a lingua franca between the the mints and even if you go from one mint to the other, you never hit the chain.
This would also hold for many of the other ideas that are proposed as layer twos where you can move in and out via lightning. I know some people advocate that you could do your stacking on liquid and then transfer out via lightning instead of pegging out, which is faster and easier.

(01:39:16):
So I think a lot of the potential that will lead to the Bitcoin network scaling in the long term comes in these currently undiscovered technologies and how they combine, not just fediment by itself is okay, cashew by itself is okay.
Either of those with the lightning network is way cooler.

(01:39:43):
It makes me very excited because again, these are there's also so many things like what I what FETI is doing with also building in matrix chat within it, building in noster integrations for basically, you know, social proof if you need it within high trust, you know, local communities, or decentralized communities that also want to build up some sort of a web of trust,

(01:40:07):
like having all of these things that you can, these different layers, not just the monetary layers, but the, the decentralized social layer, the decentralized communication layer, all of these things and having all of that be not observable by outsiders and not sensible by either
outsiders or insiders is incredibly powerful, because then you actually have the full suite of tools that you need to be able to move a little bit further down that spectrum of sovereignty, you know, and to be able to like, to really do whatever the fuck you want to like there there's no KYC in a in a

(01:40:46):
sediment, you know, like, and that's, that's beautiful. And then, but you're still ultimately able to settle that with in the hardest money that has ever been discovered by humans, which is Bitcoin, and without without that layer one, all the rest of it is meaningless,
but we have that layer one.
And I mean, sovereignty being one thing, but also just the creeping surveillance state and surveillance capitalism, like each of your credit card payment is shared with 180,000 companies.

(01:41:20):
The EU is going to renegotiate chat filters again for the third time now or whatever under the third commission chair, sorry, country chairing the commission.
Like, basically, this is when when people think about what corners of the philosophy and world, the ideas for Bitcoin came out of the cypherpunk ideals of building technology to

(01:41:56):
against surveillance. This is so hard incorporated and all of these things. And yes, you have to custodial risk, you should not forget about the custodial risk, but it's still a very useful tool that is really exciting.
And yeah, for small payments.
If you put in such a small portion of your, your overall wealth, don't don't stack your sat in a in a fatty or anything. But would I have 50 bucks worth of Bitcoin in a fatty?

(01:42:29):
Sure, why not? Because then I can go to a conference and buy a meal and split an Uber or whatever. And nobody needs to. It's literally like cash at that point. From me to you, nobody else.
And that's that's a beautiful thing like that is that is that true implementation of digital cash, but it's only possible when you have the solid foundation. And like, you know, and so again, I think that's a, that's a fair note to wrap up on.

(01:43:06):
But before we wrap up, is there anything, is there anything else we didn't cover that you wanted to is there anything we missed we come to a lot.
I was kind of expecting that we would touch on covenants just a little bit.
I'm game for it. I mean, I had, you know, I had some other questions too, but you know, we go down various rabbit holes here. Let's let's let's touch on covenants if you're down.

(01:43:28):
Yeah, I don't have to run. So I have a little more time.
Okay.
You have a little kid at home. So maybe you're you're on the first time thing, but it's okay. I've got you let me know if I have to wrap.
I've got my parents here right now. So they're they're the most willing babysitters you could imagine. They're like, no, please, please, give us more time.
Yeah.
So I don't like the term covenants. Let's start with that. Really, I think it's easier to think about what is described as covenant as op codes that introspect the spending transaction.

(01:44:04):
Like what a covenant does is it basically looks at the transaction that you use to spend an output and only under certain conditions if certain features are present in the spending transaction, it resolves to valid.
We have some of those already. We have a tax sequence verify, we have up check lock time verify.

(01:44:29):
So for example, up check lock time verify requires that the lock time field on a Bitcoin transaction is set to a certain value, at least a certain value.
So we have some of those up quotes already. And basically what what all of the proposals up internal key up tx hash up text, seek from stack and so forth are introducing our other ways of requiring

(01:44:58):
certain features to present in the transaction that spends an output eventually.
I am open to some of these getting merged eventually. I think with the technology that we have right now on train, we're not going to be able to build that future where everybody can do all of their payments and all of their savings and

(01:45:26):
like just entering and exiting all of the second layer protocols or side chains or whatever people might build or contract.
All of that will require a bunch of on chain capabilities and block space.
So we will need more features. Some of those are coming by themselves. Some of them are being built. A lot of them are being discussed.

(01:45:56):
What I'm kind of still missing is I'm just not convinced by any one of those to a degree that I'd say this makes this use case 10x better or this can build this thing that we couldn't do before that blows me completely out of the water.
So while some of these proposals are technically already pretty advanced or well fleshed out, I think that they are still lacking in the narrative department and the motivation department.

(01:46:31):
As you say, if you want people to sail their seas with you, make them long the ocean. Don't drum them up to build a boat with you.
So I think where we need more work is convince the community that what you're building is going to lead to exceptional improvements in certain use cases or just completely new features that we couldn't do before that are worth all the drama.

(01:47:06):
We have a bit of PTSD from Segwit, I think, the soft forks. What was supposed to be a, it turned into a multi-year ordeal and nobody really had anticipated that sort of struggle before.
Tehr Pruth seemed to me to be pretty well accepted by the developer community very quickly and also little pushback from the community and then people created huge drama about how to exactly activate it, which was completely unnecessary in my opinion.

(01:47:46):
So soft forks are more work than people anticipate. For example, specifically with Upcat, it is very impressive what people have come up with like these very complex constructions, how they can build a vault or something that is sort of like a zero-conflict transaction.

(01:48:08):
That both on-chain is very complicated, lots of block space and just has extremely complex scripts that, you know, with Solidity, people have seen that anyone can write Solidity.
It's like JavaScript. However, the difficult thing is to write the contract so it does exactly what you intended, nothing else. And reliably, that's what you intended.

(01:48:36):
The difficulty is not in making it accessible so everyone can write it. The difficulty is in writing a good geographic protocol.
So I feel like Upcat by itself would maybe be a little more of a foot gun and I don't see the 10x anywhere. Having vaults in general, it would enable vaults, which is something we can't do yet. But most people just do multi-sig and achieve very similar things.

(01:49:05):
There's a couple scenarios I've been convinced that cannot be solved with multi-sig that can be introduced with vaults. But I have a hard time getting excited for Upcat so far.
So I would argue if the people that are heavily pushing for the new Upcodes and feel that these are the things that we absolutely need, please invest in the narrative and convince us that what you're building is worth a soft fork.

(01:49:39):
And to that end, I see some discussions on Twitter. I know that there's chat groups and telegram and so forth. It would really help if a lot of this discussion would end up eventually in more archivable and searchable spaces like
the Dove Bitcoin, the mailing list, blog posts or something where if you are only slightly interested and want to keep abreast, you don't have to hunt down these conversations, but you have these points or artifacts that you can consume in order to keep abreast.

(01:50:18):
So, yeah. I think we have a lot to do in the scaling department in the long run if we want this to be the internet cache for everyone.
And we will need better tools and cool new ideas, maybe some of those whatever 50 proposed layer twos. Some of those might come through and are really cool.

(01:50:43):
Maybe if we get a few Upcodes, people can build some really fancy stuff. I hope that we don't cause even more minor centralization, which is one of the things that I'm actually really concerned about breaking the Bitcoin network.
Right now, there's just a handful of major hash rate, well, mining pools or block template creators that control what goes into blocks. It would be way too easy for those people to form a cartel and start a censorship attack.

(01:51:17):
One of the big concerns people have around all of these Upcodes is that we might introduce minor extractable value where we make it too complex for miners to be able to build the optimal block and therefore introduce new intermediaries,
people that build the block for miners and reduce the number of people that decide what goes into blocks even further, which just creates a central point of failure, just one door to knock on to decide what can be sent on the Bitcoin network.

(01:51:52):
So, yeah, I think that anyone that designs Covenants or protocols that make use, sorry, I'm not saying Covenants myself, new Upcodes, people that work on new Upcodes, I hope that they keep in mind how that interacts with mining incentives.
And they come up with some really 10x or 1000x improvements because, sure, we can eventually maybe make the block space bigger. Let's make it 10 times bigger.

(01:52:25):
Now we can have 10 million payments instead of 1 million payments per day, but that still doesn't allow us really to do coffee payments on-chain.
It will blow up the UTXO set even further, which makes it harder to run nodes. I just don't think a small linear factor of increase in capacity is going to be that exciting.

(01:52:49):
So please work on a 100x idea and convince us that you can build it. Then I think you'll get a lot of buy-in for your stuff for proposal.
I think that's a great piece of advice. If you want people to accept something, make sure that it is orders of magnitude better than what exists right now without sacrificing decentralization and security of the network.

(01:53:15):
Or trade-offs. We just talked about trade-offs. Maybe it's less decentralized, but if you can prove that there was nothing underhanded going on, that might still be perfectly fine.
Like ARC is super centralized. You have an ARC service provider. They actually have to put up a ton of liquidity, which is one of the things that makes me curious whether it would be able to adopt it.

(01:53:45):
Or at least their original ARC proposal. My understanding is that there's no variants that are more scalable or easier to bootstrap. Or a Fediment, fairly centralized, extremely private.
You have trade-offs. You can build other stuff on a dumb network. You can build very smart stuff. Sorry.

(01:54:10):
I love it. That's a good note to wrap up on. Where do you want to send people? Where should they go to find you? I'll link stuff in the show.
But also, anywhere else you want to send people to just to stay up to date with this stuff?
All right. I have a few. A few friends of mine and me, we sort of kicked off a Bitcoin mining developer mailing list recently. If you are a developer that works on mining stuff that might be interesting to join,

(01:54:43):
we talked about that in the recent Bitcoin Optech Recap and newsletter. I think that was last week, so 3.18.
So if you're involved in development surrounding mining, new mailing list. Yeah. Otherwise, if you have questions on how Bitcoin works technically,

(01:55:05):
I think you'll find a lot of answers on Stack Exchange. If you ask new questions, probably one, mostly Bitcoin developers or just heavily involved power users and enthusiasts will hopefully quickly respond to you.
Please ask away. We could use more good and interesting questions. And yeah, if you want to hear more about current development, if you're in a business and need to advise your CEO what's going on in Bitcoin,

(01:55:37):
we heard that every week in the Bitcoin Optech newsletter and recap.
I'll drop those in the show notes as well. Thank you so much. Absolutely. And Merch, thanks for sharing your scarce time with me. Bitcoin, like your time is scarce, but Bitcoin podcasts are abundant,
which I think is a good thing. So thanks for sharing your time with me. I learned a lot and I appreciate your perspective on these things. I think people are going to enjoy this.

(01:56:07):
Thanks for having me, Walker. I hope I get leverage on my time with all your listeners.
I am so too.

(01:56:43):
Bitcoin doesn't care, but I always appreciate it.
You can find me on Noster by going to primal.net slash Walker. If you want to follow the Bitcoin podcast on Twitter, go to at Titcoin podcast and at Walker America.
You can also find the video version of this podcast at youtube.com slash at Walker America and at Walker America on rumble.

(01:57:05):
Or just go to Bitcoin podcast.net slash podcast and find links everywhere.
Bitcoin is scarce. There will only ever be 21 million, but Bitcoin podcasts are abundant. So thank you for spending your scarce time to listen to another fucking Bitcoin podcast.
Until next time, stay free.

All Episodes

Everything You Don't Understand About Bitcoin Development - MURCH (THE Bitcoin Podcast)

Episode Transcript

Popular Podcasts

United States of Kennedy

Stuff You Should Know

Dateline NBC

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Everything You Don't Understand About Bitcoin Development - MURCH (THE Bitcoin Podcast)