CD123: PHOENIX WALLET AND SERVER WITH CEO PIERRE

Transcript

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 4/2/2024 7:50:51 PM
Duration: 4846.080
Channels: 1

1
00:00:02.480 --> 00:00:04.240
You say gold was in a,

2
00:00:04.720 --> 00:00:05.220
consolidation

3
00:00:05.520 --> 00:00:07.700
phase for the years? Multi years.

4
00:00:08.055 --> 00:00:14.555
You know, multi year. Yeah. Something close to that. So what could where where could we go? Yeah. You know, the breakout above that 2063

5
00:00:15.094 --> 00:00:19.080
threshold was a big deal for us, and it allowed us to arrive at an objective

6
00:00:19.780 --> 00:00:24.840
intermediate term of about 22.80, that's not too far off, but longer term of about 25100

7
00:00:25.140 --> 00:00:29.365
for the price of gold. Think it'll be sort of a slow moving ship that direction,

8
00:00:30.065 --> 00:00:46.745
but the momentum is there. And even right now, as of yesterday, we have what looks like we call it a flag breakout on the charts. It's when you have a sharp up move, consolidation, and then a a short term breakout. So In a similar vein, I guess, if you believe it if you believe that it's digital property,

9
00:00:47.524 --> 00:00:57.750
Bitcoin is also NA for for an upside objective. Isn't that true. Yeah. New all time highs. That's what happens. And, I mean, I believe in the uptrend at least. It it has very good momentum.

10
00:00:58.370 --> 00:01:05.075
The pullback that we saw, it looks like nothing on the chart. It's pretty remarkable because it was 17, 18 percent of downside,

11
00:01:05.375 --> 00:01:08.435
but it looks like a lift. Nothing for you. It is. It really is.

12
00:01:08.815 --> 00:01:12.755
And, now, of course, within, like, you know, days, we've had a resumption

13
00:01:13.329 --> 00:01:26.094
higher. So I feel pretty good about the trend there as well. The breakout creates a a long term catalyst for Bitcoin too. It's always going to be higher beta, you know, the spread to the 50 day moving average. I looked at it this morning. It was something like 13, 14%

14
00:01:26.954 --> 00:01:30.975
versus the S and P, which is about 4%. So those are initial support readings.

15
00:01:31.500 --> 00:01:35.360
But that's just the risk that you take by Commodities in

16
00:02:08.050 --> 00:02:13.270
Happy Bitcoin Tuesday, freaks. It's your host, Odell, here for another Citadel Dispatch,

17
00:02:13.785 --> 00:02:14.525
the interactive

18
00:02:14.825 --> 00:02:19.405
live show focused on actionable Bitcoin and Freedom Tech discussion.

19
00:02:20.425 --> 00:02:24.920
That clip in the beginning has absolutely nothing to do with the chat we're gonna have today.

20
00:02:26.100 --> 00:02:33.704
I just thought it was kinda funny having a suit on CNBC doing Bitcoin TA. Every suit is now a Bitcoin influencer.

21
00:02:34.245 --> 00:02:39.840
I have a great chat, lined up for us. We have, Pierre here. Who's this?

22
00:02:40.140 --> 00:02:41.359
How's it going, Pierre?

23
00:02:41.659 --> 00:02:43.519
He is the CEO of Async,

24
00:02:44.465 --> 00:02:46.004
which is the company behind

25
00:02:46.944 --> 00:02:48.805
the Async lightning implementation.

26
00:02:49.345 --> 00:02:53.109
He's behind Phoenix Wallet and recently Phoenix Server.

27
00:02:54.609 --> 00:02:58.549
This is awesome. I I I just wanna start off the conversation by saying, Pierre,

28
00:02:59.185 --> 00:03:02.805
thank you for what you and your team have been building. I mean, Phoenix Wallet

29
00:03:03.265 --> 00:03:04.084
is absolutely

30
00:03:04.385 --> 00:03:04.885
amazing.

31
00:03:05.265 --> 00:03:07.045
It's incredibly easy to use.

32
00:03:07.620 --> 00:03:10.340
It's the main wallet I onboard people with now,

33
00:03:10.660 --> 00:03:14.520
if they're just getting started with Bitcoin and they wanna make payments very easily.

34
00:03:15.380 --> 00:03:16.295
So thank you.

35
00:03:16.775 --> 00:03:18.235
Thanks for having me. Yeah.

36
00:03:19.334 --> 00:03:19.834
Well,

37
00:03:21.095 --> 00:03:23.355
we see Phoenix as a demonstrator of what

38
00:03:23.930 --> 00:03:26.110
what Lightning can offer. So,

39
00:03:28.330 --> 00:03:33.445
I like to think that what you see in Phoenix, you will be able to see that in many other

40
00:03:33.745 --> 00:03:34.245
implementations

41
00:03:34.705 --> 00:03:35.525
in the future.

42
00:03:35.985 --> 00:03:38.485
Maybe done better, maybe a little bit different.

43
00:03:39.050 --> 00:03:44.830
So it's like when we started phonics, it was the world of the future. We meant it as

44
00:03:45.130 --> 00:03:45.790
we're gonna

45
00:03:46.330 --> 00:03:47.069
try out

46
00:03:47.745 --> 00:03:48.405
the latest,

47
00:03:49.025 --> 00:03:51.365
of what you can do with lightning. And

48
00:03:52.305 --> 00:03:57.285
so it's it's a very it's a very good project to to work on. I'm I'm glad you like it.

49
00:03:58.120 --> 00:03:59.180
Yeah. I mean

50
00:03:59.879 --> 00:04:04.780
so, I mean, there's a lot of there's a lot of places we can go here. Yes. I think,

51
00:04:06.095 --> 00:04:09.715
first off, like, I I think it's really cool. So there's there's,

52
00:04:10.974 --> 00:04:12.435
there's 3 main,

53
00:04:13.295 --> 00:04:14.275
lightning implementations.

54
00:04:15.250 --> 00:04:18.470
Right? There's lnd there's 4, I guess. There's lnd.

55
00:04:18.930 --> 00:04:20.470
There's core lightning.

56
00:04:21.250 --> 00:04:22.230
There's LDK,

57
00:04:22.784 --> 00:04:25.044
and then there's async. And async,

58
00:04:25.345 --> 00:04:26.004
you guys,

59
00:04:27.264 --> 00:04:34.240
are are a little bit unique in the lightning implementation space because you're actually building out this lightning implementation

60
00:04:35.340 --> 00:04:42.815
purpose built for powering Phoenix Wallet. So how do you think about that, you know, when you when you think about what you're building compared to

61
00:04:43.514 --> 00:04:50.310
what many of the other Lightning developers are building out in the space? Yeah. We have 2, actually. We have 2 separate Lightning implementations,

62
00:04:51.730 --> 00:04:52.790
little known fact.

63
00:04:53.250 --> 00:04:57.285
The first one is Eclair, which is the one we started working on in 2015,

64
00:05:00.625 --> 00:05:02.085
and the goal of Eclair

65
00:05:02.790 --> 00:05:06.169
was to power large scale routing node.

66
00:05:06.790 --> 00:05:09.770
Because since the beginning, we were convinced that

67
00:05:11.044 --> 00:05:12.405
we didn't really believe in,

68
00:05:12.965 --> 00:05:14.264
everybody running

69
00:05:14.724 --> 00:05:16.664
a small writing at home

70
00:05:17.365 --> 00:05:19.305
for obvious reasons related to

71
00:05:20.419 --> 00:05:23.560
liquidity and security management and a lot of stuff.

72
00:05:23.940 --> 00:05:28.535
So we don't think it made sense economically to run a small,

73
00:05:29.074 --> 00:05:30.134
routing node.

74
00:05:30.675 --> 00:05:33.175
So since the the very first

75
00:05:34.990 --> 00:05:38.050
commit on a eclair, it was designed to handle

76
00:05:38.830 --> 00:05:39.890
a lot of channels

77
00:05:40.270 --> 00:05:42.705
to be maybe not very,

78
00:05:43.565 --> 00:05:45.105
maybe not with a lot of features,

79
00:05:45.645 --> 00:05:46.685
maybe not with the,

80
00:05:48.205 --> 00:05:49.985
all the bells and whistles,

81
00:05:50.930 --> 00:05:52.229
No fancy interface

82
00:05:52.530 --> 00:05:53.430
and all that,

83
00:05:53.970 --> 00:05:54.470
but

84
00:05:55.010 --> 00:05:55.830
very reliable,

85
00:05:56.370 --> 00:05:58.150
very scalable and

86
00:06:00.685 --> 00:06:01.425
and that's

87
00:06:01.965 --> 00:06:03.185
the, if

88
00:06:04.845 --> 00:06:05.665
if I would,

89
00:06:06.340 --> 00:06:08.520
if if you wanted to character characterize,

90
00:06:09.140 --> 00:06:10.520
our implementation compared

91
00:06:12.260 --> 00:06:12.920
to c

92
00:06:13.460 --> 00:06:14.360
lightning, LND,

93
00:06:15.275 --> 00:06:16.415
that would be it.

94
00:06:16.955 --> 00:06:19.935
And, so we did this between 2015 and 2018,

95
00:06:20.715 --> 00:06:21.375
I think.

96
00:06:23.410 --> 00:06:29.030
And at that point, we realized that it was quite easy to make this software run on Android.

97
00:06:29.410 --> 00:06:31.590
That's when Eclair Mobile started.

98
00:06:32.544 --> 00:06:34.485
And, Eklamaobile is

99
00:06:35.505 --> 00:06:36.965
the ancestor of Phoenix.

100
00:06:37.985 --> 00:06:39.845
But then we wanted to

101
00:06:41.700 --> 00:06:44.360
to have this wallet run on iOS 2.

102
00:06:44.980 --> 00:06:50.915
And at this point, we make a we we created a new implementation from scratch. So it's

103
00:06:51.294 --> 00:06:54.355
inspired from Eclair, but it's it's a separate implementation.

104
00:06:55.215 --> 00:06:56.835
It's in it's written in Kotlin.

105
00:06:57.370 --> 00:06:57.810
And,

106
00:06:58.250 --> 00:06:59.390
and this one is

107
00:07:00.490 --> 00:07:01.550
focused on

108
00:07:02.170 --> 00:07:03.070
very lightweight,

109
00:07:03.450 --> 00:07:05.150
very, lightweight implementation,

110
00:07:06.544 --> 00:07:10.324
workforce efficient. It does not scale to a 100000 channels,

111
00:07:10.865 --> 00:07:11.264
but,

112
00:07:12.225 --> 00:07:16.350
but it's very portable. You run it on Android, you can run it on iOS.

113
00:07:16.889 --> 00:07:21.389
And it turns out you can also run it on a server, which is what we did with Phoenix.

114
00:07:21.770 --> 00:07:23.310
So we already have 2 implementations,

115
00:07:24.995 --> 00:07:25.735
each with

116
00:07:26.115 --> 00:07:26.935
their characteristics.

117
00:07:28.595 --> 00:07:29.095
And

118
00:07:31.979 --> 00:07:32.720
and we,

119
00:07:35.419 --> 00:07:35.919
like,

120
00:07:36.539 --> 00:07:39.759
if you take a look at at what we worked on since, we started,

121
00:07:40.699 --> 00:07:41.440
we have

122
00:07:42.205 --> 00:07:43.485
basically never changed,

123
00:07:43.885 --> 00:07:44.945
direction and and,

124
00:07:45.805 --> 00:07:52.080
like, have always followed the linear path. And so everything, like, every pieces that we put together,

125
00:07:53.180 --> 00:07:55.840
was towards this goal, which is why sometimes,

126
00:07:56.700 --> 00:07:58.400
like, from the outside, you could wonder

127
00:07:58.700 --> 00:08:03.965
why do they, you know, spend the time and energy building aclare? Why don't they use another implementations?

128
00:08:05.705 --> 00:08:07.785
Well, the reason is that we had to

129
00:08:09.530 --> 00:08:13.470
it was purpose built for what we have what we had in mind. And

130
00:08:14.410 --> 00:08:15.390
we didn't want

131
00:08:16.410 --> 00:08:17.790
to to depend on

132
00:08:18.285 --> 00:08:19.825
other teams to build it.

133
00:08:21.805 --> 00:08:27.585
I'm just trying to, you know, I'm going a little bit besides the the original point, but to explain

134
00:08:28.509 --> 00:08:31.810
why we do what what we do and why we do it that way.

135
00:08:33.070 --> 00:08:37.795
Is that when you work on a technology like lightning, which is evolving very fast,

136
00:08:38.834 --> 00:08:39.334
and

137
00:08:39.795 --> 00:08:41.894
you you won't want to to depend

138
00:08:42.915 --> 00:08:43.654
on the upstream,

139
00:08:45.555 --> 00:08:46.055
implementers

140
00:08:46.750 --> 00:08:47.250
because

141
00:08:48.510 --> 00:08:51.410
if if you're stuck behind someone developing,

142
00:08:53.230 --> 00:09:00.575
some feature that you need, then you're gonna have a hard time. You're gonna have to wait. It's gonna be frustrating. Maybe they're gonna have different priorities and all that.

143
00:09:01.195 --> 00:09:06.960
Our approach and with specificity of our approach is that we control the whole stack.

144
00:09:07.340 --> 00:09:09.520
Right. Even before the implementation,

145
00:09:09.900 --> 00:09:11.920
like, down to the protocol design.

146
00:09:12.425 --> 00:09:15.245
And this allows us to move very fast.

147
00:09:16.665 --> 00:09:18.525
But it means that we have to

148
00:09:19.065 --> 00:09:19.885
work on

149
00:09:20.450 --> 00:09:21.670
all the different pieces,

150
00:09:22.130 --> 00:09:22.950
that we need.

151
00:09:23.330 --> 00:09:30.254
Right. I mean, I think that's key that's key to a lot of your success and key to one of the reasons that the UX is

152
00:09:30.875 --> 00:09:35.930
is so much better than so many other self custody lightning wallets in the space.

