CD199: CRAIG RAW - SILENT PAYMENTS AND SPARROW WALLET

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 04/13/2026 20:28:08
Duration: 4300.068
Channels: 1

1
00:00:32.530 --> 00:00:33.970
Happy Bitcoin

2
00:00:34.050 --> 00:00:39.170
Monday, freaks. It's your host, Odell, here for another Citadel Dispatch.

3
00:00:39.650 --> 00:00:42.930
The show focused on actual Bitcoin and freedom

4
00:00:43.345 --> 00:00:45.345
tech discussion.

5
00:00:48.545 --> 00:00:50.945
How's it going, guys? It's a Monday morning,

6
00:00:51.025 --> 00:00:52.385
and we are off

7
00:00:52.625 --> 00:00:57.265
to a great start. It is seventeen hundred UTC

8
00:00:57.265 --> 00:01:00.500
right now, April 13 Monday, April 3.

9
00:01:01.060 --> 00:01:01.700
The

10
00:01:02.500 --> 00:01:04.260
Trump announced that

11
00:01:05.860 --> 00:01:09.620
the US military will be blockading the Strait Of Hormuz

12
00:01:09.780 --> 00:01:18.495
to complement the the Iranian blockade on their side, And Bitcoin is somehow sitting at $72,276,

13
00:01:18.655 --> 00:01:21.695
which I feel like is a good sign, but we shall see.

14
00:01:22.175 --> 00:01:26.495
The current block height is nine four four nine one

15
00:01:26.575 --> 00:01:26.895
six.

16
00:01:27.730 --> 00:01:32.850
The current stats per dollar is one three eight four. And currently,

17
00:01:33.010 --> 00:01:33.890
one Bitcoin

18
00:01:34.610 --> 00:01:36.770
can buy you a little more

19
00:01:37.250 --> 00:01:38.050
than

20
00:01:38.290 --> 00:01:47.355
15 ounces of gold. We've been tracking that conversion price, and that has been on a bullish trend, I have to say. So we'll keep watching that. Anyway, freaks, as

21
00:01:48.235 --> 00:01:50.315
always, dispatch is supported

22
00:01:50.875 --> 00:01:51.515
by

23
00:01:51.675 --> 00:01:55.835
viewers like you. Thank you guys for sending your scare stats as donations

24
00:01:55.970 --> 00:01:58.290
support the show. We have no ads or sponsors,

25
00:01:58.690 --> 00:01:59.729
just you guys.

26
00:02:00.130 --> 00:02:03.650
Top zaps from last week, our Fediment update

27
00:02:03.970 --> 00:02:07.170
was open mic with 22,222

28
00:02:07.170 --> 00:02:13.025
sets. So Justin O'Dell, how about a live sale dispatch in Minneapolis for the next half year Federment check-in episode?

29
00:02:13.505 --> 00:02:16.865
I like that idea. I've been trying to make it to the Minneapolis meetup

30
00:02:16.944 --> 00:02:22.225
for a while now, and I need to make that a reality. I love how you guys hosted at

31
00:02:22.545 --> 00:02:23.825
the O'Shaughnessy

32
00:02:24.230 --> 00:02:25.110
Distillery,

33
00:02:25.110 --> 00:02:28.390
a Bitcoiner owned distillery in Minneapolis.

34
00:02:28.390 --> 00:02:31.750
So I will try and make it out there. I know it's one of the best meetups in the country.

35
00:02:31.990 --> 00:02:35.430
And then stimmy, 40 HPW, Zap, 21,000 SATs.

36
00:02:35.590 --> 00:02:38.630
As always, freaks, all relevant links are still at dispatch.com.

37
00:02:39.005 --> 00:02:44.285
If you don't have stats to spare, sharing with your friends and family really does help search

38
00:02:44.685 --> 00:02:51.325
still dispatch in your favorite podcast app. Open up their phone, search it in their podcast app, press the subscribe button,

39
00:02:51.565 --> 00:02:58.650
and who knows? Maybe they'll get some little bits of wisdom that they weren't expecting. But anyway, freaks, I have a great show lined up today.

40
00:02:59.690 --> 00:03:04.810
Ride or die, good friend, massive return guest, been on the show a million times,

41
00:03:05.129 --> 00:03:08.650
maintains the best Bitcoin wallet in the world. There is no second best.

42
00:03:09.335 --> 00:03:12.615
Craig Raw of Sparrow Wallet. How's it going, Craig?

43
00:03:13.575 --> 00:03:18.455
It is good to be back, Matt. It is going well. I'm excited to be here.

44
00:03:20.215 --> 00:03:33.190
Excited to have you. So, I mean, Sparrow is the best. I don't we but you keep shipping. You keep shipping and you keep improving it. And the latest improvement you've made is a big push into the silent payments

45
00:03:33.270 --> 00:03:41.225
support path, which is something that a lot a lot of us have been tracking for a while. I guess a good place to start is what are silent payments and why should people care?

46
00:03:42.025 --> 00:03:43.865
Yeah, great question.

47
00:03:45.305 --> 00:03:52.185
You know, silent payments are a way to have a static payment code. What is a static payment code? It's just

48
00:03:52.970 --> 00:03:58.810
a bank account number that you can pay, and you don't have to go and get a new one every time you make a payment. Right?

49
00:03:59.129 --> 00:04:02.490
So that's something that Bitcoin has never

50
00:04:02.890 --> 00:04:09.465
really had in any widespread fashion, as we know. We always have to go and get a new address,

51
00:04:09.864 --> 00:04:11.145
at least most people do,

52
00:04:11.465 --> 00:04:13.065
in order to pay somebody,

53
00:04:13.784 --> 00:04:15.865
in order to do that in a private way.

54
00:04:16.264 --> 00:04:17.544
You know, you'd always Right. Consider

55
00:04:19.305 --> 00:04:24.750
I'm sorry. I'm gonna try and not cut you off much, but we kind of have always had it now because I mean,

56
00:04:25.550 --> 00:04:32.350
a ton of Bitcoin payments are made to just reuse Bitcoin addresses. It's just, it's really bad for privacy if you do that.

57
00:04:32.910 --> 00:04:56.750
Yeah. No, that's right. So do it in a privacy preserving way. That's really the difference, right? That's what you have to do. So, you know, if you look back at what the white paper said about these things, it had a section about privacy in it, and it mentioned this issue of address reuse, but effectively left it unsold. And it's one of those kind of unsold issues that we've had to try and address ourselves.

58
00:04:57.790 --> 00:05:05.885
What we're trying to do here is have a way to not have this back and forth every time. Because if you have the back and forth, you basically have a situation

59
00:05:05.965 --> 00:05:09.165
where convenience is not aligned with privacy.

60
00:05:09.325 --> 00:05:15.645
And as you and I both know, Max, whenever you have convenience not aligned with privacy, privacy is the one that suffers.

61
00:05:15.965 --> 00:05:28.419
So, what you need to do is to have it so those two things are aligned. So, it is both convenient and private. And that's largely what we try and do. We try and make sure that those things are aligned so then people just use stuff automatically

62
00:05:28.580 --> 00:05:34.819
rather than trying to fit their lives around the tech. So, Silent Payments is really just the most recent

63
00:05:35.414 --> 00:05:38.615
version of trying to solve this particular issue.

64
00:05:38.854 --> 00:05:47.735
And I think it's quite a compelling one. But in order to really understand, I think, what it is, one has to kind of take a step back and look at the history of

65
00:05:48.360 --> 00:05:54.440
how we derive addresses in Bitcoin wallets, how we've done that in the past leading up to today.

66
00:05:57.320 --> 00:05:58.520
Okay, so

67
00:05:59.800 --> 00:06:00.600
let's do that.

68
00:06:01.534 --> 00:06:08.975
Okay, so the first way in which people and indeed Satoshi himself or herself did that was to

69
00:06:09.134 --> 00:06:10.574
basically derive

70
00:06:10.814 --> 00:06:12.495
a single key. So you basically

71
00:06:13.020 --> 00:06:18.300
take a secret and then you derive an address from it and then you can pay that particular

72
00:06:18.620 --> 00:06:22.300
address. But of course, that's just a single address system.

73
00:06:22.539 --> 00:06:29.025
So you can certainly pay to that address again, but as you mentioned, Matt, you then end up with privacy impact.

74
00:06:29.505 --> 00:06:38.305
So what people started doing is they'd have like a bag of these single key addresses, which they then have to have some management system on their side, some

75
00:06:38.800 --> 00:06:45.040
unique custom system to manage. And that was the early way in which it was done for quite a while, actually, many years.

76
00:06:46.160 --> 00:06:46.800
Now,

77
00:06:47.200 --> 00:06:48.720
in 2013,

78
00:06:48.720 --> 00:06:59.145
we had the first major upgrade to the system, which is still a commonly used system in place today. And that's called an HD wallet, and it was specified by a BIP called BIP32,

79
00:06:59.305 --> 00:07:01.065
and it effectively creates

80
00:07:01.945 --> 00:07:08.985
this kind of tree that you can think of it like a folders, and you can create as many folders as you like, and then you can have files in those folders.

81
00:07:09.479 --> 00:07:13.240
And effectively what we have are these long chains of addresses

82
00:07:13.319 --> 00:07:26.715
and that gives us or gives the wallet rather the ability to create a new address at will. And the idea was right, so now it's cheap to create addresses and we can keep track of them all and we can restore them all from one seed.

83
00:07:26.955 --> 00:07:44.390
And that's really a massive step forward. And it was, it was a huge step forward. And that's, you know, the reason that it is the system that we use today is why it survived for thirteen years and will no doubt be in common use for many years to come. So the HD Wallet is great, but it has a big downside

84
00:07:44.630 --> 00:07:46.470
in that it does not enforce

85
00:07:46.630 --> 00:07:47.669
unique

86
00:07:47.669 --> 00:07:49.235
fresh addresses,

87
00:07:49.235 --> 00:07:52.115
right? It sort of leaves it up to the user.

88
00:07:52.435 --> 00:07:54.355
So if you're a new user,

89
00:07:54.995 --> 00:07:58.435
you get an address, you withdraw, say from an exchange,

90
00:07:58.755 --> 00:08:04.690
and then it arrives in your account. You now have this idea that that address is a trusted address.

91
00:08:05.010 --> 00:08:15.490
It works, right? And you tend to reuse it. You tend to say, Well, that one is useful to me. I'm gonna just send to it again. You might've heard that you shouldn't reuse addresses,

92
00:08:16.130 --> 00:08:19.650
but typically that advice gets ignored by newer users.

93
00:08:20.425 --> 00:08:24.745
So, something that is not well tracked in the Bitcoin ecosystem is address reuse.

94
00:08:24.905 --> 00:08:29.225
But I did find some evidence on it and it looks like it's around 25 to 35%

95
00:08:29.225 --> 00:08:30.185
of addresses

96
00:08:30.265 --> 00:08:31.305
are being used.

97
00:08:31.800 --> 00:08:38.440
So it's way higher than you might think. I mean, I don't have up to date stats. I actually have someone working on that, but

98
00:08:39.160 --> 00:08:40.279
Well, Yeah, lines up

99
00:08:41.240 --> 00:08:41.960
sorry.

100
00:08:42.200 --> 00:08:46.600
No, it actually went as high as 50% during the 2021 bull run.

101
00:08:47.335 --> 00:08:51.015
So, you know, and that's not just affecting

102
00:08:51.095 --> 00:08:53.175
the people who reuse addresses,

103
00:08:53.175 --> 00:08:55.895
that because privacy on a public blockchain

104
00:08:56.215 --> 00:08:58.375
is kind of a common good,

105
00:08:58.535 --> 00:08:59.415
it affects everyone.

