#671: What's Really in Bitcoin Core Version 30 with Instagibbs

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Got to be spicy, Greg.

(00:01):
We meet here on the on the eve of Bitcoin's death, October 9th, 2025.
Bitcoin Core version 30.
Yeah.
Drops tomorrow.
Very somber.
Very somber.
In all seriousness, though, I think a lot of discussion as we were just talking.
before we hit record has revolved around obviously this op return debate whether or not the limit

(00:29):
should be lifted or not and the potential consequences of doing that maybe we'll touch
on that but i think um there hasn't been enough discussion on everything else that's included in
bitcoin core version 30 so i wanted to sit down with you and talk about what bitcoin core has

(00:51):
been working on with this particular version and i think before we do that for the layman out there
maybe we just do like a high level um a high level refresher of what bitcoin core is what
what is entailed in um basically releasing um new versions particularly significant versions

(01:17):
like version 30 and then we can jump into the nitty-gritty of what's included.
Sure. You want me to take the lead on this?
Yes, sir.
All right. So basically there's a Bitcoin Core software is the reference client, so to speak,
where it has majority kind of mind share and running share of the Bitcoin protocol itself.

(01:40):
It includes a bunch of different parts, peer-to-peer layer stuff, consensus stuff.
A wallet, which people still use, a bunch of other tools and pieces in there.
A major release is done every six months.
So on a six-month cadence, there's what's called a feature freeze, which is, hey, stop adding new things.

(02:04):
We're going to continue just doing bug fixes until this time.
There's a branch off, which means, okay, now we have a new fork in the history that will turn into releases that will release binaries based off of this.
and then eventually a release, right, with a series of release candidates,
which is happening right now, and then eventually a final release.

(02:25):
In addition to this, you also have kind of using this forked history
that if there's future bugs found, if and when there are future bugs found
and issues, the fixes can be applied directly on these forked off histories
and do minor releases.
So someday I will very highly likely have a 30.1 for various reasons.

(02:47):
And this is how that's done. That's done on a per-need basis. So right now, if I understand correctly, there's 20 and 29 minor releases being cut right now for various reasons, bug fixes and improvements.
So this can happen throughout this lifecycle. And then eventually, at some point, these major releases or these major branches get marked as end of life, saying basically we won't support this anymore.

(03:16):
we won't do any effort to like update maintenance to this make build and make binaries or anything
like that and then it kind of gets stale and so that's kind of the life cycle yeah yeah and
taking even further step back just on the concept of implementations right you have bitcoin
or consensus and then implementations like core knots the bitcoin uh ptcd they sort of

(03:43):
have their own implementations that build software that is within consensus but does things
a little differently correct yeah so some are complete implementations so btcd is a
good example that's been around a long time um it has it's programmed in go the golang and it has

(04:03):
a complete implementation of the consensus software so when you get a string of bytes
in the form of a blockchain, it needs to come out to the same exact answer as Bitcoin D or any other
implementation. The re-implementation raises the chance that there is mismatches, but those can
hopefully be ironed out and debugged and fixed over time. But there's definitely always, it's a

(04:31):
very demanding problem, making sure they're in lockstep of consensus. And even between Bitcoin
versions, there's been historical problems with that, where implementation details, like
how the database is stored, causes forks in the future, right?
With unforeseen events.
It's been a long time since it's happened, but it's always possible with updates or not

(04:56):
updating too.
Yeah.
And where would you say we are in terms of the path of Bitcoin Core?
I remember my first BitDevs in New York in 2015.
Russ Janofsky basically presented on SegWit.

(05:17):
And obviously we had SegWit getting implemented.
But I think one thing over the year, over the last 12 years,
has been made clear to me is that Satoshi, when he launched Bitcoin,
was a bit of a spaghetti code base.
And there's been a lot of work to sort of separate things
within that code base, particularly, or not particularly, but one thing being like the

(05:38):
wallet and the GUI.
And it feels like the last decade of Bitcoin core development specifically has been trying
to get the implementation to a point where things are separated appropriately, more modular,
and you can begin to do things that make it more complex, make it easier to build more

(06:02):
complex applications on top of the Bitcoin protocol layer.
Yeah, there's definitely, that's one of the major things happening is historically splitting
out these functionalities, getting them into their own containers that can be tested separately.
So focusing on like the charlatan he's been working on, he's been continuing carrying this

(06:25):
torch on the LibBitcoin kernel.
So being able to separate the consensus parts out of the code base completely exposes an API so people can reuse this either in an alternative implementation or just for tooling.
It's not exactly, you know, a lot of this work is not glamorous in that there's cost benefits to be weighed.

(06:49):
the cost is here is that when you're refactoring these very critical parts of the code base,
most of the consensus, not wallet.
I mean, wallet's important in its own way, but for the consensus parts,
making sure that when you're changing this code to make it modular,
you're not also changing the behavior, which is very difficult.
So as you said, Satoshi started with main.cpp, one big file that has wallet, consensus, peer-to-peer.

(07:13):
It just says everything just jumbled in it.
And it's been a long process of carefully teasing these pieces out, which is continuing today.
One big project is the inter-process communication interface.
So there's this project basically split up to different binaries.
So you can have your Bitcoin node communicate with your Bitcoin wallet over interface, different binaries.

(07:36):
Or in the future, you could have the peer-to-peer parts handled only by a separate binary or different ideas like that.
but this is like future roadmap stuff yeah well sticking on current roadmap stuff like beyond
op return which is obviously the most talked about feature in core version 30 i'm looking at

(07:59):
my notes now looks like there's going to be removal of checkpoint support and depreciation
of checkpoints uh changes to data carrier size behavior and deprecation plan support for multiple
op return outputs per transaction p2p relay mempool adjustments rate limiting and denial
services protections refactoring internal cleanup infrastructure so there's much beyond

(08:23):
yeah up return up return as well yeah let's start on checkpoints because i think that right
has been uh not very controversial but i think people have very uh depending on who you talk to
um very uh specific views on checkpoints for the good or the bad is removing them good or bad
Yeah. So checkpoints historically are an anti-diagnostic service mechanism. So back in the day, if you spun up a node and you didn't have these checkpoints, like let's say a few versions back, maybe 10 versions back, a peer could connect to you and then hand you a bunch of data that they cheaply made using, maybe they have like one ASIC, right?

(09:07):
of one miner and they make a long block header chain,
a very weak difficulty, and they intercept you right when you're getting connected
to the network and just feeds you these headers.
These headers, based on the current architecture at the time, are just
written to disk. And so these are 80 bytes each. And so if you do enough, you're essentially

(09:27):
just writing 80 bytes of data over and over and over to disk.
And this is called a header disk fill attack.
Like these checkpoints were basically saying, OK, up until this point, we're not going to accept any forks in the blockchain history.
It must get to this point. And then it continues doing validation after that.

(09:48):
But this point that they picked is basically like, you know, it's, oh, it would take 10 percent of the network's mining power, yada, yada, long time to make a header chain this long.
therefore um it makes the attack that much harder but that was like the original motivation
because it was a real attack and correct me if i'm wrong but wasn't there

(10:11):
aren't the way the checkpoints are sort of like verified or um decide upon that you have like a
number of developers basically just sign like this is the right checkpoint this is the right yeah
exactly add a new checkpoint all you need to do well let's see for check i haven't thought
of us in a while, but you want to make sure that reorg will not happen beyond that point.

