CD179: SETH FOR PRIVACY QUARTERLY UPDATE

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 09/26/2025 21:40:23
Duration: 4454.144
Channels: 1

1
00:00:01.920 --> 00:00:04.420
And that is why today I am announcing

2
00:00:05.120 --> 00:00:09.139
this government will make a new free of charge digital ID

3
00:00:09.760 --> 00:00:10.260
mandatory

4
00:00:10.800 --> 00:00:12.019
for the right to work

5
00:00:12.320 --> 00:00:13.700
by the end of this parliament.

6
00:00:14.845 --> 00:00:18.945
Let me spell that out. You will not be able to work in The United Kingdom

7
00:00:19.405 --> 00:00:21.185
if you do not have digital

8
00:00:21.725 --> 00:00:22.225
ID.

9
00:00:22.845 --> 00:00:24.625
It's as simple as that.

10
00:01:02.949 --> 00:01:03.850
Happy Bitcoin

11
00:01:04.470 --> 00:01:08.490
Friday, freaks. It's your host, Odell, here for another Citadel Dispatch,

12
00:01:08.790 --> 00:01:11.690
the interactive live show focused on actual Bitcoin

13
00:01:12.585 --> 00:01:14.765
and Freedom Tech discussion.

14
00:01:16.745 --> 00:01:18.445
That intro clip was

15
00:01:18.825 --> 00:01:21.085
the prime minister of The UK

16
00:01:21.785 --> 00:01:22.605
with some

17
00:01:22.905 --> 00:01:26.285
dystopian news for our friends across the pond,

18
00:01:27.689 --> 00:01:28.829
forcing them into

19
00:01:30.250 --> 00:01:32.270
the digital ID future,

20
00:01:33.290 --> 00:01:38.430
and threatening their jobs if they do not comply, which is something that we've been tracking for a while.

21
00:01:40.925 --> 00:01:46.625
The trend has been getting worse and worse, but to actually see it actually come into practice is is quite dark.

22
00:01:47.005 --> 00:01:50.065
I have our friend, return guest to the show,

23
00:01:51.565 --> 00:01:53.104
Seth here. Seth for privacy.

24
00:01:53.725 --> 00:01:56.760
He's currently running Cake Wallet. How's it going, sir?

25
00:01:57.860 --> 00:02:03.720
Doing pretty well. Doing pretty well. I'm I'm sad I'm I'm on the road. I would have had my my mempool block pillow

26
00:02:04.020 --> 00:02:05.940
in the background that I'm rocking now.

27
00:02:06.500 --> 00:02:11.240
My my backdrop at home, it would have fit perfectly with the the mempool dot space up there. But,

28
00:02:11.995 --> 00:02:16.975
sadly, no. When I got as close as I could, it's at least somewhat mempool related. So you know?

29
00:02:17.355 --> 00:02:18.475
Well, I like these,

30
00:02:19.435 --> 00:02:24.255
I like doing these quarterly so you can you we can make sure you you're on brand next

31
00:02:25.050 --> 00:02:26.830
next trip. That's true. I'll travel

32
00:02:27.450 --> 00:02:33.230
with you next time. That shirt you're wearing was actually from the event that we were both at, which was the Oslo Freedom Forum,

33
00:02:34.810 --> 00:02:36.270
and it's a Whirlpool transaction.

34
00:02:37.130 --> 00:02:40.395
Crazy timing of that too because this was right

35
00:02:40.955 --> 00:02:41.455
after

36
00:02:42.155 --> 00:02:45.535
they were arrested. Yeah. But it was created all before

37
00:02:46.315 --> 00:02:47.855
we knew any of that. Like,

38
00:02:48.635 --> 00:02:51.295
they also know that it's a hard work. And

39
00:02:52.235 --> 00:02:54.475
Yeah. They commissioned it before the arrest, but,

40
00:02:55.500 --> 00:02:56.480
shout out them

41
00:02:57.580 --> 00:03:00.000
for leaning into it even harder after the arrest.

42
00:03:01.819 --> 00:03:02.319
Mhmm.

43
00:03:02.939 --> 00:03:04.079
That actually brings,

44
00:03:04.700 --> 00:03:05.519
me to

45
00:03:08.195 --> 00:03:10.375
my first question, which was

46
00:03:11.395 --> 00:03:13.095
by an audience member.

47
00:03:16.835 --> 00:03:17.335
Now

48
00:03:17.875 --> 00:03:18.695
now that

49
00:03:20.120 --> 00:03:22.060
the gentleman at samurai are

50
00:03:22.599 --> 00:03:24.700
they're about to face charges. I guess the,

51
00:03:25.640 --> 00:03:27.980
the ruling is coming up shortly, but, obviously,

52
00:03:28.359 --> 00:03:28.859
samurai,

53
00:03:31.159 --> 00:03:32.700
there's an there's a new

54
00:03:33.285 --> 00:03:35.785
samurai fork in town that's being maintained, Ashigaru,

55
00:03:37.685 --> 00:03:39.545
and their own Whirlpool implementation.

56
00:03:40.805 --> 00:03:42.425
In terms of Bitcoin CoinJoin,

57
00:03:43.444 --> 00:03:48.265
do you have a preference over that versus the current state of Wasabi or

58
00:03:49.879 --> 00:03:53.099
or join market? Do you have a preference there? How do you think about that?

59
00:03:53.879 --> 00:03:54.860
Yeah. I mean,

60
00:03:55.800 --> 00:03:58.860
I feel like we're still in a bit of a tricky place. I I think

61
00:03:59.560 --> 00:04:03.099
my preference, like, if I had to use one, would be Ashigaru.

62
00:04:05.825 --> 00:04:06.325
But

63
00:04:07.105 --> 00:04:09.685
just the amount of trust required in coordinators

64
00:04:10.145 --> 00:04:11.205
in both approaches

65
00:04:12.225 --> 00:04:19.870
makes it a little concerning for me. I mean, Ashigaru guys seem seem great, seem on brand so far, or seem like their heads down just doing the work,

66
00:04:20.569 --> 00:04:24.909
which I like, but, obviously, they're also anonymous. Like, one of the benefits of the samurai guys

67
00:04:25.449 --> 00:04:32.110
being somewhat known was you you had kind of someone to tie a reputation to, and they proved themselves over the course of six years.

68
00:04:33.685 --> 00:04:35.145
Yeah. I mean, you can have an anon

69
00:04:35.525 --> 00:04:46.230
as long as long as the anon has long term reputation in the space, which you actually got regards to not have. Yeah. Yeah. Yeah. For sure. For sure. Yeah. That's it's not a problem once they prove themselves, but

70
00:04:46.630 --> 00:04:48.890
specifically, because you're so reliant on the coordinator

71
00:04:49.270 --> 00:04:51.130
being legitimate for civil resistance.

72
00:04:52.790 --> 00:04:53.290
Like

73
00:04:53.750 --> 00:05:00.490
yeah. It it's just it's something where I'm a little bit hesitant to, like, recommend it to the average person. But if I had to choose one, it would definitely be

74
00:05:01.435 --> 00:05:10.815
over Wasabi, even though I think in theory, Wasabi can be okay these days too if you use a good coordinator. But they've just had so many, like, teething pains

75
00:05:11.354 --> 00:05:15.375
of this, like, choose your own coordinator model that it's been

76
00:05:15.870 --> 00:05:17.650
been painful as well. Have you tested

77
00:05:18.030 --> 00:05:20.290
have you tested the new Ashigawa Whirlpool?

78
00:05:20.990 --> 00:05:22.050
I have not. No.

79
00:05:22.990 --> 00:05:26.930
No. I I mean Yeah. Go ahead. Go ahead. No. No.

80
00:05:27.485 --> 00:05:33.745
We'll get the group. I was gonna say that I mean, my personal recommendation when people ask me now is I'd say wasabi.

81
00:05:34.764 --> 00:05:40.225
I think the Asha Gaur team I I think centralized coordinator model inherently, there's trust in the coordinator.

82
00:05:40.845 --> 00:05:41.345
Yep.

83
00:05:42.479 --> 00:05:42.979
I,

84
00:05:44.080 --> 00:05:46.979
the proof of work is just not there yet with the Ashigar guys.

85
00:05:48.000 --> 00:05:59.835
So we'll see, you know, as as as that develops and as that gets built out. The liquidity is also significantly less. Mhmm. Just because it's a it's a fresh liquidity pool.

86
00:06:01.335 --> 00:06:03.115
The, you know, the keys the keys,

87
00:06:03.574 --> 00:06:06.555
of the last liquidity pool died with the samurai rest.

88
00:06:06.935 --> 00:06:11.035
So it's a completely fresh liquidity pool. A lot of my complaints about Wasabi

89
00:06:11.479 --> 00:06:13.180
have been solved throughout the years,

90
00:06:15.000 --> 00:06:16.380
so that's good to see.

91
00:06:17.160 --> 00:06:19.340
And then one of the biggest complaints

92
00:06:19.880 --> 00:06:22.139
was the actual z k Snacks coordinator.

93
00:06:22.759 --> 00:06:23.259
Yeah.

94
00:06:23.720 --> 00:06:27.100
And now they switched to an open coordinator model where anyone can run a coordinator.

95
00:06:27.665 --> 00:06:33.205
And the current main coordinator, like the one with all the liquidity, is run by this guy named Crew,

96
00:06:34.465 --> 00:06:34.965
who

97
00:06:35.585 --> 00:06:38.725
does have a pretty long track record in the space,

98
00:06:39.665 --> 00:06:40.805
and seems legit.

99
00:06:41.790 --> 00:06:43.410
So it's easy to use.

100
00:06:44.510 --> 00:06:46.930
You know, your mileage may vary.

101
00:06:47.950 --> 00:06:51.410
Don't take it as a hard and fast recommendation. But if you are looking for

102
00:06:51.870 --> 00:06:56.530
a CoinJoin tool in Bitcoin land right now, my personal recommendation is Wasabi

103
00:06:57.655 --> 00:06:59.595
with, with cruise coordinator specifically.

104
00:07:00.375 --> 00:07:01.115
Have you

105
00:07:01.655 --> 00:07:02.555
have you run-in

106
00:07:04.134 --> 00:07:05.195
with tainted coins

107
00:07:05.895 --> 00:07:06.955
after using it?

108
00:07:08.375 --> 00:07:11.730
I mean, it depends on which service you use, and it depends which,

109
00:07:13.010 --> 00:07:20.870
round a UTXO is in. Right? Like, I don't think either CoinJoin implementation solves that. Right? It's like Mhmm. You're doing a collaborative transaction,

110
00:07:21.890 --> 00:07:24.310
with other parties. So who is in your

111
00:07:24.645 --> 00:07:26.425
is in your CoinJoin with you?

112
00:07:27.845 --> 00:07:29.705
But, yeah, I mean, I think that's just

113
00:07:30.085 --> 00:07:42.420
that's just an issue or a trade off with CoinJoin in general. I think we both have talked about it a lot in the past, which is it's incredibly obvious on chain. Yeah. So if a service wants to block CoinJoin specifically,

114
00:07:43.680 --> 00:07:45.780
it's relatively easy for them too.

115
00:07:46.080 --> 00:07:50.260
And if they wanna apply taints to who depending on who you're in around with,

116
00:07:51.920 --> 00:07:53.540
then they can do that as well.

117
00:07:54.074 --> 00:07:57.455
Yeah. The the odd thing that I've seen so far is I've I

118
00:07:57.914 --> 00:08:01.694
I have used Wasabi since they shut down the z k snacks coordinator,

119
00:08:03.514 --> 00:08:07.375
a good bit, and I have had multiple instances of frozen funds.

120
00:08:08.090 --> 00:08:10.350
Obviously, I'm not using any KYC exchanges,

121
00:08:10.810 --> 00:08:12.350
but, Yeah. But

122
00:08:13.450 --> 00:08:15.150
the Monero swap services

123
00:08:15.450 --> 00:08:16.990
are actually tend to be worse,

124
00:08:17.690 --> 00:08:31.125
if that's what you're using it for. But that's From That's kinda the oddness. I mean, that is that is where I've had it. From what I hear. Yeah. Yeah. That's that is where I've had it. Instant exchanger's kinda problematic. These weren't instant exchangers through cake. Just for clarity, I did use them externally, but,

125
00:08:32.065 --> 00:08:35.525
it was I was surprised because I had done the same

126
00:08:35.905 --> 00:08:37.925
with samurai funds for years,

127
00:08:38.839 --> 00:08:42.620
and I never had any instance of Interesting. Funds being frozen,

128
00:08:43.959 --> 00:08:48.699
whereas in relatively little usage compared to how often I had done this in the past.

129
00:08:49.399 --> 00:08:49.899
I

130
00:08:50.375 --> 00:08:51.815
had issues multiple times.

131
00:08:52.295 --> 00:08:53.915
Obviously, I won't name specifics

132
00:08:54.455 --> 00:08:55.435
for my one OPSEC

133
00:08:56.055 --> 00:09:02.075
and others, but it was very surprising to me and and made me kind of wonder if there's just a much more aggressive

134
00:09:02.615 --> 00:09:03.115
wasabi

135
00:09:03.495 --> 00:09:03.995
specific

136
00:09:05.090 --> 00:09:07.670
taint that is is filtering it out. I mean,

