1
00:00:00,000 --> 00:00:01,920
Got to be spicy, Greg.

2
00:00:01,980 --> 00:00:06,760
We meet here on the on the eve of Bitcoin's death, October 9th, 2025.

3
00:00:08,080 --> 00:00:09,600
Bitcoin Core version 30.

4
00:00:10,520 --> 00:00:10,660
Yeah.

5
00:00:11,720 --> 00:00:12,440
Drops tomorrow.

6
00:00:13,560 --> 00:00:14,140
Very somber.

7
00:00:14,540 --> 00:00:15,080
Very somber.

8
00:00:16,900 --> 00:00:21,780
In all seriousness, though, I think a lot of discussion as we were just talking.

9
00:00:21,780 --> 00:00:29,860
before we hit record has revolved around obviously this op return debate whether or not the limit

10
00:00:29,860 --> 00:00:36,720
should be lifted or not and the potential consequences of doing that maybe we'll touch

11
00:00:36,720 --> 00:00:44,000
on that but i think um there hasn't been enough discussion on everything else that's included in

12
00:00:44,000 --> 00:00:51,660
bitcoin core version 30 so i wanted to sit down with you and talk about what bitcoin core has

13
00:00:51,660 --> 00:00:58,900
been working on with this particular version and i think before we do that for the layman out there

14
00:00:58,900 --> 00:01:08,180
maybe we just do like a high level um a high level refresher of what bitcoin core is what

15
00:01:08,180 --> 00:01:17,980
what is entailed in um basically releasing um new versions particularly significant versions

16
00:01:17,980 --> 00:01:23,220
like version 30 and then we can jump into the nitty-gritty of what's included.

17
00:01:24,120 --> 00:01:26,520
Sure. You want me to take the lead on this?

18
00:01:26,920 --> 00:01:27,320
Yes, sir.

19
00:01:27,920 --> 00:01:34,240
All right. So basically there's a Bitcoin Core software is the reference client, so to speak,

20
00:01:34,360 --> 00:01:40,480
where it has majority kind of mind share and running share of the Bitcoin protocol itself.

21
00:01:40,960 --> 00:01:46,360
It includes a bunch of different parts, peer-to-peer layer stuff, consensus stuff.

22
00:01:47,980 --> 00:01:54,340
A wallet, which people still use, a bunch of other tools and pieces in there.

23
00:01:55,680 --> 00:01:57,800
A major release is done every six months.

24
00:01:58,140 --> 00:02:03,580
So on a six-month cadence, there's what's called a feature freeze, which is, hey, stop adding new things.

25
00:02:04,520 --> 00:02:07,300
We're going to continue just doing bug fixes until this time.

26
00:02:07,700 --> 00:02:17,320
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.

27
00:02:17,320 --> 00:02:22,320
and then eventually a release, right, with a series of release candidates,

28
00:02:22,460 --> 00:02:24,800
which is happening right now, and then eventually a final release.

29
00:02:25,680 --> 00:02:30,180
In addition to this, you also have kind of using this forked history

30
00:02:30,180 --> 00:02:36,200
that if there's future bugs found, if and when there are future bugs found

31
00:02:36,200 --> 00:02:40,020
and issues, the fixes can be applied directly on these forked off histories

32
00:02:40,020 --> 00:02:41,320
and do minor releases.

33
00:02:41,320 --> 00:02:46,580
So someday I will very highly likely have a 30.1 for various reasons.

34
00:02:47,320 --> 00:03:01,440
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.

35
00:03:02,140 --> 00:03:16,180
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.

36
00:03:16,180 --> 00:03:21,340
we won't do any effort to like update maintenance to this make build and make binaries or anything

37
00:03:21,340 --> 00:03:28,920
like that and then it kind of gets stale and so that's kind of the life cycle yeah yeah and

38
00:03:28,920 --> 00:03:34,340
taking even further step back just on the concept of implementations right you have bitcoin

39
00:03:34,340 --> 00:03:43,760
or consensus and then implementations like core knots the bitcoin uh ptcd they sort of

40
00:03:43,760 --> 00:03:49,620
have their own implementations that build software that is within consensus but does things

41
00:03:49,620 --> 00:03:55,540
a little differently correct yeah so some are complete implementations so btcd is a

42
00:03:55,540 --> 00:04:03,780
good example that's been around a long time um it has it's programmed in go the golang and it has

43
00:04:03,780 --> 00:04:08,820
a complete implementation of the consensus software so when you get a string of bytes

44
00:04:08,820 --> 00:04:14,700
in the form of a blockchain, it needs to come out to the same exact answer as Bitcoin D or any other

45
00:04:14,700 --> 00:04:23,540
implementation. The re-implementation raises the chance that there is mismatches, but those can

46
00:04:23,540 --> 00:04:31,620
hopefully be ironed out and debugged and fixed over time. But there's definitely always, it's a

47
00:04:31,620 --> 00:04:36,860
very demanding problem, making sure they're in lockstep of consensus. And even between Bitcoin

48
00:04:36,860 --> 00:04:43,060
versions, there's been historical problems with that, where implementation details, like

49
00:04:43,060 --> 00:04:48,900
how the database is stored, causes forks in the future, right?

50
00:04:48,960 --> 00:04:50,740
With unforeseen events.

51
00:04:51,200 --> 00:04:56,440
It's been a long time since it's happened, but it's always possible with updates or not

52
00:04:56,440 --> 00:04:57,140
updating too.

53
00:04:58,620 --> 00:04:58,780
Yeah.

54
00:04:59,280 --> 00:05:06,520
And where would you say we are in terms of the path of Bitcoin Core?

55
00:05:06,520 --> 00:05:12,680
I remember my first BitDevs in New York in 2015.

56
00:05:14,120 --> 00:05:16,800
Russ Janofsky basically presented on SegWit.

57
00:05:17,000 --> 00:05:19,780
And obviously we had SegWit getting implemented.

58
00:05:20,120 --> 00:05:24,360
But I think one thing over the year, over the last 12 years,

59
00:05:24,420 --> 00:05:27,640
has been made clear to me is that Satoshi, when he launched Bitcoin,

60
00:05:27,840 --> 00:05:29,680
was a bit of a spaghetti code base.

61
00:05:29,940 --> 00:05:33,820
And there's been a lot of work to sort of separate things

62
00:05:33,820 --> 00:05:38,120
within that code base, particularly, or not particularly, but one thing being like the

63
00:05:38,120 --> 00:05:40,100
wallet and the GUI.

64
00:05:40,840 --> 00:05:46,760
And it feels like the last decade of Bitcoin core development specifically has been trying

65
00:05:46,760 --> 00:05:54,460
to get the implementation to a point where things are separated appropriately, more modular,

66
00:05:54,460 --> 00:06:02,880
and you can begin to do things that make it more complex, make it easier to build more

67
00:06:02,880 --> 00:06:06,300
complex applications on top of the Bitcoin protocol layer.

68
00:06:07,380 --> 00:06:13,160
Yeah, there's definitely, that's one of the major things happening is historically splitting

69
00:06:13,160 --> 00:06:18,520
out these functionalities, getting them into their own containers that can be tested separately.

70
00:06:19,160 --> 00:06:25,240
So focusing on like the charlatan he's been working on, he's been continuing carrying this

71
00:06:25,240 --> 00:06:27,500
torch on the LibBitcoin kernel.

72
00:06:27,500 --> 00:06:39,900
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.

73
00:06:41,180 --> 00:06:49,200
It's not exactly, you know, a lot of this work is not glamorous in that there's cost benefits to be weighed.

74
00:06:49,200 --> 00:06:54,940
the cost is here is that when you're refactoring these very critical parts of the code base,

75
00:06:55,060 --> 00:06:56,920
most of the consensus, not wallet.

76
00:06:57,640 --> 00:07:01,480
I mean, wallet's important in its own way, but for the consensus parts,

77
00:07:01,700 --> 00:07:04,480
making sure that when you're changing this code to make it modular,

78
00:07:04,600 --> 00:07:06,880
you're not also changing the behavior, which is very difficult.

79
00:07:07,340 --> 00:07:13,840
So as you said, Satoshi started with main.cpp, one big file that has wallet, consensus, peer-to-peer.

80
00:07:13,840 --> 00:07:15,900
It just says everything just jumbled in it.

81
00:07:15,900 --> 00:07:20,900
And it's been a long process of carefully teasing these pieces out, which is continuing today.

82
00:07:21,980 --> 00:07:26,780
One big project is the inter-process communication interface.

83
00:07:27,340 --> 00:07:30,300
So there's this project basically split up to different binaries.

84
00:07:30,500 --> 00:07:36,400
So you can have your Bitcoin node communicate with your Bitcoin wallet over interface, different binaries.

85
00:07:36,740 --> 00:07:44,960
Or in the future, you could have the peer-to-peer parts handled only by a separate binary or different ideas like that.

86
00:07:44,960 --> 00:07:53,100
but this is like future roadmap stuff yeah well sticking on current roadmap stuff like beyond

87
00:07:53,100 --> 00:07:59,200
op return which is obviously the most talked about feature in core version 30 i'm looking at

88
00:07:59,200 --> 00:08:04,880
my notes now looks like there's going to be removal of checkpoint support and depreciation

89
00:08:04,880 --> 00:08:13,040
of checkpoints uh changes to data carrier size behavior and deprecation plan support for multiple

90
00:08:13,040 --> 00:08:18,600
op return outputs per transaction p2p relay mempool adjustments rate limiting and denial

91
00:08:18,600 --> 00:08:23,700
services protections refactoring internal cleanup infrastructure so there's much beyond

92
00:08:23,700 --> 00:08:31,020
yeah up return up return as well yeah let's start on checkpoints because i think that right

93
00:08:31,020 --> 00:08:35,380
has been uh not very controversial but i think people have very uh depending on who you talk to

94
00:08:35,380 --> 00:08:42,940
um very uh specific views on checkpoints for the good or the bad is removing them good or bad

95
00:08:42,940 --> 00:09:07,780
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?

96
00:09:07,780 --> 00:09:11,460
of one miner and they make a long block header chain,

97
00:09:11,840 --> 00:09:15,580
a very weak difficulty, and they intercept you right when you're getting connected

98
00:09:15,580 --> 00:09:18,800
to the network and just feeds you these headers.

99
00:09:19,660 --> 00:09:23,800
These headers, based on the current architecture at the time, are just

100
00:09:23,800 --> 00:09:27,860
written to disk. And so these are 80 bytes each. And so if you do enough, you're essentially

101
00:09:27,860 --> 00:09:31,760
just writing 80 bytes of data over and over and over to disk.

102
00:09:32,160 --> 00:09:35,320
And this is called a header disk fill attack.

103
00:09:35,320 --> 00:09:43,420
Like these checkpoints were basically saying, OK, up until this point, we're not going to accept any forks in the blockchain history.

104
00:09:43,680 --> 00:09:48,140
It must get to this point. And then it continues doing validation after that.

105
00:09:48,140 --> 00:09:59,700
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.

106
00:09:59,700 --> 00:10:05,480
therefore um it makes the attack that much harder but that was like the original motivation

107
00:10:05,480 --> 00:10:11,560
because it was a real attack and correct me if i'm wrong but wasn't there

108
00:10:11,560 --> 00:10:18,640
aren't the way the checkpoints are sort of like verified or um decide upon that you have like a

109
00:10:18,640 --> 00:10:22,720
number of developers basically just sign like this is the right checkpoint this is the right yeah

110
00:10:22,720 --> 00:10:29,680
exactly add a new checkpoint all you need to do well let's see for check i haven't thought

111
00:10:29,680 --> 00:10:35,580
of us in a while, but you want to make sure that reorg will not happen beyond that point.

112
00:10:35,660 --> 00:10:37,620
So it has to be very deep, right?

113
00:10:37,840 --> 00:10:41,760
It's qualitatively different than another feature called assume valid.

114
00:10:42,600 --> 00:10:45,500
So this one, you have to say that we will never fork this one out.

115
00:10:45,940 --> 00:10:51,540
And so it's kind of labor intensive to like philosophically argue that is 300,000 blocks,

116
00:10:51,760 --> 00:10:52,000
correct?

117
00:10:52,140 --> 00:10:53,880
400,000, things like that.

118
00:10:53,880 --> 00:10:57,840
And it's because you really are saying like, I will not devorge from this history.

119
00:10:58,560 --> 00:10:59,380
But yes.

120
00:10:59,680 --> 00:11:04,100
ostensibly you get into a GitHub pull request.

121
00:11:04,240 --> 00:11:06,120
Somebody says, I'm updating it to this height.

122
00:11:06,620 --> 00:11:09,020
So 500,000 or something like that.

123
00:11:09,400 --> 00:11:12,660
This is the hash and everyone sits there and makes sure that, yeah,

124
00:11:12,720 --> 00:11:15,600
there's been 500,000 blocks on top of it since then.

125
00:11:16,000 --> 00:11:17,680
And this hash matches.

126
00:11:18,000 --> 00:11:19,120
That would be a verification.