153
00:09:37.050 --> 00:09:42.190
And a perfect example of that is, like so, like, if you're an end user. Right? If you're an end user and,

154
00:09:42.970 --> 00:09:48.214
maybe you're new to Bitcoin. You're you're new to Bitcoin, and you you launch Phoenix Wallet for the first time,

155
00:09:48.915 --> 00:09:55.430
and and you buy some Bitcoin or you receive Bitcoin from a friend, and you receive that payment as an on chain payment,

156
00:09:56.690 --> 00:10:01.750
Phoenix is immediately creating a lightning channel for you. And then if you if you

157
00:10:02.524 --> 00:10:05.425
receive more money on chain going forward,

158
00:10:06.125 --> 00:10:13.810
that that payment is that on chain payment is automatically then spliced into your existing lightning channel. And I believe in practice,

159
00:10:14.190 --> 00:10:22.685
it's it's the only it's the only mobile self custody wallet that supports splicing right now, and because you guys control the entire stack. Yeah. Well,

160
00:10:23.945 --> 00:10:27.005
it's also be you know, there are there are different kind of features,

161
00:10:27.945 --> 00:10:28.265
and

162
00:10:29.170 --> 00:10:30.550
but features like splicing,

163
00:10:31.410 --> 00:10:32.710
they only operate

164
00:10:33.490 --> 00:10:38.470
at the peer level, which means that if we control both the mobile and the

165
00:10:39.115 --> 00:10:40.735
routing node, then we can,

166
00:10:43.115 --> 00:10:44.335
we we can do stuff.

167
00:10:45.035 --> 00:10:46.175
Some other features,

168
00:10:47.355 --> 00:10:48.095
for example,

169
00:10:48.880 --> 00:10:51.140
privacy features, network wide features,

170
00:10:51.680 --> 00:10:58.565
we need to wait for the protocol to be mature enough. That's why that's why it takes more time. It's not that it's less prioritized.

171
00:10:59.024 --> 00:11:03.925
It's just that it's much more difficult to to to deploy because, we depend on others.

172
00:11:04.305 --> 00:11:04.625
And,

173
00:11:05.265 --> 00:11:07.170
and that's more difficult. It takes more time.

174
00:11:08.050 --> 00:11:14.230
But, yeah. So am I correct that so so when when you're using Phoenix Wallet, right, there's

175
00:11:14.904 --> 00:11:15.404
there's

176
00:11:15.705 --> 00:11:23.084
one implementation's running on the phone, and then the routing the routing node is running a clear? Yep. So it's actually 2 different implementations.

177
00:11:23.625 --> 00:11:24.125
Yes.

178
00:11:24.550 --> 00:11:27.690
They they they share some similarities because of the same people

179
00:11:28.070 --> 00:11:29.370
worked on them. Right.

180
00:11:31.350 --> 00:11:32.649
But but they are different.

181
00:11:33.255 --> 00:11:39.515
So, basically, that means that when we ship something like splicing, we actually implement it twice.

182
00:11:41.800 --> 00:11:48.060
One more complete part on, eclair and the more specific limited part on, on

183
00:11:49.315 --> 00:11:53.735
the library that underpins Phoenix, which is called lightning k a m p.

184
00:11:55.075 --> 00:11:55.575
So

185
00:11:56.274 --> 00:11:57.870
that's how it works. Yeah.

186
00:11:58.589 --> 00:11:59.650
Okay. So let's,

187
00:12:00.670 --> 00:12:03.410
for the sake of this conversation, let's start with the wallet,

188
00:12:04.670 --> 00:12:07.730
and then we can talk about we can go deeper on the implementations

189
00:12:08.175 --> 00:12:12.274
and, like and how how you're how you're thinking about protocol development.

190
00:12:12.975 --> 00:12:22.420
And we can talk about Phoenix Server. I think Phoenix Server is is absolutely massive, and it's it's relatively new newly announced. It was announced last week. People seem to like it. We will

191
00:12:23.540 --> 00:12:31.755
I'm I'm really looking forward to see what, what is going to be built on top of it. But let's start with the wallet. Let's start with the wallet. Sure. One one of the things I like about

192
00:12:32.135 --> 00:12:33.995
you guys is your website

193
00:12:35.220 --> 00:12:39.320
is is is very clear on, like, the trade offs you make with the wallet.

194
00:12:40.100 --> 00:12:42.440
You don't try and, like, hide things from the users.

195
00:12:42.985 --> 00:12:46.605
You you make you make specific trade offs, and and you do it intentionally.

196
00:12:47.785 --> 00:12:52.620
And and so so when you're talking when you're thinking about the actual Phoenix Wallet,

197
00:12:53.020 --> 00:12:53.920
Phoenix Wallet

198
00:12:55.339 --> 00:12:56.800
at red by default,

199
00:12:57.260 --> 00:13:01.920
all your funds are in a essentially a single lightning channel. Yeah.

200
00:13:02.685 --> 00:13:03.584
Do you think

201
00:13:04.204 --> 00:13:09.824
so? So if a user wants to make if a user wants to make a a on chain payment,

202
00:13:10.125 --> 00:13:10.945
they're actually

203
00:13:12.090 --> 00:13:15.550
doing a swap to pull it out of out of the lightning channel. Correct?

204
00:13:17.690 --> 00:13:18.750
Yes. But,

205
00:13:19.315 --> 00:13:20.135
you know, since

206
00:13:21.715 --> 00:13:25.015
the the splicing update, it has been a major change in

207
00:13:27.540 --> 00:13:28.280
in how

208
00:13:29.220 --> 00:13:29.960
we see

209
00:13:30.340 --> 00:13:33.080
on chain and off chain, because before splicing,

210
00:13:33.944 --> 00:13:35.324
like, you would be either

211
00:13:36.024 --> 00:13:37.964
on chain or on Lightning.

212
00:13:40.024 --> 00:13:41.725
And it was kind of fixed and

213
00:13:43.940 --> 00:13:44.760
really separate.

214
00:13:45.220 --> 00:13:46.280
But with splicing,

215
00:13:47.780 --> 00:13:54.005
the the difference between the these two layers, it's it's really, really thin, which means that you can actually spend

216
00:13:55.505 --> 00:14:00.085
a channel is just a UTXO. Right? It's a UTXO, an unspent transaction output.

217
00:14:01.190 --> 00:14:05.050
And it's it can be spent by a transaction that

218
00:14:06.470 --> 00:14:14.065
gives some funds to the LSP us and some funds to you, and this transaction is left unpublished. That's what the channel is. It's just a UTXO.

219
00:14:14.605 --> 00:14:15.105
Right.

220
00:14:16.525 --> 00:14:17.965
But you can spend this,

221
00:14:18.445 --> 00:14:25.330
UTXO directly when you in Phoenix. It's just gonna create a new channel at the same time.

222
00:14:25.710 --> 00:14:30.805
So you're not really, like yes. Logically, you're swapping funds, but you're actually spending

223
00:14:31.185 --> 00:14:33.524
the same Bitcoins that are in your channel.

224
00:14:34.064 --> 00:14:35.845
It is the same. And

225
00:14:36.464 --> 00:14:42.170
It's still just one Bitcoin payment now that splicing exists. It used to be 2 Bitcoin payments, basically. Right?

226
00:14:43.110 --> 00:14:46.855
No. In the previous version of Phoenix, it was simply trusted. You would send us.

227
00:14:47.574 --> 00:14:53.755
You would pay us over lightning, and we would make the swap. It was trusted. It was very basic, extremely basic. It was,

228
00:14:55.250 --> 00:14:55.890
it was,

229
00:14:56.610 --> 00:14:59.110
like, quite primitive, really. And,

230
00:14:59.810 --> 00:15:04.215
so in this, with splicing, you just span your outputs

231
00:15:04.755 --> 00:15:05.075
and,

232
00:15:05.715 --> 00:15:08.055
create a new channel at the same time. And

233
00:15:09.075 --> 00:15:09.575
but

234
00:15:10.115 --> 00:15:14.460
the thing is, I don't I don't know if you remember, but a few years back,

235
00:15:15.320 --> 00:15:16.380
there were a lot of

236
00:15:17.960 --> 00:15:19.980
ideas putting forward and

237
00:15:20.904 --> 00:15:23.404
people were imagining what lightning could become.

238
00:15:24.185 --> 00:15:26.365
A lot of them were unrealistic turns out,

239
00:15:26.824 --> 00:15:27.324
but

240
00:15:27.625 --> 00:15:29.404
some of them one of them was

241
00:15:30.200 --> 00:15:30.700
every

242
00:15:31.560 --> 00:15:34.140
unchained transaction will be a lightning channel.

243
00:15:34.840 --> 00:15:35.900
And at that time,

244
00:15:36.935 --> 00:15:42.875
most of this idea that we are floating around, I was I was like, no. It's totally it's not gonna happen. It's totally unrealistic.

245
00:15:43.255 --> 00:15:45.750
This one, I was also thinking,

246
00:15:46.210 --> 00:15:47.410
that sounds a little bit,

247
00:15:48.930 --> 00:15:49.430
unreasonable,

248
00:15:50.050 --> 00:15:50.550
but

249
00:15:50.930 --> 00:15:54.425
it done that. It's ex exactly what splicing is. When you

250
00:15:55.225 --> 00:15:55.884
with splicing,

251
00:15:56.745 --> 00:15:58.045
you create a new channel

252
00:15:58.560 --> 00:16:07.940
with every transaction that you make. And there is no, basically no overhead when you do an on chain payment versus a lightning payment. So

253
00:16:08.355 --> 00:16:17.850
it's you could even describe Phoenix as an an on chain wallet with a single UTXO, so all your funds are always consolidated. That's a trigger that we we could address.

254
00:16:18.390 --> 00:16:20.490
Right. But, basically, you could see it as,

255
00:16:21.910 --> 00:16:25.210
an on share wallet with the option to spend your funds over lightning.

256
00:16:28.264 --> 00:16:30.685
It's it's, it will be a fair characterization.

257
00:16:33.780 --> 00:16:37.000
Yeah. No. I mean, once you once you added splicing,

258
00:16:37.460 --> 00:16:43.154
it really changed the game. I mean, in terms of fee burden too, it it really changed the game. Yeah. Yeah.

259
00:16:43.615 --> 00:16:46.355
Okay. So let's let's talk about the trade offs a little bit.

260
00:16:47.855 --> 00:16:50.835
The the first thing I wanna talk about is

261
00:16:52.800 --> 00:16:56.100
how how you think about on chain fees. We recently had,

262
00:16:58.000 --> 00:17:01.060
on chain fees spike with with the different inscription,

263
00:17:02.755 --> 00:17:03.575
pressure and

264
00:17:04.115 --> 00:17:04.615
and,

265
00:17:04.915 --> 00:17:05.975
you know, mempools

266
00:17:06.435 --> 00:17:10.320
filled up, and and and we had on chain fees go up high.

267
00:17:10.880 --> 00:17:12.019
And as a result,

268
00:17:13.600 --> 00:17:18.100
your users specifically, I I assume your support request went up tremendously.

269
00:17:18.815 --> 00:17:22.355
And there's, like, new settings now in the wallet in terms of

270
00:17:23.135 --> 00:17:28.515
maximum fee and stuff like that. How do you how do you think about that? I mean, this is obviously a

271
00:17:30.640 --> 00:17:33.460
as someone who onboards a lot of people to Bitcoin,

272
00:17:34.240 --> 00:17:36.420
it's a hard thing for me to

273
00:17:36.880 --> 00:17:38.500
translate to a new user.

274
00:17:39.425 --> 00:17:46.085
That, you know, when they receive their first payment, the Lightning channel needs to be open. They're gonna pay an on chain fee. And then going forward,

275
00:17:46.919 --> 00:17:49.820
if they're if they're if they're paying via lightning,

276
00:17:50.200 --> 00:17:52.299
they're gonna have a much lower fee.

277
00:17:52.919 --> 00:18:01.985
If they pay via on chain, they're going to have a much higher fee. If they don't have inbound liquidity, inbound liquidity is another piece there. Then they're going to have to do another on chain transaction.

278
00:18:02.285 --> 00:18:06.870
Yeah. Increased. How do you think about this? I mean, it's not an easy problem.

279
00:18:07.250 --> 00:18:09.750
No. It it's definitely not easy. So

280
00:18:10.210 --> 00:18:11.509
the first thing is,

281
00:18:13.925 --> 00:18:15.625
so during the past

282
00:18:16.805 --> 00:18:17.945
6, 9 months,

283
00:18:18.565 --> 00:18:21.225
the fees have have been very volatile.

284
00:18:21.759 --> 00:18:23.779
And so it it creates issues,

285
00:18:24.799 --> 00:18:25.299
but

286
00:18:25.679 --> 00:18:28.000
it's also another an environment for which,

287
00:18:28.720 --> 00:18:30.740
which is pretty positive for our service.

288
00:18:32.235 --> 00:18:33.295
You know, there are

289
00:18:33.675 --> 00:18:35.295
22 situations where,

290
00:18:36.795 --> 00:18:38.895
as a Lightning Wallet, you're gonna have trouble

291
00:18:40.590 --> 00:18:43.250
expanding your, your value to users

292
00:18:43.710 --> 00:18:44.690
as an LSP

293
00:18:45.150 --> 00:18:47.410
is if the fees are always

294
00:18:48.030 --> 00:18:48.850
very low,

295
00:18:49.335 --> 00:18:51.435
which is why during the

296
00:18:51.895 --> 00:18:52.715
past years,

297
00:18:54.055 --> 00:18:54.555
Moon

298
00:18:54.855 --> 00:19:00.940
Moon Wallet was a very attractive choice. Right. Because we because why not? When it's very cheap, it seems simpler.

299
00:19:02.200 --> 00:19:05.500
The other situation is when fees are always very high.

300
00:19:06.105 --> 00:19:08.825
And then it's a problem for for the LSP because,

301
00:19:10.665 --> 00:19:13.485
everything is is, more expensive all the time.

