CD154: DAN GOULD - PAYJOIN

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 04/11/2025 21:25:26
Duration: 4314.41
Channels: 1

1
00:00:00.080 --> 00:00:01.939
Where's the upside for crypto?

2
00:00:05.120 --> 00:00:08.020
This is Sectors Up Close, and we're talking cryptocurrency.

3
00:00:08.880 --> 00:00:10.960
Bitcoin hit a $20.25

4
00:00:10.960 --> 00:00:11.940
low on Monday,

5
00:00:12.255 --> 00:00:13.795
sliding alongside equities

6
00:00:14.255 --> 00:00:17.395
even though president Trump had promised favorable policies

7
00:00:17.775 --> 00:00:20.755
that would make The US the crypto capital of the planet.

8
00:00:21.135 --> 00:00:23.875
So what's happened to the optimism around cryptocurrency?

9
00:00:24.575 --> 00:00:27.360
Well, Andrew O'Neil is digital assets managing director

10
00:00:28.560 --> 00:00:29.780
at S and P

11
00:00:30.320 --> 00:00:38.100
Global Ratings. Andrew, cryptocurrency was intended as a departure from the traditional financial system, but isn't it moving a lot like any other risky asset at the moment?

12
00:00:38.480 --> 00:00:46.155
Well, Elena, thank you for having me. I think, you're referring to price movements in the last few, few days, few weeks. Certainly, we've seen,

13
00:00:47.655 --> 00:00:48.635
a trend where,

14
00:00:49.735 --> 00:00:51.755
markets have moved to a risk off,

15
00:00:53.150 --> 00:00:56.170
paradigm, in recent days. And, and, clearly,

16
00:00:56.870 --> 00:01:02.410
crypto has joined other asset class in that movement. I think when we come back to why

17
00:01:03.270 --> 00:01:04.395
crypto could be,

18
00:01:04.875 --> 00:01:10.895
an asset that behaves differently, a lot of the assumptions behind that are things that, you know, are are still developing,

19
00:01:11.274 --> 00:01:13.854
may over a number of years become true.

20
00:01:14.395 --> 00:01:16.414
But I would also highlight that then among

21
00:01:16.720 --> 00:01:20.979
crypto assets themselves that there are significant differences. And when we're talking about that

22
00:01:21.759 --> 00:01:25.700
asset that may behave differently, that may be a,

23
00:01:26.240 --> 00:01:29.939
a hedge against current TV basement, for example, that may be uncorrelated

24
00:01:30.465 --> 00:01:43.590
to, to stocks. We're primarily focused on Bitcoin. We're focused on its characteristics as an alternate form of money. We're focused on the fact that it's decentralized, that it's geopolitically neutral,

25
00:01:44.310 --> 00:01:53.689
And we're starting to see adoption in that sense, so that narrative of investment appearing among institutional investors, among public sector investors, among national governments.

26
00:01:54.069 --> 00:02:02.035
But that but we are still very early in that trend. And so it's not very surprising that in an environment where investors are rapidly

27
00:02:02.735 --> 00:02:21.160
switching risk off in their portfolios, that we're seeing some, some correlation between crypto assets and other asset classes. Yes. Last year, of course, there was a lot of talk about Bitcoin being the new gold, about it becoming a safe haven asset. When do you think we will see that happen then? Or perhaps what do we need what needs to happen first? We've already seen,

28
00:02:21.700 --> 00:02:25.800
a an executive order announcing the creation of a,

29
00:02:26.500 --> 00:02:27.000
US

30
00:02:28.114 --> 00:02:28.614
strategic

31
00:02:28.915 --> 00:02:29.814
Bitcoin reserve.

32
00:02:30.114 --> 00:02:30.594
And,

33
00:02:30.995 --> 00:02:33.575
what that has done so far is allocating

34
00:02:34.275 --> 00:02:35.894
existing holdings of Bitcoin,

35
00:02:36.194 --> 00:02:39.814
that, that the, the government has acquired through various

36
00:02:40.510 --> 00:02:41.730
law enforcement procedures,

37
00:02:42.910 --> 00:02:44.930
to this reserve that will not be sold.

38
00:02:45.790 --> 00:02:55.814
There is there there was some discussion in that executive order about adding to that reserve over time if a way to do that can be found that does not bring additional cost to taxpayers.

39
00:02:56.594 --> 00:02:59.974
So we will see over the next couple of months if proposals emerge

40
00:03:00.355 --> 00:03:02.674
or or brought forward that that that are that,

41
00:03:03.394 --> 00:03:08.135
that carry that effect. There was a proposal made last year by senator Cynthia Lummis,

42
00:03:08.720 --> 00:03:09.860
which aimed to accumulate

43
00:03:10.160 --> 00:03:12.020
a million Bitcoin over a period

44
00:03:12.560 --> 00:03:15.220
of five years, which would clearly be significant,

45
00:03:16.320 --> 00:03:23.465
well, bring significant buying pressure to, to to Bitcoin markets. That would be, for context, more Bitcoin than is actually produced

46
00:03:23.765 --> 00:03:26.745
on an annual basis coming as a as a net new,

47
00:03:27.125 --> 00:03:28.745
demand, for the asset.

48
00:03:29.045 --> 00:03:29.545
So

49
00:03:30.005 --> 00:03:32.245
there it's possible that some of the,

50
00:03:32.885 --> 00:03:35.864
early exuberance this year, in Bitcoin price was

51
00:03:36.940 --> 00:03:49.760
something like that being announced. So far, we've only had the announcement regarding Bitcoin already held, but we'll see in the in the next few months if something further comes on that. Bitcoin investors have been a bit disappointed so far with the second Trump administration.

52
00:03:50.060 --> 00:03:55.525
Were they expecting further crypto friendly moves that we haven't seen yet? I think there is that aspect around,

53
00:03:56.465 --> 00:03:59.045
additional buying coming from from the National Reserve.

54
00:03:59.585 --> 00:04:01.525
Beyond that, you know, I I think

55
00:04:01.905 --> 00:04:05.765
crypto markets do bring in a certain amount of leverage that can lead to,

56
00:04:06.660 --> 00:04:07.160
liquidations

57
00:04:07.540 --> 00:04:09.640
and more rapid price decreases.

58
00:04:10.020 --> 00:04:13.560
So we've kind of experienced that in the last few days with

59
00:04:14.340 --> 00:04:18.920
increasing liquidations across centralized and and decentralized exchanges and crypto.

60
00:04:19.555 --> 00:04:20.055
But,

61
00:04:20.595 --> 00:04:24.354
when we look at some of the early developments that we've seen in,

62
00:04:25.395 --> 00:04:27.815
since the change of administration, we've seen the repeal

63
00:04:28.435 --> 00:04:30.134
of SAB one twenty one, which was

64
00:04:30.914 --> 00:04:32.455
a a a a regulatory measure that effectively

65
00:04:32.995 --> 00:04:34.250
made it impossible

66
00:04:34.630 --> 00:04:41.050
for regulated banks to provide custody services on crypto assets. And so that's a major change in terms of bringing institutional

67
00:04:41.510 --> 00:04:42.650
players into the market.

68
00:04:43.030 --> 00:04:46.330
We expect to see regulation emerge on stablecoins

69
00:04:46.790 --> 00:04:49.805
in The US market this year, which will bring,

70
00:04:50.825 --> 00:04:51.565
more comfort

71
00:04:52.265 --> 00:04:56.605
to regulated institutions using blockchain technology and using crypto rails

72
00:04:56.985 --> 00:05:07.010
to transact on, and, again, more emphasis on participation in in, in crypto markets. The last piece of that puzzle is market structure, which is

73
00:05:07.470 --> 00:05:13.330
a legal framework looking to say which regulator will be responsible for which area of the crypto market.

74
00:05:14.110 --> 00:05:15.490
That, that that

75
00:05:16.030 --> 00:05:16.750
that's also,

76
00:05:17.230 --> 00:05:23.705
on on, on the to do list of the US legislature, but, these things take time. And it's certainly not surprising

77
00:05:24.165 --> 00:05:24.565
that,

78
00:05:25.285 --> 00:05:27.785
that, that those things have not yet been,

79
00:05:28.245 --> 00:05:39.030
brought into effect, but we would expect to see movement on that, this year. That was Andrew O'Neil of S and P Global Ratings. Don't forget, you can watch more videos on Reuters.com.

80
00:06:23.925 --> 00:06:30.090
Happy Bitcoin Friday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive

81
00:06:30.470 --> 00:06:35.210
live show focused on actual Bitcoin and Freedom Tech discussion.

82
00:06:35.990 --> 00:06:37.130
That intro clip

83
00:06:37.670 --> 00:06:39.210
was from Reuters

84
00:06:39.510 --> 00:06:41.930
interviewing some suit from S and P,

85
00:06:43.275 --> 00:06:44.415
talking about Bitcoin.

86
00:06:44.715 --> 00:06:48.795
Completely irrelevant really to our today's discussion, but it it felt,

87
00:06:49.435 --> 00:06:52.895
notable enough to to put in the beginning of dispatch.

88
00:06:53.355 --> 00:06:55.950
So I wanna thank you guys for sitting through that with us.

89
00:06:56.830 --> 00:07:01.650
As always, dispatch is a % audience funded. We do not have ads or sponsors.

90
00:07:02.990 --> 00:07:04.690
It is supported by

91
00:07:05.070 --> 00:07:10.130
all you ride or die freaks that continue to donate sets to the show. I see we have

92
00:07:10.724 --> 00:07:14.985
some of our rider dies already in the Nasr live chat. It's good to have the Nasr live chat

93
00:07:15.525 --> 00:07:17.465
back up and on screen

94
00:07:17.925 --> 00:07:19.544
today for this episode

95
00:07:20.245 --> 00:07:21.064
or this show.

96
00:07:22.485 --> 00:07:24.425
I will start off by saying

97
00:07:25.199 --> 00:07:28.660
that I may have blamed some technical difficulties on ZapStream

98
00:07:29.039 --> 00:07:29.780
by Kieran,

99
00:07:30.960 --> 00:07:33.300
but it appears my stream key was rotated,

100
00:07:33.680 --> 00:07:36.900
and I had not adjusted that on my side. So

101
00:07:37.245 --> 00:07:37.905
hand up,

102
00:07:38.205 --> 00:07:43.485
I'll take full blame for that. But we have Super Fat Hour has already zapped 21,000.

103
00:07:43.485 --> 00:07:45.745
EZ has zapped 3,000.

104
00:07:45.885 --> 00:07:47.985
And our top boost from the last

105
00:07:48.365 --> 00:07:51.745
two shows was from Wood Butcher. Wood Butcher,

106
00:07:52.500 --> 00:07:56.199
4,200 sets, and he said, God bless capitalism.

107
00:07:57.539 --> 00:07:58.599
Love to see it.

108
00:07:59.060 --> 00:08:07.965
We have ride or die freak Dan Gould here to join us. It is the second time on the show. First time as a solo guest, we'll be talking about PayJoint. We'll be talking about

109
00:08:08.925 --> 00:08:13.425
using Bitcoin privately. We'll be talking about many things. How's it going, Dan?

110
00:08:13.805 --> 00:08:15.665
Good. Talk about whatever you want.

111
00:08:16.044 --> 00:08:16.365
It's,

112
00:08:17.645 --> 00:08:19.985
something I've been looking forward to to a long time.

113
00:08:20.365 --> 00:08:20.790
Yeah.

114
00:08:22.150 --> 00:08:25.290
I I an interesting place to start, just a relevant,

115
00:08:26.870 --> 00:08:28.090
newsworthy item.

116
00:08:28.950 --> 00:08:33.370
I was pretty excited about this DOJ memo that came out,

117
00:08:34.315 --> 00:08:36.654
saying that they're getting rid of their crypto enforcement

118
00:08:37.035 --> 00:08:37.535
division

119
00:08:38.075 --> 00:08:40.975
and that they will not be

120
00:08:41.435 --> 00:08:41.935
focused

121
00:08:42.875 --> 00:08:45.455
on individuals and developers that are running

122
00:08:45.835 --> 00:08:47.055
or that are maintaining

123
00:08:49.040 --> 00:08:52.899
sovereignty focused Bitcoin software. I think they called out by name,

124
00:08:53.279 --> 00:08:54.579
mixers and tumblers

125
00:08:55.519 --> 00:08:58.899
and self custody wallets. Do you have any opinions on that?

126
00:09:00.000 --> 00:09:08.805
As soon as that came out, my first reaction was, I can't wait for Lola leads to report on this, which did come right after, from the rage.

127
00:09:10.225 --> 00:09:12.485
It's an internal memo. It's not really

128
00:09:13.025 --> 00:09:15.685
a law. It's not even guidance like

129
00:09:16.390 --> 00:09:19.130
FinCEN has. We'll see what actually changes.

130
00:09:19.670 --> 00:09:21.290
It's a narrative shift, but