106
00:08:59.949 --> 00:09:06.829
And your privacy is worse because other people reuse addresses. Sorry, Matt, you're saying? Yeah. If like 50% of people are reusing addresses,

107
00:09:07.389 --> 00:09:08.269
then like

108
00:09:08.670 --> 00:09:12.110
the way Bitcoin is tracked is based is through probability analysis

109
00:09:12.865 --> 00:09:32.230
on change of ownership. And so that makes that probability analysis obviously much easier because you can narrow down when ownership changes even if you are not reusing your own addresses. What I was gonna say is it actually kinda makes sense to me, at least directionally, that it's that high for two reasons. First of all, the number one self custody wallet in the world is Trust Wallet.

110
00:09:32.630 --> 00:09:33.350
I I

111
00:09:33.750 --> 00:09:46.894
think they default to a static address. They did for a while. I don't know if they changed it. Also, in shitcoin land, that's just the common flow. Like, in Ethereum, you have you get your Ethereum account, which looks like a Bitcoin address, basically.

112
00:09:47.295 --> 00:10:00.630
And, like, that is always what you use. You use the same one over and over again. So anyone who's coming over from shitcoin land will be used to that UX flow and will do it. Obviously, it puts no risk at funds being lost. It is the easiest way to use Bitcoin.

113
00:10:01.110 --> 00:10:03.430
And unless you kinda go out of your way,

114
00:10:04.070 --> 00:10:07.270
then people tend to reuse addresses. And I'll use an example

115
00:10:07.590 --> 00:10:10.390
partially why I'm so excited about selling payments

116
00:10:11.155 --> 00:10:14.355
is with OpenSites, we're sending out a multisig transaction

117
00:10:14.515 --> 00:10:19.715
once a month to about 200 people. So that's 200 Bitcoin addresses.

118
00:10:20.275 --> 00:10:27.720
The lazy way for us to handle that is when they receive their grant, their one year grant paid out monthly, they give us a single address,

119
00:10:28.040 --> 00:10:32.680
and then we would just send it to that same address every month. Now that's horrible for privacy.

120
00:10:33.080 --> 00:10:52.334
So we go out of our way not to do that, and we have to get a new address from them every month. To be clear, we usually in the beginning of their grand say, like, send us 12 addresses at once, and we'll send it to a new one every time. But you can see how logistically that becomes a real pain in the ass. We have to audit the transaction, make sure all the addresses are correct, and make sure the right amounts are being sent.

121
00:10:53.390 --> 00:10:56.190
While strictly speaking, if we just had single

122
00:10:57.310 --> 00:11:00.990
address that we could send to every time, it would be much easier.

123
00:11:02.430 --> 00:11:04.190
Yeah. And as

124
00:11:04.430 --> 00:11:05.390
you were saying,

125
00:11:06.590 --> 00:11:07.470
just because

126
00:11:08.015 --> 00:11:19.215
if you're listening to this podcast, almost certainly you are not reusing addresses. I think it's, you know, and I think it's easy to assume that, you know, because everyone around you is not reusing,

127
00:11:19.455 --> 00:11:31.829
then there's not a lot of reuse, but actually it's really quite high. You know, just think about an exchange. Generally with an exchange, you have to kind of go through this process where you register an address that you're gonna withdraw to

128
00:11:32.389 --> 00:11:37.189
and you know, the whole system is almost set up in order to encourage you

129
00:11:37.555 --> 00:11:40.755
to reuse addresses rather than the other way around.

130
00:11:41.075 --> 00:11:41.635
So,

131
00:11:42.115 --> 00:11:44.355
you know, the HD wallet system

132
00:11:45.555 --> 00:11:56.730
was a big step forward, but it's really not getting us to where we need to be. We need to take another step forward. And the first attempt to move beyond that was in 2015

133
00:11:56.730 --> 00:12:02.170
with the arrival of BIP 47, and I'm gonna just skim over some kind of earlier

134
00:12:04.410 --> 00:12:11.705
attempts there because BIP 47 is really, I think, the first major attempt to kind of move beyond that. Now, BIP 47 is

135
00:12:11.865 --> 00:12:19.385
still a contender today. It's still around and it's still being, you know, you can still use it in Sparrow, you can use it in Ashigaru,

136
00:12:19.385 --> 00:12:20.265
many other wallets.

137
00:12:20.910 --> 00:12:24.029
Blue Wallet is one. What BIP47

138
00:12:24.829 --> 00:12:27.230
has is this notification

139
00:12:27.230 --> 00:12:28.190
transaction,

140
00:12:28.190 --> 00:12:31.950
which is quite well known for, and that has been criticized

141
00:12:31.950 --> 00:12:40.365
for various reasons. I don't actually think it's a major issue. Personally, I think that the cost of setting up a notification transaction, which is usually the

142
00:12:40.685 --> 00:12:42.125
most immediate reason,

143
00:12:42.445 --> 00:12:56.550
is actually pretty low. It's about a thousand sets, not a huge amount of money. There is a linkability concern, and I think that that's valid, where it's not the payment that you send that can be linked, but it is the notification transaction,

144
00:12:56.870 --> 00:13:16.274
the input sending to that notification transaction and any change that might be spent out of it, that then can be tracked. And then you can see some degree of a payment graph, not how much you're paying, but who you're paying as a result if you can track those particular inputs and outputs. Like you would know you would know that I

145
00:13:17.389 --> 00:13:27.310
me and you are paying each other, but you wouldn't know when we pay each other or how much we're paying each other. Right? That's right. So if you were able to track, if if you were able to see, oh,

146
00:13:27.870 --> 00:13:34.334
I used the change output from sending to a notification address and I saw, oh, that's Craig's change output.

147
00:13:34.415 --> 00:13:36.175
I managed to figure that out somehow.

148
00:13:36.415 --> 00:13:39.375
Then I can see, oh, Craig made a notification

149
00:13:39.695 --> 00:13:48.540
transaction to Matt. I know that he must have likely paid Matt in the past. That kind of thing is not ideal. It obviously does harm privacy

150
00:13:48.779 --> 00:13:49.420
in

151
00:13:50.459 --> 00:13:56.779
some way. But actually these issues are not in my view the major reason that Bit forty seven hasn't

152
00:13:57.485 --> 00:14:04.845
gathered kind of widespread adoption to date. I think the major reason for that is actually that it doesn't support hardware wallets.

153
00:14:05.084 --> 00:14:08.285
So something which is not I think well understood

154
00:14:08.524 --> 00:14:18.410
is that in order to derive new addresses in BIP 47 wallets, you need to have a private key of that wallet. So something as basic as just deriving a new address,

155
00:14:18.810 --> 00:14:29.435
which is something that a coordinator has to do, not a hardware wallet requires that private key. And it was invented in an era where hardware wallets was just not a big thing.

156
00:14:29.915 --> 00:14:33.995
As a result, I don't think it really took that particular need into account.

157
00:14:34.475 --> 00:14:45.010
But we're obviously living in a world where Bitcoin is predominantly used as savings tech, and most people are not prepared to put their savings onto software

158
00:14:45.090 --> 00:14:48.530
wallets. So as a result, you just have this natural

159
00:14:48.770 --> 00:15:00.105
resistance to adoption of this new address system. And I think that that for me is probably the major reason we haven't seen a lot of uptake of BIK 47 to date.

160
00:15:00.985 --> 00:15:01.865
Makes sense.

161
00:15:03.305 --> 00:15:14.940
So, you know, since then, we've obviously been trying to push that forward for a long, long, long time, hasn't really gone too far. And I think what's happened in the last few years is we've seen some new

162
00:15:16.779 --> 00:15:23.180
contenders come. And I think the major one of those is the one we're gonna talk about today, which is silent payments.

163
00:15:23.420 --> 00:15:24.779
So silent payments,

164
00:15:25.945 --> 00:15:30.585
and you know, the way you can think about all these address systems is

165
00:15:30.745 --> 00:15:33.465
how can you arrange the cryptographic

166
00:15:33.785 --> 00:15:34.585
operations

167
00:15:34.585 --> 00:15:39.225
in such a way that certain elements emerge as natural characteristics?

168
00:15:39.650 --> 00:15:40.930
That's,

169
00:15:40.930 --> 00:15:46.690
if I can frame it in that way, that's kind of what they're all doing. So they're all actually using

170
00:15:46.930 --> 00:15:47.890
fundamentally

171
00:15:47.890 --> 00:15:50.290
the same very basic mathematics

172
00:15:50.290 --> 00:15:54.930
underneath, but they just arrange it in different ways. They put the data in different places

173
00:15:55.254 --> 00:15:59.975
and they compute that data at different times in order to derive,

174
00:16:00.295 --> 00:16:02.935
you know, how, what the emergent characteristics

175
00:16:02.935 --> 00:16:03.495
are.

176
00:16:03.814 --> 00:16:07.175
So, silent payments is not doing anything mathematically

177
00:16:07.175 --> 00:16:13.150
which is new. It's just using very standard maths, very standard cryptographic stuff, which has been around,

178
00:16:13.550 --> 00:16:16.910
you know, for decades or more. But it's doing it in a different

179
00:16:17.310 --> 00:16:23.070
way. So what silent payments does is it takes all the list of pros and cons and optimizes

180
00:16:23.070 --> 00:16:28.035
every single one of them to be the best it can be, except for one, except for scanning

181
00:16:28.035 --> 00:16:30.035
to receive payments.

182
00:16:30.274 --> 00:16:40.435
And on that one, it just says, right, we're gonna make that one really tough, but on all the others, we're just gonna ace it. We're gonna be like a green tick on all the others. We're gonna have hardware wallet support.

183
00:16:40.595 --> 00:16:43.210
We're going to have enforced,

184
00:16:43.210 --> 00:16:47.610
you know, fresh addresses all the time, you can't have a reused address.

185
00:16:47.850 --> 00:16:53.930
We're going to basically do the best that we can in every way you can measure an address system except for this one thing.

186
00:16:54.555 --> 00:16:58.555
And that's, I think the right way to kind of see it, because

187
00:16:58.955 --> 00:17:02.235
when people have pushed back on silent payments in the past, it's usually

188
00:17:02.395 --> 00:17:06.475
on that scanning cost. And I think, so I think that that's,

189
00:17:07.435 --> 00:17:09.915
yeah, as I say, the way in which I would view

190
00:17:10.170 --> 00:17:11.290
these different

191
00:17:13.610 --> 00:17:16.250
ways of being able to derive addresses.

192
00:17:17.530 --> 00:17:20.410
I mean, to be clear on the hardware wallet

193
00:17:20.570 --> 00:17:24.250
support piece, the cool part about silent payments is basically

194
00:17:25.174 --> 00:17:43.130
the hard hardware wallets are agnostic to it. They don't even even realize that silent payments are being used. So they don't have to do any kind of changes for receiving on the hardware wallet side. On the sending side, that's not the case, though. Right? On the sending side, there needs to be some changes in order to be able to like pay a silent payment address?

195
00:17:43.930 --> 00:17:51.385
Yeah. So so there's there's actually a a number of different bips which have come out. So there's two two bips which

196
00:17:51.385 --> 00:17:52.345
specify

197
00:17:52.585 --> 00:17:56.745
how to send to a silent payments address,

198
00:17:56.985 --> 00:17:59.385
and they're basically just additional PSPT

199
00:17:59.385 --> 00:18:12.070
fields that the hardware wallet needs to be able to read. And then there is one additional BIP, which was actually only merged last week. So this is brand new, BIP three seventy six, and that specifies how to spend

200
00:18:12.230 --> 00:18:14.950
silent payments amounts that you have received.

201
00:18:15.430 --> 00:18:19.825
So with those two BIPs, we now have a complete hardware wallet specification