302
00:19:15.169 --> 00:19:18.309
The intermediate situation where we are, we have been,

303
00:19:18.610 --> 00:19:23.350
in the past months is actually the one which is the most favorable for our business because

304
00:19:24.085 --> 00:19:25.385
when when fees are volatile,

305
00:19:26.005 --> 00:19:28.265
the service that we offer to the users

306
00:19:28.565 --> 00:19:29.465
is just to,

307
00:19:30.005 --> 00:19:30.505
like,

308
00:19:31.290 --> 00:19:32.169
absorb this,

309
00:19:32.650 --> 00:19:34.510
volatility by offering liquidity.

310
00:19:34.970 --> 00:19:40.190
So it's not a bad thing for us. It's it's hard to explain and to guide users,

311
00:19:42.775 --> 00:19:44.555
for them to navigate this environment,

312
00:19:45.015 --> 00:19:46.475
but it's actually

313
00:19:47.335 --> 00:19:48.600
the situation that is

314
00:19:49.320 --> 00:19:52.220
the more the most positive for, an LSP.

315
00:19:52.840 --> 00:19:59.875
I don't know if that makes sense, but so it allows us basically to to tell users, okay, you're gonna have one mining fee.

316
00:20:00.255 --> 00:20:00.915
If you manage

317
00:20:02.175 --> 00:20:05.600
your requite, you're right, you're gonna save a lot of

318
00:20:06.160 --> 00:20:07.059
ancient transactions.

319
00:20:08.000 --> 00:20:14.900
And then on our side, if the money fees are volatile, that it means that sometime in the future, maybe in a few months,

320
00:20:15.865 --> 00:20:24.010
the fees are going to be low and then we can claim back, unused liquidity. So it's essential that that fees don't stay consistently

321
00:20:24.390 --> 00:20:26.810
low or consist consistently high.

322
00:20:27.350 --> 00:20:27.850
My

323
00:20:28.390 --> 00:20:30.170
my my gut feeling is that

324
00:20:30.835 --> 00:20:34.535
this is going to be like that in the future. A little bit like the price. It's always volatile.

325
00:20:35.635 --> 00:20:39.175
But you don't think we're gonna be consistently high in the future. Right?

326
00:20:39.590 --> 00:20:42.650
I don't think so. I mean, I still think it'll be volatile.

327
00:20:43.030 --> 00:20:51.355
Yeah. It's gonna be volatile. It's a free market. It's a truly free market. So free markets are volatile. Yeah. Exactly. Exactly. But higher than

328
00:20:51.815 --> 00:20:52.555
the current

329
00:20:53.175 --> 00:20:54.575
volatile free market

330
00:20:55.015 --> 00:21:01.500
Yes. In my opinion. Like, 8 like, right now, we're looking we have mempool dot I always have mempool dot space up during the live streams.

331
00:21:01.960 --> 00:21:05.020
And, like, next block fee is 19 sats per byte.

332
00:21:05.640 --> 00:21:19.320
Like, we could be in a situation where instead of it ranging from a 100 sats per byte to 5 sats per byte, it's ranging from 400 sats to byte to a 100 sats per byte, something like that. You know? Yeah. It's it could

333
00:21:22.100 --> 00:21:23.640
be. But the thing is

334
00:21:24.179 --> 00:21:25.240
as long as

335
00:21:26.175 --> 00:21:28.195
every now and then the fees go down,

336
00:21:28.575 --> 00:21:30.115
then it's good for us.

337
00:21:31.775 --> 00:21:37.790
And if they if every now and then it goes high, then it gives a very good reasons for users to to,

338
00:21:39.150 --> 00:21:41.970
to use a word like Phoenix or any other liking wallet.

339
00:21:42.375 --> 00:21:44.155
And, you know what's funny is that,

340
00:21:45.575 --> 00:21:46.855
so on one hand,

341
00:21:47.575 --> 00:21:51.920
during, at the end of the previous year, we were busy migrating our users

342
00:21:52.480 --> 00:21:59.140
from the previous version of Phoenix. So Right. Yeah. We had to pay for those fees. So on one hand, it was not very nice, but on the other hand,

343
00:21:59.600 --> 00:22:00.045
it

344
00:22:01.005 --> 00:22:01.745
it showcased,

345
00:22:03.245 --> 00:22:06.465
the, advantage of being relating to a lot of user.

346
00:22:06.925 --> 00:22:09.265
And one funny thing too is,

347
00:22:09.920 --> 00:22:13.700
you know, so it's a small team at AC. We're just 10 people.

348
00:22:14.560 --> 00:22:19.804
Amazing. It's amazing what you guys have built with such small team. And we're doing everything including the support,

349
00:22:20.585 --> 00:22:26.684
which means that first, we are very well aware of the issues that our users have because we we do it directly.

350
00:22:27.880 --> 00:22:39.475
And most of the customer support that we had to do, at the end of, previous year was not related to Lightning. It's actually related to people having trouble with block time and confirmation time. Right. So that's interesting.

351
00:22:39.934 --> 00:22:41.235
So whenever you,

352
00:22:42.710 --> 00:22:48.490
somebody somebody says, you know, like, it's too difficult. It's too complicated. That's not what we experience.

353
00:22:49.430 --> 00:22:50.385
I think it's

354
00:22:50.785 --> 00:22:51.525
because since

355
00:22:51.985 --> 00:22:57.765
failures on Lightning tend to be, immediate, like, maybe you're not gonna found find a route,

356
00:22:58.330 --> 00:23:01.070
to make a payment, but that's the kind of error

357
00:23:01.850 --> 00:23:04.010
that the users can understand. And,

358
00:23:04.809 --> 00:23:05.530
they are they,

359
00:23:06.250 --> 00:23:15.414
they can deal with that. But having a transaction and transaction linger for weeks, they don't like it at all. And they don't understand why, why, why it could happen. It's confusing.

360
00:23:15.715 --> 00:23:16.695
Yeah. It's confusing.

361
00:23:17.020 --> 00:23:17.340
And,

362
00:23:18.220 --> 00:23:18.720
so,

363
00:23:20.380 --> 00:23:21.360
those those

364
00:23:21.900 --> 00:23:22.400
volatile

365
00:23:23.020 --> 00:23:24.080
manifest times,

366
00:23:25.020 --> 00:23:26.640
it's quite interesting to

367
00:23:27.325 --> 00:23:28.304
to to live.

368
00:23:28.845 --> 00:23:29.345
So,

369
00:23:32.365 --> 00:23:36.145
yeah. I mean, I think it's it's really I mean, like, so I personally run,

370
00:23:37.040 --> 00:23:37.940
5 lightning,

371
00:23:38.240 --> 00:23:39.380
you know, full nodes.

372
00:23:41.440 --> 00:23:43.540
And then I also I I have,

373
00:23:44.565 --> 00:23:48.904
you know, like, my my I I do use Phoenix Wallet. Like, Phoenix Wallet is awesome.

374
00:23:50.804 --> 00:23:51.304
I,

375
00:23:53.010 --> 00:23:57.350
you know, I might have been in the beginning. I might have been in the camp where, like, I thought

376
00:23:57.809 --> 00:23:59.669
a lot more people were gonna be

377
00:24:00.184 --> 00:24:01.804
managing liquidity themselves,

378
00:24:02.105 --> 00:24:04.365
running routing nodes, doing all these things.

379
00:24:05.225 --> 00:24:08.125
But I think it's kinda interesting with Phoenix Wallet is is

380
00:24:08.510 --> 00:24:10.130
there there's, like, an argument

381
00:24:10.990 --> 00:24:12.210
for a, like, more

382
00:24:13.070 --> 00:24:19.985
like, even even a more technical user to just send, like, a large amount, like, a large UTXO in

383
00:24:20.445 --> 00:24:27.030
and then just, like, use that as their spending wallet and not have to deal with any channel management or anything. Yeah. And in in that situation,

384
00:24:27.650 --> 00:24:33.510
like, the on chain fee burden doesn't really matter to them. You know, like, let's say they're they're sending in, you know,

385
00:24:34.515 --> 00:24:35.495
$3,000 or $4,000.

386
00:24:36.515 --> 00:24:40.535
Like, what the on chain fee burden is fucking negligible in that situation.

387
00:24:41.020 --> 00:24:42.480
I think most users,

388
00:24:43.260 --> 00:24:45.120
most Phoenix users do not realize

389
00:24:46.140 --> 00:24:46.640
that,

390
00:24:47.980 --> 00:24:51.195
the splicing feature and the fact that their funds are consolidating

391
00:24:51.975 --> 00:24:57.115
into a single q UTXO, which is, again, a privacy trade off that we can discuss,

392
00:24:57.940 --> 00:25:06.735
they're gonna be very happy with that once Right. The average money fee is going to be higher. Like and that's a major difference. That's why that's why, splicing

393
00:25:07.115 --> 00:25:10.735
really is was fundamental change is that before that,

394
00:25:11.115 --> 00:25:13.375
some users had literally hundreds of channels,

395
00:25:13.860 --> 00:25:21.960
and they they were not even aware of it because a lot of users don't don't understand how it works at all. And, this was this was a real

396
00:25:22.605 --> 00:25:25.985
issue for them going forward. So now it's,

397
00:25:27.405 --> 00:25:30.065
it's future proof in a in a sense. So so

398
00:25:33.100 --> 00:25:36.000
that that's that's why it was a really, very, important.

399
00:25:36.620 --> 00:25:38.640
But where I was going with that is,

400
00:25:40.475 --> 00:25:50.350
I wanna go a little bit into, like, how you guys are so, like, I I think it was a little bit you probably were getting a ton of support requests on on large fee amounts.

401
00:25:51.450 --> 00:25:52.909
And then you added this,

402
00:25:53.450 --> 00:25:56.830
like, the fees section in settings, like, the channel management,

403
00:25:57.955 --> 00:25:59.815
where it's like a max fee amount.

404
00:26:02.115 --> 00:26:16.875
Like, is that do you think that is, like, a a temporary stop gap solution? Because it's a little bit hard. It's a little bit confusing. Like, they receive their first lightning payment. The thing is And, like, what if I'm sending them if I send them a large lightning fee payment, a lightning payment,

405
00:26:17.335 --> 00:26:20.635
and they have to open their first, you know, they have to open the channel,

406
00:26:21.655 --> 00:26:23.515
and fees are high on chain.

407
00:26:24.230 --> 00:26:29.690
It's like an absolute amount. Like, how do you how do you think about that? Do you know what I do you know what I mean? Yeah. Yeah. I mean,

408
00:26:30.549 --> 00:26:32.009
we wish we could do it better.

409
00:26:34.735 --> 00:26:38.115
Before we introduced this, we had a fixed 1%

410
00:26:38.495 --> 00:26:39.395
fee on receive

411
00:26:39.775 --> 00:26:42.120
Right. Plus 3,000 sets.

412
00:26:42.840 --> 00:26:43.340
And,

413
00:26:44.040 --> 00:26:45.660
this had the advantage of simplicity,

414
00:26:46.680 --> 00:26:47.180
but

415
00:26:48.120 --> 00:26:57.325
You were getting killed on on chain fees. Yeah. It's it's just a risk. It's just a risk. I mean, we were doing great when fees were low, but it's just a risk. And the the the main

416
00:26:57.860 --> 00:26:59.160
change that we made

417
00:26:59.540 --> 00:27:02.040
was to just push the money fee to the users.

418
00:27:02.740 --> 00:27:05.160
To us, it's just a matter of managing,

419
00:27:05.940 --> 00:27:06.440
risk.

420
00:27:06.855 --> 00:27:08.554
And once once you do

421
00:27:08.855 --> 00:27:10.475
that, you you cannot just,

422
00:27:12.215 --> 00:27:16.570
exchange Auto charge them. Yeah. It's it's it's very difficult to, to

423
00:27:17.049 --> 00:27:20.750
to put to put in in one sentence what's the cost is going to be.

424
00:27:21.130 --> 00:27:24.750
And so, obviously, we are, you know, trying to to

425
00:27:25.130 --> 00:27:27.645
the the the way it is done currently is not final.

426
00:27:28.025 --> 00:27:30.525
We are we are we are thinking about it every day, but,

427
00:27:30.985 --> 00:27:32.525
the goal was to offer,

428
00:27:33.625 --> 00:27:34.845
more advanced users

429
00:27:35.470 --> 00:27:36.850
a way to fine tune,

430
00:27:37.470 --> 00:27:39.010
their fees to the very minimal,

431
00:27:39.470 --> 00:27:40.850
which is why, you know,

432
00:27:42.585 --> 00:27:44.845
you're gonna have Phoenix users who say,

433
00:27:45.305 --> 00:27:53.620
it's too expensive. I'm getting killed by fees. It's, it's nonsense. And you're gonna have all that who gotta say, it's awesome. It's almost cost me nothing.

434
00:27:54.080 --> 00:28:06.370
So our our because they're using it the correct way. And our goal is to find a way in the UX to make the users understand how it works and But there is a level of, understanding that you need to have,

435
00:28:06.850 --> 00:28:09.030
which by the way, you must have the same

436
00:28:09.410 --> 00:28:11.190
kind of level of understanding

437
00:28:11.730 --> 00:28:20.465
at the on chain level 2 if you don't know what's a new tool. You're gonna have issues with, with mining fees. You can get killed a bit in the same way.

438
00:28:20.845 --> 00:28:22.705
So it's a very difficult problem.

439
00:28:23.590 --> 00:28:34.155
But Especially since I mean, so many people have been, like, conditioned on custodial wallets, especially newcomers. Like, I I like when I try and transfer someone over from, like, Wallet Satoshi or something,

440
00:28:34.535 --> 00:28:36.875
they're like, I'm getting charged so much more fees.

441
00:28:37.255 --> 00:28:46.299
And it's like, yeah. Well, you know, you actually have a lightning channel. Like, you're actually holding self custody of your funds. Well, you know what? If you look into the fees, it's not like