127
00:11:20,000 --> 00:11:20,120
Yeah.

128
00:11:20,800 --> 00:11:21,680
And how's that?

129
00:11:22,120 --> 00:11:23,580
What's being replaced?

130
00:11:23,660 --> 00:11:26,360
Is that headers precinct or something like that?

131
00:11:26,680 --> 00:11:27,080
Exactly.

132
00:11:27,080 --> 00:11:29,100
So there's this long, this idea,

133
00:11:29,100 --> 00:11:32,340
this is years and years of an idea where you could say, okay,

134
00:11:32,400 --> 00:11:34,160
what if we have a, when we're first,

135
00:11:34,260 --> 00:11:35,860
when you're freshly syncing with the network,

136
00:11:36,200 --> 00:11:39,500
you just have a broad idea of like how many,

137
00:11:40,060 --> 00:11:42,700
how much proof of work you should be expecting.

138
00:11:42,860 --> 00:11:44,840
So you connect to the network and say, I'm expecting, you know,

139
00:11:45,340 --> 00:11:49,920
this many X, I can't even say the hashes or whatever. Right.

140
00:11:50,600 --> 00:11:54,760
And then you get this, you get fed this header chain,

141
00:11:54,760 --> 00:11:57,380
but instead of committing to disk, you just walk the whole chain,

142
00:11:57,380 --> 00:12:02,460
the whole way until you hit that minimum proof of work requirement that you've internally

143
00:12:02,460 --> 00:12:07,860
internalized. Once you hit it, you say, okay, that looks good. I've gotten all this way and I've only

144
00:12:07,860 --> 00:12:12,020
stored one header at a time in memory. Now that I've gotten this way, I'm going to do it backwards

145
00:12:12,020 --> 00:12:17,820
again. You just sync it twice. So you sync the headers once to verify that your disk is not going

146
00:12:17,820 --> 00:12:23,760
to be filled. And then you sync again to actually write to disk. And this, along with a bunch of

147
00:12:23,760 --> 00:12:29,080
extra testing work allows you to remove checkpoints entirely from the code base.

148
00:12:29,980 --> 00:12:35,360
Does that have any IBD trade-offs in terms of time?

149
00:12:35,960 --> 00:12:39,940
Yeah, I think with the current implementation, if you have a flappy internet connection,

150
00:12:40,020 --> 00:12:43,100
which I had once when I was testing, I was testing by flapping the internet connection.

151
00:12:43,760 --> 00:12:50,500
During the precinct, before you've finished the first pass, if it gets interrupted,

152
00:12:50,500 --> 00:12:53,340
like your peer drops for whatever reason, it has to restart.

153
00:12:53,760 --> 00:12:55,620
So that shouldn't happen.

154
00:12:55,660 --> 00:12:59,480
I haven't seen that since I was testing it, but that's one constraint there.

155
00:12:59,560 --> 00:13:01,400
So you need to be able to download the header chain once.

156
00:13:01,960 --> 00:13:05,340
As soon as that's done, it goes like historical.

157
00:13:05,340 --> 00:13:14,860
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.

158
00:13:15,760 --> 00:13:15,900
Yeah.

159
00:13:15,900 --> 00:13:31,900
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?

160
00:13:33,940 --> 00:13:36,800
Are you talking about initial block download or just this?

161
00:13:36,800 --> 00:13:40,260
IBD, you can even talk like peer-to-peer level.

162
00:13:40,260 --> 00:13:49,140
um, uh, obviously, uh, or transactions going to be, um, matriculated through the,

163
00:13:49,140 --> 00:13:54,980
the peer to peer network faster. Sure. So on the, the checkpoints front,

164
00:13:55,680 --> 00:14:01,780
front that doesn't improve efficiency at all. That's just a philosophical, uh, change to make

165
00:14:01,780 --> 00:14:08,020
it clear that the core devs are not in charge of what your chain is. Um, but from a performance

166
00:14:08,020 --> 00:14:13,140
perspective, there's been a bunch of work done by Lawrence who has focused on, especially on the

167
00:14:13,140 --> 00:14:18,320
lower end of hardware, for initial block download. I haven't paid very close attention to that,

168
00:14:18,660 --> 00:14:28,040
but I know it's happening. The other kind of transaction robustness, right, for the peer-to-peer

169
00:14:28,040 --> 00:14:35,460
network, there's been a bunch of work both on, there's this thing called the transaction orphanage

170
00:14:35,460 --> 00:14:37,760
and also package relay.

171
00:14:38,380 --> 00:14:40,820
So I'll start with the orphanage part

172
00:14:40,820 --> 00:14:44,020
where if you turn your node on for the first time

173
00:14:44,020 --> 00:14:46,720
and your mempool is empty,

174
00:14:47,080 --> 00:14:48,720
people will start telling you about transactions

175
00:14:48,720 --> 00:14:52,140
which have dependencies in the mempool itself,

176
00:14:52,220 --> 00:14:53,420
but you don't have them.

177
00:14:53,700 --> 00:14:57,780
So for example, you get a second generation transaction

178
00:14:57,780 --> 00:14:59,100
that depends on a first.

179
00:15:00,060 --> 00:15:12,740
Right now prior to 30 this process is a little flaky and can be interrupted by direct peers who are either malicious or malfunctioning

180
00:15:12,920 --> 00:15:16,480
So 30.0 has a significant improvement to that.

181
00:15:16,600 --> 00:15:25,460
It was spearheaded by Gloria, Peter, and others to make this robust to single peers being malicious or even end peers being malicious.

182
00:15:25,660 --> 00:15:30,620
So as long as you have one honest peer, you can make this kind of transaction catch up in the mempool.

183
00:15:31,860 --> 00:15:35,740
is this for like child pays for parent and RBF only or?

184
00:15:36,700 --> 00:15:41,400
No, not only. So this, it is, it was aimed at it.

185
00:15:41,480 --> 00:15:43,840
So it was aimed at the kind of one parent,

186
00:15:43,920 --> 00:15:46,240
one child package relay project,

187
00:15:46,240 --> 00:15:49,240
which was deployed in full on 28.0.

188
00:15:50,320 --> 00:15:55,060
But the existing implementation had this weakness where if a single peer

189
00:15:55,060 --> 00:15:55,740
connects to you,

190
00:15:55,800 --> 00:15:59,980
they can throw garbage at you and basically empty out this, this cache.

191
00:16:00,080 --> 00:16:01,640
Right. So basically it's,

192
00:16:01,860 --> 00:16:05,180
the way of connecting the dots in your mempool

193
00:16:05,180 --> 00:16:07,400
is to get disrupted by a single peer.

194
00:16:08,200 --> 00:16:12,580
And the new implementation of what's called the orphanage,

195
00:16:12,680 --> 00:16:14,840
finding your parent, this is robust,

196
00:16:14,940 --> 00:16:17,540
even if you have N-1 connections being attackers.

197
00:16:17,540 --> 00:16:22,080
So basically the one honest peer can take up a slot

198
00:16:22,080 --> 00:16:26,880
and make honest CPFPs and package relay attempts

199
00:16:26,880 --> 00:16:29,020
at least one at a time.

200
00:16:30,060 --> 00:16:30,660
So...

201
00:16:31,860 --> 00:16:39,260
I'm trying to visualize that. You have, let's say, out of the box, eight peers, seven of them are malicious.

202
00:16:40,560 --> 00:16:41,320
Internet is just.

203
00:16:42,220 --> 00:16:47,720
So they're feeding you orphan garbage, so stuff they don't intend to ever fix, right?

204
00:16:47,840 --> 00:16:50,360
So really, it's just stuff that doesn't cost them anything.

205
00:16:50,560 --> 00:16:52,440
They're just handing you data to look at and hold.

206
00:16:52,800 --> 00:16:57,220
But basically, instead of one big global bucket, which it was before, there's like a global bucket.

207
00:16:57,220 --> 00:17:01,560
So one peer could just go in and switch out the buckets of contents you have.

208
00:17:01,560 --> 00:17:08,260
end buckets and these end buckets can be shared it uses some optimistic pathing like optimistic

209
00:17:08,260 --> 00:17:14,120
assumptions about using the whole space by one peer but under kind of these loads where either

210
00:17:14,120 --> 00:17:21,280
things are very busy or the peers being malicious then we protect at least uh we have a protections

211
00:17:21,280 --> 00:17:27,360
slots for each peer essentially to make sure that economically valid transactions are propagated

212
00:17:27,360 --> 00:17:33,840
yeah i'm just trying to think how would uh how does the node software determine that the

213
00:17:33,840 --> 00:17:40,580
one peer providing you good data is actually the right data so it's not scoring or anything like

214
00:17:40,580 --> 00:17:47,580
that uh it's just saying i think the if i remember right it's saying a maximum transaction package

215
00:17:47,580 --> 00:17:53,800
can be like this big like 101 kilovitual bytes it says i'll protect that much per peer

216
00:17:53,800 --> 00:17:59,900
so whether or not the peer is malicious or not doesn't affect this number it's just something

217
00:17:59,900 --> 00:18:05,880
you allocate for that peer so it doesn't it doesn't take like historical note of who's

218
00:18:05,880 --> 00:18:13,660
given you useful things it just allocates that yeah that makes a lot of sense it's funny because

219
00:18:13,660 --> 00:18:21,440
uh many people i mean as back when we're hitting we hit all-time highs earlier this week we're at

220
00:18:21,440 --> 00:18:25,160
$2.5 trillion market cap in most of the world.

221
00:18:25,380 --> 00:18:29,460
It's focused on Bitcoin, just views it as this digital

222
00:18:29,460 --> 00:18:33,500
capital good, which it certainly is. But I think

223
00:18:33,500 --> 00:18:37,400
getting into the nitty gritty of policies like this,

224
00:18:37,440 --> 00:18:41,520
or not even policies, but optimizations like this

225
00:18:41,520 --> 00:18:45,500
really reminds me, at least in the Bitcoin

226
00:18:45,500 --> 00:18:49,920
protocol, is extremely complex

227
00:18:49,920 --> 00:19:01,780
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.

228
00:19:02,040 --> 00:19:06,880
And these kind of things don't require coordination with other groups.

229
00:19:07,280 --> 00:19:11,120
So there's no new like peer to peer messages, no new format here.

230
00:19:11,120 --> 00:19:22,560
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.

231
00:19:23,700 --> 00:19:33,740
Larger changes might require more changes from a higher level, but then that requires more coordination with other projects, like B2CD as an example.

232
00:19:33,740 --> 00:19:40,840
yeah and on that note like how how's that coordination improving or deprecating over

233
00:19:40,840 --> 00:19:48,220
time is it getting harder to coordinate or well like i said i think most things are happening

234
00:19:48,220 --> 00:19:55,660
within within the colored lines so in the lines for coloring which it just improves velocity but

235
00:19:55,660 --> 00:20:07,620
But yeah, like there are no commonly used from scratch implementations of Bitcoin today that are not Bitcoin core, right?

236
00:20:08,100 --> 00:20:17,920
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.

237
00:20:17,920 --> 00:20:32,900
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.

238
00:20:32,900 --> 00:20:44,540
So WTXID gossip. So this can impact decisions that Bitcoin Core makes internally, how we try to save bandwidth for our peers.

239
00:20:44,700 --> 00:20:52,240
We have to be cognizant of what other nodes on the network, what are they doing, and that can affect things internally as well.

240
00:20:52,240 --> 00:20:59,180
well i mean sticking on btcd there was an example that a couple years ago now at this point when

241
00:20:59,180 --> 00:21:07,380
barack did that 999 of 1000 multi-sig yeah that knocked uh that knocked btcd off the network and

242
00:21:07,380 --> 00:21:17,880
some lightning nodes for a period of time yeah so that was enabled by tap right yeah and there's

243
00:21:17,880 --> 00:21:23,600
been other ones with so some fuzzing work i can't remember who did the fuzzing but the slight

244
00:21:23,600 --> 00:21:30,100
difference in how the script interpreter uh executed a certain thing called find and delete

245
00:21:30,100 --> 00:21:36,860
it's a very obscure function in the old script code base like this is like like bitcoin uh satoshi

246
00:21:36,860 --> 00:21:42,220
era scripting that we don't use anymore in segwit or taproot but like these minor differences can

247
00:21:42,220 --> 00:21:44,360
result in possible forking opportunities.

248
00:21:45,600 --> 00:21:48,160
And if I remember right, that was even with

249
00:21:48,160 --> 00:21:49,920
transactions that were standard.

250
00:21:50,160 --> 00:21:54,000
Someone who's malicious could have forked off B2CD, but didn't.

251
00:21:54,220 --> 00:21:55,320
So that was good.

252
00:21:56,960 --> 00:21:58,700
It's hard. Very hard.

253
00:21:59,840 --> 00:22:03,840
I mean, since you mentioned scripting, is there anything in version 30 that

254
00:22:03,840 --> 00:22:07,060
involves scripting?

255
00:22:09,240 --> 00:22:11,880
No. So the last, I don't think