202
00:18:19.825 --> 00:18:34.304
in terms of PSPT fields and how to treat them for hardware wallet support. So, you know, this is all brand new, but these are well reviewed BIPs by, you know, lots of people and that gives us the ability to be able to support

203
00:18:35.330 --> 00:18:38.130
to support silent payments on a hardware wallet level.

204
00:18:40.210 --> 00:18:41.090
Got it. So,

205
00:18:41.570 --> 00:18:44.049
we will need the hardware wallets to

206
00:18:45.490 --> 00:18:48.290
do updates, right, in order to have full support?

207
00:18:49.045 --> 00:18:50.645
Absolutely, yeah, yeah.

208
00:18:51.125 --> 00:18:51.765
So,

209
00:18:52.325 --> 00:18:53.765
let me return now

210
00:18:53.925 --> 00:18:54.725
this

211
00:18:55.445 --> 00:18:57.445
kind of key issue. So,

212
00:18:57.845 --> 00:19:07.789
just wanna kinda iterate the main benefits of silent payments again. One, we get the static payment codes, which we need, right? You don't have to do the back and forth interaction for every new payment,

213
00:19:08.110 --> 00:19:12.349
right? So that's perhaps the most important obvious thing, but I think

214
00:19:13.070 --> 00:19:17.070
almost more important, I mean, it's kind of the same as the fact that you have enforced

215
00:19:17.164 --> 00:19:27.004
fresh addresses every time. You have no more address reuse. And I think that that's just a massive win for Bitcoin privacy on a broad level. If we can transition

216
00:19:27.325 --> 00:19:29.565
to this new address system,

217
00:19:29.804 --> 00:19:57.505
we all get more private Bitcoin as a result. So, you know, you might be thinking, why should I care? Well, this is why you should care, because if you adopt this and you encourage others to, well, you get more private Bitcoin as a result. And then finally, for the more technical people will be aware of this thing, which is kind of inherent to HD wallets, something called the gap limit, which is how far ahead in the wallet it searches for new transactions.

218
00:19:58.945 --> 00:20:05.179
So we talked about that chain of addresses that the HD wallet has to create.

219
00:20:05.260 --> 00:20:18.554
It doesn't know how long to make that chain. So it says, well, I'm gonna look a certain amount forward. If I don't see an address with funds in it, I'm gonna stop. And that thing is called the gap limit. It is an issue because with a BDC pay server instance today,

220
00:20:18.715 --> 00:20:20.554
you can request a new invoice,

221
00:20:20.635 --> 00:20:26.714
you can not pay the invoice, you can go on and do that twenty, thirty, 40 times and suddenly

222
00:20:27.434 --> 00:20:35.350
any new amount sent to an address further down the chain just aren't seen, because the wallet doesn't know to look

223
00:20:36.310 --> 00:20:39.910
that far. So you have these kind of issues which really are

224
00:20:40.470 --> 00:20:45.510
very much non ideal and create a lot of friction in the Bitcoin payments

225
00:20:45.215 --> 00:20:46.095
ecosystem.

226
00:20:46.495 --> 00:20:49.774
So those are the major things, but silent payments

227
00:20:49.855 --> 00:20:51.534
removes the gap limit,

228
00:20:52.095 --> 00:20:56.335
it's no longer a thing. And that just makes wallet development much, much easier.

229
00:20:56.815 --> 00:20:58.240
So, you know,

230
00:20:58.880 --> 00:21:03.280
going back to the reason that we don't have silent payments today, right? It's

231
00:21:03.280 --> 00:21:05.119
obviously better in every way,

232
00:21:05.440 --> 00:21:08.240
except for one, except for this scanning cost.

233
00:21:08.559 --> 00:21:19.284
So the way in which the silent payments BIP proposed to actually improve on this was to say, well, we can do live client support, we can use compact block filters,

234
00:21:19.525 --> 00:21:21.205
and we can basically

235
00:21:21.284 --> 00:21:24.085
reduce the amount of data that we need to scan

236
00:21:24.245 --> 00:21:24.565
by

237
00:21:25.410 --> 00:21:33.250
taking the entire transaction and saying, well, we can compress that down to a single key of information that we actually need. And that's called a tweak.

238
00:21:33.490 --> 00:21:35.730
So you basically go through the entire

239
00:21:36.290 --> 00:21:38.530
blockchain and you say every single

240
00:21:39.325 --> 00:21:40.525
transaction that

241
00:21:40.925 --> 00:21:49.565
could have spent to a silent payment address. In other words, the inputs were right and the output was going to a taproot output, it had at least one of those.

242
00:21:51.570 --> 00:22:01.730
Can then say, okay, well, let's reduce that transaction to a tweak. And then we go and we can scan that long list of tweaks and we can do our computations

243
00:22:01.730 --> 00:22:02.769
on the tweak.

244
00:22:03.010 --> 00:22:10.804
Now that asks the client to download all the tweaks, run the scanning, and then download the blocks using compact block filters.

245
00:22:11.285 --> 00:22:21.609
That is a lot of work. And let me tell you that is a great deal of work to ask any client to do, let alone a mobile phone. And if you've tried to use silent payments before,

246
00:22:22.009 --> 00:22:22.969
you've probably

247
00:22:23.210 --> 00:22:38.955
had an experience which was not ideal. And that's basically the reason why, because all of the early client implementations use this particular approach, which requires downloading a whole lot of information to begin with, then performing this really expensive compute on that information.

248
00:22:39.115 --> 00:22:45.515
And then on the basis of the outcome of that compute, downloading the blocks and extracting the transactions

249
00:22:45.515 --> 00:22:49.515
that are paid to you from those blocks. So you can Is this okay while it does it?

250
00:22:50.309 --> 00:23:01.429
I believe so. Yes. I'm not actually sure exactly what their method method is, but yeah. I believe this is what what But like when you try to do with Cakewallet, like the scanning just takes a while. Like it's just like it eventually

251
00:23:01.509 --> 00:23:05.425
shows up, but it's that's the trade off, right? It's like you're basically,

252
00:23:05.425 --> 00:23:08.465
you have to have the app open for a while while it's scanning everything.

253
00:23:09.105 --> 00:23:30.010
Yeah, so I kind of did a little test with Cake Wallet and this is not a scientific test, but I had to catch up around two years and I figured at the current rate of scanning, it was gonna take me around nine hours. That figure may be a bit out, but it is a more or less directional figure about how long it takes to scan. Now on

254
00:23:30.424 --> 00:23:33.784
wallets, you really have to consider the user experience,

255
00:23:34.424 --> 00:23:38.744
because if you don't, then you just don't get users. And on a mobile phone,

256
00:23:38.905 --> 00:23:40.504
you perhaps have,

257
00:23:41.225 --> 00:23:42.424
I would say, thirty seconds,

258
00:23:42.940 --> 00:23:55.340
twenty seconds. Maybe you have a little bit more if it's like a once off, but you know, if somebody checks their wallet once a month, once every few weeks, it needs to catch up within, I would say, twenty seconds

259
00:23:55.635 --> 00:23:57.235
with good progress

260
00:23:57.315 --> 00:23:59.635
in order to be usable. You can't do,

261
00:24:00.195 --> 00:24:11.220
you know, ten minutes because nobody sits looking at their phone, keeping, you know, particularly on iOS where you have to keep it sort of alive, the app alive. No one really does does

262
00:24:11.460 --> 00:24:25.300
that. Do creative things on Android where it's like in the background, it's doing the syncing so the user doesn't realize. But and also, it's not even just the user being willing to wait. If you if if it's a nontechnical user and they open up their wallet

263
00:24:25.894 --> 00:24:28.294
and for a half an hour it shows zero,

264
00:24:28.615 --> 00:24:31.494
when they really have received Bitcoin, they're gonna panic.

265
00:24:32.054 --> 00:24:32.934
Yep,

266
00:24:32.934 --> 00:24:38.934
absolutely. And just the fact that all of that compute is going to make your phone hot, drain your battery,

267
00:24:39.390 --> 00:24:42.350
You know, there's just a lot of work that is

268
00:24:42.830 --> 00:24:45.710
really required in order to do it in this way.

269
00:24:45.950 --> 00:24:47.470
So for me personally,

270
00:24:48.350 --> 00:24:49.710
I don't think that

271
00:24:50.190 --> 00:24:51.630
the BIP approach

272
00:24:52.424 --> 00:24:53.465
is inherently

273
00:24:53.465 --> 00:25:13.500
a bad approach. It's a very private approach because all the works being done on the client. I don't wanna knock the devs that are going down that path because it is a very private way. And there is a use case for that. If you're an activist, you can't run a server, you are probably prepared to sit and wait. You will make a plan. But for, you know, 95%

274
00:25:13.500 --> 00:25:20.300
of people in the world, it's just not gonna work for them. So, you know, they're prepared to give up a little bit of

275
00:25:20.725 --> 00:25:23.524
privacy for a system that works

276
00:25:24.085 --> 00:25:25.284
and gets them

277
00:25:25.605 --> 00:25:29.764
privacy in a different way. That's what I would say. So

278
00:25:30.325 --> 00:25:43.440
I decided to say, well, I don't think that this client side standing approach is the right approach. Let me try a different way of doing it. Let me see if I can move this onto a server and do it in the most performant way that I can imagine.

279
00:25:43.760 --> 00:25:51.424
And so the first thing I did was take all of that tweak information, all of those transactions reduced to a single key, put that in a

280
00:25:51.665 --> 00:25:52.304
database

281
00:25:53.025 --> 00:26:01.345
and then scan that using a custom database function. And I did that because I didn't wanna have to retrieve all of that data from the database,

282
00:26:01.505 --> 00:26:13.080
do the compute on it and then, you know, figure out what to do next. I kind of wanted to keep the compute as close to the data as I could. So that was the reason for doing it in a database function.

283
00:26:13.480 --> 00:26:23.374
Right, so I did that and I managed to bring the scanning time down from hours down to minutes, which was a huge step forward. But we were still talking about minutes

284
00:26:23.695 --> 00:26:37.809
and now we have a server involved, you've kind of added that on. So it wasn't really a solution at that point. It was just a step forward. It was just a step in the right direction, right? You had to kind of get down to a much better state. For example, if I had a public server,

285
00:26:37.970 --> 00:26:40.289
you know, I'd be able to serve one client.

286
00:26:40.450 --> 00:26:42.129
That's just not gonna work.

287
00:26:42.610 --> 00:26:51.544
So the next step was to say, well, how can we do this thing faster? How can we do the compute faster? And I sort of looked at the whole thing and it turns out that because

288
00:26:51.705 --> 00:26:58.105
every transaction is kind of in terms of scanning independent from the others, it either contains a payment to you or it doesn't.

289
00:26:58.450 --> 00:27:00.130
You have this situation

290
00:27:00.130 --> 00:27:01.330
where the

291
00:27:02.050 --> 00:27:05.410
sort of literature on this calls it embarrassingly

292
00:27:05.410 --> 00:27:06.290
parallel.

293
00:27:06.290 --> 00:27:10.450
I actually looked this term up today. It's a Wikipedia term because it keeps appearing

294
00:27:10.785 --> 00:27:16.385
in all kinds of other search searches that I'm doing, but it basically means that you can compute

295
00:27:16.545 --> 00:27:17.425
independently

296
00:27:17.425 --> 00:27:26.225
of the other computations that you're doing. And it turns out GPUs do this kind of thing really well, much better than sort of a pipeline where they have to rely

297
00:27:26.659 --> 00:27:30.419
on one of the other inputs in order to do the compute.

298
00:27:30.820 --> 00:27:36.179
So, what I did is I basically implemented the scanning function in a

299
00:27:36.580 --> 00:27:42.464
GPU and I managed to bring that scan time down from minutes down to seconds,

300
00:27:42.465 --> 00:27:43.904
right? So we're now talking