137
00:09:08.130 --> 00:09:11.910
I know that there's been some interesting flows through cruise coordinators specifically

138
00:09:12.450 --> 00:09:13.650
that are very, very high,

139
00:09:15.890 --> 00:09:17.270
Yeah. My guess is it depends.

140
00:09:17.634 --> 00:09:22.134
It it definitely there's definitely a part of it that depends what rounds you're in. Right?

141
00:09:22.755 --> 00:09:26.055
Maybe I just got unlucky, and he was with, like, Bitfinex Hacker or something.

142
00:09:26.514 --> 00:09:27.795
Something really bad. Like I

143
00:09:28.595 --> 00:09:32.375
and I don't I don't really know what the mitigation is there. I mean,

144
00:09:32.940 --> 00:09:46.640
the attempted mitigation with the z k snacks guys was to blacklist on the input side, which I think is not a reasonable trade off. Yeah. So it's just something that, you know, you have to kinda take with it. Anyway, I completely derailed the conversation.

145
00:09:48.145 --> 00:09:50.404
I don't even know oh, it came up because of your shirt.

146
00:09:50.705 --> 00:09:52.085
Yeah. But, Freaks,

147
00:09:52.785 --> 00:09:58.485
as always, dispatch is funded by viewers like you with Bitcoin donations. We have no ads or sponsors.

148
00:09:59.920 --> 00:10:02.340
Last week's show, our largest Zap,

149
00:10:02.880 --> 00:10:06.820
was 10,000 sats from ride or die freak Mav 21.

150
00:10:07.120 --> 00:10:10.180
You can find out how to support the show at hilldispatch.com.

151
00:10:10.560 --> 00:10:12.340
All of the relevant links are there.

152
00:10:13.255 --> 00:10:16.955
And I see you guys are joining the live chat, whether that's through zapped.stream

153
00:10:17.015 --> 00:10:17.515
or,

154
00:10:19.095 --> 00:10:26.235
any Napster app that supports video streaming. I've been personally helping build out Primal. You can download in your favorite app store.

155
00:10:27.110 --> 00:10:29.589
And I see Vik zapped 21,000

156
00:10:29.589 --> 00:10:30.089
sats.

157
00:10:30.870 --> 00:10:35.050
He's advertising his new service, bitcointutorials.org.

158
00:10:35.190 --> 00:10:35.690
V

159
00:10:36.070 --> 00:10:37.510
bitcointutorials.org

160
00:10:37.510 --> 00:10:44.145
is the website. And as you can imagine, it's got Bitcoin tutorials on it. Anyway, Seth, since we last had you on

161
00:10:47.965 --> 00:10:53.025
oh, I just checked the YouTube chat. Just so I can show O'Dell recommending Wasabi lost the plot.

162
00:10:53.565 --> 00:10:54.525
I will say,

163
00:10:54.845 --> 00:10:57.600
that there's still no love lost, with

164
00:10:57.980 --> 00:10:59.520
the old Wasabi team.

165
00:11:00.140 --> 00:11:01.200
No Power himself,

166
00:11:02.060 --> 00:11:02.800
was grandstanding

167
00:11:03.180 --> 00:11:05.520
on Twitter after the recent Peter Todd,

168
00:11:07.820 --> 00:11:12.675
article about CoinJoin implementations, about how Matodel was wrong, blah blah blah,

169
00:11:13.075 --> 00:11:18.535
and completely ignored that they did a complete rewrite of Wasabi since I voiced my concerns

170
00:11:19.075 --> 00:11:23.735
and never acknowledged that my concerns were valid and then proceeded to fix most of them.

171
00:11:24.115 --> 00:11:28.135
And, also, No Power is no longer involved with the project, and they've made a lot of progress

172
00:11:28.460 --> 00:11:30.160
specifically since, the samurai,

173
00:11:31.100 --> 00:11:32.080
guys got arrested,

174
00:11:33.980 --> 00:11:36.880
pushing out you know, just removing it from the company.

175
00:11:37.580 --> 00:11:39.200
And I think that should be,

176
00:11:39.820 --> 00:11:41.360
acknowledged. That should be acknowledged.

177
00:11:41.740 --> 00:11:43.440
Unfortunately, there's not much

178
00:11:44.595 --> 00:11:53.575
good privacy work happening in the Bitcoin space, and I think, the open source team that is now focused on building Awasabi and Cruise specifically for actually running a coordinator,

179
00:11:55.555 --> 00:11:58.195
stand out from the rest in a lot of ways. And,

180
00:11:59.130 --> 00:12:01.150
you'll always speak my mind on that regard.

181
00:12:01.930 --> 00:12:04.030
Yeah. Exactly. Like, I wouldn't have a coordinator.

182
00:12:05.690 --> 00:12:06.190
So

183
00:12:06.810 --> 00:12:08.670
should, you know, shout out him for that.

184
00:12:10.170 --> 00:12:15.345
Okay. Back to the topic at hand. Cake wallet, you guys have made a lot of progress. You've been shipping stuff.

185
00:12:16.045 --> 00:12:19.745
The big thing you shipped is, Cupcake. You wanna tell us about Cupcake?

186
00:12:20.365 --> 00:12:21.405
For sure. For sure.

187
00:12:21.885 --> 00:12:32.110
So, yeah, I mean, we have obviously long had this focus on trying to make things really accessible and useful for the average person and not just, like, the the westerner, the ton of money.

188
00:12:32.410 --> 00:12:36.030
And a really cool idea that, Vic came up with was basically,

189
00:12:36.410 --> 00:12:40.270
why don't we make a simpler way to turn in the old hardware wallet?

190
00:12:40.890 --> 00:12:48.085
And I know, technically, you've been able to do this for a while. Like, you could use you could have used Sentinel like this, SamuraWallet Sentinel,

191
00:12:48.705 --> 00:12:52.005
technically, to kind of create the transaction with the keys offline,

192
00:12:52.785 --> 00:12:54.805
and then transmit it using SamuraWallet.

193
00:12:55.440 --> 00:12:58.740
So a similar thing has actually been possible for years, but

194
00:12:59.040 --> 00:13:04.740
no one had really built it out in a way that was more user friendly or that was something that also was,

195
00:13:05.760 --> 00:13:11.925
supportive of Monero, which is obviously another focus for us at Cake Wallet. So we we started with Monero, and we launched

196
00:13:12.305 --> 00:13:21.745
a very alpha version, about a year ago now, with only Monero support. But Bitcoin was always the real target. I think that's the most useful fit right now more so than Monero.

197
00:13:22.144 --> 00:13:25.180
Don't tell the Monero guys, but I'm sure they're not watching us.

198
00:13:26.280 --> 00:13:29.740
But Bitcoin was definitely the target for that. The the idea really is

199
00:13:30.360 --> 00:13:32.940
there are obviously lots of benefits to having

200
00:13:33.640 --> 00:13:38.780
your keys on a separate device, specifically an offline device if you can, but really on something that is very secure.

201
00:13:39.455 --> 00:13:42.435
But, obviously, the downside to this has always been

202
00:13:42.895 --> 00:13:44.515
not only are harder wallets expensive,

203
00:13:44.895 --> 00:13:55.110
but how do you actually get one in a way that doesn't just announce to the world or at least announce to the manufacturer, hey. I have a lot of Bitcoin, and I want to keep it safe at this address.

204
00:13:55.829 --> 00:14:02.329
And most people are just ordering these things straight to their homes, which I understand. Like, I have done that in the past. I've I have made that mistake, but

205
00:14:02.630 --> 00:14:09.769
there are a lot of downsides to doing that. Even in the best case scenario, it's not ideal. But in the worst case scenario, I e, the ledger act that everyone knows about,

206
00:14:11.225 --> 00:14:14.925
your ownership of large amounts of crypto, at least comparatively,

207
00:14:15.625 --> 00:14:16.685
and where you live

208
00:14:17.145 --> 00:14:21.165
being tied together is, like, nightmare fuel, from an OPSEC perspective.

209
00:14:22.200 --> 00:14:31.100
So we wanted to simplify this and also to allow people who are in jurisdictions and geographies that don't have access to hardware wallets because you can't get them shipped everywhere.

210
00:14:31.560 --> 00:14:38.235
And even if you can, a lot of times, it's horribly cost prohibitive to get a hardware wallet actually through customs and everything in many countries.

211
00:14:38.615 --> 00:14:52.780
Like I was there, I worked at foundation, like, you know, all too well how painful that is doing international delivery of these things. Plus, then you have even more privacy violations because then customs knows exactly who you are, where you live, and that you bought a Gold Guard or you bought a passport or you bought a ledger.

212
00:14:53.880 --> 00:14:57.340
And so cupcake that is turning your old phone,

213
00:14:57.960 --> 00:14:59.500
preferably something on, like, GrapheneOS,

214
00:15:00.360 --> 00:15:11.555
something that's very secure or an old iPhone that still gets security updates. And I can talk a little bit more about, like, exactly what I recommend later, but using something like that to keep your keys separate and offline.

215
00:15:11.855 --> 00:15:19.350
You can go super hardcore mode. You can keep the device always offline, OS updates. But if you do truly keep it always offline, there are downsides to that.

216
00:15:19.829 --> 00:15:21.610
Or you just rely on

217
00:15:22.069 --> 00:15:29.529
good device security and the app itself being open source, audited, and not having the ability to access network at all,

218
00:15:29.910 --> 00:15:31.930
and thus no ability to exfiltrate keys,

219
00:15:32.630 --> 00:15:34.410
and be able to use an old

220
00:15:34.904 --> 00:15:45.404
phone as a hardware wallet. So the the way it actually works is essentially the same as something like passport or a cold card where you use animated QRs to to transmit signed transactions

221
00:15:45.705 --> 00:15:50.740
back and forth. So that's gonna be the same exact flows that you're used to there. Nothing too, like,

222
00:15:51.440 --> 00:15:57.220
novel very intentionally. Like, we used industry standards. We used, BCUR is what we default to,

223
00:15:57.840 --> 00:16:05.300
which is what Passport uses. Seed center uses a version of that, Jade, many other Ergap hardware wallets. And then we also have BBQR support

224
00:16:05.815 --> 00:16:07.995
too in Cake Wallet and in Cupcake,

225
00:16:08.615 --> 00:16:13.995
if you specifically need to use that. But we do default to BCUR because it is a little bit more of the industry standard.

226
00:16:14.615 --> 00:16:29.870
But really simple. You can just obviously keep your keys offline. You can create the transaction in Cake Wallet or actually in any other software wallet that supports air gapped hardware wallets. Something we touched on a little bit before the show is you can pretend that cupcake is a passport, for instance, and use it with Sparrow.

227
00:16:30.410 --> 00:16:32.990
It will work just fine because it speaks the same language.

228
00:16:33.850 --> 00:16:37.675
And you are able to keep your keys offline, still be able to spend easily.

229
00:16:38.135 --> 00:16:39.995
You don't have to dox yourself to

230
00:16:40.295 --> 00:16:42.795
a hardware wallet company. You don't have to spend any money,

231
00:16:43.735 --> 00:16:55.250
which the, like, the other benefit to this and something that, like, I wanna talk a lot to the HRF about just generally, like, maybe also Freedom Forum next year is I think this is a really, really, really useful tool for

232
00:16:56.270 --> 00:16:58.450
political dissidents, journalists, activists,

233
00:16:59.710 --> 00:17:02.930
refugees, anyone fleeing a country because you can have

234
00:17:03.745 --> 00:17:13.044
relatively easy access to secure storage without anything extra being out there about you and linking you back to crypto storage. Not to mention it's much easier to uncover after.

235
00:17:13.345 --> 00:17:14.645
And, like, when you're traveling

236
00:17:15.184 --> 00:17:17.684
Yeah. The difference between having, like, a

237
00:17:18.010 --> 00:17:19.470
Pixel phone in your,

238
00:17:21.049 --> 00:17:25.549
in your bag versus having a cold card in your bag is a completely different ballgame.

239
00:17:26.090 --> 00:17:30.190
Very much so. Very much so. I think, thankfully, if you have something that's not a ledger

240
00:17:30.934 --> 00:17:37.015
right now, they're niche enough that you Yeah. Aren't usually gonna have problems. You'll you'll more just get weird looks like, what the hell is this?

241
00:17:37.495 --> 00:17:40.955
Like, I I traveled with my passport many times, and I've had twice

242
00:17:41.255 --> 00:17:51.440
the, like, TSA agent be like, just just give me a weird look and let it pass. But they've never actually done anything because it doesn't mean no one knows what a passport is at TSA. Like, it's niche enough. Maybe they'd know a ledger.

243
00:17:52.700 --> 00:17:55.200
I got, I went on McCormick's show,

244
00:17:56.220 --> 00:17:57.680
like, three years ago,

245
00:17:59.065 --> 00:18:01.645
and he was sponsored by Ledger at the time.

246
00:18:03.065 --> 00:18:09.485
Honestly, I think it was the it was one of the shows where we're shitting on Ledger, and I got a free Ledger out of it.

247
00:18:11.225 --> 00:18:11.625
And,

248
00:18:12.690 --> 00:18:15.429
so I traveled with a ledger in the box,

249
00:18:15.970 --> 00:18:17.990
like, sealed. It's a book move.