256
00:22:11,880 --> 00:22:18,100
The script interpreter is one big kind of scary area that you're hesitant to touch unless you really need to.

257
00:22:19,400 --> 00:22:23,100
And during normal releases, there's almost no reason to touch it.

258
00:22:23,100 --> 00:22:29,180
I would say the only thing that might touch is the Bookwing kernel with interface stuff, but I think not even then.

259
00:22:30,160 --> 00:22:34,720
The last time I touched it was a couple of releases ago.

260
00:22:35,060 --> 00:22:38,620
So the pay to anchor update, that's a very minor change.

261
00:22:38,620 --> 00:22:42,220
That doesn't even change the definition of what's happening.

262
00:22:42,340 --> 00:22:48,720
It's just like minor basically saying this is not an upgrade path anymore.

263
00:22:48,860 --> 00:22:50,120
Let people use it.

264
00:22:51,000 --> 00:22:55,740
So I would say in general, we don't touch scripting unless there's a consensus change we're trying to affect.

265
00:23:00,940 --> 00:23:07,260
My research, I thought I read something about ephemeral anchors with 30.

266
00:23:07,260 --> 00:23:14,400
is that okay no so that would be so go through the history so the femoral anchors is kind of

267
00:23:14,400 --> 00:23:21,460
two concepts right there's the pay to anchor part which is the script that was 20.28.0 and then

268
00:23:21,460 --> 00:23:28,640
ephemeral dust was the other part and that was in 29.0 so those have been out for about one two

269
00:23:28,640 --> 00:23:36,580
release cycles um obviously this this package relay buff that we're deploying in 38 is going to

270
00:23:36,580 --> 00:23:42,480
help but those key parts were already uh deployed in place all right that's right yeah and ephemeral

271
00:23:42,480 --> 00:23:47,320
dust doesn't affect scripting whatsoever it's just it's just a rule that basically says you're

272
00:23:47,320 --> 00:23:58,020
allowed to have one dust output if you spend it it's pretty simple um what are you most excited

273
00:23:58,020 --> 00:24:00,020
about in version 30?

274
00:24:01,560 --> 00:24:01,800
Hmm.

275
00:24:03,700 --> 00:24:04,800
Yeah, a lot of the stuff

276
00:24:04,800 --> 00:24:05,740
is kind of just like

277
00:24:05,740 --> 00:24:07,120
not letting the network

278
00:24:07,120 --> 00:24:08,100
fall apart kind of stuff.

279
00:24:08,240 --> 00:24:10,040
I think a lot of the,

280
00:24:11,160 --> 00:24:12,240
if I'm not exactly

281
00:24:12,240 --> 00:24:13,100
answering the question,

282
00:24:13,260 --> 00:24:14,840
but I think a lot of the work

283
00:24:14,840 --> 00:24:15,600
has been done

284
00:24:15,600 --> 00:24:17,020
at the security level.

285
00:24:18,040 --> 00:24:19,140
Some excellent work

286
00:24:19,140 --> 00:24:21,000
with the Brink fuzzing team.

287
00:24:21,000 --> 00:24:22,120
So like Nicholas

288
00:24:22,120 --> 00:24:25,180
and Marco DeLeon,

289
00:24:25,880 --> 00:24:26,740
not Marco Falque.

290
00:24:28,020 --> 00:24:31,520
And team have been doing great work with the fuzzing infrastructure.

291
00:24:31,880 --> 00:24:39,660
So I feel like the assurances we have are much higher than prior years, including just going back a couple of versions.

292
00:24:41,040 --> 00:24:43,820
I can go more into that if you'd like.

293
00:24:44,520 --> 00:24:47,040
Well, I'd like you to go into more like not letting the network fall apart.

294
00:24:48,560 --> 00:24:49,880
That's part of it, right?

295
00:24:49,880 --> 00:24:51,500
I can get into this.

296
00:24:52,240 --> 00:24:52,360
Yeah.

297
00:24:52,360 --> 00:25:02,880
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.

298
00:25:02,880 --> 00:25:15,940
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.

299
00:25:16,360 --> 00:25:22,260
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.

300
00:25:22,360 --> 00:25:42,720
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.

301
00:25:42,720 --> 00:25:47,880
So basic ones is we assume that any message that appear consensus won't make us crash.

302
00:25:47,880 --> 00:25:57,700
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.

303
00:25:58,400 --> 00:26:03,780
The other thing you can do is do kind of this we call invariance checks, which are things like.

304
00:26:05,140 --> 00:26:10,860
Any message that this one peer, so it's a peer A, peer A sends us a peer-to-peer message.

305
00:26:11,000 --> 00:26:13,340
It should never cause us to disconnect peer B.

306
00:26:14,080 --> 00:26:18,320
So an attacker shouldn't be able to connect to me and make me disconnect with the honest peer.

307
00:26:19,220 --> 00:26:30,560
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.

308
00:26:30,820 --> 00:26:39,860
Basically spewing stuff, valid or not, at the node and making sure that this connection, this connection of peer B stays, stays online.

309
00:26:39,860 --> 00:26:50,900
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.

310
00:26:52,700 --> 00:26:55,360
Is that specifically to stop something like an eclipse attack?

311
00:26:56,720 --> 00:26:57,000
Yeah.

312
00:26:57,200 --> 00:27:06,360
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.

313
00:27:06,360 --> 00:27:16,860
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.

314
00:27:17,600 --> 00:27:25,400
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.

315
00:27:25,860 --> 00:27:28,360
Right. And you could basically have the same exact thing.

316
00:27:29,300 --> 00:27:33,440
Spears a bunch of data at it and make sure that nothing is ever evicted from this honest peer.

317
00:27:33,440 --> 00:27:41,480
and so the level of assurance you get uh gets much higher i think i can go on all day about this but

318
00:27:41,480 --> 00:27:46,540
you know well let's dig in more because there's a bunch of there's definitely with the price going

319
00:27:46,540 --> 00:27:52,020
up a bunch of people are new to bitcoin but let's dig into this concept of an eclipse attack so try

320
00:27:52,020 --> 00:27:57,080
to prevent this to make sure when you have a bitcoin node you have slots open that peers

321
00:27:57,080 --> 00:28:03,020
connect to so that you can receive and pass on transactions and other data.

322
00:28:03,180 --> 00:28:07,820
But the concept of an Eclipse attack is if you have malicious peers that take up all

323
00:28:07,820 --> 00:28:13,680
of the slots interacting with your node, they can begin feeding you bad data and basically

324
00:28:13,680 --> 00:28:16,900
ensure that you're not in consensus with belonging.

325
00:28:17,120 --> 00:28:17,360
Yeah.

326
00:28:18,240 --> 00:28:20,820
Bitcoin relies on the one honest peer assumption.

327
00:28:21,080 --> 00:28:26,300
So as long as one peer that you've reached out to or has reached to you is honest, then

328
00:28:26,300 --> 00:28:29,780
you can stay caught up on the best chain of blocks,

329
00:28:29,920 --> 00:28:31,420
the heaviest chain of blocks.

330
00:28:31,960 --> 00:28:33,440
And an eclipse attack is a way of trying,

331
00:28:33,640 --> 00:28:36,840
it's an attacker using kind of arbitrary network means,

332
00:28:36,920 --> 00:28:39,560
trying to trick you into not keeping on to a good person

333
00:28:39,560 --> 00:28:41,680
or letting them go or not letting them in at all.

334
00:28:42,220 --> 00:28:44,060
And so one way of doing that would be like,

335
00:28:44,380 --> 00:28:47,080
send a message that causes you to disconnect a good person.

336
00:28:47,080 --> 00:28:47,420
Right.

337
00:28:48,160 --> 00:28:48,460
So.

338
00:28:50,160 --> 00:28:50,720
Exactly.

339
00:28:50,720 --> 00:28:59,320
why is it important to protect against these attacks as on this like how would well what would

340
00:28:59,320 --> 00:29:05,960
what is the intent of yeah somebody so there's an eclipse attack so there's two two reasons why you

341
00:29:05,960 --> 00:29:10,300
wouldn't want why an attacker would well two major reasons why an attacker would want to stop you

342
00:29:10,300 --> 00:29:15,980
uh your attacker is another miner and you're a miner so you're mining blocks and they want to

343
00:29:15,980 --> 00:29:20,840
partition you from the network, get you alone. So you think you're doing good work and making

344
00:29:20,840 --> 00:29:24,360
the longest chain, but in reality, you're falling behind the rest of the network.

345
00:29:25,060 --> 00:29:31,160
So, you know, if you're, if you're 30% of the network, if you can partition off 1%

346
00:29:31,160 --> 00:29:39,720
pools off the network, suddenly your 30% becomes 35%, 40% over time. Right. And this benefits you

347
00:29:39,720 --> 00:29:44,480
greatly because larger miners tend to fare better because they're just getting ahead.

348
00:29:45,460 --> 00:29:47,780
The other would be, if you're not a miner,

349
00:29:47,960 --> 00:29:50,040
it would be something like you run a lightning node

350
00:29:50,040 --> 00:29:52,760
or a node that has a watchtower of any sort.

351
00:29:52,900 --> 00:29:56,160
So you have like pre-sign vault transactions

352
00:29:56,160 --> 00:29:58,660
and you want to watch when things are happening, right?

353
00:29:58,680 --> 00:29:59,860
If a theft is occurring.

354
00:30:00,480 --> 00:30:01,660
Lightning is the same idea.

355
00:30:03,040 --> 00:30:05,400
A lightning party, counterparty,

356
00:30:05,900 --> 00:30:08,560
is trying to defraud you going with an old state on chain.

357
00:30:09,380 --> 00:30:19,220
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

358
00:30:19,880 --> 00:30:21,100
So yeah.

359
00:30:21,160 --> 00:30:25,040
And lightning specifically with the, um, what's it called?

360
00:30:26,660 --> 00:30:27,140
HTLCs.

361
00:30:27,300 --> 00:30:32,480
Well, the HTLCs, but if you get Eclipse attacked and you don't know that your channel counterparty

362
00:30:32,480 --> 00:30:37,300
has the specific transaction with your channel partner is not responding.

363
00:30:37,300 --> 00:30:38,260
Commitment transaction.

364
00:30:38,500 --> 00:30:38,680
Yeah.

365
00:30:38,720 --> 00:30:43,760
Yeah. So they could have gone to chain with an old version long ago and you just never heard about it.

366
00:30:44,120 --> 00:30:48,400
You're sitting there waiting. You're saying, that's weird. I'm not getting blocks, but things must be OK.

367
00:30:49,280 --> 00:30:56,060
You know, maybe miners are slow. Right. And then on the other side, they actually have taken your money and run.

368
00:30:57,040 --> 00:31:01,840
Yeah. And that takes it's two weeks for that or two weeks.

369
00:31:02,020 --> 00:31:08,520
Depends. Yeah. So with Lightning specifically, that's up to the node operator and channel partner.

370
00:31:08,720 --> 00:31:16,320
So you can say, I feel comfortable waiting with you running off with my money after half a day or one day.

371
00:31:16,400 --> 00:31:17,640
That's really up to you.

372
00:31:17,920 --> 00:31:19,820
And that's the reactive security model.

373
00:31:19,820 --> 00:31:24,980
Basically, it's for better security, you should turn that dial way up.

374
00:31:25,280 --> 00:31:33,260
So talking again about that L&D exploit crashing, like that's one example why you might want a longer delay,

375
00:31:33,260 --> 00:31:35,960
because not only are you worried about eclipse attacks,

376
00:31:36,040 --> 00:31:38,660
but you're worried about bugs and packages

377
00:31:38,660 --> 00:31:42,520
and your internet getting cut off.

378
00:31:42,700 --> 00:31:43,840
There's all sorts of reasons

379
00:31:43,840 --> 00:31:46,520
that you'd want to have these time locks be longer.

380
00:31:48,800 --> 00:31:50,320
Since you mentioned bugs,

381
00:31:50,740 --> 00:31:53,460
as it pertains to bugs in V30,

382
00:31:54,980 --> 00:31:57,420
would any be patched?

383
00:31:59,760 --> 00:32:00,280
Surely.

384
00:32:00,700 --> 00:32:02,500
So if you go to BitcoinCore.org,

385
00:32:02,500 --> 00:32:08,240
I'm pulling up right now. There's the see my foot in my mouth here.

386
00:32:08,440 --> 00:32:13,480
I find it releases security by development, security advisories.

387
00:32:13,820 --> 00:32:16,460
This is the place to track all the publicly known vulnerabilities.

388
00:32:17,600 --> 00:32:25,220
And so, for example, the latest one was a remote crash due to address spam.

389
00:32:25,220 --> 00:32:31,720
And there it'll give you all the details of who, you know, what severity it's ranked.

390
00:32:31,720 --> 00:32:41,060
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.

391
00:32:41,260 --> 00:32:45,220
So the worst would be something like chain split, right?

392
00:32:45,840 --> 00:32:49,820
Forking off people and making double spending happen.