301
00:27:44.144 --> 00:27:45.984
thirty seconds, that kind

302
00:27:46.705 --> 00:27:47.904
of thing, right? So

303
00:27:48.225 --> 00:27:49.584
really a big step

304
00:27:50.144 --> 00:27:55.590
forward and I was starting to get quite excited about this, but you know, was still

305
00:27:56.870 --> 00:28:17.845
okay, but it wasn't great. The other thing that moving the compute onto a GPU did was it relieved the burden on the CPU. So if you have a server running, and then every time someone comes along and says, I wanna scan my silent payments address, and the server says, Okay, right, I'm not gonna do anything else but scan your silent payments address,

306
00:28:17.845 --> 00:28:24.110
you don't have a public server at that point. You just have a block which is doing only one thing.

307
00:28:24.590 --> 00:28:32.830
So, you have to offload load it in order to be able to not only achieve the speed, but also just to have the server able to do normal server

308
00:28:32.990 --> 00:28:33.310
things.

309
00:28:34.125 --> 00:28:34.845
So,

310
00:28:35.165 --> 00:28:39.725
right. So now we have a situation where we have a GPU

311
00:28:40.765 --> 00:28:43.164
silent payments scanning algorithm,

312
00:28:43.565 --> 00:28:50.129
but what we don't have is enough speedier to really run a public server. And I think the

313
00:28:50.690 --> 00:28:53.809
public server is really the critical point.

314
00:28:54.129 --> 00:28:54.769
You know,

315
00:28:56.450 --> 00:29:26.919
you think about it, I would guess most people who listen to this run their own node, but most people out there rely on the public servers in order to be able to retrieve information about their wallet. And we might say that that's not ideal, but it's just the truth of the world. And we can only take people down a path where we can make Bitcoin useful to them and then hope that they will run a node in future to increase their own privacy, but we can't force them to do it. And certainly,

316
00:29:27.320 --> 00:29:35.725
you know, asking them to run a node right off the bat is just gonna ensure that they never use Bitcoin at all. So for me personally,

317
00:29:35.805 --> 00:29:46.450
getting silent payments to a point where we could have a public server was a critical step. It was a requirement, otherwise this technology is just not interesting at all and I shouldn't build it in.

318
00:29:47.090 --> 00:29:47.729
So

319
00:29:47.890 --> 00:29:54.849
it was important to get the next step. What was the next next step? And it turned out that the next step was improving the performance

320
00:29:54.929 --> 00:29:59.275
of the GPU. And that was actually, there's

321
00:29:59.915 --> 00:30:01.275
a guy who came along

322
00:30:01.755 --> 00:30:05.275
into my, I think he posted on delving Bitcoin

323
00:30:05.755 --> 00:30:10.155
a month or two back and said, Hey, I've got this new project. It's called Ultrafast

324
00:30:10.155 --> 00:30:11.115
SCCP

325
00:30:11.240 --> 00:30:18.840
two fifty six ks one, which is the Curve Bitcoin Users. And his kind of focus is how can I make the fastest library

326
00:30:19.080 --> 00:30:23.080
that can do various kinds of cryptographic functions

327
00:30:23.160 --> 00:30:27.075
that Bitcoiners need? And he's just been relentless

328
00:30:27.075 --> 00:30:32.914
at this. And with his help, we've managed to take the scanning time of signed payments,

329
00:30:33.315 --> 00:30:35.315
not just sort of 10%

330
00:30:35.315 --> 00:30:35.875
or

331
00:30:36.160 --> 00:30:37.040
15%

332
00:30:37.040 --> 00:30:39.600
or 20% better, which is typically

333
00:30:39.920 --> 00:30:44.799
the kind of performance improvements that you can get when you do this of work.

334
00:30:44.960 --> 00:30:49.280
I mean, there are people out there who will spend a month getting 5%

335
00:30:49.095 --> 00:30:59.014
out of a particular algorithm and consider that a huge win. So, I think it's important to frame this in the right context because I was not expecting

336
00:30:59.414 --> 00:31:02.215
even close to the results that emerged.

337
00:31:02.750 --> 00:31:05.310
And the result that emerged is we managed to

338
00:31:05.630 --> 00:31:11.790
get this thing 14 times faster than it was. Wow. That is just massive.

339
00:31:13.310 --> 00:31:15.595
Was jaw on the floor, I could not believe

340
00:31:16.475 --> 00:31:29.399
that it was as fast as it was. But, you know, the nice thing about silent payments scanning is that it's either right or it's not. You either find all of the transactions or you don't. And as a result, we have a system

341
00:31:29.800 --> 00:31:31.720
which can now do

342
00:31:31.880 --> 00:31:35.240
years of scanning in seconds on a public server

343
00:31:35.320 --> 00:31:36.120
without

344
00:31:36.520 --> 00:31:39.159
having to run 20

345
00:31:39.160 --> 00:31:40.040
GPUs

346
00:31:40.040 --> 00:31:43.774
or doing something nuts, right? We can have individuals

347
00:31:44.015 --> 00:31:46.894
being able to afford discrete CPUs,

348
00:31:46.975 --> 00:31:49.455
gaming, public servers, but that can

349
00:31:49.535 --> 00:31:51.695
handle thousands of clients,

350
00:31:51.934 --> 00:32:00.080
right? That's a huge step forward. Now, again, going back, remember the only thing that Scion Payments has going against it is scanning speed.

351
00:32:00.240 --> 00:32:02.479
So if we can solve scanning speed,

352
00:32:02.720 --> 00:32:11.205
we have a better address system. And that's the fundamental thing that if you get nothing else from this chat, that's the key point, right?

353
00:32:12.645 --> 00:32:16.085
If we solve that, we have a better address system than HD Walls.

354
00:32:16.725 --> 00:32:17.445
Now,

355
00:32:17.845 --> 00:32:25.580
you know, Frigate is the implementation of this. It's not widely used yet. It's still an, I still call it an experimental

356
00:32:25.660 --> 00:32:34.540
service. So, you know, as many as slip to its cup and lip, and we're not there yet. But all of the building blocks, I think, are in place

357
00:32:34.700 --> 00:32:40.794
for this thing to replace the HD Wallet system that we all know and use today.

358
00:32:41.755 --> 00:32:50.715
So how does this look in practice? Is this, I running an Electrum server and then I'm also running a Frigate server or does Frigate have

359
00:32:51.770 --> 00:32:54.649
all the Electrum dependencies also built into it?

360
00:32:55.049 --> 00:32:56.970
So, yeah, great question, Matt.

361
00:32:57.210 --> 00:32:57.850
So

362
00:32:58.169 --> 00:33:19.110
I've kind of really just focused on the silent payments scanning part of it. And, you know, for me, I haven't wanted to build the entire kind of the Electrum server stack in. What I actually really want is for people to take the ideas or at least the code, certainly that database function, which is written in C plus or

363
00:33:19.670 --> 00:33:22.470
even just the idea and

364
00:33:22.950 --> 00:33:25.350
implemented themselves. I don't particularly

365
00:33:25.590 --> 00:33:29.190
need to maintain more pieces of software,

366
00:33:29.190 --> 00:33:30.790
but either

367
00:33:30.790 --> 00:33:31.350
way,

368
00:33:31.670 --> 00:33:35.965
we're going to have an Electrum server that

369
00:33:36.205 --> 00:33:39.805
supports it. Right now, you can run Frigate alongside

370
00:33:39.805 --> 00:33:51.160
something like Fulcrum and you can configure Frigate to talk to Fulcrum as a backend server and it'll just pass all of the requests that it doesn't handle itself through to Fulcrum.

371
00:33:51.240 --> 00:34:00.840
Fulcrum does the work or the Electrum X or whatever you use, and then it just sends it out. So you can have to clear here, Fulcrum is a

372
00:34:01.575 --> 00:34:03.975
Fulcrum is a highly performant Electrum server.

373
00:34:04.775 --> 00:34:07.494
Yes, it is. But you can use anyone, you can use it.

374
00:34:08.775 --> 00:34:09.734
ElectRS,

375
00:34:09.734 --> 00:34:12.855
you can use whatever you like. Frigate will just delegate

376
00:34:12.855 --> 00:34:25.380
all of those calls that it doesn't do. You know, I may very, very well in time improve Frigate to the point where it does handle those calls. But I think the major thing to kind of understand from this chat is

377
00:34:25.620 --> 00:34:30.340
the solving of the silent payments kind of piece. The scanning piece

378
00:34:30.605 --> 00:34:34.285
is for me, I think largely at a point now where

379
00:34:34.365 --> 00:34:36.045
we can start to really

380
00:34:36.525 --> 00:34:38.845
get this out into a broader audience.

381
00:34:39.964 --> 00:34:41.805
Yeah, mean, I think for

382
00:34:42.765 --> 00:34:43.645
professionals,

383
00:34:44.790 --> 00:34:51.030
right, and who I would put under professionals is like, I don't know, like Blockstream is running a public Electrum server.

384
00:34:52.070 --> 00:34:58.070
MZ is running a public Electrum server. These people that have been running public Electrum infrastructure

385
00:34:58.070 --> 00:34:58.470
for,

386
00:35:00.045 --> 00:35:01.325
you know, a decade

387
00:35:01.405 --> 00:35:04.365
now, maybe maybe a little bit less, but for years,

388
00:35:04.925 --> 00:35:10.605
they can easily just, know, run frigate or something similar to frigate on the side of it and and do that.

389
00:35:11.165 --> 00:35:12.285
But when we're talking about,

390
00:35:13.130 --> 00:35:18.970
you know, home, it would like an average user using their own node and using them with silent payments.

391
00:35:19.930 --> 00:35:28.945
Probably the ideal setup in the future is something like, you know, one click, you're on start nine, and you install one package.

392
00:35:29.185 --> 00:35:34.465
And it probably, I mean, right now the current state is you install Bitcoin Core,

393
00:35:34.865 --> 00:35:38.465
and then you install your choice of Electrum server separately. I

394
00:35:39.025 --> 00:35:44.070
guess in this situation would be, and then you would install Frigate. So you have you're installing three different packages.

395
00:35:44.230 --> 00:35:45.030
Ideally,

396
00:35:45.030 --> 00:35:48.070
I think it'd be great if there was just one,

397
00:35:48.630 --> 00:35:52.070
you know, but at the very least two, you know, you do Bitcoin Core,

398
00:35:52.150 --> 00:36:00.734
Bitcoin Nods, whatever the hell you wanna run. And then your Electrum server of choice that has, like, the frigate functionality built in. But, I mean, it's probably just

399
00:36:01.535 --> 00:36:08.494
in practice, doesn't matter that much. I mean, you're just pressing install for one more thing. For the average user that's not using their node,

400
00:36:09.339 --> 00:36:12.060
they're installing Sparrow Wallet. They're going to sparrowwallet.com.

401
00:36:12.060 --> 00:36:13.580
They're installing Sparrow Wallet.

402
00:36:13.900 --> 00:36:22.859
They're booting up Sparrow for the first time. And it's like, okay. Are you gonna use your own node? Are you gonna use a remote node? And the way you handle it is you give them a bunch of,

403
00:36:23.454 --> 00:36:37.295
like, tool tips, explanations on the privacy risks and the sovereignty risks of using a remote node that's not controlled by you. But if you choose to go down that path, because like we said, most users will not use their own node, you give them a predetermined

404
00:36:37.869 --> 00:36:43.230
set of high integrity nodes, nodes that have a lot of proof of work and

405
00:36:43.470 --> 00:37:06.315
good reputation in the space. It's like a short list of four or five nodes for them to choose from. And the reason that is freaks for those that might not be aware is because there are a lot of malicious actors there that are running Electrum servers to track transactions. So if you're just very naive about which ones you choose and you just go with truly random, you might get stuck with a malicious one, which is why Craig, like, has a,