250
00:18:18.529 --> 00:18:28.795
Well, I mean, what does it matter? I was just curious. I wanted to see if if, TSA would pick it up, and they never picked it up. I mean, I must've I traveled a little bit, like, six times security or seven times through security.

251
00:18:29.175 --> 00:18:29.675
Wow.

252
00:18:30.455 --> 00:18:34.875
Because I was just curious. Like, are they paying attention to it yet? Mhmm. It's still probably a little bit early.

253
00:18:35.255 --> 00:18:41.035
I mean, there could be a point. I I wouldn't be surprised if there's a point. I mean, we started off with the digital IDs in The UK.

254
00:18:41.570 --> 00:18:43.250
There's a there's a point where

255
00:18:44.130 --> 00:18:47.750
well, I've always expected there to be a point where there'd be lists of known Bitcoiners,

256
00:18:49.490 --> 00:18:52.710
where regardless of what you're traveling with, you're on an, you know,

257
00:18:53.010 --> 00:18:54.550
additional security list.

258
00:18:56.215 --> 00:18:58.635
But, fortunately, that hasn't happened yet, and,

259
00:18:59.015 --> 00:19:05.195
you know, I don't know. We'll see we'll see where that goes. But, yeah, anyway, back to Cupcake. I mean, look. I think this is a really cool tool.

260
00:19:05.495 --> 00:19:09.355
You guys have made it very clean and very easy to use, very obvious interface.

261
00:19:09.670 --> 00:19:13.050
Mhmm. It's almost exactly what you would expect if if

262
00:19:13.510 --> 00:19:17.050
you've used any of these QR based signers in the past. Yep.

263
00:19:17.670 --> 00:19:19.770
Almost everyone already has an old phone.

264
00:19:20.150 --> 00:19:20.650
Mhmm.

265
00:19:21.350 --> 00:19:28.145
You can also like, I think there's a decent argument for buying a new phone to use with something like this depending on how much money you're storing.

266
00:19:28.605 --> 00:19:33.825
You know? What? You go out and buy, like, a $300 Pixel or something, install graphene on it.

267
00:19:34.205 --> 00:19:34.705
Yeah.

268
00:19:35.005 --> 00:19:44.340
I think there's probably significant benefits on the security side. There's like this is a problem with a tool like this is a nice thing about buying a cold card is you have a very

269
00:19:45.040 --> 00:19:45.540
strong

270
00:19:45.840 --> 00:19:46.820
security guarantee

271
00:19:47.280 --> 00:19:48.180
that's uniform.

272
00:19:48.560 --> 00:19:51.380
Mhmm. But with a tool like this, it very much

273
00:19:52.000 --> 00:19:52.500
depends

274
00:19:53.040 --> 00:19:53.540
on

275
00:19:54.105 --> 00:20:04.184
what devices you're using with. I mean, you talked about connecting it to the Internet to get security updates or get, I guess, app updates too. Right? Like, I imagine you guys are gonna update Cupcake. For sure.

276
00:20:04.505 --> 00:20:10.090
So it's hard to give, like, a hard and fast, like, these are the security benefits you get, but I

277
00:20:10.549 --> 00:20:12.330
it's it's it's clearly

278
00:20:13.190 --> 00:20:18.090
it's clearly a useful tool that gives you pretty strong security across the board just from being

279
00:20:18.710 --> 00:20:24.115
mostly offline and in mostly a clean environment. Like, if you're not using it with anything else

280
00:20:24.655 --> 00:20:30.515
Yeah. You know you don't have, like, additional malware on the device. Can we talk a little bit about how you think about that?

281
00:20:31.054 --> 00:20:32.595
Yeah. I mean, like,

282
00:20:32.895 --> 00:20:41.980
I do wanna be really clear. Like, I don't view this as replacing hardware wallets entirely. Like, that's not that's not at all the goal, and that's not really the target demographic. Like, if you have a cold card,

283
00:20:42.519 --> 00:20:55.335
just use your cold card. Like, the only reason in that case you would maybe use Cupcake would be if you wanted to use it with Monero or with Litecoin or with Bitcoin silent payments. Like, that's obviously a goal of ours is to have native silent payment support.

284
00:20:56.675 --> 00:20:59.815
Or if you want to have, like, interesting advanced functionality,

285
00:21:00.115 --> 00:21:02.535
like, we have bit three fifty three verification,

286
00:21:03.795 --> 00:21:06.055
coming soon where it'll actually validate the DNSSEC

287
00:21:06.780 --> 00:21:07.280
signatures

288
00:21:07.580 --> 00:21:11.920
all the way through, let you see the username itself in cupcake. Like, we'll be able to do

289
00:21:12.540 --> 00:21:22.315
basically, we'll be able to move a lot quicker on these tertiary features. Obviously, we won't mess with the the security, but the the thing that we can do is we can we can implement more, like, cutting edge

290
00:21:22.775 --> 00:21:26.315
things in it that would be much harder on something where you have to ship a whole firmware update,

291
00:21:26.934 --> 00:21:28.875
to be able to implement these new things.

292
00:21:30.455 --> 00:21:33.355
So, yeah, I I don't view it as replacing hardware wallets.

293
00:21:33.815 --> 00:21:37.195
To me, it really is something that is it's there for people who

294
00:21:37.530 --> 00:21:44.970
can't get a hardware wallet or shouldn't get a hardware wallet, which is basically activists or people in countries where spending $300

295
00:21:44.970 --> 00:21:51.710
on it would be nonsense because they probably only have dollars of crypto. Maybe they're storing USDT or they're storing

296
00:21:52.735 --> 00:22:02.195
the Sats that they've been able to collect. Like, it's not something where we're replacing something like that. So I really view it as more like, how can we give the 99% who will never buy

297
00:22:02.654 --> 00:22:04.434
a harder wallet, if we're honest?

298
00:22:04.815 --> 00:22:05.955
How do we give them

299
00:22:06.330 --> 00:22:07.070
80%,

300
00:22:07.130 --> 00:22:13.070
85, 90% of the functionality and security of a hardware wallet, without them having to spend anything?

301
00:22:13.370 --> 00:22:19.549
And that's specifically, like, why we're talking so much about old phones because if you if you if you look at any part of the global south,

302
00:22:20.090 --> 00:22:21.390
any developing country,

303
00:22:21.895 --> 00:22:27.595
everyone already has a phone. There are countries where people will not have electricity. They won't have running water, but they'll have a smartphone.

304
00:22:28.054 --> 00:22:32.554
And they'll iterate through those smartphones. They'll have old ones. Like, it's something that's just a a ubiquitous

305
00:22:32.855 --> 00:22:36.740
universal thing right now. So it makes sense to target from that perspective.

306
00:22:37.200 --> 00:22:40.820
But, yeah, very much not replacing a hardware wallet. Like, those are always going to be

307
00:22:41.440 --> 00:22:41.940
more

308
00:22:42.320 --> 00:22:43.540
hardcore security

309
00:22:44.320 --> 00:22:49.300
with all the pros and cons that comes with that. But those would be more like if if you're talking generational wealth,

310
00:22:49.765 --> 00:22:51.125
you should probably be using,

311
00:22:51.605 --> 00:22:55.304
a hardware wallet. If you're talking, like, a treasury company, if you're talking,

312
00:22:55.725 --> 00:22:56.585
a company

313
00:22:57.125 --> 00:23:03.145
like Vault, that kind of thing, you should be doing multisig with hardware wallets. Like, I I absolutely think that those things still are

314
00:23:03.450 --> 00:23:09.309
necessary and useful, but this is more for different people. But you're right that I think the hardest thing when you talk about something like cupcake

315
00:23:10.169 --> 00:23:12.590
is so much of the security comes down to

316
00:23:13.210 --> 00:23:17.995
what device is it on, what OS is it running, Is it getting security updates? Is it not?

317
00:23:18.315 --> 00:23:21.055
Is the user using a secure PIN to properly

318
00:23:21.355 --> 00:23:24.735
secure the device itself? Now, obviously, Cupcake itself has a separate,

319
00:23:25.915 --> 00:23:28.015
separate auth. You can do PIN or password.

320
00:23:28.549 --> 00:23:35.370
We have protections in place where on a device that has secure enclave or secure element, we're obviously using that to the fullest extent,

321
00:23:35.750 --> 00:23:36.809
sandboxing, etcetera.

322
00:23:37.190 --> 00:23:39.130
But even on devices that don't have

323
00:23:39.510 --> 00:23:42.090
hardware protections for PIN or password entry,

324
00:23:42.725 --> 00:23:47.785
we're doing some really interesting proof of work to essentially ensure that you can't brute force the PIN,

325
00:23:49.925 --> 00:23:58.500
infinitely quickly. Obviously, you're we're still gonna be limited. Like, the the best would be that you have something like a Pixel or an iPhone that has incredibly smart or cheap.

326
00:23:59.280 --> 00:24:04.100
For Ledger Don John. For sure. I would love for him to think to do this one and get that. I mean,

327
00:24:04.480 --> 00:24:19.294
that's important because particularly if the tar if part of the target, which I makes sense to me, is the developing world. They're probably gonna be using it on, like, a shitty old Android phone that's Oh, yeah. Really cheap, does not have a secure element. They're not gonna be running graphene on it. Yeah.

328
00:24:21.514 --> 00:24:28.095
So that makes sense to me. Just try and harden it as much as possible. I also just I think this just goes to show, like, the power of open standards.

329
00:24:28.450 --> 00:24:33.510
Right? Like, I think it's super cool that that now means you can use a cold card or a passport

330
00:24:33.890 --> 00:24:34.390
or

331
00:24:34.690 --> 00:24:41.110
any of these other QR based signers with Cake Wallet. I think it's really cool that you can use Cupcake with any of the existing coordinators,

332
00:24:41.490 --> 00:24:43.910
whether that's something like Cobalt or Sparrow,

333
00:24:45.164 --> 00:24:45.904
or Nunchuck.

334
00:24:46.205 --> 00:24:47.505
Like, that's really cool.

335
00:24:48.284 --> 00:24:50.144
And it just shows how open standards

336
00:24:50.445 --> 00:24:57.505
may compound on top of each other. Oh, yeah. Oh, yeah. And and you guys can ship something, and then it makes everything up. Like, you've mentioned multisig.

337
00:24:57.965 --> 00:24:58.705
Like, presumably,

338
00:24:59.164 --> 00:25:04.200
like, once again, like, it depends on your, trade off model. But, like, you could be in an organization

339
00:25:05.139 --> 00:25:10.840
that's using a spiral multisig because I think multisig specifically is really important, really useful in organizations.

340
00:25:11.220 --> 00:25:13.799
Mhmm. And one of the people could be using a cupcake

341
00:25:14.385 --> 00:25:14.885
signer.

342
00:25:15.345 --> 00:25:19.365
And the rest of the users, you know, maybe they're on hardware wallets. They have no idea. Whatever.

343
00:25:20.065 --> 00:25:23.845
It's just open standard. Pretty cool. Even if you can expand that to, like, an organization

344
00:25:24.145 --> 00:25:25.105
that isn't

345
00:25:25.745 --> 00:25:36.650
I mean, like, I know this this is kind of the Federman thing of, like, the the village elders model of, like, this group of people who maybe spending a thousand dollars on hardware wallets to do a multiseg

346
00:25:37.270 --> 00:25:45.154
would make it completely pointless to do a multiseg, and instead, they just are using one dude's hot wallet. Like, this this would allow them to, at no cost,

347
00:25:45.695 --> 00:25:47.315
suddenly be using multisig,

348
00:25:47.774 --> 00:25:52.595
which is pretty cool. We now to to clarify for now, we have not specifically built for multisig.

349
00:25:53.510 --> 00:26:04.649
That's not really a focus for us, but it's something that I I do want to do in there. Theoretically, you could still do it, but we don't have some of the more advanced multisig stuff like, validating addresses, like storing the,

350
00:26:05.029 --> 00:26:19.865
descriptor on the device so that you can actually validate addresses on device, that sort of thing. Because some of that does get a little bit more a little bit more advanced, and it's obviously not our the the key focus of Cupcake, but it does open up, like, multi sig, which would be prohibitively expensive in much of the world.

351
00:26:20.565 --> 00:26:23.310
Down the line, it will will open that up to them as well.

352
00:26:23.710 --> 00:26:25.650
I mean, it'd be nice if you added that.

353
00:26:25.950 --> 00:26:33.490
I assume, like, it's just a love a matter of priorities. I mean, the big thing is as a heavy user multisig is it's

354
00:26:33.950 --> 00:26:46.395
it's important to me that the signer is verifying the change address. Oh, yeah. Oh, yeah. For sure. And that's why, like, I wouldn't recommend it for a multisite right now because we don't have that more advanced functionality that that Gold Guard, Passport, etcetera do.

355
00:26:47.335 --> 00:26:53.130
So it'd be it'd be I mean, blind signing isn't quite accurate, but you wouldn't be able to properly validate everything

356
00:26:53.510 --> 00:27:14.625
right now. Unless, like, for instance, you used cupcake as only one of three where you could validate it on the other devices where you're still getting some validation. Even if you can't validate it on all, if you can validate it on two or three or something, you could could still be interesting. But that is definitely something that we we are gonna add. But, like, I'll I'll be completely honest. I think, like, we are very retail focused, and I've been pretty vocal