393
00:32:50,660 --> 00:32:56,060
Second least bad would be like I can send a message and it gets sent to everyone else and everyone crashes.

394
00:32:57,120 --> 00:32:57,240
Right.

395
00:32:57,240 --> 00:32:59,560
And you can keep going down the list, too.

396
00:32:59,960 --> 00:33:01,100
This takes a bunch of setup.

397
00:33:01,100 --> 00:33:06,020
it might cost some money and if i know a minor that kind of thing and that's kind of like the

398
00:33:06,020 --> 00:33:16,620
strata there but if it's a and then also the the the severity also informs how long it takes to be

399
00:33:16,620 --> 00:33:21,380
told about it because if it's something if it's a chain split if it's if it's unknown it's kind

400
00:33:21,380 --> 00:33:26,620
of hard to do they might not tell you about it till a few releases after the fact example like

401
00:33:26,620 --> 00:33:33,440
if it could be like only after the last vulnerable version is out of end of life so

402
00:33:33,440 --> 00:33:39,500
we told you to update these last three years you didn't here's here's the vulnerability

403
00:33:39,500 --> 00:33:45,160
versus something that's low which is like hey here's a new version and here's the vulnerability

404
00:33:45,160 --> 00:33:52,420
so if there is a i believe a if there's a low vulnerability for 30 that's passed in 30.0 you

405
00:33:52,420 --> 00:33:56,980
should hear about within a couple weeks. I believe that's how it works. I'd have to look at the

406
00:33:56,980 --> 00:34:03,180
process again, but it was a big job to get that process lined up to make sure that people are

407
00:34:03,180 --> 00:34:07,580
hearing about these things and understanding that the system still has flaws and needs to be

408
00:34:07,580 --> 00:34:16,240
continuously fixed. Yeah. Being like updating the latest version, I think that's been a big part of

409
00:34:16,240 --> 00:34:20,500
the conversation is this campaign to not update to v30,

410
00:34:21,400 --> 00:34:24,120
which is anybody can run any version they want to,

411
00:34:24,220 --> 00:34:25,200
as long as it's back compatible.

412
00:34:26,280 --> 00:34:31,080
What would you say to the people out there telling people not to download?

413
00:34:32,020 --> 00:34:36,820
I would say if you don't run your node with money,

414
00:34:36,820 --> 00:34:38,220
it doesn't matter what you do.

415
00:34:38,620 --> 00:34:39,020
I mean,

416
00:34:39,360 --> 00:34:43,340
you might be missing out on a new RPC or something for like looking at your

417
00:34:43,340 --> 00:34:44,140
mempool or something,

418
00:34:44,240 --> 00:34:45,480
but it's not too interesting.

419
00:34:46,240 --> 00:34:51,240
Um, staying up to date matters when you use money at stake and your security of your node at stake.

420
00:34:51,380 --> 00:34:58,640
So money, if you're a business, you should be updating within when possible, especially minor versions.

421
00:34:58,640 --> 00:35:02,920
So 28.something will be released at .3.

422
00:35:03,560 --> 00:35:10,500
Um, I would recommend you upgrade to that if you can't update to 29.1 or 29.2 or 30.0.

423
00:35:10,500 --> 00:35:16,580
So best case scenario, you update the latest and greatest because some fixes can't even be.

424
00:35:17,720 --> 00:35:20,520
Some fixes are harder to do as a backport.

425
00:35:20,660 --> 00:35:29,040
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.

426
00:35:29,440 --> 00:35:38,100
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.

427
00:35:38,100 --> 00:35:42,640
I'm not saying this is the case, but that's just kind of the thought process here.

428
00:35:44,620 --> 00:35:48,000
So I'd recommend stay off of end of life.

429
00:35:48,760 --> 00:35:54,840
You know, so if you're on 27, get 28 at least, 28 dot whatever the last release was.

430
00:35:55,180 --> 00:35:58,460
And then try out the new versions, too.

431
00:35:58,460 --> 00:36:13,700
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.

432
00:36:15,140 --> 00:36:15,280
Yeah.

433
00:36:17,100 --> 00:36:26,260
And what benefits would a project like BTC Pay Server have upgrading to v30 beyond what we've already discussed with the peering?

434
00:36:26,260 --> 00:36:35,700
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.

435
00:36:35,700 --> 00:36:41,400
So faster IBD and whatnot, but also just access to the latest tooling fixes.

436
00:36:42,200 --> 00:36:52,420
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,

437
00:36:52,420 --> 00:36:59,940
which is a database format that the wallet used to use but this format is extremely

438
00:36:59,940 --> 00:37:06,560
not maintained uh basically the original project maintainers quit a long time ago or don't don't

439
00:37:06,560 --> 00:37:13,220
do the patches necessarily necessary so bitcoin core had to do that that support is officially

440
00:37:13,220 --> 00:37:18,180
gone for 30.0 so there's a tool in there to migrate your wallet from to the new version

441
00:37:18,180 --> 00:37:24,860
but if you're like running a larger software stack like btc pay server there's probably more

442
00:37:24,860 --> 00:37:32,340
involvement on making sure that your users go from the old old format to the new format properly

443
00:37:32,340 --> 00:37:38,140
and what is uh what is the new format did a bunch of developers simply just write new

444
00:37:38,140 --> 00:37:46,620
database no it's just a sqlite i think uh okay yeah just like a standard format that works for

445
00:37:46,620 --> 00:37:47,980
the sizes we care about.

446
00:37:49,200 --> 00:37:52,920
It's a funny thing, because Esculite,

447
00:37:53,020 --> 00:37:56,080
that's become extremely popular in recent years.

448
00:37:56,200 --> 00:37:58,960
I've talked to Justin Moon a lot about the powers of Esculite.

449
00:38:00,440 --> 00:38:02,820
Another thing we're dealing with, with Bitcoin

450
00:38:02,820 --> 00:38:06,980
being released in 2009, and the tools that we're at

451
00:38:06,980 --> 00:38:07,880
Satoshi's.

452
00:38:08,880 --> 00:38:12,960
Every time the project gets to get rid of a dependency like BDB,

453
00:38:12,960 --> 00:38:18,580
the better off we are because these like open SSL used to be a thing that we

454
00:38:18,580 --> 00:38:21,700
had to have in consensus that was removed a long time ago.

455
00:38:21,920 --> 00:38:25,900
There's all these different little projects that are basically re-implemented

456
00:38:25,900 --> 00:38:29,360
just the parts we need and then the rest is removed or we use,

457
00:38:30,280 --> 00:38:32,800
or we swap them out for really standard components.

458
00:38:33,800 --> 00:38:33,940
Yeah.

459
00:38:37,140 --> 00:38:40,760
So the last time we spoke about the op return was when we saw each other in

460
00:38:40,760 --> 00:38:51,020
person in June, May or June? May, I think. May, BTC++, where a very, very interesting get together

461
00:38:51,020 --> 00:38:59,860
of Bitcoin developers in Austin, Texas. And I guess just to cover that whole debate of OpReturn,

462
00:38:59,860 --> 00:39:06,380
how would you frame it from your perspective? So I think that that was kind of where I

463
00:39:06,380 --> 00:39:11,920
stopped paying attention because I went in person and was able to finally get out kind of like,

464
00:39:12,180 --> 00:39:17,960
well, what's their like, what do they think the solution really is? We all agree there's

465
00:39:17,960 --> 00:39:22,300
some level of problem. Some people think it's catastrophic. Some people think it's spammy and

466
00:39:22,300 --> 00:39:29,800
noisy, but we don't love the JPEGs, but what do we do about it? And Bitcoin Core kind of people

467
00:39:29,800 --> 00:39:35,260
have been saying, well, it's really hard to disentangle what's spam mechanically and

468
00:39:35,260 --> 00:39:43,640
automatically without causing great centralization force and peer-to-peer problems in general,

469
00:39:43,720 --> 00:39:48,460
right? We're trying to save the moneyness by punishing JPEGs, but then we end up hurting

470
00:39:48,460 --> 00:39:54,960
the moneyness, the fundamental moneyness of Bitcoin. Whereas I asked like, hey, what is your

471
00:39:54,960 --> 00:39:59,300
ultimate vision for Bitcoin Core if we went down your path? And essentially it ended up being

472
00:39:59,300 --> 00:40:12,780
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.

473
00:40:13,060 --> 00:40:17,160
And people are automatically updating their configuration scripts to like filter these.

474
00:40:17,640 --> 00:40:22,660
And as you can see, like this kind of method is inherently centralizing.

475
00:40:22,860 --> 00:40:26,840
And I basically came away with, I don't think this bridge is gappable.

476
00:40:26,840 --> 00:40:31,420
there's been some efforts in the knots community to do this where you essentially have

477
00:40:31,420 --> 00:40:39,980
a web of trust of filters and it just breaks the inherent moneyness of bitcoin and i don't

478
00:40:39,980 --> 00:40:43,980
know what else there's to say about that i mean you can ask more questions of course

479
00:40:43,980 --> 00:40:55,480
no i mean i think i fall in the camp of i hate the jpegs i think they're annoying i don't like

480
00:40:55,480 --> 00:40:57,660
that they're bloating the UTXO set.

481
00:40:58,120 --> 00:41:00,000
It was not even JPEG, it's just the arbitrary.

482
00:41:00,580 --> 00:41:01,060
Ordinals, yeah.

483
00:41:01,320 --> 00:41:02,580
Ordinals, arbitrary data.

484
00:41:02,840 --> 00:41:04,200
Ordinals fills up the UTXO set, yeah.

485
00:41:04,900 --> 00:41:05,160
Yeah.

486
00:41:06,120 --> 00:41:07,900
Well, I guess let's jump into that.

487
00:41:08,080 --> 00:41:12,440
The core argument for changing op return

488
00:41:12,440 --> 00:41:14,880
and increasing the limit,

489
00:41:15,340 --> 00:41:17,200
taking the limit cap off altogether,

490
00:41:18,020 --> 00:41:21,460
basically comes down to the fact that

491
00:41:21,460 --> 00:41:24,460
people that are injecting arbitrary data

492
00:41:24,460 --> 00:41:29,800
into transactions are doing it in a non-optimal way that's bloating the UTXO seg, correct?

493
00:41:30,560 --> 00:41:36,940
Yeah, almost everyone does what's called the description, which means in segwit or taproot,

494
00:41:37,540 --> 00:41:43,840
you can put the JPEG essentially in the input side and you get the witness discount for it.

495
00:41:43,840 --> 00:41:49,540
So you pay four times less. Op return is an older way of doing it, which costs four times as much.

496
00:41:49,540 --> 00:41:54,780
and the argument is that if you need it to be in the if you need some sort of payload to be in the

497
00:41:54,780 --> 00:42:02,200
output like let's say a cryptographic proof it's called a groth 16 zero knowledge proof that's too

498
00:42:02,200 --> 00:42:07,920
big for it's bigger than 80 bytes but it needs to be somewhere in the transaction so what what

499
00:42:07,920 --> 00:42:14,400
people were theorizing about doing actually had software to do is stuff it in utxos that

500
00:42:14,400 --> 00:42:18,500
look like public keys. And so nodes have to store this forever

501
00:42:18,500 --> 00:42:21,020
just in case someone tries to spend that output.

502
00:42:22,760 --> 00:42:26,680
So if there's already these myriad of ways of embedding data

503
00:42:26,680 --> 00:42:30,640
more or less harmful, basically we hand them the least harmful

504
00:42:30,640 --> 00:42:34,600
method and say, here, use this one. I also have

505
00:42:34,600 --> 00:42:38,540
personal opinions on kind of how opinionated we should be

506
00:42:38,540 --> 00:42:42,560
about what the best wallet software is. So I worry

507
00:42:42,560 --> 00:42:46,100
that if people set their own, you know,

508
00:42:46,680 --> 00:42:49,480
hyper-specific arguments like not like arguments and knobs,

509
00:42:49,480 --> 00:42:52,940
that it really causes mistakes

510
00:42:52,940 --> 00:42:57,340
and ends up kneecapping the moneyness of Bitcoin in other ways.

511
00:42:57,600 --> 00:42:59,440
So I'll give you one example.

512
00:43:00,200 --> 00:43:01,960
For the Nots 29 release,

513
00:43:02,080 --> 00:43:03,820
which is the latest release they have,

514
00:43:05,040 --> 00:43:07,220
the new version of Lightning Channels

515
00:43:07,220 --> 00:43:10,820
would not be able to propagate on their nodes

516
00:43:10,820 --> 00:43:12,500
if you use the default settings.

517
00:43:12,560 --> 00:43:30,280
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.

518
00:43:30,940 --> 00:43:32,280
I can go more into that if you want.

519
00:43:33,020 --> 00:43:35,560
Yeah, like how would it mess up the lightning channels?

520
00:43:35,560 --> 00:43:43,920
so the new style lightning channels as well as the arc spark there's probably a few others

521
00:43:43,920 --> 00:43:48,600
they're all using this pattern of the truck transactions so version three transactions