406
00:37:07.050 --> 00:37:10.730
you know, well curated list of of defaults.

407
00:37:11.130 --> 00:37:20.490
I assume in a post silent payments world, those defaults will be ones that also have frigate support or something similar, have silent payment support.

408
00:37:20.650 --> 00:37:21.770
For that end user,

409
00:37:22.475 --> 00:37:30.235
should they be thinking about the trade off pretty similar to how they think about connecting to Blockstream's Electrum server? Like, is it it's basically

410
00:37:30.875 --> 00:37:37.515
it's a privacy risk coupled with a risk that they might not they might not tell you if you received something that you actually received. Right?

411
00:37:38.280 --> 00:37:44.920
Correct, yeah. Those are the two risks, right? So you are basically running more or less the same risks.

412
00:37:45.800 --> 00:37:48.440
I would say, you know, it's not exactly

413
00:37:48.600 --> 00:38:01.175
the same because when they scan, they obviously can say, well, you know, we didn't find any amounts to you and when there actually were amounts. So there is that risk. I think it's a pretty low But could the Electrum server say the same thing?

414
00:38:01.734 --> 00:38:06.110
Yeah, yeah. Well, I mean, that's it could, but you know, in practice, yeah,

415
00:38:07.870 --> 00:38:11.470
I have to think about that one a little bit more. There probably are some

416
00:38:12.030 --> 00:38:15.310
safeguards in there. In practice, these safeguards

417
00:38:15.310 --> 00:38:16.190
turn out to be,

418
00:38:18.405 --> 00:38:20.725
you know, I wouldn't say unnecessary,

419
00:38:21.045 --> 00:38:23.525
but because we have many different

420
00:38:23.845 --> 00:38:31.980
Electrum servers, so you're gonna switch between one or the other without even really knowing it if you're connecting to a public

421
00:38:32.460 --> 00:38:33.100
server,

422
00:38:33.420 --> 00:38:35.740
you're gonna soon see if one of them

423
00:38:36.060 --> 00:38:46.595
has any kind of issues. It's lying to you, yeah. Yeah, so you know, in practice these kind of things don't really happen because of the way it's set up. Not that we should ever assume

424
00:38:46.835 --> 00:39:04.340
that that they can't happen and we shouldn't protect against against against against them. I think that should always be considered, but they're not kind of major risks if I would say at this time. Yeah. I mean, the way you see it in practice is if you're using a wallet where it's like, pick one server, and that's it, and it doesn't rotate servers,

425
00:39:04.660 --> 00:39:09.700
and that server is down, let's say block streams, Internet is out, and wherever they host their server,

426
00:39:10.099 --> 00:39:15.635
then you open up your wallet, and it might show a zero balance. And then some people might panic. But

427
00:39:16.035 --> 00:39:28.915
if and I've had people reach out to me, then you go, no, just switch Electrum servers, they switch Electrum servers, and then it shows the actual balance. And it's not them trying to be malicious. It's just they're down. But I think that kind of make I mean, I've been thinking about it a lot. I like,

428
00:39:29.529 --> 00:39:35.369
it's basically it's interesting. Right? Because solemn payments has been pitched as a privacy improvement,

429
00:39:35.930 --> 00:39:40.089
which it net net is. So people get stuck in the perfect

430
00:39:40.170 --> 00:39:48.995
is the enemy of good. And so if you're using a remote server with to scan for your silent payments, you're obviously trusting that remote server with your privacy.

431
00:39:49.475 --> 00:39:56.195
But as you've, I think, eloquently pointed out, silent payments actually provides improvements all across the board. So

432
00:39:56.515 --> 00:39:59.075
if someone is already using a public Electrum server,

433
00:39:59.660 --> 00:40:06.620
and now they're using a public Electrum server that is frigate compatible, or, you know, silent payments compatible,

434
00:40:06.940 --> 00:40:10.140
they're they're basic, they're in a privacy improved situation.

435
00:40:10.460 --> 00:40:11.900
Right? Because publicly,

436
00:40:12.965 --> 00:40:24.245
the their their their on chain situation, what the rest of the world sees, if that server isn't logging, is significantly better than the status quo of often reusing addresses, for instance.

437
00:40:24.805 --> 00:40:27.925
That's correct. Yeah. I think that that puts it well. Yeah. There's

438
00:40:28.590 --> 00:40:33.870
there's just a sort a net win here. If you can get around the scanning cost,

439
00:40:34.830 --> 00:40:35.230
know,

440
00:40:36.030 --> 00:40:44.615
barring a few very minor caveats, you know, which, you know, it's sort of, it's more like sharing an XPUB with that server than it is sharing

441
00:40:44.775 --> 00:40:47.735
a whole bunch of addresses. Know, there's minor interesting. Caveats to

442
00:40:48.455 --> 00:40:57.510
Because you share something called your scan key, which you can think of it as like an ID for how Oh, so it is a little bit worse than a regular Electrum server because the

443
00:40:57.750 --> 00:41:07.910
way you set up with a regular Electrum server, I'm really sending them like, and that's why it solves the gap limit though. It's it's Correct. When I'm dealing with a regular Electrum server, I'm sending them like 20 addresses.

444
00:41:08.475 --> 00:41:13.035
I'm not sending them all 2,000 addresses I've used in a lifetime of my wallet or whatever.

445
00:41:13.515 --> 00:41:21.675
Yeah. Yeah. And I I think many people are gonna now say, well, you know, look at what happened to some some are some some some some

446
00:41:22.630 --> 00:41:24.710
summarized server when it was seized.

447
00:41:25.270 --> 00:41:31.270
Right. I think the very important thing here is that electron wallets have to not store any

448
00:41:31.510 --> 00:41:35.270
info, right? They have to perform the computation

449
00:41:35.270 --> 00:41:36.070
in RAM

450
00:41:36.325 --> 00:41:38.085
so that if anyone arrives,

451
00:41:38.245 --> 00:41:43.125
the only data they have on the client is whatever they were working on at that moment in time.

452
00:41:43.605 --> 00:41:49.685
And you know, that's it, right? So you would have to scan the RAM in order to get that scan key out.

453
00:41:50.410 --> 00:41:54.250
Right. It's a similar situation that we see with VPN providers,

454
00:41:54.410 --> 00:42:08.065
right? Where a VPN provider can tell you they're not keeping logs, but there's no way for you to prove if they're not keeping logs. And so some of the more reputable ones have tried to mitigate that risk more. And I know, I think Movad specifically

455
00:42:08.065 --> 00:42:11.905
has made a big point of keeping everything in RAM,

456
00:42:12.464 --> 00:42:13.425
so that

457
00:42:13.904 --> 00:42:16.705
if the server powers off, it auto wipes.

458
00:42:16.944 --> 00:42:28.670
Correct. Yeah. And I think that that's a, you know, going back to your earlier point of don't let the best be the enemy of the good, like you can achieve so much with actually really good privacy,

459
00:42:28.670 --> 00:42:30.030
you know, in practice,

460
00:42:30.510 --> 00:42:33.950
just by saying, right, if we can keep everything in RAM,

461
00:42:34.430 --> 00:42:37.045
if we can use servers

462
00:42:37.045 --> 00:42:40.085
run by people who have a long track record

463
00:42:40.325 --> 00:42:43.925
of doing good things in the space, then likely

464
00:42:44.005 --> 00:42:49.845
we are going to have a situation where most people are fine. Like that is the likely outcome.

465
00:42:50.165 --> 00:42:58.110
Now, you know, I always have to caveat it with the thing of this is Bitcoin, we running a, we're all trying to be part of a decentralized

466
00:42:58.670 --> 00:42:59.710
system here.

467
00:42:59.869 --> 00:43:03.869
If that really concerns you, run your own node. Like that's what we're all here So, to do

468
00:43:04.855 --> 00:43:13.255
you know, that's my strong pushback to anyone who says I don't like like that. Well, absolutely. Run your own node. You know? And the server model and it's it's

469
00:43:14.135 --> 00:43:17.015
I mean, I'm famous for coming up with stacking

470
00:43:17.015 --> 00:43:17.575
SATs,

471
00:43:17.850 --> 00:43:21.290
but the lesser known is that I came up with uncle Jim,

472
00:43:21.610 --> 00:43:27.850
and it's been perverted a little bit. Now uncle Jim kind of also means, like, taking custody of user funds. But historically,

473
00:43:27.850 --> 00:43:29.850
it was meant running infrastructure

474
00:43:30.250 --> 00:43:32.010
that was noncustodial

475
00:43:32.010 --> 00:43:33.210
for friends and family.

476
00:43:33.845 --> 00:43:35.845
And this is where the server

477
00:43:36.164 --> 00:43:36.885
setup

478
00:43:37.285 --> 00:43:39.445
is actually really helpful, I think,

479
00:43:40.724 --> 00:43:42.405
is that it's not just someone,

480
00:43:42.484 --> 00:43:49.780
you know, running their own node. You can also see a situation where like, maybe you're running it for your community or your meetup or something like that.

481
00:43:50.260 --> 00:43:52.020
And that brings that trust

482
00:43:53.380 --> 00:43:54.420
more local,

483
00:43:54.500 --> 00:44:00.100
right? If you're running it for your if you're running an Electrum server and a frigate server for your 75

484
00:44:00.500 --> 00:44:01.220
meetup

485
00:44:01.974 --> 00:44:02.855
members.

486
00:44:05.255 --> 00:44:09.815
They know who you are. They can ask you questions about what your setup is, how you're doing it.

487
00:44:10.135 --> 00:44:12.375
And then you're not part of a

488
00:44:12.855 --> 00:44:15.895
larger honeypot that maybe is serving 10,000,

489
00:44:15.895 --> 00:44:18.160
20,000 Bitcoin users something like that.

490
00:44:18.560 --> 00:44:24.480
Yeah, so, you know, just on that point, right, if you look at the current server, which is offered by

491
00:44:24.800 --> 00:44:35.755
Start9, it's called the Server one and it actually has a pretty decent integrated GPU on it. I unfortunately don't have one. I'm really keen to try and get some benchmarking

492
00:44:35.755 --> 00:44:41.835
on one, but I think that it would do pretty well in an uncle Jim mode. I think that it would kind

493
00:44:41.995 --> 00:44:45.275
of be not enough for a full public server,

494
00:44:45.595 --> 00:44:46.795
but it would handle

495
00:44:47.310 --> 00:44:50.670
just just fine a small number of users like that. Absolutely.

496
00:44:51.310 --> 00:44:53.550
I think you're in luck because

497
00:44:53.790 --> 00:45:16.255
self hosting is kind of having its moment right now, and it's having its moment because of AI things, which are much more GPU heavy than whatever Frigate requires. So I have a feeling that if our grand utopian vision of a bunch of people self hosting and Uncle Jimming for people comes to fruition, it probably will include integrated GPUs in most of the hardware.

498
00:45:16.895 --> 00:45:20.950
Yeah. So we got that going for us. Yeah, for sure. I think making,

499
00:45:21.109 --> 00:45:36.185
you know, as a developer, I think making a bet on GPU compute increasing in future is a pretty safe bet. And just on that note, if you're like wanting to get the most GPU compute bang for buck in like a mini PC format,

500
00:45:36.424 --> 00:45:41.545
the Mac Mini is the way go and it will run And why, when that's the case? It'll really

501
00:45:42.424 --> 00:45:47.400
do a very decent job of running Frigates. It will handle it well. Frigate

502
00:45:47.560 --> 00:45:54.600
is supports a number of different back ends. So it supports CUDA. CUDA is the back end for NVIDIA chips, which are the really powerful