(10:35):
So it has to be very deep, right?
It's qualitatively different than another feature called assume valid.
So this one, you have to say that we will never fork this one out.
And so it's kind of labor intensive to like philosophically argue that is 300,000 blocks,
correct?
400,000, things like that.
And it's because you really are saying like, I will not devorge from this history.

(10:58):
But yes.
ostensibly you get into a GitHub pull request.
Somebody says, I'm updating it to this height.
So 500,000 or something like that.
This is the hash and everyone sits there and makes sure that, yeah,
there's been 500,000 blocks on top of it since then.
And this hash matches.
That would be a verification.

(11:20):
Yeah.
And how's that?
What's being replaced?
Is that headers precinct or something like that?
Exactly.
So there's this long, this idea,
this is years and years of an idea where you could say, okay,
what if we have a, when we're first,
when you're freshly syncing with the network,
you just have a broad idea of like how many,

(11:40):
how much proof of work you should be expecting.
So you connect to the network and say, I'm expecting, you know,
this many X, I can't even say the hashes or whatever. Right.
And then you get this, you get fed this header chain,
but instead of committing to disk, you just walk the whole chain,
the whole way until you hit that minimum proof of work requirement that you've internally

(12:02):
internalized. Once you hit it, you say, okay, that looks good. I've gotten all this way and I've only
stored one header at a time in memory. Now that I've gotten this way, I'm going to do it backwards
again. You just sync it twice. So you sync the headers once to verify that your disk is not going
to be filled. And then you sync again to actually write to disk. And this, along with a bunch of

(12:23):
extra testing work allows you to remove checkpoints entirely from the code base.
Does that have any IBD trade-offs in terms of time?
Yeah, I think with the current implementation, if you have a flappy internet connection,
which I had once when I was testing, I was testing by flapping the internet connection.
During the precinct, before you've finished the first pass, if it gets interrupted,

(12:50):
like your peer drops for whatever reason, it has to restart.
So that shouldn't happen.
I haven't seen that since I was testing it, but that's one constraint there.
So you need to be able to download the header chain once.
As soon as that's done, it goes like historical.
And there are ways of improving this, but I think it's one of those engineering complexity tradeoff things, which doesn't seem worth it.

(13:15):
Yeah.
And so I guess, again, stepping back, broadly speaking, how profound would you say that this major version releases in terms of improvement of the node software itself from an efficiency standpoint?
Are you talking about initial block download or just this?

(13:36):
IBD, you can even talk like peer-to-peer level.
um, uh, obviously, uh, or transactions going to be, um, matriculated through the,
the peer to peer network faster. Sure. So on the, the checkpoints front,
front that doesn't improve efficiency at all. That's just a philosophical, uh, change to make

(14:01):
it clear that the core devs are not in charge of what your chain is. Um, but from a performance
perspective, there's been a bunch of work done by Lawrence who has focused on, especially on the
lower end of hardware, for initial block download. I haven't paid very close attention to that,
but I know it's happening. The other kind of transaction robustness, right, for the peer-to-peer

(14:28):
network, there's been a bunch of work both on, there's this thing called the transaction orphanage
and also package relay.
So I'll start with the orphanage part
where if you turn your node on for the first time
and your mempool is empty,
people will start telling you about transactions

(14:48):
which have dependencies in the mempool itself,
but you don't have them.
So for example, you get a second generation transaction
that depends on a first.
Right now prior to 30 this process is a little flaky and can be interrupted by direct peers who are either malicious or malfunctioning

(15:12):
So 30.0 has a significant improvement to that.
It was spearheaded by Gloria, Peter, and others to make this robust to single peers being malicious or even end peers being malicious.
So as long as you have one honest peer, you can make this kind of transaction catch up in the mempool.
is this for like child pays for parent and RBF only or?

(15:36):
No, not only. So this, it is, it was aimed at it.
So it was aimed at the kind of one parent,
one child package relay project,
which was deployed in full on 28.0.
But the existing implementation had this weakness where if a single peer
connects to you,
they can throw garbage at you and basically empty out this, this cache.

(16:00):
Right. So basically it's,
the way of connecting the dots in your mempool
is to get disrupted by a single peer.
And the new implementation of what's called the orphanage,
finding your parent, this is robust,
even if you have N-1 connections being attackers.
So basically the one honest peer can take up a slot

(16:22):
and make honest CPFPs and package relay attempts
at least one at a time.
So...
I'm trying to visualize that. You have, let's say, out of the box, eight peers, seven of them are malicious.
Internet is just.

(16:42):
So they're feeding you orphan garbage, so stuff they don't intend to ever fix, right?
So really, it's just stuff that doesn't cost them anything.
They're just handing you data to look at and hold.
But basically, instead of one big global bucket, which it was before, there's like a global bucket.
So one peer could just go in and switch out the buckets of contents you have.
end buckets and these end buckets can be shared it uses some optimistic pathing like optimistic

(17:08):
assumptions about using the whole space by one peer but under kind of these loads where either
things are very busy or the peers being malicious then we protect at least uh we have a protections
slots for each peer essentially to make sure that economically valid transactions are propagated
yeah i'm just trying to think how would uh how does the node software determine that the

(17:33):
one peer providing you good data is actually the right data so it's not scoring or anything like
that uh it's just saying i think the if i remember right it's saying a maximum transaction package
can be like this big like 101 kilovitual bytes it says i'll protect that much per peer
so whether or not the peer is malicious or not doesn't affect this number it's just something

(17:59):
you allocate for that peer so it doesn't it doesn't take like historical note of who's
given you useful things it just allocates that yeah that makes a lot of sense it's funny because
uh many people i mean as back when we're hitting we hit all-time highs earlier this week we're at

(18:21):
$2.5 trillion market cap in most of the world.
It's focused on Bitcoin, just views it as this digital
capital good, which it certainly is. But I think
getting into the nitty gritty of policies like this,
or not even policies, but optimizations like this

(18:41):
really reminds me, at least in the Bitcoin
protocol, is extremely complex
And a lot of people are putting hundreds of millions, billions of dollars even into this asset or completely unaware of the sort of optimizations that you guys are working on.

(19:02):
And these kind of things don't require coordination with other groups.
So there's no new like peer to peer messages, no new format here.
So this is just piggybacking up things which have existed for many years, which helps with velocity for moving forward with things, but also limits what it can possibly do.

(19:23):
Larger changes might require more changes from a higher level, but then that requires more coordination with other projects, like B2CD as an example.
yeah and on that note like how how's that coordination improving or deprecating over
time is it getting harder to coordinate or well like i said i think most things are happening

(19:48):
within within the colored lines so in the lines for coloring which it just improves velocity but
But yeah, like there are no commonly used from scratch implementations of Bitcoin today that are not Bitcoin core, right?
So you have Bitcoin knots, which is a fork of Bitcoin core, but it has per version that has all the same features pretty much with extra things added on.

(20:17):
So that doesn't take coordination. But for example, BTCD is a few versions behind on things like, as far as I know, they don't implement the way of sharing transactions in the network using witness transaction ID.
So WTXID gossip. So this can impact decisions that Bitcoin Core makes internally, how we try to save bandwidth for our peers.

(20:44):
We have to be cognizant of what other nodes on the network, what are they doing, and that can affect things internally as well.
well i mean sticking on btcd there was an example that a couple years ago now at this point when
barack did that 999 of 1000 multi-sig yeah that knocked uh that knocked btcd off the network and

(21:07):
some lightning nodes for a period of time yeah so that was enabled by tap right yeah and there's
been other ones with so some fuzzing work i can't remember who did the fuzzing but the slight
difference in how the script interpreter uh executed a certain thing called find and delete