357
00:27:14.925 --> 00:27:19.105
over the years that I think multisig is not something that the vast majority of people need.

358
00:27:19.549 --> 00:27:23.090
So I really am pretty focused on, like, most of our resources going towards

359
00:27:23.390 --> 00:27:27.010
the, again, the majority. Like, how do we target the 95%,

360
00:27:27.390 --> 00:27:30.049
what they need? And most people don't need multisig,

361
00:27:31.150 --> 00:27:36.715
even if it is free. But organizations, like you mentioned, is the that's the killer app, and that's where Bitcoin is, like

362
00:27:37.255 --> 00:27:42.955
it makes things way better than the fiat paradigm, which is a fascinating, like, specific crossover for Bitcoin.

363
00:27:43.575 --> 00:27:44.955
Look. The average user

364
00:27:46.055 --> 00:27:53.390
the the the best option first of all, the beautiful thing about Bitcoin is there is no single best option. Right? It matters about your job model,

365
00:27:54.250 --> 00:27:57.149
and your use case and your technical ability.

366
00:27:57.690 --> 00:27:58.590
But for the

367
00:27:59.130 --> 00:28:01.230
like you said, the overall majority users,

368
00:28:01.665 --> 00:28:02.965
single sig offline

369
00:28:03.345 --> 00:28:04.245
cold storage,

370
00:28:05.825 --> 00:28:11.525
is is an amazing security set and very convenient to use and hard to fuck up.

371
00:28:12.065 --> 00:28:16.405
Maybe add a pass raise on top of it if your threat model is a little bit more,

372
00:28:17.050 --> 00:28:17.550
severe.

373
00:28:18.090 --> 00:28:22.750
And then multisig is for me, like, it's usually public figures and organizations.

374
00:28:23.130 --> 00:28:27.390
Like, that's where multisig really shines. They have a a very much higher

375
00:28:29.125 --> 00:28:33.065
threshold in their in their threat model. It's a more significant threat model.

376
00:28:33.924 --> 00:28:44.265
And as a result, they can take advantage of the additional multisig. What I see a lot is people immediately say multisig or bust, and then they say, oh, multisig's too overwhelming,

377
00:28:44.700 --> 00:28:49.600
so you should buy my my Bitcoin penny stock instead of doing self custody at all.

378
00:28:50.539 --> 00:28:56.240
And I think for some people, that's probably coming from a malicious place, but for others, that's just a place of ignorance.

379
00:28:56.700 --> 00:28:59.200
I think we should make single sig great again. I think

380
00:28:59.605 --> 00:29:02.505
it's incredibly underrated how much power you have,

381
00:29:02.965 --> 00:29:04.745
from even a single sig hot wallet,

382
00:29:05.524 --> 00:29:06.664
in terms of,

383
00:29:07.764 --> 00:29:10.825
like, digital sovereignty. But once you add the offline element,

384
00:29:11.284 --> 00:29:15.980
you're just really upgrading yourself. I see Sawzall zapped. 5,555

385
00:29:15.980 --> 00:29:19.039
stats. He said happy Bitcoin Friday, freaks. Thank you for your support, sir.

386
00:29:19.580 --> 00:29:20.080
Okay.

387
00:29:20.460 --> 00:29:22.480
I had a couple topics I wanted to hit

388
00:29:22.860 --> 00:29:25.919
with you. Mhmm. And a ride or die freak

389
00:29:26.220 --> 00:29:37.255
loaded them all into a single question on Primal. So I'm gonna read his question, and then you can answer at will. And I will navigate us back if there's things that I wanted to talk about that we missed. It's from Charlie.

390
00:29:37.875 --> 00:29:43.095
He said, ask him why he keeps pushing Monero instead of privacy on Bitcoin like Cashew.

391
00:29:43.840 --> 00:29:46.740
Okay. I wanna hear about Monero's latest reorg

392
00:29:47.279 --> 00:29:50.659
Mhmm. And overall why he thinks it's a valid shitcoin to use.

393
00:29:51.600 --> 00:29:52.580
That's a good question.

394
00:29:53.759 --> 00:29:55.379
Yeah. Let's let's first

395
00:29:55.695 --> 00:30:01.235
quickly recap the Monero security situation, and then we can we can repatch the eCash thing.

396
00:30:02.975 --> 00:30:04.434
Yes. So, generally,

397
00:30:05.054 --> 00:30:11.279
why Monero? I'll I'll I'll let's we'll do why Monero. We'll talk about the security issues that Monero's had recently, and then we'll we'll tackle eCash quickly.

398
00:30:11.760 --> 00:30:12.899
So why Monero?

399
00:30:14.159 --> 00:30:17.140
Exactly for the reason that we were talking about at the top of the show.

400
00:30:17.519 --> 00:30:19.700
Yes. You can do coin join on Bitcoin.

401
00:30:20.159 --> 00:30:25.905
It's not in a great state even if it's usable. And when you do use it, you stand out and will face

402
00:30:27.025 --> 00:30:29.525
can often face issues with tainted coins,

403
00:30:30.305 --> 00:30:31.905
or getting on fund lists.

404
00:30:32.625 --> 00:30:35.880
It's also quite difficult to use. Person is not gonna coin join,

405
00:30:36.440 --> 00:30:36.940
unfortunately.

406
00:30:37.640 --> 00:30:42.460
And there's no real way to improve the user experience that much beyond what it is right now

407
00:30:42.840 --> 00:30:44.780
without changes to Bitcoin's consensus.

408
00:30:46.120 --> 00:30:58.765
Thankfully, in Bitcoin, we do have some other tools that help. We have silent payments. I mean, kQuad's been leading the way on that. Thankfully, others are jumping in. Sparrow has built out an awesome proof of concept server for silent payments, which I did not expect.

409
00:31:00.025 --> 00:31:05.510
He's supposedly also building out silent payment support in Sparrow specifically. I just heard that this morning.

410
00:31:06.530 --> 00:31:11.590
So that is growing, and that helps on the receive side, but that does the forward looking privacy side.

411
00:31:11.970 --> 00:31:15.030
We have pay join, which is fantastic on the sending side

412
00:31:15.330 --> 00:31:17.350
and can provide some privacy benefits,

413
00:31:18.185 --> 00:31:22.605
but also suffers from if the funds you're spending in the pay join are

414
00:31:23.065 --> 00:31:42.220
linked to things that they shouldn't be, you can still have problems where you actually can make your privacy worse sometimes with pay join because you are revealing at least one additional UTXO that you wouldn't be otherwise to the person that you're paying. Now I think it's still a fantastic tool, but it would be best when it's fit with this holistic privacy approach. That's just really difficult on Bitcoin.

415
00:31:42.995 --> 00:31:49.395
Monero makes all of that stupid simple. You just hit send. You get better privacy than Bitcoin can achieve at its best

416
00:31:50.835 --> 00:31:52.455
without having to do anything extra.

417
00:31:54.035 --> 00:32:05.550
Obviously, you have downside. Like, we can talk price. Like, I've I've been honest on here. Like, Monero has not done well compared to Bitcoin over the years, and I would be much wealthier if I had never touched Monero

418
00:32:05.930 --> 00:32:09.210
in terms of sats or dollars or whatever you wanna account in.

419
00:32:09.850 --> 00:32:10.350
But

420
00:32:10.650 --> 00:32:23.565
I don't think that changes the tool as a tool for freedom. And that's when I'm recommending Monero, you will very, very clearly note I have never ever, ever, ever made any comments about you should do it for price speculation or that I think the value will increase,

421
00:32:24.025 --> 00:32:26.925
anything like that. I view it purely as a tool for freedom,

422
00:32:27.409 --> 00:32:27.909
realistically

423
00:32:28.210 --> 00:32:29.429
as a tool for spending,

424
00:32:30.049 --> 00:32:32.309
and it's exceptionally good at that.

425
00:32:34.289 --> 00:32:37.270
Yeah. Any thoughts before I jump into the Banero security stuff?

426
00:32:42.675 --> 00:32:45.735
Yeah. No. I mean, I would just I would I would push back

427
00:32:46.035 --> 00:32:47.015
on Charlie's,

428
00:32:47.875 --> 00:32:48.835
comments that,

429
00:32:50.115 --> 00:32:51.335
you're focused on Monero

430
00:32:52.115 --> 00:33:01.420
at the expense of Bitcoin privacy tools. I mean, Cake Wallet is especially on mobile is leading the way in terms of Bitcoin privacy tools. Way more time on Bitcoin privacy than we are on Monero.

431
00:33:03.080 --> 00:33:05.900
Okay. But I I do wanna hear your thought. So so

432
00:33:07.525 --> 00:33:10.745
I'll I'll throw my perspective out there before we hit the reorg stuff.

433
00:33:12.805 --> 00:33:13.305
The

434
00:33:14.485 --> 00:33:18.505
I've always thought Monero is an interesting project because I care about financial privacy.

435
00:33:19.925 --> 00:33:25.360
The two biggest issues with and and I think the freaks can think of Monero kind of,

436
00:33:26.940 --> 00:33:36.000
you just imagine if, like, silent payments and CoinJoin were the default for every transaction is how you can kind of think about the the privacy architecture more or less of Monero.

437
00:33:36.875 --> 00:33:43.695
And because it's the default, it's easier to use because you don't have to think about anything. You just send and receive, and you're getting privacy benefits.

438
00:33:44.235 --> 00:33:46.815
Now the made the main negatives of it

439
00:33:47.355 --> 00:33:49.934
is, first of all, because of the privacy benefits,

440
00:33:50.930 --> 00:33:52.230
there have always been,

441
00:33:53.809 --> 00:33:57.910
if not technical concerns, but at least mental concerns about,

442
00:33:59.010 --> 00:34:02.710
whether or not there's silent inflation and whether or not you can audit the supply.

443
00:34:03.125 --> 00:34:07.945
And then second of all, there actually is a tail emission, so there isn't a fixed supply in the first place.

444
00:34:08.405 --> 00:34:09.465
And so the result

445
00:34:10.085 --> 00:34:12.665
which the market has seemed to dictate

446
00:34:13.125 --> 00:34:17.225
is that long term, Monero's price tends to go down against Bitcoin.

447
00:34:17.790 --> 00:34:20.130
So it's strictly worse for savings than Bitcoin.

448
00:34:22.270 --> 00:34:25.890
So that's one issue. And then the second issue that I've talked about at length,

449
00:34:26.510 --> 00:34:28.850
which this reorg seems to kinda prove,

450
00:34:29.470 --> 00:34:29.970
is

451
00:34:31.105 --> 00:34:31.605
I've

452
00:34:31.985 --> 00:34:34.005
never I'm I'm I've never,

453
00:34:35.105 --> 00:34:37.685
I've always thought that it's inferior to do,

454
00:34:38.865 --> 00:34:40.805
try and do a CPU based

455
00:34:41.825 --> 00:34:44.965
POW algo rather than an ASIC algo.

456
00:34:45.590 --> 00:34:47.290
And and and Monero,

457
00:34:49.270 --> 00:34:56.810
pro Monero people would say the opposite. They say it's a feature, not a bug, that it's not using specialized hardware, that you don't have it in massive hardware farms.

458
00:34:58.255 --> 00:35:02.355
But my opinion has always been the opposite that because you have this specialized hardware,

459
00:35:03.535 --> 00:35:05.795
it becomes harder and harder to attack Bitcoin

460
00:35:06.255 --> 00:35:20.610
while that's not necessarily the case with Monero. So let's talk about the reorg thing because to me, that kind of proved out that thesis on my side. Yeah. Yeah. Yeah. It it honestly did. Yeah. I mean, for a quick summary for those who aren't super familiar with Monero. So Monero,

461
00:35:22.030 --> 00:35:26.450
has from its very beginning, the idea of ASIC resistance has been at its core,

462
00:35:26.805 --> 00:35:30.984
which I think is very, like, well meaning and very interesting.

463
00:35:31.285 --> 00:35:43.380
And in many ways, I think the the right approach, especially early on in Monero's life cycle I think something when we compare, like, Monero with Bitcoin that's hard to grasp is Monero got to have this unique slow transition

464
00:35:44.160 --> 00:35:48.900
from CPU mined to GPU mined to FPGA mined to ASIC mined,

465
00:35:49.520 --> 00:35:51.620
and that meant that it had this

466
00:35:52.000 --> 00:35:53.940
onetime only ability to

467
00:35:54.240 --> 00:35:56.500
transition between those things is relatively

468
00:35:57.935 --> 00:35:58.915
relatively safe.

469
00:35:59.295 --> 00:36:06.755
After ASICs existed for Bitcoin, that was no longer possible for any other chain. Like, if Monero had just said, we're gonna flip on ASIC support tomorrow,

470
00:36:07.215 --> 00:36:10.515
you're very likely going to have, at best, one ASIC manufacturer

471
00:36:10.975 --> 00:36:21.360
that then controls the network. Like, if we're completely honest, that it's very unlikely that you would have five different ASIC manufacturers for Monero overnight or even with a six month heads up or whatever.

472
00:36:21.980 --> 00:36:28.240
So you would struggle to have manufacturing to central you would struggle to have decentralized access to ASICs.

473
00:36:29.005 --> 00:36:32.225
And very likely, you would have worked more centralized and controlled

474
00:36:32.925 --> 00:36:36.865
than doing CPU mining or generally ASIC resistant to mining.