503
00:45:55.000 --> 00:46:01.994
GPUs that all of the big AI users, all of the gamers use. Those are discrete ones. It supports OpenCL,

504
00:46:01.994 --> 00:46:04.475
which is like an open source platform

505
00:46:04.475 --> 00:46:10.795
that all of the GPU providers kind of have drivers for. So that's NVIDIA,

506
00:46:10.795 --> 00:46:11.595
AMD,

507
00:46:11.755 --> 00:46:15.240
Intel, all of those guys are supported on OpenCL.

508
00:46:15.240 --> 00:46:16.520
And then you have Metal.

509
00:46:16.680 --> 00:46:21.160
Metal is the Mac OS Apple silicon back end for GPUs.

510
00:46:21.400 --> 00:46:47.460
Frigate supports all three of three of those. The OpenCL is almost as fast as the CUDA, which means you, like, you don't just because you're on an AMD chip and not an NVIDIA chip doesn't mean you have really much of a performance impact at all. So there's a whole bunch of chips out there. It's almost every chip made in the last decade, not everyone, but most of them have some kind of GPU compute on them. So, you know, there's a fair chance that the

511
00:46:47.700 --> 00:46:50.980
current node that you have, so long as it's not a Raspberry Pi four,

512
00:46:51.220 --> 00:46:54.740
has some kind of GPU compute on it. I've got this really old,

513
00:46:55.434 --> 00:47:01.115
like, little Intel NUC Core I five. It's running Frigate with OpenCL.

514
00:47:01.835 --> 00:47:02.955
Wow. Okay.

515
00:47:03.355 --> 00:47:03.994
The

516
00:47:05.115 --> 00:47:06.315
I mean, on that note,

517
00:47:07.610 --> 00:47:11.210
and I know we've we've talked about this at length in the past because

518
00:47:11.530 --> 00:47:21.450
I think you kind of from a privacy point of view, you don't love it, but you still offer it. To me, it's always been the simplest way to use Sparrow without using a

519
00:47:22.164 --> 00:47:23.285
public node,

520
00:47:23.525 --> 00:47:24.805
which is that

521
00:47:25.365 --> 00:47:36.724
let's say you're running Sparrow on your MacBook, and then you're running Bitcoin Core on the MacBook too. And then Sparrow can link directly into it, basically. Is there a path here? I mean, if you support

522
00:47:37.050 --> 00:47:38.250
Apple Silicon

523
00:47:38.250 --> 00:47:39.290
GPUs,

524
00:47:39.530 --> 00:47:40.010
then

525
00:47:40.730 --> 00:47:42.810
is there is there a situation where I

526
00:47:43.610 --> 00:47:51.530
in like a couple years, I can just just run Sparrow on a MacBook and not run a separate home server and it just does all the computing stuff on

527
00:47:52.065 --> 00:47:53.185
that one device?

528
00:47:53.744 --> 00:47:58.065
Absolutely. So, I mean, I'm running Frigate on my Mac right now. And,

529
00:47:58.385 --> 00:48:10.990
know, as I was saying earlier, Frigate doesn't support the full set of, they make server calls now, so I'd have to run another piece of software in order to do that. But I can run Bitcoin Core, Frigate, and this,

530
00:48:11.150 --> 00:48:11.630
say,

531
00:48:12.430 --> 00:48:13.630
SelectRX

532
00:48:13.630 --> 00:48:18.510
on my Mac, and I have a full silent payments capable server at that point.

533
00:48:20.575 --> 00:48:22.895
That's awesome. I mean, that might be,

534
00:48:23.535 --> 00:48:25.775
I mean, if you wanna talk about actual

535
00:48:26.975 --> 00:48:31.295
end user support, I don't know. I mean, I remind me, can you

536
00:48:31.615 --> 00:48:35.310
run Bitcoin Core in prune mode in that situation? No, right?

537
00:48:36.190 --> 00:49:02.855
No, you can't because you have to scan, right? Full index, right? Yeah. So, I mean, you could in theory and I think that the Bitcoin Core silent payment support might support pruned node, but you know, it carries all of the kind of pruned node kind of things. So I have to decide whether Sparrow is going to support whether it's going to try and rely on Frigate for that sort of work or whether it's just going to fall back to the Bitcoin core scanning approach, probably the latter,

538
00:49:03.369 --> 00:49:09.050
In which case, it'll just inherit whatever pruning support is inherent in Bitcoin Core's

539
00:49:09.050 --> 00:49:10.330
silent payment support.

540
00:49:11.530 --> 00:49:12.250
Got it.

541
00:49:12.730 --> 00:49:24.255
And then the other piece is, you know, Lightning addresses have their own trade offs. But I think as a community or as a user base, people have really come to love the email address style

542
00:49:24.734 --> 00:49:25.535
usernames.

543
00:49:25.535 --> 00:49:28.255
Right? You know, send a payment to odellprimal

544
00:49:28.255 --> 00:49:31.855
dot net, for instance. Right? What's the deal with that and silent payments?

545
00:49:32.300 --> 00:49:33.660
I presume

546
00:49:34.060 --> 00:49:39.100
if you're running a server, can also just have a human readable address like that now.

547
00:49:39.500 --> 00:49:45.260
Yeah. So I think that the most practical way for us to get there is probably

548
00:49:45.425 --> 00:49:47.025
using DNS.

549
00:49:47.025 --> 00:49:48.625
DNS is not perfect.

550
00:49:49.345 --> 00:49:52.545
DNS is ultimately a centralized

551
00:49:52.545 --> 00:49:53.905
system and

552
00:49:54.145 --> 00:49:55.585
it can and does

553
00:49:56.385 --> 00:49:58.305
get affected by governments.

554
00:49:59.300 --> 00:50:01.860
So, think that that has to be said first, but

555
00:50:02.500 --> 00:50:08.340
for most people, DNS is fine. It is good enough. I just would say that it's not

556
00:50:09.060 --> 00:50:10.580
applicable for every use case.

557
00:50:11.735 --> 00:50:17.095
But with the DNS system, we have a BIP called BIP three fifty three, which is basically allows

558
00:50:17.495 --> 00:50:19.255
us to specify

559
00:50:20.295 --> 00:50:26.535
a Bitcoin silent payments address that looks a bit like userdomain.com.

560
00:50:26.615 --> 00:50:37.090
And effectively, that can contain a BLT12 invoice as well, which is a static invoice. So we now have a static on chain address and a static lightning address

561
00:50:37.330 --> 00:50:43.245
all in one kind of email address like looking Right, then I would just give them like odellprimal

562
00:50:43.245 --> 00:50:54.590
dot net and the person sending me can choose if they wanna send On Chain or Lightning. Exactly. In practice. Absolutely, yeah, yeah, that's it. So it kind of is just adding that. So, you know,

563
00:50:55.630 --> 00:50:59.950
yeah, it's I think a really a massive step forward in terms of,

564
00:51:00.350 --> 00:51:15.555
you know, having things like contact books and wallets where, you know, you can't do that today because you actually just need to go and ask for a new address every time. But now you have the idea of being able to have a sort of address book saying, wanna pay Matt. Okay. Let me go and fetch

565
00:51:15.795 --> 00:51:19.475
Matt's address. That kind of thing is gonna make Walletz much more usable.

566
00:51:20.660 --> 00:51:22.660
And the cool part about that is

567
00:51:23.940 --> 00:51:28.340
that could be a separate hosted service and you're not trusting the host

568
00:51:28.580 --> 00:51:29.620
of your,

569
00:51:30.420 --> 00:51:32.420
you're not trusting the host with your privacy.

570
00:51:33.315 --> 00:51:35.155
You're trusting them with uptime.

571
00:51:35.234 --> 00:51:37.635
And can they man in the middle of that situation?

572
00:51:38.195 --> 00:51:39.155
For They could

573
00:51:39.954 --> 00:51:47.714
could serve a they could serve a fake yeah. They could serve a fake silent payment a different silent payment address. No. So yeah. So

574
00:51:48.140 --> 00:51:53.820
interesting point. So BIP three fifty three uses this technology called DNSSEC,

575
00:51:53.900 --> 00:52:03.500
which effectively allows you to create a cryptographic proof all the way through to the root TLD, the root top level domain. And that is a requirement

576
00:52:03.485 --> 00:52:05.085
and must be verified

577
00:52:05.085 --> 00:52:08.045
by every wallet who implements this particular BIP.

578
00:52:08.285 --> 00:52:15.725
So no, you actually can't do that. Again, that's not to say that governments can't interfere because ultimately

579
00:52:16.000 --> 00:52:16.720
the

580
00:52:17.760 --> 00:52:20.320
DNS system is managed by ICANN,

581
00:52:20.320 --> 00:52:21.040
well, it's

582
00:52:21.520 --> 00:52:24.480
managed by ICANN, which is in practice managed by VeriSign,

583
00:52:24.560 --> 00:52:29.520
which is obviously a US based corp and is under the influence of the US

584
00:52:28.974 --> 00:52:34.575
government. So I'm certainly not making the argument that DNS is Bitcoin's level of

585
00:52:35.295 --> 00:52:36.735
independence and

586
00:52:36.974 --> 00:52:37.855
permissionless.

587
00:52:37.855 --> 00:52:39.375
It's not NSA proof.

588
00:52:39.695 --> 00:52:42.820
Correct, but you know, it's certainly

589
00:52:43.060 --> 00:52:47.300
a lot more hacker proof than you might think, so long as you have full DNSSEC

590
00:52:47.300 --> 00:52:49.060
proofs, which as I say,

591
00:52:49.380 --> 00:52:51.940
three fifty three mandates as a requirement.

592
00:52:52.500 --> 00:52:53.540
Wait, so can

593
00:52:53.780 --> 00:53:02.255
you just walk me through this? Forget about US government. Forget about the most powerful military in the world in the threat model for a second. Let's say Primal.

594
00:53:02.575 --> 00:53:06.015
Right? We're already hosting hosting people's

595
00:53:06.095 --> 00:53:07.455
lightning addresses.

596
00:53:07.455 --> 00:53:08.815
Right? And

597
00:53:08.975 --> 00:53:10.655
and navigating that comms.

598
00:53:11.360 --> 00:53:16.000
Let's say we comply with BIP three fifty three, and we're hosting.

599
00:53:16.800 --> 00:53:21.200
And let's, you know, we're in our utopian future, we're hosting both 12 and

600
00:53:21.760 --> 00:53:22.720
silent payments.

601
00:53:24.225 --> 00:53:27.105
Why why what stops primal from

602
00:53:27.825 --> 00:53:31.425
like a I understand. Okay. So it's hashed and signed presumably.

603
00:53:31.665 --> 00:53:35.585
But how do you how do you know the source of truth? Like, how do I know that primal hasn't?

604
00:53:35.665 --> 00:53:40.070
I go to pay from Sparrow Wallet, and I'm going to pay odellprimal.net.

605
00:53:41.109 --> 00:53:43.269
How do I know that Primal isn't

606
00:53:43.269 --> 00:53:44.310
swapping out

607
00:53:47.430 --> 00:53:50.515
the silent payment address? Yeah, so basically,

608
00:53:50.755 --> 00:53:54.195
you'd have to forge this proof, and that's really

609
00:53:54.435 --> 00:54:03.155
the hard thing to do. I'm gonna have to research the DNS spec It's above your pay grade too? Got it. Give you a better answer, Matt, because I don't wanna say something here which isn't true.

610
00:54:03.849 --> 00:54:08.329
It's a pretty, you know, the DNS spec is sort of a ITEF

611
00:54:08.329 --> 00:54:14.890
standard. In other words, it's kind of being vetted by serious people. Got it. So presumably,

612
00:54:14.890 --> 00:54:21.244
I go to pay I go to pay in Sparrow, and I put in Odell at prima dot net, and it serves me a,