442
00:28:46.600 --> 00:28:59.665
try to make an unchanged transaction from White Ops Satoshis and compare to the costs we sell. I know. I'm aware. I'm saying, like, the educational it's, like, it's just hard to translate that to the user, especially if they're a new user. Yeah. And it's a difficult problem.

443
00:28:59.990 --> 00:29:05.529
But, no, on the unchain feeds, when you make unchain transactions, it's actually interesting how

444
00:29:06.230 --> 00:29:12.445
Phoenix is more efficient. It's not less expensive in Phoenix because we made a particular effort on fees. No, it's just because

445
00:29:13.145 --> 00:29:27.735
if you pay for UTXO, then it's easy for you to spend it. Whereas if you have a custodial wallet, they're gonna have to manage the hot wallet, and it's it's really, really difficult to manage your hot wallet and let users spend from your wallet. It's very, very difficult. That's why it's expensive.

446
00:29:29.315 --> 00:29:30.115
Yeah. I,

447
00:29:30.674 --> 00:29:33.894
yeah. I I I so, the reason I bring it up is because,

448
00:29:37.190 --> 00:29:44.250
yeah, it I was just gonna be and when you first implemented the feature, it was like the default was a certain amount.

449
00:29:44.735 --> 00:29:46.755
It was, like, an absolute fixed amount.

450
00:29:48.255 --> 00:29:51.475
It is for it's I think by default, it's 5,000 satoshis.

451
00:29:52.430 --> 00:30:01.115
Which, like, what is that what is that sat per byte rate where that gets hit? Do you know? It it's it's an absolute in, satoshis,

452
00:30:01.895 --> 00:30:02.395
because,

453
00:30:03.175 --> 00:30:04.555
But shouldn't it be percentage?

454
00:30:06.990 --> 00:30:08.370
You you have both, actually.

455
00:30:08.750 --> 00:30:09.310
There is

456
00:30:09.870 --> 00:30:16.975
I mean, the fact is the the real cost is absolute. It's an unchain fee, so the real cost is absolute. So it doesn't make sense to to put it,

457
00:30:17.695 --> 00:30:19.475
to have the main setting be relative,

458
00:30:20.415 --> 00:30:21.475
but you could,

459
00:30:22.415 --> 00:30:25.875
put a very high amount and there is also a relative

460
00:30:26.560 --> 00:30:30.980
in the advanced setting somewhere. There is also a relative check. Yeah. I see advanced percentages.

461
00:30:32.480 --> 00:30:33.940
Our approach to it is

462
00:30:34.835 --> 00:30:35.975
there are so many,

463
00:30:36.355 --> 00:30:37.015
you know,

464
00:30:40.995 --> 00:30:41.800
side effects,

465
00:30:42.280 --> 00:30:48.300
and so many stuff going on that you don't want to be too far from the reality. And the reality is the cost is

466
00:30:48.600 --> 00:30:52.075
independent of the amount. So if we if we don't want to have too many headaches,

467
00:30:52.855 --> 00:30:54.395
that's the easiest way.

468
00:30:55.255 --> 00:30:55.915
Fair enough.

469
00:30:56.295 --> 00:31:00.070
I just know when I was onboarding in the higher fee environment, I was just literally

470
00:31:00.870 --> 00:31:06.490
I before I would have them send into the wallet, I would go into settings and just jack up that.

471
00:31:07.065 --> 00:31:11.325
Yeah. It was like an it was they were like, what are you doing? I was like, you gotta go into settings.

472
00:31:11.945 --> 00:31:13.885
You gotta you gotta increase this amount,

473
00:31:14.350 --> 00:31:18.370
and there was but there's no easy answer. I don't pretend there's an easy answer. Well, it's,

474
00:31:19.070 --> 00:31:19.810
we we

475
00:31:20.350 --> 00:31:24.085
we have introduced a feature related to that in in the phoenix,

476
00:31:25.345 --> 00:31:25.845
release.

477
00:31:26.385 --> 00:31:29.285
Maybe we'll talk about it later, but it's related to that. It's

478
00:31:29.585 --> 00:31:31.285
bay it's it's the feed credit.

479
00:31:31.780 --> 00:31:33.800
Is it's a way for for

480
00:31:34.180 --> 00:31:34.680
to

481
00:31:34.980 --> 00:31:36.440
to aggregate amounts,

482
00:31:37.380 --> 00:31:38.840
before you open the channel.

483
00:31:40.725 --> 00:31:42.425
You know, like you cannot onboard

484
00:31:42.805 --> 00:31:47.225
a user by sending him a 1,000 sats if it costs a 1,000 sats,

485
00:31:47.605 --> 00:31:56.000
in mining fee. So the idea is to say, okay. But what what you're actually going to do is you're gonna pay for WAN and you're gonna

486
00:31:56.540 --> 00:32:00.345
pay in advance the LSP to just put the amount aside

487
00:32:00.725 --> 00:32:10.370
and take it from your future mining fee. And it's a bit like custodial without being custodial. You trust us because you're paying advance, but those are not your fans.

488
00:32:11.390 --> 00:32:13.890
So it's kind of a gray gray area in

489
00:32:15.304 --> 00:32:18.845
in a regulation from a regulation point of view, but I think it works that

490
00:32:19.145 --> 00:32:20.605
way. Yeah. That makes sense.

491
00:32:21.465 --> 00:32:24.365
Okay. So let's talk about continuing the trade offs.

492
00:32:25.370 --> 00:32:30.350
The major trade off with Phoenix right now is privacy trade off, and you're very clear on your website.

493
00:32:30.890 --> 00:32:32.990
But you wanna just discuss, like, what

494
00:32:33.615 --> 00:32:36.914
what kind of information can Phoenix see if I'm a Phoenix user?

495
00:32:38.975 --> 00:32:40.575
So we can see

496
00:32:41.580 --> 00:32:42.240
if you

497
00:32:43.100 --> 00:32:49.205
if you don't use store, we can see your, your IP address because you're connecting directly to our node. Right.

498
00:32:50.225 --> 00:32:51.445
We can correlate

499
00:32:52.705 --> 00:32:57.845
since you are we are the only node that you're connected to, we can correlate your transactions,

500
00:32:59.010 --> 00:33:00.130
obviously. I mean,

501
00:33:00.850 --> 00:33:06.390
we we see how much beacon you have in your wallet because they are on the other side of the channel. Right.

502
00:33:09.835 --> 00:33:11.215
But that would be

503
00:33:14.390 --> 00:33:15.690
this is not a specific

504
00:33:15.990 --> 00:33:16.730
trade off

505
00:33:17.030 --> 00:33:20.330
of Phoenix. It's a specific trade off when you're connected to a single node.

506
00:33:22.150 --> 00:33:24.010
Are you keeping track of, like,

507
00:33:25.174 --> 00:33:27.674
so, like, if I if I open Phoenix

508
00:33:28.455 --> 00:33:29.595
and I pay

509
00:33:29.975 --> 00:33:33.275
a lightning address, right, you can pay 2 lightning addresses,

510
00:33:34.440 --> 00:33:37.179
and I pay, like, Odell at at voltage.

511
00:33:38.440 --> 00:33:40.460
Are you keeping track of those,

512
00:33:43.835 --> 00:33:46.895
which lightning addresses you're paying? Are you keeping track of the memos

513
00:33:47.515 --> 00:33:50.255
of those addresses? Like, the memos of those transactions?

514
00:33:50.649 --> 00:33:54.269
We don't have access to that because the resolution is done on the mobile.

515
00:33:54.570 --> 00:34:02.255
But we keep track of the the payments. Like, with the endpoint, where it goes, which node it it ends up. So

516
00:34:05.090 --> 00:34:06.610
what what we need to do as,

517
00:34:07.170 --> 00:34:09.830
routing node is we need to allocate our fans.

518
00:34:10.370 --> 00:34:13.110
We need to know where to allocate them. Right. So

519
00:34:13.865 --> 00:34:16.525
it's very so we have to to see where,

520
00:34:17.225 --> 00:34:17.965
we should

521
00:34:18.905 --> 00:34:21.085
put our funds so that it's it's more reliable.

522
00:34:22.200 --> 00:34:23.580
One important thing,

523
00:34:24.440 --> 00:34:26.300
in Phoenix is that,

524
00:34:27.240 --> 00:34:29.180
it implements trampoline routing.

525
00:34:29.635 --> 00:34:30.695
Trampoline routing

526
00:34:31.395 --> 00:34:33.255
so the the default routing,

527
00:34:33.635 --> 00:34:37.095
in, lightning is called onion routing and it's just

528
00:34:39.920 --> 00:34:47.140
the the source when you make a payment from a to d, the source computes the route from a to b to b to c to c to d.

529
00:34:48.025 --> 00:34:50.525
And then makes an onion and intermediate

530
00:34:50.825 --> 00:34:57.005
routing node. In my example, it would be b and c. They don't know where the payment is going. They just forward it from the

531
00:34:57.680 --> 00:34:59.220
previous node to the next node.

532
00:34:59.680 --> 00:35:06.215
The idea of the temporary routing was to do just that, just the same. It's a nonlinear routing too,

533
00:35:07.255 --> 00:35:10.715
but, like, if you want to pay from a to z,

534
00:35:12.695 --> 00:35:17.400
the source of the payment, they would not have to find the whole route because this

535
00:35:18.180 --> 00:35:18.680
requires

536
00:35:19.700 --> 00:35:30.575
them to know the whole network table which changes constantly and is a pain to to sync and all that. It slows down the UX of the transaction. Exactly. So the the goal they they only need to

537
00:35:31.060 --> 00:35:35.500
to select a few intermediate nodes. Like, they would say, okay. I want to,

538
00:35:35.940 --> 00:35:39.080
I'm gonna use a route, I don't know, f, n,

539
00:35:39.780 --> 00:35:40.360
and p.

540
00:35:41.515 --> 00:35:41.915
And,

541
00:35:42.395 --> 00:35:49.660
and then this intermediate node, this trampoline node, that's up to them to find the route between themselves. So it's the same,

542
00:35:50.680 --> 00:35:53.420
it's very similar but at a higher level.

543
00:35:53.880 --> 00:35:56.300
And so we came up with this idea

544
00:35:56.600 --> 00:35:59.145
of taupelyn routing a few years back and,

545
00:35:59.785 --> 00:36:02.285
we we we thought it was a really good way

546
00:36:02.665 --> 00:36:03.325
to offer

547
00:36:03.945 --> 00:36:04.445
privacy

548
00:36:04.985 --> 00:36:05.725
for mobile

549
00:36:06.345 --> 00:36:10.410
lightning wallets without having them sync and be aware of the,

550
00:36:10.810 --> 00:36:12.910
whole network table all the time.

551
00:36:13.770 --> 00:36:15.625
That's where the the I'm just

552
00:36:16.105 --> 00:36:18.285
saying that to explain where the current,

553
00:36:19.545 --> 00:36:24.205
state comes from. And but as about as I mentioned earlier,

554
00:36:25.760 --> 00:36:29.460
some, protocol features involve the whole network, and that's the case for trampoline.

555
00:36:30.480 --> 00:36:33.395
The whole I mean, a lot of the nodes in the network

556
00:36:33.935 --> 00:36:38.755
need to be trampoline. They need to understand this protocol for this to work. And when we started,

557
00:36:39.455 --> 00:36:43.029
we were pushing this feature and only us were supporting

558
00:36:43.369 --> 00:36:43.869
this.

559
00:36:44.210 --> 00:36:47.190
So what what Phoenix does generally is a trampoline routing,

560
00:36:47.490 --> 00:36:50.125
but with only 1 trampoline node. So the destination

561
00:36:50.425 --> 00:36:55.885
is always known to us because we know they're not gonna do any more hops. And was that the LSP?

562
00:36:56.660 --> 00:36:57.160
Yeah.

563
00:36:57.860 --> 00:36:58.260
So that's,

564
00:36:59.060 --> 00:37:03.000
that's why currently we know the final destination of, all payments.

565
00:37:03.460 --> 00:37:11.085
The idea was this to be a first step to work. But if other routing nodes add trampoline routing, then you won't know the final destination.

566
00:37:11.385 --> 00:37:12.845
No. They don't. Because between

567
00:37:13.430 --> 00:37:17.050
between property nodes or between the last property node and the destination,

568
00:37:17.430 --> 00:37:22.890
which is the case in Phoenix because the first property node is the last property node, it's normal Lightning payments.

569
00:37:23.375 --> 00:37:23.875
So

570
00:37:25.535 --> 00:37:26.194
so yeah.

571
00:37:28.974 --> 00:37:30.434
This is going to be

572
00:37:32.630 --> 00:37:33.530
majorly improved,

573
00:37:34.710 --> 00:37:37.450
very soon with the introduction of the daily path.

574
00:37:38.230 --> 00:37:42.855
That's a more technical feature. I don't know if you want to address right now or later. But,

575
00:37:43.575 --> 00:37:48.395
We but we're on the topic. Let's talk about blind Alright. So blind blind blind blind blind blind blind blind blind blind blind blind blind is

576
00:37:50.090 --> 00:37:51.710
is a way for the recipient

577
00:37:52.570 --> 00:37:53.070
to

578
00:37:53.770 --> 00:37:55.310
to to to give,

579
00:37:56.090 --> 00:37:57.310
the end of the route

580
00:37:58.555 --> 00:38:00.335
or a few sets of routes,

581
00:38:00.635 --> 00:38:01.135
the

582
00:38:01.515 --> 00:38:03.775
last part of the routes to to pay them,

583
00:38:04.155 --> 00:38:09.140
which means So it's in the invoice? Yeah. It's the it's it's in the invoice. So

584
00:38:10.000 --> 00:38:14.980
from Phoenix, if you would pay I don't know. You would you want to send your money to

585
00:38:17.174 --> 00:38:22.474
to any any place. You wouldn't you would not to Bob, say. You would not

586
00:38:23.894 --> 00:38:24.394
send

587
00:38:24.780 --> 00:38:28.640
the destination bob to our node. You would say you would send

588
00:38:28.940 --> 00:38:29.440
an