475
00:36:37.325 --> 00:36:39.345
So the idea, I think, is very sound,

476
00:36:39.965 --> 00:36:54.290
but that doesn't mean that it's perfect or even necessarily that it's the right approach. But this has been a debate that's been going on in Monero for a decade now of what the right approach is. We landed on random access, algo that basically turns your CPU into an so the the modern,

477
00:36:55.310 --> 00:36:56.655
CPU that you have in your

478
00:36:57.695 --> 00:36:58.195
etcetera

479
00:36:58.575 --> 00:37:13.800
is essentially the most efficient way to be able to mine Monero. And to make a better miner for Monero would basically mean you're improving CPUs for everybody, which would be also be just kind of a net good thing. So the idea is sound. The main part where it falls apart and the main thing that I love about ASIC

480
00:37:14.580 --> 00:37:19.000
usage for network security is that there's a a sunk cost into the ASICs themselves,

481
00:37:19.700 --> 00:37:23.720
and there's an inability for people to repurpose hardware for other things.

482
00:37:24.255 --> 00:37:27.555
And when it comes to CPU mined, a sec, resistant algorithms,

483
00:37:27.934 --> 00:37:30.674
what that means is AWS, Microsoft, Google,

484
00:37:31.055 --> 00:37:33.075
anyone who has data centers has

485
00:37:33.934 --> 00:37:44.039
a data center of Monero miners at their disposal at any moment. And they can turn them on. They can turn them off. They can use them during business hours to make a lot of money. And then when they're idle, they can use them to buy Monero.

486
00:37:44.420 --> 00:37:47.400
There are many, many different things that can happen there.

487
00:37:47.940 --> 00:37:49.559
And with this latest attack,

488
00:37:50.405 --> 00:37:52.984
like, long story short, there's, another altcoin

489
00:37:53.285 --> 00:37:55.224
that's price was tanking

490
00:37:56.005 --> 00:38:00.984
for marketing purposes. They launched an attack on Monero by essentially launching their own Monero mining pool,

491
00:38:01.765 --> 00:38:04.265
and then using all of their printed currency

492
00:38:04.670 --> 00:38:08.610
to subsidize those miners to pay them extra to mine Monero on their pool.

493
00:38:09.230 --> 00:38:15.250
And then they did this weird tokenomics thing where, like, they bought back their own currency and burned it, like, stupid stuff.

494
00:38:15.710 --> 00:38:16.210
But

495
00:38:17.085 --> 00:38:25.425
what is interesting and useful about it is that, essentially, they were able to attack Monero. Now there there was never a 51% attack. There was never control over the network.

496
00:38:26.205 --> 00:38:29.105
Rough estimates are probably if they had 30 to 35%

497
00:38:29.289 --> 00:38:39.390
hash rate of the network at any, at a a moment in time, not for long periods of time. And that manifested at its worst worst in a 18 block yard in Monero,

498
00:38:41.415 --> 00:38:43.515
three weeks ago maybe, something like that,

499
00:38:44.375 --> 00:38:44.875
which

500
00:38:45.255 --> 00:38:46.475
obviously is a problem,

501
00:38:47.175 --> 00:38:48.875
specifically for two reasons.

502
00:38:49.335 --> 00:38:53.355
One, just to caveat, Monero has two minute block times.

503
00:38:53.680 --> 00:38:56.260
So this would be equivalent to, like, a five block

504
00:38:56.640 --> 00:38:57.140
reorg,

505
00:38:58.800 --> 00:39:01.940
in Bitcoin. So it's it's different. It's not perfectly comparable, but,

506
00:39:02.400 --> 00:39:04.180
an 18 block deep reorg,

507
00:39:04.560 --> 00:39:05.060
has

508
00:39:05.360 --> 00:39:14.405
more causes causes more problems in Monero than it does in Bitcoin because in Monero, the reason we have this thing called a 10 block lock where which basically means you can't spend funds until you they have 10 confirmations

509
00:39:15.265 --> 00:39:18.565
is the way that Monero's privacy works references other,

510
00:39:20.069 --> 00:39:20.569
unspent

511
00:39:20.869 --> 00:39:24.170
transactions. We don't know if any transaction is spent in Minerals network.

512
00:39:24.630 --> 00:39:27.210
And if the transaction gets reorged,

513
00:39:27.829 --> 00:39:32.650
the fake spends also could get reorged, and it can essentially destroy the privacy for those transactions.

514
00:39:33.155 --> 00:39:36.695
So transactions get invalidated if they get reorged out past 10 blocks,

515
00:39:37.395 --> 00:39:52.720
which causes more issues. So there was this big reorg. The attack itself, like I said, that they never got 51%, but it was good proof that an attacker who can print money, which essentially is attacker, was able to at a scale that is much smaller than a nation state, is able to cause problems with Monero's network.

516
00:39:53.420 --> 00:39:59.119
And it proved out some concerns that we've had for years and has caused a lot of thought within the Monero community of how do we improve,

517
00:40:00.185 --> 00:40:06.845
the security of Monero long term. But it it gets really hard because like I said, you can't just go, like, oh, we'll just be ASIC mined

518
00:40:07.225 --> 00:40:08.205
tomorrow or

519
00:40:08.665 --> 00:40:18.580
in six months because you would really have to guarantee that there's gonna be broad access to those ASICs to ensure that you don't just end up centralizing under a different name rather than the one that you you already are struck.

520
00:40:20.560 --> 00:40:21.140
I mean,

521
00:40:24.320 --> 00:40:26.650
in practice, I I think it was a,

522
00:40:28.935 --> 00:40:29.435
relatively

523
00:40:29.735 --> 00:40:30.235
painless,

524
00:40:30.855 --> 00:40:42.900
wake up call for you guys. I don't think anyone actually lost any money. It was more of, like, a denial of service attack. I've seen some crazy proposals out of the Monero community about how to try and mitigate it going forward. I'm just gonna

525
00:40:43.520 --> 00:40:44.740
throw out a,

526
00:40:46.720 --> 00:40:47.460
a a a

527
00:40:47.920 --> 00:40:48.420
suggestion,

528
00:40:50.720 --> 00:40:51.220
unrequested

529
00:40:51.520 --> 00:40:52.020
suggestion

530
00:40:52.320 --> 00:40:57.540
Let's hear it. That I think could be interesting, but also, like, I have no skin in the game.

531
00:40:58.985 --> 00:41:01.005
Just why don't you just steal Litecoin's

532
00:41:01.545 --> 00:41:05.645
ASIC algo? Just steal script, and then you get the entire because,

533
00:41:06.105 --> 00:41:10.605
I mean, the the Monero community seems to be way more dedicated than the Litecoin community,

534
00:41:10.905 --> 00:41:14.410
and you already have a bootstrap to ASIC industry there. You could just

535
00:41:14.710 --> 00:41:15.610
fork Monero.

536
00:41:15.990 --> 00:41:19.370
Monero already forks relatively often. Just fork it to script,

537
00:41:19.750 --> 00:41:24.810
and you have a completely established ASIC industry ready to go to mine Monero.

538
00:41:25.670 --> 00:41:27.110
Yeah. There I mean, there are

539
00:41:29.335 --> 00:41:30.795
essentially, that would be merge mining,

540
00:41:33.015 --> 00:41:33.835
which there

541
00:41:34.615 --> 00:41:36.155
are downsides to that.

542
00:41:36.775 --> 00:41:41.175
I I think it's an interesting idea, and it's one of those things that I think is like the

543
00:41:42.099 --> 00:41:48.200
if all else fails and shit hits the fan, just merge mine with Bitcoin or Litecoin. Well, merge mining merge mining

544
00:41:48.740 --> 00:41:50.760
has issues if you're the second

545
00:41:51.300 --> 00:41:53.000
coin in line on the algo.

546
00:41:53.540 --> 00:42:01.635
We wouldn't, though. Well, I mean, I guess it depends on how you it would depend on how much revenue miners would get from mining it versus like argument

547
00:42:02.015 --> 00:42:04.275
I think there's a decent argument to be made

548
00:42:04.895 --> 00:42:07.955
that quickly Monero would overtake Litecoin in that situation,

549
00:42:09.295 --> 00:42:16.030
and become the dominant one. Because Litecoin's Alcos also merged mine with Dogecoin, I believe. Yeah. Yeah. It does.

550
00:42:16.490 --> 00:42:21.390
And at one point, Dogecoin almost overtook Litecoin. Like, the Litecoin people were, like, freaking out.

551
00:42:22.890 --> 00:42:29.194
But Monero actually would have an opportunity to. I don't know. I'm just throwing it out there. I would enjoy the chaos from the sidelines.

552
00:42:30.694 --> 00:42:34.154
And I think it I always I always theorize that that could

553
00:42:35.335 --> 00:42:46.030
be I my early theory theories were that people that chains were gonna try and attack other people's algos to try and take them over. But But what happened was the in almost the entire industry moved to proof of stake.

554
00:42:46.570 --> 00:42:52.830
And the only, like, all chains that are proof of work of, like, any reasonable size are Monero, Litecoin, and Dogecoin.

555
00:42:54.570 --> 00:43:05.005
So that's where we are now. Anyway That's an interesting point, honestly. Putting it out there. I mean, it's it's really the only way you could do a six, I think, safely, is you would have to do something that already reasonable

556
00:43:05.865 --> 00:43:07.405
a six saturation and distribution

557
00:43:07.705 --> 00:43:18.329
to be able to do that. Yeah. And then you'd immediately have miners who have all the hardware and would be willing to mine because they'd And manufacturers that are already making the hardware too. Yeah.

558
00:43:18.869 --> 00:43:20.250
It's true. Yeah.

559
00:43:21.589 --> 00:43:22.089
Anyway,

560
00:43:22.710 --> 00:43:27.765
that's enough Monero for today. I'm sure there's gonna be people that are triggered by it.

561
00:43:28.565 --> 00:43:29.605
I will just say,

562
00:43:31.684 --> 00:43:32.565
that I think,

563
00:43:32.885 --> 00:43:41.545
the Bitcoin Maximus community has lost the moral high ground once all the Bitcoin influencers or mostly Bitcoin influencers went on the payroll of Bitcoin penny stocks.

564
00:43:42.805 --> 00:43:43.305
So,

565
00:43:44.540 --> 00:43:48.140
It's been interesting to watch. I think it's it's much more interesting to,

566
00:43:49.100 --> 00:43:50.400
talk through a

567
00:43:51.260 --> 00:43:57.225
one of the last remaining proof of work change that's not Bitcoin and how they're dealing with these types of situations.

568
00:43:57.605 --> 00:44:00.905
Okay. So I wanna go back to you've been talking about bringing lightning,

569
00:44:03.445 --> 00:44:04.665
lightning to Cake Wallet.

570
00:44:05.685 --> 00:44:13.289
How are you thinking about that? Lightning historically has been difficult to do in a self custody way. There's a lot of new options out there. Yeah.

571
00:44:13.849 --> 00:44:21.950
Some of the projects I'm working on have been thinking about how best to execute on that front, just making self custody Lightning easier to use.

572
00:44:22.410 --> 00:44:24.195
So how how are you guys thinking about it?

573
00:44:25.555 --> 00:44:26.935
Yeah. I mean, it's been

574
00:44:27.395 --> 00:44:29.095
a, honestly, it's been a year long

575
00:44:30.035 --> 00:44:40.055
struggle to make that decision and find a good approach. Like, I think one of the first things I did when I first joined Cake was say, like, I just wasn't happy with beta the Lightning beta that we had at the time,

576
00:44:41.360 --> 00:44:44.100
which was using the green light approach. And I think that

577
00:44:44.400 --> 00:44:52.660
has proven itself out as just essentially a a nonstarter as a a way to solve this self custodial lightning thing. Pretty much everybody's pivoted away from that.

578
00:44:55.365 --> 00:45:02.025
And finding another solution has been incredibly difficult for many reasons. One is that doing lightning just properly

579
00:45:03.045 --> 00:45:04.985
is just never going to be

580
00:45:05.525 --> 00:45:09.785
the user experience that people are going to be willing to handle.

581
00:45:10.580 --> 00:45:11.220
And it's

582
00:45:11.700 --> 00:45:13.000
it has gotten better,

583
00:45:13.380 --> 00:45:20.680
but it's still something that will will never become something that the the vast majority of people will be willing to jump in and use. And again, like I've like I mentioned before, like,

584
00:45:20.980 --> 00:45:22.580
we're targeting the 95.

585
00:45:22.580 --> 00:45:33.244
Like, obviously, we don't wanna compromise on self custody. So that's what especially makes this challenging is there are easy ways to just compromise on self custody and and solve lightning because you're not doing lightning. You're not doing Bitcoin.

586
00:45:34.585 --> 00:45:36.204
But we didn't wanna sacrifice.

587
00:45:37.539 --> 00:45:43.720
So hitting those two points of, like, how do we make lightning something that's usable by the normal user

588
00:45:44.180 --> 00:45:46.119
and yet not give up on self custody

589
00:45:46.500 --> 00:45:50.440
essentially just meant that we couldn't use anything that's out there today,

590
00:45:51.145 --> 00:45:52.445
and we couldn't use

591
00:45:52.745 --> 00:45:53.565
the liquid