(21:30):
it's a very obscure function in the old script code base like this is like like bitcoin uh satoshi
era scripting that we don't use anymore in segwit or taproot but like these minor differences can
result in possible forking opportunities.
And if I remember right, that was even with
transactions that were standard.

(21:50):
Someone who's malicious could have forked off B2CD, but didn't.
So that was good.
It's hard. Very hard.
I mean, since you mentioned scripting, is there anything in version 30 that
involves scripting?
No. So the last, I don't think

(22:11):
The script interpreter is one big kind of scary area that you're hesitant to touch unless you really need to.
And during normal releases, there's almost no reason to touch it.
I would say the only thing that might touch is the Bookwing kernel with interface stuff, but I think not even then.
The last time I touched it was a couple of releases ago.

(22:35):
So the pay to anchor update, that's a very minor change.
That doesn't even change the definition of what's happening.
It's just like minor basically saying this is not an upgrade path anymore.
Let people use it.
So I would say in general, we don't touch scripting unless there's a consensus change we're trying to affect.

(23:00):
My research, I thought I read something about ephemeral anchors with 30.
is that okay no so that would be so go through the history so the femoral anchors is kind of
two concepts right there's the pay to anchor part which is the script that was 20.28.0 and then

(23:21):
ephemeral dust was the other part and that was in 29.0 so those have been out for about one two
release cycles um obviously this this package relay buff that we're deploying in 38 is going to
help but those key parts were already uh deployed in place all right that's right yeah and ephemeral

(23:42):
dust doesn't affect scripting whatsoever it's just it's just a rule that basically says you're
allowed to have one dust output if you spend it it's pretty simple um what are you most excited
about in version 30?
Hmm.

(24:03):
Yeah, a lot of the stuff
is kind of just like
not letting the network
fall apart kind of stuff.
I think a lot of the,
if I'm not exactly
answering the question,
but I think a lot of the work
has been done
at the security level.
Some excellent work
with the Brink fuzzing team.
So like Nicholas
and Marco DeLeon,

(24:25):
not Marco Falque.
And team have been doing great work with the fuzzing infrastructure.
So I feel like the assurances we have are much higher than prior years, including just going back a couple of versions.
I can go more into that if you'd like.
Well, I'd like you to go into more like not letting the network fall apart.

(24:48):
That's part of it, right?
I can get into this.
Yeah.
Yeah. So historically, one problem with Bitcoin releases is that it's hard to test everything end to end in a robust fashion where you have a bunch of layers.
So you have a networking stack where you're taking in random TCP IP data, you're talking to peers, you're receiving data from peers, you're processing data and like paths that depend on a bunch of context.

(25:16):
So it's hard to enumerate all the possible paths. And it's hard to do this in a test that's in a robust way.
But basically, Nicholas and a few others have been working on a fuzz harness, which is like putting random intelligent, but random data and inputting it directly into the binary and seeing if that if the behavior follows the what we assume to happen.

(25:42):
So basic ones is we assume that any message that appear consensus won't make us crash.
That's kind of obvious, but making it try to trace all the different code paths to make sure it doesn't crash is like a non-trivial thing.
The other thing you can do is do kind of this we call invariance checks, which are things like.

(26:05):
Any message that this one peer, so it's a peer A, peer A sends us a peer-to-peer message.
It should never cause us to disconnect peer B.
So an attacker shouldn't be able to connect to me and make me disconnect with the honest peer.
And so you can essentially set up a harness like that, do a few hundred iterations per second of different message patterns, including block headers, transaction announcements, pings, pongs, whatever.

(26:30):
Basically spewing stuff, valid or not, at the node and making sure that this connection, this connection of peer B stays, stays online.
And so there's been a number of historical kind of catches with this, and I think it'll be very nice to have going forward, especially with peer-to-peer changes or policy changes, too.

(26:52):
Is that specifically to stop something like an eclipse attack?
Yeah.
So that example, the invariance check of don't make me disconnect with my honest peer would be, yes, like I want to hear about all blocks that are honest or even transactions, too.
So one interesting with this orphanage update or how we're holding on to these orphan transactions, there's a fuzz harness that is essentially this.

(27:17):
You know, if the honest peer is staying within their limits, then another peer should never be able to evict the honest peer's things.
Right. And you could basically have the same exact thing.
Spears a bunch of data at it and make sure that nothing is ever evicted from this honest peer.
and so the level of assurance you get uh gets much higher i think i can go on all day about this but

(27:41):
you know well let's dig in more because there's a bunch of there's definitely with the price going
up a bunch of people are new to bitcoin but let's dig into this concept of an eclipse attack so try
to prevent this to make sure when you have a bitcoin node you have slots open that peers
connect to so that you can receive and pass on transactions and other data.

(28:03):
But the concept of an Eclipse attack is if you have malicious peers that take up all
of the slots interacting with your node, they can begin feeding you bad data and basically
ensure that you're not in consensus with belonging.
Yeah.
Bitcoin relies on the one honest peer assumption.
So as long as one peer that you've reached out to or has reached to you is honest, then

(28:26):
you can stay caught up on the best chain of blocks,
the heaviest chain of blocks.
And an eclipse attack is a way of trying,
it's an attacker using kind of arbitrary network means,
trying to trick you into not keeping on to a good person
or letting them go or not letting them in at all.
And so one way of doing that would be like,
send a message that causes you to disconnect a good person.

(28:47):
Right.
So.
Exactly.
why is it important to protect against these attacks as on this like how would well what would
what is the intent of yeah somebody so there's an eclipse attack so there's two two reasons why you
wouldn't want why an attacker would well two major reasons why an attacker would want to stop you

(29:10):
uh your attacker is another miner and you're a miner so you're mining blocks and they want to
partition you from the network, get you alone. So you think you're doing good work and making
the longest chain, but in reality, you're falling behind the rest of the network.
So, you know, if you're, if you're 30% of the network, if you can partition off 1%

(29:31):
pools off the network, suddenly your 30% becomes 35%, 40% over time. Right. And this benefits you
greatly because larger miners tend to fare better because they're just getting ahead.
The other would be, if you're not a miner,
it would be something like you run a lightning node
or a node that has a watchtower of any sort.

(29:52):
So you have like pre-sign vault transactions
and you want to watch when things are happening, right?
If a theft is occurring.
Lightning is the same idea.
A lightning party, counterparty,
is trying to defraud you going with an old state on chain.
You want to hear about the newest blocks as fast as possible and the fastest way to do that Well if you being if it being stopped entirely then you just never hear about it And then your money goes out the window

(30:19):
So yeah.
And lightning specifically with the, um, what's it called?
HTLCs.
Well, the HTLCs, but if you get Eclipse attacked and you don't know that your channel counterparty
has the specific transaction with your channel partner is not responding.
Commitment transaction.
Yeah.
Yeah. So they could have gone to chain with an old version long ago and you just never heard about it.

(30:44):
You're sitting there waiting. You're saying, that's weird. I'm not getting blocks, but things must be OK.
You know, maybe miners are slow. Right. And then on the other side, they actually have taken your money and run.
Yeah. And that takes it's two weeks for that or two weeks.
Depends. Yeah. So with Lightning specifically, that's up to the node operator and channel partner.

(31:08):
So you can say, I feel comfortable waiting with you running off with my money after half a day or one day.
That's really up to you.
And that's the reactive security model.
Basically, it's for better security, you should turn that dial way up.
So talking again about that L&D exploit crashing, like that's one example why you might want a longer delay,