589
00:38:29.740 --> 00:38:32.320
entry node, which is a few nodes

590
00:38:32.785 --> 00:38:40.245
before bobs. And our job would just be to route the payment the payment to this entry node, and then the last

591
00:38:40.625 --> 00:38:41.525
remaining hops,

592
00:38:42.650 --> 00:38:44.030
are already computed.

593
00:38:44.730 --> 00:38:47.870
And so it's it's base it's it's resembles,

594
00:38:48.250 --> 00:38:50.670
what we wanted to achieve with the original temporary

595
00:38:52.345 --> 00:38:54.605
payments. So is LND implementing this?

596
00:38:55.465 --> 00:38:59.165
I oh, you will have to ask, Bastian for the exact,

597
00:38:59.545 --> 00:39:00.765
but I think yes.

598
00:39:01.090 --> 00:39:04.290
So this is this is related to, to bolt,

599
00:39:04.690 --> 00:39:05.190
12.

600
00:39:05.890 --> 00:39:08.470
Oh, so l and d isn't implementing. Yeah. Yeah.

601
00:39:09.025 --> 00:39:17.765
I don't know exactly how how far they are, but, yes, they are more important. Okay. Well, I definitely wanna talk about vault 12, but let's continue on the wallet just real quick here because,

602
00:39:18.400 --> 00:39:20.799
I just wanna go through the trade offs on the wallet. Sure.

603
00:39:21.520 --> 00:39:24.935
So, I mean, right now, that that main trade off, then you know the end

604
00:39:25.575 --> 00:39:28.315
the real the the key reason for the end user

605
00:39:29.015 --> 00:39:32.795
for that privacy trade off is that Phoenix payments are almost instant.

606
00:39:33.640 --> 00:39:35.660
And if you use, like, a Zeus wallet,

607
00:39:37.080 --> 00:39:37.980
where where

608
00:39:38.280 --> 00:39:40.380
they're computing the whole path locally,

609
00:39:41.395 --> 00:39:51.049
is when is when you kinda sit there and you make the joke. You're like, oh, look. The future of finance. And you're, like, sitting there for, like, 15, 20 seconds while your payment goes through. Yeah.

610
00:39:51.430 --> 00:39:54.569
And and so Phoenix makes that trade off so that

611
00:39:54.950 --> 00:40:11.440
so that the the payments are just like it's it's literally just like a snap of finger. It's it's crazy how quick it goes. It's also more reliable because you could, like, try some routes, but it changes all the time. The availability of routes, the the amount of events available in each channel and so on,

612
00:40:13.020 --> 00:40:14.480
it changes all the time. So

613
00:40:16.994 --> 00:40:24.615
our point of view in this is okay, yeah, we know the destination, but let first, comparing to making a simple on chain payment,

614
00:40:26.190 --> 00:40:29.250
is still in my opinion, it's still much better. Right.

615
00:40:29.869 --> 00:40:30.369
And

616
00:40:30.910 --> 00:40:38.515
and also it's so easy I mean, if it's an on chain payment, you would know the I mean Yeah. I mean, everybody would have that that information, basically. Everyone has a destination.

617
00:40:39.694 --> 00:40:48.820
And, and also, there is there are no KYC, no subscription. So you can open a new wallet as you want. So what does this really mean for us to know the destination

618
00:40:49.280 --> 00:40:49.780
where

619
00:40:50.135 --> 00:40:55.675
you can change your identity whenever you want? It's it's not as valuable as,

620
00:40:59.170 --> 00:41:00.470
as, like, having,

621
00:41:01.010 --> 00:41:08.135
the user stuck in 1 user ID or user account, and then you can correlate everything that's related to it. And,

622
00:41:09.015 --> 00:41:14.715
and also what what it allows us, and it's very important for UX, is a predictable fee for sending.

623
00:41:16.589 --> 00:41:19.490
Because one of the critics that we had in our,

624
00:41:20.270 --> 00:41:20.770
previous,

625
00:41:22.325 --> 00:41:27.865
iteration of the wallet was. I don't know how it's going to how much it's going to cost me when I send the payments.

626
00:41:28.405 --> 00:41:28.485
And

627
00:41:30.630 --> 00:41:35.450
Oh, yeah. It's great. It shows the fee ahead of time. Exactly. And that's, that's that's important.

628
00:41:37.285 --> 00:41:40.105
Okay. So the next thing I've I've gotten

629
00:41:42.085 --> 00:41:44.325
you know, I just love Bitcoin, and,

630
00:41:44.805 --> 00:41:46.425
I want Bitcoin to be

631
00:41:47.770 --> 00:41:54.815
as useful to people as possible and wide variety of users. And I live in the heavy technical world of bitcoin a lot,

632
00:41:55.295 --> 00:41:56.835
but I also live in the the

633
00:41:57.775 --> 00:42:03.395
the newcomer world a lot. I have a lot of exposure with people that are are relatively new to Bitcoin.

634
00:42:04.250 --> 00:42:07.550
And one thing I've gotten a little bit of heat for lately is

635
00:42:08.329 --> 00:42:10.670
I really like the fact that you can

636
00:42:12.525 --> 00:42:15.505
back up your iOS Phoenix wallet to Icloud,

637
00:42:17.244 --> 00:42:22.640
which is just I mean, if you asked me 5 years ago, 4 years ago, I would have been like,

638
00:42:22.940 --> 00:42:24.000
fucking hell no.

639
00:42:24.940 --> 00:42:30.744
But it's it's a very easy way for a new user to back back up their wallet

640
00:42:31.125 --> 00:42:33.704
without dealing with seed phrases, without dealing

641
00:42:34.484 --> 00:42:40.240
with actually storing the seed phrases securely, with making sure that they're still there. If they lose their iPhone, they can just

642
00:42:40.540 --> 00:42:41.920
easily log back in

643
00:42:42.300 --> 00:42:48.625
and and have their wallet. Now when you one of the cool things you guys do is when you go to initiate iCloud backup,

644
00:42:49.405 --> 00:42:50.625
you give, like, really

645
00:42:51.110 --> 00:42:52.490
clear scary warnings,

646
00:42:53.430 --> 00:43:00.650
as you enable it. What are the real risks there in terms of a user that is, like, using the iCloud backup feature?

647
00:43:03.654 --> 00:43:04.154
Well,

648
00:43:06.214 --> 00:43:09.890
on the top of my head, but, I would need to double check with

649
00:43:10.450 --> 00:43:11.510
our iOS guys.

650
00:43:13.089 --> 00:43:16.309
The main trade off is that if your Icloud account is compromised,

651
00:43:17.424 --> 00:43:18.805
then it's not good for you.

652
00:43:19.424 --> 00:43:19.924
Whereas

653
00:43:20.224 --> 00:43:21.525
if, like, on on Android,

654
00:43:22.065 --> 00:43:24.164
you there is no Google Drive backup,

655
00:43:25.140 --> 00:43:27.320
Right. Then you're safe from

656
00:43:27.700 --> 00:43:28.520
that. So

657
00:43:29.860 --> 00:43:34.785
So, like, if you're if you're storing, like, nude pictures of yourself in Icloud, like, there's

658
00:43:35.245 --> 00:43:35.745
probably

659
00:43:36.205 --> 00:43:45.559
you're probably cool with with with storing your wallet in Icloud. Right? Like, I mean, like, it's I when I read the when I read the things, it's like Apple might compromise you.

660
00:43:45.859 --> 00:43:46.359
Yes.

661
00:43:47.059 --> 00:43:48.440
But it's encrypt it's

662
00:43:48.740 --> 00:43:50.760
technically encrypted, the backup.

663
00:43:51.140 --> 00:43:51.640
Yes.

664
00:43:52.420 --> 00:43:52.920
But

665
00:43:53.415 --> 00:43:54.555
if you have access

666
00:43:54.855 --> 00:44:01.940
to your if somebody has access to your hack like if because if you have a very weak, password, if you have a very weak hack like that password,

667
00:44:03.460 --> 00:44:06.280
And people are usually terrible at passwords. So,

668
00:44:07.300 --> 00:44:09.565
that's the trade off. Yeah. I mean,

669
00:44:10.205 --> 00:44:11.405
the warnings are, like, very

670
00:44:12.285 --> 00:44:16.305
I mean, they should be. I I applaud you for putting scary warnings there.

671
00:44:17.750 --> 00:44:20.890
But I think it's very compelling for a lot of people. I mean, I think,

672
00:44:23.269 --> 00:44:28.905
The the reason we did it on the iCloud and on the Apple and not on on, Android is that on Android, we

673
00:44:29.465 --> 00:44:33.625
by default, you don't have access to Google Drive. So this would require,

674
00:44:34.809 --> 00:44:36.829
to ask for permission, and that's,

675
00:44:38.250 --> 00:44:40.190
some people don't like Google Drive.

676
00:44:41.450 --> 00:44:41.950
So

677
00:44:42.825 --> 00:44:48.205
this feature is only available on, on Apple for now. Yeah. Well, I mean, what I see with most people is,

678
00:44:49.545 --> 00:44:52.730
like, most people are more likely to lose their money

679
00:44:53.690 --> 00:44:55.630
than have someone steal their money,

680
00:44:55.930 --> 00:44:57.070
and most people

681
00:44:57.609 --> 00:45:04.125
are are unlikely to be, like, a high value target that, like, Apple would presumably, like, try and attack.

682
00:45:04.825 --> 00:45:08.205
And Apple takes pretty decent lengths to protect

683
00:45:08.585 --> 00:45:09.724
Icloud from,

684
00:45:11.050 --> 00:45:12.750
you know, general attackers

685
00:45:13.130 --> 00:45:17.550
because of the fapping that happened when all the celebrities nude photos all got out,

686
00:45:18.105 --> 00:45:22.205
which is not good for Apple's business. Like, they don't want nude photos getting out. So

687
00:45:22.585 --> 00:45:29.710
the protection they provide for the nude photos, they're kind of providing for the phoenix backup. And for me, like, that flow, that process

688
00:45:30.570 --> 00:45:38.665
of getting someone new to Bitcoin, and I don't want them to use a custodial wallet, I onboard them on a Phoenix wallet. I have them enable iCloud backups

689
00:45:39.365 --> 00:45:42.665
and make sure they read the warnings. And I explain to them, like,

690
00:45:43.204 --> 00:45:46.770
you know, make sure your iCloud password is is secure password.

691
00:45:47.950 --> 00:45:53.490
They also have some, like, ridiculous two factor that is, like, very opaque and hard to understand, but

692
00:45:54.305 --> 00:45:56.485
apparently works reasonably well.

693
00:45:57.425 --> 00:46:02.805
I I it just seems like a good trade off balance. Like, I I've I've known so many people who've lost seed phrases,

694
00:46:04.080 --> 00:46:07.060
particularly for their first for their first wallet, and

695
00:46:07.360 --> 00:46:11.380
and and I I think it's a a a a good UX flow.

696
00:46:14.355 --> 00:46:16.855
Awesome. Okay. I think we got through

697
00:46:17.715 --> 00:46:24.540
the wallet trade offs. Yeah. There is one trade off that you have not mentioned, but it's a recurring question for us is why don't we allow,

698
00:46:25.320 --> 00:46:28.460
users to connect to different nodes? I know. Why not?

699
00:46:29.955 --> 00:46:34.935
It's funny because most people think that it's because we want to capture all the all the payment fees,

700
00:46:35.555 --> 00:46:39.140
which is not the result it's not the reason at all. The reason is that.

701
00:46:39.700 --> 00:46:40.839
There are 2 reasons.

702
00:46:44.180 --> 00:46:46.839
The problem are incentives. That's the main reason.

703
00:46:47.195 --> 00:46:48.095
You don't want

704
00:46:48.715 --> 00:46:49.775
to develop software

705
00:46:50.235 --> 00:46:53.055
and put software out for users to to use

706
00:46:53.355 --> 00:47:02.310
and then have users connecting to random lightning nodes. So if they're using your software, you're not part of it. You're just providing the software, and then you have to,

707
00:47:03.010 --> 00:47:05.750
and then they're gonna do whatever they want and connect to

708
00:47:06.515 --> 00:47:08.615
nodes as unreliable as possible.

709
00:47:09.714 --> 00:47:16.339
When they're going to encounter issues, who are they going to turn to turn to is going to be to you because you're the most sales

710
00:47:17.039 --> 00:47:25.365
actor in this in this message. Why are my payments failing? Exactly. So we don't want to be stuck doing support for user of the tile using,

711
00:47:25.685 --> 00:47:32.185
nodes that we have no power over, no control over because it's just a nightmare. You don't want to do that. It's just going to be

712
00:47:32.690 --> 00:47:36.310
wasting a lot of time and a lot of effort. So that's the main reason.

713
00:47:37.329 --> 00:47:43.475
If if users were competent and, like, we could we could do as many warnings as we could.

714
00:47:43.855 --> 00:47:52.180
It just doesn't work. We we we actually did this before with Xtra Mobile. You could correct me. So we know what that is, and we don't want to do that.

715
00:47:52.640 --> 00:47:55.220
It's not about the physical. The the

716
00:47:56.240 --> 00:47:56.740
the,

717
00:48:02.965 --> 00:48:09.349
yeah, sorry. That's what I was about. It's about the user experience. You wanna be able to provide a good

718
00:48:09.650 --> 00:48:13.349
reliable user experiences. Yeah. I mean, we don't want to be stuck because

719
00:48:13.730 --> 00:48:19.405
this is complex tech, and you don't want to be to be stuck in the middle. It's just a problem with incentives.

720
00:48:20.025 --> 00:48:24.285
Yeah. I mean, I I yeah. Yeah. Go on. The other very important reason is that

721
00:48:25.430 --> 00:48:28.250
one of the the main service that we provide is,

722
00:48:28.790 --> 00:48:29.270
is,

723
00:48:29.750 --> 00:48:30.250
liquidity

724
00:48:30.550 --> 00:48:32.730
and specifically on the flight channels.