613
00:54:22.204 --> 00:54:25.885
you know, malicious silent payments address instead of the real one,

614
00:54:26.204 --> 00:54:27.244
then presumably

615
00:54:27.244 --> 00:54:31.085
something should pop up in Sparrow and be like, this is unauthenticated.

616
00:54:31.085 --> 00:54:36.360
It failed to check or something like that. Correct. Yeah. That's it. That's it. Don't send the payment.

617
00:54:36.680 --> 00:54:40.120
That's right. It'll it'll it'll not allow you to go on.

618
00:54:40.920 --> 00:54:44.600
Got it. Okay. So, I mean, look, this all sounds well and good.

619
00:54:45.160 --> 00:54:48.920
I would love if, you know, OpenSats is 371

620
00:54:48.920 --> 00:54:53.745
plus grantees were able to just give us a single fixed silent payments

621
00:54:53.905 --> 00:54:56.465
address. And to be clear here in that use case,

622
00:54:56.865 --> 00:55:03.825
you can forget about that whole DNS part we have explained. Right? They can just copy paste a something that looks like a Bitcoin address

623
00:55:04.119 --> 00:55:17.080
that we can reuse over and over again. So, that whole threat model can actually go out the window. That's, I think, more for like everyday payments, and just like a UX improvement, right? How far away are we from that? What needs to be done? How can to be really

624
00:55:17.880 --> 00:55:18.680
make that a reality?

625
00:55:19.244 --> 00:55:26.365
So, so I've got kind of a call out to three different groups in the Bitcoin ecosystem

626
00:55:26.365 --> 00:55:41.620
to think about this more, right? The first are the hardware wallet vendors, right? We have, as I said earlier, all of the standards in place now to implement silent payments. Now I will call out the BitBox here, they implemented a proprietary

627
00:55:41.620 --> 00:55:43.220
kind of implementation

628
00:55:43.940 --> 00:55:46.260
of sending to silent payment

629
00:55:46.515 --> 00:55:52.035
addresses so it's not like they've done nothing, they have done work on it, but it's not the

630
00:55:52.275 --> 00:55:55.555
standards because they simply weren't around at the time. So,

631
00:55:55.795 --> 00:56:01.474
you know, what we need to have is adoption on a hardware wallet level because that's ultimately

632
00:56:01.640 --> 00:56:14.680
a very important part of the ecosystem that we just can't ignore. And if we don't have adoption on the hardware wallet level, this thing will never go anywhere. So that's the first group that I would like to appeal to, to start taking this seriously.

633
00:56:15.145 --> 00:56:16.985
The second group is

634
00:56:18.905 --> 00:56:20.585
the node vendors,

635
00:56:20.585 --> 00:56:23.785
if you will. So we mentioned Start9 earlier,

636
00:56:24.185 --> 00:56:26.105
they've got a great platform for

637
00:56:26.585 --> 00:56:31.090
this. It would be great to see Frigate or even better, another implementation

638
00:56:31.090 --> 00:56:36.050
which uses the database extension that I use in Frigate, that would be awesome too,

639
00:56:36.290 --> 00:56:37.570
and integrates that.

640
00:56:38.130 --> 00:56:41.890
That's Can't you just package that into the community registry

641
00:56:41.890 --> 00:56:42.690
without permission?

642
00:56:43.415 --> 00:56:52.775
I believe it can be done and I believe someone's looking at it, yeah. Awesome. But you know, I think that it needs, it might need a little bit of handholding

643
00:56:52.775 --> 00:56:55.494
in order to get access to the

644
00:56:57.070 --> 00:57:07.070
GPU, I'm not sure, but it would just be You want first class support for it on Star nine and Umbral, just like the Electrum servers are already there, right? Yeah, correct, correct. Makes sense.

645
00:57:07.390 --> 00:57:15.755
Yeah. And then the third group is really the node runners. So the people out there, the individuals and organizations that you mentioned earlier,

646
00:57:16.315 --> 00:57:16.795
who

647
00:57:17.115 --> 00:57:19.994
have been running public spectrum servers

648
00:57:20.190 --> 00:57:25.470
for a long time to start looking at this and saying, is this something that I think I could run?

649
00:57:25.950 --> 00:57:35.470
What kind of hardware do I need? Because all of that stuff takes time, you have to be able to acquire it in today's world with various resource

650
00:57:34.785 --> 00:57:35.665
constraints.

651
00:57:35.665 --> 00:57:38.385
But I do believe we are now at a moment where

652
00:57:38.625 --> 00:57:48.305
Frigate is not gonna get a whole lot faster. Don't think. I think we're at a point where it's fast enough, to be honest. So, you know, now is the time for it to be run, to be tested,

653
00:57:48.305 --> 00:57:59.390
for us to see whether a public server can indeed be run as I believe it can. So those are the three groups that I'm really appealing to at this point to say, start looking at this thing because

654
00:57:59.630 --> 00:58:06.095
if we get it, if we manage to make it an upgrade path for people from HD wallets,

655
00:58:06.335 --> 00:58:10.175
then we have improved privacy on a very fundamental level.

656
00:58:12.895 --> 00:58:13.695
Awesome.

657
00:58:13.695 --> 00:58:17.295
Just to be clear here, once again, just on the hardware wallet side,

658
00:58:20.920 --> 00:58:21.720
the

659
00:58:22.520 --> 00:58:24.280
Sparrow's basically

660
00:58:24.440 --> 00:58:32.360
right. If I'm sending a payment to a silent payment address, I'm using Sparrow to coordinate that transaction and make the PSBT.

661
00:58:32.724 --> 00:58:35.205
Like, it's just giving my cold card a

662
00:58:35.845 --> 00:58:41.045
regular Bitcoin address at that point. Right? It's not serving through the PSBT asylum payments address.

663
00:58:41.605 --> 00:58:42.965
It actually is. Right?

664
00:58:43.204 --> 00:58:45.445
Yeah. So so so basically,

665
00:58:45.525 --> 00:58:48.930
there are checks which the hardware wallet performs.

666
00:58:49.490 --> 00:58:50.930
There's this particular

667
00:58:51.890 --> 00:58:54.290
element of data called a

668
00:58:55.170 --> 00:59:03.115
discrete log equivalence proof, a DLEQ proof. And what that does is it basically says, it allows the coordinator

669
00:59:03.275 --> 00:59:05.195
to check the

670
00:59:05.755 --> 00:59:10.875
Bitcoin address, the normal on chain Bitcoin address that the hardware wallet generates.

671
00:59:10.875 --> 00:59:12.635
So only the hardware wallet

672
00:59:12.795 --> 00:59:14.315
has enough information

673
00:59:14.315 --> 00:59:15.355
to actually generate

674
00:59:16.040 --> 00:59:26.520
the Bitcoin address that you eventually send to derive from the silent payments address. But you can't just trust that the hardware wallet is gonna do the right thing. What if you have a compromised hardware

675
00:59:26.920 --> 00:59:31.905
wallet, right? You can't just have this thing which has all that power. So this DLEQ

676
00:59:31.905 --> 00:59:34.865
proof basically allows the coordinator

677
00:59:34.865 --> 00:59:36.145
to cryptographically

678
00:59:36.145 --> 00:59:42.385
prove that the hardware wallet did the right thing. And that's additional fields that go into the PSPT

679
00:59:42.545 --> 00:59:48.400
need to be answered and filled in by the hardware wallet when it sends So we need all the hardware wallets to

680
00:59:48.800 --> 00:59:49.440
switch

681
00:59:49.920 --> 00:59:52.240
from my OpenSAT situation to

682
00:59:52.960 --> 00:59:54.080
come to fruition. That's

683
00:59:55.119 --> 00:59:58.720
That's right. Right. Are there any complications for like multisig stuff or?

684
00:59:59.915 --> 01:00:02.955
Yeah, there are. So multi sig and

685
01:00:03.595 --> 01:00:11.915
silent payments is not a thing today. Right? In fact Well, about sending from a multi sig? So Yeah. Let's use OpenSets example again.

686
01:00:12.330 --> 01:00:16.570
So like open sets, our treasuries in multi sig, and then we're sending out payments

687
01:00:16.970 --> 01:00:20.650
to presumably, it's fine if the grant recipients are single sig.

688
01:00:21.130 --> 01:00:30.575
Right? I mean, I'm honestly fine with telling grant recipients, they have to run sparrow to receive their grants, they'll figure it they'll do it to get there, you know, 10,000 a month or whatever.

689
01:00:30.815 --> 01:00:35.375
They'll run Sparrow to receive it. But it's a red line that the

690
01:00:36.735 --> 01:00:38.494
the OpenSachs

691
01:00:38.494 --> 01:00:45.530
Treasury has to be multi sig because we don't want a single board member being able to spend the funds. So in that situation, even in that situation it breaks?

692
01:00:46.250 --> 01:00:53.690
Yeah, so you can't send from multisig address to a silent payments address as of now. There are ways to do it. Can basically

693
01:00:53.850 --> 01:00:54.970
have an intermediate

694
01:00:55.325 --> 01:00:56.445
transaction,

695
01:00:56.525 --> 01:00:59.725
which allows you to basically send to

696
01:01:00.205 --> 01:01:00.925
like

697
01:01:01.725 --> 01:01:02.765
sort a output

698
01:01:03.645 --> 01:01:04.445
address.

699
01:01:04.765 --> 01:01:11.600
So you kind of send two transactions in one go. So one is You're like sending to a single SIG that's programmatically Exactly.

700
01:01:12.319 --> 01:01:14.320
Sending to its proper destination.

701
01:01:14.400 --> 01:01:15.280
Absolutely.

702
01:01:15.280 --> 01:01:25.065
So that work has not yet been done. Still needs to be done, but there's no particular reason why that can't work. It's just one of those steps that has to be added in.

703
01:01:26.505 --> 01:01:29.145
Got it. So we're still bets off.

704
01:01:29.625 --> 01:01:30.265
Right?

705
01:01:32.185 --> 01:01:46.350
I think we're now at a point where we we need people to take this thing on a broader ecosystem level. That's kind of where I'm at. And what I'm trying to do today is really just create a bit of excitement for this because there's lots of stuff

706
01:01:46.750 --> 01:01:54.365
all the time going on and lots of places to put your time. But as I say, I think that, you know, the

707
01:01:54.685 --> 01:01:59.645
building blocks are place now. There's no particular reason not to

708
01:02:00.045 --> 01:02:02.045
build on this. I think the most critical

709
01:02:02.600 --> 01:02:06.200
issues have been solved. The standards are largely in place.

710
01:02:06.600 --> 01:02:08.120
We're at a point where

711
01:02:08.360 --> 01:02:12.840
we can upgrade and get that address reuse down. Yeah, that's my

712
01:02:13.400 --> 01:02:20.955
opinion. What about in probably the, this is the the most reachable level of this usage and obviously

713
01:02:21.195 --> 01:02:23.355
not the final form, but

714
01:02:24.235 --> 01:02:33.890
it's nice because literally everything is in your control. Sparrow single sig software wallet sending to a Sparrow single sig software wallet using silent payments.

715
01:02:34.450 --> 01:02:35.890
That's possible today?

716
01:02:36.930 --> 01:02:48.745
It's not possible today because I haven't built so I haven't had a chance to build the receiving side in, right? So, you know, that's the thing that everyone wants. And I've kind of wanted to make sure that the server side was really

717
01:02:49.145 --> 01:02:52.985
like solid before I did that. Because what I don't wanna do is release

718
01:02:53.660 --> 01:02:57.820
asylum payments wallets and then it's just a poor user experience.

719
01:02:58.380 --> 01:02:59.020
Was

720
01:02:59.180 --> 01:03:01.180
very much a you'll kill them on momentum.