(31:33):
because not only are you worried about eclipse attacks,
but you're worried about bugs and packages
and your internet getting cut off.
There's all sorts of reasons
that you'd want to have these time locks be longer.
Since you mentioned bugs,
as it pertains to bugs in V30,

(31:54):
would any be patched?
Surely.
So if you go to BitcoinCore.org,
I'm pulling up right now. There's the see my foot in my mouth here.
I find it releases security by development, security advisories.
This is the place to track all the publicly known vulnerabilities.

(32:17):
And so, for example, the latest one was a remote crash due to address spam.
And there it'll give you all the details of who, you know, what severity it's ranked.
So low, medium, high, which is basically a rough ranking of how easy it is to do and how bad is it to result in.

(32:41):
So the worst would be something like chain split, right?
Forking off people and making double spending happen.
Second least bad would be like I can send a message and it gets sent to everyone else and everyone crashes.
Right.
And you can keep going down the list, too.
This takes a bunch of setup.
it might cost some money and if i know a minor that kind of thing and that's kind of like the

(33:06):
strata there but if it's a and then also the the the severity also informs how long it takes to be
told about it because if it's something if it's a chain split if it's if it's unknown it's kind
of hard to do they might not tell you about it till a few releases after the fact example like

(33:26):
if it could be like only after the last vulnerable version is out of end of life so
we told you to update these last three years you didn't here's here's the vulnerability
versus something that's low which is like hey here's a new version and here's the vulnerability
so if there is a i believe a if there's a low vulnerability for 30 that's passed in 30.0 you

(33:52):
should hear about within a couple weeks. I believe that's how it works. I'd have to look at the
process again, but it was a big job to get that process lined up to make sure that people are
hearing about these things and understanding that the system still has flaws and needs to be
continuously fixed. Yeah. Being like updating the latest version, I think that's been a big part of

(34:16):
the conversation is this campaign to not update to v30,
which is anybody can run any version they want to,
as long as it's back compatible.
What would you say to the people out there telling people not to download?
I would say if you don't run your node with money,

(34:36):
it doesn't matter what you do.
I mean,
you might be missing out on a new RPC or something for like looking at your
mempool or something,
but it's not too interesting.
Um, staying up to date matters when you use money at stake and your security of your node at stake.
So money, if you're a business, you should be updating within when possible, especially minor versions.

(34:58):
So 28.something will be released at .3.
Um, I would recommend you upgrade to that if you can't update to 29.1 or 29.2 or 30.0.
So best case scenario, you update the latest and greatest because some fixes can't even be.
Some fixes are harder to do as a backport.

(35:20):
So all the way to old versions, basically, like this big change to like, you know, there'll be some big change to this script engine or something like that.
They're not going to mess with that for old versions unless unless the bug is easy to hit and becomes public or something like that.
I'm not saying this is the case, but that's just kind of the thought process here.

(35:44):
So I'd recommend stay off of end of life.
You know, so if you're on 27, get 28 at least, 28 dot whatever the last release was.
And then try out the new versions, too.
If you need to integrate it like BTC Pay Server and all those, you need to keep trying these new versions to make sure that if there's any API breaks, they get caught early and can get fixed or worked over at an appropriate speed.

(36:15):
Yeah.
And what benefits would a project like BTC Pay Server have upgrading to v30 beyond what we've already discussed with the peering?
I mean, it's less it's a less thing of benefits per se, but I mean, there's obviously the performance benefits that you get.

(36:35):
So faster IBD and whatnot, but also just access to the latest tooling fixes.
It's more about making sure that things aren't broken, because as an example, Bitcoin Core for a long time had maintained a series of patches for this thing called BDB,
which is a database format that the wallet used to use but this format is extremely

(36:59):
not maintained uh basically the original project maintainers quit a long time ago or don't don't
do the patches necessarily necessary so bitcoin core had to do that that support is officially
gone for 30.0 so there's a tool in there to migrate your wallet from to the new version
but if you're like running a larger software stack like btc pay server there's probably more

(37:24):
involvement on making sure that your users go from the old old format to the new format properly
and what is uh what is the new format did a bunch of developers simply just write new
database no it's just a sqlite i think uh okay yeah just like a standard format that works for

(37:46):
the sizes we care about.
It's a funny thing, because Esculite,
that's become extremely popular in recent years.
I've talked to Justin Moon a lot about the powers of Esculite.
Another thing we're dealing with, with Bitcoin
being released in 2009, and the tools that we're at

(38:06):
Satoshi's.
Every time the project gets to get rid of a dependency like BDB,
the better off we are because these like open SSL used to be a thing that we
had to have in consensus that was removed a long time ago.
There's all these different little projects that are basically re-implemented
just the parts we need and then the rest is removed or we use,

(38:30):
or we swap them out for really standard components.
Yeah.
So the last time we spoke about the op return was when we saw each other in
person in June, May or June? May, I think. May, BTC++, where a very, very interesting get together

(38:51):
of Bitcoin developers in Austin, Texas. And I guess just to cover that whole debate of OpReturn,
how would you frame it from your perspective? So I think that that was kind of where I
stopped paying attention because I went in person and was able to finally get out kind of like,

(39:12):
well, what's their like, what do they think the solution really is? We all agree there's
some level of problem. Some people think it's catastrophic. Some people think it's spammy and
noisy, but we don't love the JPEGs, but what do we do about it? And Bitcoin Core kind of people
have been saying, well, it's really hard to disentangle what's spam mechanically and

(39:35):
automatically without causing great centralization force and peer-to-peer problems in general,
right? We're trying to save the moneyness by punishing JPEGs, but then we end up hurting
the moneyness, the fundamental moneyness of Bitcoin. Whereas I asked like, hey, what is your
ultimate vision for Bitcoin Core if we went down your path? And essentially it ended up being

(39:59):
this argument of we'll have kind of a scripting language or possibly like, you know, this list of bad scripts that we have to pass around to other nodes.
And people are automatically updating their configuration scripts to like filter these.
And as you can see, like this kind of method is inherently centralizing.

(40:22):
And I basically came away with, I don't think this bridge is gappable.
there's been some efforts in the knots community to do this where you essentially have
a web of trust of filters and it just breaks the inherent moneyness of bitcoin and i don't
know what else there's to say about that i mean you can ask more questions of course

(40:43):
no i mean i think i fall in the camp of i hate the jpegs i think they're annoying i don't like
that they're bloating the UTXO set.
It was not even JPEG, it's just the arbitrary.
Ordinals, yeah.
Ordinals, arbitrary data.
Ordinals fills up the UTXO set, yeah.

(41:04):
Yeah.
Well, I guess let's jump into that.
The core argument for changing op return
and increasing the limit,
taking the limit cap off altogether,
basically comes down to the fact that
people that are injecting arbitrary data
into transactions are doing it in a non-optimal way that's bloating the UTXO seg, correct?

(41:30):
Yeah, almost everyone does what's called the description, which means in segwit or taproot,
you can put the JPEG essentially in the input side and you get the witness discount for it.
So you pay four times less. Op return is an older way of doing it, which costs four times as much.
and the argument is that if you need it to be in the if you need some sort of payload to be in the

(41:54):
output like let's say a cryptographic proof it's called a groth 16 zero knowledge proof that's too
big for it's bigger than 80 bytes but it needs to be somewhere in the transaction so what what
people were theorizing about doing actually had software to do is stuff it in utxos that
look like public keys. And so nodes have to store this forever