725
00:48:33.885 --> 00:48:34.285
And,

726
00:48:34.685 --> 00:48:36.465
I I discussed it with the,

727
00:48:39.325 --> 00:48:43.770
Blockstream guys when they were working on Greenlight is. How do you know

728
00:48:44.070 --> 00:48:46.490
how can you tell if the users is lacking

729
00:48:46.790 --> 00:48:47.290
liquidity

730
00:48:48.790 --> 00:48:51.370
if you don't have the total view of their channels?

731
00:48:51.785 --> 00:48:52.444
You know?

732
00:48:52.984 --> 00:48:55.244
Maybe you cannot receive the payment,

733
00:48:55.625 --> 00:48:56.845
using the channel that

734
00:48:57.305 --> 00:49:02.349
you have with async, but maybe your Phoenix has another channel that you're not aware about.

735
00:49:02.650 --> 00:49:09.365
So why would we charge the user something if it could can go to the to the to, another direction? So to

736
00:49:09.745 --> 00:49:13.265
me, we can we cannot offer both connecting to,

737
00:49:13.665 --> 00:49:18.980
many nodes and on the file liquidity. I don't see how that can possibly work. It's going to

738
00:49:19.280 --> 00:49:20.819
to be very hard to explain.

739
00:49:21.920 --> 00:49:22.420
So

740
00:49:22.880 --> 00:49:24.260
those are the actual reasons.

741
00:49:25.945 --> 00:49:27.565
Yep. That makes sense to me.

742
00:49:29.145 --> 00:49:29.964
Okay. So,

743
00:49:30.265 --> 00:49:33.085
I guess before we leave the wallet, I have two questions

744
00:49:34.450 --> 00:49:36.150
relating to Gnoster. How

745
00:49:36.530 --> 00:49:36.930
how,

746
00:49:38.450 --> 00:49:43.345
attentive are you to the Gnoster ecosystem? Are you familiar with Gnoster Wallet Connect? No.

747
00:49:43.885 --> 00:49:45.905
No. I I know that,

748
00:49:46.765 --> 00:49:47.425
some people

749
00:49:47.805 --> 00:49:49.825
want us to do something with that,

750
00:49:50.740 --> 00:49:59.625
But, I don't know exactly what that is. And Okay. So Nasr Wallet Connect is, like, in Nasr. Right? We have the ability to send Zaps. Right? And,

751
00:50:00.065 --> 00:50:00.725
you know,

752
00:50:01.105 --> 00:50:02.885
lightning payments to users

753
00:50:03.505 --> 00:50:05.925
within within a Nostra app. Right?

754
00:50:06.599 --> 00:50:08.140
And nostril WalletConnect,

755
00:50:10.200 --> 00:50:11.980
basically uses nostril,

756
00:50:12.599 --> 00:50:15.579
as a communication protocol back to your LSP

757
00:50:16.565 --> 00:50:21.545
that says, like, I wanna make these payments. So, like, right now, if I'm using Phoenix to send a Zap,

758
00:50:22.805 --> 00:50:27.240
I have to I have to leave the Nostra app. I have to go back into Phoenix.

759
00:50:27.860 --> 00:50:33.695
It, like, automatically opens in Phoenix, and then I have to approve the payment in Phoenix. But if you use Nasr WalletConnect,

760
00:50:34.395 --> 00:50:37.615
those payments all get queued. And next time I open Phoenix,

761
00:50:38.234 --> 00:50:44.960
Phoenix can have, like, a threshold where it automatically makes the payment, or it can ask me, do I wanna make the payment at that moment?

762
00:50:45.980 --> 00:50:48.480
So it basically just uses nostr as a communication

763
00:50:49.315 --> 00:50:53.655
as a communication protocol, which that is what nostr is, a secure communication protocol,

764
00:50:55.234 --> 00:51:00.579
to to allow you to queue payments for all sorts of things. And now people are using it for

765
00:51:01.119 --> 00:51:01.619
subscriptions.

766
00:51:01.920 --> 00:51:04.180
So like Geyser Geyser Fund,

767
00:51:05.359 --> 00:51:12.595
you can like you can set up, like, almost like a Patreon level subscription where I wanna, like, I wanna send 5,000 sats every month.

768
00:51:13.680 --> 00:51:16.260
And, basically, guys are sending this Noster event

769
00:51:17.520 --> 00:51:25.325
to to Phoenix. And then when I open Phoenix, it's like you have these subscriptions, and I can, like, immunity wallet has kind of been ahead of the game on that.

770
00:51:26.345 --> 00:51:32.190
And, like, so they Yeah. So You can set, like, a threshold. You know? You can set a threshold. Like, every day, I wanna auto

771
00:51:33.069 --> 00:51:33.549
approve,

772
00:51:34.030 --> 00:51:35.010
a certain amount,

773
00:51:36.030 --> 00:51:41.970
for this one app so that I when I open up Phoenix, it just automatically makes those payments, essentially. Okay.

774
00:51:42.295 --> 00:51:43.575
So it's essentially just,

775
00:51:43.895 --> 00:51:46.395
Phoenix embeds the Northstar client. Right?

776
00:51:47.095 --> 00:51:49.790
And reads Into the LSP. Yeah. Okay.

777
00:51:51.070 --> 00:51:53.730
Look into it. Cool. And then the other thing is

778
00:51:54.590 --> 00:51:56.770
using, like, Nostra contact lists

779
00:51:57.915 --> 00:52:13.380
for like, so you can have, like, a I don't know if I mean, you're in France. I don't know if you know, like, Venmo or I I assume, like, Revolut and, like, the European based ones have it. But, like, basically, I can just, like, open it up and be like, I wanna pay Marty, and Marty's already my Noster contact.

780
00:52:13.975 --> 00:52:14.475
So

781
00:52:15.255 --> 00:52:20.395
he has a Lightning address set up, you know, so I it linked to his Noster account so I can just, like, easily

782
00:52:20.695 --> 00:52:23.549
import my Noster contacts to pay people. Those are two

783
00:52:23.849 --> 00:52:25.470
different things. On the on the

784
00:52:25.770 --> 00:52:26.510
more general

785
00:52:27.130 --> 00:52:28.109
payment front,

786
00:52:28.490 --> 00:52:31.725
our immediate focus is bolt 12, which is a

787
00:52:32.105 --> 00:52:36.365
major milestone. Perfect. Let's talk about block 12. Yeah. So, I mean,

788
00:52:36.905 --> 00:52:39.565
these these features that you're mentioning to me is,

789
00:52:39.945 --> 00:52:41.380
like the cherry on the

790
00:52:41.920 --> 00:52:43.140
cake once we have the big

791
00:52:43.920 --> 00:52:45.140
infrastructure working.

792
00:52:47.039 --> 00:52:47.440
So

793
00:52:47.839 --> 00:52:51.954
Well, let's talk about Bolt 12. Like, where are we on Bolt 12? How are you thinking about it?

794
00:52:52.654 --> 00:52:53.615
So Bolt 12, we have

795
00:52:56.869 --> 00:53:09.725
as for everything, we have to implement it twice. Remember, once in a clear, once in the lightning KMP. So Right. We have done it in a clear a few months ago, and we are currently doing it in the Lightning KMP, so in the Phoenix.

796
00:53:11.145 --> 00:53:15.805
I think it's a matter of weeks, months. Let's say more of a matter of a few months.

797
00:53:18.329 --> 00:53:19.069
And the

798
00:53:20.569 --> 00:53:24.505
so the the what it offers you basically, it's a static address. It's like your

799
00:53:24.904 --> 00:53:25.404
old

800
00:53:25.704 --> 00:53:32.525
beacon address that you can put everywhere on your, wherever you want, and it doesn't change, and it allows you to receive lightning payments.

801
00:53:33.109 --> 00:53:33.609
And,

802
00:53:34.390 --> 00:53:37.130
it's it would make the Phoenix server

803
00:53:37.509 --> 00:53:42.515
demo even more nice because basically you just start the daemon, it just prints,

804
00:53:43.295 --> 00:53:45.315
an address and then you can put this

805
00:53:45.694 --> 00:53:46.355
and like

806
00:53:47.214 --> 00:53:48.515
for, to receive donations,

807
00:53:50.420 --> 00:53:51.080
like, donations

808
00:53:51.860 --> 00:53:52.100
on the

809
00:53:52.900 --> 00:53:53.720
on on wherever,

810
00:53:54.500 --> 00:53:57.960
it's so simple. You just put your Finnish server

811
00:53:58.415 --> 00:54:01.455
somewhere on your node. You don't even need to to to,

812
00:54:01.935 --> 00:54:11.550
to bother with firewall or whatever. It just sits somewhere and connects to the Internet, and then you can paste your your static address and receive, receive it.

813
00:54:11.930 --> 00:54:14.910
It's it's the same UX basically as a regular

814
00:54:15.770 --> 00:54:16.750
beacon address.

815
00:54:17.244 --> 00:54:18.444
The thing is and it's

816
00:54:20.765 --> 00:54:22.385
it uses a lot of tech

817
00:54:23.964 --> 00:54:24.464
because

818
00:54:25.190 --> 00:54:27.849
what it does essentially when you pay

819
00:54:28.710 --> 00:54:30.250
a static address like this,

820
00:54:30.790 --> 00:54:36.835
your your the sending wallet is going to ask is going to go through the Lightning Network.

821
00:54:37.295 --> 00:54:39.955
It sends a message. It's not a payment. It's a message

822
00:54:40.655 --> 00:54:45.310
to to reach the destination node and ask for an invoice, and then it's gonna pay the invoice.

823
00:54:45.849 --> 00:54:47.710
So there are 2 round trips,

824
00:54:48.250 --> 00:54:56.174
which also had the added benefits that it's kind of like a probing, like you can check whether the destination is whichever before asking the invoice.

825
00:54:56.474 --> 00:54:57.295
A lot of,

826
00:54:59.580 --> 00:55:02.320
lightning products currently do actually

827
00:55:02.700 --> 00:55:03.600
manual probing.

828
00:55:05.885 --> 00:55:06.625
This allows

829
00:55:07.165 --> 00:55:12.785
us to wake up the mobile in the case of Phoenix because we know that the payment is going to happen.

830
00:55:14.089 --> 00:55:15.710
Like, so there are a lot of

831
00:55:16.970 --> 00:55:20.430
Right. So does that mean I can receive if I don't have the app open?

832
00:55:21.635 --> 00:55:23.415
It's already the case. You know?

833
00:55:24.035 --> 00:55:26.295
You can try to turn off Phoenix.

834
00:55:26.675 --> 00:55:41.494
I mean, to generate an invoice, to share an invoice and then turn off Phoenix. It's gonna wake up just in time Got it. To receive the payment. But the problem is that you still have to generate an invoice for that payment. Right. Every time I gotta generate I gotta open that, generate an invoice, send it. So in the case of Phoenix,

835
00:55:43.474 --> 00:55:45.150
we're gonna wake it up,

836
00:55:45.950 --> 00:55:46.849
just in time,

837
00:55:48.029 --> 00:55:52.510
to to create the invoice. This is going to to happen automatically. You won't be,

838
00:55:53.485 --> 00:55:56.365
no interaction necessary at that point, and then,

839
00:55:56.685 --> 00:55:58.465
the payment was going to go through.

840
00:55:59.645 --> 00:56:00.145
So

841
00:56:00.845 --> 00:56:05.770
yeah. The goal is to have a very, very similar experience to, to receiving a bunch of payments.

842
00:56:06.630 --> 00:56:07.130
So,

843
00:56:08.950 --> 00:56:12.890
like, I mean okay. So I'm, like, I've been excited about Bold 12 for

844
00:56:14.855 --> 00:56:15.915
many years now.

845
00:56:17.895 --> 00:56:21.195
Like, how close are we from that experience actually happening?

846
00:56:21.930 --> 00:56:28.910
Oh, yeah. We are close. I mean, we are if I mean, we well, we we don't we don't have the habit to make announcements of announcements,

847
00:56:30.994 --> 00:56:34.535
but, that's what we are working on currently. That's our main

848
00:56:34.835 --> 00:56:35.974
next main,

849
00:56:37.555 --> 00:56:38.430
raise feature.

850
00:56:39.309 --> 00:56:39.809
The

851
00:56:40.190 --> 00:56:43.569
the only thing is that this is network wide.

852
00:56:44.030 --> 00:56:46.369
So just because Phoenix supports it

853
00:56:46.855 --> 00:56:53.195
doesn't mean that you can do We need the sender to support it and the routing We need everyone to support it. We need everyone to support it.

854
00:56:56.759 --> 00:56:58.359
Like, I don't know if you have been using,

855
00:56:58.920 --> 00:56:59.420
Kraken

856
00:56:59.880 --> 00:57:02.700
with auto lightning feature, but you have to

857
00:57:03.055 --> 00:57:07.635
to to input a new invoice every time you want to make, to send parents of our lightning.

858
00:57:08.255 --> 00:57:08.995
That's really

859
00:57:10.335 --> 00:57:11.155
that's great.

860
00:57:11.740 --> 00:57:12.240
So

861
00:57:12.620 --> 00:57:17.920
Yeah. Yeah. We would need them to implement that too and all the exchanging on that. So that takes time.

862
00:57:19.225 --> 00:57:25.705
Like, specifically, the sender side needs to be able to support. Yeah. I mean, the sender side, but also the network because, you know, it's it's,

863
00:57:26.105 --> 00:57:31.549
it uses onion messages. So messages has to be have to be routed in the network.

864
00:57:32.010 --> 00:57:39.474
We can skip some nodes. Not everyone has to update, but it's it's better if, you know a large amount, a decent amount for reliability reasons.

865
00:57:40.734 --> 00:57:42.515
Okay. So Phoenix server

866
00:57:42.815 --> 00:57:45.155
is this idea of taking the ease of use

867
00:57:45.770 --> 00:57:50.590
of Phoenix Wallet and putting it in an always on server environment. Yeah.

868
00:57:51.690 --> 00:57:55.515
Let's chat about I mean, because you released this last week. I mean, on the surface, it