131
00:09:22.149 --> 00:09:23.130
I'm cautiously

132
00:09:23.589 --> 00:09:24.089
optimistic

133
00:09:24.630 --> 00:09:27.209
to look at it, as anything more than that.

134
00:09:27.830 --> 00:09:31.850
Yeah. I mean, I I appreciate the constant skepticism from Lola.

135
00:09:32.525 --> 00:09:38.545
She is quite unique in the Bitcoin journalism space. And I I don't think she's wrong. Right? Like, it's definitely not

136
00:09:38.925 --> 00:09:40.045
a panacea, but,

137
00:09:42.285 --> 00:09:47.345
I think it's also absolutely massive. Like, I think it's pretty crazy that a year ago,

138
00:09:49.000 --> 00:09:52.700
less than a year ago, we had the samurai developer start in jail.

139
00:09:53.320 --> 00:09:54.860
And today, we have

140
00:09:55.240 --> 00:09:59.900
the DOJ shuttering the same crypto enforcement division that led that case.

141
00:10:00.595 --> 00:10:03.415
I mean, they're obviously still in jail. They still have a court case.

142
00:10:03.795 --> 00:10:04.295
Lola

143
00:10:04.995 --> 00:10:06.695
rightfully pointed out that

144
00:10:07.315 --> 00:10:10.935
they, said that that part is out of scope. They, like,

145
00:10:11.875 --> 00:10:13.255
took that out of the memo.

146
00:10:15.000 --> 00:10:18.140
But, yeah, I think it's a big deal. I think she also reported today,

147
00:10:18.840 --> 00:10:19.900
at least on Noster,

148
00:10:21.880 --> 00:10:27.660
that the broker dealer rule from the IRS is out, which wanted to do KYC on self custody exchanges.

149
00:10:28.735 --> 00:10:34.355
And she seemed pretty optimistic on that. So I don't know. It feels like a lot of progress is being made. It feels like

150
00:10:34.735 --> 00:10:36.115
we have a window here,

151
00:10:38.815 --> 00:10:44.970
where at least the US government isn't actively trying to throw open source contributors into the gulags,

152
00:10:46.070 --> 00:10:48.170
and we should probably be seizing the moment.

153
00:10:50.390 --> 00:10:51.770
Absolutely. It's time

154
00:10:52.230 --> 00:10:52.810
to take

155
00:10:53.110 --> 00:10:54.410
as much as we can

156
00:10:55.315 --> 00:10:58.774
that enables self custody, like sovereign self custody mainstream,

157
00:10:59.475 --> 00:10:59.975
and

158
00:11:01.475 --> 00:11:04.214
raise the bar in terms of what's expected

159
00:11:04.915 --> 00:11:06.455
for bare minimum privacy.

160
00:11:08.020 --> 00:11:14.360
Damn right. Okay. So let's talk about let's just start let's just dive right in. You've been focused on PageJoin,

161
00:11:15.460 --> 00:11:17.000
specifically PageJoin DevKit.

162
00:11:17.860 --> 00:11:19.960
Let's start high level. What is PageJoin?

163
00:11:21.285 --> 00:11:24.825
Pay join is the most fundamental way to batch

164
00:11:25.205 --> 00:11:25.705
transactions

165
00:11:26.325 --> 00:11:27.465
on the input side.

166
00:11:28.005 --> 00:11:28.505
So

167
00:11:28.965 --> 00:11:34.505
almost everyone's familiar with output batching. When you make a withdrawal from

168
00:11:34.890 --> 00:11:36.270
any exchange. They're gonna

169
00:11:36.730 --> 00:11:44.990
make a ton of inputs in or a ton of outputs in that transaction to pay out their users because they make less change and they share the overhead and they save money.

170
00:11:45.770 --> 00:11:48.510
But So, like, if if I do, like, a strike withdrawal,

171
00:11:50.055 --> 00:11:53.495
you'll like, when you look up your strike withdrawal on mempool.space

172
00:11:53.495 --> 00:11:54.075
or whatever,

173
00:11:54.455 --> 00:12:04.955
that transaction is really sending Bitcoin to maybe 200 people, 300 people, including you, and that's that output side batching. Exactly. Because they save a ton of money, and

174
00:12:06.270 --> 00:12:07.490
it doesn't clog

175
00:12:08.110 --> 00:12:13.090
up mempool so they're able to have high throughput so that happened all in 2017

176
00:12:14.590 --> 00:12:18.770
when mempools were full and full and full and fees were getting more and more expensive

177
00:12:19.265 --> 00:12:25.685
Everyone's like, how do you scale a database, which fundamentally Bitcoin blockchain is, and you do that with batching. And that

178
00:12:26.065 --> 00:12:27.925
is consensus. I mean, there was even

179
00:12:28.545 --> 00:12:29.605
calls from

180
00:12:30.625 --> 00:12:36.110
the community at large, like naming and shaming people that didn't do batching until they did it. It was very effective.

181
00:12:38.490 --> 00:12:40.510
Okay. So but in that situation,

182
00:12:40.890 --> 00:12:46.110
usually, it's just one or two on the input side. There's, like, one or two input transactions.

183
00:12:47.130 --> 00:12:52.824
Well, yeah, there there may be any number of inputs, but they all come from the exchange. The exchange

184
00:12:53.845 --> 00:12:58.185
constructs this transaction so that there are enough inputs to fund all of their withdrawals.

185
00:12:59.125 --> 00:13:01.704
They sign it, and they post it to the network.

186
00:13:02.404 --> 00:13:05.305
And that has been great for

187
00:13:06.190 --> 00:13:06.690
throughput.

188
00:13:07.310 --> 00:13:09.410
It's reduced the fees everyone pays,

189
00:13:10.110 --> 00:13:12.050
but it doesn't address this

190
00:13:12.670 --> 00:13:21.490
problem that even Satoshi left in the white paper that anyone looking at a transaction can assume that all the inputs came from the same person.

191
00:13:22.535 --> 00:13:24.075
But because of the way that

192
00:13:24.615 --> 00:13:25.515
Bitcoin works,

193
00:13:27.415 --> 00:13:30.714
any inputs can be spent in a transaction as long as they have a signature.

194
00:13:31.415 --> 00:13:32.154
So if

195
00:13:32.774 --> 00:13:36.394
the person sending the transaction and the person receiving the transaction

196
00:13:37.430 --> 00:13:41.769
both talk to each other, they can contribute inputs and break that assumption

197
00:13:42.870 --> 00:13:43.370
and

198
00:13:43.910 --> 00:13:46.490
that lets us do a ton of stuff. It lets us

199
00:13:47.110 --> 00:13:52.010
save fees because it's even better batching. You're packing more intents into one transaction

200
00:13:52.655 --> 00:13:58.755
and it raises the bar in terms of the minimum privacy everyone gets because that assumption

201
00:13:59.695 --> 00:14:00.195
about

202
00:14:00.575 --> 00:14:02.275
how money flows in the chain

203
00:14:02.975 --> 00:14:06.275
is no longer true. That assumption that all the inputs come from one person.

204
00:14:08.400 --> 00:14:09.300
Right. So

205
00:14:09.920 --> 00:14:12.580
just to unpack a little bit, with Bitcoin surveillance,

206
00:14:14.080 --> 00:14:17.620
and transaction tracking, it's all just probability analysis.

207
00:14:18.320 --> 00:14:18.820
And

208
00:14:19.305 --> 00:14:22.265
so the what is that probability analysis to property

209
00:14:22.745 --> 00:14:27.805
probability analysis is trying is is these surveillance firms are trying to figure out

210
00:14:28.345 --> 00:14:33.965
what percent chance is there that ownership has changed hands between Bitcoin UTXOs.

211
00:14:35.610 --> 00:14:39.310
And the main the main heuristic they use for that

212
00:14:39.769 --> 00:14:48.829
is common input ownership heuristic. This idea that everything on the input side is owned by the sender and who's a single person or a single entity.

213
00:14:51.205 --> 00:14:52.505
With pay join,

214
00:14:54.085 --> 00:14:56.345
multiple parties can contribute inputs.

215
00:14:56.805 --> 00:14:59.385
So all of a sudden, you break that fundamental

216
00:15:01.125 --> 00:15:03.225
probability assumption that everyone

217
00:15:03.605 --> 00:15:05.600
on the input side is the

218
00:15:06.940 --> 00:15:08.399
same the same entity.

219
00:15:09.100 --> 00:15:13.100
Yeah. And there's other tech that Yeah. Breaks this too, but pay join is kind of

220
00:15:14.060 --> 00:15:15.279
pay join is the most

221
00:15:15.740 --> 00:15:18.560
convenient way to do that. Everything around

222
00:15:18.894 --> 00:15:19.394
PayJoin

223
00:15:20.095 --> 00:15:21.475
is set up so that

224
00:15:22.654 --> 00:15:28.675
any two software services can set up a standard way that they can talk to each other and arrange

225
00:15:29.214 --> 00:15:31.394
to make this kind of batch

226
00:15:31.774 --> 00:15:33.020
if they're both online.

227
00:15:35.400 --> 00:15:36.140
So then

228
00:15:38.520 --> 00:15:40.140
why don't you so so

229
00:15:40.600 --> 00:15:41.100
the

230
00:15:41.560 --> 00:15:50.325
the the privacy improvement is clear. I mean, is that you're breaking this you're you're breaking that probability assumption, your that common input ownership heuristic.

231
00:15:51.345 --> 00:15:54.005
How does how does that process of

232
00:15:54.385 --> 00:16:00.145
of adding additional inputs that aren't, you know, maybe they're not even necessary to,

233
00:16:02.370 --> 00:16:07.029
fulfilling the transaction. I mean, you could do the transaction without PayJoin. How does that save fees?

234
00:16:07.810 --> 00:16:09.110
Yeah. The really interesting

235
00:16:10.050 --> 00:16:11.510
savings comes from

236
00:16:12.290 --> 00:16:12.790
creating

237
00:16:14.225 --> 00:16:16.885
fewer coins overall. So this is the same thing

238
00:16:17.345 --> 00:16:17.845
with

239
00:16:18.465 --> 00:16:20.325
receiver side batching that I think

240
00:16:20.865 --> 00:16:21.365
people,

241
00:16:22.705 --> 00:16:27.845
it doesn't readily, it's not readily apparent to people the first time they think about it. So when you batch a bunch of outputs,

242
00:16:29.240 --> 00:16:34.220
yes, all of these transaction intents share one transaction and they share that 10 byte overhead.

243
00:16:34.920 --> 00:16:39.740
But really the big savings comes from not every single

244
00:16:40.839 --> 00:16:41.339
output

245
00:16:42.225 --> 00:16:45.605
to, someone withdrawing from an exchange, say, creating change.

246
00:16:45.985 --> 00:16:52.725
So if there's a change for every single person that withdraws, that input then needs to be spent at some point in the future.

247
00:16:53.265 --> 00:16:54.885
But if you batch them all together,

248
00:16:55.200 --> 00:17:01.860
you can batch 300 people and just get one change. And the input is actually the expensive part of a transaction that includes

249
00:17:02.320 --> 00:17:04.260
the the witness and the script.

250
00:17:05.200 --> 00:17:05.700
So

251
00:17:07.665 --> 00:17:12.725
when you do a pay join, you can do the same sort of thing where if I was gonna send

252
00:17:13.585 --> 00:17:14.405
some exchange

253
00:17:15.185 --> 00:17:19.445
some money and they knew they needed to make a withdrawal, they would have to take my UTXO

254
00:17:19.985 --> 00:17:22.005
and then they would need to spend it again

255
00:17:23.080 --> 00:17:24.700
and we would both create

256
00:17:25.240 --> 00:17:28.460
change. But instead, we can do something called cut through

257
00:17:28.840 --> 00:17:30.139
where some proposal

258
00:17:30.679 --> 00:17:33.260
to a receiver, an exchange from a depositor,

259
00:17:33.960 --> 00:17:39.855
can directly fund withdrawals. So So in some cases, the exchange may not even need to spend their internal coin.

260
00:17:40.235 --> 00:17:40.894
The sender

261
00:17:41.434 --> 00:17:42.815
can fund the transaction

262
00:17:43.115 --> 00:17:43.774
that directly

263
00:17:44.635 --> 00:17:45.135
pays

264
00:17:45.755 --> 00:17:46.255
the,

265
00:17:47.514 --> 00:17:48.894
the people making withdrawals.

266
00:17:50.420 --> 00:17:51.320
And, overall,

267
00:17:51.860 --> 00:17:56.520
there are both fewer transactions and there are fewer coins created. So that

268
00:17:57.860 --> 00:18:00.120
that is where the savings come from.

269
00:18:00.420 --> 00:18:05.155
So if there's, like, a hundred people depositing to strike at the same time as

270
00:18:05.615 --> 00:18:08.115
there's 50 people withdrawing from strike,

