Nov. 23, 2021
CD45: the future of mobile lightning wallets with @ericsirion, @akumaigorodski, and @fiatjaf
EPISODE: 45
BLOCK: 711009
PRICE: 1752 sats per dollar
TOPICS: the future of mobile lightning wallets, federated chaumian ecash, el salvador experience, hosted channels, IMMORTAN, simple bitcoin wallet, lightning liquidity, private routing, user experience, better wallet names, jupiter has a lot of moons
@ericsirion: https://twitter.com/@ericsirion
@akumaigorodski: https://twitter.com/akumaigorodski
@fiatjaf: https://twitter.com/fiatjaf
streamed live every tuesday:
https://citadeldispatch.com
twitch: https://twitch.tv/citadeldispatch
bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos
podcast: https://anchor.fm/citadeldispatch
telegram: https://t.me/citadeldispatch
support the show: https://tippin.me/@odell
stream sats to the show: https://www.fountain.fm/
join the chat: http://citadel.chat/
00:00 - The rise of cryptocurrency and its potential impact on currencies and nations
03:19 - The future of mobile lightning wallets and their importance
08:33 - Introduction to Simple Bitcoin Wallet and its goal of making lightning payments more successful
54:09 - Proposal for a special protocol for federations to link multiple federations and route payments between them
55:19 - Importance of Lightning integration with federations for permissionless access and starting your own federation
01:01:38 - Benefits of Lightning integration for interoperability and direct interaction with other Lightning wallets and merchants
01:44:44 - Discussion about a questionable advertisement
01:45:15 - Opinions on whether the advertisement looked like a scam
01:47:01 - Comparison of the advertisement to Bitcoin in the past
01:48:01 - Discussion about the people at the booth
01:49:03 - Final thoughts on lightning and privacy
01:50:08 - Appreciation for the guests and invitation for future collaboration
01:50:25 - Closing remarks and upcoming episodes
WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 3/21/2024 8:14:58 PM
Duration: 6974.981
Channels: 1
1
00:00:00.240 --> 00:00:06.100
More area that I hope nation states start paying greater attention to is the rise of cryptocurrency.
2
00:00:07.285 --> 00:00:08.725
Because what looks like,
3
00:00:09.125 --> 00:00:10.505
a very interesting
4
00:00:10.805 --> 00:00:12.505
and and somewhat exotic,
5
00:00:13.205 --> 00:00:13.764
effort to,
6
00:00:14.980 --> 00:00:16.119
literally mine,
7
00:00:16.900 --> 00:00:19.800
new coins in order to trade with them
8
00:00:20.180 --> 00:00:22.520
has the potential for undermining,
9
00:00:23.220 --> 00:00:23.720
currencies,
10
00:00:24.365 --> 00:00:25.025
for undermining
11
00:00:25.405 --> 00:00:25.905
the,
12
00:00:26.845 --> 00:00:29.744
role of the dollar as the reserve currency
13
00:00:30.125 --> 00:00:30.945
for destabilizing
14
00:00:31.805 --> 00:00:35.590
nations, perhaps starting with small ones but going much larger.
15
00:00:36.050 --> 00:00:42.310
So when we think about this new environment in which we find ourselves that we've been discussing for the last
16
00:00:42.835 --> 00:00:43.735
some minutes,
17
00:00:44.595 --> 00:00:46.775
we can't just think about nation states.
18
00:01:23.785 --> 00:01:29.200
Happy Bitcoin Tuesday, freaks. It's your boy, Matt O'Dell, here for another Citadel dispatch,
19
00:01:29.680 --> 00:01:35.060
Dispatch. The interactive live show about Bitcoin distributed systems privacy and open source software.
20
00:01:35.680 --> 00:01:39.634
That clip out you just heard was from failed presidential candidate Hillary Clinton
21
00:01:40.415 --> 00:01:40.915
explaining
22
00:01:41.295 --> 00:01:43.795
the absolute power and significance of Bitcoin
23
00:01:44.095 --> 00:01:45.795
to the new economy forum.
24
00:01:47.270 --> 00:01:53.610
Huge shout out to the ride or die freaks who are joining us in the live chat. I know it's an earlier time than usual,
25
00:01:53.955 --> 00:01:54.775
but I got
26
00:01:55.235 --> 00:02:00.890
a straight fire group of guests to join us today, and we had to make this time work.
27
00:02:01.930 --> 00:02:07.310
Happy Thanksgiving to all the American freaks out there. I know it's a big family week,
28
00:02:07.850 --> 00:02:10.965
for most of us, so make sure you treat your families
29
00:02:11.345 --> 00:02:15.765
with at least some monochrome of respect when you're talking about Bitcoin.
30
00:02:17.560 --> 00:02:26.005
Huge shout out to all the ride or die freaks who continue to support the show and keep it ad free, sponsor free, and purely focused on actionable Bitcoin discussion.
31
00:02:26.465 --> 00:02:30.085
The easiest way to support the show is through podcasting 2.0 apps.
32
00:02:31.080 --> 00:02:33.660
My two favorites are Fountain Podcasts
33
00:02:33.960 --> 00:02:37.980
and Breeze Wallet. Breeze, that's b r e e z.
34
00:02:39.185 --> 00:02:47.765
If you just download one of those apps, you can load it up with Sats, search Citadel dispatch, and you can send Sats directly to my node
35
00:02:48.470 --> 00:02:50.569
as you listen to the show.
36
00:02:51.110 --> 00:02:53.690
You can also support dispatch at cildispatch.com,
37
00:02:54.549 --> 00:02:56.409
either through lightning or through Paynim.
38
00:02:57.075 --> 00:03:00.695
My samurai Paynim is Odell. It is very easy to remember.
39
00:03:01.475 --> 00:03:13.549
So thank you again for supporting the show, and thank you to the ride or dies who continue to join us in the live chat, which, a reminder, I had some people ask me, you can access through Twitter, Twitch, or YouTube, whichever platform you prefer.
40
00:03:14.329 --> 00:03:15.470
With all that said,
41
00:03:15.775 --> 00:03:18.035
we have Citadel dispatch 45
42
00:03:18.335 --> 00:03:18.835
today.
43
00:03:19.855 --> 00:03:24.090
The focus is gonna be on the future of mobile lightning wallets. I expect,
44
00:03:24.550 --> 00:03:25.770
and I think
45
00:03:26.310 --> 00:03:28.170
many Bitcoiners would agree with me,
46
00:03:28.630 --> 00:03:33.795
that the overwhelming majority of new Bitcoiners will come in through phone wallets.
47
00:03:34.575 --> 00:03:35.075
And
48
00:03:35.455 --> 00:03:41.395
on that note, many of them will come in through lightning. So mobile lightning wallets are an extremely important topic
49
00:03:41.730 --> 00:03:44.070
and how we develop them, how we improve them,
50
00:03:44.530 --> 00:03:49.510
how we see them going forward is going to be a very important topic.
51
00:03:50.864 --> 00:03:54.405
I am very excited to have repeat guest, Fiat Jaffe here, prolific
52
00:03:55.344 --> 00:03:56.325
lightning developer
53
00:03:56.704 --> 00:03:58.084
with very strong opinionated,
54
00:03:59.560 --> 00:04:02.460
very strong opinion. How's it going, Fiat, Jeff?
55
00:04:03.320 --> 00:04:04.300
Yeah. It's good.
56
00:04:04.920 --> 00:04:05.660
Not many
57
00:04:06.200 --> 00:04:07.180
prolific contributions
58
00:04:07.560 --> 00:04:09.795
lately, but still strong opinions.
59
00:04:10.655 --> 00:04:13.475
Well, welcome welcome back. Happy to have you again.
60
00:04:14.815 --> 00:04:16.355
We have Anton here,
61
00:04:17.380 --> 00:04:23.880
lead maintainer of Simple Bitcoin Wallet, a mobile on chain and lightning wallet. How's it going, Anton?
62
00:04:25.380 --> 00:04:26.680
It's been fine. Thanks.
63
00:04:27.444 --> 00:04:33.625
Thank you for coming on. And we have Eric Sirion here who has a new proposal for Federated
64
00:04:34.485 --> 00:04:34.985
Chaumian
65
00:04:35.810 --> 00:04:36.710
Lightning Wallets,
66
00:04:37.570 --> 00:04:39.990
that aim to bring more privacy,
67
00:04:41.170 --> 00:04:44.950
and easier UX to mobile lightning wallets. How's it going, Eric?
68
00:04:46.245 --> 00:04:51.625
Quite well. Just came back, from an awesome week in El Salvador where I experienced lightning,
69
00:04:52.165 --> 00:04:53.945
in the real world first time.
70
00:04:54.910 --> 00:04:56.850
Well, I mean, that's a good place to start.
71
00:04:58.950 --> 00:05:01.730
Are Anton or Fiat, Jeff, are either of you in El Salvador?
72
00:05:03.745 --> 00:05:05.284
No. I haven't been there.
73
00:05:05.905 --> 00:05:06.645
No. No.
74
00:05:07.504 --> 00:05:09.365
What was your experience like, Eric?
75
00:05:12.750 --> 00:05:13.250
Like,
76
00:05:13.710 --> 00:05:15.810
the few shops that supported lightning,
77
00:05:16.510 --> 00:05:21.055
like, not everyone did, but the ones that did and were using,
78
00:05:22.955 --> 00:05:23.455
like,
79
00:05:24.474 --> 00:05:25.134
a community
80
00:05:25.435 --> 00:05:26.150
built wallets,
81
00:05:26.710 --> 00:05:28.169
like, Bitcoin Beach Wallet,
82
00:05:28.630 --> 00:05:29.770
all these good things.
83
00:05:31.350 --> 00:05:36.595
They still had some problems with you. Like, people were entering their own amounts they want to pay,
84
00:05:36.975 --> 00:05:37.475
and,
85
00:05:37.935 --> 00:05:46.570
like, it wasn't as smooth as it could be. So I think that we can do a lot better, and I'm looking forward to contribute to that.
86
00:05:47.990 --> 00:05:51.770
Awesome. Yeah. I mean, I I've I've heard a lot of mixed
87
00:05:53.515 --> 00:05:56.335
mixed experiences on the ground, particularly with
88
00:05:56.875 --> 00:05:59.615
the the Chivo wallet, the government wallet,
89
00:06:00.580 --> 00:06:05.639
which I I guess a lot of merchants use because they wanna they wanna instantly convert to US dollars.
90
00:06:09.224 --> 00:06:12.284
Yeah. I didn't want to talk about that. That was just terrible. Like,
91
00:06:13.705 --> 00:06:15.645
Jiro just, didn't work. Like,
92
00:06:16.090 --> 00:06:18.030
the people that figured out how to,
93
00:06:20.090 --> 00:06:21.950
generate lightning invoice on Jibo.
94
00:06:22.570 --> 00:06:25.710
Then they had to fight for huge delays before the
95
00:06:27.365 --> 00:06:29.465
sections was with the air. Like,
96
00:06:30.005 --> 00:06:33.705
that's definitely not a good part of, experiencing lightning in El Salvador.
97
00:06:34.660 --> 00:06:39.960
But Bitcoin Beach, was doing much better. So if you want to visit there, that's the place to go.
98
00:06:40.660 --> 00:06:44.365
I mean, it kinda makes sense. I mean, Bitcoin Beach has been on the ground,
99
00:06:46.105 --> 00:06:50.765
helping merchants and helping users for at least a couple years now,
100
00:06:52.220 --> 00:06:53.600
if not longer. So,
101
00:06:54.220 --> 00:06:56.720
they did did kinda have a head start in El Salvador.
102
00:06:57.660 --> 00:06:59.280
I mean, I thought it was an interesting
103
00:06:59.765 --> 00:07:04.265
interesting spot spot to start because, I mean, El Salvador is a whole country that got
104
00:07:04.725 --> 00:07:05.865
thrown into lightning,
105
00:07:06.885 --> 00:07:07.865
by their president,
106
00:07:10.569 --> 00:07:14.509
and most of them aren't going to use computers. They're gonna be using mobile wallets,
107
00:07:14.889 --> 00:07:18.110
and most of them aren't gonna be using on chain. They're gonna be using lightning.
108
00:07:19.425 --> 00:07:22.565
So I feel like it kind of was a big kick in the ass to the community,
109
00:07:23.985 --> 00:07:24.485
to
110
00:07:25.025 --> 00:07:25.845
really prioritize
111
00:07:26.145 --> 00:07:28.620
better UX and more user friendly,
112
00:07:30.360 --> 00:07:31.660
mobile lightning wallets,
113
00:07:32.840 --> 00:07:36.195
sooner rather than later. Did you also get that that,
114
00:07:36.895 --> 00:07:38.035
that vibe, Eric?
115
00:07:39.215 --> 00:07:50.330
Very much so. And one other thing that showed in El Salvador is that, like, most of the local people, they actually use, like, not self sovereign wallets, but
116
00:07:51.245 --> 00:07:54.944
custodial or semi custodial solutions like, Bitcoin Beach Wallet.
117
00:07:55.365 --> 00:07:55.865
So
118
00:07:56.525 --> 00:08:02.160
and that's exactly what I was thinking when I was developing my ecash idea. And I think,
119
00:08:02.940 --> 00:08:03.760
that's where
120
00:08:05.740 --> 00:08:09.815
and Santon agree with me. And we have many other points we disagree
121
00:08:10.195 --> 00:08:12.615
on, but that's the one thing we might agree on.
122
00:08:13.075 --> 00:08:13.575
Yeah.
123
00:08:13.955 --> 00:08:16.295
I'm I'm very excited to get to the disagreement.
124
00:08:16.845 --> 00:08:17.345
Lightning.
125
00:08:19.220 --> 00:08:23.160
I'm very excited to get to the disagreement. But before we before we get there,
126
00:08:23.540 --> 00:08:24.360
I was thinking,
127
00:08:26.475 --> 00:08:27.854
let's start with
128
00:08:29.435 --> 00:08:31.455
let's start with Anton about
129
00:08:31.995 --> 00:08:36.139
a simple Bitcoin wallet. It's a it's a great wallet right now that exists.
130
00:08:36.839 --> 00:08:40.139
It's available on app stores. You can download the APK directly.
131
00:08:40.825 --> 00:08:41.565
Then let's
132
00:08:41.865 --> 00:08:47.565
the basic structure of the conversation today. Then let's then let's move to your Chaumu Unique cash proposal,
133
00:08:49.480 --> 00:08:55.180
Federated Chow Meany cash proposal, and how you expect how you see it working out in practice,
134
00:08:56.324 --> 00:09:01.225
and then let's dive into open discussion on trade offs and critiques and thoughts.
135
00:09:03.769 --> 00:09:08.510
So, Anton, you wanna start us off? Simple Bitcoin wallet. Why should I use it? What's you know,
136
00:09:09.130 --> 00:09:10.589
why should the freaks care?
137
00:09:12.385 --> 00:09:13.285
Okay. So
138
00:09:13.585 --> 00:09:20.245
I'd say that the grand goal here in developing this thing is to make lightning bolt which
139
00:09:20.690 --> 00:09:21.510
actually works.
140
00:09:22.370 --> 00:09:22.770
And,
141
00:09:23.410 --> 00:09:24.550
by this, I mean,
142
00:09:25.010 --> 00:09:29.910
the wallet where you can send an arbitrary lightning payment and most of the time,
143
00:09:31.305 --> 00:09:32.125
it succeeds.
144
00:09:33.865 --> 00:09:34.925
And I guess
145
00:09:37.145 --> 00:09:38.390
most Lightning users
146
00:09:38.790 --> 00:09:45.130
will agree with me as is currently this is not the case. A lot of payments fail all the time.
147
00:09:45.645 --> 00:09:48.225
And, in my opinion, which is
148
00:09:48.765 --> 00:09:50.385
somewhat based on experience,
149
00:09:51.885 --> 00:09:55.850
this is due to liquidity issues which are present on lightning.
150
00:09:56.390 --> 00:09:56.630
And,
151
00:09:58.150 --> 00:10:05.295
what I mean by liquidity here is channel balances of working capital, which is required to
152
00:10:05.995 --> 00:10:08.335
get your payment through in certain direction.
153
00:10:08.875 --> 00:10:10.815
And this is an issue because
154
00:10:12.130 --> 00:10:13.350
in lightening this,
155
00:10:14.850 --> 00:10:20.070
liquidity, it's not present as some global pool which you can use,
156
00:10:20.545 --> 00:10:21.365
But it's,
157
00:10:22.225 --> 00:10:25.285
like scattered across all these channels, and
158
00:10:25.745 --> 00:10:29.445
levels of liquidity are very different in different directions.
159
00:10:31.500 --> 00:10:32.480
So as a result,
160
00:10:33.180 --> 00:10:35.280
even if we put all the bugs
161
00:10:35.980 --> 00:10:36.720
and inefficiencies
162
00:10:37.180 --> 00:10:37.680
away,
163
00:10:38.115 --> 00:10:40.195
This issue is still present, and,
164
00:10:41.075 --> 00:10:43.895
a lot of payments still fail because of it.
165
00:10:44.435 --> 00:10:44.935
So
166
00:10:46.690 --> 00:10:47.350
my opinion is
167
00:10:49.330 --> 00:10:50.950
if we can develop
168
00:10:51.330 --> 00:10:55.265
any technologies which can help with this, then we should.
169
00:10:55.825 --> 00:10:57.845
And, that's what I've been doing
170
00:10:58.385 --> 00:11:01.445
for the past few months with my library in the world.
171
00:11:01.905 --> 00:11:02.405
And
172
00:11:03.550 --> 00:11:05.890
concrete things I've been working on,
173
00:11:06.990 --> 00:11:09.790
there are 2 things. They're called 1 called
174
00:11:10.365 --> 00:11:14.545
one is called hosted channels, and another one is private routing.
175
00:11:16.045 --> 00:11:19.345
The end goal of both is increasing liquidity levels,
176
00:11:19.970 --> 00:11:20.470
And,
177
00:11:21.330 --> 00:11:29.925
they are both supported by Simple Bitcoin wallet hosted channels, revised version of them. Actually works for about a month now, and,
178
00:11:31.505 --> 00:11:34.165
private routing is coming this year.
179
00:11:34.779 --> 00:11:39.199
So, hopefully, that will help and provide for the best experience possible.
180
00:11:39.899 --> 00:11:43.279
So simple simple Bitcoin wallet is using
181
00:11:43.740 --> 00:11:44.240
a
182
00:11:45.005 --> 00:11:46.945
a mobile focused lightning
183
00:11:47.565 --> 00:11:53.585
implementation in the back end called Immortan. Is are you the lead maintainer of that as well? Yes. That's true.
184
00:11:54.250 --> 00:11:54.750
So
185
00:11:56.010 --> 00:11:58.350
I feel like that's a good place to start. So Immordin,
186
00:12:00.250 --> 00:12:01.390
is mobile focused.
187
00:12:02.345 --> 00:12:07.725
What makes it mobile focused? Like, what is the what is the strategy there when you're developing Amorton?
188
00:12:09.145 --> 00:12:11.725
Well, it's focused on private channels mostly.
189
00:12:12.320 --> 00:12:14.740
So and private and mobile are kinda
190
00:12:16.000 --> 00:12:18.180
synonyms, so so there.
191
00:12:18.640 --> 00:12:18.960
And,
192
00:12:19.520 --> 00:12:22.564
when we have private channels, we can have some
193
00:12:23.345 --> 00:12:30.245
pretty unique privacy properties, like a node which can only have private channels, may not have a stable node ID,
194
00:12:30.870 --> 00:12:31.270
and,
195
00:12:31.750 --> 00:12:36.170
that increases privacy because the that node ID is not shown in invoices.
196
00:12:36.790 --> 00:12:41.175
Every node I connect to can see my wallet that it's some kind of different
197
00:12:41.795 --> 00:12:43.975
remote node and, so on.
198
00:12:44.915 --> 00:12:45.895
So and
199
00:12:47.199 --> 00:12:53.300
So that's like the public key is is is, like, basically rotating. It's not like a fixed public key? Yeah. Yeah. Yeah.
200
00:12:54.639 --> 00:12:56.420
But, of course, the main focus
201
00:12:56.865 --> 00:12:57.365
is,
202
00:12:58.945 --> 00:13:05.204
again, liquidity via private routing. So if we have these private channels, we can make them route payments
203
00:13:05.505 --> 00:13:06.165
as well.
204
00:13:08.050 --> 00:13:13.830
And that's what it's about, really, plus costed channels, of course. So when I download Simple Bitcoin Wallet,
205
00:13:14.945 --> 00:13:19.345
or when any user downloads Simple Bitcoin Wallet, they automatically have a hosted channel
206
00:13:19.825 --> 00:13:20.725
Yes. Open
207
00:13:21.425 --> 00:13:23.365
for 1,000,000 sats to receive
208
00:13:23.850 --> 00:13:30.910
so they can instantly receive funds, which is a common complaint with lightning is that it takes work to be able to receive funds because you don't have inbound liquidity.
209
00:13:31.305 --> 00:13:33.645
Yeah. Inbound liquidity problem. Yes.
210
00:13:34.025 --> 00:13:34.525
So
211
00:13:35.145 --> 00:13:36.045
so what's
212
00:13:36.665 --> 00:13:40.445
what's the high level explanation of hosted channels and their trade offs?
213
00:13:41.670 --> 00:13:42.310
Okay. So,
214
00:13:44.790 --> 00:13:48.890
hosted channel is a way to add some trust between
215
00:13:49.270 --> 00:13:49.770
peers
216
00:13:50.305 --> 00:13:51.685
on the protocol level,
217
00:13:52.465 --> 00:13:57.605
and, I'd say let the rest of the network leverage the trust. And,
218
00:13:58.450 --> 00:14:05.190
technically, it's a new kind of channel, a hosted channel which does not have chain backing in principle.
219
00:14:06.105 --> 00:14:08.205
So this is where trust comes from.
220
00:14:08.985 --> 00:14:10.765
And, it gets implanted
221
00:14:11.225 --> 00:14:12.925
into lightning node and
222
00:14:14.370 --> 00:14:15.910
to the rest of the subsystems
223
00:14:16.290 --> 00:14:23.345
in that node. It looks just like another channel. So it can participate in lightning stuff like
224
00:14:23.904 --> 00:14:27.045
multipart payments and routing and so on.
225
00:14:27.665 --> 00:14:27.985
And,
226
00:14:28.785 --> 00:14:33.370
But it doesn't it doesn't exist on chain. There's no UTXO commitment. Yes. Of course. Yes.
227
00:14:34.170 --> 00:14:35.069
That's the idea.
228
00:14:37.290 --> 00:14:42.089
That's interesting. So it's it's it is it is custodial by design? Or is it
229
00:14:42.834 --> 00:14:45.735
Yes. Of course. It's custodial solution 100%.
230
00:14:46.194 --> 00:14:47.894
So when you have a hosted channel,
231
00:14:49.235 --> 00:14:54.170
I'm trusting the provider of the hosted channel for that hosted channel. Yes. You do.
232
00:14:54.790 --> 00:15:02.415
And I get the benefit of what's my benefit out of that? My benefit is, I guess, lower lower fees. I don't have to worry about an on chain transaction.
233
00:15:03.915 --> 00:15:06.495
Yeah. You get that. You get inbound liquidity
234
00:15:06.795 --> 00:15:09.935
and, all the lightning stuff like privacy
235
00:15:10.475 --> 00:15:10.870
because
236
00:15:11.990 --> 00:15:17.370
routing graph is still on your device, so you can construct routes locally, and
237
00:15:18.045 --> 00:15:23.425
host the channel provider has no idea whom you're paying to. This is one of the differences between
238
00:15:23.885 --> 00:15:24.385
other
239
00:15:25.005 --> 00:15:36.140
custodians who actually know everything about So that would be, like, the difference between something like Wallet of Satoshi, which is just straight custodial, no hosted channels. Yes. Yes. And this privacy is 1. Yes.
240
00:15:36.645 --> 00:15:38.105
You you can't say, like,
241
00:15:39.365 --> 00:15:42.825
Wallet of Satoshi. You you tell them, oh, pay this,
242
00:15:43.845 --> 00:15:46.630
porn website for me, and then they will
243
00:15:47.090 --> 00:15:59.985
know. But with the hosted channel, you just view the route on your phone, and the payment goes, and they don't know where it's going. You can also, like, split the pay do a multipart payment. Yeah. Basically, they they won't they even know that the amount.
244
00:16:00.765 --> 00:16:02.305
An idea is to mimic,
245
00:16:03.140 --> 00:16:13.605
chain backed lightning channels as closely as possible. So, basically, the only thing because the channel misses is chain part. When it comes to lightning, it can be treated like,
246
00:16:14.305 --> 00:16:16.645
a normal lightning channel. So we have
247
00:16:17.105 --> 00:16:17.605
all,
248
00:16:18.385 --> 00:16:20.300
lightning features like privacy,
249
00:16:20.600 --> 00:16:21.500
then the ability
250
00:16:22.280 --> 00:16:31.815
I mean, then the ability of enriching payments. So we can say that we can always say that the payment that we sent or received was never our payment, and we have nothing
251
00:16:32.675 --> 00:16:36.695
know nothing about it, and it just was a root payment, stuff like that.
252
00:16:38.110 --> 00:16:46.450
Okay. And this Apart from the routing privacy, I think the other big benefit of hosted channels is that they are standard. Like, you can choose your
253
00:16:47.825 --> 00:16:57.970
host to channel provider and you're not bound to trust the one app provider like Wallet of Satoshi just because they happen to build the app. But you can choose a friend of yours, for example,
254
00:16:58.510 --> 00:17:01.570
and choose any other host channel capable app.
255
00:17:02.110 --> 00:17:12.835
Yeah. You can choose your own node, for example. It won't be custodial then. Instead of opening the normal channel to your own node, which doesn't make too much sense, you can open a hosted channel,
256
00:17:13.375 --> 00:17:13.875
and
257
00:17:14.269 --> 00:17:15.090
that's cool.
258
00:17:15.549 --> 00:17:17.090
And, of course, you can have,
259
00:17:19.230 --> 00:17:20.529
you can have many,
260
00:17:21.149 --> 00:17:23.815
hosted channel providers in single wallet.
261
00:17:25.335 --> 00:17:26.394
So you can have,
262
00:17:27.414 --> 00:17:36.380
say, 2 or 3 hosted channels which lead to different providers, and you can use all them all all them at once for multipart payments,
263
00:17:36.920 --> 00:17:37.900
which is also
264
00:17:38.440 --> 00:17:39.820
an interest in property,
265
00:17:40.360 --> 00:17:41.180
I'd say.
266
00:17:41.644 --> 00:17:42.125
And,
267
00:17:43.085 --> 00:17:44.664
Wait. So when I
268
00:17:45.085 --> 00:17:48.304
on Symbol Bitcoin Wallet, I automatically have a open
269
00:17:49.000 --> 00:17:50.780
hosted channel to me,
270
00:17:51.160 --> 00:17:53.100
when I when I start the wallet.
271
00:17:53.400 --> 00:17:56.120
So I have inbound liquidity. If I open a channel
272
00:17:56.635 --> 00:18:00.095
if I load it up with on chain funds and I open a channel
273
00:18:00.635 --> 00:18:06.850
Mhmm. Where I can choose any node, right now that's Clearnet, or if I use Orbot, I can choose one that's Tor.
274
00:18:07.710 --> 00:18:08.530
Does it
275
00:18:09.550 --> 00:18:13.934
is that a normal channel, or is that a hosted channel? That's a normal channel. Right?
276
00:18:15.115 --> 00:18:16.075
Well, there is,
277
00:18:16.475 --> 00:18:20.315
hosted channel is denoted as such. There's clear note,
278
00:18:20.955 --> 00:18:25.030
clear text, posted channel, and custodial solution below it.
279
00:18:26.690 --> 00:18:32.235
And normal channel does not have it, so that's how you can discern that. And, yes, of course, if you
280
00:18:32.855 --> 00:18:39.595
open channel to someone by by funding it from your chain wallets, that would be a chain backed channel,
281
00:18:40.360 --> 00:18:41.260
not a hosted
282
00:18:42.520 --> 00:18:43.020
one.
283
00:18:44.280 --> 00:18:44.780
Gotcha.
284
00:18:45.320 --> 00:18:51.205
By the way, my my Ntx bot node, it has the hosted channels of, enabled.
285
00:18:51.585 --> 00:18:53.445
So anyone could, in theory,
286
00:18:53.985 --> 00:18:56.725
have a hosted channel from the LNTP bot node
287
00:18:57.200 --> 00:18:58.900
through their simple Bitcoin wallet.
288
00:18:59.600 --> 00:19:01.460
Yeah. But it works. It works.
289
00:19:02.640 --> 00:19:07.405
Another important thing that probably is the coolest thing about it, in my opinion,
290
00:19:07.865 --> 00:19:11.565
is so far we have been discussing private hosted channels.
291
00:19:12.505 --> 00:19:12.825
And,
292
00:19:13.545 --> 00:19:15.805
just like normal public channels,
293
00:19:17.290 --> 00:19:23.390
2 peers may establish a hosted channel between them and declare it public to the rest of the network.
294
00:19:24.090 --> 00:19:24.590
And
295
00:19:25.755 --> 00:19:27.455
everyone else on the network
296
00:19:27.755 --> 00:19:30.895
can use the channel to route their own payments,
297
00:19:31.195 --> 00:19:34.255
and they can do it without any trust assumptions
298
00:19:34.555 --> 00:19:36.700
or trust assumptions added.
299
00:19:37.240 --> 00:19:39.580
Or in other words, if you are
300
00:19:39.960 --> 00:19:43.340
a sender of payment, and even if you don't like this
301
00:19:43.715 --> 00:19:50.775
hosted channels idea at all, all your channel local channels are backed on chains. Basically, you are using
302
00:19:51.200 --> 00:19:52.820
classic lightning, let's say.
303
00:19:53.280 --> 00:19:58.260
If you see that some hosted channel exists somewhere deep in the network,
304
00:19:59.280 --> 00:19:59.680
there's
305
00:20:00.175 --> 00:20:01.155
it can totally
306
00:20:01.455 --> 00:20:05.235
it is totally safe to use it for your own payments because
307
00:20:06.495 --> 00:20:07.400
whatever is
308
00:20:07.800 --> 00:20:09.980
whatever happens in that hosted channel,
309
00:20:10.840 --> 00:20:16.455
deep on the network, you can always either get your payment delivered to recipient, or you can
310
00:20:17.095 --> 00:20:20.075
get it back on chain from your local channel.
311
00:20:20.455 --> 00:20:20.955
So
312
00:20:21.495 --> 00:20:22.394
even if you
313
00:20:22.855 --> 00:20:30.770
don't like this idea, don't participate in it in in any way, you can you still only have upside from this, no downside.
314
00:20:31.665 --> 00:20:32.165
And,
315
00:20:32.705 --> 00:20:33.845
linking this to
316
00:20:35.505 --> 00:20:40.565
my liquidity talk at start, this thing, this hosted channels, once they become
317
00:20:41.100 --> 00:20:43.200
public, they increase total liquidity
318
00:20:43.500 --> 00:20:44.620
on the network, and,
319
00:20:45.100 --> 00:20:47.280
that leads to more successful payments,
320
00:20:48.700 --> 00:20:49.200
and,
321
00:20:50.645 --> 00:20:52.025
well, more user satisfaction.
322
00:20:52.565 --> 00:20:56.185
For example, it's a working scene already. There are
323
00:20:56.645 --> 00:20:57.545
3 nodes
324
00:20:59.340 --> 00:21:01.679
and 2 hosted channels between them.
325
00:21:02.059 --> 00:21:02.299
And,
326
00:21:02.940 --> 00:21:06.559
this has been working for about 3 weeks now, and we have
327
00:21:06.925 --> 00:21:09.505
a few hundred route payments through them.
328
00:21:11.245 --> 00:21:13.345
So, I mean, Fiat, Jeff mentioned
329
00:21:13.965 --> 00:21:14.465
that
330
00:21:14.970 --> 00:21:17.550
the l n transaction bot node accepts,
331
00:21:18.490 --> 00:21:20.990
basically, like, inbound hosted channel requests.
332
00:21:21.850 --> 00:21:22.350
Yes.
333
00:21:22.955 --> 00:21:29.695
How is isn't isn't isn't there a trust issue there for Fiat Jaffe that I could open up
334
00:21:31.399 --> 00:21:33.100
a hosted channel with him
335
00:21:33.559 --> 00:21:39.655
Mhmm. And route a payment through it, and there's no on chain backing? Like, there's no, like, collateral backing it? How does
336
00:21:40.215 --> 00:21:41.675
am I missing something there?
337
00:21:42.215 --> 00:21:48.440
When you open a channel like, if you get a channel from my note, it will be all the liquidated on my side.
338
00:21:48.919 --> 00:21:56.539
Oh, okay. It's the reverse. So so you Yeah. Of course. You can't just, like, open a hosted channel outbound to some random node.
339
00:21:57.375 --> 00:21:59.075
Yeah. Yeah. Right. You can.
340
00:21:59.855 --> 00:22:02.115
Okay. That makes sense. Really little sense here.
341
00:22:02.415 --> 00:22:06.630
Yeah. I was I was a little bit, I was like, that sounds like a massive hole. Okay.
342
00:22:07.010 --> 00:22:09.430
I guess. Well, I'm glad you guys thought about that already.
343
00:22:11.490 --> 00:22:16.105
Okay. So that's awesome. So so you you have the UX benefits
344
00:22:17.685 --> 00:22:20.425
of traditional custodial wallets like Wallet of Satoshi,
345
00:22:21.045 --> 00:22:22.025
but you have,
346
00:22:22.750 --> 00:22:24.610
performance and privacy benefits,
347
00:22:26.110 --> 00:22:30.130
rather than that in an hosted channel model to distill it. Yeah. Almost.
348
00:22:30.644 --> 00:22:31.764
Almost. Because,
349
00:22:32.164 --> 00:22:33.865
in order to receive payment,
350
00:22:34.644 --> 00:22:41.330
such a channel still has to be online unlike, say, Wallet of Satoshi, but it's for a very good reason because,
351
00:22:43.550 --> 00:22:46.210
in hosted channels, just like in normal channels,
352
00:22:47.395 --> 00:22:52.054
The final receiver is the one who releases pretty much, and as such,
353
00:22:53.635 --> 00:22:55.655
hosted channel users can prove
354
00:22:56.100 --> 00:22:59.000
then he really received payment, or
355
00:22:59.540 --> 00:23:00.760
if host starts,
356
00:23:01.220 --> 00:23:03.960
like, acting funny, it can prove that,
357
00:23:04.915 --> 00:23:06.995
payments that it has received and,
358
00:23:07.715 --> 00:23:10.195
for which it has released the pre match still
359
00:23:10.915 --> 00:23:13.575
well, the money belongs to receiver.
360
00:23:13.970 --> 00:23:17.750
I hope that's So you have to have the wallet open when you're receiving. Right?
361
00:23:18.370 --> 00:23:19.270
Excuse me. What?
362
00:23:20.290 --> 00:23:24.375
You're saying you have to have the wallet open when you're receiving? Yeah. Basically. Yes.
363
00:23:25.795 --> 00:23:36.910
With with a fully custodial thing, you presumably don't have to. Yeah. This is the thing with fully custodial is they receive payment on your behalf. So they can
364
00:23:37.290 --> 00:23:46.295
say things like they never received it. With hosted channel, it's still you who received it. So you can prove that you really received it is if
365
00:23:46.675 --> 00:23:48.215
they say you didn't.
366
00:23:49.100 --> 00:23:49.919
Got it. Another
367
00:23:50.539 --> 00:23:51.039
difference.
368
00:23:53.419 --> 00:23:57.600
Freaks in the live chat. I mean, if you have any questions, as always, feel free to,
369
00:23:58.955 --> 00:24:01.695
hit us. Hit us. Whatever you're saying, hit us.
370
00:24:02.395 --> 00:24:04.335
Yeah. And it doesn't do you any good,
371
00:24:05.010 --> 00:24:16.295
like, claim that your host or channel provider scammed you. Like, otherwise, if you say you trust them anyway, then you could also just give them the preimage, and then you wouldn't have the problem that you need to keep your wallet open to receive.
372
00:24:18.275 --> 00:24:24.110
Yeah. Well, then they can say, yeah, that you never received that payment, and you have no way to prove otherwise.
373
00:24:24.650 --> 00:24:26.350
That's the thing. Yeah. But you're
374
00:24:27.050 --> 00:24:28.350
you're trusting them anyway.
375
00:24:28.835 --> 00:24:30.135
So, yes, there's
376
00:24:30.675 --> 00:24:35.095
trust involved, but it's not that kind of trust that you have in normal
377
00:24:35.395 --> 00:24:35.895
custodial
378
00:24:38.060 --> 00:24:41.280
provider, like, Wallet of Satoshi. In hosted channels,
379
00:24:41.740 --> 00:24:42.540
there's still,
380
00:24:43.660 --> 00:24:46.000
balance distribution is always cryptographically
381
00:24:46.460 --> 00:24:46.960
provable.
382
00:24:47.285 --> 00:24:53.145
So you can prove that, whatever host owes to you that it is the case.
383
00:24:54.165 --> 00:24:57.570
So this is the reason to have all this. So it's essentially,
384
00:24:58.350 --> 00:25:01.870
secured by the potential of raising a stink on Twitter that,
385
00:25:02.350 --> 00:25:04.050
some specific host of channel
386
00:25:04.795 --> 00:25:10.655
provide a scammed you. And you couldn't do this giving them the pretty much because then they could just claim you actually never,
387
00:25:11.595 --> 00:25:13.375
like, got an invoice paid.
388
00:25:14.030 --> 00:25:17.170
You get, like, cryptographic proof of exit scam?
389
00:25:17.630 --> 00:25:18.850
Yes. Mhmm.
390
00:25:20.030 --> 00:25:22.205
Yeah. Is it that's true. Yes. Because,
391
00:25:22.585 --> 00:25:26.105
exit scam is probably the only type of scam that,
392
00:25:26.985 --> 00:25:32.490
host can perform because they can't scan selectively because that will become very visible
393
00:25:32.950 --> 00:25:33.450
immediately.
394
00:25:34.950 --> 00:25:36.169
Yeah. But, the,
395
00:25:36.789 --> 00:25:38.650
like, the one thing about
396
00:25:39.505 --> 00:25:43.505
the exit scam is that it happens all at once. Like, the mark of an exit scam. So,
397
00:25:44.945 --> 00:25:51.050
what is the benefit of being able to prove that someone just excellent, just lost their funds anyway, and no no one else
398
00:25:51.750 --> 00:25:52.250
will
399
00:25:52.790 --> 00:25:54.845
trust them anymore. So
400
00:25:55.625 --> 00:25:59.005
no I mean, I couldn't presumably I mean, presumably,
401
00:25:59.865 --> 00:26:06.250
someone like Waller or Satoshi could, and they they haven't as far as I'm con as far as I'm aware, but they they could
402
00:26:06.710 --> 00:26:07.210
conceivably
403
00:26:07.510 --> 00:26:10.170
be stealing money from, like, certain individuals
404
00:26:10.835 --> 00:26:12.535
in small amounts without
405
00:26:13.315 --> 00:26:16.695
doing a full blown exit scam? Yes. Totally. They could.
406
00:26:17.555 --> 00:26:23.150
That's the thing about lightning. It's it's much worse, I'd say, that even on chain in this regard because
407
00:26:23.530 --> 00:26:26.030
everything is off chain. And if you use
408
00:26:28.295 --> 00:26:29.195
these custodians,
409
00:26:29.575 --> 00:26:39.860
nothing is provable at all. They can do anything. They can claim that, yeah, that whatever payment you receive, you didn't receive, and it's your word against the there's
410
00:26:40.559 --> 00:26:41.059
the
411
00:26:42.399 --> 00:26:46.980
I mean, a perfect example feels like the experience people are hearing about Chivo,
412
00:26:48.145 --> 00:26:50.165
which is a fully custodial wallet,
413
00:26:50.705 --> 00:26:53.925
the government wallet of El Salvador where you pay a lightning payment,
414
00:26:54.225 --> 00:26:57.410
and then the sender's wallet says that it was successfully sent,
415
00:26:57.970 --> 00:27:00.710
but the receiver has no proof that
416
00:27:01.250 --> 00:27:08.115
they they don't see it on their side, and then you call support or whatever and support's like, you gotta call up lightning and get your money refunded.
417
00:27:09.215 --> 00:27:11.315
If Chivo was using hosted wallets,
418
00:27:11.935 --> 00:27:13.395
then at least you'd have
419
00:27:15.550 --> 00:27:20.530
you'd have some kind of receipt. You'd have, like, a cryptographic proof that you'd you didn't get your money.
420
00:27:21.205 --> 00:27:28.980
Yeah. If she were able to use hosted channels, then it would just be a routing note, and, receiving would have actually happened at,
421
00:27:29.620 --> 00:27:30.760
user ports.
422
00:27:31.460 --> 00:27:34.120
So, yeah, it would be a totally different situation.
423
00:27:34.900 --> 00:27:38.465
That's actually a good point. Like, it prevents implementation errors kind of. Like, currently,
424
00:27:39.184 --> 00:27:42.164
that feels like a big, implementation bug in Shivo.
425
00:27:42.465 --> 00:27:46.100
But by requiring to query the client for the preimage,
426
00:27:46.480 --> 00:27:51.220
you kind of, like, prevent this whole set of bugs that you
427
00:27:51.600 --> 00:27:54.100
could build into such a system. Yeah. That's true.
428
00:27:55.485 --> 00:27:55.985
Cool.
429
00:27:58.125 --> 00:27:59.825
Okay. So that's hosted wallets
430
00:28:00.205 --> 00:28:03.345
and simple Bitcoin wallet. Now let's move,
431
00:28:05.310 --> 00:28:06.050
to Eric's,
432
00:28:06.750 --> 00:28:09.090
Federated Charmin eCash proposal.
433
00:28:09.870 --> 00:28:12.690
Eric, you wanna describe that high level for us?
434
00:28:13.715 --> 00:28:18.615
Yeah. And I think it's really good that we, started with hosted channels because,
435
00:28:19.155 --> 00:28:19.655
like,
436
00:28:20.440 --> 00:28:21.500
in some sense,
437
00:28:21.880 --> 00:28:32.304
federated e cache is just an extension of that idea because my observation was, like, most people will not be able open their own lightning notes. So what do we do about it?
438
00:28:32.605 --> 00:28:33.505
Like, letting them
439
00:28:33.885 --> 00:28:36.830
go to banks, to traditional custodians, it's it's
440
00:28:37.630 --> 00:28:39.090
the the worst solution of all.
441
00:28:40.029 --> 00:28:42.049
But on the other hand, like, I can't expect,
442
00:28:43.399 --> 00:28:43.845
someone
443
00:28:44.804 --> 00:28:48.345
who maybe makes $5 a day to open a channel for $4.
444
00:28:48.804 --> 00:28:50.105
That's also not viable.
445
00:28:51.684 --> 00:28:52.184
So
446
00:28:52.610 --> 00:28:57.750
we already touched on hosted channels, and in my opinion, there are 2 major concerns.
447
00:28:58.929 --> 00:29:02.405
The first is obviously trust. Like, you need to trust
448
00:29:02.965 --> 00:29:04.105
your host
449
00:29:04.645 --> 00:29:05.465
channel provider.
450
00:29:05.845 --> 00:29:10.115
And federated e cash of not really solves, but a problem
451
00:29:10.700 --> 00:29:13.440
by distributing the trust over multiple parties,
452
00:29:14.620 --> 00:29:18.880
of which now some might be malicious without the whole thing falling apart.
453
00:29:19.184 --> 00:29:25.044
Like, if you have a federation of 4, one can just be malicious and, all your funds are safe. The federation
454
00:29:25.505 --> 00:29:26.405
stays operational.
455
00:29:27.840 --> 00:29:31.780
And the second thing that Federated Ecash solves is privacy.
456
00:29:32.480 --> 00:29:35.539
Because while hosted channels provide good payment privacy,
457
00:29:37.365 --> 00:29:46.850
the, like, account holdings privacy isn't all that great because your host of channel provider still sees how much, he owes you. He knows how much you own in in the host channel.
458
00:29:47.870 --> 00:29:56.325
So with e cash, you also hide how much you you own in a certain ecache federation, which is equivalent to the hosted channel provider.
459
00:29:57.345 --> 00:30:02.490
So on a high level, these are the two things that, federated ecache fixes.
460
00:30:06.950 --> 00:30:07.450
So
461
00:30:08.415 --> 00:30:13.235
when I when I attempt to describe your proposal, the way I kind of describe it is
462
00:30:17.030 --> 00:30:20.890
you have the UX benefits of a custodial lightning wallet.
463
00:30:22.630 --> 00:30:23.450
You have
464
00:30:24.725 --> 00:30:28.745
that you have the custodial risk of actual funds loss being mitigated,
465
00:30:30.485 --> 00:30:30.985
because
466
00:30:31.285 --> 00:30:40.039
instead of a single custodian, you have this collection of custodians that have to basically collude to steal your money. So people can think of that like a multi sig custodian.
467
00:30:40.715 --> 00:30:43.375
And then you have these privacy this privacy benefit
468
00:30:43.914 --> 00:30:45.375
of Chaumu and e cash
469
00:30:45.995 --> 00:30:48.975
where not only do you have privacy from the custodian,
470
00:30:51.360 --> 00:30:53.059
but you get increased privacy
471
00:30:54.399 --> 00:30:57.379
for all of your operations on the greater Lightning Network,
472
00:30:58.185 --> 00:30:59.485
the larger that
473
00:30:59.945 --> 00:31:04.525
pool of funds gets in that within that federation. So you you're able to operate
474
00:31:06.080 --> 00:31:08.740
in in both these cases, in both with both,
475
00:31:09.200 --> 00:31:10.820
hosted channels and
476
00:31:11.520 --> 00:31:13.940
Federated Chaumian e cache, you're able to operate
477
00:31:14.804 --> 00:31:16.245
among the Greater Lightning where
478
00:31:17.125 --> 00:31:20.105
grading Greater Lightning Network you can send and receive
479
00:31:20.485 --> 00:31:23.385
from any Lightning Wallet, to those wallets.
480
00:31:25.810 --> 00:31:27.430
Exactly. Yeah. Yeah.
481
00:31:27.890 --> 00:31:30.950
And the the nice thing about the e cash is that it's
482
00:31:31.404 --> 00:31:36.705
actually perfectly private. Like, at least federation internal ecash to ecash transactions
483
00:31:37.485 --> 00:31:38.945
that you have, essentially
484
00:31:39.730 --> 00:31:41.669
the unlimited set of your entire federation,
485
00:31:42.289 --> 00:31:46.070
more or less. Like, there are some details that I'm leaving out, but, like,
486
00:31:47.625 --> 00:31:51.885
in a ideal federation, that's the case. Then, like, there's the second case with,
487
00:31:52.345 --> 00:31:56.365
interacting with the wider lightning network, and that's a little bit more complicated.
488
00:31:57.360 --> 00:31:58.900
Like, you can definitely hide,
489
00:31:59.679 --> 00:32:01.460
when you're sending a Lightning transaction
490
00:32:02.000 --> 00:32:03.540
that who is the sender,
491
00:32:04.665 --> 00:32:05.165
And
492
00:32:05.705 --> 00:32:07.805
if you're the recipient, who's the recipient?
493
00:32:09.945 --> 00:32:16.080
It's the problem thing is hiding the other side, like the lightning side. It's actually did some great work because,
494
00:32:16.780 --> 00:32:24.645
like, what you're doing there is you let the lightning, the the client actually route. So you only give only a message to the service
495
00:32:26.385 --> 00:32:27.205
out of the federation,
496
00:32:27.665 --> 00:32:28.725
and then let them,
497
00:32:29.185 --> 00:32:29.685
send
498
00:32:32.140 --> 00:32:36.960
once the product instead of making them relevant and all the stuff, a lot more information.
499
00:32:39.265 --> 00:32:43.365
It's I kind of think of it as a UX trade off. And,
500
00:32:45.080 --> 00:32:54.804
like, one caveat I have to add here is that Federated ECash is a research project right now. Like, there's no product, nothing that you should use or could use, on Bitcoin today.
501
00:32:55.664 --> 00:32:58.565
So I don't even have the lightning integration
502
00:32:59.105 --> 00:33:00.164
as it should be,
503
00:33:00.625 --> 00:33:05.789
implemented yet. Okay. I'm actually not sure if I will go the hosted channel way of routing
504
00:33:06.250 --> 00:33:07.870
or, like, the more traditional
505
00:33:08.730 --> 00:33:09.470
let's tell
506
00:33:10.250 --> 00:33:10.750
the
507
00:33:11.215 --> 00:33:14.035
equation where I want my payment to Google way of routing.
508
00:33:15.375 --> 00:33:16.355
That's still ongoing
509
00:33:16.895 --> 00:33:21.560
research essentially for me. The host to channel approach is a really interesting trade off.
510
00:33:22.420 --> 00:33:24.120
And other things like
511
00:33:25.885 --> 00:33:27.025
the payment privacy
512
00:33:27.805 --> 00:33:29.505
proposed by, Bastian,
513
00:33:32.045 --> 00:33:32.945
where you essentially
514
00:33:34.120 --> 00:33:37.100
include a plan that path in your invoice, that's also
515
00:33:37.640 --> 00:33:43.180
a great option. And I will see whatever works best and provides the best UX and
516
00:33:43.625 --> 00:33:44.285
best privacy.
517
00:33:44.585 --> 00:33:48.285
Because in my opinion, what is most important is to couple
518
00:33:48.745 --> 00:34:01.735
privacy with good UX so people actually want to use it because otherwise, you will have to 10 people that need privacy use your service. But all the other people that don't really care will use something else, and then you have unlimited set of 10. That's not what we want.
519
00:34:02.275 --> 00:34:08.240
Right. Right now private like, using Bitcoin privately is is more difficult and more expensive than the alternative,
520
00:34:09.339 --> 00:34:11.920
and you wanna reduce that as much as possible.
521
00:34:12.915 --> 00:34:16.055
Yeah. Let's make it the most convenient and cheapest form of payment.
522
00:34:16.515 --> 00:34:18.935
That's what I'm aiming for with Federated ECash.
523
00:34:22.170 --> 00:34:22.670
Awesome.
524
00:34:24.730 --> 00:34:28.350
So I think that was pretty good high level on Eric's proposal.
525
00:34:29.985 --> 00:34:40.640
I know Anton and Fiat, Jeff, have some feedback and some critiques. So I you guys want to jump into that, and we can have some good productive discussion here.
526
00:34:42.059 --> 00:34:42.880
Yeah. Maybe
527
00:34:43.260 --> 00:34:45.760
whatever concerns privacy and security,
528
00:34:46.140 --> 00:34:46.640
it's
529
00:34:47.115 --> 00:34:49.135
an interesting question here because
530
00:34:51.195 --> 00:34:52.255
so, you know,
531
00:34:52.555 --> 00:34:53.775
like has been explained
532
00:34:54.180 --> 00:34:55.160
by Eric,
533
00:34:56.579 --> 00:34:57.079
this
534
00:34:58.260 --> 00:35:03.240
federated cache thing wants to be a thing of its own and then also
535
00:35:05.605 --> 00:35:07.785
a lightning scaling solution, kinda.
536
00:35:08.565 --> 00:35:09.065
So
537
00:35:09.525 --> 00:35:12.805
it wants to integrate with lightning. And,
538
00:35:13.450 --> 00:35:17.790
if we are to extend lightning with this solution solutions,
539
00:35:18.730 --> 00:35:20.510
custodial solutions, we can
540
00:35:21.455 --> 00:35:23.715
talk about their quality, I guess,
541
00:35:26.735 --> 00:35:27.955
in the ways that,
542
00:35:28.495 --> 00:35:29.235
for example,
543
00:35:30.240 --> 00:35:32.260
when we're using normal channels,
544
00:35:33.520 --> 00:35:36.740
this graph on device, we can where we we have certain,
545
00:35:38.000 --> 00:35:38.980
useful features
546
00:35:39.595 --> 00:35:41.135
besides off chain payments,
547
00:35:42.635 --> 00:35:43.855
such as, for example,
548
00:35:44.234 --> 00:35:48.575
I can list 3 of them, which are related to privacy and security.
549
00:35:49.250 --> 00:35:53.109
First is already mentioned privacy when sending a payment
550
00:35:53.569 --> 00:35:54.069
because
551
00:35:55.410 --> 00:35:58.630
sender has a graph on device and can construct route.
552
00:35:59.315 --> 00:35:59.555
And,
553
00:36:00.435 --> 00:36:01.815
second one is
554
00:36:02.355 --> 00:36:02.855
enforceability
555
00:36:03.395 --> 00:36:05.815
on chain when receiving the payment,
556
00:36:06.115 --> 00:36:07.015
which is due
557
00:36:07.395 --> 00:36:08.615
to HTLC mechanics
558
00:36:09.050 --> 00:36:09.790
where receiver
559
00:36:10.170 --> 00:36:12.510
can publish transaction on chain
560
00:36:12.970 --> 00:36:13.470
if
561
00:36:14.170 --> 00:36:15.710
if peer starts to
562
00:36:16.994 --> 00:36:19.575
play some games and not update in the state.
563
00:36:20.115 --> 00:36:26.134
And, the third one is already mentioned, the inability, which comes from ability to route payment.
564
00:36:26.440 --> 00:36:31.579
And the the inability here is ability to always claim that this payment is not yours.
565
00:36:32.359 --> 00:36:32.859
So,
566
00:36:34.119 --> 00:36:36.140
I'd say I'd say a good
567
00:36:38.345 --> 00:36:45.965
extension to lightning, custodial extension would retain as much of those properties as possible. And when it comes to hosted channels,
568
00:36:47.040 --> 00:36:47.940
sender privacy
569
00:36:48.320 --> 00:36:48.820
and
570
00:36:49.840 --> 00:36:50.580
the the liability
571
00:36:51.280 --> 00:36:52.660
are retained in full,
572
00:36:53.120 --> 00:36:54.180
and the enforceability
573
00:36:54.560 --> 00:37:00.675
on chain is, of course, thrown away because there is no chain part, but it's replaced with probability,
574
00:37:01.455 --> 00:37:03.475
which is weaker notion, but
575
00:37:03.935 --> 00:37:05.315
still better than nothing.
576
00:37:06.560 --> 00:37:07.060
And,
577
00:37:07.360 --> 00:37:09.740
well, yeah. When it comes to,
578
00:37:10.800 --> 00:37:12.900
federated cash, I think there's,
579
00:37:13.360 --> 00:37:13.860
like,
580
00:37:14.955 --> 00:37:15.695
no consideration
581
00:37:15.995 --> 00:37:18.495
has been given to these things yet.
582
00:37:18.875 --> 00:37:19.375
So
583
00:37:19.915 --> 00:37:21.375
this concerns me indeed.
584
00:37:23.355 --> 00:37:24.335
Yeah. So
585
00:37:25.020 --> 00:37:27.260
let me start from the back of your,
586
00:37:27.660 --> 00:37:32.160
list of 3 points. Like Mhmm. I think the liability actually becomes less important,
587
00:37:32.619 --> 00:37:35.994
once you have the anonymity that Ecash provides because
588
00:37:36.535 --> 00:37:41.515
when you're sending a payment, then the sender is completely anonymous anyway.
589
00:37:42.010 --> 00:37:47.770
Like, except for maybe leaking, something on the lightning side, which we need to con consider too. But,
590
00:37:48.490 --> 00:37:48.990
like,
591
00:37:49.494 --> 00:37:51.914
so does a host of channels need to do?
592
00:37:52.934 --> 00:37:55.194
So you don't really gain anything from
593
00:37:55.494 --> 00:37:59.320
and see where you're having routed the payment or not. Like, you don't care. Like
594
00:37:59.620 --> 00:38:01.560
Mhmm. Okay. You as a sender and
595
00:38:01.940 --> 00:38:04.920
anonymous in the first way 1st place. K?
596
00:38:05.325 --> 00:38:06.065
The enforceability,
597
00:38:07.244 --> 00:38:09.665
there, I probably agree with you. Like, e cash
598
00:38:10.605 --> 00:38:13.425
is not auditable, so you fully trust the federation.
599
00:38:14.290 --> 00:38:15.510
Mhmm. But
600
00:38:15.890 --> 00:38:19.590
as I said, like, putting trust in the federation of you. Because,
601
00:38:19.970 --> 00:38:23.755
let's say you have a community where you have 4 people that in the normal circumstances
602
00:38:24.295 --> 00:38:26.474
are well regarded to have reputation and you trust.
603
00:38:27.654 --> 00:38:29.595
But one of them now has accident
604
00:38:30.055 --> 00:38:33.370
and needs a lot of money really short on really short notice.
605
00:38:33.750 --> 00:38:38.330
Otherwise, he dies, for example. Then he would certainly exit scam you in a hosted channel scenario
606
00:38:38.645 --> 00:38:39.145
because
607
00:38:39.605 --> 00:38:42.745
then just how incentives work. But in a federated
608
00:38:44.085 --> 00:38:51.170
scenario, like, one of these 4 cannot just you can't even stop the federation and extort you. It would already need 2 participants.
609
00:38:52.190 --> 00:38:58.695
So you're much safer as a user. And so I think it might be a reasonable trade off to just fully trust the federation
610
00:38:59.155 --> 00:39:01.575
in exchange for way better privacy.
611
00:39:02.980 --> 00:39:04.680
Because e cash Well,
612
00:39:04.980 --> 00:39:06.600
I have another question then,
613
00:39:07.940 --> 00:39:13.505
I have another question then. It's again about lightning integration. How this federation would,
614
00:39:14.125 --> 00:39:15.745
manage a lightning node?
615
00:39:17.165 --> 00:39:17.645
Because,
616
00:39:18.045 --> 00:39:20.785
it doesn't seem like an easy task to me
617
00:39:21.450 --> 00:39:23.450
to split Yeah. Like within many
618
00:39:24.650 --> 00:39:29.695
yeah. Please do. That's actually a really interesting question. Like, federated e cache in and of itself,
619
00:39:30.255 --> 00:39:32.915
does not need to have anything to do with lightning.
620
00:39:33.535 --> 00:39:34.435
Like, in the basic,
621
00:39:35.055 --> 00:39:42.099
model that I'm currently building, you have on chain an on chain multisig wallet. We have the majority of backing funds. And
622
00:39:44.800 --> 00:39:49.495
Mhmm. For these, you get eCash tokens issued by using smart contract inside the federation
623
00:39:50.435 --> 00:39:50.935
to
624
00:39:51.315 --> 00:39:58.040
incentivize an external Lightning Gateway, which has its own funds, which are not counted towards the backing funds of the federation,
625
00:39:59.060 --> 00:40:02.040
to make payments for you or to receive payments for you.
626
00:40:02.695 --> 00:40:06.235
So, essentially, you build a bridge between Lightning and your federation
627
00:40:06.615 --> 00:40:07.275
through these
628
00:40:07.735 --> 00:40:09.275
gate train nodes.
629
00:40:10.055 --> 00:40:11.355
And, so the Lightning,
630
00:40:14.230 --> 00:40:19.450
like, a single third party, but due to the smart console, you essentially rebuild HTLCs
631
00:40:19.750 --> 00:40:20.730
inside the federation,
632
00:40:21.265 --> 00:40:22.005
more or less.
633
00:40:23.904 --> 00:40:29.525
Yeah. That's that's like the current plan. And, like, in some future version of it, I could also,
634
00:40:30.260 --> 00:40:33.400
like, imagine having a fully federated lightning
635
00:40:33.780 --> 00:40:36.280
note. But as you said, that's really complicated. It needs
636
00:40:36.660 --> 00:40:39.765
a bunch of changes to the peer to peer protocol. It definitely needs
637
00:40:40.964 --> 00:40:42.424
taproot and Schnorr signatures,
638
00:40:42.805 --> 00:40:43.704
sees, like, all the
639
00:40:45.125 --> 00:40:47.605
good stuff. So that's not on the
640
00:40:50.230 --> 00:40:53.290
so yeah. Maybe, one thing I should mention is that
641
00:40:53.590 --> 00:40:56.730
by doing so, I assume that the funds held in Lightning
642
00:40:57.914 --> 00:41:02.974
are way smaller than the total packed in funds or the total deposited funds in the federation.
643
00:41:03.434 --> 00:41:04.255
Because, otherwise,
644
00:41:04.730 --> 00:41:07.710
this, model wouldn't make any sense because the light
645
00:41:10.569 --> 00:41:14.510
note essentially needs to hold a double because they can't be counted duration.
646
00:41:21.515 --> 00:41:24.095
So this is what I was going to to say. Like,
647
00:41:25.290 --> 00:41:26.670
I see, like, a a conflict
648
00:41:27.450 --> 00:41:28.430
between having
649
00:41:28.809 --> 00:41:30.270
multiple small federations.
650
00:41:30.650 --> 00:41:32.750
Like, I I don't know if the name mini mint,
651
00:41:33.725 --> 00:41:37.585
is intended to to mean that the the these federations will be small.
652
00:41:38.845 --> 00:41:39.345
And,
653
00:41:39.885 --> 00:41:43.960
like, have having a large federation with a ton of accounts in it.
654
00:41:44.260 --> 00:41:44.760
And
655
00:41:45.140 --> 00:41:46.900
because you need either
656
00:41:47.460 --> 00:41:49.960
you need a large thing with a ton of people using
657
00:41:50.805 --> 00:41:53.865
so so they can transact between them, or you need
658
00:41:54.405 --> 00:41:55.945
very good inter interoperability
659
00:41:56.325 --> 00:41:58.025
between many small providers.
660
00:42:01.570 --> 00:42:03.589
Yeah. That's why you need lightning probably.
661
00:42:04.690 --> 00:42:07.589
Do not convince everyone around to use your tokens
662
00:42:08.130 --> 00:42:09.270
beyond your users.
663
00:42:10.654 --> 00:42:15.394
Yeah. Exactly. That's, That's my understanding that why lightning is so important. So you have interoperable
664
00:42:17.454 --> 00:42:24.310
between these different means. And I agree, more expensive with on chain transactions get, the larger the federation
665
00:42:24.770 --> 00:42:25.670
needs to grow.
666
00:42:26.945 --> 00:42:32.085
And I'm not entirely sure that, having the lightning node external to the federation
667
00:42:34.700 --> 00:42:38.160
makes it significantly worse, like a 2 x factor, I think.
668
00:42:39.740 --> 00:42:41.600
That's maybe the difference between
669
00:42:41.975 --> 00:42:46.075
10 people, a 10 user federation, or a 20 user federation being economical.
670
00:42:48.215 --> 00:42:52.599
So we will see in the it will be a market process. That's the great thing. Like,
671
00:42:52.900 --> 00:43:00.295
I'm bill we are all building this stuff as open source software, so everyone can just run it, and we will see whatever wins.
672
00:43:01.395 --> 00:43:02.135
And also,
673
00:43:02.915 --> 00:43:04.215
for me, it's currently research.
674
00:43:04.835 --> 00:43:06.055
Probably won't be ready
675
00:43:06.560 --> 00:43:08.100
for mass market,
676
00:43:09.440 --> 00:43:10.900
in 2 years or so.
677
00:43:11.440 --> 00:43:14.260
I kinda hope to have a working prototype that
678
00:43:15.515 --> 00:43:22.175
a reckless person can set up on Mainnet. Yeah. It's it's research. Excuse me. Is it just me, or the quality is absolutely
679
00:43:23.595 --> 00:43:24.095
bad?
680
00:43:28.170 --> 00:43:29.150
I mean, Eric's
681
00:43:29.770 --> 00:43:32.750
Eric's breaking up a little bit, but I can mostly hear him.
682
00:43:33.695 --> 00:43:34.435
Mhmm. Okay.
683
00:43:35.375 --> 00:43:36.115
I'm sorry.
684
00:43:37.055 --> 00:43:37.715
I mean,
685
00:43:39.535 --> 00:43:46.760
I I mean, the the last thing he said is that it he doesn't expect to have, you know, a working app available for at least 2 years.
686
00:43:49.775 --> 00:43:51.315
Mhmm. Okay. I see.
687
00:43:52.255 --> 00:43:54.115
If you're hearing my background noise.
688
00:43:56.255 --> 00:43:58.515
No. You've been good about background noise recently.
689
00:43:59.519 --> 00:44:01.220
So, I mean, 2 years,
690
00:44:02.319 --> 00:44:05.299
so, like, realistically, that's, like, 4 years. Right, Eric?
691
00:44:07.815 --> 00:44:09.915
Yeah. Possibly. Like, I'm always
692
00:44:10.455 --> 00:44:20.049
taking into account such things. Like, I was at this 2 years thing, like, I mentioned ideally in 1 year, like, for next HCPP, I will have some
693
00:44:20.349 --> 00:44:24.855
working prototype on my net where I run a federation, so only I will lose funds.
694
00:44:29.475 --> 00:44:33.140
That should already work. We need to be really careful with
695
00:44:34.640 --> 00:44:35.460
new experimental
696
00:44:35.760 --> 00:44:37.859
things so that people don't trust.
697
00:44:39.325 --> 00:44:39.825
Yeah.
698
00:44:40.765 --> 00:44:44.224
So I tend to be a little bit more conservative. I mean, I think
699
00:44:45.005 --> 00:44:48.140
I think before you even have an app out, like, people are going
700
00:44:48.619 --> 00:44:50.079
to learn the hard way,
701
00:44:50.619 --> 00:44:54.880
the current custodial risks in terms of stuff like while the satoshi and blue wallet.
702
00:44:56.105 --> 00:45:00.285
Well, blue wallet is only custodial for its lightning, at least by default,
703
00:45:01.065 --> 00:45:02.204
not on chain.
704
00:45:02.770 --> 00:45:05.910
I mean, we saw it previously. I don't know if you guys remember,
705
00:45:07.890 --> 00:45:09.570
one of the most popular
706
00:45:09.995 --> 00:45:13.935
at one point, one of the most popular mobile lightning wallets was
707
00:45:14.555 --> 00:45:15.055
Dropbit,
708
00:45:16.155 --> 00:45:18.815
which is a custodial lightning wallet, and
709
00:45:19.115 --> 00:45:19.855
the feds,
710
00:45:20.300 --> 00:45:21.440
the US government,
711
00:45:23.020 --> 00:45:24.160
raided them because
712
00:45:24.619 --> 00:45:28.720
that guy, I think Larry Harmon was his name, was running a mixer as well,
713
00:45:30.435 --> 00:45:34.375
a custodial mixer, and they seized all the funds. Everyone lost all their money,
714
00:45:36.960 --> 00:45:42.400
and people forget that really quickly. But, as I as I see I mean, I I was looking at,
715
00:45:43.595 --> 00:45:44.414
all the videos of people
716
00:45:44.714 --> 00:45:47.775
buying pupusas in, El Salvador this week.
717
00:45:48.154 --> 00:45:52.654
A lot of people were using wild as Satoshi. Like, a lot of people that you'd think would know better.
718
00:45:54.290 --> 00:45:58.950
You know, they say, oh, it's just for a small amount, but, you know, that small amount tends to grow.
719
00:46:02.025 --> 00:46:12.580
Yeah. I remember that's sort of failure to come in. That's the reason my hosted channels are limited to only 1,000,000 satoshi. So they were just, like, entry point, and then user just can't
720
00:46:12.960 --> 00:46:13.780
receive more.
721
00:46:14.720 --> 00:46:16.500
I have no desire to,
722
00:46:17.125 --> 00:46:19.705
like, store any more money for my users.
723
00:46:20.325 --> 00:46:22.265
So, I mean, the way I look at it,
724
00:46:23.740 --> 00:46:27.520
from a UX point of view, there's obviously massive benefits to custodial.
725
00:46:28.780 --> 00:46:29.760
As a Bitcoiner,
726
00:46:30.140 --> 00:46:31.039
I am,
727
00:46:33.475 --> 00:46:35.495
emotionally I I'm, obviously,
728
00:46:35.875 --> 00:46:36.375
against
729
00:46:36.755 --> 00:46:37.895
custodial models.
730
00:46:39.740 --> 00:46:42.240
Makes me a little bit sick just thinking about it.
731
00:46:44.300 --> 00:46:48.640
Hosted channels seems like a decent trade off balance in terms of UX,
732
00:46:49.315 --> 00:46:50.535
privacy and security,
733
00:46:53.075 --> 00:46:57.015
for the near term, and then, ideally, something like this
734
00:46:57.740 --> 00:46:58.960
Federated Chamian
735
00:46:59.579 --> 00:47:00.079
proposal,
736
00:47:01.500 --> 00:47:02.400
for the future,
737
00:47:03.180 --> 00:47:05.280
kind of improves on that trade off balance.
738
00:47:06.345 --> 00:47:08.924
Fiat and Anton, do you disagree with that
739
00:47:10.265 --> 00:47:11.805
thought process or that analysis?
740
00:47:13.065 --> 00:47:13.885
Not necessarily,
741
00:47:14.265 --> 00:47:14.765
but
742
00:47:15.530 --> 00:47:17.310
I guess I'd better see
743
00:47:18.330 --> 00:47:23.630
something real with relation to this Fedimint, and then I could make a better judgment.
744
00:47:25.235 --> 00:47:31.495
What I think is, like, if if Eric managed to get a federated lightning node running,
745
00:47:32.550 --> 00:47:35.450
And then, like, he he will have to implement
746
00:47:35.910 --> 00:47:40.204
something that looks like hosted yesterday to to achieve better privacy for
747
00:47:40.825 --> 00:47:42.045
outgoing and incoming
748
00:47:42.345 --> 00:47:43.165
lightning payments,
749
00:47:44.665 --> 00:47:45.805
then it will be good.
750
00:47:46.480 --> 00:47:48.020
I guess even more
751
00:47:48.320 --> 00:47:50.100
more recently than Drop It,
752
00:47:52.160 --> 00:47:57.065
one of my favorite Lightning wallets, which I used to receive donations for the show as well,
753
00:47:58.325 --> 00:48:00.505
is Fiat Jaff's, LNTX
754
00:48:00.964 --> 00:48:04.180
bot, which is a lightning wallet, a custodial lightning wallet that operates
755
00:48:04.640 --> 00:48:09.060
on Telegram. And you got you recently got attacked. Right? You lost all your funds.
756
00:48:10.915 --> 00:48:13.494
Not not all funds, but, total funds.
757
00:48:13.875 --> 00:48:21.950
It's not not an attack like a bug. So And then I'll start well, you don't think it was an attack? You think it was, like, an accidental fund drain?
758
00:48:22.410 --> 00:48:24.670
Yeah. Yeah. Some random user
759
00:48:26.570 --> 00:48:27.470
and and, like,
760
00:48:27.974 --> 00:48:32.315
started exploiting. This this happened in the past. This this last one was the biggest one.
761
00:48:32.775 --> 00:48:35.675
But you don't think it was intentional, or do you think?
762
00:48:36.780 --> 00:48:39.900
Oh, I think it was intentional, but, like, the guy spotted on the
763
00:48:40.460 --> 00:48:41.600
he stepped on the bug
764
00:48:42.220 --> 00:48:46.715
and without understanding what was happening. And then there's, like, all the ink and money. Money. Yeah. Yeah.
765
00:48:47.975 --> 00:48:53.035
And then, I guess I mean, I don't agree with everything he does, but is it true that Alastair Milne
766
00:48:53.380 --> 00:48:58.200
jumped in and and made you whole so the wallet could keep going? Yes. Amazing.
767
00:48:58.500 --> 00:49:01.605
I didn't expect you to. He just he just gave me
768
00:49:02.085 --> 00:49:02.984
ton of money.
769
00:49:04.005 --> 00:49:07.145
Yeah. What was it? It was, like, 14,000,000 sats or something like that?
770
00:49:07.445 --> 00:49:07.945
Yeah.
771
00:49:08.700 --> 00:49:10.640
So was that's, like, like, $75100
772
00:49:11.500 --> 00:49:12.640
or something like that?
773
00:49:14.140 --> 00:49:20.365
Yes. That's it. That's impressive. He just jumped right in there on Twitter. I was impressed. I mean, like I said, I don't agree with everything he does, but,
774
00:49:21.244 --> 00:49:25.265
you know, I think he's he's enjoying the bot on his Theragun group.
775
00:49:25.565 --> 00:49:27.185
Yeah. I mean, the bot is dope.
776
00:49:28.520 --> 00:49:34.300
Yeah. But It's definitely a lot of fun. Not worth that that enough money he he gave me to find the the bot.
777
00:49:36.115 --> 00:49:36.935
That's awesome.
778
00:49:38.355 --> 00:49:39.175
So, I mean,
779
00:49:39.715 --> 00:49:40.695
I I didn't realize,
780
00:49:41.075 --> 00:49:43.815
but you guys hit on an interesting point there. I mean,
781
00:49:44.670 --> 00:49:46.770
in Bitcoin land, we like to,
782
00:49:48.590 --> 00:49:51.170
if we see something that's like a theoretical proposal
783
00:49:52.125 --> 00:49:55.345
that looks awesome, we tend to really hype the fuck out of it.
784
00:49:56.205 --> 00:49:57.905
I think I'm better than most,
785
00:49:58.445 --> 00:49:59.505
but I will admit
786
00:50:00.380 --> 00:50:02.080
that with Eric's Charmian
787
00:50:02.859 --> 00:50:04.640
Federated Charmian eCash proposal,
788
00:50:06.540 --> 00:50:08.960
I got very excited, and I'm still very excited
789
00:50:10.445 --> 00:50:13.425
because, I mean, to me, I'm I have a privacy focus,
790
00:50:14.205 --> 00:50:18.385
and I'm, like, constantly trying to educate new users on using Bitcoin privately.
791
00:50:19.089 --> 00:50:24.630
And there's so many nuances, there's so many difficulties, like the fact that you could have, like, an easy, low cost,
792
00:50:25.410 --> 00:50:26.869
you know, mobile focused,
793
00:50:27.915 --> 00:50:30.175
very private way of using Bitcoin,
794
00:50:31.035 --> 00:50:32.175
to me is like
795
00:50:32.555 --> 00:50:36.895
I mean, it would save me so much time. I mean, if someone's only spending a $100, $200,
796
00:50:37.420 --> 00:50:39.120
you know, a 1,000,000 sats,
797
00:50:39.900 --> 00:50:45.040
2,000,000 sats, like, if they can just download an app and have relatively good,
798
00:50:47.085 --> 00:50:52.545
security guarantees in terms of custodial risk, and have very good privacy guarantees
799
00:50:52.845 --> 00:50:54.065
at very low fees,
800
00:50:54.940 --> 00:50:58.560
to me, that's like a holy grail. I would save a ton of time when I'm,
801
00:50:59.420 --> 00:51:01.599
trying to educate new users. Now
802
00:51:02.355 --> 00:51:04.775
one thing that I missed in this whole aspect
803
00:51:06.035 --> 00:51:12.180
is what Anton mentioned earlier, and I I think we need to highlight that a little bit more. I mean, this idea that
804
00:51:13.380 --> 00:51:14.119
the Federation
805
00:51:14.500 --> 00:51:22.165
with these Charmian tokens is separate from the actual Lightning node itself. That seems to be the biggest hurdle here. Would you agree, Eric?
806
00:51:25.605 --> 00:51:27.705
I don't see it as such a big hurdle.
807
00:51:29.125 --> 00:51:30.505
I mean, it's also not
808
00:51:31.190 --> 00:51:44.385
intended to stay that way forever. Like, ideally, at some point, we can actually federate a lightning node. But for now, like, it's just so much easier to implement it that way and not just wait another 7 years to get featherweighted lightning nodes.
809
00:51:45.405 --> 00:51:48.500
I'm Would it be an old man or would it be a few years? Use it.
810
00:51:49.200 --> 00:51:56.705
Yes. Exactly. And I I also need a prompt besides do you need anything besides Taproot to federate a lightning node?
811
00:51:59.005 --> 00:52:01.665
I'm not entirely sure. Like, the problem is I'm not
812
00:52:02.180 --> 00:52:07.000
that much of a lightning developer. I don't know all that much about lightning.
813
00:52:08.020 --> 00:52:09.960
Like, I spoke to some people
814
00:52:10.340 --> 00:52:10.920
I've had
815
00:52:11.885 --> 00:52:12.625
in Miami,
816
00:52:13.645 --> 00:52:15.825
and they were pretty then actually building
817
00:52:16.285 --> 00:52:18.065
a distributed lighting note eventually.
818
00:52:20.340 --> 00:52:25.560
But I think much work that needs to be done before, like even just getting all the benefits
819
00:52:26.020 --> 00:52:27.825
into lightning, eventually, probably,
820
00:52:29.805 --> 00:52:30.305
resulting
821
00:52:30.925 --> 00:52:37.840
in l 2 and all the good stuff. Like, that will take a lot of time. So they are not thinking about it just right now
822
00:52:38.220 --> 00:52:39.520
as far as I'm aware.
823
00:52:40.460 --> 00:52:43.920
So I have a question. Like, what what do you have against
824
00:52:44.515 --> 00:52:46.695
having instead of a bunch of federations,
825
00:52:47.395 --> 00:52:49.335
you have a big federation like liquid,
826
00:52:49.875 --> 00:52:50.375
but
827
00:52:50.755 --> 00:52:53.175
that's being a a Chow Meon Mint.
828
00:52:53.670 --> 00:52:58.089
And then you Okay. The the the need for lightning decreases very much.
829
00:52:59.430 --> 00:52:59.930
So
830
00:53:00.309 --> 00:53:02.730
at the risk of, pissing off someone,
831
00:53:03.465 --> 00:53:04.205
at Blockstream.
832
00:53:04.825 --> 00:53:05.325
No.
833
00:53:05.625 --> 00:53:06.125
Seriously.
834
00:53:08.185 --> 00:53:11.085
I think this one federation all approach
835
00:53:12.160 --> 00:53:15.060
isn't all that great to onboard
836
00:53:15.920 --> 00:53:17.460
general the general users,
837
00:53:17.840 --> 00:53:19.060
of Bitcoin. Like,
838
00:53:19.555 --> 00:53:24.935
liquid is great, for example, for traders that trust exchanges anyway. They don't really give a shit. Like,
839
00:53:25.955 --> 00:53:29.880
their trust model is far worse, and with liquid, it doesn't get that much worse.
840
00:53:30.339 --> 00:53:46.405
But normal Bitcoin users should have higher standards when it comes to custodial risk. And having this one big federation to rule them all would become a systemic risk over time, in my opinion. And that's not what I want for Bitcoin. That's not what I want to work on. Like, if there's there wouldn't be a possibility
841
00:53:46.740 --> 00:53:48.200
to easily integrate
842
00:53:48.500 --> 00:53:49.000
different
843
00:53:49.940 --> 00:53:55.560
make it federations interoperable. I wouldn't have proposed it. Even so, it's still a really interesting research idea.
844
00:53:56.505 --> 00:53:57.645
But, like, only
845
00:53:58.265 --> 00:53:59.565
by making them interoperable,
846
00:53:59.945 --> 00:54:00.685
they really
847
00:54:01.385 --> 00:54:09.010
benefit to Bitcoin, in my opinion. Otherwise, there would be too much of a risk that over time it would centralize into, like, just one big federation.
848
00:54:09.950 --> 00:54:14.734
So another idea just came to my mind. What if you have, like, a special
849
00:54:15.035 --> 00:54:15.535
protocol
850
00:54:15.835 --> 00:54:20.895
that could be, like, some payment general stuff, but special for federations
851
00:54:21.980 --> 00:54:23.760
that involve a trust between federations
852
00:54:24.620 --> 00:54:28.000
that you could, like, link multiple federations using that.
853
00:54:28.515 --> 00:54:31.494
And then people could route payments between federations.
854
00:54:31.955 --> 00:54:35.734
I'm, like, bypassing lightning completely, but still
855
00:54:36.609 --> 00:54:39.109
splitting the trust between many federations.
856
00:54:41.089 --> 00:54:44.230
But what would be the difference between such a inter federation,
857
00:54:45.105 --> 00:54:49.924
payment layer? Like, if you still want to avoid trust between federations, which is really important,
858
00:54:50.305 --> 00:54:56.220
then you definitely need something like lightning. And at that point, why not just connect it to the wider lightning network?
859
00:54:56.920 --> 00:54:58.440
That just has benefits. Like
860
00:54:59.640 --> 00:55:03.965
Yeah. Because because we don't know how to make up Federated lightning node. That's the reason.
861
00:55:04.345 --> 00:55:07.325
And we could Oh, yeah. But the c plan to do
862
00:55:08.825 --> 00:55:11.005
a payment channel based on trust
863
00:55:11.465 --> 00:55:12.365
between federations.
864
00:55:14.090 --> 00:55:18.270
Yeah. But, I don't want payment channels based on trust. That's that's really bad.
865
00:55:19.210 --> 00:55:21.470
Like, even worse in the case of these federations
866
00:55:21.885 --> 00:55:26.465
The great thing about having Lightning integration with these federations is that you can start your own without
867
00:55:27.005 --> 00:55:27.985
asking for permission.
868
00:55:28.605 --> 00:55:30.305
If you need a trusted channel
869
00:55:30.660 --> 00:55:31.640
to other federations,
870
00:55:32.579 --> 00:55:34.760
then you're at this point where you have
871
00:55:35.299 --> 00:55:38.520
to ask for permission to cooperate with them and, like,
872
00:55:38.944 --> 00:55:39.765
open these channels.
873
00:55:40.464 --> 00:55:42.885
That would be horrible. That would just recreate banking.
874
00:55:44.145 --> 00:55:49.410
Well, we still need permission for for lightning nodes, like, to establish a channel. So I don't see
875
00:55:49.810 --> 00:55:51.030
that's the difference there.
876
00:55:51.410 --> 00:55:53.510
It's if it's open, if you can
877
00:55:53.810 --> 00:55:55.430
open channels for anyone, like,
878
00:55:55.985 --> 00:55:58.545
I don't know. I mean, today Yeah. But Like, I know definitely.
879
00:55:58.945 --> 00:56:00.405
If I open a channel today.
880
00:56:01.345 --> 00:56:04.245
I do care. I hate people opening channels for many months.
881
00:56:05.599 --> 00:56:06.579
Oh, wow. Wow.
882
00:56:07.040 --> 00:56:08.819
You have a strong opinion on that.
883
00:56:09.200 --> 00:56:09.940
Didn't know.
884
00:56:11.520 --> 00:56:15.300
Never generally. I imagine lightning to stay this open network where,
885
00:56:16.065 --> 00:56:21.765
like, if I open a channel to you, you don't ask too many questions. Otherwise, it will be a failure. Otherwise, it will be
886
00:56:25.550 --> 00:56:26.290
by regulators.
887
00:56:26.910 --> 00:56:28.610
That's the big problem. If
888
00:56:29.710 --> 00:56:31.090
appears to connect to you,
889
00:56:31.710 --> 00:56:32.190
that you
890
00:56:32.845 --> 00:56:35.105
then lightning will tend to centralize.
891
00:56:37.565 --> 00:56:43.960
So that's why I'm also not too big of a fan of routing hosted channels. Like, they are great for users, for end users,
892
00:56:44.280 --> 00:56:45.099
but between,
893
00:56:46.599 --> 00:56:47.740
your lightning nodes,
894
00:56:49.320 --> 00:56:54.885
they create a a big risk of, like, exit scams. Like, let's say, half your channels,
895
00:56:55.425 --> 00:56:57.685
a host of channels, and then you just put
896
00:56:58.080 --> 00:57:03.380
put all the funds out of them, put them into your real channels, and close them, and you're gone.
897
00:57:03.760 --> 00:57:05.540
That's a big risk. And secondly,
898
00:57:06.880 --> 00:57:07.360
you
899
00:57:08.005 --> 00:57:08.905
might actually get
900
00:57:09.525 --> 00:57:10.745
the first time before
901
00:57:11.205 --> 00:57:13.685
you do this. You get the big,
902
00:57:14.005 --> 00:57:14.505
benefit.
903
00:57:16.630 --> 00:57:17.610
Unfair benefits
904
00:57:18.510 --> 00:57:19.010
of
905
00:57:20.150 --> 00:57:20.970
the competition,
906
00:57:23.430 --> 00:57:24.625
namely that you don't
907
00:57:25.025 --> 00:57:25.685
need to,
908
00:57:26.865 --> 00:57:28.085
expand as much capital
909
00:57:29.025 --> 00:57:29.685
as you.
910
00:57:33.390 --> 00:57:37.890
I know. So I'm not not too big of a fan of routing host channels, but you might disagree.
911
00:57:42.295 --> 00:57:45.195
I haven't heard all of, what you said, but
912
00:57:48.470 --> 00:57:52.810
there was something unfair in there, and then I didn't hear. Can you please repeat that
913
00:57:53.110 --> 00:57:54.010
that part?
914
00:57:54.630 --> 00:57:56.170
What is exactly unfair?
915
00:57:59.335 --> 00:58:01.115
Essentially, you get an unfair advantage
916
00:58:01.655 --> 00:58:02.714
over the
917
00:58:03.015 --> 00:58:04.474
your peers that use
918
00:58:05.815 --> 00:58:07.035
fully backed channels.
919
00:58:08.529 --> 00:58:17.589
So, like, I mean, it's not really unfair in that sense, but, like, fortune until people figure out they can use this to exit scam and then the market will have to price in that risk.
920
00:58:20.005 --> 00:58:21.945
The market distortion that, disincentivizes,
921
00:58:22.805 --> 00:58:24.425
actually having the backing funds.
922
00:58:27.370 --> 00:58:28.670
Don't know about that.
923
00:58:29.610 --> 00:58:35.390
Well, to me, it's like, if you open a hosted channel, you take certain risk. Yes. You don't put
924
00:58:35.735 --> 00:58:37.035
funds on chain.
925
00:58:37.575 --> 00:58:38.075
So
926
00:58:38.375 --> 00:58:41.355
you have spared some working capital, but you have
927
00:58:41.735 --> 00:58:43.435
risk of exit scam. So
928
00:58:43.770 --> 00:58:47.150
to my understanding, it's fair. You understand your risks
929
00:58:47.450 --> 00:58:48.910
and which is important
930
00:58:49.210 --> 00:58:54.315
if something goes wrong, this doesn't spread towards Yeah. Exact. My fear is that people will under
931
00:58:55.755 --> 00:58:56.255
sorry.
932
00:59:04.150 --> 00:59:06.490
I mean, go on, Eric. I think Anton finished.
933
00:59:08.070 --> 00:59:10.135
Your fear is? Yeah. Yeah. Yeah. I,
934
00:59:10.755 --> 00:59:11.415
I finished.
935
00:59:13.955 --> 00:59:15.655
So you you were cutting
936
00:59:16.450 --> 00:59:17.990
it for me. It's probably me.
937
00:59:19.650 --> 00:59:20.150
But,
938
00:59:20.610 --> 00:59:21.510
yeah, if you
939
00:59:22.530 --> 00:59:24.390
understand these risks, it's great.
940
00:59:24.690 --> 00:59:25.250
Then I'll
941
00:59:27.674 --> 00:59:32.894
Yeah. Well, a lot of hosted channels could be a problem. I'd agree with that. But, hopefully,
942
00:59:33.275 --> 00:59:35.454
people won't be taking that much risks.
943
00:59:36.300 --> 00:59:37.280
This is specifically
944
00:59:37.900 --> 00:59:39.760
if the hosted channels are
945
00:59:40.140 --> 00:59:42.960
routing hosted channels. If they're private hosted channels
946
00:59:43.260 --> 00:59:44.320
for an end user,
947
00:59:46.155 --> 00:59:51.214
then you don't have that person. He was cutting in and out a bit for me. It was probably me. So so,
948
00:59:53.520 --> 00:59:54.960
yeah, my my fear is that,
949
00:59:55.360 --> 00:59:56.260
people underestimate
950
00:59:57.120 --> 00:59:58.500
the the excess game risk.
951
01:00:03.494 --> 01:00:05.434
Well, I see I mean it's hard to say.
952
01:00:06.055 --> 01:00:07.755
I mean, my fear is,
953
01:00:09.140 --> 01:00:11.640
lightning has not really operated in adversarial
954
01:00:11.940 --> 01:00:12.440
environment.
955
01:00:13.859 --> 01:00:17.480
I mean, lightning hasn't operated in adversarial environment, period.
956
01:00:19.724 --> 01:00:21.665
So I think most people are underestimating
957
01:00:22.125 --> 01:00:26.145
the risk, period, of having funds on Lightning. Would you guys disagree with that?
958
01:00:28.839 --> 01:00:35.260
Yeah. No. No. I I think those some of those attacks that people write white papers about,
959
01:00:35.640 --> 01:00:36.925
they're serious,
960
01:00:38.185 --> 01:00:45.085
and I think also no one is no one who wants to attack is has the knowledge to to operate these attacks
961
01:00:47.140 --> 01:00:50.360
so far, I guess. Well, there was this attack when
962
01:00:51.300 --> 01:00:53.080
lightning channels were not
963
01:00:53.380 --> 01:00:54.360
actually backed
964
01:00:55.055 --> 01:00:56.115
by transactions.
965
01:00:57.455 --> 01:00:57.955
So
966
01:00:59.215 --> 01:01:06.130
well I guess we were kind of running hosted channels the whole time, and we didn't even Yeah. Yeah. Without even knowing it.
967
01:01:06.589 --> 01:01:07.650
Yeah. That's true.
968
01:01:08.190 --> 01:01:10.210
I mean, I've I've had a relatively,
969
01:01:10.750 --> 01:01:16.515
you know, multiple relatively large lightning nodes for over 2 years now, and I've just literally
970
01:01:18.015 --> 01:01:21.075
I've just been waiting for my funds to get lost.
971
01:01:21.820 --> 01:01:23.120
That that hasn't happened yet.
972
01:01:30.415 --> 01:01:35.555
No. I mean, this this discussion is super interesting. I would go back to what Fiat Jaffe was saying earlier
973
01:01:36.095 --> 01:01:39.715
about why the lightning component in the first place. And to me,
974
01:01:40.830 --> 01:01:46.690
you know, would Eric's proposal be interesting still if he didn't have the Lightning component? Yes. Because I'm
975
01:01:47.125 --> 01:01:50.745
a I I I care about privacy on Bitcoin being easier,
976
01:01:52.485 --> 01:01:55.990
but it wouldn't be nearly as interesting to me for the interoperability
977
01:01:56.370 --> 01:01:59.110
aspect of it. Like, it's not only
978
01:01:59.890 --> 01:02:01.190
the fact that the federations
979
01:02:01.570 --> 01:02:02.390
can interoperate
980
01:02:02.770 --> 01:02:05.135
very easily. Like, what I've noticed with liquid,
981
01:02:05.675 --> 01:02:14.255
which absolutely nobody uses. I mean, I have mempool dot space up, but if I switch it, I could switch it right now to the to the liquid one.
982
01:02:14.750 --> 01:02:15.490
Just fucking
983
01:02:15.790 --> 01:02:16.770
absolutely empty.
984
01:02:19.150 --> 01:02:23.250
The the biggest friction to me with liquid is that it's a separate chain,
985
01:02:24.244 --> 01:02:28.025
and it's it's that in and out. It's it's moving between
986
01:02:28.325 --> 01:02:31.224
the two chains that is so difficult. So not only
987
01:02:34.710 --> 01:02:36.330
not only do you have the interoperability
988
01:02:37.110 --> 01:02:42.234
benefit for the actual federation, so you could have more federations that can, you know,
989
01:02:43.015 --> 01:02:44.635
work together via lightning.
990
01:02:45.895 --> 01:02:48.395
You also have that benefit of
991
01:02:48.970 --> 01:02:50.190
being able to
992
01:02:50.809 --> 01:02:51.309
directly
993
01:02:51.609 --> 01:02:55.470
operate you know, directly interact with any kind of other,
994
01:02:56.010 --> 01:02:56.910
Lightning Wallet,
995
01:02:57.555 --> 01:03:06.295
including the ton of merchants that are already onboarded onto Lightning. Like, if you go to El Salvador, like, no one accepts Liquid, no one will accept a new Federation token,
996
01:03:06.650 --> 01:03:08.350
but they're already accepting Lightning.
997
01:03:10.490 --> 01:03:14.510
So, like, that's the main advantage to me. Or if you use something like Strike to onboard
998
01:03:15.135 --> 01:03:21.315
and you're going bank account through Stripe, like, you can pay into any Lightning Wallet. If if Eric's
999
01:03:21.775 --> 01:03:22.275
proposal
1000
01:03:23.010 --> 01:03:29.670
rings true, then you could just go straight into that federation. You wouldn't have to deal with any external swap services or any friction like that.
1001
01:03:32.194 --> 01:03:33.635
I think his proposal
1002
01:03:35.395 --> 01:03:38.775
we we can't say very much because the lightning part is not
1003
01:03:39.075 --> 01:03:40.135
decided, but
1004
01:03:40.880 --> 01:03:43.779
but it has a kind of a swap thing.
1005
01:03:44.240 --> 01:03:53.565
I think it it's not very different from the thing I said. I was, like, I didn't I never finished that my bridge between liquid and,
1006
01:03:54.105 --> 01:03:55.325
Bitcoin lighting networks.
1007
01:03:55.970 --> 01:04:00.150
Like, something like that could could solve liquid like, could make liquid
1008
01:04:00.530 --> 01:04:01.030
reusable,
1009
01:04:01.810 --> 01:04:03.350
for example. And then I think
1010
01:04:03.865 --> 01:04:09.724
if Eric has federations that have a way to do this, like, they could be usable too.
1011
01:04:10.265 --> 01:04:12.924
And that's his idea. Right? It's just not
1012
01:04:13.310 --> 01:04:14.350
defining what he's going to
1013
01:04:17.390 --> 01:04:18.530
I'm going to
1014
01:04:18.910 --> 01:04:23.385
switch back from the liquid block explorer because that is just depressing as fuck.
1015
01:04:29.600 --> 01:04:31.940
Yeah. No. I mean, that makes sense to me.
1016
01:04:32.800 --> 01:04:36.740
We lost Eric, so now we're just having a conversation about his proposal without him.
1017
01:04:40.655 --> 01:04:46.915
What do you guys wanna cover? You have anything? And we have some more time here. If you you have any lightning hot takes?
1018
01:04:47.700 --> 01:04:53.400
Yeah. I tried to use Moon Wallet today for the first time. Oh, not With 2 use. Moon with 2 use.
1019
01:04:54.815 --> 01:04:57.075
Moon with 2. Yeah. 2 years. Yeah.
1020
01:04:57.454 --> 01:04:57.954
Yeah.
1021
01:04:58.415 --> 01:05:10.520
And I couldn't get a payment. I think the idea was that you would receive a lightning payment, and it would open a channel to you. Right? When I tried to pay that invoice, I generated it and it never opened a channel
1022
01:05:11.155 --> 01:05:17.495
because I wasn't able to pay the invoice, but the fees were too high. Something like that. All the notes, all the wallets I tried,
1023
01:05:17.795 --> 01:05:21.369
they always said that the fees are too high. So this is
1024
01:05:21.670 --> 01:05:23.529
like I'm just saying this
1025
01:05:23.829 --> 01:05:25.289
to say that this trustless
1026
01:05:25.910 --> 01:05:31.355
open channel and demand thing, it's it's very bad idea for me, at least in my
1027
01:05:32.375 --> 01:05:33.835
experience. Moon Moon is,
1028
01:05:35.335 --> 01:05:42.100
you know, like everyone else in this chat, I mean, besides me, is focused on, you know, trying to make mobile
1029
01:05:42.480 --> 01:05:42.980
UX,
1030
01:05:44.650 --> 01:05:45.150
easy.
1031
01:05:46.945 --> 01:05:50.645
The single best thing they've done is that if you scan any QR code,
1032
01:05:51.585 --> 01:05:52.645
you're able to,
1033
01:05:53.345 --> 01:05:54.085
pay it.
1034
01:05:54.670 --> 01:05:57.330
Whether that's a lightning QR code, whether that's
1035
01:05:57.950 --> 01:05:58.450
SegWit,
1036
01:05:59.150 --> 01:05:59.650
Legacy,
1037
01:06:00.110 --> 01:06:06.065
Taproot address, any QR code you can sign, you should be able to pay it. It registers, and you should be able to pay it.
1038
01:06:08.205 --> 01:06:09.905
The lightning side
1039
01:06:10.630 --> 01:06:12.810
operates on a semi custodial basis,
1040
01:06:17.510 --> 01:06:19.610
that that is settled on chain
1041
01:06:20.855 --> 01:06:23.974
relatively quickly after the fact. Now I'm pretty sure
1042
01:06:24.615 --> 01:06:32.710
Is it a a channel like like Phoenix, for example, that opens a channel to you? They don't open a channel to you. They're just using they're using
1043
01:06:33.250 --> 01:06:34.390
they're using swaps
1044
01:06:34.770 --> 01:06:35.270
and,
1045
01:06:36.665 --> 01:06:42.365
they're using swaps, and the overwhelming majority of your funds are actually kept in a 2 of 2 multisig on chain,
1046
01:06:43.225 --> 01:06:45.165
and they're using on demand swaps.
1047
01:06:46.870 --> 01:06:51.290
Now I think their biggest issue is something we're gonna see in the lightning space a lot,
1048
01:06:51.750 --> 01:06:53.130
where it is so
1049
01:06:55.585 --> 01:07:02.405
it it is it is easy to use, so it's recommended often. And with the with El Salvador and with this, you know,
1050
01:07:02.730 --> 01:07:08.260
more people using mobile lightning wallets, their liquidity is just completely wrecked. Like, I they just do not have,
1051
01:07:10.325 --> 01:07:11.705
they do not have good liquidity.
1052
01:07:12.325 --> 01:07:16.105
I've noticed there many times trying to receive lightning on moon.
1053
01:07:17.970 --> 01:07:21.589
It's definitely a a massive pain point. And I also don't know
1054
01:07:21.890 --> 01:07:22.369
how they're
1055
01:07:23.490 --> 01:07:30.545
if everything's supposed to settle on chain, like, that does not scale if we actually have sustained high fees on chain.
1056
01:07:31.565 --> 01:07:32.065
So
1057
01:07:32.685 --> 01:07:33.825
that's a whole different.
1058
01:07:34.260 --> 01:07:35.860
Well, my understanding is very
1059
01:07:36.660 --> 01:07:44.984
I thought it was opening channels. I think their the the v one was with Yeah. It's also news to me. I saw they had some kind of channel somewhere.
1060
01:07:45.525 --> 01:07:50.265
I mean, on user side. I knew I knew the v one was based on on swaps.
1061
01:07:50.830 --> 01:07:55.730
I didn't know about this multi 6. But then I listened to some podcasts whether the
1062
01:07:56.350 --> 01:07:58.370
Dario, the the guy from
1063
01:07:58.895 --> 01:08:00.755
said that he had that V2 that had
1064
01:08:01.375 --> 01:08:03.635
a variant of l and d running on the phone.
1065
01:08:03.935 --> 01:08:05.954
So it's So maybe I'm wrong.
1066
01:08:06.390 --> 01:08:08.570
Maybe I'm operating under the previous one.
1067
01:08:09.110 --> 01:08:10.170
But either way,
1068
01:08:10.550 --> 01:08:12.490
I've used Moon, and the liquidity
1069
01:08:13.030 --> 01:08:14.730
is a fucking mess.
1070
01:08:15.935 --> 01:08:17.795
Yeah. Liquidity is always a problem.
1071
01:08:18.255 --> 01:08:19.795
The biggest one, I'd say.
1072
01:08:20.255 --> 01:08:23.795
U x u x x issues does not come close to this.
1073
01:08:24.790 --> 01:08:28.010
I'd say liquidity is the one we should solve somehow.
1074
01:08:29.989 --> 01:08:34.615
But isn't it just, like, inherently fucked the way, like, liquidity works on the Lightning Network?
1075
01:08:36.535 --> 01:08:37.035
Maybe.
1076
01:08:37.815 --> 01:08:41.995
We are yet to determine this, I guess. Like, the cool part
1077
01:08:42.340 --> 01:08:49.000
the cool part of of lightning is this, you know, interoperable payment channel network that is relatively permissionless,
1078
01:08:50.344 --> 01:08:52.364
but the trade off of that is
1079
01:08:53.225 --> 01:08:57.965
that liquidity is divide I guess, like, multipar payments and stuff like that could Mhmm.
1080
01:08:58.350 --> 01:09:00.530
Help mitigate it. Right? But you're still
1081
01:09:00.830 --> 01:09:02.990
mitigating something. It's still a inherent
1082
01:09:03.710 --> 01:09:04.210
Yeah.
1083
01:09:05.875 --> 01:09:13.410
My hope is that hosted channels and private routing will address this at at least to some extent, if not solve it.
1084
01:09:13.890 --> 01:09:16.390
So you mentioned private routing earlier.
1085
01:09:16.850 --> 01:09:17.350
Yeah.
1086
01:09:17.650 --> 01:09:24.235
If the name is any good, I assume it means routing over private channels. Am I incorrect about that? Yes. It's exactly that.
1087
01:09:24.615 --> 01:09:25.835
Okay. It's a good name.
1088
01:09:27.255 --> 01:09:34.080
So how far away are we from that? Like, I thought you can't route over private channels because they're not publicly broadcast in the gossip network.
1089
01:09:35.535 --> 01:09:40.835
Yeah. Oh, well, I I can elaborate on all of that if you want. Yeah. Elaborate. Hit us.
1090
01:09:41.455 --> 01:09:41.955
So,
1091
01:09:43.230 --> 01:09:51.410
let's start from basics probably. There are 2 kinds of channels on lightning, public ones and private ones. Or
1092
01:09:51.845 --> 01:09:57.065
another name for private ones is unannounced channels. That's basically the only difference,
1093
01:09:58.165 --> 01:10:00.105
between them and public channels.
1094
01:10:01.250 --> 01:10:02.710
Public channels exist
1095
01:10:03.330 --> 01:10:10.390
in routing graph, and, they are visible by everyone who has the graph on their devices. And as such,
1096
01:10:10.915 --> 01:10:13.574
everyone can use these channels to route payments.
1097
01:10:14.275 --> 01:10:15.895
And the private channels,
1098
01:10:16.835 --> 01:10:18.295
they just don't do that.
1099
01:10:18.830 --> 01:10:21.889
And, the reason they don't do that is because
1100
01:10:22.270 --> 01:10:27.489
private channels are typically opened to mobile devices, which are mostly offline.
1101
01:10:28.125 --> 01:10:31.905
So even if they were to broadcast themselves to graph,
1102
01:10:33.405 --> 01:10:35.585
it would make very little sense because
1103
01:10:36.310 --> 01:10:42.170
most of the times, they would be unusable because the device is offline with the way mobile devices are used.
1104
01:10:42.710 --> 01:10:44.489
And, another problem
1105
01:10:45.125 --> 01:10:53.864
with that would be scalability. That is if we ever to get millions of phones with private channels, if they all were to broadcast
1106
01:10:55.440 --> 01:11:03.140
their info to routing graph, they would just, I guess, either bring it down or make other nodes prude them prune them.
1107
01:11:04.135 --> 01:11:04.614
So,
1108
01:11:05.094 --> 01:11:06.155
up until recently,
1109
01:11:06.775 --> 01:11:07.675
routing routing
1110
01:11:09.335 --> 01:11:11.835
through mobile channels was completely invisible.
1111
01:11:12.770 --> 01:11:13.270
But,
1112
01:11:14.050 --> 01:11:16.389
since the introduction of private routing,
1113
01:11:16.690 --> 01:11:18.070
it actually became
1114
01:11:18.449 --> 01:11:18.949
possible
1115
01:11:19.250 --> 01:11:21.750
to route through private channels exactly
1116
01:11:22.594 --> 01:11:28.534
when mobile device is online, even if it's something like 5 minutes per day, still possible,
1117
01:11:29.074 --> 01:11:29.574
and
1118
01:11:30.599 --> 01:11:32.460
without them becoming public.
1119
01:11:33.079 --> 01:11:33.579
So
1120
01:11:34.360 --> 01:11:35.420
I think this
1121
01:11:36.360 --> 01:11:38.380
is very interesting area. It,
1122
01:11:39.585 --> 01:11:42.245
once implemented, private routing will unlock
1123
01:11:43.985 --> 01:11:47.880
this routing liquidity of all those private channels, which was inaccessible
1124
01:11:48.580 --> 01:11:49.480
earlier. And,
1125
01:11:49.860 --> 01:11:50.440
of course,
1126
01:11:50.820 --> 01:11:53.700
this is another way to increase liquidity on network and,
1127
01:11:54.180 --> 01:11:56.945
increase increase the number of successful payments.
1128
01:11:57.644 --> 01:11:58.144
So
1129
01:11:58.684 --> 01:12:05.950
I'm looking forward to that. I'm working on that currently, finalizing this. And, this is expected to happen this year, hopefully,
1130
01:12:06.810 --> 01:12:07.550
in simple.
1131
01:12:09.130 --> 01:12:10.730
The the main problem with,
1132
01:12:11.690 --> 01:12:18.875
like, the private channel routing should be that you don't know that they exist. Isn't that that? So how do you solve the problem of,
1133
01:12:19.335 --> 01:12:23.260
like, making the people that want to route through them aware of them?
1134
01:12:24.619 --> 01:12:25.760
Yeah. Once the,
1135
01:12:26.380 --> 01:12:26.880
wallet
1136
01:12:27.260 --> 01:12:43.560
with such private channels becomes online, it would send a special message to all of all of its peer who support private route and that it can private route. It would basically be basically be saying to each peers that I am now online, and I can route
1137
01:12:44.180 --> 01:12:45.000
this amount.
1138
01:12:46.100 --> 01:12:47.480
That's it. And
1139
01:12:48.785 --> 01:12:56.085
peers can use it themselves, and they can further relay this message, maybe 2 or 3 hopes further to inform
1140
01:12:56.889 --> 01:12:58.909
their own peers that there exists
1141
01:12:59.530 --> 01:13:06.485
private router right now, right here. And all of them would have this knowledge and will be able to use it.
1142
01:13:06.945 --> 01:13:07.844
That's the plan.
1143
01:13:08.864 --> 01:13:09.364
So
1144
01:13:10.305 --> 01:13:16.739
that would make these channels, much less private in nature, which might be okay depending on usage. It doesn't because,
1145
01:13:17.600 --> 01:13:20.659
an information they will be sending is just,
1146
01:13:21.440 --> 01:13:24.775
like, thanks to trampoline routing. They will be basically
1147
01:13:25.235 --> 01:13:39.580
saying yeah. They will be saying I can route this amount, but they won't be saying in how. They won't be disclosing how many channels they have. They could have, like, hosted private channels and use it for routing or something
1148
01:13:40.075 --> 01:13:41.695
entirely wild then. No.
1149
01:13:42.715 --> 01:13:46.415
Something like Telegram group where they exchange 3 majors or something.
1150
01:13:48.235 --> 01:13:49.760
But yeah. So
1151
01:13:50.700 --> 01:13:52.160
what I'm getting is, like,
1152
01:13:52.780 --> 01:13:54.320
suppose I have a a node
1153
01:13:54.700 --> 01:13:56.960
that has a simple Bitcoin wallet,
1154
01:13:57.580 --> 01:14:07.025
connected to it through a to a normal channel or a hosted channel. Mhmm. And and that same simple Bitcoin wallet is also connected to someone else's node.
1155
01:14:07.325 --> 01:14:07.825
Yes.
1156
01:14:08.300 --> 01:14:09.360
And then I guess
1157
01:14:10.060 --> 01:14:15.120
yeah. And then when that that wallet is online, it sends a message to my node,
1158
01:14:16.045 --> 01:14:25.020
and my node is about to make a payment. And so it uses it sends the payment to that simple Bitcoin wallet. Yeah. That simple Bitcoin wallet forwards it to the other node.
1159
01:14:25.500 --> 01:14:28.960
Yeah. It can use that option. It can use its own graph or
1160
01:14:30.220 --> 01:14:33.920
trampoline, this trampoline router, whatever is cheaper or more preferable.
1161
01:14:34.605 --> 01:14:35.985
Something like that. Yes.
1162
01:14:38.045 --> 01:14:42.225
But if I have a peer that's, like, another routing node that is online.
1163
01:14:42.730 --> 01:14:43.230
Mhmm.
1164
01:14:43.530 --> 01:14:51.050
I can send a message to that peer saying, oh, I have a private channel here and an announcement channel here that's A private router. Let's say
1165
01:14:51.635 --> 01:14:52.455
Yeah. This
1166
01:14:52.795 --> 01:14:53.295
way.
1167
01:14:53.635 --> 01:15:04.900
In that tier have a private router right here, right now, which is important. It is online right now, and it is ready to route such an amount. So if you want to route it through the tier, then be my guest.
1168
01:15:06.480 --> 01:15:11.515
Yes. So I guess for users, you have to be very careful about interactions with hosted channels because
1169
01:15:12.135 --> 01:15:14.315
as a user, I might be balancing
1170
01:15:14.935 --> 01:15:28.429
my funds really cautiously between different host channel provider because I might not trust any of them fully, and I'm prepared to lose any of these channels. So if I now enable routing between them, then that could, essentially
1171
01:15:29.065 --> 01:15:29.565
distort,
1172
01:15:30.265 --> 01:15:31.005
the distribution.
1173
01:15:32.665 --> 01:15:38.270
I guess we can limit, like, oh, I have a a or make a channel host a channel here that has a limit of
1174
01:15:39.070 --> 01:15:44.370
an amount. That's the amount that you're willing to lose. But I think this also works, this private routing,
1175
01:15:44.750 --> 01:15:48.050
with just normal channels. No no hosted channels involved. Right?
1176
01:15:50.075 --> 01:15:50.575
Right?
1177
01:15:54.075 --> 01:15:54.575
Yeah.
1178
01:15:55.440 --> 01:15:55.940
Well,
1179
01:15:56.719 --> 01:16:03.460
I can say that, yes, was using private channel for payments or for routing is always a risk, but, like,
1180
01:16:04.525 --> 01:16:10.465
I guess we're all grown ups here, so we can manage our risks. We cannot use them if we don't want to
1181
01:16:11.405 --> 01:16:12.145
or otherwise.
1182
01:16:13.490 --> 01:16:19.510
I'm not judged, like, how bad this is. I don't know if we're all grown ups. I don't know if we can manage our own risk.
1183
01:16:21.225 --> 01:16:22.845
Okay. Then we'll find
1184
01:16:25.545 --> 01:16:28.125
while I have you oh, yeah. Go. Hit us.
1185
01:16:29.160 --> 01:16:30.380
One question that,
1186
01:16:30.920 --> 01:16:33.420
like, I had while you talked about
1187
01:16:33.720 --> 01:16:35.820
it. Did you do any research
1188
01:16:36.175 --> 01:16:41.635
how much it would increase the liquidity on Lightning or how much it would actually benefit? Because
1189
01:16:42.095 --> 01:16:45.475
I did some probing back in 2019, so it's a long time ago.
1190
01:16:46.180 --> 01:16:59.495
But it appeared that the user channels actually made up not that much of capacity. Like, they were pretty small in general, and then there was a big core network, with much bigger channels and a larger routing capacity.
1191
01:17:00.115 --> 01:17:01.575
So I could imagine that
1192
01:17:02.210 --> 01:17:02.710
enabling
1193
01:17:03.170 --> 01:17:16.664
these user channels from time to time only, like, that actually doesn't do a lot of good for quite some implementation complexity and quite some traffic because every time now that someone comes online or goes offline, you need to send messages and stuff like that.
1194
01:17:17.844 --> 01:17:19.545
Well, I haven't run any simulations
1195
01:17:20.244 --> 01:17:21.940
or or something like that, and
1196
01:17:23.760 --> 01:17:29.540
I don't have anything definite to say on this. This is, yeah, kinda an uncharted territory.
1197
01:17:29.885 --> 01:17:35.745
And they say, I think I should, like, run this and see how it goes. That's the plan.
1198
01:17:36.205 --> 01:17:39.425
And then I would be able to say something more concrete
1199
01:17:39.760 --> 01:17:40.980
after some time
1200
01:17:41.520 --> 01:17:43.300
of it's being on.
1201
01:17:45.520 --> 01:17:49.265
One thing I like I don't know if you I think you didn't mention this, but
1202
01:17:50.065 --> 01:18:00.630
the understanding I had before was that it would be good to have this private routing. So, for example, Breeze, the Breeze node opens channels to to a bunch of mobile wallets,
1203
01:18:01.010 --> 01:18:01.670
and they'll
1204
01:18:01.970 --> 01:18:06.070
it locks liquidity there that's, like, lost forever or
1205
01:18:06.370 --> 01:18:10.195
for a long time. And with this, like, the this can
1206
01:18:11.215 --> 01:18:18.480
can use these channels to to route their business. Yeah. Currently, liquidity in private channels is basically a loss for looting for But
1207
01:18:19.040 --> 01:18:19.540
tiers.
1208
01:18:20.480 --> 01:18:22.420
But Yes. I've heard,
1209
01:18:24.804 --> 01:18:26.344
many Lightning devs
1210
01:18:26.965 --> 01:18:28.485
say that the
1211
01:18:30.005 --> 01:18:33.925
and I know I know not all Lightning devs agree, especially the ones that I have,
1212
01:18:34.550 --> 01:18:35.370
in this conversation right now.
1213
01:18:36.150 --> 01:18:44.575
I've heard many Lightning devs say the expectation in the future is that most end users will have a single balanced channel
1214
01:18:45.275 --> 01:18:47.295
with, like, a well connected routing node.
1215
01:18:47.835 --> 01:18:48.895
Do you guys not
1216
01:18:49.290 --> 01:18:57.150
believe that's the expectation, that's not what we should expect? Because, I mean, if that's the case, then they're not gonna be really providing any,
1217
01:18:58.345 --> 01:19:02.445
helpful liquidity there if they're just they're just like an endpoint almost.
1218
01:19:02.745 --> 01:19:05.885
Yeah. If they have only 1 channel, they obviously can't root.
1219
01:19:06.310 --> 01:19:07.850
They need to have at least 2.
1220
01:19:08.790 --> 01:19:09.430
Well, it's,
1221
01:19:09.910 --> 01:19:11.530
it's a hard question because,
1222
01:19:12.630 --> 01:19:14.330
in order to pull this
1223
01:19:16.475 --> 01:19:23.855
on the provider side, they really need to have a lot a lot of money to afford to open a private channel to everyone.
1224
01:19:24.400 --> 01:19:29.620
And then a lot of that liquidity that they put in this channel would be lost because
1225
01:19:30.160 --> 01:19:32.900
many of these channels would be offline for,
1226
01:19:34.085 --> 01:19:35.465
long periods of time.
1227
01:19:36.245 --> 01:19:36.745
So
1228
01:19:37.765 --> 01:19:38.425
it's really
1229
01:19:38.725 --> 01:19:42.425
a hard feat, I'd say, to prove off to make this all profitable.
1230
01:19:43.190 --> 01:19:43.690
So
1231
01:19:44.630 --> 01:19:45.449
my understanding
1232
01:19:45.750 --> 01:19:52.705
that is that routing is essential to lightnings. Whenever you have a channel, you need to be able to route from it somehow.
1233
01:19:53.405 --> 01:19:53.905
And,
1234
01:19:54.285 --> 01:19:56.385
otherwise, it's just broken design.
1235
01:19:57.565 --> 01:19:59.425
Maybe I'm wrong, but time will tell.
1236
01:20:00.350 --> 01:20:04.425
Yeah. I think in my opinion
1237
01:20:05.355 --> 01:20:09.430
Wrong. Okay. And in my opinion,
1238
01:20:10.205 --> 01:20:12.465
like, the people that have just one channel,
1239
01:20:13.085 --> 01:20:16.785
today, like, they probably won't have a channel at all in the future because,
1240
01:20:17.245 --> 01:20:18.670
they are typically just,
1241
01:20:19.150 --> 01:20:21.890
end users that don't have too much money in Lightning.
1242
01:20:22.510 --> 01:20:25.489
So even as a Bitcoin, like, if you can have
1243
01:20:25.949 --> 01:20:26.449
an
1244
01:20:27.695 --> 01:20:41.030
your your lightning funds essentially that today you have in this, weird one channel that might go offline if your counterparty goes offline. So it's not really that that great for you. But you could put it into a federation, let's say, in the Ecash Federation. And
1245
01:20:41.570 --> 01:20:42.630
that would give you
1246
01:20:43.489 --> 01:20:44.390
close enough,
1247
01:20:45.985 --> 01:20:47.485
like, nearly the same
1248
01:20:47.785 --> 01:20:48.285
functionality
1249
01:20:48.985 --> 01:20:51.165
as for if you're one big channel today.
1250
01:20:52.025 --> 01:20:52.525
And,
1251
01:20:53.100 --> 01:20:58.540
like, the funds that you really want to keep for saving, that you keep on train anyway. Like, that,
1252
01:20:59.020 --> 01:21:04.955
it's not something you would keep on your mobile phone wallet, in this one big channel because you might lose it.
1253
01:21:06.295 --> 01:21:07.435
So I see these
1254
01:21:07.975 --> 01:21:12.600
end user notes with only one channel disappear. Like, you will either be a routing node,
1255
01:21:13.700 --> 01:21:15.320
even if it's just the raspberry
1256
01:21:16.340 --> 01:21:18.515
even if it's just the raspberry pi at home.
1257
01:21:21.155 --> 01:21:22.455
Yeah. That could be true.
1258
01:21:25.235 --> 01:21:26.775
I'd actually agree with it.
1259
01:21:27.260 --> 01:21:33.600
Either you are routing node of some kind, private routing node, public routing node, or probably it would be
1260
01:21:34.035 --> 01:21:35.895
a custodial user of some kind.
1261
01:21:36.595 --> 01:21:39.335
Yeah. Maybe a hostage Makes a lot of sense.
1262
01:21:39.875 --> 01:21:42.410
Like, just imagine we are onboarding the next,
1263
01:21:42.970 --> 01:21:44.970
like, 6, 6,000,000,000 users.
1264
01:21:46.650 --> 01:21:53.595
Like, not all of them are the technical that they are actually able to run a note. Not all of them have the funds to run their own note.
1265
01:21:55.335 --> 01:22:03.040
So I imagine, like, if you have your local community of, let's say, 100 or 1000 people, then there will be maybe 4 or
1266
01:22:03.340 --> 01:22:07.235
7 of them that are technical enough that, Bitcoiners today even.
1267
01:22:07.855 --> 01:22:08.994
And they will still
1268
01:22:09.375 --> 01:22:11.375
be self custodying. They will,
1269
01:22:12.790 --> 01:22:17.690
like, doing all using all the right cypherpunk tools, that we are building today.
1270
01:22:18.389 --> 01:22:20.969
But in addition to that, they will also be providing
1271
01:22:21.595 --> 01:22:33.370
the service for their local community that all these other people can access lightning, for example, or federations, or they could be hosted channel service providers depending on what, success succeeds in the market.
1272
01:22:34.150 --> 01:22:34.650
So,
1273
01:22:35.510 --> 01:22:37.690
yeah, I see these mobile wallets
1274
01:22:40.005 --> 01:22:42.665
with actual lightning channels disappearing because
1275
01:22:43.364 --> 01:22:45.705
it just doesn't make any sense to lock funds
1276
01:22:46.050 --> 01:22:51.270
in a wallet that is only online from time to time. Like, it's not good use of capital.
1277
01:22:53.865 --> 01:22:57.485
Do do you have any idea of what is the, like, the
1278
01:22:58.665 --> 01:22:59.565
the the way,
1279
01:23:00.105 --> 01:23:00.605
Esync
1280
01:23:01.065 --> 01:23:04.770
and Breeze are planning to make money on their
1281
01:23:06.350 --> 01:23:07.489
their channels on demand
1282
01:23:07.870 --> 01:23:13.665
thing. I mean, their goal right now I mean, they're just burning money for user acquisition right now. They're just eating it.
1283
01:23:15.324 --> 01:23:17.905
And then later, they'll have ads on the the wallets.
1284
01:23:18.285 --> 01:23:18.710
What?
1285
01:23:19.590 --> 01:23:20.489
Well, I guess,
1286
01:23:21.030 --> 01:23:27.530
the idea is that there will be so many payments that they will be making some money on rooting, I guess.
1287
01:23:28.375 --> 01:23:29.435
Something like that.
1288
01:23:30.614 --> 01:23:38.420
I mean, I have respect for both those teams, but, I mean, also, there's there's some money to be made on data. I don't know if they're willing to actually
1289
01:23:38.880 --> 01:23:42.660
go into that business, but there's some data monetization that you can do there.
1290
01:23:44.465 --> 01:23:46.304
Yeah. I think the secret plan is,
1291
01:23:46.705 --> 01:23:50.885
that opening all these channels allows you as a company allows them as a company
1292
01:23:51.264 --> 01:23:54.370
to buy a lot of Bitcoin, and that will be enough in the future.
1293
01:23:56.270 --> 01:24:02.825
They're forced huddling because they just have all these empty chat they have all these channels that no one's using, and it's just sitting there.
1294
01:24:04.245 --> 01:24:06.425
Well, hopefully, that works out for them. I,
1295
01:24:09.210 --> 01:24:13.950
do you guys know was so, I mean, Eric, I assume, like so what you expect
1296
01:24:14.825 --> 01:24:19.965
is instead of users having this single channel open is they're gonna have, you know, some kind of
1297
01:24:20.425 --> 01:24:21.965
semi custodial relationship,
1298
01:24:23.180 --> 01:24:25.840
whether that's through your proposal or hosted channels
1299
01:24:26.460 --> 01:24:28.720
or community wallets or something like that.
1300
01:24:29.180 --> 01:24:31.920
Yeah. Exactly. Like, there's also a certain
1301
01:24:32.495 --> 01:24:33.715
option kind of,
1302
01:24:34.335 --> 01:24:38.114
like, channel factories, it's called. It's even more researchy than what I'm doing.
1303
01:24:38.415 --> 01:24:42.630
I think that's maybe in 10 years. I don't know. Maybe I'm wrong on that.
1304
01:24:43.250 --> 01:24:46.310
But where multiple people could come together and run,
1305
01:24:46.770 --> 01:24:48.630
like, one lightning note together
1306
01:24:48.995 --> 01:24:51.495
and share channels and stuff like that, which is also
1307
01:24:51.875 --> 01:24:55.255
pretty cool in my opinion. But, yeah, either you,
1308
01:24:56.250 --> 01:24:58.830
like, are actually routing, have multiple channels,
1309
01:24:59.610 --> 01:25:00.410
or you,
1310
01:25:00.890 --> 01:25:04.185
are using such a note from someone else. Like, there's,
1311
01:25:04.965 --> 01:25:17.210
like, no way in my opinion that, some people will be willing to lock up funds for you, just so you can use them as a routing notes. You have to contribute something too by routing.
1312
01:25:17.590 --> 01:25:22.025
So I actually agree with Anton on that. Yeah. Just to go back I think
1313
01:25:22.325 --> 01:25:24.105
I think you guys agree on a lot.
1314
01:25:25.205 --> 01:25:28.345
Just to go back, first of all, that Moon conversation, I'm 99%
1315
01:25:28.725 --> 01:25:39.025
sure that Moon, their v two implementation hasn't released yet, and they're still doing swaps, but their intention is to run some kind of mobile lightning client. Maybe they'll choose a Morden. That could be interesting.
1316
01:25:41.565 --> 01:25:47.480
But I'm pretty sure v two isn't out yet. You guys know how do any of you guys know how Bitcoin Beach Wallet works?
1317
01:25:48.739 --> 01:25:51.400
Nope. I have no idea. It's probably the server.
1318
01:25:52.405 --> 01:25:53.925
From what I'm getting,
1319
01:25:54.245 --> 01:25:55.605
the lightning note is,
1320
01:25:56.405 --> 01:26:02.060
fully custodial, but it only holds, like, a small percentage of the funds. I think I heard something like 5%,
1321
01:26:02.920 --> 01:26:08.140
while the majority of funds are held on chain in the multisig wallet. So it's actually
1322
01:26:08.605 --> 01:26:09.985
even closer to,
1323
01:26:10.685 --> 01:26:12.065
like, Federated Ecash
1324
01:26:12.605 --> 01:26:17.185
than hosted channels kind of because the most of the funds are held in the Federated,
1325
01:26:17.725 --> 01:26:19.250
way, just manually.
1326
01:26:21.470 --> 01:26:24.610
That's kinda how you view, like, the early implementations
1327
01:26:24.990 --> 01:26:31.605
of your proposal going. Right? Where you just have, like, a small portion held in a custodial lightning wallet and the majority is held in the federation.
1328
01:26:32.385 --> 01:26:33.205
Yeah. Yeah.
1329
01:26:33.985 --> 01:26:37.490
Well, that's the I think the the the multi sig part is like
1330
01:26:38.450 --> 01:26:38.950
sorry.
1331
01:26:39.330 --> 01:26:40.070
Go on,
1332
01:26:40.370 --> 01:26:48.835
Fiat, Jeff. I think this multi sig part is like some ad hoc thing that you can do or cannot do. For example, LNTPX bought
1333
01:26:49.775 --> 01:26:51.235
most of the the
1334
01:26:51.695 --> 01:26:55.489
the funds that the balance of users are on the Lightning node,
1335
01:26:55.869 --> 01:26:57.170
but, like, I could
1336
01:26:57.550 --> 01:26:58.929
close some channels and
1337
01:26:59.309 --> 01:27:03.635
make a multi multi sig on chain wallet and and and say my
1338
01:27:04.095 --> 01:27:05.715
the analytics part is partly
1339
01:27:06.175 --> 01:27:06.755
a federation.
1340
01:27:07.695 --> 01:27:12.110
But that I I don't think that changes the the nature of the custodianship. Like,
1341
01:27:12.489 --> 01:27:12.989
the
1342
01:27:13.370 --> 01:27:16.110
the Bitcoin Beach is, like, is a server with
1343
01:27:16.410 --> 01:27:17.150
an API,
1344
01:27:17.715 --> 01:27:24.455
HTTP API that the wallet stopped you, like, the normal custodial thing. But they have this this idea of,
1345
01:27:25.710 --> 01:27:28.610
local communities each running their own server, which is
1346
01:27:28.989 --> 01:27:33.889
not not an uncommon model. Like, Allen Beats also has the same idea.
1347
01:27:34.685 --> 01:27:38.305
And I think hosted channels is, like, an an evolution of that.
1348
01:27:39.485 --> 01:27:40.625
Because they could actually
1349
01:27:41.165 --> 01:27:48.219
they could they could mix host of channels with that relatively easily. Right? Like, the custodial lightning wallet could be using hosted channels,
1350
01:27:49.239 --> 01:27:52.915
and then they can have the majority of funds held on chain in multisig.
1351
01:27:54.094 --> 01:28:00.114
Yeah. Yeah. The same could be could be true for an hosted channel from Anton today, for example.
1352
01:28:01.670 --> 01:28:02.969
Yeah. It's exactly true.
1353
01:28:03.429 --> 01:28:10.215
Yeah. But, we have Jeff. Like, you you of all people should agree that, putting some of your funds in, off
1354
01:28:10.675 --> 01:28:15.895
chain, on chain wallet would probably have been a good idea, like, given the recent tech.
1355
01:28:16.330 --> 01:28:19.710
Like, that's exactly one thing you are guarding against with that.
1356
01:28:20.330 --> 01:28:25.950
Yeah. Yeah. And I agree. Like, even to a bigger degree if, you had the Allen Bits community
1357
01:28:26.554 --> 01:28:28.415
where you have a 2 or 3 multisig.
1358
01:28:29.114 --> 01:28:35.550
And this community has to decide when to replenish your funds in your writing note. And I agree it would be a lot of work,
1359
01:28:36.270 --> 01:28:39.650
then you wouldn't be the single point of failure anymore, kind of.
1360
01:28:42.085 --> 01:28:47.065
Or maybe you still would be because the ledger of the account balances would still be in your hand.
1361
01:28:47.685 --> 01:28:48.185
Okay.
1362
01:28:49.130 --> 01:28:51.310
In that sense, yeah, that's problematic. So
1363
01:28:51.690 --> 01:28:57.215
combining that with hosted channels so you get actual proof of, how much you own, that would be cool.
1364
01:28:57.594 --> 01:29:00.255
Yeah. But then it becomes impossible on Telegram.
1365
01:29:01.675 --> 01:29:02.574
Yeah. Yeah.
1366
01:29:03.630 --> 01:29:06.530
That's why I'm building my stuff not on Telegram.
1367
01:29:10.765 --> 01:29:13.325
Yeah. But, one thing I wanted to ask,
1368
01:29:13.725 --> 01:29:14.225
Anton,
1369
01:29:15.005 --> 01:29:16.305
before we end this,
1370
01:29:17.085 --> 01:29:20.760
like, I got some feedback from people that if we wanted to do
1371
01:29:21.300 --> 01:29:27.305
e cache sooner than my federated e cache proposal, why not just combine it with hosted channels? Like,
1372
01:29:27.865 --> 01:29:29.245
you could probably integrate,
1373
01:29:30.425 --> 01:29:35.805
e cache with hosted channels in a way that, you don't know users' balance anymore. Like,
1374
01:29:36.580 --> 01:29:39.240
I guess, from the our conversation we had already,
1375
01:29:39.780 --> 01:29:50.785
the problem is that you can't get, the proof of payment and stuff like that because, e cash behaves so differently from a lightning channel. But in principle, you could still do,
1376
01:29:52.119 --> 01:29:54.940
the payments and routing stuff. Like, for example,
1377
01:29:55.320 --> 01:30:00.219
if someone wants to pay an you to pay an invoice for them, they generate the routing
1378
01:30:00.875 --> 01:30:02.735
information or generate the onion,
1379
01:30:03.115 --> 01:30:07.695
give it, to the host of channel provider, also give the e cache to the host of channel provider.
1380
01:30:08.230 --> 01:30:12.250
And the host of channel provider knows because of the e cache that they should,
1381
01:30:12.710 --> 01:30:14.970
forward the onion message, during the payment.
1382
01:30:17.355 --> 01:30:20.655
Well, maybe. It's, of course, much easier said than done.
1383
01:30:22.075 --> 01:30:28.940
Yeah. Certainly. Certainly. But, like, nonfederated e cache is actually, like, pretty old and pretty well established.
1384
01:30:29.480 --> 01:30:33.179
Like, when you look at the Rabi Sabi paper, they have a great
1385
01:30:35.145 --> 01:30:36.765
a great cryptographic protocol
1386
01:30:37.065 --> 01:30:43.550
they use that even allows arbitrary amounts to be encoded in the ecash tokens. So you don't need multiple of them
1387
01:30:43.869 --> 01:30:48.130
necessarily, but you can have, Ecash tokens for arbitrary amounts that are still anonymous.
1388
01:30:50.270 --> 01:30:58.910
So maybe that is a interesting thing to look at, for you because you could probably have a working prototype much sooner than me because it's,
1389
01:30:59.310 --> 01:31:02.530
like, much easier to build it in a centralized way than federated.
1390
01:31:06.035 --> 01:31:12.215
Well, perhaps I think I should finish basic hosted channels first because Yes.
1391
01:31:12.750 --> 01:31:16.369
Although it's in production already, it's not completely ready.
1392
01:31:16.750 --> 01:31:20.050
There is still some work to do, so first things first.
1393
01:31:21.575 --> 01:31:22.875
Well, as an end user,
1394
01:31:23.335 --> 01:31:24.955
I would love if you guys collaborated.
1395
01:31:27.815 --> 01:31:32.820
Yeah. I think it would be a very interesting feature to hide end user balances in these hosted channels
1396
01:31:33.120 --> 01:31:34.100
using e cache.
1397
01:31:38.455 --> 01:31:40.395
You see that Eric is, like, assuming
1398
01:31:40.775 --> 01:31:41.995
there will not be
1399
01:31:42.614 --> 01:31:43.675
a true corporation
1400
01:31:43.975 --> 01:31:46.150
because it's possible for, like,
1401
01:31:46.469 --> 01:31:47.449
2 geniuses
1402
01:31:48.390 --> 01:31:49.530
programming together.
1403
01:31:50.710 --> 01:31:52.170
It's better if each one
1404
01:31:52.630 --> 01:31:53.850
does its own thing.
1405
01:31:54.345 --> 01:31:59.725
Well, I'm happy to be, you know, the monkey head in between if you guys need, some glue there.
1406
01:32:02.640 --> 01:32:07.140
Yeah. I definitely enjoyed the conversation with you, and it's, also much better to,
1407
01:32:07.760 --> 01:32:08.260
talk
1408
01:32:08.560 --> 01:32:11.605
voice to voice than on Twitter screaming at each other.
1409
01:32:12.645 --> 01:32:13.545
And in the end,
1410
01:32:14.325 --> 01:32:17.465
like, we agree on a lot of stuff. Just in the details,
1411
01:32:18.005 --> 01:32:18.745
we have
1412
01:32:19.510 --> 01:32:21.850
very strongly held opinions that differ.
1413
01:32:22.790 --> 01:32:24.410
I love the strongly held opinions.
1414
01:32:25.350 --> 01:32:29.954
We have we have 2 questions in the chat. The first question,
1415
01:32:32.574 --> 01:32:34.114
is asking about Blockstream's
1416
01:32:34.415 --> 01:32:35.315
peer swap
1417
01:32:35.650 --> 01:32:37.190
lightning balancing protocol.
1418
01:32:38.370 --> 01:32:39.670
I think this was released
1419
01:32:40.050 --> 01:32:41.110
8 days ago
1420
01:32:41.730 --> 01:32:43.030
at in El Salvador.
1421
01:32:43.375 --> 01:32:46.275
Are any of you guys familiar with this protocol at all?
1422
01:32:48.735 --> 01:32:50.114
We have 9 dogs.
1423
01:32:51.400 --> 01:32:51.900
Okay.
1424
01:32:52.440 --> 01:32:55.660
I I talked a bit, after we caught, with Constantine,
1425
01:32:56.600 --> 01:32:59.580
who seems to be the lead developer behind us.
1426
01:33:01.304 --> 01:33:06.364
And the question is if we can integrate it with Federated ECash somehow
1427
01:33:06.665 --> 01:33:07.625
or that you could,
1428
01:33:08.105 --> 01:33:10.445
swap balances in and out of ECash.
1429
01:33:11.930 --> 01:33:12.430
And
1430
01:33:12.970 --> 01:33:14.670
I think, technically, that's possible.
1431
01:33:15.610 --> 01:33:16.810
The question is,
1432
01:33:17.450 --> 01:33:18.110
like, since
1433
01:33:18.915 --> 01:33:21.735
e cache these e cache evaluations are meant to be,
1434
01:33:22.994 --> 01:33:31.170
that they're meant to be many of them with different, trust assumptions because there are different people involved. Like, can you actually find one with the
1435
01:33:31.650 --> 01:33:35.270
your peer you want to swap with, that you both agree on trusting?
1436
01:33:37.155 --> 01:33:37.795
Because otherwise,
1437
01:33:38.595 --> 01:33:39.895
if you can't, then
1438
01:33:40.355 --> 01:33:43.975
for inter federation payments, you need lightning anyway, and you would
1439
01:33:44.449 --> 01:33:50.230
unbalance lightning channel in that way. And that would kind of destroy the whole point behind PierceRock,
1440
01:33:50.610 --> 01:33:51.989
which is that you only
1441
01:33:52.965 --> 01:33:54.985
rebalanced channels with direct peers
1442
01:33:55.605 --> 01:34:00.344
or with, peers only one hop away in that sense that all involved parties
1443
01:34:01.409 --> 01:34:02.710
actually want to do this.
1444
01:34:03.650 --> 01:34:06.949
Like, you are not, unbalancing someone else's channel.
1445
01:34:08.745 --> 01:34:11.005
So I think it's an interesting idea, but,
1446
01:34:12.025 --> 01:34:14.685
complicated in in practice, I guess.
1447
01:34:17.750 --> 01:34:18.570
Fair enough.
1448
01:34:19.270 --> 01:34:21.530
I have not looked into it personally yet.
1449
01:34:24.325 --> 01:34:27.945
It would be nice if it is easier to balance channels and to,
1450
01:34:29.685 --> 01:34:32.265
have some kind of more distributed marketplace
1451
01:34:32.725 --> 01:34:33.225
than
1452
01:34:35.190 --> 01:34:36.730
Lightning Labs' pool.
1453
01:34:38.790 --> 01:34:42.570
Someone else asked a relatively similar similar question.
1454
01:34:43.195 --> 01:34:51.215
Do you think something like a lease pool that node operators participate in would be appropriate to cover the costs of opening individual private channels?
1455
01:34:51.915 --> 01:34:54.550
And I I'll just jump in here. I mean,
1456
01:34:55.250 --> 01:34:56.630
I know this is Breeze's,
1457
01:34:58.530 --> 01:35:02.070
Breeze has has has spoke about this. Breeze with 2 e's
1458
01:35:02.435 --> 01:35:03.095
and a
1459
01:35:03.515 --> 01:35:04.015
z.
1460
01:35:04.515 --> 01:35:07.095
I have fucking naming schemes of these Bitcoin wallets.
1461
01:35:08.115 --> 01:35:12.770
Breeze has talked about this. I mean, the biggest issue is, to me, is UX friction.
1462
01:35:13.390 --> 01:35:16.210
It's like, if a new user needs to pay somebody
1463
01:35:17.470 --> 01:35:19.970
on lightning to be able to receive on lightning,
1464
01:35:21.925 --> 01:35:25.545
it's not necessarily the easiest thing to do from a UX perspective.
1465
01:35:26.644 --> 01:35:27.545
It's not intuitive.
1466
01:35:28.790 --> 01:35:30.730
That seems to be the biggest
1467
01:35:31.110 --> 01:35:34.090
hurdle with this type of stuff. What what do you guys think?
1468
01:35:35.954 --> 01:35:37.255
No. I think it's true.
1469
01:35:38.275 --> 01:35:41.394
Yeah. Definitely. And it's even worse. Like, how big,
1470
01:35:41.875 --> 01:35:43.655
do you make this channel you open,
1471
01:35:44.150 --> 01:35:46.170
when you want to receive your first payment?
1472
01:35:46.710 --> 01:35:55.655
Like, if if it's too big, you pay way too much in fees. If it's too small, then at some later point, you will have to pay again. And how do you
1473
01:35:56.195 --> 01:35:57.815
teach a user that
1474
01:35:58.355 --> 01:35:59.575
at some sometimes,
1475
01:35:59.955 --> 01:36:01.810
randomly, basically for them,
1476
01:36:02.290 --> 01:36:05.510
they need to pay more in transaction fees. That's totally unintuitive.
1477
01:36:05.890 --> 01:36:06.950
Yeah. That's tough.
1478
01:36:07.970 --> 01:36:09.190
To convince someone.
1479
01:36:09.805 --> 01:36:12.285
Yeah. So that's another reason why I think these,
1480
01:36:13.005 --> 01:36:16.605
like, just one channel lightning notes, that's not the way to go. It's just,
1481
01:36:17.330 --> 01:36:23.990
you can't get your x right because either you're spending way too much money on opening humongous channels. Like,
1482
01:36:24.805 --> 01:36:28.505
poor Phoenix. I still have a channel open with them, I think,
1483
01:36:28.885 --> 01:36:30.985
10,000,000,000 sets or something like that on,
1484
01:36:31.420 --> 01:36:37.760
like, something ridiculous. Maybe only 7. But I I accidentally used it as a on chain wallet and didn't notice that they automatically
1485
01:36:38.139 --> 01:36:39.119
swap on lightning.
1486
01:36:39.445 --> 01:36:39.945
So
1487
01:36:41.365 --> 01:36:44.885
I'm I feel really sorry for that. Maybe I should just close it at some point.
1488
01:36:45.445 --> 01:36:48.105
But yeah. No. Keep it. I don't teach him a lesson.
1489
01:36:48.410 --> 01:36:49.870
Yeah. Either you do that
1490
01:36:50.330 --> 01:36:52.030
or you will have to repeatedly
1491
01:36:52.410 --> 01:36:53.290
open new channels,
1492
01:36:54.170 --> 01:37:07.765
swap in Bitcoin, which is on chain operation again and costs money. So it's not So I mean, right now, simple Bitcoin wallet, Anton's project, like, they they he gives you the ability to buy from Bitrefill or from Ellen Big,
1493
01:37:08.760 --> 01:37:11.580
which it would be a similar situation as
1494
01:37:12.040 --> 01:37:14.940
the this lease pool that he mentioned, except, obviously, that's
1495
01:37:15.375 --> 01:37:16.035
would be,
1496
01:37:17.215 --> 01:37:18.515
theoretically more distributed
1497
01:37:19.135 --> 01:37:24.195
than 2 centralized providers, but it provides the same UX hurdle. It's like, what the fuck am I doing?
1498
01:37:27.280 --> 01:37:34.465
Anton, you have any views there? I mean, obviously, you in integrated those that feature and that I can just press a button and buy a channel from Ellen
1499
01:37:34.765 --> 01:37:36.305
Big, whoever the fuck that is.
1500
01:37:38.285 --> 01:37:38.785
Well
1501
01:37:39.165 --> 01:37:40.865
well well, I agree. Again, this
1502
01:37:41.530 --> 01:37:47.630
this requires some level of understanding of what is going on. Yeah. And simple Bitcoin wallet is
1503
01:37:48.330 --> 01:37:48.830
actually
1504
01:37:49.265 --> 01:37:50.245
not that simple
1505
01:37:51.265 --> 01:37:52.885
after all. And
1506
01:37:55.745 --> 01:37:56.225
and,
1507
01:37:56.625 --> 01:37:58.245
it's aimed at somewhat
1508
01:37:58.740 --> 01:38:02.360
prepared users. I'd say Maybe it should be called, like, advanced Bitcoin wallet.
1509
01:38:03.140 --> 01:38:03.940
Well, it's
1510
01:38:04.420 --> 01:38:05.640
Intermediate Bitcoin.
1511
01:38:06.985 --> 01:38:08.925
First version was called them
1512
01:38:09.225 --> 01:38:13.085
that, and then I just decided to not change the name.
1513
01:38:13.510 --> 01:38:19.670
So, yeah, it anticipates that user more or less understands what's going on. The user
1514
01:38:20.950 --> 01:38:21.930
yeah. Yeah.
1515
01:38:22.245 --> 01:38:25.065
I mean so I was actually going to
1516
01:38:25.925 --> 01:38:28.985
I wanted to bring this up before we wrap this up.
1517
01:38:29.740 --> 01:38:35.440
It was like a while I had you kind of thing. As someone who,
1518
01:38:37.155 --> 01:38:40.935
you know, still dispatch, the audience here is more technical focused.
1519
01:38:41.715 --> 01:38:45.175
I think they have a pretty decent understanding of lightning,
1520
01:38:45.560 --> 01:38:48.300
how it works, you know, the basic trade offs.
1521
01:38:48.920 --> 01:38:50.380
That's why I do still dispatch.
1522
01:38:50.760 --> 01:38:52.540
My other show, rabbit hole recap,
1523
01:38:53.335 --> 01:38:54.235
is a more
1524
01:38:55.095 --> 01:38:56.235
accessible show,
1525
01:38:57.815 --> 01:39:01.195
and I do a lot of education just, like, to new users and whatnot.
1526
01:39:02.980 --> 01:39:04.760
And when I'm, like, recommending wallets,
1527
01:39:05.060 --> 01:39:10.360
and I already kind of alluded to it with moon with 2 u's, and breeze with 2 e's and a z,
1528
01:39:11.824 --> 01:39:15.525
Like, names are important, especially when it comes across on audio.
1529
01:39:16.225 --> 01:39:18.225
And, like, simple Bitcoin wallet is just
1530
01:39:19.050 --> 01:39:21.390
like, I respect what you're doing. The wallet seems
1531
01:39:22.250 --> 01:39:25.070
pretty awesome, to be honest, and it's very snappy.
1532
01:39:26.865 --> 01:39:31.685
But, like, Simple Bitcoin Wallet as a name is a horrible name. It's an absolute horrible name.
1533
01:39:32.065 --> 01:39:37.190
Like, what the go download Simple Bitcoin Wallet. Yeah. Which one? No. Simple Bitcoin Wallet. You
1534
01:39:37.650 --> 01:39:40.390
know, it just doesn't w's in 3 words.
1535
01:39:41.170 --> 01:39:42.550
Yeah. But I do.
1536
01:39:44.235 --> 01:39:48.175
There's worse names. I'll give you that. It's better than Moon and Breeze. But,
1537
01:39:50.955 --> 01:39:55.650
yeah, I just I don't know if it's a good name for a wallet. It's it's kind of
1538
01:39:56.430 --> 01:39:58.850
counterintuitive when you say simple Bitcoin wallet.
1539
01:40:01.765 --> 01:40:14.010
Also, when it comes to confusing users, there was a really interesting question to chat, if simple Bitcoin wallet is the same as Bitcoin lightning wallet because that's what I asked asked myself too when I first start.
1540
01:40:14.630 --> 01:40:28.015
Maybe you can explain the evolution because they're probably related somehow because you both worked on them. Yeah. You worked on both. Well, they are only related in a sense that I developed them, both of them. But, otherwise, they are different to worlds.
1541
01:40:28.395 --> 01:40:28.895
That's
1542
01:40:30.060 --> 01:40:34.880
not any kind of, like, inheritance from one to another. Just different apps.
1543
01:40:38.355 --> 01:40:43.895
You I think you must clarify that. Simple Bitcoin wallet was a wallet from 2014
1544
01:40:44.435 --> 01:40:45.175
or something.
1545
01:40:45.600 --> 01:40:46.100
2016.
1546
01:40:47.040 --> 01:40:48.980
Yeah. It was just a very,
1547
01:40:49.520 --> 01:40:52.740
actually, very simple Bitcoin wallet, Bitcoin only.
1548
01:40:53.915 --> 01:40:55.055
My And it had,
1549
01:40:55.435 --> 01:40:57.055
like, a 100 k users,
1550
01:40:57.515 --> 01:41:00.575
something like that? Yeah. It still has. It's pretty popular.
1551
01:41:01.035 --> 01:41:01.535
And,
1552
01:41:02.260 --> 01:41:02.760
yeah,
1553
01:41:03.219 --> 01:41:07.159
at some point, I decided to upgrade it to lightning also.
1554
01:41:07.460 --> 01:41:11.355
So that's the story. Instead of continuing development of,
1555
01:41:11.835 --> 01:41:13.614
Bitcoin lightning wallet because
1556
01:41:14.074 --> 01:41:17.534
that turned out to be a dead end and not easily upgradeable
1557
01:41:17.835 --> 01:41:21.800
to private routing and other stuff that they wanted to go with.
1558
01:41:23.140 --> 01:41:25.240
So I decided to continue on that
1559
01:41:25.555 --> 01:41:27.094
in simple Bitcoin world.
1560
01:41:27.555 --> 01:41:31.495
I mean, Bitcoin Lightning Wallet was also a horrible name, for what it's worth.
1561
01:41:32.355 --> 01:41:34.535
And this is all love. I mean, so
1562
01:41:35.390 --> 01:41:40.930
just, some just my 2 stats, you know, take it or leave it. I appreciate you regardless.
1563
01:41:42.110 --> 01:41:44.770
You know, Jupiter has, like, 20 something moons,
1564
01:41:45.375 --> 01:41:47.075
and, like, Bitcoiners like moons.
1565
01:41:47.535 --> 01:41:49.875
So, like, you could pick 1 of the Jupiter moons,
1566
01:41:50.495 --> 01:41:53.395
could be a good name. You know, like Europa, Callisto,
1567
01:41:54.175 --> 01:41:54.675
Thebe.
1568
01:41:55.360 --> 01:41:57.300
Those are good names for for wallets.
1569
01:41:57.920 --> 01:42:01.620
That's a nice proposition. Thank you. I'll think about it.
1570
01:42:02.855 --> 01:42:06.715
Yeah. Do you see someone in the comments? It's simple Bitcoin wallet with Wise.
1571
01:42:07.015 --> 01:42:08.075
Yeah. Don't do that.
1572
01:42:10.060 --> 01:42:12.159
But, yeah, I do appreciate you guys.
1573
01:42:13.500 --> 01:42:18.159
Last thing before we wrap up, I mean, I Fiat, Jeff, you sent out a tweet,
1574
01:42:19.295 --> 01:42:20.915
Something about implementing,
1575
01:42:22.175 --> 01:42:25.315
lightning in your app is a pain in the fucking ass.
1576
01:42:26.989 --> 01:42:28.929
You wanna talk about that at all? Or
1577
01:42:29.710 --> 01:42:32.929
I don't know. I think I'm just very unlucky because
1578
01:42:33.364 --> 01:42:39.705
all the nodes fail with me. Right now, I have a a bug on the clear that doesn't route payments bigger than,
1579
01:42:40.565 --> 01:42:41.065
8,000
1580
01:42:41.445 --> 01:42:42.940
sets. Like, if
1581
01:42:43.400 --> 01:42:46.700
it it has the channels, but it doesn't find any routes. And,
1582
01:42:47.240 --> 01:42:49.820
yeah, it's being being being debugged by
1583
01:42:50.145 --> 01:42:52.804
Eclair people and also Intel helping.
1584
01:42:53.344 --> 01:43:00.350
But, yeah, I have I have so many bad experiences with c lightning before, and many of the bugs that resulted in exploited
1585
01:43:01.050 --> 01:43:02.670
bugs exploited money,
1586
01:43:03.050 --> 01:43:03.550
whatever,
1587
01:43:04.090 --> 01:43:08.190
was, like, because the APIs were not clear, and they they didn't
1588
01:43:08.785 --> 01:43:15.525
do what I expected them to do. And, anyway, many, many bugs. And, also, I know that that all the other custodial services
1589
01:43:15.905 --> 01:43:17.685
had similar bugs,
1590
01:43:18.370 --> 01:43:20.310
But that's where I was coming from.
1591
01:43:20.930 --> 01:43:25.250
I I wanted to ask one thing to to Eric, like, if he saw the
1592
01:43:25.965 --> 01:43:30.705
because I just saw a picture of that. I I stand on the the conference on El Salvador
1593
01:43:31.325 --> 01:43:31.825
with,
1594
01:43:33.005 --> 01:43:35.185
simple Bitcoin wallet stuff and
1595
01:43:35.870 --> 01:43:37.170
stuff being given out.
1596
01:43:37.870 --> 01:43:40.530
It was very funny. Yeah. It was the the best,
1597
01:43:41.390 --> 01:43:42.750
proof of, the best,
1598
01:43:43.310 --> 01:43:44.850
like, ads ever. Like,
1599
01:43:45.355 --> 01:43:47.295
I had to take a picture of that.
1600
01:43:49.515 --> 01:43:50.815
It felt so nineties.
1601
01:43:55.200 --> 01:43:59.060
Yeah. Maybe if people don't know what we are referring to. Like, there was
1602
01:44:00.480 --> 01:44:02.740
a big poster with a beautiful lady,
1603
01:44:03.775 --> 01:44:05.555
advertising Simple Bitcoin Wallet.
1604
01:44:06.335 --> 01:44:11.715
Oh, no. Was isn't it Alan Big, or was it Simple Bitcoin Wallet? I think it was Simple Bitcoin Wallet.
1605
01:44:12.430 --> 01:44:18.450
Was it? It's handled by a big guy. Yes. And he was promoting both himself and my wallet. Oh,
1606
01:44:20.764 --> 01:44:21.425
yeah. Because
1607
01:44:22.125 --> 01:44:29.665
the lady was on the on the Yeah. Most of the lady told you. We had a designer who was making his stuff, and
1608
01:44:31.070 --> 01:44:37.090
and he was like we also asked him whether he's this lady is appropriate or not. He said that it increases
1609
01:44:37.550 --> 01:44:38.850
engagement guaranteed.
1610
01:44:39.885 --> 01:44:42.705
So it must be there if you want, like, more attention.
1611
01:44:44.364 --> 01:44:47.665
I didn't know if it was, like, a parody or not. So it definitely,
NOTE
Transcription provided by Podhome.fm
Created: 3/21/2024 8:14:58 PM
Duration: 6974.981
Channels: 1
1
00:00:00.240 --> 00:00:06.100
2
00:00:07.285 --> 00:00:08.725
Because what looks like,
3
00:00:09.125 --> 00:00:10.505
a very interesting
4
00:00:10.805 --> 00:00:12.505
and and somewhat exotic,
5
00:00:13.205 --> 00:00:13.764
effort to,
6
00:00:14.980 --> 00:00:16.119
literally mine,
7
00:00:16.900 --> 00:00:19.800
new coins in order to trade with them
8
00:00:20.180 --> 00:00:22.520
has the potential for undermining,
9
00:00:23.220 --> 00:00:23.720
currencies,
10
00:00:24.365 --> 00:00:25.025
for undermining
11
00:00:25.405 --> 00:00:25.905
the,
12
00:00:26.845 --> 00:00:29.744
role of the dollar as the reserve currency
13
00:00:30.125 --> 00:00:30.945
for destabilizing
14
00:00:31.805 --> 00:00:35.590
nations, perhaps starting with small ones but going much larger.
15
00:00:36.050 --> 00:00:42.310
So when we think about this new environment in which we find ourselves that we've been discussing for the last
16
00:00:42.835 --> 00:00:43.735
some minutes,
17
00:00:44.595 --> 00:00:46.775
we can't just think about nation states.
18
00:01:23.785 --> 00:01:29.200
19
00:01:29.680 --> 00:01:35.060
Dispatch. The interactive live show about Bitcoin distributed systems privacy and open source software.
20
00:01:35.680 --> 00:01:39.634
That clip out you just heard was from failed presidential candidate Hillary Clinton
21
00:01:40.415 --> 00:01:40.915
explaining
22
00:01:41.295 --> 00:01:43.795
the absolute power and significance of Bitcoin
23
00:01:44.095 --> 00:01:45.795
to the new economy forum.
24
00:01:47.270 --> 00:01:53.610
Huge shout out to the ride or die freaks who are joining us in the live chat. I know it's an earlier time than usual,
25
00:01:53.955 --> 00:01:54.775
but I got
26
00:01:55.235 --> 00:02:00.890
a straight fire group of guests to join us today, and we had to make this time work.
27
00:02:01.930 --> 00:02:07.310
Happy Thanksgiving to all the American freaks out there. I know it's a big family week,
28
00:02:07.850 --> 00:02:10.965
for most of us, so make sure you treat your families
29
00:02:11.345 --> 00:02:15.765
with at least some monochrome of respect when you're talking about Bitcoin.
30
00:02:17.560 --> 00:02:26.005
Huge shout out to all the ride or die freaks who continue to support the show and keep it ad free, sponsor free, and purely focused on actionable Bitcoin discussion.
31
00:02:26.465 --> 00:02:30.085
The easiest way to support the show is through podcasting 2.0 apps.
32
00:02:31.080 --> 00:02:33.660
My two favorites are Fountain Podcasts
33
00:02:33.960 --> 00:02:37.980
and Breeze Wallet. Breeze, that's b r e e z.
34
00:02:39.185 --> 00:02:47.765
If you just download one of those apps, you can load it up with Sats, search Citadel dispatch, and you can send Sats directly to my node
35
00:02:48.470 --> 00:02:50.569
as you listen to the show.
36
00:02:51.110 --> 00:02:53.690
You can also support dispatch at cildispatch.com,
37
00:02:54.549 --> 00:02:56.409
either through lightning or through Paynim.
38
00:02:57.075 --> 00:03:00.695
My samurai Paynim is Odell. It is very easy to remember.
39
00:03:01.475 --> 00:03:13.549
So thank you again for supporting the show, and thank you to the ride or dies who continue to join us in the live chat, which, a reminder, I had some people ask me, you can access through Twitter, Twitch, or YouTube, whichever platform you prefer.
40
00:03:14.329 --> 00:03:15.470
With all that said,
41
00:03:15.775 --> 00:03:18.035
we have Citadel dispatch 45
42
00:03:18.335 --> 00:03:18.835
today.
43
00:03:19.855 --> 00:03:24.090
The focus is gonna be on the future of mobile lightning wallets. I expect,
44
00:03:24.550 --> 00:03:25.770
and I think
45
00:03:26.310 --> 00:03:28.170
many Bitcoiners would agree with me,
46
00:03:28.630 --> 00:03:33.795
that the overwhelming majority of new Bitcoiners will come in through phone wallets.
47
00:03:34.575 --> 00:03:35.075
And
48
00:03:35.455 --> 00:03:41.395
on that note, many of them will come in through lightning. So mobile lightning wallets are an extremely important topic
49
00:03:41.730 --> 00:03:44.070
and how we develop them, how we improve them,
50
00:03:44.530 --> 00:03:49.510
how we see them going forward is going to be a very important topic.
51
00:03:50.864 --> 00:03:54.405
I am very excited to have repeat guest, Fiat Jaffe here, prolific
52
00:03:55.344 --> 00:03:56.325
lightning developer
53
00:03:56.704 --> 00:03:58.084
with very strong opinionated,
54
00:03:59.560 --> 00:04:02.460
very strong opinion. How's it going, Fiat, Jeff?
55
00:04:03.320 --> 00:04:04.300
56
00:04:04.920 --> 00:04:05.660
Not many
57
00:04:06.200 --> 00:04:07.180
prolific contributions
58
00:04:07.560 --> 00:04:09.795
lately, but still strong opinions.
59
00:04:10.655 --> 00:04:13.475
60
00:04:14.815 --> 00:04:16.355
We have Anton here,
61
00:04:17.380 --> 00:04:23.880
lead maintainer of Simple Bitcoin Wallet, a mobile on chain and lightning wallet. How's it going, Anton?
62
00:04:25.380 --> 00:04:26.680
63
00:04:27.444 --> 00:04:33.625
64
00:04:34.485 --> 00:04:34.985
Chaumian
65
00:04:35.810 --> 00:04:36.710
Lightning Wallets,
66
00:04:37.570 --> 00:04:39.990
that aim to bring more privacy,
67
00:04:41.170 --> 00:04:44.950
and easier UX to mobile lightning wallets. How's it going, Eric?
68
00:04:46.245 --> 00:04:51.625
69
00:04:52.165 --> 00:04:53.945
in the real world first time.
70
00:04:54.910 --> 00:04:56.850
71
00:04:58.950 --> 00:05:01.730
Are Anton or Fiat, Jeff, are either of you in El Salvador?
72
00:05:03.745 --> 00:05:05.284
73
00:05:05.905 --> 00:05:06.645
No. No.
74
00:05:07.504 --> 00:05:09.365
75
00:05:12.750 --> 00:05:13.250
76
00:05:13.710 --> 00:05:15.810
the few shops that supported lightning,
77
00:05:16.510 --> 00:05:21.055
like, not everyone did, but the ones that did and were using,
78
00:05:22.955 --> 00:05:23.455
like,
79
00:05:24.474 --> 00:05:25.134
a community
80
00:05:25.435 --> 00:05:26.150
built wallets,
81
00:05:26.710 --> 00:05:28.169
like, Bitcoin Beach Wallet,
82
00:05:28.630 --> 00:05:29.770
all these good things.
83
00:05:31.350 --> 00:05:36.595
They still had some problems with you. Like, people were entering their own amounts they want to pay,
84
00:05:36.975 --> 00:05:37.475
and,
85
00:05:37.935 --> 00:05:46.570
like, it wasn't as smooth as it could be. So I think that we can do a lot better, and I'm looking forward to contribute to that.
86
00:05:47.990 --> 00:05:51.770
87
00:05:53.515 --> 00:05:56.335
mixed experiences on the ground, particularly with
88
00:05:56.875 --> 00:05:59.615
the the Chivo wallet, the government wallet,
89
00:06:00.580 --> 00:06:05.639
which I I guess a lot of merchants use because they wanna they wanna instantly convert to US dollars.
90
00:06:09.224 --> 00:06:12.284
91
00:06:13.705 --> 00:06:15.645
Jiro just, didn't work. Like,
92
00:06:16.090 --> 00:06:18.030
the people that figured out how to,
93
00:06:20.090 --> 00:06:21.950
generate lightning invoice on Jibo.
94
00:06:22.570 --> 00:06:25.710
Then they had to fight for huge delays before the
95
00:06:27.365 --> 00:06:29.465
sections was with the air. Like,
96
00:06:30.005 --> 00:06:33.705
that's definitely not a good part of, experiencing lightning in El Salvador.
97
00:06:34.660 --> 00:06:39.960
But Bitcoin Beach, was doing much better. So if you want to visit there, that's the place to go.
98
00:06:40.660 --> 00:06:44.365
99
00:06:46.105 --> 00:06:50.765
helping merchants and helping users for at least a couple years now,
100
00:06:52.220 --> 00:06:53.600
if not longer. So,
101
00:06:54.220 --> 00:06:56.720
they did did kinda have a head start in El Salvador.
102
00:06:57.660 --> 00:06:59.280
I mean, I thought it was an interesting
103
00:06:59.765 --> 00:07:04.265
interesting spot spot to start because, I mean, El Salvador is a whole country that got
104
00:07:04.725 --> 00:07:05.865
thrown into lightning,
105
00:07:06.885 --> 00:07:07.865
by their president,
106
00:07:10.569 --> 00:07:14.509
and most of them aren't going to use computers. They're gonna be using mobile wallets,
107
00:07:14.889 --> 00:07:18.110
and most of them aren't gonna be using on chain. They're gonna be using lightning.
108
00:07:19.425 --> 00:07:22.565
So I feel like it kind of was a big kick in the ass to the community,
109
00:07:23.985 --> 00:07:24.485
to
110
00:07:25.025 --> 00:07:25.845
really prioritize
111
00:07:26.145 --> 00:07:28.620
better UX and more user friendly,
112
00:07:30.360 --> 00:07:31.660
mobile lightning wallets,
113
00:07:32.840 --> 00:07:36.195
sooner rather than later. Did you also get that that,
114
00:07:36.895 --> 00:07:38.035
that vibe, Eric?
115
00:07:39.215 --> 00:07:50.330
116
00:07:51.245 --> 00:07:54.944
custodial or semi custodial solutions like, Bitcoin Beach Wallet.
117
00:07:55.365 --> 00:07:55.865
So
118
00:07:56.525 --> 00:08:02.160
and that's exactly what I was thinking when I was developing my ecash idea. And I think,
119
00:08:02.940 --> 00:08:03.760
that's where
120
00:08:05.740 --> 00:08:09.815
and Santon agree with me. And we have many other points we disagree
121
00:08:10.195 --> 00:08:12.615
on, but that's the one thing we might agree on.
122
00:08:13.075 --> 00:08:13.575
123
00:08:13.955 --> 00:08:16.295
I'm I'm very excited to get to the disagreement.
124
00:08:16.845 --> 00:08:17.345
Lightning.
125
00:08:19.220 --> 00:08:23.160
I'm very excited to get to the disagreement. But before we before we get there,
126
00:08:23.540 --> 00:08:24.360
I was thinking,
127
00:08:26.475 --> 00:08:27.854
let's start with
128
00:08:29.435 --> 00:08:31.455
let's start with Anton about
129
00:08:31.995 --> 00:08:36.139
a simple Bitcoin wallet. It's a it's a great wallet right now that exists.
130
00:08:36.839 --> 00:08:40.139
It's available on app stores. You can download the APK directly.
131
00:08:40.825 --> 00:08:41.565
Then let's
132
00:08:41.865 --> 00:08:47.565
the basic structure of the conversation today. Then let's then let's move to your Chaumu Unique cash proposal,
133
00:08:49.480 --> 00:08:55.180
Federated Chow Meany cash proposal, and how you expect how you see it working out in practice,
134
00:08:56.324 --> 00:09:01.225
and then let's dive into open discussion on trade offs and critiques and thoughts.
135
00:09:03.769 --> 00:09:08.510
So, Anton, you wanna start us off? Simple Bitcoin wallet. Why should I use it? What's you know,
136
00:09:09.130 --> 00:09:10.589
why should the freaks care?
137
00:09:12.385 --> 00:09:13.285
138
00:09:13.585 --> 00:09:20.245
I'd say that the grand goal here in developing this thing is to make lightning bolt which
139
00:09:20.690 --> 00:09:21.510
actually works.
140
00:09:22.370 --> 00:09:22.770
And,
141
00:09:23.410 --> 00:09:24.550
by this, I mean,
142
00:09:25.010 --> 00:09:29.910
the wallet where you can send an arbitrary lightning payment and most of the time,
143
00:09:31.305 --> 00:09:32.125
it succeeds.
144
00:09:33.865 --> 00:09:34.925
And I guess
145
00:09:37.145 --> 00:09:38.390
most Lightning users
146
00:09:38.790 --> 00:09:45.130
will agree with me as is currently this is not the case. A lot of payments fail all the time.
147
00:09:45.645 --> 00:09:48.225
And, in my opinion, which is
148
00:09:48.765 --> 00:09:50.385
somewhat based on experience,
149
00:09:51.885 --> 00:09:55.850
this is due to liquidity issues which are present on lightning.
150
00:09:56.390 --> 00:09:56.630
And,
151
00:09:58.150 --> 00:10:05.295
what I mean by liquidity here is channel balances of working capital, which is required to
152
00:10:05.995 --> 00:10:08.335
get your payment through in certain direction.
153
00:10:08.875 --> 00:10:10.815
And this is an issue because
154
00:10:12.130 --> 00:10:13.350
in lightening this,
155
00:10:14.850 --> 00:10:20.070
liquidity, it's not present as some global pool which you can use,
156
00:10:20.545 --> 00:10:21.365
But it's,
157
00:10:22.225 --> 00:10:25.285
like scattered across all these channels, and
158
00:10:25.745 --> 00:10:29.445
levels of liquidity are very different in different directions.
159
00:10:31.500 --> 00:10:32.480
So as a result,
160
00:10:33.180 --> 00:10:35.280
even if we put all the bugs
161
00:10:35.980 --> 00:10:36.720
and inefficiencies
162
00:10:37.180 --> 00:10:37.680
away,
163
00:10:38.115 --> 00:10:40.195
This issue is still present, and,
164
00:10:41.075 --> 00:10:43.895
a lot of payments still fail because of it.
165
00:10:44.435 --> 00:10:44.935
So
166
00:10:46.690 --> 00:10:47.350
my opinion is
167
00:10:49.330 --> 00:10:50.950
if we can develop
168
00:10:51.330 --> 00:10:55.265
any technologies which can help with this, then we should.
169
00:10:55.825 --> 00:10:57.845
And, that's what I've been doing
170
00:10:58.385 --> 00:11:01.445
for the past few months with my library in the world.
171
00:11:01.905 --> 00:11:02.405
And
172
00:11:03.550 --> 00:11:05.890
concrete things I've been working on,
173
00:11:06.990 --> 00:11:09.790
there are 2 things. They're called 1 called
174
00:11:10.365 --> 00:11:14.545
one is called hosted channels, and another one is private routing.
175
00:11:16.045 --> 00:11:19.345
The end goal of both is increasing liquidity levels,
176
00:11:19.970 --> 00:11:20.470
And,
177
00:11:21.330 --> 00:11:29.925
they are both supported by Simple Bitcoin wallet hosted channels, revised version of them. Actually works for about a month now, and,
178
00:11:31.505 --> 00:11:34.165
private routing is coming this year.
179
00:11:34.779 --> 00:11:39.199
So, hopefully, that will help and provide for the best experience possible.
180
00:11:39.899 --> 00:11:43.279
181
00:11:43.740 --> 00:11:44.240
a
182
00:11:45.005 --> 00:11:46.945
a mobile focused lightning
183
00:11:47.565 --> 00:11:53.585
implementation in the back end called Immortan. Is are you the lead maintainer of that as well? Yes. That's true.
184
00:11:54.250 --> 00:11:54.750
So
185
00:11:56.010 --> 00:11:58.350
I feel like that's a good place to start. So Immordin,
186
00:12:00.250 --> 00:12:01.390
is mobile focused.
187
00:12:02.345 --> 00:12:07.725
What makes it mobile focused? Like, what is the what is the strategy there when you're developing Amorton?
188
00:12:09.145 --> 00:12:11.725
189
00:12:12.320 --> 00:12:14.740
So and private and mobile are kinda
190
00:12:16.000 --> 00:12:18.180
synonyms, so so there.
191
00:12:18.640 --> 00:12:18.960
And,
192
00:12:19.520 --> 00:12:22.564
when we have private channels, we can have some
193
00:12:23.345 --> 00:12:30.245
pretty unique privacy properties, like a node which can only have private channels, may not have a stable node ID,
194
00:12:30.870 --> 00:12:31.270
and,
195
00:12:31.750 --> 00:12:36.170
that increases privacy because the that node ID is not shown in invoices.
196
00:12:36.790 --> 00:12:41.175
Every node I connect to can see my wallet that it's some kind of different
197
00:12:41.795 --> 00:12:43.975
remote node and, so on.
198
00:12:44.915 --> 00:12:45.895
So and
199
00:12:47.199 --> 00:12:53.300
200
00:12:54.639 --> 00:12:56.420
201
00:12:56.865 --> 00:12:57.365
is,
202
00:12:58.945 --> 00:13:05.204
again, liquidity via private routing. So if we have these private channels, we can make them route payments
203
00:13:05.505 --> 00:13:06.165
as well.
204
00:13:08.050 --> 00:13:13.830
And that's what it's about, really, plus costed channels, of course. So when I download Simple Bitcoin Wallet,
205
00:13:14.945 --> 00:13:19.345
206
00:13:19.825 --> 00:13:20.725
Yes. Open
207
00:13:21.425 --> 00:13:23.365
for 1,000,000 sats to receive
208
00:13:23.850 --> 00:13:30.910
so they can instantly receive funds, which is a common complaint with lightning is that it takes work to be able to receive funds because you don't have inbound liquidity.
209
00:13:31.305 --> 00:13:33.645
210
00:13:34.025 --> 00:13:34.525
211
00:13:35.145 --> 00:13:36.045
so what's
212
00:13:36.665 --> 00:13:40.445
what's the high level explanation of hosted channels and their trade offs?
213
00:13:41.670 --> 00:13:42.310
214
00:13:44.790 --> 00:13:48.890
hosted channel is a way to add some trust between
215
00:13:49.270 --> 00:13:49.770
peers
216
00:13:50.305 --> 00:13:51.685
on the protocol level,
217
00:13:52.465 --> 00:13:57.605
and, I'd say let the rest of the network leverage the trust. And,
218
00:13:58.450 --> 00:14:05.190
technically, it's a new kind of channel, a hosted channel which does not have chain backing in principle.
219
00:14:06.105 --> 00:14:08.205
So this is where trust comes from.
220
00:14:08.985 --> 00:14:10.765
And, it gets implanted
221
00:14:11.225 --> 00:14:12.925
into lightning node and
222
00:14:14.370 --> 00:14:15.910
to the rest of the subsystems
223
00:14:16.290 --> 00:14:23.345
in that node. It looks just like another channel. So it can participate in lightning stuff like
224
00:14:23.904 --> 00:14:27.045
multipart payments and routing and so on.
225
00:14:27.665 --> 00:14:27.985
And,
226
00:14:28.785 --> 00:14:33.370
227
00:14:34.170 --> 00:14:35.069
228
00:14:37.290 --> 00:14:42.089
229
00:14:42.834 --> 00:14:45.735
230
00:14:46.194 --> 00:14:47.894
231
00:14:49.235 --> 00:14:54.170
I'm trusting the provider of the hosted channel for that hosted channel. Yes. You do.
232
00:14:54.790 --> 00:15:02.415
And I get the benefit of what's my benefit out of that? My benefit is, I guess, lower lower fees. I don't have to worry about an on chain transaction.
233
00:15:03.915 --> 00:15:06.495
234
00:15:06.795 --> 00:15:09.935
and, all the lightning stuff like privacy
235
00:15:10.475 --> 00:15:10.870
because
236
00:15:11.990 --> 00:15:17.370
routing graph is still on your device, so you can construct routes locally, and
237
00:15:18.045 --> 00:15:23.425
host the channel provider has no idea whom you're paying to. This is one of the differences between
238
00:15:23.885 --> 00:15:24.385
other
239
00:15:25.005 --> 00:15:36.140
240
00:15:36.645 --> 00:15:38.105
241
00:15:39.365 --> 00:15:42.825
Wallet of Satoshi. You you tell them, oh, pay this,
242
00:15:43.845 --> 00:15:46.630
porn website for me, and then they will
243
00:15:47.090 --> 00:15:59.985
know. But with the hosted channel, you just view the route on your phone, and the payment goes, and they don't know where it's going. You can also, like, split the pay do a multipart payment. Yeah. Basically, they they won't they even know that the amount.
244
00:16:00.765 --> 00:16:02.305
245
00:16:03.140 --> 00:16:13.605
chain backed lightning channels as closely as possible. So, basically, the only thing because the channel misses is chain part. When it comes to lightning, it can be treated like,
246
00:16:14.305 --> 00:16:16.645
a normal lightning channel. So we have
247
00:16:17.105 --> 00:16:17.605
all,
248
00:16:18.385 --> 00:16:20.300
lightning features like privacy,
249
00:16:20.600 --> 00:16:21.500
then the ability
250
00:16:22.280 --> 00:16:31.815
I mean, then the ability of enriching payments. So we can say that we can always say that the payment that we sent or received was never our payment, and we have nothing
251
00:16:32.675 --> 00:16:36.695
know nothing about it, and it just was a root payment, stuff like that.
252
00:16:38.110 --> 00:16:46.450
253
00:16:47.825 --> 00:16:57.970
host to channel provider and you're not bound to trust the one app provider like Wallet of Satoshi just because they happen to build the app. But you can choose a friend of yours, for example,
254
00:16:58.510 --> 00:17:01.570
and choose any other host channel capable app.
255
00:17:02.110 --> 00:17:12.835
256
00:17:13.375 --> 00:17:13.875
and
257
00:17:14.269 --> 00:17:15.090
that's cool.
258
00:17:15.549 --> 00:17:17.090
And, of course, you can have,
259
00:17:19.230 --> 00:17:20.529
you can have many,
260
00:17:21.149 --> 00:17:23.815
hosted channel providers in single wallet.
261
00:17:25.335 --> 00:17:26.394
So you can have,
262
00:17:27.414 --> 00:17:36.380
say, 2 or 3 hosted channels which lead to different providers, and you can use all them all all them at once for multipart payments,
263
00:17:36.920 --> 00:17:37.900
which is also
264
00:17:38.440 --> 00:17:39.820
an interest in property,
265
00:17:40.360 --> 00:17:41.180
I'd say.
266
00:17:41.644 --> 00:17:42.125
And,
267
00:17:43.085 --> 00:17:44.664
268
00:17:45.085 --> 00:17:48.304
on Symbol Bitcoin Wallet, I automatically have a open
269
00:17:49.000 --> 00:17:50.780
hosted channel to me,
270
00:17:51.160 --> 00:17:53.100
when I when I start the wallet.
271
00:17:53.400 --> 00:17:56.120
So I have inbound liquidity. If I open a channel
272
00:17:56.635 --> 00:18:00.095
if I load it up with on chain funds and I open a channel
273
00:18:00.635 --> 00:18:06.850
Mhmm. Where I can choose any node, right now that's Clearnet, or if I use Orbot, I can choose one that's Tor.
274
00:18:07.710 --> 00:18:08.530
Does it
275
00:18:09.550 --> 00:18:13.934
is that a normal channel, or is that a hosted channel? That's a normal channel. Right?
276
00:18:15.115 --> 00:18:16.075
277
00:18:16.475 --> 00:18:20.315
hosted channel is denoted as such. There's clear note,
278
00:18:20.955 --> 00:18:25.030
clear text, posted channel, and custodial solution below it.
279
00:18:26.690 --> 00:18:32.235
And normal channel does not have it, so that's how you can discern that. And, yes, of course, if you
280
00:18:32.855 --> 00:18:39.595
open channel to someone by by funding it from your chain wallets, that would be a chain backed channel,
281
00:18:40.360 --> 00:18:41.260
not a hosted
282
00:18:42.520 --> 00:18:43.020
one.
283
00:18:44.280 --> 00:18:44.780
284
00:18:45.320 --> 00:18:51.205
285
00:18:51.585 --> 00:18:53.445
So anyone could, in theory,
286
00:18:53.985 --> 00:18:56.725
have a hosted channel from the LNTP bot node
287
00:18:57.200 --> 00:18:58.900
through their simple Bitcoin wallet.
288
00:18:59.600 --> 00:19:01.460
Yeah. But it works. It works.
289
00:19:02.640 --> 00:19:07.405
290
00:19:07.865 --> 00:19:11.565
is so far we have been discussing private hosted channels.
291
00:19:12.505 --> 00:19:12.825
And,
292
00:19:13.545 --> 00:19:15.805
just like normal public channels,
293
00:19:17.290 --> 00:19:23.390
2 peers may establish a hosted channel between them and declare it public to the rest of the network.
294
00:19:24.090 --> 00:19:24.590
And
295
00:19:25.755 --> 00:19:27.455
everyone else on the network
296
00:19:27.755 --> 00:19:30.895
can use the channel to route their own payments,
297
00:19:31.195 --> 00:19:34.255
and they can do it without any trust assumptions
298
00:19:34.555 --> 00:19:36.700
or trust assumptions added.
299
00:19:37.240 --> 00:19:39.580
Or in other words, if you are
300
00:19:39.960 --> 00:19:43.340
a sender of payment, and even if you don't like this
301
00:19:43.715 --> 00:19:50.775
hosted channels idea at all, all your channel local channels are backed on chains. Basically, you are using
302
00:19:51.200 --> 00:19:52.820
classic lightning, let's say.
303
00:19:53.280 --> 00:19:58.260
If you see that some hosted channel exists somewhere deep in the network,
304
00:19:59.280 --> 00:19:59.680
there's
305
00:20:00.175 --> 00:20:01.155
it can totally
306
00:20:01.455 --> 00:20:05.235
it is totally safe to use it for your own payments because
307
00:20:06.495 --> 00:20:07.400
whatever is
308
00:20:07.800 --> 00:20:09.980
whatever happens in that hosted channel,
309
00:20:10.840 --> 00:20:16.455
deep on the network, you can always either get your payment delivered to recipient, or you can
310
00:20:17.095 --> 00:20:20.075
get it back on chain from your local channel.
311
00:20:20.455 --> 00:20:20.955
So
312
00:20:21.495 --> 00:20:22.394
even if you
313
00:20:22.855 --> 00:20:30.770
don't like this idea, don't participate in it in in any way, you can you still only have upside from this, no downside.
314
00:20:31.665 --> 00:20:32.165
And,
315
00:20:32.705 --> 00:20:33.845
linking this to
316
00:20:35.505 --> 00:20:40.565
my liquidity talk at start, this thing, this hosted channels, once they become
317
00:20:41.100 --> 00:20:43.200
public, they increase total liquidity
318
00:20:43.500 --> 00:20:44.620
on the network, and,
319
00:20:45.100 --> 00:20:47.280
that leads to more successful payments,
320
00:20:48.700 --> 00:20:49.200
and,
321
00:20:50.645 --> 00:20:52.025
well, more user satisfaction.
322
00:20:52.565 --> 00:20:56.185
For example, it's a working scene already. There are
323
00:20:56.645 --> 00:20:57.545
3 nodes
324
00:20:59.340 --> 00:21:01.679
and 2 hosted channels between them.
325
00:21:02.059 --> 00:21:02.299
And,
326
00:21:02.940 --> 00:21:06.559
this has been working for about 3 weeks now, and we have
327
00:21:06.925 --> 00:21:09.505
a few hundred route payments through them.
328
00:21:11.245 --> 00:21:13.345
329
00:21:13.965 --> 00:21:14.465
that
330
00:21:14.970 --> 00:21:17.550
the l n transaction bot node accepts,
331
00:21:18.490 --> 00:21:20.990
basically, like, inbound hosted channel requests.
332
00:21:21.850 --> 00:21:22.350
333
00:21:22.955 --> 00:21:29.695
334
00:21:31.399 --> 00:21:33.100
a hosted channel with him
335
00:21:33.559 --> 00:21:39.655
Mhmm. And route a payment through it, and there's no on chain backing? Like, there's no, like, collateral backing it? How does
336
00:21:40.215 --> 00:21:41.675
am I missing something there?
337
00:21:42.215 --> 00:21:48.440
338
00:21:48.919 --> 00:21:56.539
339
00:21:57.375 --> 00:21:59.075
340
00:21:59.855 --> 00:22:02.115
Okay. That makes sense. Really little sense here.
341
00:22:02.415 --> 00:22:06.630
342
00:22:07.010 --> 00:22:09.430
I guess. Well, I'm glad you guys thought about that already.
343
00:22:11.490 --> 00:22:16.105
Okay. So that's awesome. So so you you have the UX benefits
344
00:22:17.685 --> 00:22:20.425
of traditional custodial wallets like Wallet of Satoshi,
345
00:22:21.045 --> 00:22:22.025
but you have,
346
00:22:22.750 --> 00:22:24.610
performance and privacy benefits,
347
00:22:26.110 --> 00:22:30.130
rather than that in an hosted channel model to distill it. Yeah. Almost.
348
00:22:30.644 --> 00:22:31.764
349
00:22:32.164 --> 00:22:33.865
in order to receive payment,
350
00:22:34.644 --> 00:22:41.330
such a channel still has to be online unlike, say, Wallet of Satoshi, but it's for a very good reason because,
351
00:22:43.550 --> 00:22:46.210
in hosted channels, just like in normal channels,
352
00:22:47.395 --> 00:22:52.054
The final receiver is the one who releases pretty much, and as such,
353
00:22:53.635 --> 00:22:55.655
hosted channel users can prove
354
00:22:56.100 --> 00:22:59.000
then he really received payment, or
355
00:22:59.540 --> 00:23:00.760
if host starts,
356
00:23:01.220 --> 00:23:03.960
like, acting funny, it can prove that,
357
00:23:04.915 --> 00:23:06.995
payments that it has received and,
358
00:23:07.715 --> 00:23:10.195
for which it has released the pre match still
359
00:23:10.915 --> 00:23:13.575
well, the money belongs to receiver.
360
00:23:13.970 --> 00:23:17.750
361
00:23:18.370 --> 00:23:19.270
362
00:23:20.290 --> 00:23:24.375
363
00:23:25.795 --> 00:23:36.910
364
00:23:37.290 --> 00:23:46.295
say things like they never received it. With hosted channel, it's still you who received it. So you can prove that you really received it is if
365
00:23:46.675 --> 00:23:48.215
they say you didn't.
366
00:23:49.100 --> 00:23:49.919
Got it. Another
367
00:23:50.539 --> 00:23:51.039
difference.
368
00:23:53.419 --> 00:23:57.600
369
00:23:58.955 --> 00:24:01.695
hit us. Hit us. Whatever you're saying, hit us.
370
00:24:02.395 --> 00:24:04.335
371
00:24:05.010 --> 00:24:16.295
like, claim that your host or channel provider scammed you. Like, otherwise, if you say you trust them anyway, then you could also just give them the preimage, and then you wouldn't have the problem that you need to keep your wallet open to receive.
372
00:24:18.275 --> 00:24:24.110
373
00:24:24.650 --> 00:24:26.350
That's the thing. Yeah. But you're
374
00:24:27.050 --> 00:24:28.350
you're trusting them anyway.
375
00:24:28.835 --> 00:24:30.135
So, yes, there's
376
00:24:30.675 --> 00:24:35.095
trust involved, but it's not that kind of trust that you have in normal
377
00:24:35.395 --> 00:24:35.895
custodial
378
00:24:38.060 --> 00:24:41.280
provider, like, Wallet of Satoshi. In hosted channels,
379
00:24:41.740 --> 00:24:42.540
there's still,
380
00:24:43.660 --> 00:24:46.000
balance distribution is always cryptographically
381
00:24:46.460 --> 00:24:46.960
provable.
382
00:24:47.285 --> 00:24:53.145
So you can prove that, whatever host owes to you that it is the case.
383
00:24:54.165 --> 00:24:57.570
384
00:24:58.350 --> 00:25:01.870
secured by the potential of raising a stink on Twitter that,
385
00:25:02.350 --> 00:25:04.050
some specific host of channel
386
00:25:04.795 --> 00:25:10.655
provide a scammed you. And you couldn't do this giving them the pretty much because then they could just claim you actually never,
387
00:25:11.595 --> 00:25:13.375
like, got an invoice paid.
388
00:25:14.030 --> 00:25:17.170
389
00:25:17.630 --> 00:25:18.850
390
00:25:20.030 --> 00:25:22.205
Yeah. Is it that's true. Yes. Because,
391
00:25:22.585 --> 00:25:26.105
exit scam is probably the only type of scam that,
392
00:25:26.985 --> 00:25:32.490
host can perform because they can't scan selectively because that will become very visible
393
00:25:32.950 --> 00:25:33.450
immediately.
394
00:25:34.950 --> 00:25:36.169
395
00:25:36.789 --> 00:25:38.650
like, the one thing about
396
00:25:39.505 --> 00:25:43.505
the exit scam is that it happens all at once. Like, the mark of an exit scam. So,
397
00:25:44.945 --> 00:25:51.050
what is the benefit of being able to prove that someone just excellent, just lost their funds anyway, and no no one else
398
00:25:51.750 --> 00:25:52.250
will
399
00:25:52.790 --> 00:25:54.845
trust them anymore. So
400
00:25:55.625 --> 00:25:59.005
401
00:25:59.865 --> 00:26:06.250
someone like Waller or Satoshi could, and they they haven't as far as I'm con as far as I'm aware, but they they could
402
00:26:06.710 --> 00:26:07.210
conceivably
403
00:26:07.510 --> 00:26:10.170
be stealing money from, like, certain individuals
404
00:26:10.835 --> 00:26:12.535
in small amounts without
405
00:26:13.315 --> 00:26:16.695
doing a full blown exit scam? Yes. Totally. They could.
406
00:26:17.555 --> 00:26:23.150
407
00:26:23.530 --> 00:26:26.030
everything is off chain. And if you use
408
00:26:28.295 --> 00:26:29.195
these custodians,
409
00:26:29.575 --> 00:26:39.860
nothing is provable at all. They can do anything. They can claim that, yeah, that whatever payment you receive, you didn't receive, and it's your word against the there's
410
00:26:40.559 --> 00:26:41.059
411
00:26:42.399 --> 00:26:46.980
I mean, a perfect example feels like the experience people are hearing about Chivo,
412
00:26:48.145 --> 00:26:50.165
which is a fully custodial wallet,
413
00:26:50.705 --> 00:26:53.925
the government wallet of El Salvador where you pay a lightning payment,
414
00:26:54.225 --> 00:26:57.410
and then the sender's wallet says that it was successfully sent,
415
00:26:57.970 --> 00:27:00.710
but the receiver has no proof that
416
00:27:01.250 --> 00:27:08.115
they they don't see it on their side, and then you call support or whatever and support's like, you gotta call up lightning and get your money refunded.
417
00:27:09.215 --> 00:27:11.315
If Chivo was using hosted wallets,
418
00:27:11.935 --> 00:27:13.395
then at least you'd have
419
00:27:15.550 --> 00:27:20.530
you'd have some kind of receipt. You'd have, like, a cryptographic proof that you'd you didn't get your money.
420
00:27:21.205 --> 00:27:28.980
421
00:27:29.620 --> 00:27:30.760
user ports.
422
00:27:31.460 --> 00:27:34.120
So, yeah, it would be a totally different situation.
423
00:27:34.900 --> 00:27:38.465
424
00:27:39.184 --> 00:27:42.164
that feels like a big, implementation bug in Shivo.
425
00:27:42.465 --> 00:27:46.100
But by requiring to query the client for the preimage,
426
00:27:46.480 --> 00:27:51.220
you kind of, like, prevent this whole set of bugs that you
427
00:27:51.600 --> 00:27:54.100
could build into such a system. Yeah. That's true.
428
00:27:55.485 --> 00:27:55.985
429
00:27:58.125 --> 00:27:59.825
Okay. So that's hosted wallets
430
00:28:00.205 --> 00:28:03.345
and simple Bitcoin wallet. Now let's move,
431
00:28:05.310 --> 00:28:06.050
to Eric's,
432
00:28:06.750 --> 00:28:09.090
Federated Charmin eCash proposal.
433
00:28:09.870 --> 00:28:12.690
Eric, you wanna describe that high level for us?
434
00:28:13.715 --> 00:28:18.615
435
00:28:19.155 --> 00:28:19.655
like,
436
00:28:20.440 --> 00:28:21.500
in some sense,
437
00:28:21.880 --> 00:28:32.304
federated e cache is just an extension of that idea because my observation was, like, most people will not be able open their own lightning notes. So what do we do about it?
438
00:28:32.605 --> 00:28:33.505
Like, letting them
439
00:28:33.885 --> 00:28:36.830
go to banks, to traditional custodians, it's it's
440
00:28:37.630 --> 00:28:39.090
the the worst solution of all.
441
00:28:40.029 --> 00:28:42.049
But on the other hand, like, I can't expect,
442
00:28:43.399 --> 00:28:43.845
someone
443
00:28:44.804 --> 00:28:48.345
who maybe makes $5 a day to open a channel for $4.
444
00:28:48.804 --> 00:28:50.105
That's also not viable.
445
00:28:51.684 --> 00:28:52.184
So
446
00:28:52.610 --> 00:28:57.750
we already touched on hosted channels, and in my opinion, there are 2 major concerns.
447
00:28:58.929 --> 00:29:02.405
The first is obviously trust. Like, you need to trust
448
00:29:02.965 --> 00:29:04.105
your host
449
00:29:04.645 --> 00:29:05.465
channel provider.
450
00:29:05.845 --> 00:29:10.115
And federated e cash of not really solves, but a problem
451
00:29:10.700 --> 00:29:13.440
by distributing the trust over multiple parties,
452
00:29:14.620 --> 00:29:18.880
of which now some might be malicious without the whole thing falling apart.
453
00:29:19.184 --> 00:29:25.044
Like, if you have a federation of 4, one can just be malicious and, all your funds are safe. The federation
454
00:29:25.505 --> 00:29:26.405
stays operational.
455
00:29:27.840 --> 00:29:31.780
And the second thing that Federated Ecash solves is privacy.
456
00:29:32.480 --> 00:29:35.539
Because while hosted channels provide good payment privacy,
457
00:29:37.365 --> 00:29:46.850
the, like, account holdings privacy isn't all that great because your host of channel provider still sees how much, he owes you. He knows how much you own in in the host channel.
458
00:29:47.870 --> 00:29:56.325
So with e cash, you also hide how much you you own in a certain ecache federation, which is equivalent to the hosted channel provider.
459
00:29:57.345 --> 00:30:02.490
So on a high level, these are the two things that, federated ecache fixes.
460
00:30:06.950 --> 00:30:07.450
461
00:30:08.415 --> 00:30:13.235
when I when I attempt to describe your proposal, the way I kind of describe it is
462
00:30:17.030 --> 00:30:20.890
you have the UX benefits of a custodial lightning wallet.
463
00:30:22.630 --> 00:30:23.450
You have
464
00:30:24.725 --> 00:30:28.745
that you have the custodial risk of actual funds loss being mitigated,
465
00:30:30.485 --> 00:30:30.985
because
466
00:30:31.285 --> 00:30:40.039
instead of a single custodian, you have this collection of custodians that have to basically collude to steal your money. So people can think of that like a multi sig custodian.
467
00:30:40.715 --> 00:30:43.375
And then you have these privacy this privacy benefit
468
00:30:43.914 --> 00:30:45.375
of Chaumu and e cash
469
00:30:45.995 --> 00:30:48.975
where not only do you have privacy from the custodian,
470
00:30:51.360 --> 00:30:53.059
but you get increased privacy
471
00:30:54.399 --> 00:30:57.379
for all of your operations on the greater Lightning Network,
472
00:30:58.185 --> 00:30:59.485
the larger that
473
00:30:59.945 --> 00:31:04.525
pool of funds gets in that within that federation. So you you're able to operate
474
00:31:06.080 --> 00:31:08.740
in in both these cases, in both with both,
475
00:31:09.200 --> 00:31:10.820
hosted channels and
476
00:31:11.520 --> 00:31:13.940
Federated Chaumian e cache, you're able to operate
477
00:31:14.804 --> 00:31:16.245
among the Greater Lightning where
478
00:31:17.125 --> 00:31:20.105
grading Greater Lightning Network you can send and receive
479
00:31:20.485 --> 00:31:23.385
from any Lightning Wallet, to those wallets.
480
00:31:25.810 --> 00:31:27.430
481
00:31:27.890 --> 00:31:30.950
And the the nice thing about the e cash is that it's
482
00:31:31.404 --> 00:31:36.705
actually perfectly private. Like, at least federation internal ecash to ecash transactions
483
00:31:37.485 --> 00:31:38.945
that you have, essentially
484
00:31:39.730 --> 00:31:41.669
the unlimited set of your entire federation,
485
00:31:42.289 --> 00:31:46.070
more or less. Like, there are some details that I'm leaving out, but, like,
486
00:31:47.625 --> 00:31:51.885
in a ideal federation, that's the case. Then, like, there's the second case with,
487
00:31:52.345 --> 00:31:56.365
interacting with the wider lightning network, and that's a little bit more complicated.
488
00:31:57.360 --> 00:31:58.900
Like, you can definitely hide,
489
00:31:59.679 --> 00:32:01.460
when you're sending a Lightning transaction
490
00:32:02.000 --> 00:32:03.540
that who is the sender,
491
00:32:04.665 --> 00:32:05.165
And
492
00:32:05.705 --> 00:32:07.805
if you're the recipient, who's the recipient?
493
00:32:09.945 --> 00:32:16.080
It's the problem thing is hiding the other side, like the lightning side. It's actually did some great work because,
494
00:32:16.780 --> 00:32:24.645
like, what you're doing there is you let the lightning, the the client actually route. So you only give only a message to the service
495
00:32:26.385 --> 00:32:27.205
out of the federation,
496
00:32:27.665 --> 00:32:28.725
and then let them,
497
00:32:29.185 --> 00:32:29.685
send
498
00:32:32.140 --> 00:32:36.960
once the product instead of making them relevant and all the stuff, a lot more information.
499
00:32:39.265 --> 00:32:43.365
It's I kind of think of it as a UX trade off. And,
500
00:32:45.080 --> 00:32:54.804
like, one caveat I have to add here is that Federated ECash is a research project right now. Like, there's no product, nothing that you should use or could use, on Bitcoin today.
501
00:32:55.664 --> 00:32:58.565
So I don't even have the lightning integration
502
00:32:59.105 --> 00:33:00.164
as it should be,
503
00:33:00.625 --> 00:33:05.789
implemented yet. Okay. I'm actually not sure if I will go the hosted channel way of routing
504
00:33:06.250 --> 00:33:07.870
or, like, the more traditional
505
00:33:08.730 --> 00:33:09.470
let's tell
506
00:33:10.250 --> 00:33:10.750
the
507
00:33:11.215 --> 00:33:14.035
equation where I want my payment to Google way of routing.
508
00:33:15.375 --> 00:33:16.355
That's still ongoing
509
00:33:16.895 --> 00:33:21.560
research essentially for me. The host to channel approach is a really interesting trade off.
510
00:33:22.420 --> 00:33:24.120
And other things like
511
00:33:25.885 --> 00:33:27.025
the payment privacy
512
00:33:27.805 --> 00:33:29.505
proposed by, Bastian,
513
00:33:32.045 --> 00:33:32.945
where you essentially
514
00:33:34.120 --> 00:33:37.100
include a plan that path in your invoice, that's also
515
00:33:37.640 --> 00:33:43.180
a great option. And I will see whatever works best and provides the best UX and
516
00:33:43.625 --> 00:33:44.285
best privacy.
517
00:33:44.585 --> 00:33:48.285
Because in my opinion, what is most important is to couple
518
00:33:48.745 --> 00:34:01.735
privacy with good UX so people actually want to use it because otherwise, you will have to 10 people that need privacy use your service. But all the other people that don't really care will use something else, and then you have unlimited set of 10. That's not what we want.
519
00:34:02.275 --> 00:34:08.240
520
00:34:09.339 --> 00:34:11.920
and you wanna reduce that as much as possible.
521
00:34:12.915 --> 00:34:16.055
522
00:34:16.515 --> 00:34:18.935
That's what I'm aiming for with Federated ECash.
523
00:34:22.170 --> 00:34:22.670
524
00:34:24.730 --> 00:34:28.350
So I think that was pretty good high level on Eric's proposal.
525
00:34:29.985 --> 00:34:40.640
I know Anton and Fiat, Jeff, have some feedback and some critiques. So I you guys want to jump into that, and we can have some good productive discussion here.
526
00:34:42.059 --> 00:34:42.880
527
00:34:43.260 --> 00:34:45.760
whatever concerns privacy and security,
528
00:34:46.140 --> 00:34:46.640
it's
529
00:34:47.115 --> 00:34:49.135
an interesting question here because
530
00:34:51.195 --> 00:34:52.255
so, you know,
531
00:34:52.555 --> 00:34:53.775
like has been explained
532
00:34:54.180 --> 00:34:55.160
by Eric,
533
00:34:56.579 --> 00:34:57.079
this
534
00:34:58.260 --> 00:35:03.240
federated cache thing wants to be a thing of its own and then also
535
00:35:05.605 --> 00:35:07.785
a lightning scaling solution, kinda.
536
00:35:08.565 --> 00:35:09.065
So
537
00:35:09.525 --> 00:35:12.805
it wants to integrate with lightning. And,
538
00:35:13.450 --> 00:35:17.790
if we are to extend lightning with this solution solutions,
539
00:35:18.730 --> 00:35:20.510
custodial solutions, we can
540
00:35:21.455 --> 00:35:23.715
talk about their quality, I guess,
541
00:35:26.735 --> 00:35:27.955
in the ways that,
542
00:35:28.495 --> 00:35:29.235
for example,
543
00:35:30.240 --> 00:35:32.260
when we're using normal channels,
544
00:35:33.520 --> 00:35:36.740
this graph on device, we can where we we have certain,
545
00:35:38.000 --> 00:35:38.980
useful features
546
00:35:39.595 --> 00:35:41.135
besides off chain payments,
547
00:35:42.635 --> 00:35:43.855
such as, for example,
548
00:35:44.234 --> 00:35:48.575
I can list 3 of them, which are related to privacy and security.
549
00:35:49.250 --> 00:35:53.109
First is already mentioned privacy when sending a payment
550
00:35:53.569 --> 00:35:54.069
because
551
00:35:55.410 --> 00:35:58.630
sender has a graph on device and can construct route.
552
00:35:59.315 --> 00:35:59.555
And,
553
00:36:00.435 --> 00:36:01.815
second one is
554
00:36:02.355 --> 00:36:02.855
enforceability
555
00:36:03.395 --> 00:36:05.815
on chain when receiving the payment,
556
00:36:06.115 --> 00:36:07.015
which is due
557
00:36:07.395 --> 00:36:08.615
to HTLC mechanics
558
00:36:09.050 --> 00:36:09.790
where receiver
559
00:36:10.170 --> 00:36:12.510
can publish transaction on chain
560
00:36:12.970 --> 00:36:13.470
if
561
00:36:14.170 --> 00:36:15.710
if peer starts to
562
00:36:16.994 --> 00:36:19.575
play some games and not update in the state.
563
00:36:20.115 --> 00:36:26.134
And, the third one is already mentioned, the inability, which comes from ability to route payment.
564
00:36:26.440 --> 00:36:31.579
And the the inability here is ability to always claim that this payment is not yours.
565
00:36:32.359 --> 00:36:32.859
So,
566
00:36:34.119 --> 00:36:36.140
I'd say I'd say a good
567
00:36:38.345 --> 00:36:45.965
extension to lightning, custodial extension would retain as much of those properties as possible. And when it comes to hosted channels,
568
00:36:47.040 --> 00:36:47.940
sender privacy
569
00:36:48.320 --> 00:36:48.820
and
570
00:36:49.840 --> 00:36:50.580
the the liability
571
00:36:51.280 --> 00:36:52.660
are retained in full,
572
00:36:53.120 --> 00:36:54.180
and the enforceability
573
00:36:54.560 --> 00:37:00.675
on chain is, of course, thrown away because there is no chain part, but it's replaced with probability,
574
00:37:01.455 --> 00:37:03.475
which is weaker notion, but
575
00:37:03.935 --> 00:37:05.315
still better than nothing.
576
00:37:06.560 --> 00:37:07.060
And,
577
00:37:07.360 --> 00:37:09.740
well, yeah. When it comes to,
578
00:37:10.800 --> 00:37:12.900
federated cash, I think there's,
579
00:37:13.360 --> 00:37:13.860
like,
580
00:37:14.955 --> 00:37:15.695
no consideration
581
00:37:15.995 --> 00:37:18.495
has been given to these things yet.
582
00:37:18.875 --> 00:37:19.375
So
583
00:37:19.915 --> 00:37:21.375
this concerns me indeed.
584
00:37:23.355 --> 00:37:24.335
585
00:37:25.020 --> 00:37:27.260
let me start from the back of your,
586
00:37:27.660 --> 00:37:32.160
list of 3 points. Like Mhmm. I think the liability actually becomes less important,
587
00:37:32.619 --> 00:37:35.994
once you have the anonymity that Ecash provides because
588
00:37:36.535 --> 00:37:41.515
when you're sending a payment, then the sender is completely anonymous anyway.
589
00:37:42.010 --> 00:37:47.770
Like, except for maybe leaking, something on the lightning side, which we need to con consider too. But,
590
00:37:48.490 --> 00:37:48.990
like,
591
00:37:49.494 --> 00:37:51.914
so does a host of channels need to do?
592
00:37:52.934 --> 00:37:55.194
So you don't really gain anything from
593
00:37:55.494 --> 00:37:59.320
and see where you're having routed the payment or not. Like, you don't care. Like
594
00:37:59.620 --> 00:38:01.560
Mhmm. Okay. You as a sender and
595
00:38:01.940 --> 00:38:04.920
anonymous in the first way 1st place. K?
596
00:38:05.325 --> 00:38:06.065
The enforceability,
597
00:38:07.244 --> 00:38:09.665
there, I probably agree with you. Like, e cash
598
00:38:10.605 --> 00:38:13.425
is not auditable, so you fully trust the federation.
599
00:38:14.290 --> 00:38:15.510
Mhmm. But
600
00:38:15.890 --> 00:38:19.590
as I said, like, putting trust in the federation of you. Because,
601
00:38:19.970 --> 00:38:23.755
let's say you have a community where you have 4 people that in the normal circumstances
602
00:38:24.295 --> 00:38:26.474
are well regarded to have reputation and you trust.
603
00:38:27.654 --> 00:38:29.595
But one of them now has accident
604
00:38:30.055 --> 00:38:33.370
and needs a lot of money really short on really short notice.
605
00:38:33.750 --> 00:38:38.330
Otherwise, he dies, for example. Then he would certainly exit scam you in a hosted channel scenario
606
00:38:38.645 --> 00:38:39.145
because
607
00:38:39.605 --> 00:38:42.745
then just how incentives work. But in a federated
608
00:38:44.085 --> 00:38:51.170
scenario, like, one of these 4 cannot just you can't even stop the federation and extort you. It would already need 2 participants.
609
00:38:52.190 --> 00:38:58.695
So you're much safer as a user. And so I think it might be a reasonable trade off to just fully trust the federation
610
00:38:59.155 --> 00:39:01.575
in exchange for way better privacy.
611
00:39:02.980 --> 00:39:04.680
Because e cash Well,
612
00:39:04.980 --> 00:39:06.600
613
00:39:07.940 --> 00:39:13.505
I have another question then. It's again about lightning integration. How this federation would,
614
00:39:14.125 --> 00:39:15.745
manage a lightning node?
615
00:39:17.165 --> 00:39:17.645
Because,
616
00:39:18.045 --> 00:39:20.785
it doesn't seem like an easy task to me
617
00:39:21.450 --> 00:39:23.450
618
00:39:24.650 --> 00:39:29.695
yeah. Please do. That's actually a really interesting question. Like, federated e cache in and of itself,
619
00:39:30.255 --> 00:39:32.915
does not need to have anything to do with lightning.
620
00:39:33.535 --> 00:39:34.435
Like, in the basic,
621
00:39:35.055 --> 00:39:42.099
model that I'm currently building, you have on chain an on chain multisig wallet. We have the majority of backing funds. And
622
00:39:44.800 --> 00:39:49.495
Mhmm. For these, you get eCash tokens issued by using smart contract inside the federation
623
00:39:50.435 --> 00:39:50.935
to
624
00:39:51.315 --> 00:39:58.040
incentivize an external Lightning Gateway, which has its own funds, which are not counted towards the backing funds of the federation,
625
00:39:59.060 --> 00:40:02.040
to make payments for you or to receive payments for you.
626
00:40:02.695 --> 00:40:06.235
So, essentially, you build a bridge between Lightning and your federation
627
00:40:06.615 --> 00:40:07.275
through these
628
00:40:07.735 --> 00:40:09.275
gate train nodes.
629
00:40:10.055 --> 00:40:11.355
And, so the Lightning,
630
00:40:14.230 --> 00:40:19.450
like, a single third party, but due to the smart console, you essentially rebuild HTLCs
631
00:40:19.750 --> 00:40:20.730
inside the federation,
632
00:40:21.265 --> 00:40:22.005
more or less.
633
00:40:23.904 --> 00:40:29.525
Yeah. That's that's like the current plan. And, like, in some future version of it, I could also,
634
00:40:30.260 --> 00:40:33.400
like, imagine having a fully federated lightning
635
00:40:33.780 --> 00:40:36.280
note. But as you said, that's really complicated. It needs
636
00:40:36.660 --> 00:40:39.765
a bunch of changes to the peer to peer protocol. It definitely needs
637
00:40:40.964 --> 00:40:42.424
taproot and Schnorr signatures,
638
00:40:42.805 --> 00:40:43.704
sees, like, all the
639
00:40:45.125 --> 00:40:47.605
good stuff. So that's not on the
640
00:40:50.230 --> 00:40:53.290
so yeah. Maybe, one thing I should mention is that
641
00:40:53.590 --> 00:40:56.730
by doing so, I assume that the funds held in Lightning
642
00:40:57.914 --> 00:41:02.974
are way smaller than the total packed in funds or the total deposited funds in the federation.
643
00:41:03.434 --> 00:41:04.255
Because, otherwise,
644
00:41:04.730 --> 00:41:07.710
this, model wouldn't make any sense because the light
645
00:41:10.569 --> 00:41:14.510
note essentially needs to hold a double because they can't be counted duration.
646
00:41:21.515 --> 00:41:24.095
647
00:41:25.290 --> 00:41:26.670
I see, like, a a conflict
648
00:41:27.450 --> 00:41:28.430
between having
649
00:41:28.809 --> 00:41:30.270
multiple small federations.
650
00:41:30.650 --> 00:41:32.750
Like, I I don't know if the name mini mint,
651
00:41:33.725 --> 00:41:37.585
is intended to to mean that the the these federations will be small.
652
00:41:38.845 --> 00:41:39.345
And,
653
00:41:39.885 --> 00:41:43.960
like, have having a large federation with a ton of accounts in it.
654
00:41:44.260 --> 00:41:44.760
And
655
00:41:45.140 --> 00:41:46.900
because you need either
656
00:41:47.460 --> 00:41:49.960
you need a large thing with a ton of people using
657
00:41:50.805 --> 00:41:53.865
so so they can transact between them, or you need
658
00:41:54.405 --> 00:41:55.945
very good inter interoperability
659
00:41:56.325 --> 00:41:58.025
between many small providers.
660
00:42:01.570 --> 00:42:03.589
661
00:42:04.690 --> 00:42:07.589
Do not convince everyone around to use your tokens
662
00:42:08.130 --> 00:42:09.270
beyond your users.
663
00:42:10.654 --> 00:42:15.394
664
00:42:17.454 --> 00:42:24.310
between these different means. And I agree, more expensive with on chain transactions get, the larger the federation
665
00:42:24.770 --> 00:42:25.670
needs to grow.
666
00:42:26.945 --> 00:42:32.085
And I'm not entirely sure that, having the lightning node external to the federation
667
00:42:34.700 --> 00:42:38.160
makes it significantly worse, like a 2 x factor, I think.
668
00:42:39.740 --> 00:42:41.600
That's maybe the difference between
669
00:42:41.975 --> 00:42:46.075
10 people, a 10 user federation, or a 20 user federation being economical.
670
00:42:48.215 --> 00:42:52.599
So we will see in the it will be a market process. That's the great thing. Like,
671
00:42:52.900 --> 00:43:00.295
I'm bill we are all building this stuff as open source software, so everyone can just run it, and we will see whatever wins.
672
00:43:01.395 --> 00:43:02.135
And also,
673
00:43:02.915 --> 00:43:04.215
for me, it's currently research.
674
00:43:04.835 --> 00:43:06.055
Probably won't be ready
675
00:43:06.560 --> 00:43:08.100
for mass market,
676
00:43:09.440 --> 00:43:10.900
in 2 years or so.
677
00:43:11.440 --> 00:43:14.260
I kinda hope to have a working prototype that
678
00:43:15.515 --> 00:43:22.175
a reckless person can set up on Mainnet. Yeah. It's it's research. Excuse me. Is it just me, or the quality is absolutely
679
00:43:23.595 --> 00:43:24.095
680
00:43:28.170 --> 00:43:29.150
681
00:43:29.770 --> 00:43:32.750
Eric's breaking up a little bit, but I can mostly hear him.
682
00:43:33.695 --> 00:43:34.435
683
00:43:35.375 --> 00:43:36.115
684
00:43:37.055 --> 00:43:37.715
I mean,
685
00:43:39.535 --> 00:43:46.760
I I mean, the the last thing he said is that it he doesn't expect to have, you know, a working app available for at least 2 years.
686
00:43:49.775 --> 00:43:51.315
687
00:43:52.255 --> 00:43:54.115
688
00:43:56.255 --> 00:43:58.515
689
00:43:59.519 --> 00:44:01.220
So, I mean, 2 years,
690
00:44:02.319 --> 00:44:05.299
so, like, realistically, that's, like, 4 years. Right, Eric?
691
00:44:07.815 --> 00:44:09.915
692
00:44:10.455 --> 00:44:20.049
taking into account such things. Like, I was at this 2 years thing, like, I mentioned ideally in 1 year, like, for next HCPP, I will have some
693
00:44:20.349 --> 00:44:24.855
working prototype on my net where I run a federation, so only I will lose funds.
694
00:44:29.475 --> 00:44:33.140
That should already work. We need to be really careful with
695
00:44:34.640 --> 00:44:35.460
new experimental
696
00:44:35.760 --> 00:44:37.859
things so that people don't trust.
697
00:44:39.325 --> 00:44:39.825
Yeah.
698
00:44:40.765 --> 00:44:44.224
So I tend to be a little bit more conservative. I mean, I think
699
00:44:45.005 --> 00:44:48.140
700
00:44:48.619 --> 00:44:50.079
to learn the hard way,
701
00:44:50.619 --> 00:44:54.880
the current custodial risks in terms of stuff like while the satoshi and blue wallet.
702
00:44:56.105 --> 00:45:00.285
Well, blue wallet is only custodial for its lightning, at least by default,
703
00:45:01.065 --> 00:45:02.204
not on chain.
704
00:45:02.770 --> 00:45:05.910
I mean, we saw it previously. I don't know if you guys remember,
705
00:45:07.890 --> 00:45:09.570
one of the most popular
706
00:45:09.995 --> 00:45:13.935
at one point, one of the most popular mobile lightning wallets was
707
00:45:14.555 --> 00:45:15.055
Dropbit,
708
00:45:16.155 --> 00:45:18.815
which is a custodial lightning wallet, and
709
00:45:19.115 --> 00:45:19.855
the feds,
710
00:45:20.300 --> 00:45:21.440
the US government,
711
00:45:23.020 --> 00:45:24.160
raided them because
712
00:45:24.619 --> 00:45:28.720
that guy, I think Larry Harmon was his name, was running a mixer as well,
713
00:45:30.435 --> 00:45:34.375
a custodial mixer, and they seized all the funds. Everyone lost all their money,
714
00:45:36.960 --> 00:45:42.400
and people forget that really quickly. But, as I as I see I mean, I I was looking at,
715
00:45:43.595 --> 00:45:44.414
all the videos of people
716
00:45:44.714 --> 00:45:47.775
buying pupusas in, El Salvador this week.
717
00:45:48.154 --> 00:45:52.654
A lot of people were using wild as Satoshi. Like, a lot of people that you'd think would know better.
718
00:45:54.290 --> 00:45:58.950
You know, they say, oh, it's just for a small amount, but, you know, that small amount tends to grow.
719
00:46:02.025 --> 00:46:12.580
720
00:46:12.960 --> 00:46:13.780
receive more.
721
00:46:14.720 --> 00:46:16.500
I have no desire to,
722
00:46:17.125 --> 00:46:19.705
like, store any more money for my users.
723
00:46:20.325 --> 00:46:22.265
724
00:46:23.740 --> 00:46:27.520
from a UX point of view, there's obviously massive benefits to custodial.
725
00:46:28.780 --> 00:46:29.760
As a Bitcoiner,
726
00:46:30.140 --> 00:46:31.039
I am,
727
00:46:33.475 --> 00:46:35.495
emotionally I I'm, obviously,
728
00:46:35.875 --> 00:46:36.375
against
729
00:46:36.755 --> 00:46:37.895
custodial models.
730
00:46:39.740 --> 00:46:42.240
Makes me a little bit sick just thinking about it.
731
00:46:44.300 --> 00:46:48.640
Hosted channels seems like a decent trade off balance in terms of UX,
732
00:46:49.315 --> 00:46:50.535
privacy and security,
733
00:46:53.075 --> 00:46:57.015
for the near term, and then, ideally, something like this
734
00:46:57.740 --> 00:46:58.960
Federated Chamian
735
00:46:59.579 --> 00:47:00.079
proposal,
736
00:47:01.500 --> 00:47:02.400
for the future,
737
00:47:03.180 --> 00:47:05.280
kind of improves on that trade off balance.
738
00:47:06.345 --> 00:47:08.924
Fiat and Anton, do you disagree with that
739
00:47:10.265 --> 00:47:11.805
thought process or that analysis?
740
00:47:13.065 --> 00:47:13.885
741
00:47:14.265 --> 00:47:14.765
but
742
00:47:15.530 --> 00:47:17.310
I guess I'd better see
743
00:47:18.330 --> 00:47:23.630
something real with relation to this Fedimint, and then I could make a better judgment.
744
00:47:25.235 --> 00:47:31.495
745
00:47:32.550 --> 00:47:35.450
And then, like, he he will have to implement
746
00:47:35.910 --> 00:47:40.204
something that looks like hosted yesterday to to achieve better privacy for
747
00:47:40.825 --> 00:47:42.045
outgoing and incoming
748
00:47:42.345 --> 00:47:43.165
lightning payments,
749
00:47:44.665 --> 00:47:45.805
then it will be good.
750
00:47:46.480 --> 00:47:48.020
751
00:47:48.320 --> 00:47:50.100
more recently than Drop It,
752
00:47:52.160 --> 00:47:57.065
one of my favorite Lightning wallets, which I used to receive donations for the show as well,
753
00:47:58.325 --> 00:48:00.505
is Fiat Jaff's, LNTX
754
00:48:00.964 --> 00:48:04.180
bot, which is a lightning wallet, a custodial lightning wallet that operates
755
00:48:04.640 --> 00:48:09.060
on Telegram. And you got you recently got attacked. Right? You lost all your funds.
756
00:48:10.915 --> 00:48:13.494
757
00:48:13.875 --> 00:48:21.950
758
00:48:22.410 --> 00:48:24.670
759
00:48:26.570 --> 00:48:27.470
and and, like,
760
00:48:27.974 --> 00:48:32.315
started exploiting. This this happened in the past. This this last one was the biggest one.
761
00:48:32.775 --> 00:48:35.675
762
00:48:36.780 --> 00:48:39.900
763
00:48:40.460 --> 00:48:41.600
he stepped on the bug
764
00:48:42.220 --> 00:48:46.715
765
00:48:47.975 --> 00:48:53.035
And then, I guess I mean, I don't agree with everything he does, but is it true that Alastair Milne
766
00:48:53.380 --> 00:48:58.200
jumped in and and made you whole so the wallet could keep going? Yes. Amazing.
767
00:48:58.500 --> 00:49:01.605
768
00:49:02.085 --> 00:49:02.984
ton of money.
769
00:49:04.005 --> 00:49:07.145
770
00:49:07.445 --> 00:49:07.945
771
00:49:08.700 --> 00:49:10.640
772
00:49:11.500 --> 00:49:12.640
or something like that?
773
00:49:14.140 --> 00:49:20.365
Yes. That's it. That's impressive. He just jumped right in there on Twitter. I was impressed. I mean, like I said, I don't agree with everything he does, but,
774
00:49:21.244 --> 00:49:25.265
775
00:49:25.565 --> 00:49:27.185
776
00:49:28.520 --> 00:49:34.300
777
00:49:36.115 --> 00:49:36.935
778
00:49:38.355 --> 00:49:39.175
So, I mean,
779
00:49:39.715 --> 00:49:40.695
I I didn't realize,
780
00:49:41.075 --> 00:49:43.815
but you guys hit on an interesting point there. I mean,
781
00:49:44.670 --> 00:49:46.770
in Bitcoin land, we like to,
782
00:49:48.590 --> 00:49:51.170
if we see something that's like a theoretical proposal
783
00:49:52.125 --> 00:49:55.345
that looks awesome, we tend to really hype the fuck out of it.
784
00:49:56.205 --> 00:49:57.905
I think I'm better than most,
785
00:49:58.445 --> 00:49:59.505
but I will admit
786
00:50:00.380 --> 00:50:02.080
that with Eric's Charmian
787
00:50:02.859 --> 00:50:04.640
Federated Charmian eCash proposal,
788
00:50:06.540 --> 00:50:08.960
I got very excited, and I'm still very excited
789
00:50:10.445 --> 00:50:13.425
because, I mean, to me, I'm I have a privacy focus,
790
00:50:14.205 --> 00:50:18.385
and I'm, like, constantly trying to educate new users on using Bitcoin privately.
791
00:50:19.089 --> 00:50:24.630
And there's so many nuances, there's so many difficulties, like the fact that you could have, like, an easy, low cost,
792
00:50:25.410 --> 00:50:26.869
you know, mobile focused,
793
00:50:27.915 --> 00:50:30.175
very private way of using Bitcoin,
794
00:50:31.035 --> 00:50:32.175
to me is like
795
00:50:32.555 --> 00:50:36.895
I mean, it would save me so much time. I mean, if someone's only spending a $100, $200,
796
00:50:37.420 --> 00:50:39.120
you know, a 1,000,000 sats,
797
00:50:39.900 --> 00:50:45.040
2,000,000 sats, like, if they can just download an app and have relatively good,
798
00:50:47.085 --> 00:50:52.545
security guarantees in terms of custodial risk, and have very good privacy guarantees
799
00:50:52.845 --> 00:50:54.065
at very low fees,
800
00:50:54.940 --> 00:50:58.560
to me, that's like a holy grail. I would save a ton of time when I'm,
801
00:50:59.420 --> 00:51:01.599
trying to educate new users. Now
802
00:51:02.355 --> 00:51:04.775
one thing that I missed in this whole aspect
803
00:51:06.035 --> 00:51:12.180
is what Anton mentioned earlier, and I I think we need to highlight that a little bit more. I mean, this idea that
804
00:51:13.380 --> 00:51:14.119
the Federation
805
00:51:14.500 --> 00:51:22.165
with these Charmian tokens is separate from the actual Lightning node itself. That seems to be the biggest hurdle here. Would you agree, Eric?
806
00:51:25.605 --> 00:51:27.705
807
00:51:29.125 --> 00:51:30.505
I mean, it's also not
808
00:51:31.190 --> 00:51:44.385
intended to stay that way forever. Like, ideally, at some point, we can actually federate a lightning node. But for now, like, it's just so much easier to implement it that way and not just wait another 7 years to get featherweighted lightning nodes.
809
00:51:45.405 --> 00:51:48.500
810
00:51:49.200 --> 00:51:56.705
811
00:51:59.005 --> 00:52:01.665
I'm not entirely sure. Like, the problem is I'm not
812
00:52:02.180 --> 00:52:07.000
that much of a lightning developer. I don't know all that much about lightning.
813
00:52:08.020 --> 00:52:09.960
Like, I spoke to some people
814
00:52:10.340 --> 00:52:10.920
I've had
815
00:52:11.885 --> 00:52:12.625
in Miami,
816
00:52:13.645 --> 00:52:15.825
and they were pretty then actually building
817
00:52:16.285 --> 00:52:18.065
a distributed lighting note eventually.
818
00:52:20.340 --> 00:52:25.560
But I think much work that needs to be done before, like even just getting all the benefits
819
00:52:26.020 --> 00:52:27.825
into lightning, eventually, probably,
820
00:52:29.805 --> 00:52:30.305
resulting
821
00:52:30.925 --> 00:52:37.840
in l 2 and all the good stuff. Like, that will take a lot of time. So they are not thinking about it just right now
822
00:52:38.220 --> 00:52:39.520
as far as I'm aware.
823
00:52:40.460 --> 00:52:43.920
824
00:52:44.515 --> 00:52:46.695
having instead of a bunch of federations,
825
00:52:47.395 --> 00:52:49.335
you have a big federation like liquid,
826
00:52:49.875 --> 00:52:50.375
but
827
00:52:50.755 --> 00:52:53.175
that's being a a Chow Meon Mint.
828
00:52:53.670 --> 00:52:58.089
And then you Okay. The the the need for lightning decreases very much.
829
00:52:59.430 --> 00:52:59.930
830
00:53:00.309 --> 00:53:02.730
at the risk of, pissing off someone,
831
00:53:03.465 --> 00:53:04.205
at Blockstream.
832
00:53:04.825 --> 00:53:05.325
No.
833
00:53:05.625 --> 00:53:06.125
Seriously.
834
00:53:08.185 --> 00:53:11.085
I think this one federation all approach
835
00:53:12.160 --> 00:53:15.060
isn't all that great to onboard
836
00:53:15.920 --> 00:53:17.460
general the general users,
837
00:53:17.840 --> 00:53:19.060
of Bitcoin. Like,
838
00:53:19.555 --> 00:53:24.935
liquid is great, for example, for traders that trust exchanges anyway. They don't really give a shit. Like,
839
00:53:25.955 --> 00:53:29.880
their trust model is far worse, and with liquid, it doesn't get that much worse.
840
00:53:30.339 --> 00:53:46.405
But normal Bitcoin users should have higher standards when it comes to custodial risk. And having this one big federation to rule them all would become a systemic risk over time, in my opinion. And that's not what I want for Bitcoin. That's not what I want to work on. Like, if there's there wouldn't be a possibility
841
00:53:46.740 --> 00:53:48.200
to easily integrate
842
00:53:48.500 --> 00:53:49.000
different
843
00:53:49.940 --> 00:53:55.560
make it federations interoperable. I wouldn't have proposed it. Even so, it's still a really interesting research idea.
844
00:53:56.505 --> 00:53:57.645
But, like, only
845
00:53:58.265 --> 00:53:59.565
by making them interoperable,
846
00:53:59.945 --> 00:54:00.685
they really
847
00:54:01.385 --> 00:54:09.010
benefit to Bitcoin, in my opinion. Otherwise, there would be too much of a risk that over time it would centralize into, like, just one big federation.
848
00:54:09.950 --> 00:54:14.734
849
00:54:15.035 --> 00:54:15.535
protocol
850
00:54:15.835 --> 00:54:20.895
that could be, like, some payment general stuff, but special for federations
851
00:54:21.980 --> 00:54:23.760
that involve a trust between federations
852
00:54:24.620 --> 00:54:28.000
that you could, like, link multiple federations using that.
853
00:54:28.515 --> 00:54:31.494
And then people could route payments between federations.
854
00:54:31.955 --> 00:54:35.734
I'm, like, bypassing lightning completely, but still
855
00:54:36.609 --> 00:54:39.109
splitting the trust between many federations.
856
00:54:41.089 --> 00:54:44.230
857
00:54:45.105 --> 00:54:49.924
payment layer? Like, if you still want to avoid trust between federations, which is really important,
858
00:54:50.305 --> 00:54:56.220
then you definitely need something like lightning. And at that point, why not just connect it to the wider lightning network?
859
00:54:56.920 --> 00:54:58.440
That just has benefits. Like
860
00:54:59.640 --> 00:55:03.965
861
00:55:04.345 --> 00:55:07.325
And we could Oh, yeah. But the c plan to do
862
00:55:08.825 --> 00:55:11.005
a payment channel based on trust
863
00:55:11.465 --> 00:55:12.365
between federations.
864
00:55:14.090 --> 00:55:18.270
865
00:55:19.210 --> 00:55:21.470
Like, even worse in the case of these federations
866
00:55:21.885 --> 00:55:26.465
The great thing about having Lightning integration with these federations is that you can start your own without
867
00:55:27.005 --> 00:55:27.985
asking for permission.
868
00:55:28.605 --> 00:55:30.305
If you need a trusted channel
869
00:55:30.660 --> 00:55:31.640
to other federations,
870
00:55:32.579 --> 00:55:34.760
then you're at this point where you have
871
00:55:35.299 --> 00:55:38.520
to ask for permission to cooperate with them and, like,
872
00:55:38.944 --> 00:55:39.765
open these channels.
873
00:55:40.464 --> 00:55:42.885
That would be horrible. That would just recreate banking.
874
00:55:44.145 --> 00:55:49.410
875
00:55:49.810 --> 00:55:51.030
that's the difference there.
876
00:55:51.410 --> 00:55:53.510
It's if it's open, if you can
877
00:55:53.810 --> 00:55:55.430
open channels for anyone, like,
878
00:55:55.985 --> 00:55:58.545
I don't know. I mean, today Yeah. But Like, I know definitely.
879
00:55:58.945 --> 00:56:00.405
880
00:56:01.345 --> 00:56:04.245
881
00:56:05.599 --> 00:56:06.579
882
00:56:07.040 --> 00:56:08.819
You have a strong opinion on that.
883
00:56:09.200 --> 00:56:09.940
Didn't know.
884
00:56:11.520 --> 00:56:15.300
Never generally. I imagine lightning to stay this open network where,
885
00:56:16.065 --> 00:56:21.765
like, if I open a channel to you, you don't ask too many questions. Otherwise, it will be a failure. Otherwise, it will be
886
00:56:25.550 --> 00:56:26.290
by regulators.
887
00:56:26.910 --> 00:56:28.610
That's the big problem. If
888
00:56:29.710 --> 00:56:31.090
appears to connect to you,
889
00:56:31.710 --> 00:56:32.190
that you
890
00:56:32.845 --> 00:56:35.105
then lightning will tend to centralize.
891
00:56:37.565 --> 00:56:43.960
So that's why I'm also not too big of a fan of routing hosted channels. Like, they are great for users, for end users,
892
00:56:44.280 --> 00:56:45.099
but between,
893
00:56:46.599 --> 00:56:47.740
your lightning nodes,
894
00:56:49.320 --> 00:56:54.885
they create a a big risk of, like, exit scams. Like, let's say, half your channels,
895
00:56:55.425 --> 00:56:57.685
a host of channels, and then you just put
896
00:56:58.080 --> 00:57:03.380
put all the funds out of them, put them into your real channels, and close them, and you're gone.
897
00:57:03.760 --> 00:57:05.540
That's a big risk. And secondly,
898
00:57:06.880 --> 00:57:07.360
you
899
00:57:08.005 --> 00:57:08.905
might actually get
900
00:57:09.525 --> 00:57:10.745
the first time before
901
00:57:11.205 --> 00:57:13.685
you do this. You get the big,
902
00:57:14.005 --> 00:57:14.505
benefit.
903
00:57:16.630 --> 00:57:17.610
Unfair benefits
904
00:57:18.510 --> 00:57:19.010
of
905
00:57:20.150 --> 00:57:20.970
the competition,
906
00:57:23.430 --> 00:57:24.625
namely that you don't
907
00:57:25.025 --> 00:57:25.685
need to,
908
00:57:26.865 --> 00:57:28.085
expand as much capital
909
00:57:29.025 --> 00:57:29.685
as you.
910
00:57:33.390 --> 00:57:37.890
I know. So I'm not not too big of a fan of routing host channels, but you might disagree.
911
00:57:42.295 --> 00:57:45.195
912
00:57:48.470 --> 00:57:52.810
there was something unfair in there, and then I didn't hear. Can you please repeat that
913
00:57:53.110 --> 00:57:54.010
that part?
914
00:57:54.630 --> 00:57:56.170
What is exactly unfair?
915
00:57:59.335 --> 00:58:01.115
916
00:58:01.655 --> 00:58:02.714
over the
917
00:58:03.015 --> 00:58:04.474
your peers that use
918
00:58:05.815 --> 00:58:07.035
fully backed channels.
919
00:58:08.529 --> 00:58:17.589
So, like, I mean, it's not really unfair in that sense, but, like, fortune until people figure out they can use this to exit scam and then the market will have to price in that risk.
920
00:58:20.005 --> 00:58:21.945
The market distortion that, disincentivizes,
921
00:58:22.805 --> 00:58:24.425
actually having the backing funds.
922
00:58:27.370 --> 00:58:28.670
923
00:58:29.610 --> 00:58:35.390
Well, to me, it's like, if you open a hosted channel, you take certain risk. Yes. You don't put
924
00:58:35.735 --> 00:58:37.035
funds on chain.
925
00:58:37.575 --> 00:58:38.075
So
926
00:58:38.375 --> 00:58:41.355
you have spared some working capital, but you have
927
00:58:41.735 --> 00:58:43.435
risk of exit scam. So
928
00:58:43.770 --> 00:58:47.150
to my understanding, it's fair. You understand your risks
929
00:58:47.450 --> 00:58:48.910
and which is important
930
00:58:49.210 --> 00:58:54.315
931
00:58:55.755 --> 00:58:56.255
sorry.
932
00:59:04.150 --> 00:59:06.490
933
00:59:08.070 --> 00:59:10.135
934
00:59:10.755 --> 00:59:11.415
I finished.
935
00:59:13.955 --> 00:59:15.655
936
00:59:16.450 --> 00:59:17.990
it for me. It's probably me.
937
00:59:19.650 --> 00:59:20.150
But,
938
00:59:20.610 --> 00:59:21.510
yeah, if you
939
00:59:22.530 --> 00:59:24.390
understand these risks, it's great.
940
00:59:24.690 --> 00:59:25.250
Then I'll
941
00:59:27.674 --> 00:59:32.894
942
00:59:33.275 --> 00:59:35.454
people won't be taking that much risks.
943
00:59:36.300 --> 00:59:37.280
944
00:59:37.900 --> 00:59:39.760
if the hosted channels are
945
00:59:40.140 --> 00:59:42.960
routing hosted channels. If they're private hosted channels
946
00:59:43.260 --> 00:59:44.320
for an end user,
947
00:59:46.155 --> 00:59:51.214
948
00:59:53.520 --> 00:59:54.960
yeah, my my fear is that,
949
00:59:55.360 --> 00:59:56.260
people underestimate
950
00:59:57.120 --> 00:59:58.500
the the excess game risk.
951
01:00:03.494 --> 01:00:05.434
952
01:00:06.055 --> 01:00:07.755
I mean, my fear is,
953
01:00:09.140 --> 01:00:11.640
lightning has not really operated in adversarial
954
01:00:11.940 --> 01:00:12.440
environment.
955
01:00:13.859 --> 01:00:17.480
I mean, lightning hasn't operated in adversarial environment, period.
956
01:00:19.724 --> 01:00:21.665
So I think most people are underestimating
957
01:00:22.125 --> 01:00:26.145
the risk, period, of having funds on Lightning. Would you guys disagree with that?
958
01:00:28.839 --> 01:00:35.260
959
01:00:35.640 --> 01:00:36.925
they're serious,
960
01:00:38.185 --> 01:00:45.085
and I think also no one is no one who wants to attack is has the knowledge to to operate these attacks
961
01:00:47.140 --> 01:00:50.360
962
01:00:51.300 --> 01:00:53.080
lightning channels were not
963
01:00:53.380 --> 01:00:54.360
actually backed
964
01:00:55.055 --> 01:00:56.115
by transactions.
965
01:00:57.455 --> 01:00:57.955
So
966
01:00:59.215 --> 01:01:06.130
967
01:01:06.589 --> 01:01:07.650
968
01:01:08.190 --> 01:01:10.210
969
01:01:10.750 --> 01:01:16.515
you know, multiple relatively large lightning nodes for over 2 years now, and I've just literally
970
01:01:18.015 --> 01:01:21.075
I've just been waiting for my funds to get lost.
971
01:01:21.820 --> 01:01:23.120
That that hasn't happened yet.
972
01:01:30.415 --> 01:01:35.555
No. I mean, this this discussion is super interesting. I would go back to what Fiat Jaffe was saying earlier
973
01:01:36.095 --> 01:01:39.715
about why the lightning component in the first place. And to me,
974
01:01:40.830 --> 01:01:46.690
you know, would Eric's proposal be interesting still if he didn't have the Lightning component? Yes. Because I'm
975
01:01:47.125 --> 01:01:50.745
a I I I care about privacy on Bitcoin being easier,
976
01:01:52.485 --> 01:01:55.990
but it wouldn't be nearly as interesting to me for the interoperability
977
01:01:56.370 --> 01:01:59.110
aspect of it. Like, it's not only
978
01:01:59.890 --> 01:02:01.190
the fact that the federations
979
01:02:01.570 --> 01:02:02.390
can interoperate
980
01:02:02.770 --> 01:02:05.135
very easily. Like, what I've noticed with liquid,
981
01:02:05.675 --> 01:02:14.255
which absolutely nobody uses. I mean, I have mempool dot space up, but if I switch it, I could switch it right now to the to the liquid one.
982
01:02:14.750 --> 01:02:15.490
Just fucking
983
01:02:15.790 --> 01:02:16.770
absolutely empty.
984
01:02:19.150 --> 01:02:23.250
The the biggest friction to me with liquid is that it's a separate chain,
985
01:02:24.244 --> 01:02:28.025
and it's it's that in and out. It's it's moving between
986
01:02:28.325 --> 01:02:31.224
the two chains that is so difficult. So not only
987
01:02:34.710 --> 01:02:36.330
not only do you have the interoperability
988
01:02:37.110 --> 01:02:42.234
benefit for the actual federation, so you could have more federations that can, you know,
989
01:02:43.015 --> 01:02:44.635
work together via lightning.
990
01:02:45.895 --> 01:02:48.395
You also have that benefit of
991
01:02:48.970 --> 01:02:50.190
being able to
992
01:02:50.809 --> 01:02:51.309
directly
993
01:02:51.609 --> 01:02:55.470
operate you know, directly interact with any kind of other,
994
01:02:56.010 --> 01:02:56.910
Lightning Wallet,
995
01:02:57.555 --> 01:03:06.295
including the ton of merchants that are already onboarded onto Lightning. Like, if you go to El Salvador, like, no one accepts Liquid, no one will accept a new Federation token,
996
01:03:06.650 --> 01:03:08.350
but they're already accepting Lightning.
997
01:03:10.490 --> 01:03:14.510
So, like, that's the main advantage to me. Or if you use something like Strike to onboard
998
01:03:15.135 --> 01:03:21.315
and you're going bank account through Stripe, like, you can pay into any Lightning Wallet. If if Eric's
999
01:03:21.775 --> 01:03:22.275
proposal
1000
01:03:23.010 --> 01:03:29.670
rings true, then you could just go straight into that federation. You wouldn't have to deal with any external swap services or any friction like that.
1001
01:03:32.194 --> 01:03:33.635
1002
01:03:35.395 --> 01:03:38.775
we we can't say very much because the lightning part is not
1003
01:03:39.075 --> 01:03:40.135
decided, but
1004
01:03:40.880 --> 01:03:43.779
but it has a kind of a swap thing.
1005
01:03:44.240 --> 01:03:53.565
I think it it's not very different from the thing I said. I was, like, I didn't I never finished that my bridge between liquid and,
1006
01:03:54.105 --> 01:03:55.325
Bitcoin lighting networks.
1007
01:03:55.970 --> 01:04:00.150
Like, something like that could could solve liquid like, could make liquid
1008
01:04:00.530 --> 01:04:01.030
reusable,
1009
01:04:01.810 --> 01:04:03.350
for example. And then I think
1010
01:04:03.865 --> 01:04:09.724
if Eric has federations that have a way to do this, like, they could be usable too.
1011
01:04:10.265 --> 01:04:12.924
And that's his idea. Right? It's just not
1012
01:04:13.310 --> 01:04:14.350
defining what he's going to
1013
01:04:17.390 --> 01:04:18.530
1014
01:04:18.910 --> 01:04:23.385
switch back from the liquid block explorer because that is just depressing as fuck.
1015
01:04:29.600 --> 01:04:31.940
Yeah. No. I mean, that makes sense to me.
1016
01:04:32.800 --> 01:04:36.740
We lost Eric, so now we're just having a conversation about his proposal without him.
1017
01:04:40.655 --> 01:04:46.915
What do you guys wanna cover? You have anything? And we have some more time here. If you you have any lightning hot takes?
1018
01:04:47.700 --> 01:04:53.400
1019
01:04:54.815 --> 01:04:57.075
Moon with 2. Yeah. 2 years. Yeah.
1020
01:04:57.454 --> 01:04:57.954
Yeah.
1021
01:04:58.415 --> 01:05:10.520
And I couldn't get a payment. I think the idea was that you would receive a lightning payment, and it would open a channel to you. Right? When I tried to pay that invoice, I generated it and it never opened a channel
1022
01:05:11.155 --> 01:05:17.495
because I wasn't able to pay the invoice, but the fees were too high. Something like that. All the notes, all the wallets I tried,
1023
01:05:17.795 --> 01:05:21.369
they always said that the fees are too high. So this is
1024
01:05:21.670 --> 01:05:23.529
like I'm just saying this
1025
01:05:23.829 --> 01:05:25.289
to say that this trustless
1026
01:05:25.910 --> 01:05:31.355
open channel and demand thing, it's it's very bad idea for me, at least in my
1027
01:05:32.375 --> 01:05:33.835
1028
01:05:35.335 --> 01:05:42.100
you know, like everyone else in this chat, I mean, besides me, is focused on, you know, trying to make mobile
1029
01:05:42.480 --> 01:05:42.980
UX,
1030
01:05:44.650 --> 01:05:45.150
easy.
1031
01:05:46.945 --> 01:05:50.645
The single best thing they've done is that if you scan any QR code,
1032
01:05:51.585 --> 01:05:52.645
you're able to,
1033
01:05:53.345 --> 01:05:54.085
pay it.
1034
01:05:54.670 --> 01:05:57.330
Whether that's a lightning QR code, whether that's
1035
01:05:57.950 --> 01:05:58.450
SegWit,
1036
01:05:59.150 --> 01:05:59.650
Legacy,
1037
01:06:00.110 --> 01:06:06.065
Taproot address, any QR code you can sign, you should be able to pay it. It registers, and you should be able to pay it.
1038
01:06:08.205 --> 01:06:09.905
The lightning side
1039
01:06:10.630 --> 01:06:12.810
operates on a semi custodial basis,
1040
01:06:17.510 --> 01:06:19.610
that that is settled on chain
1041
01:06:20.855 --> 01:06:23.974
relatively quickly after the fact. Now I'm pretty sure
1042
01:06:24.615 --> 01:06:32.710
1043
01:06:33.250 --> 01:06:34.390
1044
01:06:34.770 --> 01:06:35.270
and,
1045
01:06:36.665 --> 01:06:42.365
they're using swaps, and the overwhelming majority of your funds are actually kept in a 2 of 2 multisig on chain,
1046
01:06:43.225 --> 01:06:45.165
and they're using on demand swaps.
1047
01:06:46.870 --> 01:06:51.290
Now I think their biggest issue is something we're gonna see in the lightning space a lot,
1048
01:06:51.750 --> 01:06:53.130
where it is so
1049
01:06:55.585 --> 01:07:02.405
it it is it is easy to use, so it's recommended often. And with the with El Salvador and with this, you know,
1050
01:07:02.730 --> 01:07:08.260
more people using mobile lightning wallets, their liquidity is just completely wrecked. Like, I they just do not have,
1051
01:07:10.325 --> 01:07:11.705
they do not have good liquidity.
1052
01:07:12.325 --> 01:07:16.105
I've noticed there many times trying to receive lightning on moon.
1053
01:07:17.970 --> 01:07:21.589
It's definitely a a massive pain point. And I also don't know
1054
01:07:21.890 --> 01:07:22.369
how they're
1055
01:07:23.490 --> 01:07:30.545
if everything's supposed to settle on chain, like, that does not scale if we actually have sustained high fees on chain.
1056
01:07:31.565 --> 01:07:32.065
So
1057
01:07:32.685 --> 01:07:33.825
that's a whole different.
1058
01:07:34.260 --> 01:07:35.860
1059
01:07:36.660 --> 01:07:44.984
I thought it was opening channels. I think their the the v one was with Yeah. It's also news to me. I saw they had some kind of channel somewhere.
1060
01:07:45.525 --> 01:07:50.265
I mean, on user side. I knew I knew the v one was based on on swaps.
1061
01:07:50.830 --> 01:07:55.730
I didn't know about this multi 6. But then I listened to some podcasts whether the
1062
01:07:56.350 --> 01:07:58.370
Dario, the the guy from
1063
01:07:58.895 --> 01:08:00.755
said that he had that V2 that had
1064
01:08:01.375 --> 01:08:03.635
a variant of l and d running on the phone.
1065
01:08:03.935 --> 01:08:05.954
So it's So maybe I'm wrong.
1066
01:08:06.390 --> 01:08:08.570
1067
01:08:09.110 --> 01:08:10.170
But either way,
1068
01:08:10.550 --> 01:08:12.490
I've used Moon, and the liquidity
1069
01:08:13.030 --> 01:08:14.730
is a fucking mess.
1070
01:08:15.935 --> 01:08:17.795
1071
01:08:18.255 --> 01:08:19.795
The biggest one, I'd say.
1072
01:08:20.255 --> 01:08:23.795
U x u x x issues does not come close to this.
1073
01:08:24.790 --> 01:08:28.010
I'd say liquidity is the one we should solve somehow.
1074
01:08:29.989 --> 01:08:34.615
1075
01:08:36.535 --> 01:08:37.035
1076
01:08:37.815 --> 01:08:41.995
We are yet to determine this, I guess. Like, the cool part
1077
01:08:42.340 --> 01:08:49.000
1078
01:08:50.344 --> 01:08:52.364
but the trade off of that is
1079
01:08:53.225 --> 01:08:57.965
that liquidity is divide I guess, like, multipar payments and stuff like that could Mhmm.
1080
01:08:58.350 --> 01:09:00.530
Help mitigate it. Right? But you're still
1081
01:09:00.830 --> 01:09:02.990
mitigating something. It's still a inherent
1082
01:09:03.710 --> 01:09:04.210
1083
01:09:05.875 --> 01:09:13.410
My hope is that hosted channels and private routing will address this at at least to some extent, if not solve it.
1084
01:09:13.890 --> 01:09:16.390
1085
01:09:16.850 --> 01:09:17.350
1086
01:09:17.650 --> 01:09:24.235
1087
01:09:24.615 --> 01:09:25.835
Okay. It's a good name.
1088
01:09:27.255 --> 01:09:34.080
So how far away are we from that? Like, I thought you can't route over private channels because they're not publicly broadcast in the gossip network.
1089
01:09:35.535 --> 01:09:40.835
1090
01:09:41.455 --> 01:09:41.955
So,
1091
01:09:43.230 --> 01:09:51.410
let's start from basics probably. There are 2 kinds of channels on lightning, public ones and private ones. Or
1092
01:09:51.845 --> 01:09:57.065
another name for private ones is unannounced channels. That's basically the only difference,
1093
01:09:58.165 --> 01:10:00.105
between them and public channels.
1094
01:10:01.250 --> 01:10:02.710
Public channels exist
1095
01:10:03.330 --> 01:10:10.390
in routing graph, and, they are visible by everyone who has the graph on their devices. And as such,
1096
01:10:10.915 --> 01:10:13.574
everyone can use these channels to route payments.
1097
01:10:14.275 --> 01:10:15.895
And the private channels,
1098
01:10:16.835 --> 01:10:18.295
they just don't do that.
1099
01:10:18.830 --> 01:10:21.889
And, the reason they don't do that is because
1100
01:10:22.270 --> 01:10:27.489
private channels are typically opened to mobile devices, which are mostly offline.
1101
01:10:28.125 --> 01:10:31.905
So even if they were to broadcast themselves to graph,
1102
01:10:33.405 --> 01:10:35.585
it would make very little sense because
1103
01:10:36.310 --> 01:10:42.170
most of the times, they would be unusable because the device is offline with the way mobile devices are used.
1104
01:10:42.710 --> 01:10:44.489
And, another problem
1105
01:10:45.125 --> 01:10:53.864
with that would be scalability. That is if we ever to get millions of phones with private channels, if they all were to broadcast
1106
01:10:55.440 --> 01:11:03.140
their info to routing graph, they would just, I guess, either bring it down or make other nodes prude them prune them.
1107
01:11:04.135 --> 01:11:04.614
So,
1108
01:11:05.094 --> 01:11:06.155
up until recently,
1109
01:11:06.775 --> 01:11:07.675
routing routing
1110
01:11:09.335 --> 01:11:11.835
through mobile channels was completely invisible.
1111
01:11:12.770 --> 01:11:13.270
But,
1112
01:11:14.050 --> 01:11:16.389
since the introduction of private routing,
1113
01:11:16.690 --> 01:11:18.070
it actually became
1114
01:11:18.449 --> 01:11:18.949
possible
1115
01:11:19.250 --> 01:11:21.750
to route through private channels exactly
1116
01:11:22.594 --> 01:11:28.534
when mobile device is online, even if it's something like 5 minutes per day, still possible,
1117
01:11:29.074 --> 01:11:29.574
and
1118
01:11:30.599 --> 01:11:32.460
without them becoming public.
1119
01:11:33.079 --> 01:11:33.579
So
1120
01:11:34.360 --> 01:11:35.420
I think this
1121
01:11:36.360 --> 01:11:38.380
is very interesting area. It,
1122
01:11:39.585 --> 01:11:42.245
once implemented, private routing will unlock
1123
01:11:43.985 --> 01:11:47.880
this routing liquidity of all those private channels, which was inaccessible
1124
01:11:48.580 --> 01:11:49.480
earlier. And,
1125
01:11:49.860 --> 01:11:50.440
of course,
1126
01:11:50.820 --> 01:11:53.700
this is another way to increase liquidity on network and,
1127
01:11:54.180 --> 01:11:56.945
increase increase the number of successful payments.
1128
01:11:57.644 --> 01:11:58.144
So
1129
01:11:58.684 --> 01:12:05.950
I'm looking forward to that. I'm working on that currently, finalizing this. And, this is expected to happen this year, hopefully,
1130
01:12:06.810 --> 01:12:07.550
in simple.
1131
01:12:09.130 --> 01:12:10.730
1132
01:12:11.690 --> 01:12:18.875
like, the private channel routing should be that you don't know that they exist. Isn't that that? So how do you solve the problem of,
1133
01:12:19.335 --> 01:12:23.260
1134
01:12:24.619 --> 01:12:25.760
Yeah. Once the,
1135
01:12:26.380 --> 01:12:26.880
wallet
1136
01:12:27.260 --> 01:12:43.560
with such private channels becomes online, it would send a special message to all of all of its peer who support private route and that it can private route. It would basically be basically be saying to each peers that I am now online, and I can route
1137
01:12:44.180 --> 01:12:45.000
this amount.
1138
01:12:46.100 --> 01:12:47.480
That's it. And
1139
01:12:48.785 --> 01:12:56.085
peers can use it themselves, and they can further relay this message, maybe 2 or 3 hopes further to inform
1140
01:12:56.889 --> 01:12:58.909
their own peers that there exists
1141
01:12:59.530 --> 01:13:06.485
private router right now, right here. And all of them would have this knowledge and will be able to use it.
1142
01:13:06.945 --> 01:13:07.844
That's the plan.
1143
01:13:08.864 --> 01:13:09.364
1144
01:13:10.305 --> 01:13:16.739
that would make these channels, much less private in nature, which might be okay depending on usage. It doesn't because,
1145
01:13:17.600 --> 01:13:20.659
1146
01:13:21.440 --> 01:13:24.775
like, thanks to trampoline routing. They will be basically
1147
01:13:25.235 --> 01:13:39.580
saying yeah. They will be saying I can route this amount, but they won't be saying in how. They won't be disclosing how many channels they have. They could have, like, hosted private channels and use it for routing or something
1148
01:13:40.075 --> 01:13:41.695
entirely wild then. No.
1149
01:13:42.715 --> 01:13:46.415
Something like Telegram group where they exchange 3 majors or something.
1150
01:13:48.235 --> 01:13:49.760
But yeah. So
1151
01:13:50.700 --> 01:13:52.160
1152
01:13:52.780 --> 01:13:54.320
suppose I have a a node
1153
01:13:54.700 --> 01:13:56.960
that has a simple Bitcoin wallet,
1154
01:13:57.580 --> 01:14:07.025
connected to it through a to a normal channel or a hosted channel. Mhmm. And and that same simple Bitcoin wallet is also connected to someone else's node.
1155
01:14:07.325 --> 01:14:07.825
1156
01:14:08.300 --> 01:14:09.360
And then I guess
1157
01:14:10.060 --> 01:14:15.120
1158
01:14:16.045 --> 01:14:25.020
and my node is about to make a payment. And so it uses it sends the payment to that simple Bitcoin wallet. Yeah. That simple Bitcoin wallet forwards it to the other node.
1159
01:14:25.500 --> 01:14:28.960
1160
01:14:30.220 --> 01:14:33.920
trampoline, this trampoline router, whatever is cheaper or more preferable.
1161
01:14:34.605 --> 01:14:35.985
Something like that. Yes.
1162
01:14:38.045 --> 01:14:42.225
1163
01:14:42.730 --> 01:14:43.230
Mhmm.
1164
01:14:43.530 --> 01:14:51.050
I can send a message to that peer saying, oh, I have a private channel here and an announcement channel here that's A private router. Let's say
1165
01:14:51.635 --> 01:14:52.455
Yeah. This
1166
01:14:52.795 --> 01:14:53.295
way.
1167
01:14:53.635 --> 01:15:04.900
1168
01:15:06.480 --> 01:15:11.515
1169
01:15:12.135 --> 01:15:14.315
as a user, I might be balancing
1170
01:15:14.935 --> 01:15:28.429
my funds really cautiously between different host channel provider because I might not trust any of them fully, and I'm prepared to lose any of these channels. So if I now enable routing between them, then that could, essentially
1171
01:15:29.065 --> 01:15:29.565
distort,
1172
01:15:30.265 --> 01:15:31.005
the distribution.
1173
01:15:32.665 --> 01:15:38.270
1174
01:15:39.070 --> 01:15:44.370
an amount. That's the amount that you're willing to lose. But I think this also works, this private routing,
1175
01:15:44.750 --> 01:15:48.050
with just normal channels. No no hosted channels involved. Right?
1176
01:15:50.075 --> 01:15:50.575
Right?
1177
01:15:54.075 --> 01:15:54.575
1178
01:15:55.440 --> 01:15:55.940
Well,
1179
01:15:56.719 --> 01:16:03.460
I can say that, yes, was using private channel for payments or for routing is always a risk, but, like,
1180
01:16:04.525 --> 01:16:10.465
I guess we're all grown ups here, so we can manage our risks. We cannot use them if we don't want to
1181
01:16:11.405 --> 01:16:12.145
or otherwise.
1182
01:16:13.490 --> 01:16:19.510
1183
01:16:21.225 --> 01:16:22.845
1184
01:16:25.545 --> 01:16:28.125
1185
01:16:29.160 --> 01:16:30.380
1186
01:16:30.920 --> 01:16:33.420
like, I had while you talked about
1187
01:16:33.720 --> 01:16:35.820
it. Did you do any research
1188
01:16:36.175 --> 01:16:41.635
how much it would increase the liquidity on Lightning or how much it would actually benefit? Because
1189
01:16:42.095 --> 01:16:45.475
I did some probing back in 2019, so it's a long time ago.
1190
01:16:46.180 --> 01:16:59.495
But it appeared that the user channels actually made up not that much of capacity. Like, they were pretty small in general, and then there was a big core network, with much bigger channels and a larger routing capacity.
1191
01:17:00.115 --> 01:17:01.575
So I could imagine that
1192
01:17:02.210 --> 01:17:02.710
enabling
1193
01:17:03.170 --> 01:17:16.664
these user channels from time to time only, like, that actually doesn't do a lot of good for quite some implementation complexity and quite some traffic because every time now that someone comes online or goes offline, you need to send messages and stuff like that.
1194
01:17:17.844 --> 01:17:19.545
1195
01:17:20.244 --> 01:17:21.940
or or something like that, and
1196
01:17:23.760 --> 01:17:29.540
I don't have anything definite to say on this. This is, yeah, kinda an uncharted territory.
1197
01:17:29.885 --> 01:17:35.745
And they say, I think I should, like, run this and see how it goes. That's the plan.
1198
01:17:36.205 --> 01:17:39.425
And then I would be able to say something more concrete
1199
01:17:39.760 --> 01:17:40.980
after some time
1200
01:17:41.520 --> 01:17:43.300
of it's being on.
1201
01:17:45.520 --> 01:17:49.265
1202
01:17:50.065 --> 01:18:00.630
the understanding I had before was that it would be good to have this private routing. So, for example, Breeze, the Breeze node opens channels to to a bunch of mobile wallets,
1203
01:18:01.010 --> 01:18:01.670
and they'll
1204
01:18:01.970 --> 01:18:06.070
it locks liquidity there that's, like, lost forever or
1205
01:18:06.370 --> 01:18:10.195
for a long time. And with this, like, the this can
1206
01:18:11.215 --> 01:18:18.480
1207
01:18:19.040 --> 01:18:19.540
tiers.
1208
01:18:20.480 --> 01:18:22.420
1209
01:18:24.804 --> 01:18:26.344
many Lightning devs
1210
01:18:26.965 --> 01:18:28.485
say that the
1211
01:18:30.005 --> 01:18:33.925
and I know I know not all Lightning devs agree, especially the ones that I have,
1212
01:18:34.550 --> 01:18:35.370
in this conversation right now.
1213
01:18:36.150 --> 01:18:44.575
I've heard many Lightning devs say the expectation in the future is that most end users will have a single balanced channel
1214
01:18:45.275 --> 01:18:47.295
with, like, a well connected routing node.
1215
01:18:47.835 --> 01:18:48.895
Do you guys not
1216
01:18:49.290 --> 01:18:57.150
believe that's the expectation, that's not what we should expect? Because, I mean, if that's the case, then they're not gonna be really providing any,
1217
01:18:58.345 --> 01:19:02.445
helpful liquidity there if they're just they're just like an endpoint almost.
1218
01:19:02.745 --> 01:19:05.885
1219
01:19:06.310 --> 01:19:07.850
They need to have at least 2.
1220
01:19:08.790 --> 01:19:09.430
Well, it's,
1221
01:19:09.910 --> 01:19:11.530
it's a hard question because,
1222
01:19:12.630 --> 01:19:14.330
in order to pull this
1223
01:19:16.475 --> 01:19:23.855
on the provider side, they really need to have a lot a lot of money to afford to open a private channel to everyone.
1224
01:19:24.400 --> 01:19:29.620
And then a lot of that liquidity that they put in this channel would be lost because
1225
01:19:30.160 --> 01:19:32.900
many of these channels would be offline for,
1226
01:19:34.085 --> 01:19:35.465
long periods of time.
1227
01:19:36.245 --> 01:19:36.745
So
1228
01:19:37.765 --> 01:19:38.425
it's really
1229
01:19:38.725 --> 01:19:42.425
a hard feat, I'd say, to prove off to make this all profitable.
1230
01:19:43.190 --> 01:19:43.690
So
1231
01:19:44.630 --> 01:19:45.449
my understanding
1232
01:19:45.750 --> 01:19:52.705
that is that routing is essential to lightnings. Whenever you have a channel, you need to be able to route from it somehow.
1233
01:19:53.405 --> 01:19:53.905
And,
1234
01:19:54.285 --> 01:19:56.385
otherwise, it's just broken design.
1235
01:19:57.565 --> 01:19:59.425
Maybe I'm wrong, but time will tell.
1236
01:20:00.350 --> 01:20:04.425
1237
01:20:05.355 --> 01:20:09.430
Wrong. Okay. And in my opinion,
1238
01:20:10.205 --> 01:20:12.465
like, the people that have just one channel,
1239
01:20:13.085 --> 01:20:16.785
today, like, they probably won't have a channel at all in the future because,
1240
01:20:17.245 --> 01:20:18.670
they are typically just,
1241
01:20:19.150 --> 01:20:21.890
end users that don't have too much money in Lightning.
1242
01:20:22.510 --> 01:20:25.489
So even as a Bitcoin, like, if you can have
1243
01:20:25.949 --> 01:20:26.449
an
1244
01:20:27.695 --> 01:20:41.030
your your lightning funds essentially that today you have in this, weird one channel that might go offline if your counterparty goes offline. So it's not really that that great for you. But you could put it into a federation, let's say, in the Ecash Federation. And
1245
01:20:41.570 --> 01:20:42.630
that would give you
1246
01:20:43.489 --> 01:20:44.390
close enough,
1247
01:20:45.985 --> 01:20:47.485
like, nearly the same
1248
01:20:47.785 --> 01:20:48.285
functionality
1249
01:20:48.985 --> 01:20:51.165
as for if you're one big channel today.
1250
01:20:52.025 --> 01:20:52.525
And,
1251
01:20:53.100 --> 01:20:58.540
like, the funds that you really want to keep for saving, that you keep on train anyway. Like, that,
1252
01:20:59.020 --> 01:21:04.955
it's not something you would keep on your mobile phone wallet, in this one big channel because you might lose it.
1253
01:21:06.295 --> 01:21:07.435
So I see these
1254
01:21:07.975 --> 01:21:12.600
end user notes with only one channel disappear. Like, you will either be a routing node,
1255
01:21:13.700 --> 01:21:15.320
even if it's just the raspberry
1256
01:21:16.340 --> 01:21:18.515
even if it's just the raspberry pi at home.
1257
01:21:21.155 --> 01:21:22.455
1258
01:21:25.235 --> 01:21:26.775
I'd actually agree with it.
1259
01:21:27.260 --> 01:21:33.600
Either you are routing node of some kind, private routing node, public routing node, or probably it would be
1260
01:21:34.035 --> 01:21:35.895
a custodial user of some kind.
1261
01:21:36.595 --> 01:21:39.335
1262
01:21:39.875 --> 01:21:42.410
Like, just imagine we are onboarding the next,
1263
01:21:42.970 --> 01:21:44.970
like, 6, 6,000,000,000 users.
1264
01:21:46.650 --> 01:21:53.595
Like, not all of them are the technical that they are actually able to run a note. Not all of them have the funds to run their own note.
1265
01:21:55.335 --> 01:22:03.040
So I imagine, like, if you have your local community of, let's say, 100 or 1000 people, then there will be maybe 4 or
1266
01:22:03.340 --> 01:22:07.235
7 of them that are technical enough that, Bitcoiners today even.
1267
01:22:07.855 --> 01:22:08.994
And they will still
1268
01:22:09.375 --> 01:22:11.375
be self custodying. They will,
1269
01:22:12.790 --> 01:22:17.690
like, doing all using all the right cypherpunk tools, that we are building today.
1270
01:22:18.389 --> 01:22:20.969
But in addition to that, they will also be providing
1271
01:22:21.595 --> 01:22:33.370
the service for their local community that all these other people can access lightning, for example, or federations, or they could be hosted channel service providers depending on what, success succeeds in the market.
1272
01:22:34.150 --> 01:22:34.650
So,
1273
01:22:35.510 --> 01:22:37.690
yeah, I see these mobile wallets
1274
01:22:40.005 --> 01:22:42.665
with actual lightning channels disappearing because
1275
01:22:43.364 --> 01:22:45.705
it just doesn't make any sense to lock funds
1276
01:22:46.050 --> 01:22:51.270
in a wallet that is only online from time to time. Like, it's not good use of capital.
1277
01:22:53.865 --> 01:22:57.485
1278
01:22:58.665 --> 01:22:59.565
the the way,
1279
01:23:00.105 --> 01:23:00.605
Esync
1280
01:23:01.065 --> 01:23:04.770
and Breeze are planning to make money on their
1281
01:23:06.350 --> 01:23:07.489
their channels on demand
1282
01:23:07.870 --> 01:23:13.665
1283
01:23:15.324 --> 01:23:17.905
1284
01:23:18.285 --> 01:23:18.710
What?
1285
01:23:19.590 --> 01:23:20.489
1286
01:23:21.030 --> 01:23:27.530
the idea is that there will be so many payments that they will be making some money on rooting, I guess.
1287
01:23:28.375 --> 01:23:29.435
Something like that.
1288
01:23:30.614 --> 01:23:38.420
1289
01:23:38.880 --> 01:23:42.660
go into that business, but there's some data monetization that you can do there.
1290
01:23:44.465 --> 01:23:46.304
1291
01:23:46.705 --> 01:23:50.885
that opening all these channels allows you as a company allows them as a company
1292
01:23:51.264 --> 01:23:54.370
to buy a lot of Bitcoin, and that will be enough in the future.
1293
01:23:56.270 --> 01:24:02.825
1294
01:24:04.245 --> 01:24:06.425
Well, hopefully, that works out for them. I,
1295
01:24:09.210 --> 01:24:13.950
do you guys know was so, I mean, Eric, I assume, like so what you expect
1296
01:24:14.825 --> 01:24:19.965
is instead of users having this single channel open is they're gonna have, you know, some kind of
1297
01:24:20.425 --> 01:24:21.965
semi custodial relationship,
1298
01:24:23.180 --> 01:24:25.840
whether that's through your proposal or hosted channels
1299
01:24:26.460 --> 01:24:28.720
or community wallets or something like that.
1300
01:24:29.180 --> 01:24:31.920
1301
01:24:32.495 --> 01:24:33.715
option kind of,
1302
01:24:34.335 --> 01:24:38.114
like, channel factories, it's called. It's even more researchy than what I'm doing.
1303
01:24:38.415 --> 01:24:42.630
I think that's maybe in 10 years. I don't know. Maybe I'm wrong on that.
1304
01:24:43.250 --> 01:24:46.310
But where multiple people could come together and run,
1305
01:24:46.770 --> 01:24:48.630
like, one lightning note together
1306
01:24:48.995 --> 01:24:51.495
and share channels and stuff like that, which is also
1307
01:24:51.875 --> 01:24:55.255
pretty cool in my opinion. But, yeah, either you,
1308
01:24:56.250 --> 01:24:58.830
like, are actually routing, have multiple channels,
1309
01:24:59.610 --> 01:25:00.410
or you,
1310
01:25:00.890 --> 01:25:04.185
are using such a note from someone else. Like, there's,
1311
01:25:04.965 --> 01:25:17.210
like, no way in my opinion that, some people will be willing to lock up funds for you, just so you can use them as a routing notes. You have to contribute something too by routing.
1312
01:25:17.590 --> 01:25:22.025
So I actually agree with Anton on that. Yeah. Just to go back I think
1313
01:25:22.325 --> 01:25:24.105
1314
01:25:25.205 --> 01:25:28.345
Just to go back, first of all, that Moon conversation, I'm 99%
1315
01:25:28.725 --> 01:25:39.025
sure that Moon, their v two implementation hasn't released yet, and they're still doing swaps, but their intention is to run some kind of mobile lightning client. Maybe they'll choose a Morden. That could be interesting.
1316
01:25:41.565 --> 01:25:47.480
But I'm pretty sure v two isn't out yet. You guys know how do any of you guys know how Bitcoin Beach Wallet works?
1317
01:25:48.739 --> 01:25:51.400
1318
01:25:52.405 --> 01:25:53.925
1319
01:25:54.245 --> 01:25:55.605
the lightning note is,
1320
01:25:56.405 --> 01:26:02.060
fully custodial, but it only holds, like, a small percentage of the funds. I think I heard something like 5%,
1321
01:26:02.920 --> 01:26:08.140
while the majority of funds are held on chain in the multisig wallet. So it's actually
1322
01:26:08.605 --> 01:26:09.985
even closer to,
1323
01:26:10.685 --> 01:26:12.065
like, Federated Ecash
1324
01:26:12.605 --> 01:26:17.185
than hosted channels kind of because the most of the funds are held in the Federated,
1325
01:26:17.725 --> 01:26:19.250
way, just manually.
1326
01:26:21.470 --> 01:26:24.610
1327
01:26:24.990 --> 01:26:31.605
of your proposal going. Right? Where you just have, like, a small portion held in a custodial lightning wallet and the majority is held in the federation.
1328
01:26:32.385 --> 01:26:33.205
1329
01:26:33.985 --> 01:26:37.490
Well, that's the I think the the the multi sig part is like
1330
01:26:38.450 --> 01:26:38.950
sorry.
1331
01:26:39.330 --> 01:26:40.070
1332
01:26:40.370 --> 01:26:48.835
1333
01:26:49.775 --> 01:26:51.235
most of the the
1334
01:26:51.695 --> 01:26:55.489
the funds that the balance of users are on the Lightning node,
1335
01:26:55.869 --> 01:26:57.170
but, like, I could
1336
01:26:57.550 --> 01:26:58.929
close some channels and
1337
01:26:59.309 --> 01:27:03.635
make a multi multi sig on chain wallet and and and say my
1338
01:27:04.095 --> 01:27:05.715
the analytics part is partly
1339
01:27:06.175 --> 01:27:06.755
a federation.
1340
01:27:07.695 --> 01:27:12.110
But that I I don't think that changes the the nature of the custodianship. Like,
1341
01:27:12.489 --> 01:27:12.989
the
1342
01:27:13.370 --> 01:27:16.110
the Bitcoin Beach is, like, is a server with
1343
01:27:16.410 --> 01:27:17.150
an API,
1344
01:27:17.715 --> 01:27:24.455
HTTP API that the wallet stopped you, like, the normal custodial thing. But they have this this idea of,
1345
01:27:25.710 --> 01:27:28.610
local communities each running their own server, which is
1346
01:27:28.989 --> 01:27:33.889
not not an uncommon model. Like, Allen Beats also has the same idea.
1347
01:27:34.685 --> 01:27:38.305
And I think hosted channels is, like, an an evolution of that.
1348
01:27:39.485 --> 01:27:40.625
1349
01:27:41.165 --> 01:27:48.219
they could they could mix host of channels with that relatively easily. Right? Like, the custodial lightning wallet could be using hosted channels,
1350
01:27:49.239 --> 01:27:52.915
and then they can have the majority of funds held on chain in multisig.
1351
01:27:54.094 --> 01:28:00.114
1352
01:28:01.670 --> 01:28:02.969
1353
01:28:03.429 --> 01:28:10.215
1354
01:28:10.675 --> 01:28:15.895
chain, on chain wallet would probably have been a good idea, like, given the recent tech.
1355
01:28:16.330 --> 01:28:19.710
Like, that's exactly one thing you are guarding against with that.
1356
01:28:20.330 --> 01:28:25.950
Yeah. Yeah. And I agree. Like, even to a bigger degree if, you had the Allen Bits community
1357
01:28:26.554 --> 01:28:28.415
where you have a 2 or 3 multisig.
1358
01:28:29.114 --> 01:28:35.550
And this community has to decide when to replenish your funds in your writing note. And I agree it would be a lot of work,
1359
01:28:36.270 --> 01:28:39.650
then you wouldn't be the single point of failure anymore, kind of.
1360
01:28:42.085 --> 01:28:47.065
Or maybe you still would be because the ledger of the account balances would still be in your hand.
1361
01:28:47.685 --> 01:28:48.185
1362
01:28:49.130 --> 01:28:51.310
1363
01:28:51.690 --> 01:28:57.215
combining that with hosted channels so you get actual proof of, how much you own, that would be cool.
1364
01:28:57.594 --> 01:29:00.255
1365
01:29:01.675 --> 01:29:02.574
1366
01:29:03.630 --> 01:29:06.530
That's why I'm building my stuff not on Telegram.
1367
01:29:10.765 --> 01:29:13.325
Yeah. But, one thing I wanted to ask,
1368
01:29:13.725 --> 01:29:14.225
Anton,
1369
01:29:15.005 --> 01:29:16.305
before we end this,
1370
01:29:17.085 --> 01:29:20.760
like, I got some feedback from people that if we wanted to do
1371
01:29:21.300 --> 01:29:27.305
e cache sooner than my federated e cache proposal, why not just combine it with hosted channels? Like,
1372
01:29:27.865 --> 01:29:29.245
you could probably integrate,
1373
01:29:30.425 --> 01:29:35.805
e cache with hosted channels in a way that, you don't know users' balance anymore. Like,
1374
01:29:36.580 --> 01:29:39.240
I guess, from the our conversation we had already,
1375
01:29:39.780 --> 01:29:50.785
the problem is that you can't get, the proof of payment and stuff like that because, e cash behaves so differently from a lightning channel. But in principle, you could still do,
1376
01:29:52.119 --> 01:29:54.940
the payments and routing stuff. Like, for example,
1377
01:29:55.320 --> 01:30:00.219
if someone wants to pay an you to pay an invoice for them, they generate the routing
1378
01:30:00.875 --> 01:30:02.735
information or generate the onion,
1379
01:30:03.115 --> 01:30:07.695
give it, to the host of channel provider, also give the e cache to the host of channel provider.
1380
01:30:08.230 --> 01:30:12.250
And the host of channel provider knows because of the e cache that they should,
1381
01:30:12.710 --> 01:30:14.970
forward the onion message, during the payment.
1382
01:30:17.355 --> 01:30:20.655
1383
01:30:22.075 --> 01:30:28.940
1384
01:30:29.480 --> 01:30:33.179
Like, when you look at the Rabi Sabi paper, they have a great
1385
01:30:35.145 --> 01:30:36.765
a great cryptographic protocol
1386
01:30:37.065 --> 01:30:43.550
they use that even allows arbitrary amounts to be encoded in the ecash tokens. So you don't need multiple of them
1387
01:30:43.869 --> 01:30:48.130
necessarily, but you can have, Ecash tokens for arbitrary amounts that are still anonymous.
1388
01:30:50.270 --> 01:30:58.910
So maybe that is a interesting thing to look at, for you because you could probably have a working prototype much sooner than me because it's,
1389
01:30:59.310 --> 01:31:02.530
like, much easier to build it in a centralized way than federated.
1390
01:31:06.035 --> 01:31:12.215
1391
01:31:12.750 --> 01:31:16.369
Although it's in production already, it's not completely ready.
1392
01:31:16.750 --> 01:31:20.050
There is still some work to do, so first things first.
1393
01:31:21.575 --> 01:31:22.875
1394
01:31:23.335 --> 01:31:24.955
I would love if you guys collaborated.
1395
01:31:27.815 --> 01:31:32.820
1396
01:31:33.120 --> 01:31:34.100
using e cache.
1397
01:31:38.455 --> 01:31:40.395
1398
01:31:40.775 --> 01:31:41.995
there will not be
1399
01:31:42.614 --> 01:31:43.675
a true corporation
1400
01:31:43.975 --> 01:31:46.150
because it's possible for, like,
1401
01:31:46.469 --> 01:31:47.449
2 geniuses
1402
01:31:48.390 --> 01:31:49.530
programming together.
1403
01:31:50.710 --> 01:31:52.170
It's better if each one
1404
01:31:52.630 --> 01:31:53.850
does its own thing.
1405
01:31:54.345 --> 01:31:59.725
1406
01:32:02.640 --> 01:32:07.140
1407
01:32:07.760 --> 01:32:08.260
talk
1408
01:32:08.560 --> 01:32:11.605
voice to voice than on Twitter screaming at each other.
1409
01:32:12.645 --> 01:32:13.545
And in the end,
1410
01:32:14.325 --> 01:32:17.465
like, we agree on a lot of stuff. Just in the details,
1411
01:32:18.005 --> 01:32:18.745
we have
1412
01:32:19.510 --> 01:32:21.850
very strongly held opinions that differ.
1413
01:32:22.790 --> 01:32:24.410
1414
01:32:25.350 --> 01:32:29.954
We have we have 2 questions in the chat. The first question,
1415
01:32:32.574 --> 01:32:34.114
is asking about Blockstream's
1416
01:32:34.415 --> 01:32:35.315
peer swap
1417
01:32:35.650 --> 01:32:37.190
lightning balancing protocol.
1418
01:32:38.370 --> 01:32:39.670
I think this was released
1419
01:32:40.050 --> 01:32:41.110
8 days ago
1420
01:32:41.730 --> 01:32:43.030
at in El Salvador.
1421
01:32:43.375 --> 01:32:46.275
Are any of you guys familiar with this protocol at all?
1422
01:32:48.735 --> 01:32:50.114
1423
01:32:51.400 --> 01:32:51.900
1424
01:32:52.440 --> 01:32:55.660
I I talked a bit, after we caught, with Constantine,
1425
01:32:56.600 --> 01:32:59.580
who seems to be the lead developer behind us.
1426
01:33:01.304 --> 01:33:06.364
And the question is if we can integrate it with Federated ECash somehow
1427
01:33:06.665 --> 01:33:07.625
or that you could,
1428
01:33:08.105 --> 01:33:10.445
swap balances in and out of ECash.
1429
01:33:11.930 --> 01:33:12.430
And
1430
01:33:12.970 --> 01:33:14.670
I think, technically, that's possible.
1431
01:33:15.610 --> 01:33:16.810
The question is,
1432
01:33:17.450 --> 01:33:18.110
like, since
1433
01:33:18.915 --> 01:33:21.735
e cache these e cache evaluations are meant to be,
1434
01:33:22.994 --> 01:33:31.170
that they're meant to be many of them with different, trust assumptions because there are different people involved. Like, can you actually find one with the
1435
01:33:31.650 --> 01:33:35.270
your peer you want to swap with, that you both agree on trusting?
1436
01:33:37.155 --> 01:33:37.795
Because otherwise,
1437
01:33:38.595 --> 01:33:39.895
if you can't, then
1438
01:33:40.355 --> 01:33:43.975
for inter federation payments, you need lightning anyway, and you would
1439
01:33:44.449 --> 01:33:50.230
unbalance lightning channel in that way. And that would kind of destroy the whole point behind PierceRock,
1440
01:33:50.610 --> 01:33:51.989
which is that you only
1441
01:33:52.965 --> 01:33:54.985
rebalanced channels with direct peers
1442
01:33:55.605 --> 01:34:00.344
or with, peers only one hop away in that sense that all involved parties
1443
01:34:01.409 --> 01:34:02.710
actually want to do this.
1444
01:34:03.650 --> 01:34:06.949
Like, you are not, unbalancing someone else's channel.
1445
01:34:08.745 --> 01:34:11.005
So I think it's an interesting idea, but,
1446
01:34:12.025 --> 01:34:14.685
complicated in in practice, I guess.
1447
01:34:17.750 --> 01:34:18.570
1448
01:34:19.270 --> 01:34:21.530
I have not looked into it personally yet.
1449
01:34:24.325 --> 01:34:27.945
It would be nice if it is easier to balance channels and to,
1450
01:34:29.685 --> 01:34:32.265
have some kind of more distributed marketplace
1451
01:34:32.725 --> 01:34:33.225
than
1452
01:34:35.190 --> 01:34:36.730
Lightning Labs' pool.
1453
01:34:38.790 --> 01:34:42.570
Someone else asked a relatively similar similar question.
1454
01:34:43.195 --> 01:34:51.215
Do you think something like a lease pool that node operators participate in would be appropriate to cover the costs of opening individual private channels?
1455
01:34:51.915 --> 01:34:54.550
And I I'll just jump in here. I mean,
1456
01:34:55.250 --> 01:34:56.630
I know this is Breeze's,
1457
01:34:58.530 --> 01:35:02.070
Breeze has has has spoke about this. Breeze with 2 e's
1458
01:35:02.435 --> 01:35:03.095
and a
1459
01:35:03.515 --> 01:35:04.015
z.
1460
01:35:04.515 --> 01:35:07.095
I have fucking naming schemes of these Bitcoin wallets.
1461
01:35:08.115 --> 01:35:12.770
Breeze has talked about this. I mean, the biggest issue is, to me, is UX friction.
1462
01:35:13.390 --> 01:35:16.210
It's like, if a new user needs to pay somebody
1463
01:35:17.470 --> 01:35:19.970
on lightning to be able to receive on lightning,
1464
01:35:21.925 --> 01:35:25.545
it's not necessarily the easiest thing to do from a UX perspective.
1465
01:35:26.644 --> 01:35:27.545
It's not intuitive.
1466
01:35:28.790 --> 01:35:30.730
That seems to be the biggest
1467
01:35:31.110 --> 01:35:34.090
hurdle with this type of stuff. What what do you guys think?
1468
01:35:35.954 --> 01:35:37.255
1469
01:35:38.275 --> 01:35:41.394
1470
01:35:41.875 --> 01:35:43.655
do you make this channel you open,
1471
01:35:44.150 --> 01:35:46.170
when you want to receive your first payment?
1472
01:35:46.710 --> 01:35:55.655
Like, if if it's too big, you pay way too much in fees. If it's too small, then at some later point, you will have to pay again. And how do you
1473
01:35:56.195 --> 01:35:57.815
teach a user that
1474
01:35:58.355 --> 01:35:59.575
at some sometimes,
1475
01:35:59.955 --> 01:36:01.810
randomly, basically for them,
1476
01:36:02.290 --> 01:36:05.510
they need to pay more in transaction fees. That's totally unintuitive.
1477
01:36:05.890 --> 01:36:06.950
1478
01:36:07.970 --> 01:36:09.190
To convince someone.
1479
01:36:09.805 --> 01:36:12.285
1480
01:36:13.005 --> 01:36:16.605
like, just one channel lightning notes, that's not the way to go. It's just,
1481
01:36:17.330 --> 01:36:23.990
you can't get your x right because either you're spending way too much money on opening humongous channels. Like,
1482
01:36:24.805 --> 01:36:28.505
poor Phoenix. I still have a channel open with them, I think,
1483
01:36:28.885 --> 01:36:30.985
10,000,000,000 sets or something like that on,
1484
01:36:31.420 --> 01:36:37.760
like, something ridiculous. Maybe only 7. But I I accidentally used it as a on chain wallet and didn't notice that they automatically
1485
01:36:38.139 --> 01:36:39.119
swap on lightning.
1486
01:36:39.445 --> 01:36:39.945
So
1487
01:36:41.365 --> 01:36:44.885
I'm I feel really sorry for that. Maybe I should just close it at some point.
1488
01:36:45.445 --> 01:36:48.105
1489
01:36:48.410 --> 01:36:49.870
1490
01:36:50.330 --> 01:36:52.030
or you will have to repeatedly
1491
01:36:52.410 --> 01:36:53.290
open new channels,
1492
01:36:54.170 --> 01:37:07.765
1493
01:37:08.760 --> 01:37:11.580
which it would be a similar situation as
1494
01:37:12.040 --> 01:37:14.940
the this lease pool that he mentioned, except, obviously, that's
1495
01:37:15.375 --> 01:37:16.035
would be,
1496
01:37:17.215 --> 01:37:18.515
theoretically more distributed
1497
01:37:19.135 --> 01:37:24.195
than 2 centralized providers, but it provides the same UX hurdle. It's like, what the fuck am I doing?
1498
01:37:27.280 --> 01:37:34.465
Anton, you have any views there? I mean, obviously, you in integrated those that feature and that I can just press a button and buy a channel from Ellen
1499
01:37:34.765 --> 01:37:36.305
Big, whoever the fuck that is.
1500
01:37:38.285 --> 01:37:38.785
1501
01:37:39.165 --> 01:37:40.865
well well, I agree. Again, this
1502
01:37:41.530 --> 01:37:47.630
this requires some level of understanding of what is going on. Yeah. And simple Bitcoin wallet is
1503
01:37:48.330 --> 01:37:48.830
actually
1504
01:37:49.265 --> 01:37:50.245
not that simple
1505
01:37:51.265 --> 01:37:52.885
after all. And
1506
01:37:55.745 --> 01:37:56.225
and,
1507
01:37:56.625 --> 01:37:58.245
it's aimed at somewhat
1508
01:37:58.740 --> 01:38:02.360
1509
01:38:03.140 --> 01:38:03.940
1510
01:38:04.420 --> 01:38:05.640
1511
01:38:06.985 --> 01:38:08.925
1512
01:38:09.225 --> 01:38:13.085
that, and then I just decided to not change the name.
1513
01:38:13.510 --> 01:38:19.670
So, yeah, it anticipates that user more or less understands what's going on. The user
1514
01:38:20.950 --> 01:38:21.930
1515
01:38:22.245 --> 01:38:25.065
I mean so I was actually going to
1516
01:38:25.925 --> 01:38:28.985
I wanted to bring this up before we wrap this up.
1517
01:38:29.740 --> 01:38:35.440
It was like a while I had you kind of thing. As someone who,
1518
01:38:37.155 --> 01:38:40.935
you know, still dispatch, the audience here is more technical focused.
1519
01:38:41.715 --> 01:38:45.175
I think they have a pretty decent understanding of lightning,
1520
01:38:45.560 --> 01:38:48.300
how it works, you know, the basic trade offs.
1521
01:38:48.920 --> 01:38:50.380
That's why I do still dispatch.
1522
01:38:50.760 --> 01:38:52.540
My other show, rabbit hole recap,
1523
01:38:53.335 --> 01:38:54.235
is a more
1524
01:38:55.095 --> 01:38:56.235
accessible show,
1525
01:38:57.815 --> 01:39:01.195
and I do a lot of education just, like, to new users and whatnot.
1526
01:39:02.980 --> 01:39:04.760
And when I'm, like, recommending wallets,
1527
01:39:05.060 --> 01:39:10.360
and I already kind of alluded to it with moon with 2 u's, and breeze with 2 e's and a z,
1528
01:39:11.824 --> 01:39:15.525
Like, names are important, especially when it comes across on audio.
1529
01:39:16.225 --> 01:39:18.225
And, like, simple Bitcoin wallet is just
1530
01:39:19.050 --> 01:39:21.390
like, I respect what you're doing. The wallet seems
1531
01:39:22.250 --> 01:39:25.070
pretty awesome, to be honest, and it's very snappy.
1532
01:39:26.865 --> 01:39:31.685
But, like, Simple Bitcoin Wallet as a name is a horrible name. It's an absolute horrible name.
1533
01:39:32.065 --> 01:39:37.190
Like, what the go download Simple Bitcoin Wallet. Yeah. Which one? No. Simple Bitcoin Wallet. You
1534
01:39:37.650 --> 01:39:40.390
know, it just doesn't w's in 3 words.
1535
01:39:41.170 --> 01:39:42.550
Yeah. But I do.
1536
01:39:44.235 --> 01:39:48.175
There's worse names. I'll give you that. It's better than Moon and Breeze. But,
1537
01:39:50.955 --> 01:39:55.650
yeah, I just I don't know if it's a good name for a wallet. It's it's kind of
1538
01:39:56.430 --> 01:39:58.850
counterintuitive when you say simple Bitcoin wallet.
1539
01:40:01.765 --> 01:40:14.010
1540
01:40:14.630 --> 01:40:28.015
1541
01:40:28.395 --> 01:40:28.895
That's
1542
01:40:30.060 --> 01:40:34.880
not any kind of, like, inheritance from one to another. Just different apps.
1543
01:40:38.355 --> 01:40:43.895
1544
01:40:44.435 --> 01:40:45.175
or something.
1545
01:40:45.600 --> 01:40:46.100
1546
01:40:47.040 --> 01:40:48.980
Yeah. It was just a very,
1547
01:40:49.520 --> 01:40:52.740
actually, very simple Bitcoin wallet, Bitcoin only.
1548
01:40:53.915 --> 01:40:55.055
1549
01:40:55.435 --> 01:40:57.055
like, a 100 k users,
1550
01:40:57.515 --> 01:41:00.575
1551
01:41:01.035 --> 01:41:01.535
And,
1552
01:41:02.260 --> 01:41:02.760
yeah,
1553
01:41:03.219 --> 01:41:07.159
at some point, I decided to upgrade it to lightning also.
1554
01:41:07.460 --> 01:41:11.355
So that's the story. Instead of continuing development of,
1555
01:41:11.835 --> 01:41:13.614
Bitcoin lightning wallet because
1556
01:41:14.074 --> 01:41:17.534
that turned out to be a dead end and not easily upgradeable
1557
01:41:17.835 --> 01:41:21.800
to private routing and other stuff that they wanted to go with.
1558
01:41:23.140 --> 01:41:25.240
So I decided to continue on that
1559
01:41:25.555 --> 01:41:27.094
in simple Bitcoin world.
1560
01:41:27.555 --> 01:41:31.495
1561
01:41:32.355 --> 01:41:34.535
And this is all love. I mean, so
1562
01:41:35.390 --> 01:41:40.930
just, some just my 2 stats, you know, take it or leave it. I appreciate you regardless.
1563
01:41:42.110 --> 01:41:44.770
You know, Jupiter has, like, 20 something moons,
1564
01:41:45.375 --> 01:41:47.075
and, like, Bitcoiners like moons.
1565
01:41:47.535 --> 01:41:49.875
So, like, you could pick 1 of the Jupiter moons,
1566
01:41:50.495 --> 01:41:53.395
could be a good name. You know, like Europa, Callisto,
1567
01:41:54.175 --> 01:41:54.675
Thebe.
1568
01:41:55.360 --> 01:41:57.300
Those are good names for for wallets.
1569
01:41:57.920 --> 01:42:01.620
1570
01:42:02.855 --> 01:42:06.715
1571
01:42:07.015 --> 01:42:08.075
Yeah. Don't do that.
1572
01:42:10.060 --> 01:42:12.159
But, yeah, I do appreciate you guys.
1573
01:42:13.500 --> 01:42:18.159
Last thing before we wrap up, I mean, I Fiat, Jeff, you sent out a tweet,
1574
01:42:19.295 --> 01:42:20.915
Something about implementing,
1575
01:42:22.175 --> 01:42:25.315
lightning in your app is a pain in the fucking ass.
1576
01:42:26.989 --> 01:42:28.929
You wanna talk about that at all? Or
1577
01:42:29.710 --> 01:42:32.929
1578
01:42:33.364 --> 01:42:39.705
all the nodes fail with me. Right now, I have a a bug on the clear that doesn't route payments bigger than,
1579
01:42:40.565 --> 01:42:41.065
8,000
1580
01:42:41.445 --> 01:42:42.940
sets. Like, if
1581
01:42:43.400 --> 01:42:46.700
it it has the channels, but it doesn't find any routes. And,
1582
01:42:47.240 --> 01:42:49.820
yeah, it's being being being debugged by
1583
01:42:50.145 --> 01:42:52.804
Eclair people and also Intel helping.
1584
01:42:53.344 --> 01:43:00.350
But, yeah, I have I have so many bad experiences with c lightning before, and many of the bugs that resulted in exploited
1585
01:43:01.050 --> 01:43:02.670
bugs exploited money,
1586
01:43:03.050 --> 01:43:03.550
whatever,
1587
01:43:04.090 --> 01:43:08.190
was, like, because the APIs were not clear, and they they didn't
1588
01:43:08.785 --> 01:43:15.525
do what I expected them to do. And, anyway, many, many bugs. And, also, I know that that all the other custodial services
1589
01:43:15.905 --> 01:43:17.685
had similar bugs,
1590
01:43:18.370 --> 01:43:20.310
But that's where I was coming from.
1591
01:43:20.930 --> 01:43:25.250
I I wanted to ask one thing to to Eric, like, if he saw the
1592
01:43:25.965 --> 01:43:30.705
because I just saw a picture of that. I I stand on the the conference on El Salvador
1593
01:43:31.325 --> 01:43:31.825
with,
1594
01:43:33.005 --> 01:43:35.185
simple Bitcoin wallet stuff and
1595
01:43:35.870 --> 01:43:37.170
stuff being given out.
1596
01:43:37.870 --> 01:43:40.530
1597
01:43:41.390 --> 01:43:42.750
proof of, the best,
1598
01:43:43.310 --> 01:43:44.850
like, ads ever. Like,
1599
01:43:45.355 --> 01:43:47.295
I had to take a picture of that.
1600
01:43:49.515 --> 01:43:50.815
It felt so nineties.
1601
01:43:55.200 --> 01:43:59.060
Yeah. Maybe if people don't know what we are referring to. Like, there was
1602
01:44:00.480 --> 01:44:02.740
a big poster with a beautiful lady,
1603
01:44:03.775 --> 01:44:05.555
advertising Simple Bitcoin Wallet.
1604
01:44:06.335 --> 01:44:11.715
1605
01:44:12.430 --> 01:44:18.450
1606
01:44:20.764 --> 01:44:21.425
1607
01:44:22.125 --> 01:44:29.665
1608
01:44:31.070 --> 01:44:37.090
and he was like we also asked him whether he's this lady is appropriate or not. He said that it increases
1609
01:44:37.550 --> 01:44:38.850
engagement guaranteed.
1610
01:44:39.885 --> 01:44:42.705
So it must be there if you want, like, more attention.
1611
01:44:44.364 --> 01:44:47.665