(42:18):
just in case someone tries to spend that output.
So if there's already these myriad of ways of embedding data
more or less harmful, basically we hand them the least harmful
method and say, here, use this one. I also have
personal opinions on kind of how opinionated we should be

(42:38):
about what the best wallet software is. So I worry
that if people set their own, you know,
hyper-specific arguments like not like arguments and knobs,
that it really causes mistakes
and ends up kneecapping the moneyness of Bitcoin in other ways.
So I'll give you one example.

(43:00):
For the Nots 29 release,
which is the latest release they have,
the new version of Lightning Channels
would not be able to propagate on their nodes
if you use the default settings.
And so I think that's a great example of either lack of communication on their part of what they're trying to filter or just ignorance, right, of what they're doing is causing the moneyness of Bitcoin to be heard for the sake of saving Bitcoin, so to speak, supposedly.

(43:30):
I can go more into that if you want.
Yeah, like how would it mess up the lightning channels?
so the new style lightning channels as well as the arc spark there's probably a few others
they're all using this pattern of the truck transactions so version three transactions
not only is it the version three being valid or to relay but it allows them to be zero fee

(43:56):
if paid for by a child so specifically in knots 29 the current release those are invalid
it does not allow those to propagate so your commitment transaction will simply be dropped
by your local node even if that was fixed then they also ban ephemeral dust so remember

(44:17):
this femoral dust is the rule where you're allowed to have a single dust output in transaction as
long as it's cleaned up immediately after in a package and they disallow the function where this
dust could be like one satoshi two satoshi all the way up to the dust limit so taproot the smallest
output is allowed normally as 330 satoshis so one through 329 would be considered invalid and simply

(44:45):
dropped even if it's spent and again the motivation here is to stop jpegs because ordinal theory
whatnot but in reality this is just like this feature is being used in the new lightning
channels like that that space of the feature is intended to be used and so this is essentially

(45:05):
going to kneecap anyone using the software and trying to do self-custodial payments using lightning
yeah when you say v3 transactions is that is that like version 3 of back 32 or no no no uh it it the transaction version numbers there a version field the version field 3 on 28 and and newer is it

(45:33):
considered standard for relay but it also enables things like uh zero p transactions
for technical reasons that i won't get into here but that's kind of like the gist of it
Yeah.
No, like you told me before we had recorded that you haven't been paying attention since BTC++,

(45:54):
but I think I came away from that way because I was highly, I don't want to say triggered,
but I was like a little emotional, like what is going on here?
I was a little demotivated.
I thought I thought there was a chance that we had bridged some some of this gap and come to an understanding where there's some solution.

(46:18):
But I just after that, I didn't think so. And I think it was it was born out to be true.
I just I don't you know, I don't see it months later.
No, you know, get a lot of there. And it's funny.
I've been a lot of people hopping in my benches on X and on YouTube and other places saying, why aren't you talking about this?
I don't want to breathe air into it.

(46:40):
I think I walked away from BTC++
with the conclusion in my mind
that these things are consensus valid.
There's nothing you can do
to stop valid transactions from getting in.
If you want to change it,
you're going to have the harder conversation
of soft work to change up return or something like that.

(47:03):
If you're not focused on that,
then I think you're looking for a Pyrrhic victory there.
And then, I mean, I guess to be critical of Bitcoin Core,
the project, I think we talked about this in May in person too.
I think it's just a massive communications PR failure.

(47:29):
I think that's why many people have gotten so triggered
and remain triggered.
The perception is that Bitcoin Core is changing policy rules arbitrarily
without talking to the broader Bitcoin user base.
Yeah, that's a little disappointing.

(47:50):
And I find it a little baffling that the response to that
is to switch to a distribution that changes policy on a whim of one guy
and completely ignorant.
I guess I'm being pointed here.
Mentioning these, they did not know they're breaking people's expectations of the network.

(48:11):
As far as I know, they haven't changed course.
Who's defending the moneyness of Bitcoin? I don't see how it would be them.
What do you think happens tomorrow? Do you think Bitcoin dies tomorrow when $1.30 is released?
I'm firmly on nothing ever happens team.
I think it's not a black swan event, no matter what.

(48:34):
It's like a very, very minor thing.
So I'm happy if people just update to relatively minor,
relatively recent releases just for the health of the network,
for security reasons, and also just the V3 transactions,
thermal dust, all those things getting out there.
It's good to see these getting traction in real life.

(48:55):
yeah
the uh
I said this on Rabbit Hole Recap I forget it was two or three weeks
ago but I
proclaimed
stated
during that episode like we're gonna look
back a year from now and we'll be laughing
that I think this is what I think

(49:15):
is gonna happen he knows what's gonna happen but
I'm also firmly in the
nothing ever happens cap and
yeah I think we'll look back
I remember we were fighting about that.
I think it's important to try to take some lessons from it, whatever those lessons are.
And then. I mean, some of the lessons are negative, right?

(49:37):
But basically doing what you can to keep your brand as far as like a infrastructure project, which doesn't lose people's money.
I think making that really your focus rather than trying to cater to every user at once, which is impossible, but also just trying to communicate that it's OK if people run their own node software that differs.

(50:01):
Right. It really is up to the person. Right. Self-sovereignty.
And I think people keep forgetting this fact that running the node 99.9% of the time is for you, right?
It's for your sovereignty, your security, your privacy.
You're not generally helping the network doing this.

(50:22):
Almost all the time, it's just for you.
And that's where the focus should be.
I think there is a broad misconception about
the power of an individual full node
and its influence on the rest of the network
it's funny rehashing these conversations that happened during the black wars

(50:43):
the concept of an economic node
I think you can definitely socially signal by running a certain version
of a certain implementation
but yeah,
the policy ends up being kind of like the mirror inverse of that,
right?
So the block size wars was the intolerant minority or intolerant minority
where basically it's like if a small fraction of economically motivated

(51:08):
users will reject things consensus,
then it kind of is brinksmanship involved that might enable software.
But with policy,
it's the inverse where a small,
small percent of people who are tolerant of a certain transaction format lets them through
in practice, even if 90% of the network doesn't.

(51:28):
And I think there's a bunch of metaphors here, like technical allegories, pretty much are
parallels.
That's a really good insight.
I never thought of it that way.
The inverse consensus versus policy.
Intolerant minority can affect consensus more than they could policy.

(51:48):
A tolerant minority can make more things relay.
They can't make less things relay.
An intolerant minority can affect consensus.
Like shrinking consensus is the easier part,
while expanding policy is the easier part on the policy side of things.

(52:10):
It's easy to expand.
It's hard to restrict.
It's kind of like the mirror universe here.
It's hard to hard fork.
It's easier to software.
in Relay, it's easier to expand, harder to restrict.
So, moving forward, when Doomsday comes and goes tomorrow,

(52:32):
we move on, I think the dust will settle.
A lot of questions around ossification,
what changes are needed in Bitcoin.
Obviously, Bitcoin Core isn't going to stop working on Bitcoin
after version 30 is released tomorrow,
and the same can be said for any other developer
working on any other implementation.

(52:53):
But in your mind, what are some of the top priorities
that people need to be focusing on
beyond what gets released tomorrow?
Well, I mean, doubling down on the security infrastructure,
but I already talked about that.
So aside from making sure that this multi-trillion dollar asset