271
00:18:08.815 --> 00:18:13.635
then those hundred people that are depositing could actually be on the input side of the withdrawal transaction,

272
00:18:13.935 --> 00:18:17.715
and you kinda knock you knock off both sides at the same time.

273
00:18:18.059 --> 00:18:20.000
That's what we wanna do long term. Yeah.

274
00:18:22.220 --> 00:18:26.240
Okay. So what is page join dev kit, and where does it

275
00:18:27.100 --> 00:18:28.399
fit into this whole

276
00:18:29.500 --> 00:18:30.000
mission?

277
00:18:30.779 --> 00:18:32.720
Yeah. Page join dev kit.

278
00:18:33.325 --> 00:18:35.985
Pedro and DevKit was the way to get me to,

279
00:18:36.525 --> 00:18:39.825
have people understand what the hell I was working on because

280
00:18:40.925 --> 00:18:45.565
Lightning DevKit was working so well, Bitcoin DevKit was working so well, and I was working on kind of the same thing,

281
00:18:46.045 --> 00:18:47.745
a software development kit

282
00:18:48.045 --> 00:18:48.545
to

283
00:18:49.460 --> 00:18:51.400
let any wallet or service

284
00:18:51.940 --> 00:18:53.480
take advantage of this technology.

285
00:18:55.380 --> 00:18:56.680
But without that

286
00:18:57.620 --> 00:18:58.120
branding,

287
00:18:58.420 --> 00:19:00.915
people didn't people didn't get what it was. And this is where,

288
00:19:01.715 --> 00:19:05.895
PayJoin's a bit different than a lot of what has come before in terms of privacy tech.

289
00:19:06.275 --> 00:19:14.455
It only really works if everyone is using it or if a significant number of people are using it. So PayJoin DevKit lets you take this off the shelf

290
00:19:14.835 --> 00:19:16.135
protocol implementation

291
00:19:16.890 --> 00:19:19.630
and plug it into your wallet. So Bold Bitcoin

292
00:19:19.930 --> 00:19:20.590
just released

293
00:19:21.210 --> 00:19:21.950
in December

294
00:19:22.570 --> 00:19:23.070
this

295
00:19:23.450 --> 00:19:26.030
PayJoin DevKit integration into their wallet,

296
00:19:26.730 --> 00:19:30.830
and we were able to demonstrate its use also in Bolt's

297
00:19:31.415 --> 00:19:36.155
Exchange and Liana over this past week. So it's an off the shelf toolkit.

298
00:19:37.095 --> 00:19:40.315
Any software can take, plug into their wallet, and activate PayJoin.

299
00:19:41.735 --> 00:19:42.715
Because if

300
00:19:43.030 --> 00:19:44.410
for this to work,

301
00:19:45.030 --> 00:19:47.370
you need you kinda need widespread

302
00:19:48.790 --> 00:19:56.505
wallet and, like, service ex support. Right? Like, the exchanges would need to support it and the the people who are,

303
00:19:57.145 --> 00:19:59.005
I guess, the people that are depositing

304
00:19:59.865 --> 00:20:03.325
their wallets would need to support it, not necessarily on the receiver side. Right?

305
00:20:04.905 --> 00:20:13.860
Matt, in an ideal world, you'd want the receivers to do this too. Oh, I guess so. Any any transaction intent, you can think of this as kind of a pseudo mempool. It's like before

306
00:20:14.320 --> 00:20:20.740
we get to mempool, if we're willing to communicate with other people, we can take all the transactions we wanna make and batch them together.

307
00:20:21.520 --> 00:20:24.660
And everyone Right. Saves money. But, yeah, that's the idea.

308
00:20:25.085 --> 00:20:30.785
You need as many but you just need as many wallets and services to support it as possible for it to work at scale,

309
00:20:31.485 --> 00:20:35.985
basically. And so dev the page join dev kit makes it easy for all of these different

310
00:20:36.445 --> 00:20:48.110
maintainers to to add support. Right? Yeah. I think of it as HTTPS. That was controversial in its day, but now it's ubiquitous and so everyone has better privacy. The only real way we can do this,

311
00:20:48.970 --> 00:20:49.470
upgrade

312
00:20:50.305 --> 00:20:51.045
to Bitcoin

313
00:20:51.745 --> 00:20:55.125
is by making it network wide, which in

314
00:20:55.505 --> 00:20:58.325
the application world, if you're not changing the actual protocol,

315
00:20:58.705 --> 00:21:01.365
you need many people to participate in. And

316
00:21:02.545 --> 00:21:03.045
the

317
00:21:04.410 --> 00:21:10.910
reason that PayJoin lets this happen across the network and not just between the people that use it is because a lot of the transactions

318
00:21:11.850 --> 00:21:17.470
that went through this process look the same as transactions that didn't necessarily go through this process.

319
00:21:18.195 --> 00:21:19.174
So you have

320
00:21:20.274 --> 00:21:22.294
you have a greater degree

321
00:21:23.955 --> 00:21:24.455
of

322
00:21:25.315 --> 00:21:25.815
ambiguity

323
00:21:27.715 --> 00:21:30.855
on whether all the inputs came from one person or not

324
00:21:31.315 --> 00:21:32.054
for everyone.

325
00:21:33.440 --> 00:21:34.260
There's a

326
00:21:34.799 --> 00:21:35.280
if you,

327
00:21:35.840 --> 00:21:38.660
so, like, if you just, like, see a non paid join transaction

328
00:21:39.280 --> 00:21:47.745
on mempool.space, for instance, you you might not be able to tell if it's a paid join or not. Right? So it just breaks that. Yeah. It's it's complex because

329
00:21:48.205 --> 00:21:49.665
there are a lot of other fingerprints,

330
00:21:50.125 --> 00:21:56.865
but this is kind of the least we can do in a package that can be automatic for all this software. So you plug it into your wallet.

331
00:21:57.325 --> 00:22:01.265
Your users don't have to take additional actions. It's just packed into the

332
00:22:01.669 --> 00:22:03.210
flow that everyone's used to.

333
00:22:03.990 --> 00:22:04.890
You send me

334
00:22:05.429 --> 00:22:07.370
an address, basically a URI,

335
00:22:08.390 --> 00:22:11.530
and, you know, like, some payment instructions, and I pay that

336
00:22:12.390 --> 00:22:20.054
by pasting that address, and my wallet takes care of the rest. If there's an opportunity to batch, we do the page one batch. If not, we fall back,

337
00:22:20.674 --> 00:22:25.414
and everyone gets this as a convenience. I think in the past, a lot of these techniques

338
00:22:25.875 --> 00:22:35.990
have involved a lot of know how. And if you didn't use them right, you could make mistakes, and you might have paid a bunch of money and time and not even be any better off. This is about the widespread

339
00:22:37.730 --> 00:22:39.909
increase for everyone. Everyone has

340
00:22:40.690 --> 00:22:41.350
a higher

341
00:22:42.610 --> 00:22:43.750
degree of privacy

342
00:22:45.035 --> 00:22:46.815
whether they even use this or not

343
00:22:47.674 --> 00:22:48.575
by existing.

344
00:22:49.275 --> 00:22:53.775
And I love the it just falls back. It'll just do a regular transaction if the pay join

345
00:22:54.554 --> 00:23:02.220
process fails. But the so, I mean, one of the the big not not necessarily issues, but trade offs with page join historically

346
00:23:02.520 --> 00:23:04.300
has been that it needs to be

347
00:23:05.080 --> 00:23:07.420
interactive and that, you know, so effectively,

348
00:23:08.120 --> 00:23:15.085
senders, all senders and receivers need to be online to, like, coordinate with each other and sign and broadcast this transaction.

349
00:23:15.705 --> 00:23:18.684
My understanding is that's no longer the case. And,

350
00:23:19.625 --> 00:23:21.645
like, how are you handling that

351
00:23:22.120 --> 00:23:23.179
information exchange?

352
00:23:27.080 --> 00:23:33.740
The beauty of Bitcoin is that it's noninteractive. You just take a transaction you post it, you submit it to Right. Whatever,

353
00:23:35.080 --> 00:23:35.580
mempool,

354
00:23:35.975 --> 00:23:37.835
and eventually it'll get mined in a block.

355
00:23:39.255 --> 00:23:44.395
Pay join takes advantage of the fact that most of us are online some of the time.

356
00:23:45.015 --> 00:23:45.515
So

357
00:23:46.055 --> 00:23:48.155
the fallback is there in case we're not.

358
00:23:48.775 --> 00:23:51.100
But if we are, we can both

359
00:23:51.480 --> 00:23:51.980
use

360
00:23:52.680 --> 00:23:54.060
what's essentially a mailbox

361
00:23:56.280 --> 00:23:58.860
to coordinate together. So the problem with

362
00:23:59.720 --> 00:24:00.460
the past,

363
00:24:01.800 --> 00:24:05.925
the his so there was there were two iterations. This has been going on since 2018.

364
00:24:06.545 --> 00:24:07.045
And

365
00:24:07.665 --> 00:24:09.125
the standard communication

366
00:24:10.065 --> 00:24:11.285
required you to

367
00:24:12.465 --> 00:24:17.125
run a public publicly accessible server to receive page lines. But we,

368
00:24:18.210 --> 00:24:19.990
meaning the page join dev kit team,

369
00:24:20.770 --> 00:24:21.909
came up with a

370
00:24:23.010 --> 00:24:24.150
directory server

371
00:24:24.690 --> 00:24:25.990
that hosts these mailboxes

372
00:24:26.450 --> 00:24:28.230
and anyone can host one of these servers.

373
00:24:28.690 --> 00:24:32.390
And you put your message in the mailbox and the person that is

374
00:24:32.695 --> 00:24:35.275
waiting for your payment is listening to updates for this.

375
00:24:35.735 --> 00:24:40.715
And just like email, when that message comes in, they can reply to it. And if they don't reply to it in time, we fall back.

376
00:24:44.870 --> 00:24:49.690
Okay. So it's still interactive. It's just Yeah. Like, it's a looser interaction.

377
00:24:50.710 --> 00:24:55.450
It's asynchronous. So we don't need to be online at the same time because there's that box in the middle.

378
00:24:56.230 --> 00:24:56.550
We

379
00:24:57.110 --> 00:25:11.965
as long as we come on within some time frame, we're both comfortable with. And what is that time frame? It's like lightning is the same thing. Lightning, you need to come online to communicate and a big issue with like zaps is that it's a synchronous protocol for the most part right now. But if we

380
00:25:13.050 --> 00:25:16.750
make that asynchronous, this problem goes away and that's where like

381
00:25:17.210 --> 00:25:22.030
an npub. Cache makes things easier because they're always online on your behalf.

382
00:25:23.690 --> 00:25:24.190
The

383
00:25:24.650 --> 00:25:26.110
async pay join spec

384
00:25:26.490 --> 00:25:26.990
says

385
00:25:27.784 --> 00:25:32.205
there's someone that can always be online on your behalf. It's not exactly the same, but

386
00:25:32.664 --> 00:25:34.524
yeah. What was the question you just asked?

387
00:25:35.544 --> 00:25:42.205
Like, in practice, how long do you think that period will be? Oh, by default, we set it to twenty four hours in clients just like,

388
00:25:43.120 --> 00:25:50.820
you know, your typical lightning invoice, but it's configurable on the client. So application specific. I think exchanges with exchange rates will probably have

389
00:25:51.120 --> 00:25:53.539
narrower constraints like b t c pays,

390
00:25:54.080 --> 00:25:55.779
exchange rate holds for an hour.

391
00:25:56.960 --> 00:25:57.460
And

392
00:25:58.835 --> 00:25:59.335
it's

393
00:25:59.715 --> 00:26:02.135
application specific. The point of the protocol is

394
00:26:02.435 --> 00:26:03.395
not to

395
00:26:05.155 --> 00:26:09.735
and I'm talking about the BIP 77 v two join async page on protocol that's

396
00:26:10.195 --> 00:26:18.450
being finalized right now. Right. The point is that everyone can communicate on the same standard just to make a batch. It doesn't restrict itself

397
00:26:19.070 --> 00:26:21.809
to the transaction needs to be of this certain shape

398
00:26:22.350 --> 00:26:30.115
or amount or within a certain time frame is just a very fundamental, convenient way we can attempt to talk to each other,

399
00:26:30.654 --> 00:26:31.154
and,

400
00:26:32.575 --> 00:26:35.794
hopefully, we're able to. And if not, we fall back.

401
00:26:37.135 --> 00:26:37.635
So,

402
00:26:39.629 --> 00:26:45.570
yeah, I mean, I don't think, you know, even twenty four hours probably be fine for most people.

403
00:26:47.230 --> 00:26:51.970
I mean, I there there's some there's some precedent already. Right? So, like, for instance,

404
00:26:52.905 --> 00:26:53.565
at least

405
00:26:54.265 --> 00:26:57.405
to my knowledge, both strike and cash app offer,