592
00:45:54.265 --> 00:45:58.685
thing that everyone switched to for a little while, but that seems like that's dying out now as well.

593
00:45:59.465 --> 00:46:01.645
And so the it really came down to

594
00:46:02.105 --> 00:46:03.165
Spark and Arc.

595
00:46:04.610 --> 00:46:05.110
And

596
00:46:05.410 --> 00:46:07.830
Arc is, like, such a fascinating solution.

597
00:46:09.090 --> 00:46:20.150
That certainly has been my my preference for a long time, and is a a very interesting, like, novel way to solve a lot of the problems with Lightning while actually allowing you to do a lot more with Bitcoin generally

598
00:46:20.744 --> 00:46:21.625
without giving up custody.

599
00:46:23.704 --> 00:46:31.964
Obviously, there are caveats, and we could be here all day if we actually got into all the like, how this stuff actually works and what's actually trustless and what's trust minimized and

600
00:46:32.345 --> 00:46:34.765
where there's custody risk and stuff like that. But,

601
00:46:36.130 --> 00:46:40.230
I I really like the idea of ARC, and I think the the concept of just

602
00:46:40.530 --> 00:46:42.150
simple ARC with bolts

603
00:46:42.609 --> 00:46:47.190
for swaps to lightning is just like it's it's going to be good.

604
00:46:47.994 --> 00:46:57.055
The problem that I've had with Arc and, like, no matter how I talk about this, someone's gonna be mad. So I'm just gonna preface this with, like, a a special Dude, a lot of people are gonna be mad about this episode.

605
00:46:58.234 --> 00:47:00.335
Yeah. We'll we'll trigger everybody in one.

606
00:47:00.970 --> 00:47:03.870
But the the main downside with ARC is just that the

607
00:47:04.650 --> 00:47:14.110
the way that rounds work, the way that you have to do VTXO refreshes in order to not essentially give up custody of funds after something like thirty days to the ARC service provider

608
00:47:15.395 --> 00:47:18.615
is not a big problem if you're talking about a desktop environment.

609
00:47:18.994 --> 00:47:19.494
It's

610
00:47:20.355 --> 00:47:21.734
really, really problematic

611
00:47:22.115 --> 00:47:23.575
when you're talking mobile,

612
00:47:23.875 --> 00:47:24.855
specifically iOS.

613
00:47:25.474 --> 00:47:32.540
If you're serving only Android users and you have a good engineering team or you're serving only desktop users, I think Arc's just absolutely a no brainer.

614
00:47:33.000 --> 00:47:39.340
Like, fantastic tool. Arc Labs guys and second guys are solving a lot of the initial hurdles with Arc as we go.

615
00:47:39.640 --> 00:47:44.300
But the main thing that you can't get away from, especially without covenants, is having to do interactive

616
00:47:45.815 --> 00:47:46.315
coordinated

617
00:47:46.775 --> 00:47:47.275
transactions

618
00:47:47.575 --> 00:47:48.075
regularly,

619
00:47:48.615 --> 00:48:08.640
which is something that is just really hard to do in an environment where most people are, which is on mobile, and is the main reason why, like, CoinJoin on mobile was never fun. Like, you could do it in samurai wallet, but you were never remixing or anything like that. It was not Yeah. It was not enjoyable. And that was the kind of the best case scenario, which is Android. There's a reason it never came to iOS because you would never ever be able to do that on iOS.

620
00:48:09.180 --> 00:48:19.734
You have a lot of the same problems with Arc. There are some ways to work around this, like the delegate intent system that the Arc Labs guys have come up with is interesting, but that only handles the refresh. That doesn't handle

621
00:48:20.355 --> 00:48:27.575
actually getting finality, like, claiming a VTXO for yourself and ensuring that no one can collude with dark service provider and steal those funds earlier.

622
00:48:29.500 --> 00:48:30.559
And it's just

623
00:48:31.180 --> 00:48:32.480
it's really hard on mobile.

624
00:48:33.019 --> 00:48:33.519
Now

625
00:48:34.460 --> 00:48:37.680
Spark is interesting because the people behind it are

626
00:48:39.259 --> 00:48:40.000
not great.

627
00:48:41.339 --> 00:48:43.039
Like, LightSpark, David Marcus,

628
00:48:43.420 --> 00:48:47.895
Libra, like, you name it. There's a lot of, like, there's a lot of baggage there.

629
00:48:48.195 --> 00:48:49.415
A 16 z.

630
00:48:49.955 --> 00:48:56.935
Yeah. It's like it's very much kind of like the antithesis of Arc in terms of where it's coming from.

631
00:48:58.360 --> 00:49:02.220
But I think something that is a very valuable exercise for everyone to do is

632
00:49:03.480 --> 00:49:10.275
put that aside and consider the tech. Now that you should not just dismiss that, like, obviously, it matters where these things come from, especially when you're talking about

633
00:49:10.755 --> 00:49:17.335
what is the long term outlook of this system look like when one general company is building the protocol. Even if it's an open protocol,

634
00:49:17.714 --> 00:49:26.930
they'll have a lot of sway in what happens. So it is important to to to know that. But if you put that aside, if you put the light spark weirdness aside and you actually look at the spark protocol,

635
00:49:27.230 --> 00:49:30.850
I think it's a very pragmatic, a very interesting approach to solving

636
00:49:31.230 --> 00:49:32.210
today's problems

637
00:49:33.230 --> 00:49:35.790
in a way that actually works as well.

638
00:49:37.150 --> 00:49:39.650
Mainly that it is quite a bit simpler

639
00:49:39.950 --> 00:49:50.465
than ARC even though you do lack true finality. The only way you get true finality in ARC is by doing these rounds, which are basically impossible on mobile or are not gonna be fun on mobile at the very least.

640
00:49:52.045 --> 00:49:53.025
It also has

641
00:49:53.589 --> 00:49:55.450
native support for tokens, which

642
00:49:55.750 --> 00:49:58.410
say what you will, I hate stable coins and tokens as well.

643
00:49:58.790 --> 00:50:02.089
Much of the world is needs and uses stable coins today,

644
00:50:02.470 --> 00:50:09.405
and support for that is something that will be useful. And I know that, like, ARC, I'm sure, is going to have stable coin support down the line through Taproot assets.

645
00:50:11.085 --> 00:50:16.305
But it also is just, it's a it's just a very interesting system that works quite well for today's problems,

646
00:50:16.845 --> 00:50:19.185
and has a good set of trade offs.

647
00:50:21.450 --> 00:50:33.070
Yeah. It's still a hard decision, and I've had I mean, I can't even count the number of hours and conversations I've had on both the spark and arc side with everyone I can possibly speak to, trying to make sure that that we make a good decision on this.

648
00:50:33.770 --> 00:50:40.065
But it's it's been interesting to figure out, like, what is the the pragmatic realistic solution, and what are the best sets of trade offs?

649
00:50:41.164 --> 00:50:49.664
I mean, really, my main, like, remaining problem with Spark is they do some privacy things really weirdly, like, badly right now. It's not weirdly. They intentionally

650
00:50:50.045 --> 00:50:52.224
they intentionally try and make it as

651
00:50:52.670 --> 00:50:54.210
the least private possible.

652
00:50:56.910 --> 00:51:02.450
I think we'll see. I I'm I'm curious if some of that holds. Most of the stuff that is problematic today

653
00:51:02.830 --> 00:51:09.645
outside of the block explorer, which does not need to exist and does exist for Spark, But, like, the like, you can't use new addresses

654
00:51:10.025 --> 00:51:16.125
is part of the technical complexity with Spark that supposedly is going to be solid very soon. Like, that that's not a

655
00:51:16.585 --> 00:51:26.490
a feature. It's a bug right now. Supposedly, again, this is where who light spark are light spark are actually matters. Like, you you need to have someone you can actually trust that they're gonna iterate on this.

656
00:51:27.910 --> 00:51:28.810
But it's also

657
00:51:29.270 --> 00:51:35.610
you get into the scenario where, like, what's the main use case? The main use case is lightning. Lightning can provide reasonable privacy,

658
00:51:37.005 --> 00:51:40.944
especially if you're not KYCing within the system. I know that there's a lot of, like,

659
00:51:41.645 --> 00:51:47.585
FUD that somehow LightSpark is gonna enforce KYC on Spark down the line. I haven't seen any evidence of that, but

660
00:51:48.045 --> 00:51:53.960
that would be obviously detrimental if they Well, I don't I don't think they could shotgun KYC

661
00:51:54.820 --> 00:51:57.960
because you can you can move out with without permission.

662
00:51:58.820 --> 00:52:03.400
They could So I mean, they could do it for hours that are too small for them. Forward.

663
00:52:04.500 --> 00:52:05.000
Yeah.

664
00:52:05.700 --> 00:52:05.835
Because

665
00:52:07.355 --> 00:52:24.280
a lot of people. Yeah. Go on. Sorry. Sorry. Yeah. I was just gonna say that is one thing that I think is, like, not discussed enough is technically, yes. Both have unilateral exit, but it's quite costly in both. From what I understand, more expensive in spark to unilaterally exit. In many scenarios, it it varies widely.

666
00:52:25.060 --> 00:52:36.795
But in both, it's going to be more expensive than just a regular on chain transaction to unilaterally exit. So if you're talking small amounts, like someone's gonna have a lightning wallet, oftentimes, it wouldn't be something where you can actually economically, feasibly,

667
00:52:37.414 --> 00:52:40.154
unilateral exit. And that's where the idea of, like,

668
00:52:40.934 --> 00:52:44.795
Spark saying, spend these funds until you prove who you are or something

669
00:52:45.350 --> 00:52:45.850
would

670
00:52:46.230 --> 00:52:50.970
actually be possible, which is terrifying. That now that goes away if any of the spark operators

671
00:52:51.350 --> 00:52:53.930
are not on board with that KYC thing.

672
00:52:54.390 --> 00:53:03.714
So that will be the main kind of decider on if it can be a system that's relatively censorship resistant or not is it's it's a one of in trust model. So if any of the spark operators are good,

673
00:53:04.174 --> 00:53:06.275
then it will as a whole be good. But

674
00:53:06.654 --> 00:53:09.954
right now, the spark operators are all light spark or light spark affiliated.

675
00:53:10.494 --> 00:53:14.674
So kinda wanna see if if others come on and join that aren't

676
00:53:15.360 --> 00:53:24.820
directly related by blood or by business relationship. I mean, in their defense, my understanding is they would they're actively trying to bring on more independent operators.

677
00:53:25.280 --> 00:53:39.045
They are. Yeah. They are. And supposedly, they'll have at least a couple more soon, but I've limited it intentionally at the beginning because it does add complexity in the, like, testing phase, and it's pretty early days for Spark. But yeah. The big the big privacy question mark is,

678
00:53:41.210 --> 00:53:41.710
like,

679
00:53:43.210 --> 00:53:43.710
they

680
00:53:44.329 --> 00:53:46.349
you could they could run the whole thing

681
00:53:46.650 --> 00:53:48.910
without publicly broadcasting every transaction,

682
00:53:49.530 --> 00:53:52.750
but they're actively choosing to do that, which is what you mentioned,

683
00:53:53.530 --> 00:53:54.990
with in terms of the Explorer.

684
00:53:55.290 --> 00:53:57.605
You would still trust the operators,

685
00:53:57.905 --> 00:54:00.325
and the operators could still partner with chain analysis.

686
00:54:00.785 --> 00:54:02.085
But to me, that's strictly

687
00:54:03.505 --> 00:54:04.325
better situation

688
00:54:04.865 --> 00:54:05.365
than,

689
00:54:06.545 --> 00:54:10.885
broadcasting it to the world every single transaction that's made. And it seems completely unnecessary

690
00:54:11.880 --> 00:54:12.359
unless

691
00:54:12.920 --> 00:54:18.940
I I mean, you're just over complying. It's like a pre compliance over compliance I mean type of situation.

692
00:54:19.640 --> 00:54:20.619
In some ways,

693
00:54:21.079 --> 00:54:27.955
if they just want it from a UX perspective of, like, people expect to be able to look up a wallet and see the tokens and stuff, like No.

694
00:54:28.575 --> 00:54:43.110
Okay. It's not a great I got it. Excuse because it is so bad from a privacy perspective. But it is very important for people to note that you it's it's like a VPN model kind of privacy. You're trusting the entity not to share your transactions. Like, in ARC, you're trusting

695
00:54:43.490 --> 00:54:50.710
one entity to not share those transactions. In Spark, you're trusting that none of the entities share your transactions. And that's because they do share your transactions.

696
00:54:51.170 --> 00:54:54.710
The average user is probably not going to be,

697
00:54:56.075 --> 00:55:04.494
at least for I mean, in unless I'm thinking about it wrong, I think the average user is gonna be using a Spark wallet to send and receive on lightning,

698
00:55:04.875 --> 00:55:09.375
and they're just gonna have a single balance. They're not gonna be, like, looking up Spark addresses or, like, individual

699
00:55:10.119 --> 00:55:13.580
whatever they call them. They're not UTXOs, but they act kinda like UTXOs.

700
00:55:14.680 --> 00:55:19.180
Yeah. It really depends, man. I'm I'm curious to see because I think, like,

701
00:55:19.880 --> 00:55:25.260
talking to both teams and a lot of other people, I think the view is that the Lightning payment side is just tiny