(53:16):
doesn't fall over in the next few years.
There is a continuing conversation
on what people call covenants
or scripting softworks.
I think that'll continue.
Rusty Russell has submitted
a somewhat serious,
more concrete proposal
for his kind of rewrite
of Bitcoin script
where taking Bitcoin script

(53:39):
and turning it up to 11.
But there's a number of different ways
that script updates can be done.
like for what you're trying to accomplish and how you do it.
And that informs how you do it. So he has one way.
Russell O'Connor has simplicity, if you've read up about that.
And then AJ also has his own bullish kind of Lisp-based programming language.

(54:03):
And I think beyond the near term, we need a bigger discussion about
if we want to continue iterating on scripting in Bitcoin,
what's the best way to do it?
That's a big engineering question as well as, you know,
theoretical and engineering.
Yeah, I pulled Sharon a couple of months ago to talk about simplicity

(54:25):
launching on Liquid Mainnet.
And we talked about the potential of it getting implemented
at the protocol level.
It seems like simplicity, I mean, obviously,
Blockstream's been working on it.
I think the paper dropped, what, like 12 years ago,
maybe even longer ago.
and it's been talked about since then
finally got a live on mainnet on liquid

(54:48):
to basically showcase what could be done there
but it seems like simplicity has always appealed to me
but I think the common pushback is how are you going to get this
into
common pushback is oh it's very complicated it's a lot of lines of code
But if you look at any other proposal, they're making severe tradeoffs, too.

(55:14):
And I think the community will have to have an honest discussion that doesn't involve brinksmanship of like, you shouldn't be arguing necessarily that Bitcoin isn't worth the work, I would say like this.
because there are facets of simplicity or simplicity-like solutions that really appeal to me as well
that aren't maintained with the great script restoration or bullish.

(55:38):
And so I think this discussion has to be made.
More near term, Antoine and I have been working on a smaller proposal,
which is template hash, check system stack, and internal key.
Have you had Antoine on for that?
No.
Okay.
But a few months back, basically, it's a slight revision and reframing of another proposal where it's like CTV as well as checkstick from stack.

(56:05):
And we basically we became intrigued with this kind of pairing and did a ground up rethink of how we would do it post Taproot era.
And that was our proposal. Essentially, it's a CTV like widget that's TapScript only.
check stick from stack which is bit 348 and internal key which is bit 349 as is

(56:27):
what would you say to the ossifiers who are worried about the unforeseen consequences of
messing with something like bitcoin script because they would argue i would argue too
there was unforeseen consequences with the combination of segwit taproot with the ordinals
manifestation um i guess how do you how do you have conversations around that in really war game

(56:56):
through the potential for stuff like that yeah i mean that's an interesting question because
the things i felt that were deficient in taproot are probably not the same ones like from an
unforeseen perspective so when i look at lessons learned from i mean there's probably a bunch from

(57:16):
segwit but let's say from taproot since it's more recent we learned things like hey maybe we should
have more tooling in place before we actually talk about activation because in taproot the way keys
are published on the network there are these 32 byte keys what we call x only keys and this ended

(57:37):
up it's may or may not be the right decision in the end but we didn't have a fuller discussion
from the tooling side of things.
How do you make cryptographic protocols
with a slightly different public key format?
And it ended up complicating certain protocols.
I think it ended up okay,
but the lessons I took away were essentially,

(57:59):
hey, tooling needs to be much more defined
before these kind of larger changes are done.
And we're taking that to heart.
So part of our efforts is not only saying, hey, these capabilities, these opcodes and capabilities enable some cool use cases.
Hey, look at these blog posts we made.

(58:21):
But much further than that, we want to have the tooling ready to go, applications deployed in like SIGNET and maybe Customs Test Nets before we even talk about things like activation.
And we're far from that.
Even from a mind share perspective, we're far away.
But from a quality assurance perspective, we're also far away.

(58:44):
So that's kind of like the lesson I took away, I guess, from Taproot.
Yeah.
So like if it activated tomorrow, ideally we'd be able to have wallets that just spin up and use things the next day, right?
Or, you know, practically the next day.
With Taproot, it ended up being like this activated in 2019 or whatever.

(59:05):
And then like, oh, it took four more years for Mucig to be formalized and another two years to be standardized.
And PSPT support is taking years.
And ideally, more of this would have been done prior to activation.
And it's the same problem we have as Bitcoiners, as a species, as we're becoming more dependent to a degree on this.

(59:35):
and this monetary protocol is approaching $2.5 trillion in value.
Not only that, you mentioned it earlier,
we have all these different second-layer solutions,
whether it's Lightning, Liquid, ARK, Spark,
throw Xiaomi and Mintz in the bag as well.
Silent, no, not Silent Payments.

(59:56):
What does Spark use?
State Chains.
State Chains.
State Chains.
Silent Payments too, right?
All these, you have this whole tech stack that's all kind of interlinked in certain ways.
And the velocity is just kind of slow because there's a lot more layers to it.
Even if I snap my fingers and we got some magical software, it would still take years for adoption.

(01:00:18):
Yeah.
This is out of left field, but just because it's a big topic of conversation,
I think when it comes to like fuzz testing is...
ai help at all with this is there any uh any vibe coding that helps i was i was briefly considering
today could you get reasonable vibe coded buzz harnesses so making but with fuzz testing you

(01:00:43):
really want to make sure like you need a lot of subject matter expertise to define it otherwise
it does like basically really random and if it's really random data then it doesn't really make any
meaningful progress it's trying random numbers essentially with no understanding of what it's
doing but the way you can write the harness with intelligence so maybe there's like maybe there is

(01:01:04):
you know i wouldn't rule it out i think ai for writing testing is probably one of the best
avenues to go forward with in this space i'm not sure how much people have been doing it
i was just going to ask is anybody working on that probably what um what would you obviously
there's been a lot of controversy and shit slinging going on over the last eight months.

(01:01:27):
What would you say is the mental state of your average developer right now?
I mean, it depends. Obviously, this kind of drama makes maintainers more risk averse in some ways,
right? So risk averse could mean they're going to ignore issues longer or they're just going to

(01:01:49):
make snap decisions and just say like, this is the way it is.
Outside of that, I think people are ready to get back to work,
working on interesting things.
So like one project that I think will become more important as time goes on
possibly is AJ is working on this thing called template sharing,
which is, and we basically want these future relay discussions to be less

(01:02:16):
political.
And so one way of doing that is solving some parts of it technically that you kind of allow you're more likely to allow people to have different mental policies as long as it doesn't affect convergence of the network in blockchain terms.
So we don't want to slow down block propagation on the network to make mining fair.

(01:02:38):
So if there are like technical ways of mitigating this, even when people disagree on mental policies, that would be a big win.
And so I think arguing less about what a default number should be in a config file, I think going this way is more fruitful.
Yeah. What would you contend is the biggest risk to Bitcoin right now?

(01:03:05):
That's a great question. Biggest risk.
I mean, I think it's the legal one for users and developers still.
Um, it's, it's a, you know, stable coin people, I would say are a political force in America,
but still not quite there for Bitcoin.

(01:03:27):
Right.
Uh, we still don't have legal, like explicit legal protections in congressional writing,
promising that they won't jail us for writing code that helps people move money.
Right.
Um, privacy is going to be a big bear to tackle.
I think privacy is essentially illegal on the Internet, and they're going to want to keep it that way, even if people figure out how to do coin joins in mass and keep off chain.