721
01:03:01.340 --> 01:03:13.965
Yeah, I'm actually still somewhat hesitant to do that because we don't yet have a frigate public server. Nobody's put up their hand to run that yet. But you know, I'm a little bit hesitant to I mean, you talked Wiz about it?

722
01:03:14.365 --> 01:03:23.000
Yeah. Yeah. I mean, I think Wiz is keen, but you know, it's it's it requires doing. We have to actually make it make it happen. Because you only really need one at first.

723
01:03:24.040 --> 01:03:28.360
It'd be great to, mean, I think I don't have to tell you, but it'd be great to,

724
01:03:28.840 --> 01:03:30.120
at the very least,

725
01:03:31.640 --> 01:03:32.920
have Sparrow

726
01:03:33.125 --> 01:03:34.964
connect to the

727
01:03:34.964 --> 01:03:41.685
only public server available and then be able to test payments between another Sparrow that's doing the same.

728
01:03:42.885 --> 01:03:45.285
Absolutely. Then it becomes real to people. Right?

729
01:03:46.150 --> 01:03:48.230
That's my goal. If if

730
01:03:48.470 --> 01:03:50.950
mempool. Space ran a public

731
01:03:51.110 --> 01:04:01.030
Frigate instance, that would be forward or at least just a public, you know, they they I have filed a feature request on the, I believe, the eSplorer

732
01:04:01.030 --> 01:04:01.510
repo,

733
01:04:01.885 --> 01:04:06.605
which is the particular flavor of Electrum server that mempool.space

734
01:04:06.605 --> 01:04:09.245
run. And my hope is that

735
01:04:09.565 --> 01:04:18.050
that feature gets built and that we we end up in a situation where we don't just have Frigate, where we have more than one Electrum server implementation,

736
01:04:18.530 --> 01:04:23.090
which can use the backend work that I've done. And that's kind of ultimately

737
01:04:23.090 --> 01:04:24.370
the better goal. Yeah.

738
01:04:24.770 --> 01:04:28.930
Mean, Mempool might not be the best example because they no longer run a public Electrum server, right?

739
01:04:29.815 --> 01:04:30.855
It could change.

740
01:04:31.175 --> 01:04:31.735
So

741
01:04:31.975 --> 01:04:44.855
does the same provider have to run both the Electrum server and Frigate? Or could we have someone spin up a Frigate, a public Frigate node that isn't running a public Electrum server? Like, can I use Blockstream's public Electrum server

742
01:04:45.110 --> 01:04:47.190
and then MZ's

743
01:04:47.190 --> 01:05:08.585
Fulcrum I mean, I forget server or something like that? Does that work? You could. Yeah. Yeah. I mean, look, it's it's ideal if one person does it. I mean, it's just And then it's local together. Yeah. Yeah. I think that from a performance point of view, that's kind of what you want. Otherwise, you have, you know, two hops and some transmission delay between and it's just not ideal,

744
01:05:08.905 --> 01:05:09.385
I would say.

745
01:05:11.800 --> 01:05:12.520
Got it.

746
01:05:13.320 --> 01:05:14.040
Okay.

747
01:05:14.599 --> 01:05:16.680
Awesome. I'm pretty excited about it.

748
01:05:17.320 --> 01:05:33.045
Yeah. Yeah. I mean, you know, my next step is, of course, to build the receiving part in. And I think all of as I said, all of the stands are now finally there for me to be able to do it. That's the other reason that I've held off doing it to date. But I would love to launch this with a

749
01:05:33.285 --> 01:05:36.965
public server that can handle it. Because then I think people will

750
01:05:37.445 --> 01:05:38.645
really experience,

751
01:05:39.125 --> 01:05:39.525
you know,

752
01:05:40.190 --> 01:05:40.830
the

753
01:05:41.630 --> 01:05:45.310
convenience of it for the first time. Just how simple it is, just how

754
01:05:45.550 --> 01:06:07.295
much better it is than what they're doing today. And that it'll become very apparent. And I think in a way that the words that I say here can't really express. It comes down to actually using it and saying, Oh, well, I just wanna pay and this thing looks like an email address, and I never have to worry about contacting them again to get a new address, and, you know, privacy is just handled. Like that is the experience I'm trying to work towards.

755
01:06:10.250 --> 01:06:18.730
Love it. Yeah. I mean, I think in a lot of ways, like this is how people like almost assume Bitcoin should work and it just hasn't been the case. And I think it's good that,

756
01:06:20.345 --> 01:06:25.705
I think we need to get away a little bit from silent payments as like purely privacy tech.

757
01:06:26.025 --> 01:06:38.960
I mean, even the name sounds like it's privacy tech, but it's just a UX improvement across the board for how people should be using these things. Yeah. So I mean, you know, I think we should call it SP wallets, like HD wallets, we just call it SP

758
01:06:39.119 --> 01:06:43.599
wallets, just makes it easier. That's what that's the kind of terminology

759
01:06:43.599 --> 01:06:47.535
that I'm gonna use in the Sparrow interface. Yeah, I mean, it's,

760
01:06:48.255 --> 01:06:52.575
I think the privacy stuff kinda comes along for the ride. It's really the convenience

761
01:06:52.575 --> 01:06:53.855
that's gonna make it

762
01:06:54.895 --> 01:07:03.270
usable and kind of make it used, I would say. Yeah. I mean, even just the contact book piece, like you said, like, I should just have a contact book in Sparrow.

763
01:07:03.750 --> 01:07:04.790
And, you know, I

764
01:07:05.670 --> 01:07:13.030
my plumbers listen to my contact book and because I paid him once or my nanny or whatever, and I should just be able to just, like, hit the drop down, fucking pay them.

765
01:07:14.125 --> 01:07:17.885
Almost like a Venmo like experience or Revolut like experience.

766
01:07:20.125 --> 01:07:25.565
Mean, goal and it yeah. Yeah. I mean, if if you think about it, like almost a bit one of the best

767
01:07:25.645 --> 01:07:34.280
places for this technology to thrive is a place like BitKey. You know, they run the hardware wallet, they run the software wallets or the

768
01:07:35.400 --> 01:07:36.359
coordinator,

769
01:07:36.359 --> 01:07:37.240
and they run

770
01:07:37.640 --> 01:07:49.695
all of those kind of servers that they need, they could bring the, you know, But they don't run the Electrum server. They make a point not to run the Electrum server. They have Wizz run it. Oh, interesting. Okay. That I did not know. That

771
01:07:50.175 --> 01:07:54.575
was like a that was a big thing for them that they have Wizz running the Electrum server.

772
01:07:54.975 --> 01:07:59.695
But, yeah, once again, they could just have Wizz run the frigate. I

773
01:07:58.680 --> 01:08:04.040
I mean, I think HD wallets is a really good example there, right? Because HD wallets clearly

774
01:08:05.800 --> 01:08:06.600
help

775
01:08:06.680 --> 01:08:08.760
people use Bitcoin more privately.

776
01:08:09.400 --> 01:08:11.559
But no one thinks of it as a privacy thing.

777
01:08:12.275 --> 01:08:18.915
It's just HD was like, that's, of course, of course, I'm gonna use a wallet that has a super easy backup scheme.

778
01:08:21.155 --> 01:08:22.275
And it's

779
01:08:22.275 --> 01:08:28.035
similar to the upgrade to silent payments. I think that makes sense. We have HD wallets now it's moved to SP wallets.

780
01:08:28.570 --> 01:08:29.530
Yeah,

781
01:08:29.690 --> 01:08:30.330
absolutely.

782
01:08:31.610 --> 01:08:32.810
Love it. Well,

783
01:08:33.690 --> 01:08:45.475
I would love to have you back on, you know, I don't know, as we get more adoption and get further along on this path and update the Freaks. Before we wrap here, do we have any final thoughts for them?

784
01:08:46.675 --> 01:09:00.190
Yeah. Look, my, I guess my my final thoughts apart from, you know, my particular call outs to various ecosystem players is just to keep an open mind. Many people are kind of entrenched in

785
01:09:00.510 --> 01:09:02.350
certain belief systems,

786
01:09:02.350 --> 01:09:02.989
and

787
01:09:03.710 --> 01:09:06.270
for whatever reason, payments may have

788
01:09:06.715 --> 01:09:11.835
not been their first choice. But, you know, just look at it from the perspective of

789
01:09:12.395 --> 01:09:13.755
what inherent

790
01:09:13.755 --> 01:09:14.555
characteristics

791
01:09:14.555 --> 01:09:23.500
does it have and can it solve use cases for me. And that's, I guess, the way in which I've kind of come around to it. I was especially

792
01:09:23.500 --> 01:09:24.619
quite hesitant,

793
01:09:25.660 --> 01:09:33.340
certainly didn't see it as the answer at all, and it was only through a lot of time of looking at it that I kind of came around to realize

794
01:09:33.665 --> 01:09:40.945
that it can indeed solve many of these issues. So, you know, that's what I would encourage people to do is just to

795
01:09:41.265 --> 01:09:46.385
kind of analyze it from that point of point of view. Can this be of use to me in my life?

796
01:09:47.790 --> 01:09:49.789
It a better way forward than what I have today?

797
01:09:50.429 --> 01:09:53.789
Love it. Thank you, Craig, for all the work you do for Bitcoin.

798
01:09:54.190 --> 01:09:59.230
My family and all my projects rely on your software, so thank you again.

799
01:10:01.195 --> 01:10:02.635
You're welcome. Thanks, Matt.

800
01:10:03.755 --> 01:10:04.635
Frakes,

801
01:10:05.035 --> 01:10:10.155
I hope you enjoyed that rep as much as me. Next week, we're gonna be talking to UTXO

802
01:10:10.395 --> 01:10:14.955
about his new Nostrap, Wisp, which is awesome and highly performant on Android.

803
01:10:15.710 --> 01:10:18.750
The week after that is the Vegas conference.

804
01:10:20.110 --> 01:10:21.390
Don't love Vegas.

805
01:10:22.030 --> 01:10:23.310
I think it's kind of a

806
01:10:25.550 --> 01:10:31.745
it's a city I don't like going to. Let me put it that way. But I will be there, so I'm skipping that week on dispatch.

807
01:10:31.745 --> 01:10:36.145
I'm trying to honestly, freaks, I'm trying to reduce international travel and focus on family.

808
01:10:36.625 --> 01:10:55.670
It's hard for me to avoid the largest conference in the world when there's a direct domestic flight to get there, so that's why I'm going. But we're gonna have an awesome RHR event that week. Me and Marty, we're doing it in partnership with PubKey and partnership with the Bugle Boys. You can find information for that at hotstyle.pubkey.com.

809
01:10:55.830 --> 01:10:58.630
Space is limited. Tickets are limited. Get your ticket now.

810
01:10:59.505 --> 01:11:01.985
Join us. It'd be great to meet a bunch of you in person.

811
01:11:02.705 --> 01:11:10.385
And then the week after that, I'm going to have Matt Hill on from start nine. I'm talking about his new o four o upgrade, massive upgrade to start OS.

812
01:11:11.185 --> 01:11:20.600
So I'll be sure to bring up with him and frigate support. What he's gonna say he's gonna say that they set it up so that anyone could package these things.

813
01:11:21.080 --> 01:11:24.760
So I think the key is to make it clear to him that this should be a first class

814
01:11:25.720 --> 01:11:27.400
Matt Hill maintained package.

815
01:11:28.645 --> 01:11:30.724
And we'll we'll see how he takes that.

816
01:11:31.284 --> 01:11:32.084
Great.

817
01:11:32.085 --> 01:11:33.445
Sounds sounds good.

818
01:11:34.005 --> 01:11:34.965
Awesome.

819
01:11:35.284 --> 01:11:37.844
Love you, freaks. Stay on the stack sets. Peace.