702
00:55:26.165 --> 00:55:29.705
compared to all of the other potential usage, specifically stablecoins.

703
00:55:30.244 --> 00:55:39.065
I think the way Spark is building is very clear around that. Like, their focus is And the stablecoins will be native Spark addresses for that. Mhmm. Yep.

704
00:55:39.445 --> 00:55:39.945
Yep.

705
00:55:40.650 --> 00:55:41.290
I mean

706
00:55:41.609 --> 00:55:49.869
so first off, I saw two questions about how does Stripe do lightning. Stripe just does lightning in a very in a completely custodial way.

707
00:55:50.410 --> 00:55:55.390
They have a great engineering team, so you have great liquidity and great payment reliability, and the UX is fantastic.

708
00:55:56.295 --> 00:55:57.435
But because it's custodial,

709
00:55:58.615 --> 00:56:00.875
you obviously have zero privacy from Stripe,

710
00:56:01.655 --> 00:56:15.020
and Stripe is a financial regulated entity that does KYC on you. Now Stripe also has an API that makes it easy for other wallets to implement it, which is what Primal did. And in Primal's case, they do less KYC than Strike does because,

711
00:56:17.319 --> 00:56:39.095
Primal limits the amount that you can transfer through it and has other yeah. That that's the basic premise is that they they limit the amount you can hold in the wallet at any given time. Obviously, this is not ideal. What we'd like to see is moving to a and and so, also, cashew has a similar trade off, which cashew is you have custodial mints that are interoperable with each other because it's an open protocol.

712
00:56:39.849 --> 00:56:46.030
But at the end of the day, you have to rely on the mint, not for your privacy, so it's a benefit on that front. But you do have to rely on it,

713
00:56:46.569 --> 00:56:52.905
in terms of the ability to spend your funds. If the mint's offline it doesn't even have to be malicious. If the mint's offline, you're not able to spend your funds.

714
00:56:53.465 --> 00:56:56.365
And then, obviously, the mint operator can rug you.

715
00:56:57.145 --> 00:56:59.165
I think Cashew has a lot of benefits

716
00:56:59.545 --> 00:57:03.005
because it's it's easy to implement. It's programmable. It's offline.

717
00:57:04.425 --> 00:57:05.565
It can be used offline,

718
00:57:05.960 --> 00:57:09.019
and it has very strong privacy and is very cheap to use.

719
00:57:09.880 --> 00:57:13.099
So I think Cashew has its place, especially for smaller amounts.

720
00:57:14.200 --> 00:57:15.980
But Argan Spark specifically

721
00:57:19.215 --> 00:57:22.355
are really, really interesting in term terms of trying

722
00:57:22.735 --> 00:57:24.915
to implement self custody lightning.

723
00:57:26.175 --> 00:57:30.195
They have interesting trade off models. You can lead both of them without permission.

724
00:57:31.775 --> 00:57:33.555
As Seth mentioned, you know,

725
00:57:33.980 --> 00:57:36.319
it needs to be over a certain amount, but

726
00:57:36.619 --> 00:57:37.119
the

727
00:57:37.420 --> 00:57:39.200
opposite side of that is it means,

728
00:57:39.819 --> 00:57:43.339
you know, worst comes to worst, you're gonna you lose a small amount. Right?

729
00:57:43.740 --> 00:57:48.960
So and that's because of on chain limitations. It's like, what is your fee to settle on chain on Bitcoin?

730
00:57:49.260 --> 00:57:51.235
And then I will say for my own analysis,

731
00:57:52.015 --> 00:58:07.200
basically, right on point with yours. Like, I think if I was gonna implement it in a wallet today, like, it'd just a 100% be Spark. I think it's way easier to implement. I wish that wasn't true. Like, I really wish that wasn't true. Yeah. Like, the cypherpunk in me is, like, just do ARC no matter what. But I

732
00:58:07.500 --> 00:58:19.055
I'm just not I'm not sure that it's actually doable today in a way that's user friendly on mobile. But that's not to say it won't be solved, and that's one of the main reasons why I still wanna see covenants. I'm not sure if those are ever gonna happen,

733
00:58:19.435 --> 00:58:23.855
but they would solve most of the problems with ARC and I think make it the clear clear winner.

734
00:58:25.035 --> 00:58:26.655
Yeah. I I would just say,

735
00:58:28.795 --> 00:58:31.135
to other people that might be in the chat,

736
00:58:32.530 --> 00:58:35.910
Greg has a personal problem with me and likes to make up lies.

737
00:58:36.290 --> 00:58:38.630
So you can just keep that in mind going forward.

738
00:58:39.490 --> 00:58:39.890
And,

739
00:58:40.530 --> 00:58:46.725
Greg, if you ever wanna have an honest conversation, I'm always happy to have an honest conversation with you as I've told you many times in the past.

740
00:58:47.685 --> 00:58:56.745
So Spark right now is implemented in the Wallet of Satoshi beta, and I've been playing around with that. And so Wallet of Satoshi historically was a completely custodial wallet,

741
00:58:59.285 --> 00:59:02.345
and they left The US following the samurai arrests,

742
00:59:03.810 --> 00:59:07.030
because as the custodian that wasn't doing KYC, they were quite concerned.

743
00:59:07.730 --> 00:59:10.390
And they're reentering The US using Spark.

744
00:59:10.690 --> 00:59:14.150
And what's really cool about it is you have a decent trust model,

745
00:59:16.835 --> 00:59:18.934
and you have a decent trust model,

746
00:59:19.555 --> 00:59:21.174
but The U the UX

747
00:59:21.555 --> 00:59:24.855
feels very much like the custodial UX that people love.

748
00:59:25.315 --> 00:59:29.974
You have, like, a single unified balance. You just pay and receive over lightning. It just fucking works.

749
00:59:32.590 --> 00:59:33.090
So,

750
00:59:33.870 --> 00:59:38.210
anyway, I was I was I'm me personally, like, I'm one of those people that

751
00:59:38.990 --> 00:59:41.170
there's so much hype and bullshit in the space,

752
00:59:41.710 --> 00:59:46.130
and there's only so much time that I tend to ignore stuff until I can play with it in person.

753
00:59:46.695 --> 00:59:55.195
And the the the realization that there was something there with Spark was when I used the wallet of the Satoshi beta. And I was like, wow. It's, like, actually fucking working,

754
00:59:55.815 --> 00:59:57.595
and it's very easy to use.

755
00:59:57.895 --> 01:00:02.430
And, you know, you probably shouldn't keep your life savings in it. I mean, at the very least, it's still a hot wallet.

756
01:00:02.990 --> 01:00:08.849
But if you're using it for spending and then ideally, you move to self custody offline cold storage,

757
01:00:10.190 --> 01:00:17.970
it seems like a pretty good trade off model to me. I'm pretty grateful it exists. And once again, it doesn't require self work, which I do not think

758
01:00:18.270 --> 01:00:25.195
we're gonna get any significant protocol changes to Bitcoin whether you want them or not. So the only things that are interesting to me,

759
01:00:26.535 --> 01:00:29.115
are things that do not require a soft fork.

760
01:00:30.690 --> 01:00:45.109
Yeah. One last minor thing about Spark two that would be interesting. Like, there's some like we talked about, there's some odd design choices with Spark, but, like, one thing that would be quite possible would be to do to add blind signing to Spark. Like, if you look at state chains generally,

761
01:00:46.545 --> 01:00:50.244
this has been done in the past. For some reason, I'm totally blanking on the

762
01:00:50.625 --> 01:00:52.405
the previous approach here. Mercury.

763
01:00:52.705 --> 01:00:54.385
Mercury. Yes. Mercury layer.

764
01:00:55.265 --> 01:00:55.925
They did

765
01:00:56.545 --> 01:01:09.070
they did state chains with blind signing. Now there were other downsides. Like, you couldn't break apart UTXOs, so you could only spend in, like, the denominations that you actually deposited in, which is very problematic. Spark solves that. But

766
01:01:09.690 --> 01:01:19.365
the weird thing that Spark has done is they aren't using blind signing. Now from a technical complexity perspective, that makes sense. But, again, it's like, okay. But, like, do it. They basically

767
01:01:19.984 --> 01:01:24.244
they took took Mercury. They stripped out the privacy, and they made it easier to implement

768
01:01:24.545 --> 01:01:25.525
is what they did.

769
01:01:25.825 --> 01:01:26.964
Which is understandable.

770
01:01:27.424 --> 01:01:30.885
But it also begs the question, it is an open protocol.

771
01:01:32.070 --> 01:01:38.890
Is there someone who would step in and say, hey. Let's take the spark protocol and let's do the privacy max version of this.

772
01:01:39.190 --> 01:01:47.290
And then let's compete in an open market to see who wants to use that spark entity versus the light spark spark entity. Like, that an open protocol and an open standard,

773
01:01:47.715 --> 01:01:50.215
anyone can jump in and start a spark entity tomorrow.

774
01:01:51.075 --> 01:01:52.215
Now there are liquidity

775
01:01:53.715 --> 01:01:58.055
the the spark service provider, like like, the lightning gateways side of things.

776
01:01:58.515 --> 01:01:59.815
But from the spark entity,

777
01:02:01.200 --> 01:02:05.140
perspective, it doesn't have the same liquidity constraints that Arc does either. So it's much

778
01:02:05.760 --> 01:02:09.859
simple, probably isn't the right term, but it's easier to spin up an entity there

779
01:02:10.240 --> 01:02:17.305
and have different spark operators. And you could do it in a way that focuses on user privacy with not publishing all the transactions, with

780
01:02:17.605 --> 01:02:20.424
doing blind signing, with bringing other privacy improvements.

781
01:02:21.365 --> 01:02:32.040
It'll be interesting to see. Now I I will say the again, I I don't know if you wanna take them at their word, but LightSpark have put out a road map, and there are clear focuses on privacy on that road map.

782
01:02:32.340 --> 01:02:34.680
Will it happen? Obviously, I I don't know.

783
01:02:35.300 --> 01:02:50.105
I'd like to think it will, but we we will see. But they have committed already to fixing the ability to not use, multiple addresses. Like I said, right now, you have to reuse addresses, but they have already committed to fixing that. That that is gonna happen. And they've said they want to do better privacy

784
01:02:50.565 --> 01:02:51.625
than blind signing.

785
01:02:51.925 --> 01:02:55.465
They still haven't said what that is, but it is something that's very possible,

786
01:02:55.765 --> 01:02:57.465
improved privacy there as well.

787
01:02:58.220 --> 01:03:16.865
So it'll it'll be interesting to see. And I I think, like you said, it's just it's one of those things that just it's built for today and it works. We don't need a soft fork. We don't have to make a ton of trade offs on the usability side, but there are other trade offs. And it's it's a difficult question, but it's it's been an interesting exploration for sure. And I'm glad that we finally have some interesting options on how to

788
01:03:17.244 --> 01:03:21.664
do self custodial lightning in a way that's actually gonna be something most people can use.

789
01:03:22.204 --> 01:03:23.585
Yeah. I mean, in their defense,

790
01:03:25.460 --> 01:03:27.720
and anyone who's actually ever shipped anything

791
01:03:28.740 --> 01:03:31.799
will completely understand this. It's very difficult to ship shit.

792
01:03:33.299 --> 01:03:34.599
And I personally

793
01:03:35.619 --> 01:03:41.295
they've done this relatively quickly, and they've gotten it to a point where it can be used in production, and it's impressive.

794
01:03:43.275 --> 01:03:46.095
And I'm a huge I'm a huge believer in

795
01:03:46.635 --> 01:03:49.375
ship in the open, iterate over time. So,

796
01:03:50.315 --> 01:03:56.015
let you know. Let's see what happens over the next year, the next two years. I mean, I think they could make it significantly better.

797
01:03:56.370 --> 01:03:58.790
I think it is I think both Arc and Spark

798
01:03:59.330 --> 01:04:00.610
are two of the most,

799
01:04:01.010 --> 01:04:04.230
promising projects in the space that I'm most excited about.

800
01:04:05.410 --> 01:04:10.630
And the development on both has happened quicker than I expected. Like, if you asked me a year ago,

801
01:04:11.525 --> 01:04:15.145
I would have given a pretty disenfranchised answer and said it was mostly hyped.

802
01:04:15.845 --> 01:04:19.065
And with Spark, we're seeing it actually being used live in wallets.

803
01:04:19.525 --> 01:04:24.745
ARC was used as the back end for merchant providers in at the Riga conference.

804
01:04:25.045 --> 01:04:28.150
So So both these things are actually being used in production right now,

805
01:04:29.010 --> 01:04:30.950
which is absolutely brilliant to see.

806
01:04:32.049 --> 01:04:33.910
Seth, this has been a great chat.

807
01:04:34.290 --> 01:04:37.430
I've enjoyed it. We've hit quite the gamut, I think.

808
01:04:38.130 --> 01:04:43.185
Always. We've successfully pissed off as many people as possible without touching core versus not,

809
01:04:43.645 --> 01:04:46.685
which is really impressive in today's in today's,

810
01:04:47.805 --> 01:04:48.305
conversation.

811
01:04:50.445 --> 01:04:53.980
Before we get to final thoughts, I just, I'm curious. Right now,

812
01:04:54.320 --> 01:04:55.700
Bitcoin privacy side,