406
00:26:58.105 --> 00:27:12.850
you can like pay for a priority withdrawal or you can get a free withdrawal that happens sometime within twenty four hours. Right. And plenty of people choose the I'm willing to wait up to twenty four hours. Usually it doesn't take a full twenty four hours, but I'm willing to wait up to twenty four hours to

407
00:27:13.390 --> 00:27:14.450
have a free withdrawal.

408
00:27:15.230 --> 00:27:25.215
And those are the best targets for the cut through because if if once people are queued up to have their withdrawal and a pay join comes into the exchange, that person depositing to the exchange can

409
00:27:25.595 --> 00:27:27.455
preempt that queue. It can pay everyone.

410
00:27:27.995 --> 00:27:28.495
Exactly.

411
00:27:29.675 --> 00:27:31.934
So my point is is, like, there's already

412
00:27:33.080 --> 00:27:37.660
effectively like real world user testing that people are like fine with that time period.

413
00:27:38.280 --> 00:27:43.500
You know, maybe you'd want it to be a little bit shorter, but that makes sense to me now in practice,

414
00:27:43.800 --> 00:27:45.420
like, just walk us through this.

415
00:27:46.280 --> 00:27:46.780
If

416
00:27:48.195 --> 00:27:52.294
let's free, let's use easy numbers. A hundred people are depositing a hundred people withdrawing

417
00:27:52.595 --> 00:27:54.455
and it's a cut through pay join.

418
00:27:54.995 --> 00:27:56.775
That means every single person

419
00:27:57.155 --> 00:27:58.135
in that transaction

420
00:28:00.030 --> 00:28:00.850
needs to be

421
00:28:01.390 --> 00:28:04.210
online for at least a little bit during that period. Right?

422
00:28:05.710 --> 00:28:07.250
Not exactly. So there's

423
00:28:07.550 --> 00:28:11.330
there's a couple levels to this thing. The page r d two spec

424
00:28:11.710 --> 00:28:13.170
is really only for

425
00:28:13.665 --> 00:28:20.165
one sender and one receiver, but that one receiver can define as many outputs as they want. So your base case

426
00:28:20.545 --> 00:28:22.645
is that there's a queue at an exchange

427
00:28:23.105 --> 00:28:27.045
where people are willing to wait, a depositor sends some money to the exchange,

428
00:28:27.420 --> 00:28:30.080
and that preempts the whole queue. If the

429
00:28:30.460 --> 00:28:32.960
exchange needs to add some input to pay for that,

430
00:28:33.300 --> 00:28:33.800
they

431
00:28:34.140 --> 00:28:35.520
can add that input.

432
00:28:35.820 --> 00:28:36.320
But

433
00:28:36.780 --> 00:28:37.260
there's

434
00:28:37.660 --> 00:28:43.065
because it's only one back and forth round of communication, it only really works with one

435
00:28:44.005 --> 00:28:44.505
depositor.

436
00:28:45.925 --> 00:28:46.425
Now

437
00:28:48.165 --> 00:28:50.665
we did just sneak in a feature

438
00:28:51.925 --> 00:28:52.425
into

439
00:28:53.925 --> 00:28:54.425
our

440
00:28:54.805 --> 00:28:57.060
last release of PageOne DevKit that allows

441
00:28:57.380 --> 00:29:00.680
multiple senders and senders to send to one receiver.

442
00:29:01.140 --> 00:29:08.680
But still that one receiver is defining all of the outputs. So from the perspective of the depositor, they're only interacting with the exchange,

443
00:29:09.460 --> 00:29:15.015
but the exchange is free to choose all of the outputs. So they can forward payment to anyone, but those

444
00:29:15.475 --> 00:29:16.615
people making withdrawals

445
00:29:17.475 --> 00:29:18.775
are not part of the interaction.

446
00:29:20.835 --> 00:29:27.390
It's just the deposit side is. Just the deposit side because they need to provide signatures. And because they need to provide signatures, you need to

447
00:29:27.850 --> 00:29:29.150
interact until that's done.

448
00:29:29.690 --> 00:29:38.270
Right. On the on the withdrawal side, it's just the exchange providing, like, all the withdrawal addresses like they usually do. Yeah. And then have the amounts or whatever.

449
00:29:39.095 --> 00:29:50.395
Okay. So that's way more doable too because then the exchange just has, like I I guess you use the word queue. It has, like, a queue of withdrawals that are, like, their free batch withdrawals, and they just wait till

450
00:29:51.059 --> 00:29:51.799
they have

451
00:29:52.899 --> 00:29:57.000
an appropriate amount of inputs on the the sender side to do the transaction.

452
00:29:57.460 --> 00:29:58.279
Boom. Done.

453
00:29:58.659 --> 00:30:04.279
At some point in the future, maybe we can have receivers too, and we can have the receiver specify what output they want

454
00:30:04.635 --> 00:30:06.975
because then then even the

455
00:30:07.355 --> 00:30:13.455
exchange wouldn't know exactly what address they sent to. They'd they'd get a proof of payment, but, like, for the highest,

456
00:30:15.435 --> 00:30:25.560
version of this, I wanna be able to send to you. I don't really care what address you have. As long as I get some proof that it ended up in your address, I don't actually wanna know what your address is.

457
00:30:26.340 --> 00:30:26.840
Right.

458
00:30:29.855 --> 00:30:31.475
That'll make sense to me.

459
00:30:32.335 --> 00:30:33.955
The you mentioned earlier

460
00:30:34.815 --> 00:30:36.035
that there's some nuances

461
00:30:36.415 --> 00:30:38.275
in terms of PayJoin fingerprinting.

462
00:30:38.655 --> 00:30:43.235
I mean, the Wallet fingerprinting. Yes. Yeah. The hype the hype

463
00:30:43.679 --> 00:30:51.139
answer is always, you know, with pay join, if we get like 5% of transactions using pay join, then everyone has privacy.

464
00:30:53.200 --> 00:30:56.740
What are the new, like, where, where are the nuances there in terms of,

465
00:30:59.505 --> 00:31:03.845
being able to tell which transactions are paid join versus which ones aren't?

466
00:31:05.424 --> 00:31:06.085
It's tough

467
00:31:06.625 --> 00:31:21.800
because this 5% number just comes from what people think of as statistically significant. Like that number is literally pulled out of the sky and I think a lot of people in research community say 5% is statistically significant but that p value can

468
00:31:22.740 --> 00:31:23.535
can change. And the other tricky part is because the page one's blank,

469
00:31:24.255 --> 00:31:25.955
And the other tricky part is

470
00:31:26.335 --> 00:31:37.055
because the page ones blend in, it's hard for it's impossible for us really to collect data on exactly how many page ones there are. And by page join here, I'm not talking about the coordination. I'm talking about,

471
00:31:38.610 --> 00:31:40.710
let's say common input transactions,

472
00:31:41.730 --> 00:31:44.630
transactions that break that assumption and those that don't.

473
00:31:45.170 --> 00:31:45.809
So it is,

474
00:31:46.770 --> 00:31:50.150
it is a vibes based measurement, but if this is widespread,

475
00:31:50.930 --> 00:31:51.830
if it's significant

476
00:31:52.210 --> 00:31:53.190
to some degree,

477
00:31:53.785 --> 00:31:55.085
then you do have

478
00:31:56.505 --> 00:31:57.005
compounding

479
00:31:57.945 --> 00:32:12.570
ambiguity in what happened in every transaction. Because if you like, if I'm doing the analysis, I have to make a guess. I have to say, I think there's a 5% chance, there's an n percent chance that these inputs came from different people and every hop along the way

480
00:32:13.830 --> 00:32:16.410
that whether or not the input is linked to the output,

481
00:32:19.110 --> 00:32:21.210
is is uncertain to me. The

482
00:32:21.585 --> 00:32:25.445
probability compounds. Wallet fingerprinting is a different is a little bit different,

483
00:32:25.985 --> 00:32:31.445
in general. So like some wallets will maybe use a certain unlock time or a certain script type

484
00:32:31.745 --> 00:32:33.125
and you can follow

485
00:32:35.269 --> 00:32:36.090
their activity

486
00:32:36.789 --> 00:32:39.929
because you know this software only produces transactions

487
00:32:40.710 --> 00:32:41.690
with this shape.

488
00:32:42.470 --> 00:32:44.010
But I believe in general

489
00:32:45.110 --> 00:32:46.409
batching this stuff together

490
00:32:47.190 --> 00:32:47.690
helps,

491
00:32:51.215 --> 00:32:52.355
make those, helps

492
00:32:52.895 --> 00:32:57.555
make those fingerprints less distinct because it's unclear what software is producing

493
00:32:58.335 --> 00:33:04.440
what fingerprint. You got to go through the source code and like pull out what fingerprints this stuff is making. There's great work,

494
00:33:05.320 --> 00:33:06.679
at ashana.com

495
00:33:06.679 --> 00:33:14.200
about this, but that's What's that? Area improvement. How do you spell that? I shaana,

496
00:33:14.200 --> 00:33:14.700
ashana

497
00:33:15.159 --> 00:33:15.659
Com.

498
00:33:16.279 --> 00:33:16.940
Got it.

499
00:33:18.045 --> 00:33:20.225
I mean, part of that gets kinda solved

500
00:33:20.605 --> 00:33:27.505
if the more wallets that add pay joint support. Right? Because that fingerprint is what wallet was used to construct the transaction.

501
00:33:28.045 --> 00:33:29.505
So if that wallet was

502
00:33:30.285 --> 00:33:37.370
has pay joint support, then it kinda solves that. And if all these things are plugged together in a big graph, it's very difficult

503
00:33:37.670 --> 00:33:40.410
to find the cluster, the edge of the cluster. Yeah.

504
00:33:40.710 --> 00:33:42.810
But, like, in a in a real world

505
00:33:43.270 --> 00:33:43.770
scenario,

506
00:33:44.310 --> 00:33:51.745
like, I think most Bitcoiners in our bubble don't realize that the number one self custody in wallet in the world by far is Trust Wallet by Binance,

507
00:33:52.365 --> 00:33:58.945
which is an absolutely horrible Bitcoin wallet, but supports Tron and Solana and everything else. So many people use it.

508
00:34:01.230 --> 00:34:10.530
And for instance, they probably have I mean, I don't know. I'm speaking out of my ass, but my guess is that they have a relatively obvious fingerprint when you do a trust wallet transaction.

509
00:34:10.990 --> 00:34:14.450
I mean, for starters, I think they just reuse addresses. But

510
00:34:16.585 --> 00:34:20.605
so if you were a user of that, then you're not getting any of the passive PayJoin

511
00:34:21.065 --> 00:34:28.365
privacy benefits because it's very obvious you're sending from Trust Wallet. So in that situation, you're clearly not using PayJoin. Right?

512
00:34:31.710 --> 00:34:32.210
Yeah.

513
00:34:33.230 --> 00:34:33.730
You're

514
00:34:34.750 --> 00:34:38.210
probably you're probably stuck with it. There is a limit to

515
00:34:39.630 --> 00:34:44.615
how effective pay join can be. If you're if you're using the same address every time, even if you're

516
00:34:46.115 --> 00:34:49.655
involved, you're not gonna be helped. There is basic hygiene

517
00:34:50.275 --> 00:34:51.175
we need to

518
00:34:51.555 --> 00:34:52.055
promote

519
00:34:52.915 --> 00:34:53.895
at, you know,

520
00:34:55.475 --> 00:34:58.600
devs and promoters in the space that people clean

521
00:34:59.700 --> 00:35:00.360
up. So,

522
00:35:01.780 --> 00:35:03.080
if I recall correctly,

523
00:35:03.540 --> 00:35:05.320
there was a pay join

524
00:35:06.820 --> 00:35:07.320
implementation

525
00:35:08.500 --> 00:35:10.440
that might still exist, that was pushed,

526
00:35:11.415 --> 00:35:14.715
that was that was implemented by BTCPay server

527
00:35:15.015 --> 00:35:16.955
that I think Kooks was,

528
00:35:19.175 --> 00:35:20.475
the maintainer of.

529
00:35:20.855 --> 00:35:23.355
And they had, like, this concept of

530
00:35:23.895 --> 00:35:25.675
I think he called it, like, a snowball

531
00:35:26.420 --> 00:35:28.680
where, like, the idea was that if you're the receiver,

532
00:35:29.300 --> 00:35:31.080
you could get fee savings

533
00:35:31.460 --> 00:35:32.200
by using

534
00:35:33.780 --> 00:35:37.400
transactions where you're receiving, let's say, you're a merchant and you could,

535
00:35:38.580 --> 00:35:43.984
basically, consolidate UTXOs because the number one fee burden for transactions is

536
00:35:44.365 --> 00:36:01.620
how many UTXOs you have on the input side. So ideally, if you care about fees, you want to consolidate UTXOs. But if you consolidate UTXOs, you have privacy loss. So why not use PayJoin to do that process for you so you don't have privacy loss, but you do have consolidation so you have fee savings?