522
00:43:48,600 --> 00:43:56,780
not only is it the version three being valid or to relay but it allows them to be zero fee

523
00:43:56,780 --> 00:44:03,660
if paid for by a child so specifically in knots 29 the current release those are invalid

524
00:44:03,660 --> 00:44:09,360
it does not allow those to propagate so your commitment transaction will simply be dropped

525
00:44:09,360 --> 00:44:17,720
by your local node even if that was fixed then they also ban ephemeral dust so remember

526
00:44:17,720 --> 00:44:23,040
this femoral dust is the rule where you're allowed to have a single dust output in transaction as

527
00:44:23,040 --> 00:44:29,560
long as it's cleaned up immediately after in a package and they disallow the function where this

528
00:44:29,560 --> 00:44:36,720
dust could be like one satoshi two satoshi all the way up to the dust limit so taproot the smallest

529
00:44:36,720 --> 00:44:45,100
output is allowed normally as 330 satoshis so one through 329 would be considered invalid and simply

530
00:44:45,100 --> 00:44:53,920
dropped even if it's spent and again the motivation here is to stop jpegs because ordinal theory

531
00:44:53,920 --> 00:44:59,760
whatnot but in reality this is just like this feature is being used in the new lightning

532
00:44:59,760 --> 00:45:05,680
channels like that that space of the feature is intended to be used and so this is essentially

533
00:45:05,680 --> 00:45:10,480
going to kneecap anyone using the software and trying to do self-custodial payments using lightning

534
00:45:10,480 --> 00:45:33,320
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

535
00:45:33,320 --> 00:45:39,740
considered standard for relay but it also enables things like uh zero p transactions

536
00:45:39,740 --> 00:45:45,340
for technical reasons that i won't get into here but that's kind of like the gist of it

537
00:45:45,580 --> 00:45:45,820
Yeah.

538
00:45:48,060 --> 00:45:54,540
No, like you told me before we had recorded that you haven't been paying attention since BTC++,

539
00:45:54,880 --> 00:46:03,960
but I think I came away from that way because I was highly, I don't want to say triggered,

540
00:46:04,100 --> 00:46:06,600
but I was like a little emotional, like what is going on here?

541
00:46:06,600 --> 00:46:10,960
I was a little demotivated.

542
00:46:10,960 --> 00:46:18,200
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.

543
00:46:18,740 --> 00:46:23,020
But I just after that, I didn't think so. And I think it was it was born out to be true.

544
00:46:23,100 --> 00:46:25,600
I just I don't you know, I don't see it months later.

545
00:46:26,400 --> 00:46:30,000
No, you know, get a lot of there. And it's funny.

546
00:46:30,100 --> 00:46:38,420
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?

547
00:46:38,420 --> 00:46:39,960
I don't want to breathe air into it.

548
00:46:40,100 --> 00:46:42,360
I think I walked away from BTC++

549
00:46:42,360 --> 00:46:45,420
with the conclusion in my mind

550
00:46:45,420 --> 00:46:48,080
that these things are consensus valid.

551
00:46:48,820 --> 00:46:50,140
There's nothing you can do

552
00:46:50,140 --> 00:46:53,960
to stop valid transactions from getting in.

553
00:46:55,480 --> 00:46:56,800
If you want to change it,

554
00:46:57,000 --> 00:46:59,680
you're going to have the harder conversation

555
00:46:59,680 --> 00:47:03,640
of soft work to change up return or something like that.

556
00:47:03,640 --> 00:47:04,860
If you're not focused on that,

557
00:47:04,860 --> 00:47:12,060
then I think you're looking for a Pyrrhic victory there.

558
00:47:12,500 --> 00:47:17,260
And then, I mean, I guess to be critical of Bitcoin Core,

559
00:47:17,540 --> 00:47:21,400
the project, I think we talked about this in May in person too.

560
00:47:21,580 --> 00:47:27,160
I think it's just a massive communications PR failure.

561
00:47:29,160 --> 00:47:31,620
I think that's why many people have gotten so triggered

562
00:47:31,620 --> 00:47:33,960
and remain triggered.

563
00:47:35,740 --> 00:47:40,980
The perception is that Bitcoin Core is changing policy rules arbitrarily

564
00:47:40,980 --> 00:47:47,060
without talking to the broader Bitcoin user base.

565
00:47:48,300 --> 00:47:49,620
Yeah, that's a little disappointing.

566
00:47:50,100 --> 00:47:53,540
And I find it a little baffling that the response to that

567
00:47:53,540 --> 00:47:59,100
is to switch to a distribution that changes policy on a whim of one guy

568
00:47:59,100 --> 00:48:01,500
and completely ignorant.

569
00:48:01,620 --> 00:48:04,680
I guess I'm being pointed here.

570
00:48:05,980 --> 00:48:10,440
Mentioning these, they did not know they're breaking people's expectations of the network.

571
00:48:11,380 --> 00:48:13,860
As far as I know, they haven't changed course.

572
00:48:15,580 --> 00:48:19,280
Who's defending the moneyness of Bitcoin? I don't see how it would be them.

573
00:48:20,980 --> 00:48:24,560
What do you think happens tomorrow? Do you think Bitcoin dies tomorrow when $1.30 is released?

574
00:48:25,400 --> 00:48:28,040
I'm firmly on nothing ever happens team.

575
00:48:28,040 --> 00:48:33,220
I think it's not a black swan event, no matter what.

576
00:48:34,360 --> 00:48:36,280
It's like a very, very minor thing.

577
00:48:36,440 --> 00:48:39,360
So I'm happy if people just update to relatively minor,

578
00:48:39,800 --> 00:48:44,120
relatively recent releases just for the health of the network,

579
00:48:44,760 --> 00:48:49,040
for security reasons, and also just the V3 transactions,

580
00:48:49,780 --> 00:48:51,480
thermal dust, all those things getting out there.

581
00:48:52,060 --> 00:48:55,780
It's good to see these getting traction in real life.

582
00:48:55,780 --> 00:48:58,100
yeah

583
00:48:58,100 --> 00:49:00,100
the uh

584
00:49:00,100 --> 00:49:03,900
I said this on Rabbit Hole Recap I forget it was two or three weeks

585
00:49:03,900 --> 00:49:05,460
ago but I

586
00:49:05,460 --> 00:49:07,060
proclaimed

587
00:49:07,060 --> 00:49:08,520
stated

588
00:49:08,520 --> 00:49:11,800
during that episode like we're gonna look

589
00:49:11,800 --> 00:49:14,020
back a year from now and we'll be laughing

590
00:49:14,020 --> 00:49:15,920
that I think this is what I think

591
00:49:15,920 --> 00:49:17,420
is gonna happen he knows what's gonna happen but

592
00:49:17,420 --> 00:49:19,960
I'm also firmly in the

593
00:49:19,960 --> 00:49:21,460
nothing ever happens cap and

594
00:49:21,460 --> 00:49:23,860
yeah I think we'll look back

595
00:49:23,860 --> 00:49:25,900
I remember we were fighting about that.

596
00:49:26,840 --> 00:49:33,320
I think it's important to try to take some lessons from it, whatever those lessons are.

597
00:49:33,700 --> 00:49:37,640
And then. I mean, some of the lessons are negative, right?

598
00:49:37,760 --> 00:49:46,940
But basically doing what you can to keep your brand as far as like a infrastructure project, which doesn't lose people's money.

599
00:49:46,940 --> 00:50:01,560
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.

600
00:50:01,800 --> 00:50:05,760
Right. It really is up to the person. Right. Self-sovereignty.

601
00:50:05,760 --> 00:50:14,340
And I think people keep forgetting this fact that running the node 99.9% of the time is for you, right?

602
00:50:14,980 --> 00:50:17,880
It's for your sovereignty, your security, your privacy.

603
00:50:18,180 --> 00:50:21,360
You're not generally helping the network doing this.

604
00:50:22,060 --> 00:50:24,320
Almost all the time, it's just for you.

605
00:50:24,600 --> 00:50:26,340
And that's where the focus should be.

606
00:50:26,340 --> 00:50:31,560
I think there is a broad misconception about

607
00:50:31,560 --> 00:50:35,800
the power of an individual full node

608
00:50:35,800 --> 00:50:38,340
and its influence on the rest of the network

609
00:50:38,340 --> 00:50:43,180
it's funny rehashing these conversations that happened during the black wars

610
00:50:43,180 --> 00:50:44,660
the concept of an economic node

611
00:50:44,660 --> 00:50:49,280
I think you can definitely socially signal by running a certain version

612
00:50:49,280 --> 00:50:50,800
of a certain implementation

613
00:50:50,800 --> 00:50:53,160
but yeah,

614
00:50:53,820 --> 00:50:57,020
the policy ends up being kind of like the mirror inverse of that,

615
00:50:57,120 --> 00:50:57,300
right?

616
00:50:57,340 --> 00:51:03,040
So the block size wars was the intolerant minority or intolerant minority

617
00:51:03,040 --> 00:51:08,120
where basically it's like if a small fraction of economically motivated

618
00:51:08,120 --> 00:51:10,760
users will reject things consensus,

619
00:51:10,760 --> 00:51:15,440
then it kind of is brinksmanship involved that might enable software.

620
00:51:15,780 --> 00:51:16,720
But with policy,

621
00:51:16,840 --> 00:51:18,440
it's the inverse where a small,

622
00:51:18,440 --> 00:51:23,800
small percent of people who are tolerant of a certain transaction format lets them through

623
00:51:23,800 --> 00:51:26,860
in practice, even if 90% of the network doesn't.

624
00:51:28,320 --> 00:51:33,700
And I think there's a bunch of metaphors here, like technical allegories, pretty much are

625
00:51:33,700 --> 00:51:34,060
parallels.

626
00:51:35,860 --> 00:51:37,120
That's a really good insight.

627
00:51:37,780 --> 00:51:38,920
I never thought of it that way.

628
00:51:39,080 --> 00:51:41,160
The inverse consensus versus policy.

629
00:51:42,000 --> 00:51:47,720
Intolerant minority can affect consensus more than they could policy.

630
00:51:48,440 --> 00:51:54,880
A tolerant minority can make more things relay.

631
00:51:57,140 --> 00:51:59,320
They can't make less things relay.

632
00:51:59,680 --> 00:52:01,620
An intolerant minority can affect consensus.

633
00:52:01,920 --> 00:52:05,340
Like shrinking consensus is the easier part,

634
00:52:06,060 --> 00:52:10,380
while expanding policy is the easier part on the policy side of things.

635
00:52:10,520 --> 00:52:11,600
It's easy to expand.

636
00:52:11,720 --> 00:52:12,580
It's hard to restrict.

637
00:52:12,980 --> 00:52:15,600
It's kind of like the mirror universe here.

638
00:52:15,600 --> 00:52:17,160
It's hard to hard fork.

639
00:52:17,300 --> 00:52:18,080
It's easier to software.

640
00:52:18,080 --> 00:52:21,940
in Relay, it's easier to expand, harder to restrict.

641
00:52:24,880 --> 00:52:32,100
So, moving forward, when Doomsday comes and goes tomorrow,

642
00:52:32,600 --> 00:52:35,940
we move on, I think the dust will settle.

643
00:52:37,080 --> 00:52:39,200
A lot of questions around ossification,

644
00:52:40,200 --> 00:52:41,480
what changes are needed in Bitcoin.

645
00:52:42,740 --> 00:52:46,400
Obviously, Bitcoin Core isn't going to stop working on Bitcoin

646
00:52:46,400 --> 00:52:48,920
after version 30 is released tomorrow,

647
00:52:49,100 --> 00:52:51,900
and the same can be said for any other developer

648
00:52:51,900 --> 00:52:53,400
working on any other implementation.

649
00:52:53,820 --> 00:52:57,320
But in your mind, what are some of the top priorities

650
00:52:57,320 --> 00:53:01,000
that people need to be focusing on

651
00:53:01,000 --> 00:53:04,800
beyond what gets released tomorrow?

652
00:53:06,800 --> 00:53:09,900
Well, I mean, doubling down on the security infrastructure,

653
00:53:09,900 --> 00:53:11,400
but I already talked about that.

654
00:53:12,620 --> 00:53:16,260
So aside from making sure that this multi-trillion dollar asset

655
00:53:16,260 --> 00:53:18,600
doesn't fall over in the next few years.

656
00:53:19,320 --> 00:53:21,200
There is a continuing conversation

657
00:53:21,200 --> 00:53:23,240
on what people call covenants

658
00:53:23,240 --> 00:53:25,120
or scripting softworks.

659
00:53:25,280 --> 00:53:26,160
I think that'll continue.

660
00:53:27,900 --> 00:53:30,660
Rusty Russell has submitted

661
00:53:30,660 --> 00:53:31,960
a somewhat serious,

662
00:53:32,140 --> 00:53:33,160
more concrete proposal

663
00:53:33,840 --> 00:53:35,360
for his kind of rewrite

664
00:53:35,360 --> 00:53:36,160
of Bitcoin script