813
01:04:56.800 --> 01:04:59.200
is there anything out there that you're excited about,

814
01:04:59.600 --> 01:05:00.100
specifically?

815
01:05:02.480 --> 01:05:04.580
I mean, honestly, there's just not that much

816
01:05:05.835 --> 01:05:12.415
that can happen, I feel like, at this point. The really, the biggest things are growing silent payment adoption, growing paid joint adoption.

817
01:05:13.115 --> 01:05:15.055
With paid joint v two and with,

818
01:05:15.675 --> 01:05:22.099
new server spec for silent payments now being out and people like Craig, brilliant people building around silent payments.

819
01:05:22.400 --> 01:05:27.460
I'm very hopeful of that adoption increasing, and both those things will solve a lot of the privacy problems with Bitcoin.

820
01:05:29.599 --> 01:05:33.915
But I think really the, like, the combination of those things with

821
01:05:34.395 --> 01:05:36.255
approachable self custodial lightning

822
01:05:36.715 --> 01:05:38.575
is probably about the best we're gonna get.

823
01:05:39.835 --> 01:05:49.295
And so I think that's that's really the focus, and that's all other reasons our focus has been so heavily on figuring out a good solution to lightning recently because that's missing piece of the privacy stack.

824
01:05:50.700 --> 01:05:51.920
That reminds me,

825
01:05:53.260 --> 01:05:54.160
silent payments

826
01:05:55.900 --> 01:05:57.280
on cake wallet, like,

827
01:05:57.580 --> 01:05:59.100
it's a pain in the fucking ass.

828
01:05:59.420 --> 01:06:01.180
Does does what Craig

829
01:06:01.580 --> 01:06:03.920
frankly, I appreciate you guys shipping it.

830
01:06:04.685 --> 01:06:11.185
Does what what Craig shipped recently, like, Frigate the, like, solid payment server thing, does that change the performance?

831
01:06:11.645 --> 01:06:14.925
Does that give you significant performance gains? Are you guys moving to that? Or

832
01:06:15.645 --> 01:06:29.900
So it's a it's a very different approach. It's the other approach that has always been possible, but no one had actually built yet. So his approach is sending the scan key to the server and letting it do the for you. So this is the ideal for the self hoster. This is the

833
01:06:30.945 --> 01:06:33.765
potentially, the ideal for a wallet company not like cake.

834
01:06:34.065 --> 01:06:39.125
That has the downside where now you're trusting a third party with the privacy of those transactions.

835
01:06:40.145 --> 01:06:49.010
But then you're still paying off than any other normal Bitcoin transaction. Because then the only person who knows the the payments received to a silent payment address are

836
01:06:49.310 --> 01:06:52.369
the node and you rather than the entire Bitcoin blockchain.

837
01:06:52.750 --> 01:06:55.650
So, basically, the Electrum server is doing the scanning

838
01:06:56.190 --> 01:06:57.250
versus locally.

839
01:06:57.965 --> 01:07:06.465
Yep. So it it would be it would be this essentially the same UX as a regular Bitcoin wallet, simply improved privacy from third parties and outside observers,

840
01:07:06.845 --> 01:07:11.310
but not from the node. So the ideal world is to just spin this up in a click on your

841
01:07:11.710 --> 01:07:14.690
Nodo or Umbrel or StartNine, whatever.

842
01:07:15.310 --> 01:07:19.730
And then you have the UX of a regular Bitcoin wallet with the privacy of setup payments.

843
01:07:20.030 --> 01:07:28.654
So I think this will this will be the norm for, like, the node runner, and it it would be probably the norm for wallets that prioritize UX over privacy. And I would say

844
01:07:29.515 --> 01:07:31.055
probably for us would be

845
01:07:31.674 --> 01:07:35.375
something we may do as an option. I'm still always wary of collecting any,

846
01:07:36.154 --> 01:07:36.654
like,

847
01:07:38.070 --> 01:07:43.290
anything that gives us any visibility into our user's activity that we don't have to have. So I'm I'm But aren't you still,

848
01:07:44.630 --> 01:07:45.130
like

849
01:07:45.670 --> 01:08:02.645
like, based on the Electrum spec, like, the user's still leaking balances to his Electrum's wary. Server. Yeah. Yeah. This is better than this is better than Electrum would be as well. Because it's still on your server. Anyway? Isn't like the the server that's running your Electrum server would also be running for it. So

850
01:08:03.345 --> 01:08:06.005
are they is the server actually getting that much more information?

851
01:08:06.549 --> 01:08:11.369
No. It's just it it will be just the silent payments piece is now a similar privacy model

852
01:08:11.990 --> 01:08:12.809
to the node

853
01:08:13.269 --> 01:08:28.184
of a regular Right. Sync. But you still the the key is that you still get all of the privacy benefits of silent payments outside observers. On chain. Yeah. Yeah. So it's it's that is I think that's the sweet spot, really, from a It's a strict benefit. Perspective. Yeah. Yeah. And you get great performance.

854
01:08:28.485 --> 01:08:37.760
Like, the performance has been the single biggest issue, particularly on mobile. It's just it's slow. Right? Yeah. And it's like again, on Android, it's quite easy to work around with background sync.

855
01:08:38.540 --> 01:08:47.985
But on iOS, there's just not really a solution other than just syncing in the foreground. So that's where it's a little painful. I mean, like, we have some ideas of how we can upload this. Like, if you

856
01:08:48.285 --> 01:09:17.045
run a a long term goal, maybe not too long term, hopefully, is if you run, like, cake on your desktop, you can offload sync to that. And that's something that we'll play play around with as well in the future. But I think this this will be like, this server model will be the sweet spot for the vast majority of people of if you already run a Bitcoin node, this will be trivial to run alongside it. And then you get the best of both worlds where you get the the UX of a regular Bitcoin wallet, but you get all the privacy assumptions of a silent payment address, which is really, really cool.

857
01:09:17.585 --> 01:09:21.605
Yeah. I mean, you're already like, if you actually want privacy when using Bitcoin,

858
01:09:22.225 --> 01:09:24.645
you should be using your own node. Mhmm.

859
01:09:25.505 --> 01:09:30.085
So for those people, like, they're running a start nine, they just run frigate alongside of it. And then

860
01:09:31.910 --> 01:09:33.450
they'll have a highly performant,

861
01:09:34.470 --> 01:09:35.610
pretty strong privacy

862
01:09:37.430 --> 01:09:43.210
situation going on. So that makes a lot of sense to me. By the way, Freaks, I forgot to check fountain as well.

863
01:09:44.145 --> 01:09:47.105
Gary, rider dog freak average Gary zapped 10,000

864
01:09:47.105 --> 01:09:49.605
last week on fountain. So thank you, Gary.

865
01:09:51.344 --> 01:09:52.565
Seth, this was awesome.

866
01:09:53.585 --> 01:09:55.364
Final thoughts before we wrap up?

867
01:09:58.770 --> 01:09:59.750
I think for me,

868
01:10:00.610 --> 01:10:01.110
just,

869
01:10:02.290 --> 01:10:06.310
it's been hard recently to not get to, like, black build

870
01:10:07.810 --> 01:10:11.235
and doom and bet the Bitcoin side. Like, just the way discourse has

871
01:10:12.275 --> 01:10:16.215
shifted and all of the Bitcoin penny stocks. And, like,

872
01:10:16.835 --> 01:10:18.375
it it feels very, like,

873
01:10:19.235 --> 01:10:23.574
dark in many ways. Like like, we're getting even further and further from the cypherpunk roots. But

874
01:10:23.980 --> 01:10:31.920
I think something that's just been helpful is I'm just spending less time on social media, not engaging in a lot of the useless discourse, and building. Like, that is

875
01:10:33.660 --> 01:10:38.880
that gives me hope as there are really, really, really brilliant people doing that

876
01:10:39.285 --> 01:10:39.785
across

877
01:10:40.245 --> 01:10:40.725
space.

878
01:10:41.125 --> 01:10:45.545
And they're building really interesting novel things, and they're solving real problems.

879
01:10:46.485 --> 01:10:56.050
And especially just being able to talk to a lot of these builders behind the scenes. Like, most of them just aren't they're not very public or talkative. They don't go on podcasts often, but they're building really cool stuff.

880
01:10:56.530 --> 01:11:00.310
And so I think just just kinda leaving people with stay off social media,

881
01:11:00.770 --> 01:11:01.750
try new stuff,

882
01:11:02.370 --> 01:11:07.005
keep an eye on the the builders who aren't the big names, who aren't the the podcasters.

883
01:11:07.705 --> 01:11:08.765
No offense, Matt.

884
01:11:09.385 --> 01:11:10.525
No offense to me.

885
01:11:10.905 --> 01:11:15.245
But You have a podcast too. Yeah. I do. I do. I unfortunately, I'm I'm one of the podcasters.

886
01:11:16.265 --> 01:11:21.165
But, yeah, just just keeping an eye on that, giving kudos where they deserve to the people who are actually building. And,

887
01:11:21.620 --> 01:11:28.280
yeah, I'm I'm optimistic on FreedomTech. I am pessimistic on Bitcoin Twitter, but that's probably where I always should have been. So Well,

888
01:11:28.660 --> 01:11:30.360
definitely aligned on that one.

889
01:11:30.820 --> 01:11:32.900
I mean, look, I take great pride that I think,

890
01:11:34.015 --> 01:11:37.955
bring on a lot of builders on dispatch that you do not hear on any other podcasts.

891
01:11:38.975 --> 01:11:43.475
I look. I was kinda in a similar hole for a little bit. I think,

892
01:11:43.935 --> 01:11:46.515
the best way the the productive way to look at it

893
01:11:48.580 --> 01:11:57.160
is we have more people self custodying using the tools, building out the tools than ever before from an absolute number. Are we smaller percentage wise?

894
01:11:57.540 --> 01:11:58.040
Yes.

895
01:11:58.580 --> 01:11:59.560
Like, is,

896
01:12:00.755 --> 01:12:05.175
you know, are is is the majority of, like, the Bitcoin influencer seen captured?

897
01:12:05.635 --> 01:12:06.135
Yes.

898
01:12:07.395 --> 01:12:09.255
Is was that always gonna happen?

899
01:12:09.715 --> 01:12:13.415
Yeah. Probably. I don't think there was any other path that that was gonna take.

900
01:12:14.190 --> 01:12:17.170
But there's a lot to be optimistic about, and I I I

901
01:12:17.550 --> 01:12:18.690
it's hard to

902
01:12:20.270 --> 01:12:23.490
short of the tornado cache and samurai rulings,

903
01:12:24.750 --> 01:12:25.810
which were devastating.

904
01:12:26.365 --> 01:12:31.025
Mhmm. And we're about to find out, you know, how much you know, what they're gonna get

905
01:12:31.965 --> 01:12:34.865
sentenced with in terms of, jail time.

906
01:12:36.125 --> 01:12:39.665
I think they face a maximum of five years on both sides.

907
01:12:42.140 --> 01:12:45.120
Short of that besides that, which is a big

908
01:12:45.500 --> 01:12:47.600
if, a big besides, but still,

909
01:12:48.460 --> 01:12:50.080
the timeline is quite strong.

910
01:12:50.460 --> 01:12:54.880
It is it is if you asked me five years ago, six years ago, like, where we stand today,

911
01:12:55.995 --> 01:13:00.255
it's hard to imagine us in a better place if what you care about is using Bitcoin,

912
01:13:01.435 --> 01:13:05.615
as freedom money and using it in a self sovereign way. Like, the tools have gotten very good,

913
01:13:06.235 --> 01:13:11.600
and they are getting better. And it's just and focus on the rider dies and touch grass and raise a strong family

914
01:13:12.380 --> 01:13:12.700
and,

915
01:13:13.420 --> 01:13:17.500
be content with that. I like it. That's a good perspective. It's a good pre

916
01:13:18.140 --> 01:13:19.600
hard to keep, but a conservative.

917
01:13:21.205 --> 01:13:23.225
We'll catch up again in three months.

918
01:13:23.844 --> 01:13:24.585
For sure.

919
01:13:25.125 --> 01:13:26.745
Onto the next quarterly update.

920
01:13:27.925 --> 01:13:31.304
Freaks. I'm gonna have on next week. I don't know,

921
01:13:33.844 --> 01:13:36.665
I don't know what day. I'll announce it on Nostr,

922
01:13:38.270 --> 01:13:43.410
But it's it's gonna be in person, so I'll have them on next week. And, I would love if you guys join us live.

923
01:13:43.870 --> 01:13:48.050
As always, all the links to dispatch or at dispatch.com.

924
01:13:48.190 --> 01:13:52.565
Whether you support the show through SATS or support the show by sharing with your friends and family,

925
01:13:54.145 --> 01:13:54.965
either help.

926
01:13:55.825 --> 01:13:58.965
You guys are are the heart and soul of the show. So,

927
01:14:00.785 --> 01:14:02.085
thanks for being along

928
01:14:02.545 --> 01:14:03.845
with me on this journey.

929
01:14:05.158 --> 01:14:06.458
Anyway, thanks, Seth.

930
01:14:06.839 --> 01:14:09.978
Thanks, Freaks. Thanks for having me on, man. Always fun. Always fun.

931
01:14:11.239 --> 01:14:12.939
Stay humble, StackSats. Peace.