(01:03:56):
I mean, just yesterday I was talking about Spark, the Spark service, how it's their policy to, on an indexer, publish every single transaction for every single account.
So if you have someone's Spark address or you get a single Bolt 11 invoice from them, a Spark user, you can look up their entire transaction history, including balance.

(01:04:21):
And my guess is they have their stated reasons, but my guess is they're worried about pushback from the federal government, whether that's invasive data requests or, you know, regulatory crackdown on their service for being, you know, not for money transmission.

(01:04:43):
I mean, they'll try to claim it. Right. So the government could still try to claim that their money transmitters, even though they claim they're not.
and this could be instigated by a service
offering practical privacy.
So I think that those are some of the finer
tightropes that are walking these wallet services.

(01:05:03):
Yeah, I saw you tweeting,
you're quote tweeting Wallace Satoshi,
which has moved to Spark.
Yeah.
As their backend.
Exactly.
And that's insane.
It's like anybody who's technical enough
can sort of probe that data.
Yeah, it's a little surprising.
I'm obviously not happy with it.

(01:05:24):
But I think to be clear for that thread, I'm bringing this up because wallets like end wallets like Wallet Satoshi have to somehow communicate these expectations of non-privacy to their users.
And I think that's very difficult.
Prior, like in previous iterations, they were the custodian.

(01:05:44):
And so Wallet Satoshi says, I'm not going to publish everything on a database.
but now they're relying on a backend that does.
How do you update the mental framework of, you know,
how do you get informed consent from your users for that?
That's really challenging.
And I'm not sure what the solution is for that.
Yeah, I'm just going to pull this up.

(01:06:09):
Yeah.
There isn't real privacy against the Spark operators
that everyone should be searchable in a public index So it like yeah they not even that is their stated that what they said so i feel comfortable saying that what they said um and then you can like uh ben carmen whipped up a tool
for me in about 10 minutes probably vibe coded it uh there we go so if you get someone's wall

(01:06:33):
satoshi invoice it immediately pulls up their account so i tested it on my own which i don't
use it seriously but you know it it would show my test transactions to my real lightning wallet
so you know that's like how do you communicate that to a user especially a new user how do you
communicate that to the user of venmo which has one you know they're maybe okay with the service

(01:07:00):
knowing but not everyone in the world knowing if they can switch a button um yeah no that's what i
I was going to say, it's like, even if the operator knows every transaction doesn't mean you broadcast.
I'd be more sympathetic if they just said, yeah, and we give you a button in the API or whatever to say, don't publish.

(01:07:21):
And then they just didn't do that.
I'd be pretty sympathetic to that.
Yeah.
Now, the privacy war is going to be a big one.
but uh i saw dan gold from page one dev kid uh a couple weeks ago it seems like they're making
good progress and when it comes to paid page one specifically i think we're gonna have to position

(01:07:44):
it as a way to uh as a sort of cost saving technology for exchanges specifically yeah
that's i mean that's the tough thing it seems like to make it palatable regulatory regulation
wise we have to say it's something else it is right pay join coin joins in general can be
potential savings lightning is a potential fee is a fee savings vehicle that gets you practical

(01:08:10):
certain certain levels of privacy better than non-chain um an arc spark well all these other
systems can also potentially offer those kind of privacy trade-offs maybe trojan horse
using the original systems, right?

(01:08:32):
Yeah.
That's why I don't know what your thoughts are on Chalmy and Mint,
but I love them.
I love the Cashew wallets and the Petty Mint wallets
that I interact with.
Yeah, I think the big challenge is who runs the Mint, right?
They cannot claim they're non-custodial

(01:08:53):
by any stretch of the imagination.
No.
So who runs them?
How much of a centralizing force is that?
Because it's more efficient if everyone's on the same mint.
Maybe there's decentralization back pressure from like, well, we have the lightning network that interconnects everything.

(01:09:17):
So maybe the centralization pressure isn't as big.
You just have like thousands of operators.
I mean, I guess we'll see.
Some people think the AIs are going to run them in.
They're going to recognize it's superior money for the agentic framework,
and they're just going to run them in.
Can I imagine conspiracy theories there?
Yeah.

(01:09:38):
But now we're getting into the philosophical side of things,
because no matter what part of the stack we're talking about,
like Spark has to make this privacy trade-off because of the government.
Maybe other things like Pajoin won't get implemented by exchanges
is because they're worried about the regulatory and compliance blowback.
Obviously, Chubby and Mintz can provide not only incredible privacy,

(01:10:01):
but since they're separate from Bitcoin and very modular,
you can build a literal new banking stack from scratch
that gives you all the functionalities you'd want from a banking service
with better, more secure tech,
minus the centralization pressures of the Mint operator.
it's like we have the potential to build an incredibly robust, secure, private financial system,

(01:10:27):
which arguably should be what everybody wants.
But for some, not for some reason, but the government just messes that up.
Yeah. Also, the user demand just isn't there for censorship-resistant payments.
I mean there obviously is some but in the west as an example no one seems to care and

(01:10:51):
what would make them care right what what events might transpire that will make them care and will
we will we be ready for them that's the other one too right we're building I think like general
hodl tech is pretty much solved I would say like Coinbase can seems to be doing okay with
a quadrillion Bitcoin or whatever, but you know, the,

(01:11:16):
the payment technology still isn't there.
And so if Bitcoin payments actually need to take off the non-pustodial way in
the future, the infrastructure needs to be there.
And I think that's kind of what we're looking at, looking at this future.
Hey, we had a good step in the right direction yesterday with the, uh,
square announcement. People were waiting for seven years for that. Yeah.

(01:11:38):
no I think the pressure is going to be digital ID
and my theory is that
they're going to try and thrust something
world coin or something like it on the masses
and people are not going to be fond of staring into the orb
and then they'll care
maybe yeah
yeah I mean now we're getting something like

(01:12:03):
do you have
Are you optimistic about the potential for the user experience and the products built on top of Bitcoin to get to a point where regardless of people desire to use peer to peer cash the experience is simply superior to the incumbent system that gets adopted because it better UX

(01:12:27):
I mean, it depends on the layer. It's already better than some things. International wires are trash and will continue to be trash for a long time.
But I think you'll, I mean, some of the payment UXs are really nice in Bitcoin, but a lot of them take steep trade-offs in the self-custody dimension.

(01:12:50):
You know, if you just park your money on, well, actually, this is where it still works, right?
Parking your Bitcoin on Coinbase is only useful if you're willing, if you're only interested in trading on Coinbase or using BaseChain or whatever.
But if you want to actually send someone over the light network of payment, I think it still works.
But there's all this regulatory pressure to not let it succeed. Right.

(01:13:12):
And I think that's where all the friction is. So I did this.
I did this last week. We had we had a 1031 off site with the portfolio companies.
We're at this resort and over the course of the three days, got to know some of the people working at the resort.

(01:13:33):
particularly the bar.
And last night, go to tip him.
He's got a Coinbase account.
I was like, I'll send it over Lightning.
And the UX was just completely abysmal.
And I thought, like, I got a confirmation on my end,
but it never hit his account.
And I got a confirmation that the payment was received.
But from what I understand, and I didn't realize this until after,
I left him.

(01:13:53):
Coinbase is asking users that accept Bitcoin over Lightning
to ask for personal information of the counterparty.
Exactly.
Yeah.
The transaction.
It's like, what?
Yeah, that's I think.
It's it's incredibly centralizing in that no one will want to do that.
But if transactions, the payments, the payments volume isn't high enough that people won't jump that hurdle to go on the other side.