537
00:36:03.680 --> 00:36:05.300
What is your opinion on that?

538
00:36:05.760 --> 00:36:17.225
That sounds great. All of this PayJoin dev kit is built on the foundation that Kooks and Nicholas and the contributors to BIP 78 page join version one worked on. So it's totally backwards compatible

539
00:36:17.845 --> 00:36:18.505
with that.

540
00:36:20.245 --> 00:36:30.900
That protocol is limited because of the liveness assumption. It requires sender and receiver to be online at the same time. But for someone like a merchant, it's it still works. You lose a little bit on the metadata protection,

541
00:36:31.840 --> 00:36:32.980
but it still works.

542
00:36:33.360 --> 00:36:42.075
Yeah. That was my next question. Like, isn't it a heuristic itself, the snowballing? Like, isn't that kinda obvious on chain that that that's what you're doing and it's a pay join?

543
00:36:42.474 --> 00:36:42.974
It

544
00:36:43.275 --> 00:36:46.175
is, but it's no different really than if you're

545
00:36:46.555 --> 00:36:58.369
making a peel chain by sending a small amount and receiving change and sending a small amount on that change the same direction. The way you get by that is by, batching some outputs or making some intermediate transactions.

546
00:36:59.630 --> 00:37:00.369
But still,

547
00:37:02.510 --> 00:37:04.050
even if you have this snowball,

548
00:37:04.430 --> 00:37:06.210
all of the inputs to that transaction

549
00:37:06.750 --> 00:37:10.050
might not necessarily come from the same person, and you might be making

550
00:37:11.795 --> 00:37:12.454
a bigger

551
00:37:13.875 --> 00:37:19.015
change. Maybe there's an amount that maybe there's a pay join out. It's hard to distinguish.

552
00:37:19.635 --> 00:37:24.055
So you don't know if this snowball, the big ball is going as change to the sender

553
00:37:24.369 --> 00:37:31.030
or the receiver. You don't necessarily know the direction. You might be able to make some assumptions about it, but I don't think it says

554
00:37:31.650 --> 00:37:34.630
I don't think that problem is as clear cut to analyze

555
00:37:35.010 --> 00:37:36.310
as some of the naysayers

556
00:37:36.690 --> 00:37:37.349
might think.

557
00:37:38.904 --> 00:37:45.964
It would it would probably have to be more of an active attack rather than, like, a passive attack looking back on the chain. Right? Because you could

558
00:37:46.585 --> 00:37:47.645
you could do, like,

559
00:37:48.184 --> 00:37:56.470
if you're thinking is a merchant using paid join in a Snowball, you can just do some transactions to the merchant, open up their BTC based server,

560
00:37:57.970 --> 00:38:08.230
send some money, see how it flows. But that's obviously completely different than, like, looking back five years on the chain or something. Right? If you're second party to the transaction, if you are the sender, you can see the change.

561
00:38:09.010 --> 00:38:09.405
That's

562
00:38:09.885 --> 00:38:10.865
or you can see

563
00:38:11.405 --> 00:38:13.745
the consolidation between the Yeah. You would know.

564
00:38:14.125 --> 00:38:17.585
Yeah. That is a big issue that needs to be alleviated

565
00:38:18.205 --> 00:38:34.610
and only can really be fixed if we have these multiparty pay joins where there are multiple senders and multiple receivers. Right now, because there's only two people involved, I know what like, if I'm sending money to you, I know what inputs and outputs are mine. You know what inputs and outputs are yours. Until we have another person involved, that's always the case.

566
00:38:35.150 --> 00:38:38.290
I guess there's there is a caveat there, which is if you're the receiver,

567
00:38:38.670 --> 00:38:45.704
you can make outputs that forward money to other people, and I don't necessarily know about that. But I Right. Would not rely on that strictly.

568
00:38:46.565 --> 00:38:47.145
I mean

569
00:38:48.005 --> 00:38:51.545
and you you have this I mean, the big issue there, right, is that

570
00:38:53.550 --> 00:38:57.650
let's just use the merchant example again. Like, if a merchant's doing paid join

571
00:38:59.230 --> 00:39:00.770
and I'm trying to

572
00:39:01.230 --> 00:39:03.250
figure out their transaction graph,

573
00:39:05.085 --> 00:39:06.065
they're disclosing

574
00:39:06.445 --> 00:39:07.585
UTXO ownership

575
00:39:07.965 --> 00:39:17.585
that they might not otherwise to me when they're giving me their input. Right? Like, is there is there, like, almost like a denial of service style? It's not really denial of service, but, like,

576
00:39:19.330 --> 00:39:19.910
input harvesting

577
00:39:20.290 --> 00:39:21.270
kind of information

578
00:39:21.650 --> 00:39:22.150
gathering

579
00:39:23.170 --> 00:39:25.270
attack that could happen there if you're

580
00:39:25.970 --> 00:39:31.975
pulling Yeah. This is the inputs from the target. Probing attack in the literature. It's a probing attack. So

581
00:39:32.355 --> 00:39:34.035
on payjoindevkit.org,

582
00:39:34.035 --> 00:39:36.775
there's a blog post all about the probing attacks

583
00:39:37.395 --> 00:39:38.295
that have been

584
00:39:38.915 --> 00:39:42.295
discussed since the earliest days of this before even the first spec

585
00:39:42.675 --> 00:39:47.175
by Ryan Hovar came out when he was trying to build a pay join protocol for

586
00:39:47.660 --> 00:39:48.160
bustabit.

587
00:39:48.540 --> 00:39:52.320
This is before HTTP servers, before p s b t's were even a thing.

588
00:39:53.020 --> 00:39:54.640
This was talked about, and

589
00:39:54.940 --> 00:39:58.240
it's mitigated to some extent by the receiver requiring

590
00:39:58.780 --> 00:40:00.560
a payment in order to consolidate.

591
00:40:01.115 --> 00:40:03.775
But, also, the receiver should only be consolidating

592
00:40:05.434 --> 00:40:06.174
what they

593
00:40:06.474 --> 00:40:07.295
are comfortable

594
00:40:07.595 --> 00:40:10.655
consolidating. If I'm gonna pay, BTC pay server

595
00:40:11.355 --> 00:40:11.855
and

596
00:40:12.954 --> 00:40:25.570
they have some input that they never want to consolidate, they don't want their customers to know about. They're just never gonna consolidate that. If they were gonna consolidate it otherwise because they needed to make a big payment later, because they needed to make a big transfer

597
00:40:26.030 --> 00:40:27.890
to an exchange to get some fiat,

598
00:40:28.590 --> 00:40:31.010
that's the type of input you would wanna use anyway.

599
00:40:31.635 --> 00:40:33.255
PayJoin, like I said, it doesn't

600
00:40:34.115 --> 00:40:34.615
make

601
00:40:34.915 --> 00:40:36.135
any requirements

602
00:40:36.475 --> 00:40:36.975
on

603
00:40:37.315 --> 00:40:40.135
coin selection. That's all up to the implementing wallet

604
00:40:40.595 --> 00:40:41.095
and

605
00:40:42.595 --> 00:40:43.095
is

606
00:40:43.395 --> 00:40:44.935
a problem to be solved

607
00:40:45.320 --> 00:40:51.180
unto itself. We've got a research team working on these problems too, but they're a little bit outside of the scope of

608
00:40:51.480 --> 00:40:53.580
the pay join coordination itself.

609
00:40:55.800 --> 00:40:56.940
So when you say

610
00:40:57.320 --> 00:41:07.345
require payment, the whole idea there is you you're putting a a cost to the attack. Right? So, like, they're gonna have to send you Bitcoin, and so they keep doing the attack to try know.

611
00:41:09.164 --> 00:41:11.184
Did you really lose me? I still have you.

612
00:41:14.010 --> 00:41:15.070
You don't have me?

613
00:41:19.050 --> 00:41:20.270
I still have you.

614
00:41:21.210 --> 00:41:24.910
I wish there was a way to post this to the live chat, the probing attacks paper,

615
00:41:25.850 --> 00:41:33.204
because we just came up with this. Can you There's a big Can you not hear me? Can you not hear me? Kit.org.

616
00:41:33.984 --> 00:41:34.805
Let's see.

617
00:41:39.585 --> 00:41:41.365
Yeah. I think I lost Dan.

618
00:41:41.930 --> 00:41:45.310
Live chat. Do you see me or Dan or both of us?

619
00:41:49.210 --> 00:41:49.710
Leave

620
00:41:50.090 --> 00:41:50.590
and

621
00:41:51.290 --> 00:41:52.510
come back.

622
00:42:00.945 --> 00:42:02.484
Live chat. Do you still have me?

623
00:42:04.385 --> 00:42:10.590
We got Mav twenty one zapped 10,000 sats. We have Lido zapped 2,100

624
00:42:10.590 --> 00:42:13.390
sats. We have chief white zapped 4,200

625
00:42:13.390 --> 00:42:17.230
sats, and Madaroo zapped 1,111

626
00:42:17.230 --> 00:42:17.730
sats.

627
00:42:18.430 --> 00:42:20.770
We have space bear saying we see both.

628
00:42:21.550 --> 00:42:25.730
I just thought I heard Dan rejoin, but I do not see him.

629
00:42:28.244 --> 00:42:29.865
Let's see if he's texting me.

630
00:42:36.724 --> 00:42:37.224
You

631
00:42:37.685 --> 00:42:38.185
lost

632
00:42:38.565 --> 00:42:39.065
me.

633
00:42:44.980 --> 00:42:45.480
Rejoin.

634
00:42:53.540 --> 00:42:54.760
Okay. He rejoined.

635
00:42:55.300 --> 00:42:56.119
Let's see.

636
00:42:56.515 --> 00:42:57.895
Dan, can you hear me?

637
00:43:02.195 --> 00:43:06.215
Test? I see your Internet is, like, trash. And, oh, I hear you now.

638
00:43:10.690 --> 00:43:14.710
I think it was your side, but who the hell knows? They're trying to stop the signal.

639
00:43:16.370 --> 00:43:17.010
Yeah. We can't

640
00:43:19.650 --> 00:43:20.550
I don't remember

641
00:43:21.170 --> 00:43:22.550
what we were talking about.

642
00:43:24.145 --> 00:43:25.765
Probing attacks, mitigations.

643
00:43:26.065 --> 00:43:36.405
Yeah. This problem has been around for years. It's mitigated. Basically, you require a government to receive money, and you always have that fallback broadcast. So there's a cost to you. There's a cost to it. Yes.

644
00:43:37.660 --> 00:43:38.160
Yeah.

645
00:43:38.780 --> 00:43:41.920
So that they'll run out of Bitcoin eventually if they're trying to

646
00:43:42.540 --> 00:43:43.680
figure out your

647
00:43:44.540 --> 00:43:45.040
UTXOs.

648
00:43:47.980 --> 00:43:51.440
Yeah. And if they try to make the same request, if they have this Yeah.

649
00:43:52.535 --> 00:43:56.815
Name puts you ban them. You just say, I'm not gonna I'm not gonna page one with you. Right.

650
00:43:57.255 --> 00:43:57.755
Money.

651
00:44:00.935 --> 00:44:04.555
Oh, because you have the fallback, so you can just just take the take the money.

652
00:44:09.760 --> 00:44:11.140
You mentioned multiparty

653
00:44:12.800 --> 00:44:13.700
input side

654
00:44:14.560 --> 00:44:15.060
transactions.

655
00:44:15.760 --> 00:44:21.380
Where do we stand on that? Was that a is that a six month problem? Is that a year long problem?

656
00:44:22.185 --> 00:44:22.685
When

657
00:44:23.225 --> 00:44:24.365
when when release?

658
00:44:27.465 --> 00:44:29.905
So it's launched. We just launched one that lets you do multis

659
00:44:30.345 --> 00:44:31.165
one receiver.

660
00:44:32.505 --> 00:44:33.485
It's in

661
00:44:34.505 --> 00:44:36.150
page one o dot 23.

662
00:44:36.630 --> 00:44:37.289
It's on,

663
00:44:37.910 --> 00:44:38.970
but you can use it.

664
00:44:41.510 --> 00:44:42.089
In terms

665
00:44:43.670 --> 00:44:47.450
of multiple receivers interacting, this is for, like, a year or two.

666
00:44:48.309 --> 00:44:49.049
It depends.

667
00:44:49.349 --> 00:44:50.250
So right now,

668
00:44:50.950 --> 00:44:51.609
in terms

669
00:44:53.725 --> 00:44:54.625
of implementations,

670
00:44:55.485 --> 00:44:56.625
we can be take

671
00:44:58.125 --> 00:44:59.505
off the shelf and integrated.

672
00:44:59.885 --> 00:45:06.625
But to have all the testing and make the thing work really well, it takes engineers on both teams, on our team and on the to do.