665
00:53:36,160 --> 00:53:39,220
where taking Bitcoin script

666
00:53:39,220 --> 00:53:40,400
and turning it up to 11.

667
00:53:41,320 --> 00:53:43,160
But there's a number of different ways

668
00:53:43,160 --> 00:53:46,080
that script updates can be done.

669
00:53:46,260 --> 00:53:50,880
like for what you're trying to accomplish and how you do it.

670
00:53:50,880 --> 00:53:53,160
And that informs how you do it. So he has one way.

671
00:53:54,220 --> 00:53:58,700
Russell O'Connor has simplicity, if you've read up about that.

672
00:53:58,880 --> 00:54:02,740
And then AJ also has his own bullish kind of Lisp-based programming language.

673
00:54:03,600 --> 00:54:08,780
And I think beyond the near term, we need a bigger discussion about

674
00:54:08,780 --> 00:54:14,420
if we want to continue iterating on scripting in Bitcoin,

675
00:54:14,420 --> 00:54:15,600
what's the best way to do it?

676
00:54:16,080 --> 00:54:19,140
That's a big engineering question as well as, you know,

677
00:54:20,200 --> 00:54:21,740
theoretical and engineering.

678
00:54:22,580 --> 00:54:25,820
Yeah, I pulled Sharon a couple of months ago to talk about simplicity

679
00:54:25,820 --> 00:54:27,780
launching on Liquid Mainnet.

680
00:54:29,240 --> 00:54:32,960
And we talked about the potential of it getting implemented

681
00:54:32,960 --> 00:54:34,160
at the protocol level.

682
00:54:34,500 --> 00:54:36,700
It seems like simplicity, I mean, obviously,

683
00:54:36,800 --> 00:54:37,920
Blockstream's been working on it.

684
00:54:37,980 --> 00:54:39,720
I think the paper dropped, what, like 12 years ago,

685
00:54:40,280 --> 00:54:41,180
maybe even longer ago.

686
00:54:41,180 --> 00:54:45,320
and it's been talked about since then

687
00:54:45,320 --> 00:54:48,660
finally got a live on mainnet on liquid

688
00:54:48,660 --> 00:54:53,080
to basically showcase what could be done there

689
00:54:53,080 --> 00:54:57,180
but it seems like simplicity has always appealed to me

690
00:54:57,180 --> 00:55:01,240
but I think the common pushback is how are you going to get this

691
00:55:01,240 --> 00:55:01,560
into

692
00:55:01,560 --> 00:55:07,500
common pushback is oh it's very complicated it's a lot of lines of code

693
00:55:07,500 --> 00:55:14,240
But if you look at any other proposal, they're making severe tradeoffs, too.

694
00:55:14,320 --> 00:55:25,380
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.

695
00:55:25,380 --> 00:55:31,880
because there are facets of simplicity or simplicity-like solutions that really appeal to me as well

696
00:55:31,880 --> 00:55:38,280
that aren't maintained with the great script restoration or bullish.

697
00:55:38,700 --> 00:55:41,000
And so I think this discussion has to be made.

698
00:55:41,720 --> 00:55:46,840
More near term, Antoine and I have been working on a smaller proposal,

699
00:55:47,160 --> 00:55:50,300
which is template hash, check system stack, and internal key.

700
00:55:50,880 --> 00:55:52,280
Have you had Antoine on for that?

701
00:55:53,080 --> 00:55:53,460
No.

702
00:55:53,980 --> 00:55:54,340
Okay.

703
00:55:54,340 --> 00:56:05,680
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.

704
00:56:05,940 --> 00:56:14,820
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.

705
00:56:15,160 --> 00:56:20,120
And that was our proposal. Essentially, it's a CTV like widget that's TapScript only.

706
00:56:20,120 --> 00:56:27,340
check stick from stack which is bit 348 and internal key which is bit 349 as is

707
00:56:27,340 --> 00:56:36,520
what would you say to the ossifiers who are worried about the unforeseen consequences of

708
00:56:36,520 --> 00:56:41,200
messing with something like bitcoin script because they would argue i would argue too

709
00:56:41,200 --> 00:56:47,040
there was unforeseen consequences with the combination of segwit taproot with the ordinals

710
00:56:47,040 --> 00:56:56,280
manifestation um i guess how do you how do you have conversations around that in really war game

711
00:56:56,280 --> 00:57:03,220
through the potential for stuff like that yeah i mean that's an interesting question because

712
00:57:03,220 --> 00:57:09,900
the things i felt that were deficient in taproot are probably not the same ones like from an

713
00:57:09,900 --> 00:57:16,640
unforeseen perspective so when i look at lessons learned from i mean there's probably a bunch from

714
00:57:16,640 --> 00:57:23,720
segwit but let's say from taproot since it's more recent we learned things like hey maybe we should

715
00:57:23,720 --> 00:57:30,740
have more tooling in place before we actually talk about activation because in taproot the way keys

716
00:57:30,740 --> 00:57:37,300
are published on the network there are these 32 byte keys what we call x only keys and this ended

717
00:57:37,300 --> 00:57:42,160
up it's may or may not be the right decision in the end but we didn't have a fuller discussion

718
00:57:42,160 --> 00:57:44,220
from the tooling side of things.

719
00:57:44,560 --> 00:57:46,040
How do you make cryptographic protocols

720
00:57:46,040 --> 00:57:48,400
with a slightly different public key format?

721
00:57:49,140 --> 00:57:54,860
And it ended up complicating certain protocols.

722
00:57:55,520 --> 00:57:57,040
I think it ended up okay,

723
00:57:57,200 --> 00:57:59,300
but the lessons I took away were essentially,

724
00:57:59,720 --> 00:58:04,100
hey, tooling needs to be much more defined

725
00:58:04,100 --> 00:58:07,300
before these kind of larger changes are done.

726
00:58:07,300 --> 00:58:09,300
And we're taking that to heart.

727
00:58:09,300 --> 00:58:19,040
So part of our efforts is not only saying, hey, these capabilities, these opcodes and capabilities enable some cool use cases.

728
00:58:19,320 --> 00:58:21,000
Hey, look at these blog posts we made.

729
00:58:21,540 --> 00:58:35,820
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.

730
00:58:35,820 --> 00:58:37,460
And we're far from that.

731
00:58:37,860 --> 00:58:40,340
Even from a mind share perspective, we're far away.

732
00:58:40,640 --> 00:58:43,580
But from a quality assurance perspective, we're also far away.

733
00:58:44,080 --> 00:58:47,380
So that's kind of like the lesson I took away, I guess, from Taproot.

734
00:58:47,980 --> 00:58:48,200
Yeah.

735
00:58:49,320 --> 00:58:57,680
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?

736
00:58:57,740 --> 00:59:00,240
Or, you know, practically the next day.

737
00:59:00,940 --> 00:59:05,720
With Taproot, it ended up being like this activated in 2019 or whatever.

738
00:59:05,820 --> 00:59:13,620
And then like, oh, it took four more years for Mucig to be formalized and another two years to be standardized.

739
00:59:14,160 --> 00:59:17,000
And PSPT support is taking years.

740
00:59:17,820 --> 00:59:21,880
And ideally, more of this would have been done prior to activation.

741
00:59:23,960 --> 00:59:35,640
And it's the same problem we have as Bitcoiners, as a species, as we're becoming more dependent to a degree on this.

742
00:59:35,640 --> 00:59:40,620
and this monetary protocol is approaching $2.5 trillion in value.

743
00:59:40,960 --> 00:59:42,920
Not only that, you mentioned it earlier,

744
00:59:43,000 --> 00:59:44,900
we have all these different second-layer solutions,

745
00:59:45,120 --> 00:59:48,900
whether it's Lightning, Liquid, ARK, Spark,

746
00:59:49,740 --> 00:59:53,260
throw Xiaomi and Mintz in the bag as well.

747
00:59:54,340 --> 00:59:55,660
Silent, no, not Silent Payments.

748
00:59:56,800 --> 00:59:58,060
What does Spark use?

749
00:59:59,280 --> 00:59:59,960
State Chains.

750
00:59:59,980 --> 01:00:00,560
State Chains.

751
01:00:00,980 --> 01:00:01,660
State Chains.

752
01:00:01,840 --> 01:00:02,900
Silent Payments too, right?

753
01:00:02,900 --> 01:00:07,240
All these, you have this whole tech stack that's all kind of interlinked in certain ways.

754
01:00:07,240 --> 01:00:11,660
And the velocity is just kind of slow because there's a lot more layers to it.

755
01:00:12,600 --> 01:00:17,580
Even if I snap my fingers and we got some magical software, it would still take years for adoption.

756
01:00:18,540 --> 01:00:18,720
Yeah.

757
01:00:20,540 --> 01:00:24,540
This is out of left field, but just because it's a big topic of conversation,

758
01:00:24,900 --> 01:00:27,420
I think when it comes to like fuzz testing is...

759
01:00:27,456 --> 01:00:34,696
ai help at all with this is there any uh any vibe coding that helps i was i was briefly considering

760
01:00:34,696 --> 01:00:43,476
today could you get reasonable vibe coded buzz harnesses so making but with fuzz testing you

761
01:00:43,476 --> 01:00:48,496
really want to make sure like you need a lot of subject matter expertise to define it otherwise

762
01:00:48,496 --> 01:00:54,116
it does like basically really random and if it's really random data then it doesn't really make any

763
01:00:54,116 --> 01:00:58,416
meaningful progress it's trying random numbers essentially with no understanding of what it's

764
01:00:58,416 --> 01:01:04,196
doing but the way you can write the harness with intelligence so maybe there's like maybe there is

765
01:01:04,196 --> 01:01:10,036
you know i wouldn't rule it out i think ai for writing testing is probably one of the best

766
01:01:10,036 --> 01:01:14,276
avenues to go forward with in this space i'm not sure how much people have been doing it

767
01:01:14,276 --> 01:01:21,316
i was just going to ask is anybody working on that probably what um what would you obviously

768
01:01:21,316 --> 01:01:27,296
there's been a lot of controversy and shit slinging going on over the last eight months.

769
01:01:27,376 --> 01:01:33,096
What would you say is the mental state of your average developer right now?

770
01:01:34,216 --> 01:01:42,456
I mean, it depends. Obviously, this kind of drama makes maintainers more risk averse in some ways,

771
01:01:42,536 --> 01:01:49,636
right? So risk averse could mean they're going to ignore issues longer or they're just going to

772
01:01:49,636 --> 01:01:52,296
make snap decisions and just say like, this is the way it is.

773
01:01:55,636 --> 01:01:58,296
Outside of that, I think people are ready to get back to work,

774
01:01:58,636 --> 01:02:00,076
working on interesting things.

775
01:02:00,076 --> 01:02:05,636
So like one project that I think will become more important as time goes on

776
01:02:05,636 --> 01:02:09,036
possibly is AJ is working on this thing called template sharing,

777
01:02:09,156 --> 01:02:16,636
which is, and we basically want these future relay discussions to be less

778
01:02:16,636 --> 01:02:17,456
political.

779
01:02:17,456 --> 01:02:33,516
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.

780
01:02:33,516 --> 01:02:37,996
So we don't want to slow down block propagation on the network to make mining fair.

781
01:02:38,316 --> 01:02:45,756
So if there are like technical ways of mitigating this, even when people disagree on mental policies, that would be a big win.

782
01:02:45,756 --> 01:02:54,876
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.

783
01:02:57,376 --> 01:03:04,936
Yeah. What would you contend is the biggest risk to Bitcoin right now?

784
01:03:05,596 --> 01:03:08,396
That's a great question. Biggest risk.

785
01:03:09,236 --> 01:03:15,296
I mean, I think it's the legal one for users and developers still.

786
01:03:15,756 --> 01:03:23,396
Um, it's, it's a, you know, stable coin people, I would say are a political force in America,

787
01:03:23,396 --> 01:03:27,296
but still not quite there for Bitcoin.

788
01:03:27,296 --> 01:03:27,716
Right.

789
01:03:27,816 --> 01:03:32,676
Uh, we still don't have legal, like explicit legal protections in congressional writing,

790
01:03:32,876 --> 01:03:39,056
promising that they won't jail us for writing code that helps people move money.

791
01:03:39,056 --> 01:03:39,456
Right.

792
01:03:40,376 --> 01:03:44,096
Um, privacy is going to be a big bear to tackle.

793
01:03:44,096 --> 01:03:56,536
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.

794
01:03:56,536 --> 01:04:11,596
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.

795
01:04:11,596 --> 01:04:21,576
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.

796
01:04:21,576 --> 01:04:43,436
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.

797
01:04:43,756 --> 01:04:49,836
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.

798
01:04:49,836 --> 01:04:53,896
and this could be instigated by a service

799
01:04:53,896 --> 01:04:56,236
offering practical privacy.

800
01:04:56,516 --> 01:04:59,156
So I think that those are some of the finer

801
01:04:59,156 --> 01:05:02,576
tightropes that are walking these wallet services.