(01:14:21):
If money is sitting in an ETF or what everyone's happy with, they don't need to.
Ask permission because it's not going anywhere.
But if you want to make payments, this is where all this friction shows up, especially especially if you're trying to send from a coin.
base or regulated institution.
Well, I don't
know if we can fix that aside from
legal changes.

(01:14:41):
It's completely immoral
though. Like I sent the Bitcoin, like I sent it
for my wallet.
I'm making a descriptive.
Oh, I know. But like just like I'm thinking about
I was thinking about it through. I was like, wait, I
sent $15, $20 for
the Bitcoin, whatever it was, to this wallet.
Like obviously it's centralized Coinbase
presenting and running the
lightning node presenting the invoice they have the bitcoin sitting somewhere in their account

(01:15:06):
the guy that i sent it to light spark does i think but yeah yeah light spark whatever it's sitting
somewhere in a centralized third party and that guy's never going to get the money and i send 20
bucks and i'm never going to get back because i don't think this guy's going to be able to find
me to ask me for my home address and all that and when he does i'm not going to give it to him i'll
i'll say spin up another invoice using using zeus or something like that and i'll send you the bitcoin

(01:15:30):
there but the coinbase just holds that money now yeah so i think i think that's where you'll see
the right like if spark does take off that that's the niche it'll fit uh there's an unfortunate
privacy thing but if you if you're willing to accept a system that says itself can self-custodial
kind of is trust odial at least um maybe that's enough for users to get onboarded

(01:15:56):
but is that a world we want to go to versus something more private this is like a big challenge
yeah i mean talking to matt corralo earlier this year he's pretty optimistic that uh self-custodial
lightning will see a step function improvement uh better it's it's definitely better than before

(01:16:18):
um i think a lot of you'll hear like oh this new layer two will fix all lightnings you know
all the issues lightning has but you look under the hood it's either making custody trade-offs
security trade-offs or it's or it's making the same assumptions as like lightning needs
improvement so it's like oh it's instant transactions they say how do you get instant

(01:16:42):
transactions oh you just trust this person not to sign twice like come on like you know that's
zero comp trust right so i think there's a in this industry there's still a bit of that even
in the Bitcoin side. It's kind of hiding
what models people are buying into.
But I'm optimistic
too. So I think there's enough there
for another 5-10

(01:17:04):
years of
development and smoothing of
processes.
Yeah. And in the meantime, in parallel
to your point,
we need to wage the campaign to abolish
the Bank Secrecy Act where all this
insane
privacy infringing
compliance and regulation comes from.

(01:17:25):
Can we somehow get the BSA as a person to insult Trump or something?
I'm trying to think of a way of instigating constitutional crisis,
because then maybe the courts will strike it down anyways.
It's like, yeah, it wasn't constitutional anyways.
Yeah.
No, it is insane.
We're dealing with the remnants of mistakes made many decades ago.

(01:17:47):
Funnily enough, 1970, I think, is when the BSA was implemented.
It interesting to see the thing that was vaguely probably not constitutional at the time accepted because we didn have computing widely Now that flipped and kind of seeing the straws being grasped by the statists who want

(01:18:10):
everything to be reported at all times.
It's really stark, I guess.
Yeah.
And admittedly, I haven't been following it as closely as it probably should be.
But last I heard, there was this doesn't have anything to do with privacy.
but to your earlier point about legal ramifications of writing open source software that allows people to use Bitcoin in a peer-to-peer fashion.

(01:18:34):
There was positive language in the Clarity Act, which hasn't been passed yet.
I don't know if it's been taken out or revised out.
It has not yet been taken out, but there's always a worry that until the job's done, it's going to get horse traded for something else, right?
Because again, you have the stablecoin bros, stablecoin contingent, and you've got the kind of Elizabeth Warren contingent at the moment.

(01:18:59):
And people are worried that Elizabeth Warren actually hates Bitcoin more than she hates to stablecoins.
So maybe a trade would happen there.
I'm optimistic long term, but you need to actually battle this out in Congress and in the courts.

(01:19:20):
Well, I mean, I think my I'm going to call it a pipe dream, but would be incredibly badass is that if they did push and put the regulatory pressure on, if you just got back to the site for Punk Roots and you just had a bunch of synonymous devs pop up and just start launching things without anybody knowing who they are.
So I have a slightly contrarian point of view on this, I guess. Yeah, I think it's a good idea of something like that. But I see America as a potential base for freedom through freedom of speech and computing.

(01:19:53):
And if I just snap my fingers and America became the place where all development, all non-custodial development is blessed legally and protected 100%.
And there's no question that you're going to be dragged out of your house because your system helped enable someone else to do money laundering.

(01:20:14):
I think that'd be a huge win for the world.
And I think we can push that way.
I don't think that everything bad for me as a developer is good for Bitcoin, I guess is my point.
I think we can kind of push the other direction and make it easier in countries with law and order, potentially more law and order, and export that goodness worldwide through the Internet.

(01:20:38):
Craig, I like that. I like that optimistic view. We should lead, by example.
I still have
I said earlier
I mean
the potential
the tools
the potential
it's all right
like we can build
yeah
an incredibly
transparent
robust
resilient
secure
relatively private
financial system

(01:20:59):
the potential's there
in general
freedom of speech
has gotten stronger
and stronger
in the United States
the one caveat is
oh but you did
talked about money
and suddenly this is like
a legal loophole
to throw you in jail forever
so I think like
just keep maximizing these first amendment gains as far as we can in the next
few years. Right. I think, I think it's possible.

(01:21:23):
I did too. Let's keep pushing. Yep. It's been awesome. This is the, uh,
this is the first time in a while I've, uh, gone deep on Bitcoin core stuff.
It always reignites the subdued nerd in me.

(01:21:46):
It makes me miss New York bit devs in the heydays
when I would nerd out with this stuff.
I think I went to probably 80% of the bit devs between 2015 and 2020.
and it's
easy to forget
the intricacies

(01:22:06):
and the complexity involved
in actually maintaining
and improving the Bitcoin
protocol
most people
are completely unaware
yeah like
with anything else there's a lot going under the hood
it doesn't directly
it's not a feature

(01:22:27):
for the user so it's hard to see
and show value
no i'm thinking too like as more institute like you have faith that uh the last question you have
faith that like as more institutions get in if banks get in that they'll have tech departments
that will understand the importance of understanding the intricacies of the protocol level

(01:22:51):
that i don't know i can't i think it's kind of we're also in an eternal september kind of situation
I would have expected
more
industry feedback
in a direct way
but you don't get that
people don't even really complain when things are broken

(01:23:11):
it is like a
there's a feedback loop problem with development
so
looking forward to find ways to solve that too
especially as things get bigger
think about it freaks
alright any final thoughts before we wrap up here
I appreciate you having me on
and excited for the future

(01:23:32):
still
future two days from now
Bitcoin dies tomorrow
so enjoy it while it lasts for you
because you've got 24 hours
yeah
all Bitcoin transactions are legal in the next 24 hours
alright see ya
thanks
peace and love freaks

(01:23:55):
Stick it.

All Episodes

Episode Transcript

Popular Podcasts

CrimeLess: Hillbilly Heist

Crime Junkie

Stuff You Should Know

.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;}#671: What's Really in Bitcoin Core Version 30 with Instagibbs

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}CrimeLess: Hillbilly Heist

Crime Junkie

Stuff You Should Know

All Episodes

#671: What's Really in Bitcoin Core Version 30 with Instagibbs

CrimeLess: Hillbilly Heist