673
00:45:11.610 --> 00:45:14.810
We've got research too. I'm not sure. I'm losing connection again. Let me

674
00:45:16.730 --> 00:45:19.310
We can kinda hear you. You cut in and out a little bit.

675
00:45:32.975 --> 00:45:34.275
Yeah. They actually,

676
00:45:35.295 --> 00:45:36.755
they're where this

677
00:45:39.210 --> 00:45:40.170
It requires Do you sound

678
00:45:40.730 --> 00:45:42.030
the trickiest part.

679
00:45:46.170 --> 00:45:47.710
Try turning off your camera.

680
00:45:54.005 --> 00:45:55.865
You're all popcorn y for us.

681
00:45:58.325 --> 00:45:59.704
Well, it was a great rip.

682
00:46:03.525 --> 00:46:04.984
I think we lost him again.

683
00:46:10.990 --> 00:46:12.290
We've lost him again.

684
00:46:12.590 --> 00:46:13.570
What's up, freaks?

685
00:46:14.990 --> 00:46:18.770
You have any questions for me while we're waiting for Dan to come back in?

686
00:46:20.030 --> 00:46:21.490
Lightning q and a.

687
00:46:22.255 --> 00:46:23.395
Oh, here comes Dan.

688
00:46:25.215 --> 00:46:33.555
You told me Adam back for fifteen minutes, so I figured I'd just play with my network connection and see what I could get away with. You look clear as day now. Did you change something?

689
00:46:34.015 --> 00:46:35.555
Yeah. Change networks.

690
00:46:36.520 --> 00:46:38.940
Oh, there we go. Okay. We're back.

691
00:46:39.400 --> 00:46:40.860
Back in business, freaks.

692
00:46:42.120 --> 00:46:43.980
But we were talking about multi party.

693
00:46:45.080 --> 00:46:47.980
You said we have it under an experimental flag.

694
00:46:48.765 --> 00:47:00.704
Basically, the bottleneck is we have to you have to work you guys have to do work on your side, but then also the implementers have to do it on their side. So there's, yeah, there's there's two things that page one dev kit is working on mainly. We're doing

695
00:47:01.480 --> 00:47:05.660
Page one integrations. Like, we have to get this thing out into the world, and we have research.

696
00:47:06.600 --> 00:47:07.100
And

697
00:47:07.800 --> 00:47:08.460
right now,

698
00:47:09.160 --> 00:47:11.500
almost all of our research effort

699
00:47:11.800 --> 00:47:13.980
has been shifted over to implementation

700
00:47:14.440 --> 00:47:14.940
because

701
00:47:15.295 --> 00:47:18.435
it doesn't make sense for us to come out with this v two protocol and then just immediately

702
00:47:18.815 --> 00:47:26.835
work on, this async protocol and immediately work on the multiparty protocol, then nothing ever gets done. We have to actually prove this stuff works. So we got in Bull Bitcoin.

703
00:47:27.215 --> 00:47:30.195
We've made some proof of concept for Bolts and Liana.

704
00:47:31.530 --> 00:47:34.270
Like, we've shown this stuff works, but we need

705
00:47:34.730 --> 00:47:35.870
it's a big effort

706
00:47:36.650 --> 00:47:39.790
to get this stuff working with wallets in a way that someone

707
00:47:40.650 --> 00:47:43.070
is comfortable putting big money through.

708
00:47:43.450 --> 00:47:46.185
We've got QA now. We've got a person that's just

709
00:47:46.905 --> 00:47:48.365
shout out Ben Allen

710
00:47:48.825 --> 00:47:52.045
for chomping away at the bit there, just making sure stuff works.

711
00:47:53.065 --> 00:48:06.930
As we roll those out, we'll be able to focus more on both the multi party protocol and then the development in the kit so that anyone that's already in integrated this integrated page one dev kit can just flip a switch basically and turn on

712
00:48:07.310 --> 00:48:07.810
multiparty.

713
00:48:08.750 --> 00:48:09.650
But right now,

714
00:48:11.390 --> 00:48:13.490
yeah, we're doing the we're doing the integrations,

715
00:48:13.869 --> 00:48:16.530
and we have more people asking for the integrations

716
00:48:17.315 --> 00:48:18.695
then we can

717
00:48:19.155 --> 00:48:21.575
build quickly. That is the the biggest bottleneck.

718
00:48:22.595 --> 00:48:30.295
Got it. Okay. That makes sense. And how I didn't ask you. How is the communication handle? Is there, like, a coordination server or something? Does

719
00:48:30.950 --> 00:48:33.050
does the exchange run the coordination?

720
00:48:33.430 --> 00:48:35.050
How does that work? There's

721
00:48:35.510 --> 00:48:42.410
two servers involved. We use something called oblivious HTTP. So the async pay join spec, like I said, has these mailboxes,

722
00:48:42.965 --> 00:48:47.225
and anyone can run a directory server that has that hosts the mailboxes.

723
00:48:48.485 --> 00:48:58.265
Right now, page join dev kit hosts one, and we just came up with a way for anyone to host one to be reachable by these oblivious HTTP relays. So

724
00:48:58.720 --> 00:49:00.420
why are we using oblivious HTTP?

725
00:49:00.880 --> 00:49:04.020
Because the directory shouldn't need to know about your IP address.

726
00:49:05.200 --> 00:49:07.220
To do that, oblivious HTTP

727
00:49:08.080 --> 00:49:12.260
enforces that there's a proxy in the middle that's one of these relay servers.

728
00:49:13.464 --> 00:49:20.445
And up till this point, those have mostly been the wallet service providers. Because if you're a wallet, you probably already know your user's IP.

729
00:49:20.984 --> 00:49:28.680
You may not. Some of them, like, cake really let you dial in all the you can have your own Electrum server. You can have your own node, but not everyone does that. Sparrow

730
00:49:28.980 --> 00:49:31.720
refuses, like, Craig Raul will never run a server.

731
00:49:32.580 --> 00:49:34.120
Yeah. Yeah. So

732
00:49:35.060 --> 00:49:46.954
you can just plug in either one of these standard servers as your configuration. Well, your the oblivious HTTP servers are really the configuration. You choose who you wanna proxy to, and you can reach a directory which is defined by the receiver.

733
00:49:47.335 --> 00:49:53.515
The the the receiver says, I'm listening at this mailbox. Talk to me here. And you communicate to that through one of these proxies

734
00:49:53.815 --> 00:49:54.315
using

735
00:49:54.695 --> 00:49:56.474
o HTTP, oblivious HTTP.

736
00:49:58.270 --> 00:49:59.569
Got it.

737
00:50:00.589 --> 00:50:09.730
That makes sense. It's a web standard. Apple uses it for their private relay, so that's really where it came from. It's this it's a standard that is becoming

738
00:50:10.464 --> 00:50:13.765
ubiquitous. I mean, even it's in Firefox for oblivious HTTP,

739
00:50:16.305 --> 00:50:18.325
like, DNS over oblivious HTTP.

740
00:50:18.944 --> 00:50:23.185
It's getting all over the place. And for the end user, like, 99%

741
00:50:23.185 --> 00:50:24.885
of end users will have no idea

742
00:50:25.190 --> 00:50:31.370
that this is really how this is working in the background. That's the whole point. Yeah. Scanning a deposit address and

743
00:50:31.990 --> 00:50:32.890
pressing send.

744
00:50:33.190 --> 00:50:38.010
Yeah. It's like two hop tour. So if that directory server and the relay colluded,

745
00:50:38.630 --> 00:50:40.725
then they could match the IP address

746
00:50:41.285 --> 00:50:42.425
to the two people

747
00:50:42.725 --> 00:50:43.225
communicating.

748
00:50:43.605 --> 00:50:57.000
But, otherwise, the directory just knows it's talking to proxies, and clients just know they're talking to proxies in one directory server. They never learn each other's IP addresses, and the directory server doesn't have enough information to know that two IP addresses are talking to each other.

749
00:50:57.700 --> 00:51:00.520
And if the user wanted extra protection, they could

750
00:51:01.220 --> 00:51:04.119
use a VPN as well or a Tor. Yeah.

751
00:51:05.220 --> 00:51:07.640
Yeah. Okay. That'll make sense to me.

752
00:51:08.495 --> 00:51:16.435
It's all about raising the bar on the default. That's everything we're doing is about making the default way, the convenient way, have a minimum

753
00:51:16.975 --> 00:51:17.475
privacy.

754
00:51:18.415 --> 00:51:18.915
Right.

755
00:51:20.255 --> 00:51:22.835
What do you say to the user that maybe

756
00:51:25.640 --> 00:51:27.420
for privacy reasons only

757
00:51:27.960 --> 00:51:28.780
pays merchants

758
00:51:29.240 --> 00:51:30.940
or deposits to exchanges

759
00:51:31.240 --> 00:51:32.059
using Lightning?

760
00:51:34.440 --> 00:51:37.660
Should they keep doing that? Should they switch to pay join if their

761
00:51:37.965 --> 00:51:44.705
merchant or service supports it? How do you think about that? Doing that? It depends. Are they this is someone that's not interested in self custody?

762
00:51:47.885 --> 00:51:49.985
Why? Because you can't self custody lightning.

763
00:51:50.690 --> 00:51:57.349
Well, the thing is if you're doing lightning self custody, you probably need to move coins around from time to time. And in those cases,

764
00:51:58.049 --> 00:52:09.224
you can use pay join with the lender. Yeah. They solve different problems. I think they're Yeah. Compatible. That's everything we've built has been as a building block too. So PayJoin plugs into the existing infrastructure.

765
00:52:09.684 --> 00:52:11.785
It doesn't try to push people out of the way.

766
00:52:12.404 --> 00:52:16.825
It makes the lightning network Got it. Have more privacy because the

767
00:52:18.710 --> 00:52:20.089
analysis of the blockchain

768
00:52:20.470 --> 00:52:26.010
gives you even less data into what's going on on the Lightning Network if Page one is being used,

769
00:52:26.470 --> 00:52:29.290
if fewer assumptions can be made about what,

770
00:52:30.595 --> 00:52:31.635
what channels have

771
00:52:32.595 --> 00:52:34.455
what channels are related to what clusters.

772
00:52:38.195 --> 00:52:38.695
Right.

773
00:52:39.235 --> 00:52:43.415
Would you consider is so a lightning channel open is

774
00:52:44.000 --> 00:52:47.059
a two of two multisig between you and your channel party,

775
00:52:49.680 --> 00:52:50.500
where both

776
00:52:51.760 --> 00:53:03.175
both both parties are providing inputs to the transaction. Do you consider that already a pay join, or is that just like a semantic thing? I I think it's a semantic thing, but I don't think it hurts to think about it as a pay join. It definitely breaks

777
00:53:03.715 --> 00:53:05.015
the common input heuristic.

778
00:53:05.395 --> 00:53:05.895
Well,

779
00:53:07.555 --> 00:53:09.475
not really. Not really. Right? It's like those

780
00:53:10.035 --> 00:53:18.050
it's like two person common in Yeah. I guess the output puristic. It's like those two people have the same But the output of the channel when you close the channel, you don't know which

781
00:53:18.350 --> 00:53:21.410
output that's made came Is who. Who. Exactly.

782
00:53:21.790 --> 00:53:22.290
Yeah.

783
00:53:22.830 --> 00:53:25.090
So it does break it in that way. Yeah.

784
00:53:27.095 --> 00:53:32.234
Yeah. Like, unless you're doing active surveillance on the lightning channel Which I the best. I think it

785
00:53:33.095 --> 00:53:34.154
is is Group probing.

786
00:53:34.535 --> 00:53:39.115
Assuming that that's being done if you want any privacy guarantees. But probably isn't.

787
00:53:40.530 --> 00:53:49.110
You should assume it, but it probably isn't for most people's channels. In the inputs, you know who's participating in the channel because that's all broadcast information. Right?

788
00:53:50.610 --> 00:53:51.110
Right.

789
00:53:52.770 --> 00:53:54.530
But you don't necessarily know

790
00:53:55.745 --> 00:53:59.125
unless you're actively probing, you don't know. Balances of the channel?

791
00:53:59.985 --> 00:54:03.365
The yeah. The active balance. Yeah. That's a good point. So that that

792
00:54:03.745 --> 00:54:04.245
helps

793
00:54:05.025 --> 00:54:09.925
create that ambiguity between which inputs and outputs are connected at the end of the channel close.

794
00:54:12.359 --> 00:54:14.140
Area so I guess to the

795
00:54:14.440 --> 00:54:18.540
the next part of that question is, like, there's probably a scenario where we could have multiparty,

796
00:54:20.280 --> 00:54:24.045
like, more than two people pay joins for channel opens for Lightning too.

797
00:54:24.605 --> 00:54:32.785
Right? Yeah. Absolutely. And I think even before we get to that, there's something in terms of convenience that is a reason you might wanna use pay join. So, like,