802
01:05:03,976 --> 01:05:05,676
Yeah, I saw you tweeting,

803
01:05:05,916 --> 01:05:07,456
you're quote tweeting Wallace Satoshi,

804
01:05:07,596 --> 01:05:08,836
which has moved to Spark.

805
01:05:09,436 --> 01:05:09,696
Yeah.

806
01:05:10,376 --> 01:05:11,156
As their backend.

807
01:05:12,016 --> 01:05:12,416
Exactly.

808
01:05:12,496 --> 01:05:13,116
And that's insane.

809
01:05:13,896 --> 01:05:15,516
It's like anybody who's technical enough

810
01:05:15,516 --> 01:05:17,476
can sort of probe that data.

811
01:05:18,096 --> 01:05:19,656
Yeah, it's a little surprising.

812
01:05:19,836 --> 01:05:24,196
I'm obviously not happy with it.

813
01:05:24,196 --> 01:05:37,836
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.

814
01:05:38,036 --> 01:05:39,176
And I think that's very difficult.

815
01:05:40,616 --> 01:05:44,516
Prior, like in previous iterations, they were the custodian.

816
01:05:44,776 --> 01:05:48,636
And so Wallet Satoshi says, I'm not going to publish everything on a database.

817
01:05:48,636 --> 01:05:51,816
but now they're relying on a backend that does.

818
01:05:52,476 --> 01:05:56,236
How do you update the mental framework of, you know,

819
01:05:56,256 --> 01:05:58,676
how do you get informed consent from your users for that?

820
01:05:59,496 --> 01:06:00,576
That's really challenging.

821
01:06:00,996 --> 01:06:02,836
And I'm not sure what the solution is for that.

822
01:06:03,996 --> 01:06:05,196
Yeah, I'm just going to pull this up.

823
01:06:09,656 --> 01:06:10,056
Yeah.

824
01:06:10,216 --> 01:06:12,876
There isn't real privacy against the Spark operators

825
01:06:12,876 --> 01:06:28,116
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

826
01:06:28,116 --> 01:06:33,916
for me in about 10 minutes probably vibe coded it uh there we go so if you get someone's wall

827
01:06:33,916 --> 01:06:39,476
satoshi invoice it immediately pulls up their account so i tested it on my own which i don't

828
01:06:39,476 --> 01:06:45,556
use it seriously but you know it it would show my test transactions to my real lightning wallet

829
01:06:45,556 --> 01:06:53,756
so you know that's like how do you communicate that to a user especially a new user how do you

830
01:06:53,756 --> 01:07:00,696
communicate that to the user of venmo which has one you know they're maybe okay with the service

831
01:07:00,696 --> 01:07:06,556
knowing but not everyone in the world knowing if they can switch a button um yeah no that's what i

832
01:07:06,556 --> 01:07:14,696
I was going to say, it's like, even if the operator knows every transaction doesn't mean you broadcast.

833
01:07:15,156 --> 01:07:21,356
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.

834
01:07:21,536 --> 01:07:22,876
And then they just didn't do that.

835
01:07:23,596 --> 01:07:24,956
I'd be pretty sympathetic to that.

836
01:07:26,856 --> 01:07:27,076
Yeah.

837
01:07:27,636 --> 01:07:32,136
Now, the privacy war is going to be a big one.

838
01:07:32,136 --> 01:07:39,436
but uh i saw dan gold from page one dev kid uh a couple weeks ago it seems like they're making

839
01:07:39,436 --> 01:07:44,736
good progress and when it comes to paid page one specifically i think we're gonna have to position

840
01:07:44,736 --> 01:07:53,256
it as a way to uh as a sort of cost saving technology for exchanges specifically yeah

841
01:07:53,256 --> 01:07:58,236
that's i mean that's the tough thing it seems like to make it palatable regulatory regulation

842
01:07:58,236 --> 01:08:03,996
wise we have to say it's something else it is right pay join coin joins in general can be

843
01:08:03,996 --> 01:08:10,516
potential savings lightning is a potential fee is a fee savings vehicle that gets you practical

844
01:08:10,516 --> 01:08:20,496
certain certain levels of privacy better than non-chain um an arc spark well all these other

845
01:08:20,496 --> 01:08:27,696
systems can also potentially offer those kind of privacy trade-offs maybe trojan horse

846
01:08:27,696 --> 01:08:31,336
using the original systems, right?

847
01:08:32,476 --> 01:08:32,796
Yeah.

848
01:08:33,676 --> 01:08:37,816
That's why I don't know what your thoughts are on Chalmy and Mint,

849
01:08:37,916 --> 01:08:39,776
but I love them.

850
01:08:39,936 --> 01:08:44,416
I love the Cashew wallets and the Petty Mint wallets

851
01:08:44,416 --> 01:08:45,256
that I interact with.

852
01:08:46,916 --> 01:08:50,336
Yeah, I think the big challenge is who runs the Mint, right?

853
01:08:50,736 --> 01:08:53,576
They cannot claim they're non-custodial

854
01:08:53,576 --> 01:08:55,576
by any stretch of the imagination.

855
01:08:56,096 --> 01:08:56,296
No.

856
01:08:56,296 --> 01:08:58,676
So who runs them?

857
01:08:59,696 --> 01:09:02,016
How much of a centralizing force is that?

858
01:09:02,696 --> 01:09:05,496
Because it's more efficient if everyone's on the same mint.

859
01:09:07,016 --> 01:09:17,496
Maybe there's decentralization back pressure from like, well, we have the lightning network that interconnects everything.

860
01:09:17,796 --> 01:09:19,976
So maybe the centralization pressure isn't as big.

861
01:09:19,976 --> 01:09:22,476
You just have like thousands of operators.

862
01:09:23,316 --> 01:09:24,696
I mean, I guess we'll see.

863
01:09:26,296 --> 01:09:28,176
Some people think the AIs are going to run them in.

864
01:09:28,836 --> 01:09:32,196
They're going to recognize it's superior money for the agentic framework,

865
01:09:32,456 --> 01:09:33,416
and they're just going to run them in.

866
01:09:34,916 --> 01:09:36,816
Can I imagine conspiracy theories there?

867
01:09:37,456 --> 01:09:37,656
Yeah.

868
01:09:38,216 --> 01:09:40,636
But now we're getting into the philosophical side of things,

869
01:09:40,716 --> 01:09:44,236
because no matter what part of the stack we're talking about,

870
01:09:44,336 --> 01:09:46,836
like Spark has to make this privacy trade-off because of the government.

871
01:09:48,756 --> 01:09:53,776
Maybe other things like Pajoin won't get implemented by exchanges

872
01:09:53,776 --> 01:09:56,596
is because they're worried about the regulatory and compliance blowback.

873
01:09:57,256 --> 01:10:01,756
Obviously, Chubby and Mintz can provide not only incredible privacy,

874
01:10:01,996 --> 01:10:04,356
but since they're separate from Bitcoin and very modular,

875
01:10:04,496 --> 01:10:07,576
you can build a literal new banking stack from scratch

876
01:10:07,576 --> 01:10:12,376
that gives you all the functionalities you'd want from a banking service

877
01:10:12,376 --> 01:10:14,936
with better, more secure tech,

878
01:10:15,736 --> 01:10:19,236
minus the centralization pressures of the Mint operator.

879
01:10:19,236 --> 01:10:27,476
it's like we have the potential to build an incredibly robust, secure, private financial system,

880
01:10:27,576 --> 01:10:31,436
which arguably should be what everybody wants.

881
01:10:32,216 --> 01:10:37,916
But for some, not for some reason, but the government just messes that up.

882
01:10:39,536 --> 01:10:45,636
Yeah. Also, the user demand just isn't there for censorship-resistant payments.

883
01:10:45,636 --> 01:10:51,956
I mean there obviously is some but in the west as an example no one seems to care and

884
01:10:51,956 --> 01:10:59,396
what would make them care right what what events might transpire that will make them care and will

885
01:10:59,396 --> 01:11:04,196
we will we be ready for them that's the other one too right we're building I think like general

886
01:11:04,196 --> 01:11:10,976
hodl tech is pretty much solved I would say like Coinbase can seems to be doing okay with

887
01:11:10,976 --> 01:11:16,556
a quadrillion Bitcoin or whatever, but you know, the,

888
01:11:16,716 --> 01:11:19,436
the payment technology still isn't there.

889
01:11:19,436 --> 01:11:24,176
And so if Bitcoin payments actually need to take off the non-pustodial way in

890
01:11:24,176 --> 01:11:26,216
the future, the infrastructure needs to be there.

891
01:11:26,296 --> 01:11:29,256
And I think that's kind of what we're looking at, looking at this future.

892
01:11:30,736 --> 01:11:33,996
Hey, we had a good step in the right direction yesterday with the, uh,

893
01:11:33,996 --> 01:11:38,776
square announcement. People were waiting for seven years for that. Yeah.

894
01:11:38,776 --> 01:11:42,636
no I think the pressure is going to be digital ID

895
01:11:42,636 --> 01:11:45,776
and my theory is that

896
01:11:45,776 --> 01:11:47,356
they're going to try and thrust something

897
01:11:47,356 --> 01:11:49,716
world coin or something like it on the masses

898
01:11:49,716 --> 01:11:53,736
and people are not going to be fond of staring into the orb

899
01:11:53,736 --> 01:11:56,816
and then they'll care

900
01:11:56,816 --> 01:11:57,876
maybe yeah

901
01:11:57,876 --> 01:12:03,056
yeah I mean now we're getting something like

902
01:12:03,056 --> 01:12:05,916
do you have

903
01:12:05,916 --> 01:12:27,016
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

904
01:12:27,016 --> 01:12:34,956
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.

905
01:12:34,956 --> 01:12:48,836
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.

906
01:12:50,436 --> 01:12:54,916
You know, if you just park your money on, well, actually, this is where it still works, right?

907
01:12:55,216 --> 01:13:03,016
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.

908
01:13:03,016 --> 01:13:07,696
But if you want to actually send someone over the light network of payment, I think it still works.

909
01:13:08,096 --> 01:13:11,996
But there's all this regulatory pressure to not let it succeed. Right.

910
01:13:12,556 --> 01:13:16,216
And I think that's where all the friction is. So I did this.

911
01:13:17,876 --> 01:13:24,136
I did this last week. We had we had a 1031 off site with the portfolio companies.

912
01:13:24,136 --> 01:13:32,736
We're at this resort and over the course of the three days, got to know some of the people working at the resort.

913
01:13:33,016 --> 01:13:33,836
particularly the bar.

914
01:13:34,256 --> 01:13:36,096
And last night, go to tip him.

915
01:13:36,196 --> 01:13:37,296
He's got a Coinbase account.

916
01:13:37,516 --> 01:13:38,656
I was like, I'll send it over Lightning.

917
01:13:38,996 --> 01:13:41,056
And the UX was just completely abysmal.

918
01:13:41,816 --> 01:13:45,336
And I thought, like, I got a confirmation on my end,

919
01:13:45,396 --> 01:13:46,456
but it never hit his account.

920
01:13:46,556 --> 01:13:48,436
And I got a confirmation that the payment was received.

921
01:13:48,936 --> 01:13:51,996
But from what I understand, and I didn't realize this until after,

922
01:13:52,796 --> 01:13:53,376
I left him.

923
01:13:53,376 --> 01:13:56,536
Coinbase is asking users that accept Bitcoin over Lightning

924
01:13:56,536 --> 01:14:00,516
to ask for personal information of the counterparty.

925
01:14:00,516 --> 01:14:00,796
Exactly.

926
01:14:01,156 --> 01:14:01,416
Yeah.

927
01:14:02,176 --> 01:14:02,876
The transaction.

928
01:14:03,016 --> 01:14:03,636
It's like, what?

929
01:14:03,896 --> 01:14:05,496
Yeah, that's I think.

930
01:14:06,676 --> 01:14:11,616
It's it's incredibly centralizing in that no one will want to do that.

931
01:14:12,476 --> 01:14:20,796
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.

932
01:14:21,236 --> 01:14:24,696
If money is sitting in an ETF or what everyone's happy with, they don't need to.

933
01:14:25,656 --> 01:14:27,396
Ask permission because it's not going anywhere.

934
01:14:27,976 --> 01:14:32,996
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.

935
01:14:33,016 --> 01:14:35,096
base or regulated institution.

936
01:14:36,196 --> 01:14:36,936
Well, I don't

937
01:14:36,936 --> 01:14:38,916
know if we can fix that aside from

938
01:14:38,916 --> 01:14:39,816
legal changes.

939
01:14:41,836 --> 01:14:42,956
It's completely immoral

940
01:14:42,956 --> 01:14:45,036
though. Like I sent the Bitcoin, like I sent it

941
01:14:45,036 --> 01:14:45,876
for my wallet.

942
01:14:46,416 --> 01:14:47,656
I'm making a descriptive.

943
01:14:48,296 --> 01:14:51,016
Oh, I know. But like just like I'm thinking about