869
00:57:56.555 --> 00:57:57.055
seems,

870
00:57:57.914 --> 00:58:00.734
absolutely massive, incredibly useful to a lot of people,

871
00:58:01.275 --> 00:58:05.910
particularly, you know, this idea that you don't have to worry about inbound liquidity,

872
00:58:07.090 --> 00:58:09.670
that that you guys handle that automatically,

873
00:58:10.210 --> 00:58:11.350
for the end user.

874
00:58:12.505 --> 00:58:17.485
Like, what's the quick what's the quick pitch on Phoenix Server? Like, how do you how do you think this

875
00:58:17.945 --> 00:58:21.005
is gonna affect kind of the the Bitcoin landscape?

876
00:58:21.740 --> 00:58:22.240
So

877
00:58:24.380 --> 00:58:27.520
basically, it's just, it's exactly like Phoenix mobile

878
00:58:27.900 --> 00:58:32.135
except that you interact with it not with pushing buttons on the

879
00:58:32.595 --> 00:58:43.690
on the on screen, but just sending HTTP codes. So it's it just bring the ease of use of, Phoenix wallet, but for developers who can build any lightning connected,

880
00:58:46.480 --> 00:58:49.885
services. And we have added a few features,

881
00:58:50.425 --> 00:58:51.325
around because

882
00:58:52.025 --> 00:58:54.045
a lot of these potential applications

883
00:58:54.345 --> 00:58:54.845
involve

884
00:58:56.290 --> 00:58:56.790
receiving.

885
00:58:58.050 --> 00:59:03.110
It's it's often receiving more than, like, from merchants receiving more funds than sending.

886
00:59:03.810 --> 00:59:09.255
It can be both, but so we added some a few features to make it really completely transparent.

887
00:59:09.954 --> 00:59:10.454
So

888
00:59:11.075 --> 00:59:13.974
you for for developers, it allows you to

889
00:59:14.890 --> 00:59:19.230
interact with lightning with absolutely no headache. It's like exactly like you would

890
00:59:19.610 --> 00:59:21.470
if you if you build a traditional

891
00:59:22.215 --> 00:59:27.595
merchant website, you would plug into Stripe and then I like so like 2 ifttp calls and

892
00:59:27.975 --> 00:59:28.875
and and one callback.

893
00:59:29.415 --> 00:59:30.740
It's exactly the same

894
00:59:31.300 --> 00:59:43.735
and in an in a cost effective way. So we made like for Phoenix, so what if we make all the trade offs except the one that is self custody. So we allow ourselves to to

895
00:59:44.515 --> 00:59:45.015
to

896
00:59:47.660 --> 00:59:49.280
to to do some trust,

897
00:59:50.700 --> 00:59:53.280
but we put the limit at self custody.

898
00:59:55.724 --> 00:59:57.345
So, like, a new merchant could

899
00:59:57.885 --> 01:00:06.490
could run this, and they just start immediately receiving lightning payments. They pay you 1% as the LSP, and that's that. Exactly. So not only is it easy,

900
01:00:07.190 --> 01:00:13.210
from an integration point of view, but you also benefit from the well known reliability that Phoenix offers.

901
01:00:13.585 --> 01:00:14.805
So when you

902
01:00:15.185 --> 01:00:16.145
when you use,

903
01:00:16.465 --> 01:00:19.445
Phoenix server to receive payments as a merchant,

904
01:00:19.825 --> 01:00:27.830
you your your inbound liquidity is the inbound liquidity of the async like node. So you can you're not gonna have any issues,

905
01:00:28.290 --> 01:00:32.630
around that. I mean, so it's a great burden to remove off your shoulders

906
01:00:33.105 --> 01:00:36.885
if you want to receive funds on anything. Wait. So right now with Phoenix Wallet,

907
01:00:37.585 --> 01:00:42.950
I let I let's say I put I put 10,000,000 sats into Phoenix Wallet, and I have 10,000,000 stats

908
01:00:43.250 --> 01:00:45.829
of outbound liquidity. But for inbound liquidity,

909
01:00:46.289 --> 01:00:49.829
I have to pay an on chain fee when I need to increase my inbound liquidity.

910
01:00:50.795 --> 01:00:55.535
How is that handled on Phoenix server? Like, am I not in that situation? Am I not,

911
01:00:56.795 --> 01:00:58.470
am I not paying that on chain fee?

912
01:00:59.349 --> 01:01:00.810
So on Phoenix server,

913
01:01:03.030 --> 01:01:05.885
let let's let's do the the actual steps.

914
01:01:06.445 --> 01:01:16.279
What's going to happen if you start with not with a brand new wallet. Okay. Brand new wallet. I'm a merchant. I have no Bitcoin. I won't accept Bitcoin. So you just you start the daemon.

915
01:01:16.740 --> 01:01:20.039
Okay. Then you're gonna use the API to create an invoice.

916
01:01:20.579 --> 01:01:22.599
Then a payment is going to arrive.

917
01:01:24.099 --> 01:01:25.000
At that point,

918
01:01:26.165 --> 01:01:27.785
if the payment is,

919
01:01:29.285 --> 01:01:34.505
more than the mining fees required to create the channel, then a create a channel is going to be created

920
01:01:35.200 --> 01:01:39.940
and, the mining fees are going to be are going to be deducted from the amount you receive.

921
01:01:40.240 --> 01:01:44.099
Okay. But and in the same operation, we are going to also add

922
01:01:45.355 --> 01:01:46.494
inbound liquidity,

923
01:01:47.194 --> 01:01:49.615
with the default of 2,000,000 SATs,

924
01:01:50.315 --> 01:01:51.694
with a 1% fee.

925
01:01:52.050 --> 01:01:58.230
Okay. Okay. So this, we are gonna do 1 unchain transaction. It's going to create a channel. It's gonna give you

926
01:01:58.610 --> 01:02:00.645
a lot of inbound and that's

927
01:02:01.025 --> 01:02:01.525
it.

928
01:02:02.625 --> 01:02:05.745
That's the easy scenario. Now another scenario where

929
01:02:06.545 --> 01:02:19.385
What if my next so then okay so that happens, and then someone walks into my store or goes online to my store and then pay tries to pay me 4,000,000 sats, Right? More than my inbound liquidity. What happens in that situation?

930
01:02:19.685 --> 01:02:22.425
Well, in that situation, it's gonna be

931
01:02:22.725 --> 01:02:26.940
the channel is going to be too small. So another on chain selection is going to be required.

932
01:02:27.320 --> 01:02:32.780
You're gonna receive the 4,000,000 in that, operation, and you're gonna have add also 2,000,000Â¢.

933
01:02:33.565 --> 01:02:40.625
So the merge the merchant's still paying that on chain fee, though. Right? Yeah. They have to pay it. But the thing is so if your average,

934
01:02:42.309 --> 01:02:49.450
if your the average invoice that your customers pay is 2 or 4,000,000 SATs, you will then want to increase the

935
01:02:49.829 --> 01:02:50.305
default

936
01:02:50.865 --> 01:02:56.085
liquidity amount to be much larger than that. Otherwise, it doesn't make sense. You're gonna have to pay on chain fees all the time.

937
01:02:56.704 --> 01:03:03.520
On the other hand, if you receive that amount, the the weight of the on chain fees is quite low in relative terms.

938
01:03:03.900 --> 01:03:09.995
So Right. It's up to you. But basically So in practice, it works very similar to the actual wallet does?

939
01:03:10.375 --> 01:03:20.020
No. Because I mean, yes. It's similar, but it's not exactly the same because on Phoenix, you wouldn't you you are not currently able to request invalid query at the same time as,

940
01:03:21.120 --> 01:03:33.010
creating a channel or a splice. So it requires 2 transactions. That's a major difference. And the other major difference is that let's suppose now that so you start from nothing and you you try to receive only a 1000 sats.

941
01:03:33.870 --> 01:03:36.050
It's not enough to cover for the unchanged production.

942
01:03:36.590 --> 01:03:40.795
On the Phoenix mobile, we would simply reject the payments because it's too expensive.

943
01:03:41.095 --> 01:03:45.995
Like, it we it's, the main fee is too expensive. You cannot cover the cost with this payment.

944
01:03:46.615 --> 01:03:47.835
On the Phoenix server,

945
01:03:48.450 --> 01:03:52.870
this amount goes to your, what we call a fee credit. It's gonna be

946
01:03:53.170 --> 01:03:55.190
used to pay future money fees.

947
01:03:55.815 --> 01:03:58.234
That means that if you're if

948
01:03:58.695 --> 01:04:05.980
like, typically, I guess that on NoStar, the typical tip is not going to be 2,000,000 sat. It's gonna be much smaller than that. Right.

949
01:04:07.240 --> 01:04:08.220
In this situation,

950
01:04:08.520 --> 01:04:09.020
then

951
01:04:09.320 --> 01:04:11.580
all the small tips would aggregate.

952
01:04:12.120 --> 01:04:15.915
And as soon as you reach the amount needed to open a channel with

953
01:04:16.855 --> 01:04:21.115
2,000,000 sat inbound liquidity by default or possibly more if you configure them differently,

954
01:04:21.560 --> 01:04:22.300
then you're

955
01:04:22.600 --> 01:04:26.700
gonna end up with a big channel and receive all the future tips in this channel.

956
01:04:27.000 --> 01:04:30.300
And you would have And then you take out the fee credit at that point.

957
01:04:30.645 --> 01:04:32.665
Exactly. And so the

958
01:04:33.285 --> 01:04:35.605
the all the small tips that,

959
01:04:36.005 --> 01:04:38.345
would have been rejected on Phoenix mobile,

960
01:04:38.869 --> 01:04:44.089
They are taken and they are used to pay the mining fees. So, every single Satoshi that you receive,

961
01:04:44.470 --> 01:04:50.115
it's not lost because it's it's going to pay to contribute to paying this the fee for your channel.

962
01:04:50.415 --> 01:04:54.355
That's a major difference because it means that you don't have to worry about,

963
01:04:54.990 --> 01:04:55.650
you know,

964
01:04:56.109 --> 01:04:57.010
threshold effects.

965
01:04:57.470 --> 01:04:59.170
Everything appears to be linear.

966
01:05:00.349 --> 01:05:08.685
So you can, as a merchant, you don't have to to pay attention to these details at all. You just have to to think in terms of

967
01:05:11.280 --> 01:05:17.780
relative fee total fee. And our goal is to bring it as close as 1% overall as possible. And it's

968
01:05:18.565 --> 01:05:24.265
you can see the the the calculations in our website. But basically, it's it's between 1 2%

969
01:05:24.565 --> 01:05:26.665
depending on your settings and the

970
01:05:27.240 --> 01:05:32.460
mining fees. Got it. Now am I correct to assume with the focus on bolt 12 that

971
01:05:35.365 --> 01:05:37.145
that is there any priority now

972
01:05:37.605 --> 01:05:41.980
with this with this Phoenix server, is there any priority to add lightning address support to that?

973
01:05:45.980 --> 01:05:47.680
We want to add something

974
01:05:48.060 --> 01:05:51.085
that's I don't know if you, came across the,

975
01:05:52.265 --> 01:05:52.765
the,

976
01:05:54.744 --> 01:05:56.205
the DNS proposal,

977
01:05:56.665 --> 01:05:57.964
from Bastian that,

978
01:05:58.585 --> 01:06:01.500
he put together. I think it's end of 2023.

979
01:06:02.759 --> 01:06:06.279
Basically, we want to offer something functionally equivalent to,

980
01:06:07.000 --> 01:06:07.900
to add an address,

981
01:06:08.200 --> 01:06:08.700
but

982
01:06:09.154 --> 01:06:10.055
much more private.

983
01:06:10.515 --> 01:06:13.815
The problem with lightning address, it from a

984
01:06:14.115 --> 01:06:15.734
functional point of view is great,

985
01:06:16.194 --> 01:06:16.694
but

986
01:06:17.620 --> 01:06:24.680
it leaks a lot of information about the sender and the recipient. Because you're asking your server and you the sender,

987
01:06:26.325 --> 01:06:29.945
when like, if you're an LSP like us, if you if we run

988
01:06:32.085 --> 01:06:34.505
a lightning address service for our Phoenix users,

989
01:06:34.970 --> 01:06:35.470
then

990
01:06:35.770 --> 01:06:36.270
whoever

991
01:06:37.610 --> 01:06:48.125
wants to send the payment to a Phoenix users for to a Phoenix user using their lightning address would reveal their IP to us, the IP address to us because they would have to contact our service.

992
01:06:48.505 --> 01:06:53.405
And they would and yep. So that's a big problem. And so there are privacy issues with that,

993
01:06:53.810 --> 01:06:55.270
and we believe that,

994
01:06:56.050 --> 01:07:00.850
leveraging bot 12 and static addresses, we can match make much, much, much,

995
01:07:01.490 --> 01:07:01.990
better,

996
01:07:03.095 --> 01:07:03.995
technical solution,

997
01:07:04.375 --> 01:07:05.755
which is also exactly

998
01:07:06.295 --> 01:07:07.435
as easy to integrate

999
01:07:07.735 --> 01:07:07.975
for,

1000
01:07:09.175 --> 01:07:11.755
for everybody who wants to to play with that

1001
01:07:12.110 --> 01:07:13.890
because it's just a static information.

1002
01:07:14.350 --> 01:07:21.330
So you just have to resolve it using DNS or using whatever you want and, it does exactly the same.

1003
01:07:22.875 --> 01:07:25.055
So that that's the reason why we haven't,

1004
01:07:25.435 --> 01:07:32.990
supported lightning address. It's not related to not being able to wake up Phoenix because we already do it when we do a regular lighting payment

1005
01:07:33.370 --> 01:07:35.790
specifically because of, privacy concerns.

1006
01:07:36.810 --> 01:07:47.535
And Right. Because right now in Phoenix, well, I can send a lightning address. I can't receive to it. You can send because if you want to send, that's your problem. We, your Phoenix is going to contact the,