798
00:54:33.244 --> 00:54:37.984
I'm funding a lightning channel for the first time. I have some coins on a non lightning

799
00:54:38.910 --> 00:54:40.849
wallet, I wanna put them into the,

800
00:54:41.869 --> 00:54:43.730
node with a wallet to open channels,

801
00:54:44.510 --> 00:54:59.325
I would typically have to communicate using the chain, which is annoying and leaves a fingerprint where I'd send my funds into the lightning nodes single sig wallet, and and then I would create a multiparty channel. But instead, if the two wallets can talk to each other,

802
00:55:01.385 --> 00:55:03.405
I can just send a fallback

803
00:55:03.785 --> 00:55:10.780
message to my node saying, hey. I wanna send you money. Do you wanna open any channels? And you manage both sides, so you're just gonna say, yeah. Open a channel.

804
00:55:11.080 --> 00:55:11.740
That's gonna

805
00:55:12.760 --> 00:55:18.700
construct the transaction that actually opens the channel, put it back to your wallet, say it's an exchange that supports PayJoin.

806
00:55:19.560 --> 00:55:22.380
They'll still sign because it's the same amount of money, and it's authenticated

807
00:55:22.760 --> 00:55:23.660
by the receiver.

808
00:55:24.075 --> 00:55:25.214
And then that one

809
00:55:25.915 --> 00:55:34.095
transaction funded from an external wallet can fund your channels, and it could even splice in perhaps. It it's really just a matter of sending messages

810
00:55:34.474 --> 00:55:40.780
back and forth. Adding that little bit of interaction where we can lets us build all sorts of these cut through transactions.

811
00:55:41.720 --> 00:55:45.980
Another one, like, we just proved was possible was with the Liana

812
00:55:46.520 --> 00:55:47.020
inheritance

813
00:55:47.400 --> 00:55:51.660
refresh. Do you mind if I talk about that a little bit? Let's go for it. Yeah. So

814
00:55:52.200 --> 00:55:52.700
Liana

815
00:55:54.135 --> 00:55:54.955
has this

816
00:55:55.975 --> 00:55:56.475
degrading

817
00:55:57.655 --> 00:55:58.475
time lock.

818
00:55:58.775 --> 00:55:59.655
And after the

819
00:56:00.215 --> 00:56:02.315
so your coins are in this

820
00:56:03.575 --> 00:56:07.675
in this time lock where after, say, ten years pass, then someone else

821
00:56:08.150 --> 00:56:09.610
can spend your coins.

822
00:56:10.550 --> 00:56:18.010
And the reason you would want this is, say, you die. Like, you want someone to be able to recover your coins, but you need to consistently refresh that,

823
00:56:18.950 --> 00:56:28.485
especially if you wanted someone to have the access access to the money sooner, say, like, within six months if they wanted to, you know if they had some payments to make to clean up your estate.

824
00:56:30.145 --> 00:56:33.765
So when you receive a pay join to one of these wallets,

825
00:56:35.710 --> 00:56:36.370
it can

826
00:56:36.750 --> 00:56:38.770
say, don't just create a new coin

827
00:56:39.150 --> 00:56:40.130
with this policy.

828
00:56:40.990 --> 00:56:47.010
It can spend all of the coins or some of the coins that have this policy and refresh the time lock in the same transaction

829
00:56:47.390 --> 00:56:49.755
that it receives from an outside wallet.

830
00:56:50.215 --> 00:56:56.395
So this is less privacy focused until all of this stuff is tappered and difficult to see the policies.

831
00:56:57.255 --> 00:56:58.875
But still, we at least

832
00:56:59.175 --> 00:57:03.275
that, that refresh can be an automatic user experience where every time

833
00:57:03.789 --> 00:57:04.849
that user wants

834
00:57:06.029 --> 00:57:07.410
to increase their stack,

835
00:57:08.829 --> 00:57:12.769
they're refreshing their time lock at the same time so they don't have to worry as much.

836
00:57:15.835 --> 00:57:16.655
Every time

837
00:57:17.875 --> 00:57:18.375
I'm

838
00:57:19.595 --> 00:57:24.575
adding DCA to my cold storage or whatever, it would refresh my time lock, which in Yeah.

839
00:57:25.035 --> 00:57:27.935
Otherwise, it wouldn't. Otherwise, you'd have to send another transaction.

840
00:57:28.715 --> 00:57:29.215
Right.

841
00:57:30.240 --> 00:57:31.060
That makes sense.

842
00:57:31.760 --> 00:57:36.260
And so specifically to the, I mean, I don't know how you made it this far, but

843
00:57:36.720 --> 00:57:40.660
to the, to the, to the freaks that are listening that maybe are a little bit confused

844
00:57:41.280 --> 00:57:42.580
about that Liana,

845
00:57:43.200 --> 00:57:48.475
example is it's using mini script and time locks, and you have to constantly refresh it. And the whole idea

846
00:57:49.195 --> 00:57:52.175
and just correct me if I'm wrong. The whole idea there is

847
00:57:52.475 --> 00:57:53.935
when that time lock ends,

848
00:57:54.395 --> 00:58:00.895
it goes from, like, a multi sig to a single sig, and so you can use it in, like, an inheritance type of situation where

849
00:58:01.490 --> 00:58:04.069
your air only has access to the single SIG.

850
00:58:05.010 --> 00:58:12.710
And so that your air can't rug you unless you stop refreshing your time lock because otherwise your air is in your threat model. Right?

851
00:58:13.475 --> 00:58:15.875
Yeah. Shout out to Armin Saburi and,

852
00:58:17.075 --> 00:58:22.215
Arthur for getting this out last weekend. They did this in the weekend. I have no idea. I don't know. It was nuts.

853
00:58:22.915 --> 00:58:24.595
I think I'm going to have,

854
00:58:25.900 --> 00:58:27.520
Rob Hamilton on the show

855
00:58:27.820 --> 00:58:31.920
in the coming weeks. Who's, one of the preeminent manuscript influencers,

856
00:58:33.340 --> 00:58:43.025
and cofounder of Anchor Watch, which has their Trident wallet. And I think, I mean, do you know, are there any other mini script wallets between Trident and Liana? Are those the two?

857
00:58:43.805 --> 00:58:48.945
I don't know. I know you keep pushing Rob to open source his stuff and he's really missing out.

858
00:58:49.325 --> 00:58:53.665
If he was open source, we would have done it on anchor watch. This would have already been done.

859
00:58:54.030 --> 00:58:56.530
So you heard it you heard it at the MIT,

860
00:58:57.230 --> 00:58:59.170
Bitcoin Expo in person,

861
00:59:00.670 --> 00:59:03.570
me pressuring him. What'd you think of MIT?

862
00:59:04.670 --> 00:59:07.730
That was I've been to those expos since I think 2018,

863
00:59:08.265 --> 00:59:11.404
and that was the best one. I think partnering with HRF

864
00:59:12.105 --> 00:59:13.565
to make it about FreedomTech

865
00:59:14.424 --> 00:59:18.204
completely changed the vibe, the content, people that were there.

866
00:59:19.145 --> 00:59:21.085
I I really enjoyed doing the hackathon.

867
00:59:22.530 --> 00:59:24.150
I liked when Roger

868
00:59:24.770 --> 00:59:27.350
Zingledine talked about Tor and how

869
00:59:27.650 --> 00:59:30.310
he communicates with the larger world about how,

870
00:59:30.850 --> 00:59:32.870
this is a necessary piece of infrastructure.

871
00:59:33.810 --> 00:59:38.414
Yeah. Overwhelmingly positive. I was really stoked to have that happen.

872
00:59:38.875 --> 00:59:40.095
Yeah. I was gonna say HRF

873
00:59:40.954 --> 00:59:41.454
HRF

874
00:59:41.755 --> 00:59:47.295
being the signaling mech it was HRF to me being involved was a signaling mechanism that it was gonna be,

875
00:59:47.595 --> 00:59:50.520
more high signal and worth my time coming out for it.

876
00:59:51.480 --> 01:00:06.625
And I, I couldn't agree more. I, and I mean, the, the currency initiative too. Like that's been around for a while churning research out at the same time. But in the past, in the past has been more like crypto blockchain stuff. Right. And, like, this time was, more focused on Bitcoin.

877
01:00:07.805 --> 01:00:08.305
Definitely.

878
01:00:09.005 --> 01:00:13.025
People showing me Flexa and Algorand last time I was there, I think. Yeah.

879
01:00:13.485 --> 01:00:13.805
I,

880
01:00:15.085 --> 01:00:18.865
yeah, it was a high signal group that were there. I mean, I was,

881
01:00:21.530 --> 01:00:38.595
fanboying a little bit on some of the Bitcoin I won't name names, but some of the Bitcoin developers that were there. When I saw you on stage, you were like, oh, man. I'm getting imposter syndrome speaking at MIT. What? Is so cool? Well, my mom was watching the live stream. I was I almost said, look, ma, I made it to MIT,

882
01:00:39.455 --> 01:00:44.755
because there's no shot. There's no shot I would've gotten in, when I was applying for colleges. So,

883
01:00:45.970 --> 01:00:49.030
it definitely definitely felt that way. It felt a little bit unreal.

884
01:00:49.890 --> 01:00:52.950
You know, the back the background for my,

885
01:00:54.050 --> 01:00:56.070
calling out Rob for the open source

886
01:00:56.770 --> 01:01:01.455
was I was making my deck, and I was gonna put a slide in there about

887
01:01:02.235 --> 01:01:04.415
how there's this beautiful, sustainable

888
01:01:05.755 --> 01:01:12.395
method of maintaining open source software, where you have a company like Anchor Watch, and then they have their open source,

889
01:01:13.850 --> 01:01:18.670
software stack Trident wallet that's available to the world, but then they monetize it through Lloyd's of London

890
01:01:18.970 --> 01:01:19.470
insurance.

891
01:01:20.330 --> 01:01:29.435
And, and there's, you know, it's, it's, it's beautiful because you don't have to rely on grant funding or anything else. And I'm like searching around for their license for Trident wallet.

892
01:01:29.815 --> 01:01:33.835
And I'm like, oh, this is not open source. This is just scratched it from the deck.

893
01:01:34.535 --> 01:01:38.455
But yeah, one day I think it's just an order operations thing. I think they intend to,

894
01:01:39.895 --> 01:01:41.310
fully open source it.

895
01:01:42.030 --> 01:01:45.330
Yeah. And that brings up something else, which is, like,

896
01:01:45.870 --> 01:01:52.290
why we're operating as a dev kit like BDK or Yeah. Lightning dev kit that's grant funded. I think

897
01:01:53.310 --> 01:01:55.970
we've seen that the sort of privacy wallet

898
01:01:56.655 --> 01:01:57.155
idea

899
01:01:58.095 --> 01:01:58.595
is

900
01:01:59.135 --> 01:02:00.195
dead as

901
01:02:00.815 --> 01:02:15.590
a funding source. It's too high risk and there's also this problem where all these shortcuts are made to get a product out that Right. Has military grade encryption or whatever. You just say whatever you need to secure a bag, and the incentives are not aligned to actually serve

902
01:02:16.210 --> 01:02:16.710
the

903
01:02:17.330 --> 01:02:32.065
users to bring the privacy up. And we get at these local maxima too where it's like, okay. I have the monopoly business. I'll focus on telling everyone that my thing is the best instead of fixing any further problems. Cause there's just no incentive for me to do that. And I think that's changing, which is welcome, but it's difficult.

904
01:02:33.325 --> 01:02:33.885
Yeah. I,

905
01:02:36.880 --> 01:02:43.060
yeah. I mean, we kinda saw that with both Wasabi and Samara last cycle where they're like, we've solved Bitcoin privacy.

906
01:02:43.920 --> 01:02:50.900
And it was not solved. Like, I didn't recommend that stuff to people. I wasn't like, yeah. Go use that because there's too many ways it can go wrong.

907
01:02:51.675 --> 01:02:54.175
HRF can't tell people, like, go and use

908
01:02:54.475 --> 01:02:58.575
Whirlpool. You'll be safe for sure. It's like, no. Not the case. No.

909
01:02:58.875 --> 01:03:01.455
The bigger issue is is the regulatory

910
01:03:01.835 --> 01:03:03.915
exposure of taking a cut of

911
01:03:05.780 --> 01:03:09.080
even if you're not taking custody, taking a cut of the flow of transactions

912
01:03:09.619 --> 01:03:11.880
seems to be where a lot of

913
01:03:12.500 --> 01:03:13.960
the regulatory targets

914
01:03:14.260 --> 01:03:15.480
come from. From their perspective,

915
01:03:15.780 --> 01:03:18.119
I think so. I don't know if that's actually the

916
01:03:18.740 --> 01:03:20.680
legal circumstance, but I think

917
01:03:21.225 --> 01:03:26.205
that's where the regulator gets upset because they're like, you're a person. You're making money. You shouldn't be doing this.