944
01:14:51,016 --> 01:14:52,756
I was thinking about it through. I was like, wait, I

945
01:14:52,756 --> 01:14:54,976
sent $15, $20 for

946
01:14:54,976 --> 01:14:56,776
the Bitcoin, whatever it was, to this wallet.

947
01:14:57,116 --> 01:14:59,236
Like obviously it's centralized Coinbase

948
01:14:59,236 --> 01:15:01,056
presenting and running the

949
01:15:01,056 --> 01:15:06,156
lightning node presenting the invoice they have the bitcoin sitting somewhere in their account

950
01:15:06,156 --> 01:15:11,316
the guy that i sent it to light spark does i think but yeah yeah light spark whatever it's sitting

951
01:15:11,316 --> 01:15:16,216
somewhere in a centralized third party and that guy's never going to get the money and i send 20

952
01:15:16,216 --> 01:15:19,616
bucks and i'm never going to get back because i don't think this guy's going to be able to find

953
01:15:19,616 --> 01:15:24,996
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

954
01:15:24,996 --> 01:15:30,436
i'll say spin up another invoice using using zeus or something like that and i'll send you the bitcoin

955
01:15:30,436 --> 01:15:37,536
there but the coinbase just holds that money now yeah so i think i think that's where you'll see

956
01:15:37,536 --> 01:15:43,776
the right like if spark does take off that that's the niche it'll fit uh there's an unfortunate

957
01:15:43,776 --> 01:15:50,036
privacy thing but if you if you're willing to accept a system that says itself can self-custodial

958
01:15:50,036 --> 01:15:56,396
kind of is trust odial at least um maybe that's enough for users to get onboarded

959
01:15:56,396 --> 01:16:02,056
but is that a world we want to go to versus something more private this is like a big challenge

960
01:16:02,056 --> 01:16:11,316
yeah i mean talking to matt corralo earlier this year he's pretty optimistic that uh self-custodial

961
01:16:11,316 --> 01:16:18,296
lightning will see a step function improvement uh better it's it's definitely better than before

962
01:16:18,296 --> 01:16:26,156
um i think a lot of you'll hear like oh this new layer two will fix all lightnings you know

963
01:16:26,156 --> 01:16:31,616
all the issues lightning has but you look under the hood it's either making custody trade-offs

964
01:16:31,616 --> 01:16:37,216
security trade-offs or it's or it's making the same assumptions as like lightning needs

965
01:16:37,216 --> 01:16:42,396
improvement so it's like oh it's instant transactions they say how do you get instant

966
01:16:42,396 --> 01:16:48,376
transactions oh you just trust this person not to sign twice like come on like you know that's

967
01:16:48,376 --> 01:16:54,076
zero comp trust right so i think there's a in this industry there's still a bit of that even

968
01:16:54,076 --> 01:16:55,856
in the Bitcoin side. It's kind of hiding

969
01:16:55,856 --> 01:16:58,216
what models people are buying into.

970
01:16:58,996 --> 01:17:00,056
But I'm optimistic

971
01:17:00,056 --> 01:17:02,036
too. So I think there's enough there

972
01:17:02,036 --> 01:17:04,396
for another 5-10

973
01:17:04,396 --> 01:17:05,036
years of

974
01:17:05,036 --> 01:17:08,196
development and smoothing of

975
01:17:08,196 --> 01:17:08,696
processes.

976
01:17:10,136 --> 01:17:11,556
Yeah. And in the meantime, in parallel

977
01:17:11,556 --> 01:17:12,816
to your point,

978
01:17:13,576 --> 01:17:16,196
we need to wage the campaign to abolish

979
01:17:16,196 --> 01:17:18,036
the Bank Secrecy Act where all this

980
01:17:18,036 --> 01:17:18,636
insane

981
01:17:18,636 --> 01:17:21,896
privacy infringing

982
01:17:21,896 --> 01:17:24,936
compliance and regulation comes from.

983
01:17:25,656 --> 01:17:31,496
Can we somehow get the BSA as a person to insult Trump or something?

984
01:17:31,756 --> 01:17:36,316
I'm trying to think of a way of instigating constitutional crisis,

985
01:17:36,536 --> 01:17:38,476
because then maybe the courts will strike it down anyways.

986
01:17:38,616 --> 01:17:40,676
It's like, yeah, it wasn't constitutional anyways.

987
01:17:41,796 --> 01:17:41,976
Yeah.

988
01:17:42,396 --> 01:17:43,116
No, it is insane.

989
01:17:43,176 --> 01:17:47,496
We're dealing with the remnants of mistakes made many decades ago.

990
01:17:47,496 --> 01:17:54,396
Funnily enough, 1970, I think, is when the BSA was implemented.

991
01:17:54,396 --> 01:18:10,376
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

992
01:18:10,376 --> 01:18:12,316
everything to be reported at all times.

993
01:18:12,636 --> 01:18:15,756
It's really stark, I guess.

994
01:18:17,236 --> 01:18:17,436
Yeah.

995
01:18:17,876 --> 01:18:21,536
And admittedly, I haven't been following it as closely as it probably should be.

996
01:18:21,536 --> 01:18:26,796
But last I heard, there was this doesn't have anything to do with privacy.

997
01:18:26,796 --> 01:18:34,276
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.

998
01:18:34,596 --> 01:18:39,436
There was positive language in the Clarity Act, which hasn't been passed yet.

999
01:18:39,616 --> 01:18:41,816
I don't know if it's been taken out or revised out.

1000
01:18:42,136 --> 01:18:50,176
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?

1001
01:18:50,176 --> 01:18:58,816
Because again, you have the stablecoin bros, stablecoin contingent, and you've got the kind of Elizabeth Warren contingent at the moment.

1002
01:18:59,236 --> 01:19:05,976
And people are worried that Elizabeth Warren actually hates Bitcoin more than she hates to stablecoins.

1003
01:19:06,236 --> 01:19:08,176
So maybe a trade would happen there.

1004
01:19:12,156 --> 01:19:19,136
I'm optimistic long term, but you need to actually battle this out in Congress and in the courts.

1005
01:19:20,176 --> 01:19:39,476
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.

1006
01:19:39,476 --> 01:19:53,076
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.

1007
01:19:53,076 --> 01:20:05,816
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%.

1008
01:20:05,816 --> 01:20:13,916
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.

1009
01:20:14,216 --> 01:20:16,396
I think that'd be a huge win for the world.

1010
01:20:16,656 --> 01:20:19,336
And I think we can push that way.

1011
01:20:19,336 --> 01:20:25,016
I don't think that everything bad for me as a developer is good for Bitcoin, I guess is my point.

1012
01:20:25,236 --> 01:20:36,536
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.

1013
01:20:38,996 --> 01:20:43,296
Craig, I like that. I like that optimistic view. We should lead, by example.

1014
01:20:43,296 --> 01:20:45,356
I still have

1015
01:20:45,356 --> 01:20:45,956
I said earlier

1016
01:20:45,956 --> 01:20:46,216
I mean

1017
01:20:46,216 --> 01:20:46,956
the potential

1018
01:20:46,956 --> 01:20:47,896
the tools

1019
01:20:47,896 --> 01:20:48,476
the potential

1020
01:20:48,476 --> 01:20:49,116
it's all right

1021
01:20:49,116 --> 01:20:50,136
like we can build

1022
01:20:50,136 --> 01:20:50,856
yeah

1023
01:20:50,856 --> 01:20:51,716
an incredibly

1024
01:20:51,716 --> 01:20:53,616
transparent

1025
01:20:53,616 --> 01:20:55,056
robust

1026
01:20:55,056 --> 01:20:55,556
resilient

1027
01:20:55,556 --> 01:20:56,376
secure

1028
01:20:56,376 --> 01:20:58,756
relatively private

1029
01:20:58,756 --> 01:20:59,916
financial system

1030
01:20:59,916 --> 01:21:01,076
the potential's there

1031
01:21:01,076 --> 01:21:02,616
in general

1032
01:21:02,616 --> 01:21:03,456
freedom of speech

1033
01:21:03,456 --> 01:21:04,456
has gotten stronger

1034
01:21:04,456 --> 01:21:04,856
and stronger

1035
01:21:04,856 --> 01:21:05,696
in the United States

1036
01:21:05,696 --> 01:21:07,116
the one caveat is

1037
01:21:07,116 --> 01:21:07,836
oh but you did

1038
01:21:07,836 --> 01:21:08,696
talked about money

1039
01:21:08,696 --> 01:21:10,176
and suddenly this is like

1040
01:21:10,176 --> 01:21:11,056
a legal loophole

1041
01:21:11,056 --> 01:21:12,056
to throw you in jail forever

1042
01:21:12,056 --> 01:21:12,976
so I think like

1043
01:21:12,976 --> 01:21:18,896
just keep maximizing these first amendment gains as far as we can in the next

1044
01:21:18,896 --> 01:21:22,496
few years. Right. I think, I think it's possible.

1045
01:21:23,636 --> 01:21:30,896
I did too. Let's keep pushing. Yep. It's been awesome. This is the, uh,

1046
01:21:30,896 --> 01:21:37,816
this is the first time in a while I've, uh, gone deep on Bitcoin core stuff.

1047
01:21:37,816 --> 01:21:45,636
It always reignites the subdued nerd in me.

1048
01:21:46,696 --> 01:21:50,596
It makes me miss New York bit devs in the heydays

1049
01:21:50,596 --> 01:21:54,376
when I would nerd out with this stuff.

1050
01:21:54,816 --> 01:22:00,596
I think I went to probably 80% of the bit devs between 2015 and 2020.

1051
01:22:00,596 --> 01:22:02,676
and it's

1052
01:22:02,676 --> 01:22:05,276
easy to forget

1053
01:22:05,276 --> 01:22:06,896
the intricacies

1054
01:22:06,896 --> 01:22:09,276
and the complexity involved

1055
01:22:09,276 --> 01:22:11,356
in actually maintaining

1056
01:22:11,356 --> 01:22:13,596
and improving the Bitcoin

1057
01:22:13,596 --> 01:22:14,096
protocol

1058
01:22:14,096 --> 01:22:16,376
most people

1059
01:22:16,376 --> 01:22:19,416
are completely unaware

1060
01:22:19,416 --> 01:22:21,456
yeah like

1061
01:22:21,456 --> 01:22:23,636
with anything else there's a lot going under the hood

1062
01:22:23,636 --> 01:22:25,636
it doesn't directly

1063
01:22:25,636 --> 01:22:27,436
it's not a feature

1064
01:22:27,436 --> 01:22:29,156
for the user so it's hard to see

1065
01:22:29,156 --> 01:22:30,196
and show value

1066
01:22:30,196 --> 01:22:40,996
no i'm thinking too like as more institute like you have faith that uh the last question you have

1067
01:22:40,996 --> 01:22:45,076
faith that like as more institutions get in if banks get in that they'll have tech departments

1068
01:22:45,076 --> 01:22:51,156
that will understand the importance of understanding the intricacies of the protocol level

1069
01:22:51,156 --> 01:22:57,136
that i don't know i can't i think it's kind of we're also in an eternal september kind of situation

1070
01:22:57,136 --> 01:23:00,156
I would have expected

1071
01:23:00,156 --> 01:23:02,096
more

1072
01:23:02,096 --> 01:23:04,716
industry feedback

1073
01:23:04,716 --> 01:23:06,296
in a direct way

1074
01:23:06,296 --> 01:23:08,856
but you don't get that

1075
01:23:08,856 --> 01:23:11,396
people don't even really complain when things are broken

1076
01:23:11,396 --> 01:23:14,916
it is like a

1077
01:23:14,916 --> 01:23:17,296
there's a feedback loop problem with development

1078
01:23:17,296 --> 01:23:18,176
so

1079
01:23:18,176 --> 01:23:21,796
looking forward to find ways to solve that too

1080
01:23:21,796 --> 01:23:23,216
especially as things get bigger

1081
01:23:23,216 --> 01:23:26,376
think about it freaks

1082
01:23:26,376 --> 01:23:28,936
alright any final thoughts before we wrap up here

1083
01:23:28,936 --> 01:23:30,996
I appreciate you having me on

1084
01:23:30,996 --> 01:23:32,936
and excited for the future

1085
01:23:32,936 --> 01:23:33,356
still

1086
01:23:33,356 --> 01:23:36,616
future two days from now

1087
01:23:36,616 --> 01:23:41,016
Bitcoin dies tomorrow

1088
01:23:41,016 --> 01:23:42,856
so enjoy it while it lasts for you

1089
01:23:42,856 --> 01:23:44,416
because you've got 24 hours

1090
01:23:44,416 --> 01:23:45,976
yeah

1091
01:23:45,976 --> 01:23:49,196
all Bitcoin transactions are legal in the next 24 hours

1092
01:23:49,196 --> 01:23:52,616
alright see ya

1093
01:23:52,616 --> 01:23:52,876
thanks

1094
01:23:52,876 --> 01:23:55,296
peace and love freaks

1095
01:23:55,296 --> 01:23:55,716
Stick it.