1007
01:07:48.309 --> 01:07:58.905
the whoever is the server. The web server. Yeah. So you're responsible request an invoice. Exactly. But we don't want to have that information ourselves. So that's why we don't offer this feature.

1008
01:07:59.365 --> 01:08:02.825
And if I have Tor enabled on Phoenix Wallet and I'm paying a

1009
01:08:03.685 --> 01:08:10.260
lightning address, then it's going through Tor when it requests that. I believe, yes. At at the very least, if you have all bot on your phone,

1010
01:08:10.560 --> 01:08:13.690
yes. I will have to double check, but I I believe it's

1011
01:08:14.904 --> 01:08:16.505
Okay. That makes sense to me.

1012
01:08:17.145 --> 01:08:24.350
Bolt 12. Hopefully I mean, I had Steve Lee on the show a couple weeks ago, and he's quite optimistic about bolt 12,

1013
01:08:25.690 --> 01:08:28.910
from the LDK side. So Yeah. Yeah. They are

1014
01:08:29.625 --> 01:08:31.724
definitely moving forward with this.

1015
01:08:32.505 --> 01:08:33.005
Awesome.

1016
01:08:35.705 --> 01:08:40.390
Yeah. I mean, I think this has been a great chat. I mean, we're a little bit over the hour mark now.

1017
01:08:41.730 --> 01:08:42.470
I think,

1018
01:08:44.050 --> 01:08:53.895
I think Phoenix d like, this Phoenix server idea could be quite it seems quite compelling. It's like, for the donation use case, for the merchant use case,

1019
01:08:54.595 --> 01:09:01.460
I can see it being implemented in BTC pay server to make it quite easy for people. That that would be the perfect use case. I mean, that definitely

1020
01:09:02.720 --> 01:09:03.540
really for

1021
01:09:06.745 --> 01:09:07.885
to as a way

1022
01:09:08.265 --> 01:09:08.765
to

1023
01:09:09.225 --> 01:09:09.725
to

1024
01:09:10.345 --> 01:09:11.325
just try out,

1025
01:09:11.705 --> 01:09:12.845
recently letting payments,

1026
01:09:14.025 --> 01:09:14.525
for

1027
01:09:17.580 --> 01:09:20.320
not a reasonably sized business, let's say.

1028
01:09:20.700 --> 01:09:23.500
I think it's really, really, very, compelling,

1029
01:09:24.755 --> 01:09:25.255
offering.

1030
01:09:26.435 --> 01:09:26.935
Awesome.

1031
01:09:27.395 --> 01:09:35.540
I have I have one last question for you, actually. And I was like Yep. Going back to I guess it's it's it's relevant to both Phoenix Wallet and Phoenix server.

1032
01:09:36.560 --> 01:09:38.820
So let's say, like, worst case scenario

1033
01:09:39.199 --> 01:09:40.580
it goes back to trade offs.

1034
01:09:41.065 --> 01:09:41.965
Worst case scenario,

1035
01:09:43.465 --> 01:09:46.045
the phoenix the phoenix node goes offline,

1036
01:09:47.065 --> 01:09:48.125
for whatever reason.

1037
01:09:48.760 --> 01:09:51.500
We don't have to speculate for for why it happened.

1038
01:09:52.360 --> 01:09:57.400
But everyone, you know, they they have a channel open with this with this node. How does the end user

1039
01:09:58.425 --> 01:10:07.290
you know, I have Phoenix Wallet. I have 10,000,000 sats there. It's in a channel with the Phoenix LSP node. That node goes down. How does that look for the end user? Okay.

1040
01:10:08.949 --> 01:10:10.409
So firstly, before that,

1041
01:10:11.670 --> 01:10:14.329
that everybody needs to be aware is in the

1042
01:10:15.030 --> 01:10:16.489
security model of Phoenix,

1043
01:10:17.015 --> 01:10:18.395
you need to have Phoenix

1044
01:10:18.695 --> 01:10:19.195
installed

1045
01:10:20.135 --> 01:10:29.300
on your mobile or one mobile that you own with connecting with access to the Internet all the time. It's not a code storage wallet. It has to be able to

1046
01:10:29.600 --> 01:10:34.580
to, access the blockchain once every 2 weeks. That's very, very important because,

1047
01:10:35.425 --> 01:10:35.925
so

1048
01:10:36.465 --> 01:10:37.764
as long as you have this,

1049
01:10:39.344 --> 01:10:40.165
then you're safe.

1050
01:10:41.344 --> 01:10:50.900
Otherwise, you could broadcast an old state and take the money. Yeah. Or anyone who has access to the node. Yeah. Exactly. And, and also, this means that you have the

1051
01:10:51.280 --> 01:10:53.940
the you you can first close the channel

1052
01:10:54.385 --> 01:10:55.805
whenever you want.

1053
01:10:56.145 --> 01:11:05.560
Maybe we're offline or maybe we are I don't know. We have been compromised or whatever. For some reason, you want to to just it's a way for you to fire us basically as an LSP

1054
01:11:05.940 --> 01:11:08.040
and just take your money back. So

1055
01:11:09.140 --> 01:11:19.730
so the way I see it so let's say one day we we go down or we we just go offline and don't respond any anymore. Business goes out of business. Yeah. Exactly.

1056
01:11:20.909 --> 01:11:21.409
If,

1057
01:11:22.510 --> 01:11:24.369
I I would imagine it's a more

1058
01:11:25.215 --> 01:11:32.915
problematic situation because if we just go go out of business, we would prepare it. Right? Right. So this is just And I could be assholes about it. Exactly.

1059
01:11:33.440 --> 01:11:36.980
So let's say we're just, we do just disappear from the

1060
01:11:37.440 --> 01:11:39.540
from, from the Internet. Right.

1061
01:11:40.080 --> 01:11:52.645
As long as you have your mobile with finish install, you're safe. You you you don't have to panic. You you you you're gonna have to force close your channel at some point. It works like just a normal force close? Exactly. You don't have to do it right away.

1062
01:11:53.170 --> 01:11:55.830
I imagine that some people would take over

1063
01:11:56.130 --> 01:11:58.070
or fork our code

1064
01:11:58.530 --> 01:11:59.030
and,

1065
01:11:59.810 --> 01:12:05.115
make a nice tool to to help. I don't know exactly, but there is no rush. There is no need to

1066
01:12:05.735 --> 01:12:06.715
there is no, like,

1067
01:12:07.575 --> 01:12:11.650
delay that you need to count before money is lost or whatever. Because

1068
01:12:12.270 --> 01:12:15.390
what Phoenix shows you and and you every user should,

1069
01:12:15.870 --> 01:12:16.590
if you want to,

1070
01:12:17.905 --> 01:12:37.635
understand how this works, go to the channel details, and you're gonna see your UTXO, and it's yours. And in your channel data, you can see the commit plan transaction. It's it's the transaction that if you publish, it's going to spend this UTXO and give you money back to your wallet. As long as you see this UTXO, you see this transaction, and you know you can publish it, you're fine. So,

1071
01:12:40.094 --> 01:12:42.835
So if I if I go into the payment channel settings

1072
01:12:43.215 --> 01:12:44.755
on Phoenix and I press

1073
01:12:45.590 --> 01:12:48.250
the close all button or the force close all button,

1074
01:12:48.790 --> 01:12:54.810
what happens next? I haven't pressed that button yet. If you if you press the close button Yeah.

1075
01:12:55.295 --> 01:13:06.820
It's just going to be a mutual close, which is What where what on chain address does that go to? Because every time I send to an on chain address in Phoenix, it just automatically splices in. So Yeah. It's going to be,

1076
01:13:09.199 --> 01:13:13.300
an on chain address derived from your seed following, BIP 84.

1077
01:13:13.975 --> 01:13:15.275
Okay? So you just,

1078
01:13:15.895 --> 01:13:38.614
use any normal standard on January, you're gonna find your fans in there. Got it. If you first I used to, like, import it into Sparrow at that point, and it'll be in Sparrow. Exactly. Yeah. Exactly. If you first close your channel, that then it's not going to go directly to your on channel address because you have there has there is a delay. The same delay 2 weeks delay that we have on our side,

1079
01:13:39.395 --> 01:13:41.415
to protect, users from

1080
01:13:41.900 --> 01:13:44.800
fraud from our part, there is the same delay

1081
01:13:45.740 --> 01:13:50.844
for Phoenix. It's it's smaller. It's just 5 days instead of 2 weeks. But for the same reason,

1082
01:13:51.304 --> 01:13:58.284
we need to protect ourselves against our users too. So you're you're gonna have to wait for 5 days before the funds

1083
01:13:59.590 --> 01:14:06.330
go to the wallet. And during these 5 days, the Phoenix needs to be installed because it it it needs to be able to publish

1084
01:14:06.985 --> 01:14:11.485
the transaction that that finally sends the funds to your personal wallet. So basically,

1085
01:14:11.945 --> 01:14:13.725
never uninstall Phoenix

1086
01:14:14.120 --> 01:14:17.500
as long as you have not recovered all the funds, and you'll be fine.

1087
01:14:18.120 --> 01:14:20.460
Got it. Okay. That seems pretty straightforward.

1088
01:14:21.159 --> 01:14:21.659
Pierre,

1089
01:14:22.120 --> 01:14:25.665
this was this was a great chat. I really enjoyed it. I really appreciate

1090
01:14:26.445 --> 01:14:27.985
what you and your team have been building.

1091
01:14:30.130 --> 01:14:30.790
I mean,

1092
01:14:31.330 --> 01:14:38.950
there's a lot of us there's a lot of us out here that that rely on on what you guys are building, and and you guys have really pushed the industry forward. Thank you.

1093
01:14:39.725 --> 01:14:41.905
Do you have any final thoughts before we wrap?

1094
01:14:43.485 --> 01:14:44.305
I I think,

1095
01:14:45.405 --> 01:14:51.170
you know, without being a lot of changes, in, Lightning and Infinix over the past year.

1096
01:14:51.870 --> 01:14:53.489
Bolt 12 is going to be a huge

1097
01:14:54.750 --> 01:14:55.250
milestone.

1098
01:14:55.710 --> 01:14:57.225
Now one of the,

1099
01:14:58.085 --> 01:14:58.585
updates

1100
01:15:00.245 --> 01:15:05.945
coming up, it's related to Taproot. We have done one part with, the swaps, but the channel,

1101
01:15:06.650 --> 01:15:10.590
transactions are going to be taboot taboot 2, which means that footprint

1102
01:15:11.690 --> 01:15:12.170
of,

1103
01:15:13.050 --> 01:15:14.489
your wallet is going to be

1104
01:15:15.235 --> 01:15:18.615
it's not going to stand out on the blockchain as much as it does currently.

1105
01:15:19.315 --> 01:15:28.260
So the technology is maturing. Phoenix is maturing. And Like right now, it's pretty obvious that it's a Phoenix wallet. Right? It used to be obvious that it's Phoenix.

1106
01:15:29.040 --> 01:15:31.860
Now it's obvious that it's a Lightning wallet.

1107
01:15:32.400 --> 01:15:33.860
And after that, it's

1108
01:15:34.385 --> 01:15:35.344
just going to look like,

1109
01:15:36.864 --> 01:15:37.364
like

1110
01:15:37.824 --> 01:15:40.565
a a stand out p 2 p 2 tr wallet.

1111
01:15:41.105 --> 01:15:43.890
It's not particularly private, but it doesn't stand out.

1112
01:15:44.850 --> 01:15:45.730
So it's a huge

1113
01:15:46.290 --> 01:15:48.230
all the privacy features that we

1114
01:15:48.930 --> 01:15:54.435
unfortunately, that those are the most difficult to do. So they they come at the end, but they are they are finally,

1115
01:15:54.815 --> 01:15:56.275
yeah, definitely coming.

1116
01:15:57.375 --> 01:15:59.155
Awesome. Well, thank you again.

1117
01:16:00.670 --> 01:16:01.070
And,

1118
01:16:01.710 --> 01:16:07.250
you have my contact information now. If I can help in any way, don't hesitate to reach out. Cool. And,

1119
01:16:07.965 --> 01:16:10.545
it was a pleasure. Thank you for having me. Bye.

1120
01:16:10.925 --> 01:16:12.145
Awesome. Thank you, Pierre.

1121
01:16:12.764 --> 01:16:16.145
I wanna do a huge shout out to the freaks who joined us in,

1122
01:16:16.685 --> 01:16:22.110
the live chat. You guys make the show unique. You guys make this show special. Thank you.

1123
01:16:22.730 --> 01:16:26.190
And a huge shout out to all the freaks who continue to support the show.

1124
01:16:27.054 --> 01:16:28.755
We're ad free, sponsor free,

1125
01:16:30.895 --> 01:16:31.295
and,

1126
01:16:31.855 --> 01:16:36.240
your donations your donations really do help. So thank you for sending your hard earned sets

1127
01:16:38.160 --> 01:16:41.620
to dispatch and and and keep us going. We have,

1128
01:16:42.080 --> 01:16:51.045
the top three supporters this week was Eric 99 with a 100,000 sets, 8 Myth Randur with 15,000 stats, and TKC TV with 10,000 stats.

1129
01:16:52.225 --> 01:16:59.000
That includes podcasting 2 point o and Zaps that come into this to the live stream. I I combine them now,

1130
01:16:59.699 --> 01:17:07.195
into one shout out. And next week, same time, same day, Tuesday, 1700 UTC. We're gonna have Tony from Unity Wallet,

1131
01:17:07.815 --> 01:17:10.555
joining us. So definitely come join us for that.

1132
01:17:11.015 --> 01:17:13.515
And, I appreciate you all. Thanks, Pierre.

1133
01:17:13.969 --> 01:17:14.469
Bye.

1134
01:20:36.010 --> 01:20:41.070
That track was Life's a Beach by Django Django. Love you freaks. Hope you enjoyed

1135
01:20:41.610 --> 01:20:45.454
this rip, and I'll see you next week. Stay humble stack sets.