918
01:03:26.665 --> 01:03:31.645
Yeah. Like, clearly, you're involved because you're making money from people using the

919
01:03:31.945 --> 01:03:32.445
tool.

920
01:03:32.825 --> 01:03:39.190
Yeah. But, like, signal people are involved using signal, and we don't, like, they're not going to jail for But it's donation based.

921
01:03:41.170 --> 01:03:44.230
It's value for value. You can use it for free. WhatsApp then?

922
01:03:44.530 --> 01:03:47.030
WhatsApp has encrypted messaging. Is just spyware.

923
01:03:47.490 --> 01:03:52.485
Yeah. I mean, they're fine with that being encrypted. Like we've been able to get to the, they're getting all the metadata

924
01:03:52.785 --> 01:04:01.125
though. They're just getting all the, there, there was a handshake deal that happened there behind the scenes. It was like, yeah. You know, it's if a hunt, if 1,500,000,000

925
01:04:01.425 --> 01:04:07.890
messages are going through WhatsApp, we can let them think it's private. And they also do, like, clear text backups and stuff. Like, that's,

926
01:04:09.810 --> 01:04:17.670
WhatsApp is a dark pattern. Like, I hopefully, we don't emulate WhatsApp. I think signal is I to me, signal is one of these massive wins.

927
01:04:18.705 --> 01:04:20.645
This this successful independent

928
01:04:21.905 --> 01:04:23.125
relatively sustainable

929
01:04:23.425 --> 01:04:26.085
donation funded open source privacy project.

930
01:04:27.745 --> 01:04:32.645
I think it's harder you know, it it helped that there was, you know, a couple billionaires involved

931
01:04:34.000 --> 01:04:40.740
in making sure that it's funded. Yeah. And, I mean, some of them are the same, like I think Dorsey doesn't get enough credit.

932
01:04:41.280 --> 01:04:42.660
He took tech secure

933
01:04:44.000 --> 01:04:44.820
into Twitter

934
01:04:45.625 --> 01:04:49.485
and let them let which was the precursor to signal and then let them

935
01:04:50.025 --> 01:04:51.245
spin out signal

936
01:04:51.625 --> 01:04:56.445
as a nonprofit entity with, without, like, taking any IP or anything.

937
01:04:57.145 --> 01:05:09.790
Like, he, like, birthed it to a degree. Yeah. It takes these live player actions. Encrypted DMs. What? It takes these live player actions. Like, this stuff doesn't just happen because the incentives are set up right. Like, people actually need to make moves.

938
01:05:11.130 --> 01:05:13.550
So I heard you talking to Nifty about this. Yeah.

939
01:05:13.974 --> 01:05:16.474
Yeah. It's tricky. How do you get the model right?

940
01:05:17.494 --> 01:05:19.575
I bet there's no perfect model. It's

941
01:05:19.895 --> 01:05:20.875
I mean, it's,

942
01:05:21.335 --> 01:05:21.994
you know,

943
01:05:22.695 --> 01:05:24.875
the real world is difficult. I

944
01:05:26.799 --> 01:05:34.020
I so I'm curious. So, like, how is how is paid joint dev kit funded right now? What is your current funding situation?

945
01:05:35.520 --> 01:05:36.020
OpenSats.

946
01:05:37.119 --> 01:05:38.420
Shout out, Odell,

947
01:05:39.035 --> 01:05:40.095
and Spiral.

948
01:05:41.195 --> 01:05:42.655
I'm trying to think if we have

949
01:05:44.075 --> 01:05:48.575
income from other play. I think that's the those are the those are the two right now. So it's

950
01:05:49.355 --> 01:05:49.855
individual

951
01:05:50.475 --> 01:05:50.975
grants

952
01:05:51.800 --> 01:05:53.980
for the most part at the moment, but

953
01:05:54.440 --> 01:05:58.060
stay tuned. If you're a business who wants to see this in the world,

954
01:05:58.600 --> 01:06:05.480
get in touch. We'll make an integration happen, and we'll take this to the next level. That's what I'll say for now. So what I think is, like

955
01:06:06.515 --> 01:06:09.635
and that, by the way, that wasn't a setup. There's I like

956
01:06:10.675 --> 01:06:12.875
it's hard for me to keep track of Yeah. Yeah.

957
01:06:13.315 --> 01:06:27.329
Of of who we're actively funding and who we're not. I said to someone the other day, I was like, you know, I'm really proud that we're funding you. He's like, my grant ended, like, four months ago. Like, you guys didn't renew me or whatever. I was like, well, I did you know, I wasn't being I wasn't trying to be a dick.

958
01:06:28.510 --> 01:06:29.010
Because

959
01:06:29.390 --> 01:06:31.809
it's way bigger than me at this point. I mean,

960
01:06:32.190 --> 01:06:32.910
we have,

961
01:06:33.549 --> 01:06:36.289
Gigi himself is just a quiet warrior.

962
01:06:38.755 --> 01:06:46.295
Then we have some part time people there, but then at the end of the day, we have our nine person volunteer board, and then we have a bunch of volunteer committee members that are reviewing stuff.

963
01:06:46.995 --> 01:06:47.955
And it's just,

964
01:06:48.355 --> 01:06:49.975
it's a full time job in itself.

965
01:06:50.515 --> 01:06:57.280
I I gotta give HRF a shout out to Because Human Rights Foundation had this bounty at all last year that They're great. That we

966
01:06:57.980 --> 01:07:00.320
were able to secure with this Bold Bitcoin

967
01:07:00.620 --> 01:07:02.000
integration as a team.

968
01:07:02.300 --> 01:07:05.755
So and they've helped us from the very beginning since, like, 2021,

969
01:07:05.755 --> 01:07:07.535
I got a tiny grant to

970
01:07:07.835 --> 01:07:08.735
work on PayJoin,

971
01:07:09.275 --> 01:07:12.175
and that was before any of the dev kit existed.

972
01:07:13.515 --> 01:07:14.655
Thank you, HRF.

973
01:07:15.915 --> 01:07:16.795
Doing great work. I

974
01:07:19.480 --> 01:07:23.020
and we do a lot of cross, like, co grants with them as well.

975
01:07:23.320 --> 01:07:23.640
I,

976
01:07:24.120 --> 01:07:26.460
where I was going with it, I just got a little bit sidetracked,

977
01:07:27.000 --> 01:07:27.500
is

978
01:07:28.760 --> 01:07:29.420
I think

979
01:07:30.440 --> 01:07:36.615
an interest just talk about business on air. I or not business, open source projects on air. I think,

980
01:07:38.135 --> 01:07:40.315
the model that Cashew is doing

981
01:07:41.255 --> 01:07:47.755
is an interesting model where they spun up and BDK is doing it as well, where they basically spun up their own foundation.

982
01:07:51.200 --> 01:07:53.220
I guess BTC pay server also

983
01:07:53.599 --> 01:07:58.099
Mhmm. Where they spin up their own foundations and then they take grants into that.

984
01:07:58.400 --> 01:08:02.420
And then they take actual independent donations out of that. And then they can pay

985
01:08:03.945 --> 01:08:08.365
all these different open source contributors and they have more focus. Like, they know

986
01:08:08.745 --> 01:08:13.405
it's hard. Like, for instance, it's if if if PayJoint DevKit ends up having

987
01:08:13.705 --> 01:08:20.960
20 contributors that are focused on different aspects of the project, it's really hard for an organization like OpenSats to be able to determine,

988
01:08:22.619 --> 01:08:29.360
you know, where money needs to go and and how how best to place support. But if you have someone like

989
01:08:29.980 --> 01:08:32.239
Cali running the Open Cash

990
01:08:32.855 --> 01:08:35.835
Foundation, I think it's called, but it's called Open Cash.

991
01:08:36.215 --> 01:08:41.915
He knows where the contributors are, where support needs to happen, and you can, like, greater focus

992
01:08:42.375 --> 01:08:46.475
the donate. And I guess that's kinda what signal does too. Signal's probably a little bit more centralized.

993
01:08:48.030 --> 01:08:51.010
We have plans here. Stay tuned. Okay.

994
01:08:51.469 --> 01:08:55.409
Well, if I can be helpful at all, let me know. You already have. Awesome.

995
01:08:58.110 --> 01:08:59.985
I got nothing else. Do you have,

996
01:09:00.605 --> 01:09:03.265
do you have anything else you wanna chat about before we wrap?

997
01:09:05.165 --> 01:09:06.145
This has been great.

998
01:09:07.165 --> 01:09:10.225
This has been really good. Yeah. Thanks for having me on.

999
01:09:11.245 --> 01:09:13.265
I guess oh, yeah. One more thing.

1000
01:09:14.330 --> 01:09:21.310
So like what's, what's the next steps here? Like there's people that are listening that are like founders of companies. There's people listening

1001
01:09:21.770 --> 01:09:23.130
that are users of,

1002
01:09:23.930 --> 01:09:25.150
customers of businesses,

1003
01:09:25.450 --> 01:09:27.550
users of wallets, maintainers of wallets.

1004
01:09:27.935 --> 01:09:30.595
Like how do we, how do we get paid, joined in every wallet,

1005
01:09:31.055 --> 01:09:32.275
every, every

1006
01:09:32.655 --> 01:09:41.075
exchange? Like what, what is, what is the next steps? What do you want to see from the community? Yeah, we gotta, we gotta do these integrations. So you mentioned foundation we've got, I think,

1007
01:09:42.740 --> 01:09:43.720
four people

1008
01:09:44.340 --> 01:09:53.800
full time right now and one part time. Like, people are working on the development kit actively. We've got these integrations out. We need people to own those.

1009
01:09:54.215 --> 01:09:54.875
If you

1010
01:09:55.895 --> 01:09:59.355
are a if you want to integrate PayJo and come and say hi and

1011
01:09:59.735 --> 01:10:04.155
use the dev kit. At this point, it's got bindings. It works in Python,

1012
01:10:04.535 --> 01:10:05.835
Kotlin, Swift.

1013
01:10:06.215 --> 01:10:08.715
We just did WebAssembly, so it'll work in the browser.

1014
01:10:09.450 --> 01:10:13.070
We can adapt it for Go and c sharp pretty straightforwardly.

1015
01:10:13.370 --> 01:10:15.950
Like, we need we need hands

1016
01:10:16.489 --> 01:10:17.790
to plug those in.

1017
01:10:18.489 --> 01:10:21.230
That's the main thing. If you wanna get involved in research,

1018
01:10:21.565 --> 01:10:26.065
once a week on Fridays, we have a study club in the

1019
01:10:26.525 --> 01:10:30.065
pay join discord, which you could find at payjoindevkit.org.

1020
01:10:31.804 --> 01:10:33.344
We've got documentation

1021
01:10:33.804 --> 01:10:36.465
being written and blog posts.

1022
01:10:37.080 --> 01:10:39.580
People need to understand what's happening, but, primarily,

1023
01:10:40.120 --> 01:10:40.860
those integrations

1024
01:10:41.400 --> 01:10:42.780
need to happen. And

1025
01:10:43.640 --> 01:10:44.140
with

1026
01:10:44.760 --> 01:10:51.240
the if you're a commercial entity, if you're an exchange, that is probably where the biggest impact can be made. If you can get

1027
01:10:52.305 --> 01:10:57.365
if your exchange supports this, you can do the cut through, you can get the savings, and you can protect the privacy

1028
01:10:57.905 --> 01:10:58.885
of your users.

1029
01:11:00.545 --> 01:11:05.905
Awesome. You said if someone wants to integrate, they should come say hi. Is that payjoindevkit.com?

1030
01:11:05.905 --> 01:11:10.760
Or how do they send that? .Org. Yep. Or github.com/payjoin

1031
01:11:10.760 --> 01:11:11.820
is where we are.

1032
01:11:12.199 --> 01:11:13.260
That would be the thing.

1033
01:11:13.880 --> 01:11:16.380
Because my my contact at bitgool dot com.

1034
01:11:17.719 --> 01:11:22.860
Love it. I'll put all those links in the show notes. Dan, thank you for joining us. I think, you know, maybe

1035
01:11:23.885 --> 01:11:25.745
six months to a year, we'll do

1036
01:11:26.125 --> 01:11:37.345
a, pull you back on and see where we're standing and do an update and just keep pushing. How do you think about that? Awesome. Well, thank you for joining us freaks. Thanks for joining us in the live chat. You make it special.

1037
01:11:37.860 --> 01:11:39.880
Appreciate you all for supporting the show.

1038
01:11:41.460 --> 01:11:45.800
I'm not sure when the next show will be, but if, if you keep track on Noster,

1039
01:11:46.500 --> 01:11:48.440
I'll keep you guys updated. We got some

1040
01:11:49.055 --> 01:11:52.115
good conversations in the works, but love you all. Stay humble.

1041
01:11:52.655 --> 01:11:53.155
Thanks.