April 7, 2022
Open Source Stage Day 1 - Bitcoin 2022 in Miami
Video: https://youtu.be/j7R6CLnWI4M
0:0:00 Odell Intro
0:4:48 Lightning Services & Liquidity Providers panel with Ryan Gentry, Roy Sheffield, niftynei, João Almeida
0:51:36 The Future of Lightning - with Christian Decker, Hannah Rosenberg
1:23:05 Signatures - with Jonas Nick, Andrew Poelstra, and Nadav Kohen
2:03:50 Covenants - with Jerem Rubin, Burak Keceli, Sanket, hosted by niftynei and Mike.
2:43:17 Tradeoffs of Lightning Implementations - Christian Decker, Matt Corallo, Olaoluwa Osuntokun
3:35:30 Defining The Standards Of Taproot & Multisig - With Keith Mukai, Jameson Lopp, Stick, Oliver Gugger, Afsheen Bigdeli
4:23:10 Preventing Attacks On Bitcoin - With Peter Todd, Bryan Bishop, Luke Dashjr
4:48:10 Olaoluwa Osuntokun - Keynote
twitch: https://twitch.tv/citadeldispatch
bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos
podcast: https://www.podpage.com/citadeldispatch
telegram: https://t.me/citadeldispatch
support the show: https://citadeldispatch.com/contribute
stream sats to the show: https://www.fountain.fm/
join the chat: https://matrix.to/#/#citadel:bitcoin.kyoto
00:00 - Odell Intro
04:48 - Lightning Services amp Liquidity Providers panel with Ryan Gentry Roy Sheffield niftynei João
51:36 - The Future of Lightning nbsp with Christian Decker Hannah Rosenberg nbsp
01:23:05 - Signatures with Jonas Nick Andrew Poelstra and Nadav Kohen nbsp
02:03:50 - Covenants with Jerem Rubin Burak Keceli Sanket hosted by niftynei and Mike. nbsp
02:43:17 - Tradeoffs of Lightning Implementations Christian Decker Matt Corallo Olaoluwa Osuntokun nbsp
03:35:30 - Defining The Standards Of Taproot amp Multisig With Keith Mukai Jameson Lopp Stick Oliver
04:23:10 - Preventing Attacks On Bitcoin With Peter Todd Bryan Bishop Luke Dashjr nbsp
04:48:10 - Olaoluwa Osuntokun Keynote twitch httpstwitch.tvcitadeldispatch nbsp bitcointv
WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 3/17/2024 8:10:48 PM
Duration: 18351.203
Channels: 1
1
00:00:00.560 --> 00:00:01.380
Hello, guys.
2
00:00:02.560 --> 00:00:03.780
Good morning, Miami.
3
00:00:09.405 --> 00:00:11.665
By a show of hands, who was here last year?
4
00:00:13.245 --> 00:00:16.065
I can't see any of your hands, so that's a bad idea.
5
00:00:16.580 --> 00:00:21.720
Well, we've come a long way from last year. Last year, we were in a little tent. We called it the Fostome.
6
00:00:23.460 --> 00:00:25.320
It was more of a tent than a dome,
7
00:00:26.705 --> 00:00:34.645
but it was very active and we had a lot of people there and people were very excited about it. So this year, it was important for us to do it bigger.
8
00:00:36.440 --> 00:00:39.820
Might have overshot it a little bit. It's pretty, pretty huge.
9
00:00:40.840 --> 00:00:46.705
But at the end of the day, I hope you fill up this stage every day. We're gonna have it today, tomorrow,
10
00:00:47.085 --> 00:00:47.585
Friday.
11
00:00:49.165 --> 00:00:52.545
Really fantastic lineup. Absolute all star developers,
12
00:00:52.910 --> 00:00:55.250
open source contributors joining us.
13
00:00:57.230 --> 00:01:01.250
I imagine since most of you are here bright and early on the first day
14
00:01:01.715 --> 00:01:03.895
that you understand the importance of open source.
15
00:01:04.995 --> 00:01:10.695
I was gonna ask you how many of you are open source contributors to raise your hand, but I'm not gonna be able to see your hands. So
16
00:01:12.100 --> 00:01:18.040
I just wanted to say that I really do appreciate all the work that all of our contributors do in this space.
17
00:01:19.215 --> 00:01:22.034
They are what makes this this movement possible.
18
00:01:23.055 --> 00:01:23.795
Open source,
19
00:01:24.415 --> 00:01:25.395
you know, has
20
00:01:27.220 --> 00:01:29.880
obviously two main benefits to society.
21
00:01:30.820 --> 00:01:35.240
One being that we don't have to trust the code we run, that we can verify it ourselves,
22
00:01:36.685 --> 00:01:37.585
that it's independent
23
00:01:38.045 --> 00:01:39.025
of any corporation
24
00:01:41.325 --> 00:01:43.425
or entity that's in control of it,
25
00:01:44.765 --> 00:01:47.969
and that at the end of the day, this code
26
00:01:48.670 --> 00:01:49.810
can all be modified,
27
00:01:50.590 --> 00:01:51.090
distributed,
28
00:01:51.549 --> 00:01:52.049
improved,
29
00:01:54.204 --> 00:01:58.704
and will outlive any of the individual creators. It's very viral in nature.
30
00:01:59.645 --> 00:02:00.145
And
31
00:02:02.470 --> 00:02:03.290
I just
32
00:02:04.150 --> 00:02:08.170
am absolutely moved by everyone who continues to work in the space,
33
00:02:08.550 --> 00:02:09.850
work in open source,
34
00:02:10.584 --> 00:02:11.084
oftentimes
35
00:02:11.465 --> 00:02:13.005
for very little compensation
36
00:02:13.385 --> 00:02:14.444
when they could have,
37
00:02:15.145 --> 00:02:16.765
you know, a big paying job
38
00:02:17.785 --> 00:02:19.245
with some major corporation
39
00:02:20.220 --> 00:02:22.000
that is KYC ing you
40
00:02:22.700 --> 00:02:26.000
and trying to control everything you do and lock you into a system.
41
00:02:27.655 --> 00:02:32.955
I also wanna say just a huge thanks to the Bitcoin Magazine team for putting this together
42
00:02:34.215 --> 00:02:38.740
and really trying to make this a first class experience for open source.
43
00:02:39.280 --> 00:02:40.020
We have
44
00:02:40.960 --> 00:02:43.700
obviously the largest Bitcoin event in history
45
00:02:45.075 --> 00:02:47.095
happening in this venue today
46
00:02:47.635 --> 00:02:49.415
or and over the next few days,
47
00:02:50.515 --> 00:02:51.735
but this room
48
00:02:52.990 --> 00:03:01.010
believe there's about 1100 chairs in here, is larger than most conferences on its own, and we cannot have the largest Bitcoin event in history
49
00:03:01.630 --> 00:03:02.130
without
50
00:03:03.455 --> 00:03:06.035
the largest focus on open source in history.
51
00:03:06.735 --> 00:03:11.955
So I'm really grateful for them to make it happen. This has been months in the process.
52
00:03:12.620 --> 00:03:15.680
Big thank you to Cash App for actually sponsoring it,
53
00:03:16.780 --> 00:03:19.280
because this was a very expensive room to book.
54
00:03:22.775 --> 00:03:23.255
And,
55
00:03:23.735 --> 00:03:26.475
I appreciate you all for showing up because,
56
00:03:27.015 --> 00:03:29.195
you know, this is a movement of people.
57
00:03:30.570 --> 00:03:31.070
Without
58
00:03:31.650 --> 00:03:32.150
people,
59
00:03:32.730 --> 00:03:34.030
the code is just words.
60
00:03:34.330 --> 00:03:38.990
Right? We need the people to actually run it, build it, use it, support it,
61
00:03:39.615 --> 00:03:41.474
and that's what makes this movement great.
62
00:03:45.215 --> 00:03:48.035
I love you all. This is a very big moment.
63
00:03:48.540 --> 00:03:50.160
We're gonna have a lot of fun together.
64
00:03:50.620 --> 00:03:54.640
We have some really great programming today. Today is gonna be more technical focused.
65
00:03:56.115 --> 00:04:01.895
The next 2 days will be a little bit more accessible and a little bit more mainstream focused, but we have some really
66
00:04:03.530 --> 00:04:07.630
all star all star open source contributors that will be on panels today.
67
00:04:09.975 --> 00:04:17.035
And, I'm looking forward to it, and I hope you're looking forward to it as well. I got this big screen that's just me in front of me, which is kinda weird.
68
00:04:19.129 --> 00:04:20.669
I have 5 more minutes,
69
00:04:21.530 --> 00:04:26.590
but I'm not I don't think I'm just gonna, like, walk on stage and just keep talking. We're running a little bit behind,
70
00:04:27.884 --> 00:04:31.664
which is natural for these types of things right in the beginning. So we're gonna get started
71
00:04:32.365 --> 00:04:32.845
and,
72
00:04:33.805 --> 00:04:36.140
keep on building. I appreciate you all. Thanks, guys.
73
00:04:45.775 --> 00:04:52.115
Welcome to the open source stage. Matt did a great job stalling opening for us, doing his thing.
74
00:04:54.020 --> 00:04:55.000
Welcome, everybody.
75
00:04:55.300 --> 00:04:57.960
Let's do quick intros for the people,
76
00:04:58.900 --> 00:05:00.120
the people of the audience
77
00:05:00.635 --> 00:05:01.135
specifically,
78
00:05:01.675 --> 00:05:03.215
and you, the viewer. Yes.
79
00:05:05.115 --> 00:05:06.895
I'm just so happy to be here with everyone.
80
00:05:07.740 --> 00:05:13.040
Zhuang, do you wanna maybe say your name correctly and also give a quick intro? Let's maybe,
81
00:05:14.140 --> 00:05:15.905
we have a little bit of time, but,
82
00:05:16.385 --> 00:05:20.165
maybe keep intro short so we can get to the the good stuff. I'm Zhuang.
83
00:05:21.585 --> 00:05:24.245
I work at OpenNode. We basically do payments
84
00:05:24.560 --> 00:05:25.780
in the Bitcoin space.
85
00:05:26.400 --> 00:05:29.620
One of the first to do lining. I'm happy to be here.
86
00:05:31.805 --> 00:05:35.905
Cool. I'm Lisa, also known as Nifty Nye. I work at Blackstream
87
00:05:36.365 --> 00:05:38.705
on core lightning, recently renamed.
88
00:05:39.645 --> 00:05:40.145
Yeah.
89
00:05:41.480 --> 00:05:42.220
I'm Roy.
90
00:05:42.600 --> 00:05:45.820
I'm building Breeze. Breeze is a lightning wallet and a platform
91
00:05:46.200 --> 00:05:48.380
to interact with the lightning economy.
92
00:05:49.405 --> 00:05:50.465
And I'm Ryan Gentry.
93
00:05:50.845 --> 00:06:03.479
I do business development at Lightning Labs, where we develop L and D and, you know, liquidity services, which is the topic of the panel. Perfect. I'm glad you I'm glad you're able to make it. No. Absolutely. Thank you for having and I'm I'm Michael Tidwell,
94
00:06:04.900 --> 00:06:09.685
moderating this great panel of candidates here, attend or whatever, panelist.
95
00:06:10.625 --> 00:06:11.845
I I run infrastructure
96
00:06:12.145 --> 00:06:14.405
at Zebedee, a gaming platform company.
97
00:06:14.785 --> 00:06:15.285
So,
98
00:06:16.270 --> 00:06:20.610
let's let's jump into it. And, I think the first thing I wanna do is
99
00:06:21.390 --> 00:06:24.370
let's maybe talk about a little bit of history of LSPs.
100
00:06:24.974 --> 00:06:25.634
You know,
101
00:06:26.014 --> 00:06:33.634
this you know, I have no idea what an LSP is being fairly new to lightning myself. Maybe someone on the panel, someone maybe Roy Yeah. Can break down.
102
00:06:33.950 --> 00:06:38.370
What is an LSP? Who who even made up this term? What what is this? That's a good question.
103
00:06:39.550 --> 00:06:42.095
I don't know. Someone came up with a term.
104
00:06:42.975 --> 00:06:44.995
LSP is a lightning service provider.
105
00:06:45.695 --> 00:06:46.655
It's kind of,
106
00:06:47.295 --> 00:06:48.515
the way that
107
00:06:48.895 --> 00:06:51.475
everyone can plug into the lightning network.
108
00:06:52.319 --> 00:06:59.939
Similarly to the way that you have an ISP and you plug your router in your home and you're plugged in into the, in Internet,
109
00:07:00.305 --> 00:07:06.164
the same way we need an infrastructure in Lightning that allows you to be connected to the network
110
00:07:06.625 --> 00:07:12.550
in as seamlessly as possible. So that's why wait. I remember. I coined the term LSC.
111
00:07:13.090 --> 00:07:14.310
Yeah. So
112
00:07:15.170 --> 00:07:17.350
that that's why I came up with this
113
00:07:17.705 --> 00:07:24.205
concept of a a Lightning service provider, and that's the service that facilitate this connectivity to the Lightning
114
00:07:24.585 --> 00:07:26.125
Network. Great. And
115
00:07:26.990 --> 00:07:33.970
I I just wanna say it it seems I I feel like we could talk about this stuff maybe for, like, an hour and a half because just because we're we're all doing
116
00:07:34.545 --> 00:07:40.885
pretty different things with lightning, like, LSPs and and and whatnot. Like, for instance, Zebedee is doing custodial
117
00:07:41.505 --> 00:07:42.965
LSP stuff, and
118
00:07:43.289 --> 00:07:44.909
Breeze, on the other hand, noncustodial.
119
00:07:45.530 --> 00:07:49.710
And we have a lot of cool things in between. I mean, there's so much to dig into. Yeah.
120
00:07:50.655 --> 00:08:00.500
I I kinda wanna maybe maybe we can kinda piecemeal this and kinda see where it goes, but, because these topics because within LSPs, there's there's so many different kind of, I guess you can
121
00:08:00.800 --> 00:08:01.120
say,
122
00:08:01.680 --> 00:08:02.420
use cases
123
00:08:02.800 --> 00:08:05.540
and and and implementations, I guess you could say.
124
00:08:07.074 --> 00:08:09.095
Maybe we start with with
125
00:08:09.875 --> 00:08:15.360
non custodial breeze route and then kinda work our way to what everyone else is doing. Yeah. Okay. Sure.
126
00:08:15.740 --> 00:08:20.639
Sure. Not not not to shit on custodial solutions, but the only way that you can do
127
00:08:21.020 --> 00:08:24.754
Lightning is in a noncustodial fashion. Lightning is the extension of Bitcoin.
128
00:08:25.134 --> 00:08:25.615
Bitcoin
129
00:08:25.935 --> 00:08:28.595
all the properties of Bitcoin of being censorship resistant,
130
00:08:29.055 --> 00:08:29.555
open,
131
00:08:30.095 --> 00:08:30.595
borderless,
132
00:08:31.055 --> 00:08:31.955
etcetera, etcetera.
133
00:08:32.319 --> 00:08:37.139
We need to bring that to the to the lightning network. So the only way that you can do
134
00:08:37.759 --> 00:08:38.259
really
135
00:08:39.815 --> 00:08:45.355
lightning is in a non custodial fashion, and and and the function of an LSP in just in that
136
00:08:46.055 --> 00:08:47.274
topology is
137
00:08:47.899 --> 00:08:57.279
how do you, as a user, how do you connect to the network? You actually need to run a node. Right? The node is the entity that facilitates your participant
138
00:08:57.645 --> 00:08:58.545
in the network.
139
00:08:58.925 --> 00:09:06.065
So you let's say you were able to run a node, and in Breeze, for example, we allow you to run a node on your mobile device.
140
00:09:07.050 --> 00:09:07.790
A node
141
00:09:08.410 --> 00:09:11.630
can do anything with the inside the lightning network without
142
00:09:12.250 --> 00:09:17.475
the ability to plug in to the network. So the LSP is the bridge between the network
143
00:09:17.855 --> 00:09:21.005
and the end user node. And the way that the
144
00:09:23.030 --> 00:09:28.090
LSP needs to connect the user to the Lightning Network is by opening a channel.
145
00:09:28.550 --> 00:09:30.250
There's an entity in Lightning Network,
146
00:09:30.710 --> 00:09:36.055
which is called the payment channel. The LSP needs to open a payment channel and provide liquidity
147
00:09:36.835 --> 00:09:38.135
to the end user.
148
00:09:38.995 --> 00:09:41.175
So so for the other panelists here,
149
00:09:41.490 --> 00:09:42.230
does anyone
150
00:09:43.250 --> 00:09:48.950
have a different take? Like like, for instance, the thing that Roy just described, does it scale? Does anyone have any, like,
151
00:09:49.445 --> 00:09:49.945
maybe
152
00:09:50.325 --> 00:10:02.200
counter objection or slightly different angle that they would want to talk about here? Or do does everyone just 100% agree with Roy? I'm just curious. Anything? I think the the the key thing that Roy said that I definitely agree with is,
153
00:10:02.680 --> 00:10:16.180
you know, when we think about lightning, we think about there's the core of the network, which is largely service provider nodes, big nodes that are doing routing, and then there's the edges of the network, right, which is generally the users, right? And so some users will be
154
00:10:16.800 --> 00:10:19.620
operating on a custodial node, some will be on non custodial,
155
00:10:19.935 --> 00:10:31.950
but that function of connecting the core to the edge, that is the service that's provided. It's connecting you to the broader lighting network, which you know, I particularly work with a bunch of like a cross section of a bunch of different LSPs,
156
00:10:33.370 --> 00:10:35.870
like everybody on the stage, Lisa aside.
157
00:10:36.410 --> 00:10:36.910
But
158
00:10:37.450 --> 00:10:37.950
we
159
00:10:39.305 --> 00:10:43.805
there's all sorts of different use cases and different things that people are doing on lightning from sending funds
160
00:10:44.665 --> 00:11:00.725
to emerging markets, from playing games, from playing podcasts, etcetera. And the function of making that connection seamless of making sure that you can get from stats from the edge of the network through the core to some other destination like that function at its core is is what the Lightning Service Provider does.
161
00:11:01.505 --> 00:11:05.310
And I would say it depends on the end user too. You know? If you're talking,
162
00:11:06.250 --> 00:11:08.269
of a big company, publicly traded
163
00:11:08.649 --> 00:11:12.029
company, they might not, at this time, be ready to run a non custodial,
164
00:11:12.569 --> 00:11:13.470
you know, infrastructure.
165
00:11:14.485 --> 00:11:19.065
They need some compliance stuff. You know? The the stuff we don't like, but that is necessary.
166
00:11:19.685 --> 00:11:22.345
So they might come, in this case, to us, you know,
167
00:11:22.885 --> 00:11:23.720
because that's
168
00:11:24.120 --> 00:11:29.740
that's what they need to show to the regulators to, like, oh, we're legit. We're running a service that
169
00:11:30.120 --> 00:11:35.125
complies to all the stuff that you need. So at the end of the day, it really depends on the end user. Right? From
170
00:11:35.425 --> 00:11:39.045
for me, from my perspective, obviously, I would want this to be all noncustodial.
171
00:11:39.900 --> 00:11:40.720
But sometimes,
172
00:11:41.180 --> 00:11:42.720
you know, if you're like McDonald's,
173
00:11:43.260 --> 00:11:47.520
they cannot run a noncustodial service today because they don't have an empty up, for instance.
174
00:11:47.834 --> 00:11:54.815
They're in the food business or real estate business, maybe. They're not in the finance business. So it it really depends on where your,
175
00:11:55.120 --> 00:12:06.605
you know, where your goals as a company. Like, do you wanna waste time pursuing that license, or do you just wanna get a quick shortcut and get into the big plugged into the Bitcoin network? So I feel like there's service for everything.
176
00:12:08.105 --> 00:12:12.080
Lisa, did you wanna or Nifty Nai, did you wanna chime in on anything here?
177
00:12:12.480 --> 00:12:18.900
And so, I mean, when we're talking about liquidity, I think one thing maybe it'd be interesting to kinda talk a little more,
178
00:12:21.225 --> 00:12:22.925
broadly about, like, what is liquidity
179
00:12:23.625 --> 00:12:24.365
on lightning?
180
00:12:24.904 --> 00:12:28.125
Be before we jump on that Yeah. Yeah. Let me ask a quick follow-up for.
181
00:12:30.610 --> 00:12:31.270
Got it.
182
00:12:31.730 --> 00:12:35.890
Which I still don't recognize you even though I've known you for years. The the hair is throwing me off.
183
00:12:37.730 --> 00:12:39.350
So so do you feel like
184
00:12:40.615 --> 00:12:46.475
companies will probably even long term will probably be noncustodial, and then maybe, like, your end users, like, your actual
185
00:12:46.990 --> 00:12:50.930
nonbusiness users are gonna be noncustodial, or do you not see it that way?
186
00:12:51.390 --> 00:12:58.795
I feel like there is a transition phase. Right? Right now, they need to go through these services like what we do. Like, eventually, long term, the goal is
187
00:12:59.335 --> 00:13:02.315
to be able for the business to build self serve. Right?
188
00:13:02.775 --> 00:13:12.269
And, ideally, the utopia is like every business runs their own infrastructure. They're in control of their money. I mean but the reality is I don't see that happening very soon.
189
00:13:13.115 --> 00:13:21.214
So, like, 2 weeks, 2 years, 20 years? I wanna give a timeline. That's like asking what's the price of Bitcoin to be here. Well, I was gonna ask that next. You know?
190
00:13:22.020 --> 00:13:22.520
Okay.
191
00:13:23.300 --> 00:13:25.640
Well, may maybe we jump into the other l,
192
00:13:26.180 --> 00:13:26.760
the liquidity.
193
00:13:27.300 --> 00:13:28.840
Oh, yeah. So Totally.
194
00:13:29.380 --> 00:13:30.200
Why don't you
195
00:13:30.505 --> 00:13:41.700
tee that off? Yeah. Totally. So, like, I mean, I think one thing that's, like, useful so I understand when you're talking about liquidity service providers is exactly what service they're providing. Right? Like, what is that liquidity
196
00:13:42.080 --> 00:13:45.280
that the l and liquidity service provider stands for?
197
00:13:45.920 --> 00:13:47.860
And it kinda goes back to how
198
00:13:48.225 --> 00:13:51.205
the lightning network is set up and what, like,
199
00:13:52.145 --> 00:13:55.045
it's when we're talking about liquidity, we're literally talking about
200
00:13:55.410 --> 00:13:59.030
Bitcoin that's being committed to lightning channels. Right?
201
00:13:59.490 --> 00:14:01.590
And there's kind of this, like, inherent
202
00:14:02.645 --> 00:14:06.985
problem with moving money over Lightning Network, and that is
203
00:14:07.445 --> 00:14:13.770
who and where is that Bitcoin that's been committed to Lightning Channels locked up? Who's got it?
204
00:14:14.150 --> 00:14:27.154
Who's got the ability to use that locked of Bitcoin to pay someone else? Right? This is, like, becomes a kind of complicated problem. Right? There's only so much Bitcoin in the world. We well, what is it? Do we hit 18? Is it 19,000,000?
205
00:14:27.850 --> 00:14:28.350
19,000,000
206
00:14:28.650 --> 00:14:31.790
was the thing? So there's only 19,000,000 Bitcoin.
207
00:14:32.490 --> 00:14:34.670
A lot of that Bitcoin lives in,
208
00:14:35.524 --> 00:14:37.545
cold storage or exchanges
209
00:14:38.805 --> 00:14:50.970
or, you know, people's, like, wallets at home, whatever. And then there's even a smaller part of that, like, ends up getting locked into Lightning Channels. Right? So I think one thing is, like, okay, there's only so much Bitcoin available to be used,
210
00:14:51.589 --> 00:14:55.805
Lightning, etcetera. Okay. So then you've got the amount of Bitcoin that's locked into Lightning channels.
211
00:14:56.985 --> 00:15:02.845
Then in order like, once you're operating on the Lightning Network, your ability to send and receive payments,
212
00:15:03.790 --> 00:15:21.570
sending payments is, like, I wanna say a little bit easier. You can buy some Bitcoin, lock it into a Lightning channel, and then send it. So that's kind of like sending Bitcoin, sending Lightning over Bitcoin to some extent is bring your own stats. Like, you've got some money and you're probably gonna, like, put it in and send it out somewhere else.
213
00:15:22.350 --> 00:15:33.185
The harder problem is receiving money on Lightning. This is this is, like, tends to be and you guys should definitely correct me if I'm wrong. This tends to be kind of the gap. The liquidity service providers,
214
00:15:33.910 --> 00:15:38.090
fill in for that edge network that Ryan is was talking about earlier.
215
00:15:38.550 --> 00:15:39.050
So
216
00:15:39.750 --> 00:15:40.230
the,
217
00:15:40.630 --> 00:15:46.315
the work of figuring out, like, okay. We only have so much Bitcoin locked into channels or, like, as a service
218
00:15:46.855 --> 00:15:50.154
provider. You know? If if someone wants to receive a payment,
219
00:15:50.509 --> 00:15:53.970
the liquidity service provider has to figure out how to get
220
00:15:54.350 --> 00:15:55.730
Bitcoin to them
221
00:15:56.269 --> 00:15:56.769
from
222
00:15:57.635 --> 00:16:04.935
whatever channels etcetera. They've they've got Bitcoin locked into already, etcetera. So we call this So this problem of, like,
223
00:16:05.270 --> 00:16:08.650
getting the ability to receive Bitcoin over Lightning,
224
00:16:09.030 --> 00:16:10.730
we call that inbound liquidity.
225
00:16:11.670 --> 00:16:16.555
Inbound liquidity is, like, kind of a valuable difficult thing to get on Lightning.
226
00:16:17.015 --> 00:16:22.635
Part of the reason for this is you have to convince someone else to make that Bitcoin available to you
227
00:16:22.960 --> 00:16:41.825
before you can receive payments. So LSPs help solve this problem. And, again, please, like, help correct me if I'm wrong here. You guys have a lot more hands on experience with us than I do. But getting LSPs are the the service that provides basically the ability to receive and send, but the receive part is the really difficult part of,
228
00:16:42.240 --> 00:16:43.940
payments over lightning. So,
229
00:16:44.800 --> 00:16:55.535
some of the work that goes into that is, like, okay, where do you have all this Bitcoin available? So, like, if you have Bitcoin available such that you can then pay it out to people. Right? Someone else is gonna pay you on the other end, but,
230
00:16:56.840 --> 00:17:00.460
I think another, like, this is a little bit of a tangent, but sort of similar.
231
00:17:01.320 --> 00:17:06.885
Another thing about Bitcoin liquidity on Lightning is that I would call Lightning a over collateralized
232
00:17:07.345 --> 00:17:10.245
network. If you wanna send a bitcoin from
233
00:17:10.705 --> 00:17:12.805
your node to 3 hops away
234
00:17:13.230 --> 00:17:14.690
because Lightning is routed,
235
00:17:15.230 --> 00:17:16.690
you need 3 Bitcoin
236
00:17:17.389 --> 00:17:20.289
of Bitcoin already locked into Lightning
237
00:17:20.835 --> 00:17:31.260
before you can send 1 bitcoin 3 hops away. So every payment that's made over lightning requires a multiple of bitcoin to already be committed to the lightning network.
238
00:17:32.120 --> 00:17:43.885
So liquidity management and how do you so then so, you know, you kinda step back a little bit. It's okay. Like, we need a lot more Bitcoin on the network in order to make payments work than the actual volume of the payments that are going through the network
239
00:17:44.424 --> 00:17:48.125
currently as it stands. Maybe we'll come up with some really fancy ways to do rehypothecation
240
00:17:51.070 --> 00:17:55.740
on lightning. We don't we don't like that word any different. But today. They're not.
241
00:17:56.715 --> 00:17:58.095
So you mean there'll be 22,000,000
242
00:17:58.475 --> 00:17:59.455
Bitcoin? Yeah.
243
00:18:00.075 --> 00:18:07.000
Maybe we'll expand the Bitcoin supply but like there's this anyway, this is like the like sort of philosophical problem about liquidity on lightning.
244
00:18:08.100 --> 00:18:16.455
So, like, then, you know, you're doing liquidity. It's like, okay. You're providing liquidity to people. People. Like, how much Bitcoin do you have? How do you attract more people that have Bitcoin that isn't on lightning
245
00:18:16.835 --> 00:18:24.080
to bring their Bitcoin into the lightning network such that we can use it as payment rails to move, you know, value around between people,
246
00:18:24.860 --> 00:18:25.360
etcetera.
247
00:18:25.660 --> 00:18:39.370
That's a lot of talk. So so you made it pretty clear. Inbound liquidity is one of the biggest challenges right now for onboarding new people for it's it's it's one of the biggest challenges right now. And I'm I'm curious. Maybe we can talk about
248
00:18:39.750 --> 00:18:42.169
how is this challenge being addressed, the inbound liquidity
249
00:18:42.470 --> 00:18:44.745
challenge. You know, and and what what are
250
00:18:45.125 --> 00:18:52.105
what are we doing to, you know, tackle this problem because there's a couple different ways. Right? So So one thing that I think is was really interesting,
251
00:18:53.110 --> 00:18:54.730
last week when Kraken
252
00:18:55.270 --> 00:18:57.850
finally turned on their node and
253
00:18:58.150 --> 00:19:09.705
got on and joined the Lightning Network, their node, like last I looked, they had like rocketed up to something like number 10 in total capacity on the network. Everyone here is probably guilty of helping that. Not a failure.
254
00:19:10.725 --> 00:19:15.559
But I think what was what's really interesting is like the inbound liquidity problem
255
00:19:15.940 --> 00:19:16.440
is
256
00:19:16.740 --> 00:19:17.240
generally
257
00:19:18.100 --> 00:19:19.080
absolutely agreed
258
00:19:19.565 --> 00:19:31.960
with Lisa that it is like the scarce resource and the hard thing to acquire. But then you have an entity like Kraken where people are like hey, we want them to succeed, we think there's gonna be a ton of fees to be earned by routing payments
259
00:19:32.419 --> 00:19:33.640
to the Kraken node,
260
00:19:33.975 --> 00:19:48.480
like let's allocate a ton of capital to them or they don't even have to pay for it, we'll just kinda like optimistically think that that's where we're gonna earn a return from. It's like it's like if you're so cool and popular, it's like life is easy for you. You know what I mean? I know. I don't know anything about that. That must be nice.
261
00:19:49.875 --> 00:19:54.295
So I think that's been like a really interesting thing, and we've seen that a couple times where
262
00:19:54.675 --> 00:20:11.605
there are like new services that pop up on Lightning and they ask like how can I go and get connected to the network? And we're just still in these early days where kind of the best solution still is like put up the bat signal on Twitter and say like hey, we have a new node, can you please connect to us and the community will generally
263
00:20:11.985 --> 00:20:13.205
open the channels to you.
264
00:20:13.970 --> 00:20:18.950
As it matures and the network gets bigger, I think it's fundamentally, it's a market problem.
265
00:20:19.650 --> 00:20:30.855
As Lisa said, well you're trying to convince somebody to allocate capital to your direction, and like what's the best way to do that? Well, you just pay them. Right? I agree, because right now it's I feel like for
266
00:20:31.220 --> 00:20:39.480
Lightning companies or Lightning service providers, there's almost kinda, like, right now, an excess of capital where it's like, I don't wanna just deploy this randomly, but when I see a Kraken,
267
00:20:39.805 --> 00:20:43.265
I suddenly have plenty of capital to deploy. You know? And,
268
00:20:43.725 --> 00:20:54.320
I think I think we're kinda past, like, the 2019, 2020, 2021 where we just wanna open up random channels to everyone. We wanna be a little bit more thoughtful on that, so It has it definitely has matured for sure.
269
00:20:54.860 --> 00:21:04.765
I I would say there are 2 different issues like connecting to routing nodes to other hubs in the network and onboarding end user. Yes. These are 2 completely separate problems.
270
00:21:05.110 --> 00:21:10.330
Would you think that that's, like, the core and edge distinction? Yeah. Yeah. And then end user can be,
271
00:21:10.789 --> 00:21:15.155
like a service, like OpenNode as well. Like but yeah. So let's say an edge
272
00:21:15.695 --> 00:21:18.835
onboarding edges and connecting to other nodes
273
00:21:19.215 --> 00:21:23.075
in the network, these are completely 2 separate problems. And and
274
00:21:23.535 --> 00:21:34.355
I don't know if it's easy to send in the Lightning Network right now because in order to send, you need to first receive. And then before you're able to send, you need to receive and and to solve the inbound liquidity
275
00:21:34.655 --> 00:21:35.155
problem.
276
00:21:35.455 --> 00:21:38.915
So I think there are what what's cool about the inbound liquidity,
277
00:21:39.935 --> 00:21:47.559
problem that is it's being solved for end users at least. Like, we want we don't have enough tools to manage liquidity
278
00:21:47.940 --> 00:21:51.960
efficiently currently in the Lightning Network, but at least to onboard users,
279
00:21:52.325 --> 00:21:54.024
there are set of solutions
280
00:21:54.404 --> 00:21:57.465
that, were put into place in order to facilitate
281
00:21:58.245 --> 00:22:01.385
this, out of the box inbound liquidity issue.
282
00:22:01.850 --> 00:22:08.270
One of the solutions is what we're doing at Breeze, opening 0 confirmation channels. So we're actually utilizing
283
00:22:08.835 --> 00:22:12.215
the liquidity of the end user in order to open
284
00:22:12.675 --> 00:22:13.175
liquidity,
285
00:22:13.715 --> 00:22:14.855
to allocate liquidity
286
00:22:15.315 --> 00:22:24.440
to the user end. So we open a channel and we push liquidity, the same liquidity that the user used to top up the wallet. We use it in order to provide
287
00:22:25.435 --> 00:22:27.375
inbound liquidity. That's one solution.
288
00:22:28.795 --> 00:22:33.855
Another solution is pool solution like pool from Lightning Labs is the ability to lease
289
00:22:34.620 --> 00:22:35.120
liquidity
290
00:22:35.740 --> 00:22:36.720
and to open
291
00:22:37.820 --> 00:22:38.480
a channel
292
00:22:38.940 --> 00:22:41.040
which is a list for by default,
293
00:22:41.660 --> 00:22:43.565
a month, 2 weeks, what's the default?
294
00:22:43.865 --> 00:22:49.200
It's we have range, but there's a duration for 2 weeks, a month, 3 months, and a year now, I believe. Okay. That's very cool.
295
00:22:50.000 --> 00:22:51.539
And the 3rd solution from
296
00:22:52.799 --> 00:22:59.085
Lisa I think worked on it, it's liquidity ads where nodes can announce that they are willing
297
00:23:00.424 --> 00:23:00.924
to
298
00:23:01.625 --> 00:23:04.765
rent you liquidity for such and such
299
00:23:05.145 --> 00:23:05.645
price.
300
00:23:06.720 --> 00:23:15.139
So we have pool, we have Breeze with the model where if I download the Breeze wallet, I get inbound liquidity kind of by being a user of Breeze.
301
00:23:15.525 --> 00:23:27.309
You have liquidity at I'm actually a little bit unfamiliar. Would you like to Yeah. I can talk about them a bit. So liquidity ads is a proposal that I wrote for the lightning spec, so it's specified.
302
00:23:27.610 --> 00:23:35.035
That means that we are working with other lightning implementations so that, hopefully, it'll be supported by every node on the Lightning Network.
303
00:23:35.815 --> 00:23:37.735
It's basically act a way to
304
00:23:38.615 --> 00:23:40.930
I call it like a billboard system of advertising
305
00:23:41.309 --> 00:23:44.050
that you've got liquidity that you're looking to deploy.
306
00:23:44.910 --> 00:23:53.784
This billboard ad that you can put up, you can put in, like, how much you're looking to get for the capital that you have available. So you set your own rate of how much that your
307
00:23:54.245 --> 00:23:59.320
available capital is worth to you, and you can set that. You put it into a little advertisement.
308
00:23:59.940 --> 00:24:06.420
Those advertisements go into something in lightning we call the gossip network, which every node on the network sends and receives.
309
00:24:07.140 --> 00:24:11.955
So so you can advertise. You put a little bit of information, this little kind of, like, classified ad
310
00:24:12.255 --> 00:24:26.534
called liquidity ads into your gossip goes out to every node on the network. So if you're running a node right now, you're currently getting all the liquidity ad data. It's on your node. Whether or not your node exposes that to you is a different question, but if you're on core lightning, you can see them.
311
00:24:27.015 --> 00:24:29.434
They're also available to see on lnrouter.app,
312
00:24:31.015 --> 00:24:35.419
which is like a little there's a little dashboard. You can go look at all the liquidity ads that are currently available.
313
00:24:35.879 --> 00:24:50.925
Anyway, so this is the way you advertise, like, hey. I've got some capital. I'd like to deploy it. Here's how much I want you to pay for me. And then you can if you're trying to buy or get inbound liquidity, you can go look at all the nodes that are offering liquidity, where they are on the network, whether it's worth, what they're offering to you or not, and then
314
00:24:51.305 --> 00:24:55.600
decide whether or not to take them up on their ads. So it's a it's super decentralized.
315
00:24:55.900 --> 00:25:10.525
I have no information for you. It's been out for maybe, like, 7 months now. I have no information for you about how many people have used it, or how much capital has been allocated using that market because that data only exists between the buyer and seller.
316
00:25:11.140 --> 00:25:15.400
You can go look at I think the number of ads is, like, we're close to, like, 15, 20 these days.
317
00:25:15.780 --> 00:25:17.320
So it's, like, small but growing.
318
00:25:18.100 --> 00:25:29.549
Yeah. I wanna talk a little bit custodial with you for for but before I do that, I wanna jump and and wrap up maybe some pool because we didn't really talk about pool much. Where do you see the leasing
319
00:25:30.649 --> 00:25:31.149
liquidity
320
00:25:31.690 --> 00:25:40.325
industry, the leasing channel market? What what do you what is it like now? What was it before? What's what's it gonna become? Maybe you can talk a little bit about that since you're familiar. Sure.
321
00:25:40.885 --> 00:25:41.385
So
322
00:25:41.765 --> 00:25:43.850
what it was previously was, like,
323
00:25:44.169 --> 00:25:45.150
before we had,
324
00:25:45.690 --> 00:25:54.785
you know, channel leases as like a formal kind of financial product on lightning, it was all handshake agreements between, you know, people on the stage, right, saying like, hey
325
00:25:55.405 --> 00:25:59.985
message you on Telegram, hey can you please open 1 Bitcoin channel to me, like we're expecting
326
00:26:00.285 --> 00:26:03.030
a lot of volume this weekend or something like that. Right?
327
00:26:03.410 --> 00:26:08.150
That obviously doesn't scale if we think flight in network is gonna be tens to hundreds of thousands
328
00:26:08.610 --> 00:26:09.350
of nodes,
329
00:26:10.050 --> 00:26:10.550
businesses
330
00:26:11.485 --> 00:26:18.545
being able to interact. So turning that kind of interaction into more of a market interaction saying, you know, I will pay you
331
00:26:18.880 --> 00:26:23.059
x amount or x percent of the capital that you, commit to me,
332
00:26:23.600 --> 00:26:30.655
as long as you keep that channel open for say a 3 month period. Right, and I think the cool thing that that both pool and,
333
00:26:31.515 --> 00:26:38.070
the liquidity edge construction does is that that lease term is actually secured by Bitcoin script. Right. So if the channel is opened,
334
00:26:38.850 --> 00:26:42.790
it actually, you know, those funds can't be decommitted from that channel.
335
00:26:43.170 --> 00:26:48.745
Bitcoin itself will not allow that channel to be closed until the duration is up, which I think is a really cool construction.
336
00:26:49.205 --> 00:26:50.745
So so it's like I can either
337
00:26:51.365 --> 00:26:55.385
use, like, something like pool or like a commit or whatever to get, like, inbound liquidity,
338
00:26:55.710 --> 00:27:07.475
or I can just start an exchange and get really popular and get a bunch of users, and they get free inbound liquidity. Yeah. Or just, like, a bunch of Twitter users and just say, hey. I need inbound liquidity. Or we can or we can download reason. Or we can
339
00:27:08.595 --> 00:27:12.434
so so so I guess The final thing that I wanna say on that though, which is which is really interesting,
340
00:27:12.995 --> 00:27:13.495
is,
341
00:27:15.290 --> 00:27:16.030
we've seen
342
00:27:17.130 --> 00:27:19.150
in pool, the lease rates are public.
343
00:27:20.170 --> 00:27:28.475
If you're running a node you can download all the data and read through all the history. And so we've seen over the last like couple months or this year that like
344
00:27:28.990 --> 00:27:34.210
demand is starting to is like really starting to pick up, rates are starting to get, like, pretty sustainably high,
345
00:27:34.670 --> 00:27:40.674
which means that there is now, like, you know, well maybe in the early days there was an overabundance of supply,
346
00:27:41.535 --> 00:27:58.525
like demand is starting to kind of pick up and push prices up, which should in theory then induce kind of more supply coming on the network. Because if you can earn, you know, 6% annualized on your Bitcoin for opening a channel to a node that wants it, like, that's a pretty good deal. Or you can trust all your money with, like, a custodial
347
00:27:59.305 --> 00:28:06.760
you know? I I'm not gonna name names. Kinda like, hey. We magically give you 6%, and we and they they take this is like the I mean,
348
00:28:07.220 --> 00:28:18.195
this might be the only thing I can think of that's, like, noncustodial, actually, like, providing a service where you can get a little bit of income on your Bitcoin potentially. Right? Absolutely. And, like, you know And that's key. We need to break a myth here. Like, there's a misconception
349
00:28:19.135 --> 00:28:20.995
that Lightning is free.
350
00:28:21.320 --> 00:28:25.019
Yes. And and in order for Lightning to be successful,
351
00:28:26.039 --> 00:28:28.539
the the routing fees need to go higher
352
00:28:29.185 --> 00:28:30.725
and and lightning needs
353
00:28:31.345 --> 00:28:33.525
basically, the the entire thing about liquidity
354
00:28:34.065 --> 00:28:44.149
is is why would people allocate liquidity to going back to what Lisa said, like what's the reason that people will put their liquidity in lightning? They want to generate yield, right?
355
00:28:44.575 --> 00:28:46.434
So if people put liquidity
356
00:28:46.735 --> 00:28:47.235
in
357
00:28:47.535 --> 00:28:56.990
lightning and they they are able to generate yield, then people will put more liquidity in lightning. So there there's a circle here of like traffic
358
00:28:57.690 --> 00:28:58.590
brings liquidity,
359
00:28:59.245 --> 00:29:09.400
liquidity provides yield, yield provides more traffic, traffic provides more liquidity. So we need to start thinking about lightning as an economical tool,
360
00:29:10.500 --> 00:29:11.000
and
361
00:29:11.460 --> 00:29:16.280
lightning, like long term, if we all want Bitcoin and lightning to be successful,
362
00:29:16.934 --> 00:29:19.755
it can't be as cheap as it is now.
363
00:29:20.774 --> 00:29:21.335
Thank you.
364
00:29:21.894 --> 00:29:26.080
Can you scoot forward just a little bit? What's that? Just scoot forward a little bit. I need to tell
365
00:29:26.780 --> 00:29:27.840
you. These guys
366
00:29:28.620 --> 00:29:29.360
think, like,
367
00:29:29.660 --> 00:29:39.475
noncustodial lightning will scale, and I just wanna talk, like, real between you between Zebi and OpenNode right now about how, like, Lightning will actually work in the future. Actually, we've, full story about liquidity.
368
00:29:39.855 --> 00:29:45.870
There were a trending that we're seeing. So we're working, like, pretty big digital wallets that today in our world.
369
00:29:46.250 --> 00:29:50.270
And we're doing is they actually are connecting to us saying, yo,
370
00:29:50.645 --> 00:30:07.680
we need to connect for launching our product. That's to some private channels because they don't want to announce first their node on network because they don't wanna get attacked like the OS. Mhmm. And then so we're doing we actually sign contracts, like legal contracts about channels, which is smart contracts, dumb real contracts? Contracts. Yeah.
371
00:30:08.035 --> 00:30:09.095
Like, real contracts.
372
00:30:09.715 --> 00:30:15.975
So it's it's a it's a trend, we're seeing. Like, we're actually, like, signing contracts about opening channels to these service providers.
373
00:30:16.770 --> 00:30:22.549
So so, you know Oh, yeah. Yeah. It's it's good. That's see. That that's a sign of maturity of lightning. Yeah.
374
00:30:22.850 --> 00:30:32.255
And I think we're gonna see that more often in the future. One one thing on the on the fees, which I it's you're absolutely right on, but I just I just happened to be looking at the numbers,
375
00:30:32.895 --> 00:30:33.875
last week. So
376
00:30:34.470 --> 00:30:35.370
Visa, Mastercard
377
00:30:35.830 --> 00:30:42.784
kind of average rates that they charge for domestic payments is like and you would know this better than me probably is you know, 1.29%
378
00:30:43.645 --> 00:30:44.625
plus 5.5¢,
379
00:30:46.044 --> 00:30:46.945
for per payment.
380
00:30:47.565 --> 00:30:52.580
I looked at, like, the top five biggest nodes on the Lightning Network, and it just so happens
381
00:30:53.039 --> 00:30:54.580
that the average fee rate,
382
00:30:55.039 --> 00:30:58.019
across those 5 nodes is, like, exactly
383
00:30:58.320 --> 00:30:58.820
90%
384
00:30:59.205 --> 00:31:05.144
of that. So it's it's the the 10 x difference. It was, like, 13 depths or something Okay. Which I think is just, like, a very interesting
385
00:31:05.765 --> 00:31:10.030
way that, you know, this this free market decentralized ecosystem has kind of coalesced,
386
00:31:10.890 --> 00:31:14.669
at a rate that is, you know, typical venture capital wisdom
387
00:31:15.125 --> 00:31:31.149
is, you know, in order for something to, you know, a new network to disrupt the incumbent, it has to be 10x better Yeah. In fees. And so I thought that was just interesting that that is kind of where the rates are right now. And it's happened it it happens very naturally because fees are your only 2 currently within the Lightning Network
388
00:31:31.450 --> 00:31:34.705
to to say, like, how do I want the liquidity flow
389
00:31:35.804 --> 00:31:37.585
to be. Like if I want
390
00:31:38.044 --> 00:31:40.625
the liquidity to flow from one end to another,
391
00:31:41.485 --> 00:31:42.465
I need to have
392
00:31:42.909 --> 00:31:43.809
lower fees.
393
00:31:44.590 --> 00:31:49.250
And if I wanted the liquidity to flow in the other way from B to A,
394
00:31:50.110 --> 00:31:54.015
if I don't want the liquidity to flow from B to A, I need to set high fees.
395
00:31:54.475 --> 00:31:54.975
So
396
00:31:56.555 --> 00:31:59.135
it's it's it's it's basically represent, like, the opportunity
397
00:31:59.435 --> 00:32:00.370
cost of
398
00:32:00.850 --> 00:32:02.309
of the liquidity. So
399
00:32:02.850 --> 00:32:04.550
and fees are the only way to control
400
00:32:05.010 --> 00:32:05.830
the the how
401
00:32:06.210 --> 00:32:11.975
how bitcoins are flowing within this lightning network. When I when I analogize lightning to to normies,
402
00:32:12.595 --> 00:32:27.955
I talk about how the channels are like roads and your fees are like your traffic lights. Okay. Right? Where it's like if you if you don't want traffic to flow down this way, you gotta hike the rate, which is like turning the light red. And if you want traffic to flow, you lower lower the rate and make the light green,
403
00:32:28.515 --> 00:32:30.855
which I think is accurate. Yeah. Yeah.
404
00:32:31.955 --> 00:32:32.755
Nice. I,
405
00:32:33.715 --> 00:32:37.409
I love that analogy. Really good. Yeah. He runs red lights. Yeah.
406
00:32:37.870 --> 00:32:43.250
Better better than my beads on a string analogy. Well, you know, but we it takes all kinds. Yeah.
407
00:32:45.424 --> 00:32:50.085
I I I did wanna talk a little bit I wanna I wanna involve this this gentleman right here
408
00:32:50.785 --> 00:32:55.820
and and say, what are what do you think the challenges are? You know, we we talked a bit about noncustodial
409
00:32:56.440 --> 00:32:58.620
liquidity, lightning service provider challenges.
410
00:32:59.720 --> 00:33:09.120
Although it doesn't fit Roy's definition to a t, the we can maybe caveat it with the non, you know, custodial Lightning providers. What what do you think the challenges are
411
00:33:09.920 --> 00:33:21.445
for people like you and I, stuff like that? I think the risk of custodial Bitcoin is the biggest challenge. I would say it's there's a huge risk to, like, hold Bitcoin. It's something that you don't want you don't wanna do.
412
00:33:23.185 --> 00:33:30.970
You know, and once you're holding Bitcoin from someone's else, there is compliance risks. There is all certain of legal stuff that you have to
413
00:33:31.270 --> 00:33:34.010
to go through, especially if your company is in the United States.
414
00:33:34.825 --> 00:33:38.125
That's why a lot of people do not make their company in the United States.
415
00:33:40.025 --> 00:33:43.645
But I would say the biggest challenge is definitely the the user onboarding
416
00:33:44.140 --> 00:33:44.640
today.
417
00:33:44.940 --> 00:33:47.840
Obviously, Kustodil makes it easier. It makes it simple.
418
00:33:48.780 --> 00:33:54.295
Is it the the solution? I don't think so it is. I think you're you guys are doing a really good job on that.
419
00:33:55.715 --> 00:34:04.610
But so far, we're still in a transition period. Right? And if you want to involve certain parties in this economy, we need to make tools that are,
420
00:34:05.150 --> 00:34:05.650
you
421
00:34:06.750 --> 00:34:07.650
know, somehow,
422
00:34:08.350 --> 00:34:09.730
easy enough for them.
423
00:34:10.395 --> 00:34:16.494
And it's a transition period. I would say, obviously, long term, the idea is to everything to make a trustless system
424
00:34:17.275 --> 00:34:17.775
noncustodial.
425
00:34:18.650 --> 00:34:20.809
But right now, we still have to go through this
426
00:34:21.289 --> 00:34:24.270
Transition phase. Transition phase. Like, people still need the dollars.
427
00:34:24.809 --> 00:34:25.390
You know?
428
00:34:25.885 --> 00:34:27.425
What about hot wallet,
429
00:34:27.885 --> 00:34:29.745
cold wallet kind of concern
430
00:34:30.525 --> 00:34:31.905
that concern you?
431
00:34:32.580 --> 00:34:36.840
That's what I was saying. It's about the risk When you look just explain the others that when you lock liquidity
432
00:34:37.300 --> 00:34:40.440
in lightning, it's being locked in a hot wallet currently.
433
00:34:41.045 --> 00:34:51.280
Yes. There's definitely so, yeah, it's basically a hot wallet where your Bitcoins are exposed somehow to, like they're online. Right? They're exposed to the Internet, to the outside world.
434
00:34:51.660 --> 00:34:53.360
While when you're doing cold storage,
435
00:34:54.220 --> 00:34:57.815
you know, the Bitcoin, your your secret, your c, your password,
436
00:34:58.435 --> 00:34:59.335
it was never,
437
00:34:59.635 --> 00:35:04.295
like, interactive maybe with a computer. So there is no way for anyone to know that password.
438
00:35:04.610 --> 00:35:06.790
And so when you're locking up funds in Lightning,
439
00:35:07.490 --> 00:35:08.790
those funds are somehow
440
00:35:09.970 --> 00:35:12.390
exposed, or there is a there is a chance,
441
00:35:13.455 --> 00:35:18.595
that, eventually, they might get stolen or not, depending on security practices. Right?
442
00:35:18.975 --> 00:35:25.530
And but I think we're coming up with tools like the remote signing, you know, things that are improving. You know,
443
00:35:27.109 --> 00:35:32.165
the the the software is is going through another phase now where, like, okay, Things are being pretty,
444
00:35:32.485 --> 00:35:35.625
risky now. Let's let's decouple the stuff
445
00:35:35.925 --> 00:35:39.225
and try to make the signing stuff like a cold storage offline,
446
00:35:39.980 --> 00:35:46.319
where you like because you every time you do a transaction aligning, you have to update the channel. And to update the channel, you need to sign a transaction.
447
00:35:46.755 --> 00:35:49.975
So, eventually, that software needs to have access to to the signer.
448
00:35:50.275 --> 00:36:02.260
The problem here is the signer. Right? You don't want to expose that entity to the outs to the Internet because then you have a threat. If you expose your password or you're not exposing your password, but there is
449
00:36:02.960 --> 00:36:05.220
there is a way that eventually someone,
450
00:36:05.785 --> 00:36:14.985
if they know enough about you, might be able to get that password. And when you do cold storage, that information is not accessible anywhere. But with the remote signing tools, I think we're,
451
00:36:16.050 --> 00:36:22.310
we're getting there. Yeah. We're getting there. Not there yet, but we'll get there. We're getting there. On the Hot Wallet risk, one
452
00:36:22.664 --> 00:36:23.665
interesting thing. So,
453
00:36:24.105 --> 00:36:31.484
we have a service liquidity service we provide called Loop, not to be confused with pool. Just you spell it backwards. You spell it backwards. Yeah. Something.
454
00:36:31.790 --> 00:36:37.310
And so Loop is, a submarine swap provider where it's a it's a bridge between on chain Bitcoin and off chain Bitcoin,
455
00:36:38.589 --> 00:36:41.575
where if you if you need more inbound liquidity, you
456
00:36:42.055 --> 00:36:45.355
send funds to Lightning Labs, and then in a noncustodial way,
457
00:36:45.815 --> 00:36:50.155
we return the funds to you on chain. One interesting use case for that,
458
00:36:50.609 --> 00:37:07.244
more so than just needing to acquire invalid liquidity is actually risk management. Mhmm. Right? If you wanna make sure that the amount of capital that you have on your node stays low that's on your side of the channels. One thing that we're seeing a lot of folks do is just continually make sure to loop out to send funds
459
00:37:08.160 --> 00:37:15.940
out of out of their custody and return it back to their on chain wallet, which I think is an interesting thing that, you know, as the network has grown,
460
00:37:16.454 --> 00:37:27.540
has become something yeah. Like, you know, all of a sudden, certain providers say, man, we have, like, a 100 Bitcoin in this node. Like, we gotta be careful. We gotta, like Start looping out. Start start looping out and start using some risk management practices, which I think is very interesting.
461
00:37:28.160 --> 00:37:31.060
Cool. And and we we've talked about a couple of things. We,
462
00:37:31.360 --> 00:37:37.115
remote signing and the what in in terms of the future of LSPs and and things to look forward to,
463
00:37:37.495 --> 00:37:39.995
what kinda like, I know we have
464
00:37:40.615 --> 00:37:41.435
Nifty here,
465
00:37:41.895 --> 00:37:43.115
Blockchain. We have
466
00:37:43.430 --> 00:37:43.930
Ryan,
467
00:37:44.470 --> 00:37:47.450
Lightning Labs that are working on implementations of Lightning,
468
00:37:48.230 --> 00:38:00.005
that kinda help enable some of these things. What what what can what can I'll tell you from a user, like, from a He's gonna tell you what he needs, and then you'll have to call it. Yeah. Exactly. The guy that's running an LSP,
469
00:38:00.310 --> 00:38:00.970
I need
470
00:38:01.270 --> 00:38:02.890
better control of my liquidity.
471
00:38:03.270 --> 00:38:04.410
I need better flexibility
472
00:38:04.790 --> 00:38:07.610
to manage my liquidity. So I think in that regard,
473
00:38:07.990 --> 00:38:09.370
I'm looking forward to splicing.
474
00:38:09.815 --> 00:38:12.875
The ability splicing is the ability to change the capacity
475
00:38:13.175 --> 00:38:14.474
of the channel dynamically
476
00:38:14.855 --> 00:38:16.234
without closing the channel.
477
00:38:16.535 --> 00:38:26.039
And, basically, if you let's say, I'll give you a very simple use case. Let's say we have a user. The user is is using Breeze to get inbound liquidity.
478
00:38:26.525 --> 00:38:27.345
So we open
479
00:38:27.885 --> 00:38:39.090
a one BTC channel to the end user. The the Bitcoin are on the user side. The user used the entire BTC to to pay for stuff. And now I I got one BTC
480
00:38:39.390 --> 00:38:46.695
locked in the channel on my end of the channel. And the user stopped using Breeze for some reason. I don't know why it's a great product, but
481
00:38:47.235 --> 00:38:47.735
but
482
00:38:48.115 --> 00:38:53.849
they stopped they stopped using Breeze, and now I got liquidity locked on my end of the channel as an LSP.
483
00:38:54.150 --> 00:38:59.210
And I need to reallocate this liquidity because I want to onboard new user using this
484
00:38:59.695 --> 00:39:04.115
BTC or I want to put this liquidity somewhere else where it generate
485
00:39:04.495 --> 00:39:08.035
a much better yield than than the user that doesn't use
486
00:39:08.415 --> 00:39:15.940
Prism anymore. So in order to take this liquidity out of the channel, I need a way to splice out, I need a way to dynamically
487
00:39:16.400 --> 00:39:18.740
configure the channel to have a lower capacity
488
00:39:19.125 --> 00:39:21.385
so I'll be able to reallocate this liquidity
489
00:39:21.845 --> 00:39:22.744
someplace else.
490
00:39:23.125 --> 00:39:31.140
Yeah. So any implementation that doesn't support splicing obviously hates Bitcoin. So what are we gonna do to fix this problem? Correlating is working on splicing.
491
00:39:32.079 --> 00:39:39.955
The great news about so the cool thing about liquidity ad stuff is a lot of the base, the background work we had to do to make liquidity ads happen,
492
00:39:41.215 --> 00:39:47.700
lends itself real easily to making splicing happen. So we are actively working on making splicing happen.
493
00:39:48.720 --> 00:39:51.140
Hopefully, that will come out at some point.
494
00:39:52.095 --> 00:39:56.915
In 2 weeks? 2 weeks. Yeah. 2 weeks. So look for it in 2 weeks. We're great. Yeah.
495
00:39:57.295 --> 00:40:06.590
So, yeah, we hear this. And I'm like, man, it's so much fun to think through all the ways that splicing lets you do wild stuff with your channels when you get it going.
496
00:40:07.690 --> 00:40:14.285
Yeah. The way that we wrote, like, some of the so the precursor stuff we had to do before we get liquidity ads is this thing that,
497
00:40:14.905 --> 00:40:19.545
calling collaborative channel opens. It used to be called dual funding, but that got a little,
498
00:40:20.810 --> 00:40:21.790
let's see, the namespace
499
00:40:22.090 --> 00:40:25.530
collision started happening so we're calling it collaborative channel opens now.
500
00:40:26.010 --> 00:40:32.035
Anyways, so all that work that we did to make that happen, you can use cool stuff where you can splice across multiple channels on the same transaction
501
00:40:32.655 --> 00:40:33.714
with multiple peers,
502
00:40:34.415 --> 00:40:35.714
on Lightning, decentralized,
503
00:40:36.015 --> 00:40:38.849
it's like cool stuff. So we're hoping to bring that to splicing
504
00:40:39.150 --> 00:40:39.809
real soon.
505
00:40:40.349 --> 00:40:42.049
That's the plan. Thank you, Lisa.
506
00:40:43.390 --> 00:40:43.890
Brian?
507
00:40:44.269 --> 00:40:44.769
Yeah.
508
00:40:46.029 --> 00:40:47.170
Same. 2 weeks.
509
00:40:47.855 --> 00:40:52.835
One is like another another side of this and as an infrastructure guy, I imagine you have thoughts on this.
510
00:40:54.015 --> 00:41:03.690
One really funny thing that happened like a year ago, as I remember talking with a bunch of lightning companies about kind of like what they what they wanted from l and d,
511
00:41:04.365 --> 00:41:05.665
in the year 2021.
512
00:41:06.525 --> 00:41:15.430
And it was the first time that instead of it being, you know, new features and and new techniques and and new cool bells and whistles, it was, you know, can we have,
513
00:41:16.290 --> 00:41:22.925
accounting software? Yeah. Can we have, you know, like, a more scalable database? Right? It's like very, like, adult requests instead.
514
00:41:23.464 --> 00:41:30.340
And so I think that's like the other lens of this is running the infrastructure and and scaling like your back end and, you know, like the post stuff,
515
00:41:31.200 --> 00:41:33.845
that we're working on, that kind of making sure that,
516
00:41:34.405 --> 00:41:39.545
just your nodes stay online, that they're, you know, easy to manage, that you have all the data that you need,
517
00:41:39.845 --> 00:41:46.910
as well, like, you know, data that you need for reporting requirements and, you know, accounting stuff, like, all of those kind of boring,
518
00:41:47.529 --> 00:41:53.535
tools as well as something that, you know, is is increasingly more in demand as lightning companies get bigger, succeed, raise money,
519
00:41:54.075 --> 00:41:57.830
and and and get more kind of That's Ryan Wade. He's saying me wait.
520
00:41:58.790 --> 00:41:59.290
So
521
00:41:59.670 --> 00:42:01.290
I said 2 weeks. Yeah.
522
00:42:01.910 --> 00:42:03.430
Yeah. I I am curious, though.
523
00:42:03.830 --> 00:42:06.970
Maybe this is something that anyone can talk about. Does
524
00:42:07.475 --> 00:42:08.935
Bolt 12 or Taproot
525
00:42:09.475 --> 00:42:14.615
affect LSPs? And if so, what way what what does what's better? Because I know, like, for instance,
526
00:42:14.920 --> 00:42:19.579
LMD is a little bit more or sorry. Not LLD. Lightning Labs is a little bit more focused on,
527
00:42:19.960 --> 00:42:20.940
supporting Taproot.
528
00:42:21.559 --> 00:42:22.059
And
529
00:42:23.414 --> 00:42:28.055
and I was just curious. Maybe we can talk about that a little bit. How in in in its relation to,
530
00:42:29.414 --> 00:42:31.170
providing service like LSP?
531
00:42:32.190 --> 00:42:35.310
Well, so I think Taproot, just from, like, a fundamental level,
532
00:42:36.270 --> 00:42:40.984
just opens up, like, a a brand of much bigger design space for what can be done,
533
00:42:41.605 --> 00:42:55.795
on lightning. I think it it enables a lot more use cases just kinda upgrading the channel commitment types and and things like that to supporting Taproot. It just it it it's more of like kind of like a a platform upgrade, so to speak, the to think of. Right? And I think,
534
00:42:56.255 --> 00:43:00.755
you know, that's kind of like a little bit of a of a longer term thing where you can think of, you know,
535
00:43:01.300 --> 00:43:06.360
for instance, I know one thing that that roast beef is working on, is the concept of dynamic commitments
536
00:43:06.740 --> 00:43:09.320
where, like, right now if you wanted to upgrade a channel,
537
00:43:10.045 --> 00:43:19.185
that's a a a normal, you know, pre Taproot channel, you would need to close the channel and then reopen a new Taproot one and spend to a new Taproot output.
538
00:43:19.720 --> 00:43:32.305
You know, working on a proposal to be able to allow that to happen. If you think about that at scale, right, there's something like 80,000 channels on the network right now, public channels, like 80,000 bitcoin transactions closing channels and then reopening would be like pretty heavy.
539
00:43:32.685 --> 00:43:37.710
But with dynamic commitments being able to do that kind of on the fly and upgrading your commitment output,
540
00:43:38.109 --> 00:43:46.355
without changing the channel is is, you know, a cool thing that then allows for, you know, wacky things like, you know, our proposal yesterday,
541
00:43:46.895 --> 00:43:49.795
Taro, which which leverages it will be Taproot Channels,
542
00:43:50.175 --> 00:43:52.915
where you can send, you know, assets that aren't Bitcoin,
543
00:43:53.530 --> 00:43:57.950
you know, say, you know, a a Fiat backed stablecoin or something like that, you could send those
544
00:43:58.410 --> 00:43:59.550
over the lightning network.
545
00:43:59.930 --> 00:44:13.060
Those channels require tapered outputs. Right? So things like that. And that proposal actually increased the demand of liquidity inside the network because these assets move between one node to the other, they're being
546
00:44:13.760 --> 00:44:14.260
Bitcoinized.
547
00:44:14.720 --> 00:44:19.244
Bitcoinizing the dollar. Yeah, exactly. That's the meme. So we need more Bitcoin
548
00:44:19.625 --> 00:44:22.285
collateral in order to facilitate new assets
549
00:44:22.744 --> 00:44:27.050
that will increase the demand of having more liquidity in the Lightning Network.
550
00:44:27.690 --> 00:44:28.190
Yep.
551
00:44:29.690 --> 00:44:31.930
Nifi or John, did did you wanna chime in on
552
00:44:32.650 --> 00:44:50.340
I would say privacy. Right? I think it's the Yep. I mean, the big one here. It's the basic one. Taproot will bring privacy to lightning, because today, you can literally look at on chain and see what channels were closed and kinda figure out liquidity and what's happening. And with Tapware, it's gonna look like another transaction.
553
00:44:50.800 --> 00:44:52.480
So I think that's a big win. With,
554
00:44:53.585 --> 00:44:54.484
That's well,
555
00:44:55.105 --> 00:45:03.125
we're gonna talk about privacy more on Friday. I'm doing a privacy panel. We'll get way into that. I'm gonna push back and say that just upgrading the Taproot
556
00:45:03.730 --> 00:45:07.970
outputs isn't actually gonna solve the privacy problem. It's
557
00:45:08.610 --> 00:45:11.990
I think the biggest thing is moving to blinded routes in bolt 12.
558
00:45:13.015 --> 00:45:22.950
Right now, no one cares about on chain footprint. If you're handing them an invoice, it tells you where the payment's going, what you're paying for, how much it's for. Like, you don't even have to look at the chain if you give someone an invoice.
559
00:45:23.329 --> 00:45:23.829
Like,
560
00:45:24.690 --> 00:45:27.270
so I think Taproot's cool. I think, like,
561
00:45:27.855 --> 00:45:29.955
lightning's gonna get to Taproot soon.
562
00:45:31.055 --> 00:45:39.760
Upgrading it, doing dynamic commitments is, like, an awesome thing. Miners might not like it so much, as the people running the channels, but, you know, that's fine.
563
00:45:40.859 --> 00:45:44.515
But yeah. Anyways, like, Taproot's cool. It's coming.
564
00:45:44.915 --> 00:45:46.535
Really excited about the,
565
00:45:47.075 --> 00:45:52.710
novel engineering that Labs is doing with Taproot stuff, and excited to see how that goes. But
566
00:45:53.990 --> 00:46:02.570
yeah. Okay. We have a few minutes left. Do you wanna do closing thoughts? Do you wanna maybe start with Juwan? I wanna ask Oh. URL versus ball 12.
567
00:46:03.005 --> 00:46:10.225
Oh, okay. Well, let's rephrase the question real quick. Instead of doing closing thoughts, let's just do lnurl versus ball 12. Let's get into it.
568
00:46:12.260 --> 00:46:20.265
Let's let's let's I'll I'll I'll I'll sit here. Y'all y'all go for it. Yeah. Just from a service provider, there's a lot of demand for this type of stuff.
569
00:46:20.585 --> 00:46:23.085
So I know lining at Lightning Labs is a position.
570
00:46:23.865 --> 00:46:26.525
See, lining has the the other position. So I'm
571
00:46:26.984 --> 00:46:30.045
just curious to hear both your thoughts about why
572
00:46:30.410 --> 00:46:36.350
you want to invest in Bold 12 and why you don't want to invest in Bold 12 right now. Just curious. I'm the moderator now.
573
00:46:40.735 --> 00:46:44.435
So, you know, like, I like, Lalu Lalu published his his thoughts,
574
00:46:44.895 --> 00:46:47.855
on this, and I think he stated it well. It's like we're,
575
00:46:48.750 --> 00:46:53.170
you know, a small team. We have something like 26 people. There's there's only so many engineers,
576
00:46:53.870 --> 00:46:55.490
and, like, the priority is
577
00:46:55.790 --> 00:46:58.565
is doing Taproot stuff. And I think in particular
578
00:46:59.265 --> 00:47:01.365
one thing that we've talked a lot about
579
00:47:01.744 --> 00:47:02.244
is
580
00:47:03.664 --> 00:47:14.240
responding to the developers in particular that are building on our stuff. And we haven't had a bunch of developers beating down our door saying, this is wrong, we need you to focus on Vault 12 instead,
581
00:47:14.565 --> 00:47:16.665
Right? Because they're kinda happy with lnurl.
582
00:47:17.365 --> 00:47:21.940
Right? And I you know, like, it's it's it's bad business to tell your customers that they're wrong.
583
00:47:22.579 --> 00:47:31.855
And so that's you know, we're we're focused on Taproot, and I think that's that's gonna it. I think I don't I don't and I I wanna be clear. Like, I don't think we think whole 12 is necessarily
584
00:47:32.395 --> 00:47:37.055
a bad proposal. I think blinded routes are great. I think the static invoice is great.
585
00:47:37.995 --> 00:47:42.450
There's a bunch of good stuff in there. It's just not the priority for this quarter.
586
00:47:43.870 --> 00:47:46.530
I think we need both. I think we need both
587
00:47:47.365 --> 00:47:49.065
will facilitate payments between
588
00:47:49.365 --> 00:47:53.945
peers in the network without the need to have an HTTP web server.
589
00:47:55.280 --> 00:47:57.380
And Allen URL is great for
590
00:47:57.920 --> 00:48:07.444
for custodial services that has that have online presence, and it's great for merchants that have web presence. So whenever you have a web server,
591
00:48:07.744 --> 00:48:12.039
you can definitely build on ln, ln URL, but it doesn't solve
592
00:48:12.339 --> 00:48:14.680
the problem of the the ability
593
00:48:15.299 --> 00:48:18.839
to send payments to other user in the network without
594
00:48:19.214 --> 00:48:22.434
creating an invoice first. And for that, we need bolt well.
595
00:48:23.454 --> 00:48:24.994
And you still do have to, like,
596
00:48:25.375 --> 00:48:36.935
generate an invoice, Right? For both of them. Like, you have the static part, but you still need to go and actually fetch You need a pointer you need a pointer to to begin with, but the pointer doesn't need to be, like,
597
00:48:37.555 --> 00:48:51.760
an an HTTP server. Right? Yep. It's like AMP. What's the difference between, like, the essential core difference between both wealth and AMP? It's the ability to have proof of payment. That's, like, for me the big difference between both. And you guys have
598
00:48:52.060 --> 00:48:52.560
AMP
599
00:48:53.244 --> 00:48:58.065
and you don't have both 12. Well, but I think it is a little bit different because you still do need to do
600
00:48:58.605 --> 00:49:08.530
invoice fetching with both 12. Right? Like, you still do need to, like, get a secret to pay whereas with amp it's actually static like there is no interaction required you can just pay to a
601
00:49:09.835 --> 00:49:13.454
receive the pop key from somewhere. You again, you need a pointer. Hey.
602
00:49:14.315 --> 00:49:17.775
Not not to not to interrupt. The family conversation here,
603
00:49:18.315 --> 00:49:21.559
because I I I love this. And and and, you know, I feel like,
604
00:49:22.900 --> 00:49:27.720
we we we should have a bolt 12, l and euro pay kind of discussion, maybe. Fight.
605
00:49:28.225 --> 00:49:35.765
We need we need fiat, Jeff. We we we need yeah. We need we should like, WWE people start sliding in, bringing in chairs and stuff. But
606
00:49:36.380 --> 00:49:39.920
I we're we're out of time. I wanna I just wanna give everyone
607
00:49:40.380 --> 00:49:45.519
a few seconds just to do, like, a closing. How do people know about you if you wanna show your Twitter, if you wanna
608
00:49:46.015 --> 00:49:48.755
let people know how to follow you, whatever it might be?
609
00:49:49.055 --> 00:49:52.994
Yeah. Yeah. You can find us, open note dot com or open it on Twitter.
610
00:49:53.359 --> 00:49:57.380
You can find me, Zhuang Almeida. It's a hard name, so you're not gonna find it.
611
00:49:58.320 --> 00:49:59.859
Yeah. You can find me on Twitter.
612
00:50:01.904 --> 00:50:03.684
Yeah. I'm nifty n I
613
00:50:04.065 --> 00:50:06.244
f t y n e I, if you wanna,
614
00:50:06.785 --> 00:50:07.845
follow my Twitter.
615
00:50:09.020 --> 00:50:11.680
I also work with core lightning. So core_ln
616
00:50:12.780 --> 00:50:15.440
is our lightning node implementation. I work at Blockstream
617
00:50:15.740 --> 00:50:17.599
who obviously is also on Twitter.
618
00:50:18.895 --> 00:50:23.635
Yeah. You can find me on the Breeze various handles at Twitter, Breeze_tech.
619
00:50:24.895 --> 00:50:25.395
Breeze.technology.
620
00:50:26.335 --> 00:50:28.119
That's our website. You
621
00:50:28.579 --> 00:50:30.280
can join our Telegram group,
622
00:50:31.859 --> 00:50:32.359
Breeze.
623
00:50:32.819 --> 00:50:35.799
Breeze spelled b r e Without a c. Yeah. Without
624
00:50:36.135 --> 00:50:37.675
an e at the end. Yeah.
625
00:50:37.975 --> 00:50:39.595
Yeah. I'm Ryan Gentry.
626
00:50:40.135 --> 00:50:42.155
Ryan the Gentry on Twitter.
627
00:50:43.015 --> 00:50:44.075
Follow us on
628
00:50:44.530 --> 00:50:46.150
on Twitter as well at at lightning,
629
00:50:46.850 --> 00:50:48.790
and the website is lightning dot engineering.
630
00:50:49.890 --> 00:50:51.250
Thank you, Michael, for,
631
00:50:51.755 --> 00:50:55.454
such a well moderated How can we find you, Michael? Yeah. How can we find you?
632
00:50:55.914 --> 00:50:59.855
I'm Mike 20 spelled out with a 1 on the end. It's so obvious.
633
00:51:00.359 --> 00:51:00.759
And,
634
00:51:01.160 --> 00:51:01.660
I'm
635
00:51:02.200 --> 00:51:13.335
not that popular, but for some reason, they have tons of scammers. I'm not giving away free Bitcoin. And when when when's the Tapcom? The next Tabconf? If you well, not to shill too much because we're at a conference, but,
636
00:51:13.975 --> 00:51:19.359
Tabconf is a technical focused conference in Atlanta, Georgia. It's gonna be in October. Tabconf, tabconf.com.
637
00:51:22.140 --> 00:51:25.119
Yeah. Thanks for helping me show that, I guess. Yeah. Just go on.
638
00:51:27.075 --> 00:51:29.575
Yeah. Oh, alright. Thank you, everybody. Thanks for coming.
639
00:51:35.970 --> 00:51:36.470
Alright.
640
00:51:38.050 --> 00:51:44.230
So this is the future of lightning development panel. Sadly, we lost our our illustrious moderator,
641
00:51:45.005 --> 00:51:51.184
who couldn't make it to Miami in time. So instead, I get to moderate these these two lovely folks.
642
00:51:52.390 --> 00:51:55.450
So why don't we start with Hannah and we can do quick intros
643
00:51:55.830 --> 00:52:05.025
of who you are and what you work on, and then we'll dive right in. Cool. I'm Hannah Rosenberg. I work as a developer advocate at Lightning Labs, and I've been,
644
00:52:05.885 --> 00:52:11.540
say, in the Bitcoin space a while and obsessed with Lightning since it came out. So delighted to be here talking about it.
645
00:52:12.320 --> 00:52:14.260
Yeah. Hi. I'm Chris. I,
646
00:52:14.880 --> 00:52:18.445
been in this space for a long long long
647
00:52:18.905 --> 00:52:20.525
time, 20, 2009.
648
00:52:21.465 --> 00:52:27.005
And my hobby became my job. So now I'm working for Blockstream on for Lightning.
649
00:52:28.090 --> 00:52:29.150
And I'm Matt.
650
00:52:29.850 --> 00:52:33.390
Sadly, Christian predates me a little bit, but I did get into Bitcoin in in 2011.
651
00:52:34.090 --> 00:52:35.390
I have the the illustrious
652
00:52:35.785 --> 00:52:39.165
claim to fame of I actually wrote the 1st payments channel implementation
653
00:52:39.945 --> 00:52:45.160
anywhere long before lightning and before we had routing or or in fact bidirectional payment channels.
654
00:52:45.540 --> 00:52:52.523
And I don't think anyone ever used it. But that's okay. Oh, that's good. You're you're the only one. We had a student project working on it. So
655
00:52:52.927 --> 00:53:00.200
Oh, alright. Well, good. It was it was usable. Good job. Thanks. I might have tested it once.
656
00:53:01.160 --> 00:53:02.619
So we're gonna we're gonna
657
00:53:03.240 --> 00:53:05.020
talk very briefly about,
658
00:53:05.400 --> 00:53:09.900
kind of the history of lightning and how how it's grown, and then we're gonna get into
659
00:53:10.345 --> 00:53:11.725
how we see it maturing
660
00:53:12.025 --> 00:53:12.925
and and
661
00:53:13.705 --> 00:53:14.605
going from there.
662
00:53:15.065 --> 00:53:20.770
So I don't know if who wants to start with Hannah, you can start with that one. This one. This I think the past year
663
00:53:21.150 --> 00:53:23.490
just since we were I was at this conference,
664
00:53:23.869 --> 00:53:30.065
last year and until now, like, just watching the explosion in lightning. And it's been really interesting to me
665
00:53:30.444 --> 00:53:35.980
to watch lightning progress from, you know, just a proof of concept where everyone was like, is this even going to work?
666
00:53:36.280 --> 00:53:38.859
To, you know, then being very much in the hobbyist
667
00:53:39.480 --> 00:53:40.619
enthusiast territory,
668
00:53:40.920 --> 00:53:52.230
you know, where you're on the command line and, you know, only people that are, you know, nerdy enough to be on the command line can use it. So then we get much more user friendly stuff going on. And then now it's moved from
669
00:53:52.770 --> 00:53:53.270
hobbyists
670
00:53:53.570 --> 00:54:05.860
more into, you know, businesses really attempting to use this in their products and services and just spend this huge explosion, and and it's been really amazing to watch and to think about where it might go from here.
671
00:54:07.780 --> 00:54:08.280
Yeah.
672
00:54:09.380 --> 00:54:19.825
I would I would go further and say, like, yeah, it it's specializing. Right? So it it's it's gone from hobbyist, but they still exist. They're still there. They're still running running ClubNet and it's still routing a lot of payments.
673
00:54:20.365 --> 00:54:22.385
And we have so I I now work for
674
00:54:22.839 --> 00:54:28.460
for, I guess, Block is now our name, not on Cash App, but but, you know, Cash App now it's deployed
675
00:54:28.839 --> 00:54:29.660
deployed lightning,
676
00:54:29.960 --> 00:54:38.325
and that's that's a whole different world. And we just had the LSP panel and the mobile lightning world and the the LSPs also need a whole different set of things.
677
00:54:39.480 --> 00:54:43.820
So let's let's kinda split up the future of lightning development by those categories
678
00:54:44.120 --> 00:54:46.060
and then kinda dive in from there.
679
00:54:47.435 --> 00:54:49.775
So let's let's start with mobile. So,
680
00:54:50.555 --> 00:55:01.329
you know, we just had a bunch of discussion about LSPs and what they need, but maybe let's look more towards the future and talk about, you know, what what do these mobile clients themselves need. Yeah.
681
00:55:02.485 --> 00:55:03.465
Yeah. And I,
682
00:55:04.485 --> 00:55:06.505
LDK is a fabulous
683
00:55:07.045 --> 00:55:11.970
tool for mobile. That's really cool. And we're also talking about the problems,
684
00:55:12.990 --> 00:55:14.530
with mobile payments,
685
00:55:15.150 --> 00:55:25.695
enlightening, sort of sort of an app having to be on, you know, to receive a payment, which is a big issue at the moment. And then just trying to shove a lightning node
686
00:55:26.430 --> 00:55:29.650
into a mobile application is certainly quite a challenge.
687
00:55:30.510 --> 00:55:31.410
But that's why
688
00:55:31.710 --> 00:55:55.255
you know all the time you know it's like sorry I'm just gonna go off on this tangent, but it's like I love that, you know, I've spent so much time being obsessed with lightning and it's only been in the past year that when people come up to me and ask me, hey, Hannah, can you do x y and z on Lightning? I don't have to tell them theoretically, yes. I can tell them, yes, you can, and here's the library you should use to do that. And so that's been a really amazing change in the past year. But there's still
689
00:55:55.795 --> 00:55:56.695
this big issue,
690
00:55:57.155 --> 00:56:24.890
with with mobile payments that I don't know if any want to dive into that a little bit. But essentially, I think one of the problems there is just getting an app to, you know, because you have to be online to have payments. And one of the issues there is just how do you get that app to be online to receive payments? How do you solve that problem? And then shoving a note into a mobile application is not a problem. Yeah. Yeah. I I think we do see a lot of experimentation going on especially now, with regards to how do we want to integrate lightning into
691
00:56:25.224 --> 00:56:27.964
mobile apps, into web apps, into whatever.
692
00:56:29.224 --> 00:56:38.359
And, the experimentation we're seeing right now is, is going in direction of do we want to really want to shove a full node into, into a mobile app,
693
00:56:38.819 --> 00:56:39.880
potentially segmenting
694
00:56:40.180 --> 00:56:47.145
your funds across a multitude of app, basically locking in, the users into an individual app so making it hard to experiment.
695
00:56:48.085 --> 00:56:50.825
Or do we want to have a more centralized node
696
00:56:51.285 --> 00:57:02.945
that is still operated and run by you and where we just remote into it and, and I think those those are the trade offs we are currently seeing explored and we will see, how these work out in the future.
697
00:57:03.565 --> 00:57:22.244
Yeah. And and we also see, like, you know, we were talking about the the online requirements. I mean, obviously, if I I guess I can say this, you know, Cash App's, like, almost all of their payment failures are just the app wasn't open. It was being sent to a mobile client. The app wasn't open, and they didn't get the payment because the app wasn't open.
698
00:57:22.865 --> 00:57:25.025
So having having better logic there and then,
699
00:57:26.610 --> 00:57:37.775
enabling more you know, we've kind of seen this this first generation of mobile wallets that all kind of have this simple, you know, we took a lightning node or at least a payment channel and we put it in an app,
700
00:57:38.475 --> 00:57:42.415
and we shipped it and it works pretty well and we have this LSP and we wrote out payments through it and whatever.
701
00:57:42.875 --> 00:57:51.190
But, you know, we haven't gone down the route of, like, okay, well, what if we have, like, a server assist more server assisted lightning node, like,
702
00:57:51.515 --> 00:57:54.575
green light and like some of the other things core lightning is working on,
703
00:57:54.875 --> 00:57:56.575
and what it you know, do we have,
704
00:57:57.435 --> 00:57:58.895
better protocols for,
705
00:57:59.549 --> 00:58:00.770
papering over this,
706
00:58:01.150 --> 00:58:07.965
on chain requirement? Right? So I I had that proposal, whatever, 6 months ago, and we're still long ways from implementing it
707
00:58:08.685 --> 00:58:12.305
to do use onion messages as a base for doing,
708
00:58:14.285 --> 00:58:15.425
on doing payments
709
00:58:15.740 --> 00:58:19.440
such that you can kind of hide the fact that the nodes have to be online
710
00:58:19.820 --> 00:58:21.440
synchronously to receive the payment.
711
00:58:22.060 --> 00:58:24.080
And and you can actually do
712
00:58:24.914 --> 00:58:35.410
offline kind of payments, but, like, you know, it goes out and it sits pending, and then, you can actually receive it without it sitting pending across an entire route across the lightning network, and holding that capacity
713
00:58:35.869 --> 00:58:39.569
for, you know, potentially hours or days until the user opens their phone.
714
00:58:40.575 --> 00:58:47.635
So there's still, you know, we we finally have lightning on on phones, but we still have a lot to go to actually
715
00:58:48.089 --> 00:58:51.150
fix a lot of these UX issues that we've run into.
716
00:58:52.730 --> 00:58:57.230
And Yeah. And it So I say that, you know, lightning is is now usable,
717
00:58:57.735 --> 00:59:00.795
like in production in real services but just barely.
718
00:59:01.575 --> 00:59:06.850
Yeah it's it's definitely not smooth and and there there is a lot of infrastructure that we are working on
719
00:59:07.970 --> 00:59:12.150
and I'm speaking for all implementations here of course not just just core lightning.
720
00:59:12.930 --> 00:59:13.430
That
721
00:59:14.215 --> 00:59:17.995
where we are learning from the experience of operating lightning nodes
722
00:59:18.375 --> 00:59:18.695
of,
723
00:59:19.255 --> 00:59:19.915
of basically
724
00:59:20.295 --> 00:59:24.880
providing users with the ability to to make more of their lightning nodes
725
00:59:25.340 --> 00:59:25.840
and
726
00:59:26.300 --> 00:59:29.440
this experience will flow back into the spec process as well
727
00:59:31.195 --> 00:59:34.735
and inform where the directions are going to go in the future.
728
00:59:35.595 --> 00:59:36.495
And that
729
00:59:38.890 --> 00:59:44.190
it is going to continue to be interesting, you know, as the the amount of resources required
730
00:59:44.650 --> 00:59:46.430
to kind of maintain a lightning node
731
00:59:47.515 --> 00:59:56.970
will only continue to grow as we have multiple different completely divergent use cases for lightning. We have, you know, whether it's people trying to run it in enterprise
732
00:59:57.430 --> 01:00:19.670
and who want, you know, features that might help them, people trying to run it on mobile. And then you want to add onion messages and, like, onion message mailboxes so that you can do, you know, be offline all the time. All of a sudden you have all of these new features coming in that all the lightning implementations are at least kind of mostly need to support or at least look at it and and add chunks of it so that things can be interoperable.
733
01:00:21.250 --> 01:00:25.875
Just the the amount of resources required to maintain a lightning node is only gonna continue to increase.
734
01:00:26.655 --> 01:00:27.694
It's already whatever
735
01:00:28.255 --> 01:00:36.079
I think all the major implementations have at least 3 or 4 engineers full time on it, and that presumably will only continue to grow.
736
01:00:36.405 --> 01:00:41.385
Absolutely. So so there is definitely a scaling up of the engineering side of, of things,
737
01:00:42.165 --> 01:00:58.325
but I do think that, by us basically, as as Lightning implementations, concentrating on a common kernel that sort of builds the basis for all of the applications that we build on top. And I've been often asked what what sort of is the coolest thing you can imagine doing with lightning, and I usually
738
01:00:58.705 --> 01:01:05.180
say that I'm not the right one to ask. I'm I'm I'm the kernel guy. I'm not I'm not the cool fancy UI guy. So,
739
01:01:06.119 --> 01:01:12.825
but I think that, that keeping that kernel small will help us basically provide a basis for for whatever comes next
740
01:01:13.125 --> 01:01:13.785
and whatever
741
01:01:14.405 --> 01:01:16.345
maybe these guys will build here.
742
01:01:16.799 --> 01:01:17.299
Yeah.
743
01:01:17.760 --> 01:01:25.380
So let's talk a little bit about, you know, we talked a little bit about mobile, let's talk about kind of LSPs. Obviously, we we just had an LSP panel,
744
01:01:25.955 --> 01:01:26.855
but but what
745
01:01:27.955 --> 01:01:29.895
features in the lightning protocol
746
01:01:30.355 --> 01:01:31.175
might be needed,
747
01:01:31.875 --> 01:01:32.375
for
748
01:01:32.700 --> 01:01:36.000
looking towards LSPs and but the future of development
749
01:01:36.620 --> 01:01:37.120
that
750
01:01:37.420 --> 01:01:40.080
we have to do on a lower level might be needed for
751
01:01:40.445 --> 01:01:40.945
those
752
01:01:41.245 --> 01:01:43.825
services in the, over the next few years?
753
01:01:44.605 --> 01:01:47.185
I think very much of the groundwork is,
754
01:01:47.885 --> 01:01:49.105
is already started
755
01:01:49.610 --> 01:02:01.225
with with the liquidity ads, which is, which is a way for you to signal the availability of funds and the, and the readiness of of allocating those funds to a, to a channel that you'd
756
01:02:01.625 --> 01:02:03.165
that somebody would like to open.
757
01:02:03.839 --> 01:02:06.099
And I think that is sort of the direction that
758
01:02:06.400 --> 01:02:08.420
I would like to see things going forward
759
01:02:08.720 --> 01:02:12.180
where we have an open marketplace where everybody can participate,
760
01:02:12.515 --> 01:02:13.815
where there is no mediator,
761
01:02:14.675 --> 01:02:16.135
where we can
762
01:02:16.515 --> 01:02:18.615
just exchange our interest in
763
01:02:18.915 --> 01:02:21.495
opening or closing channels and what
764
01:02:22.230 --> 01:02:24.809
the set of costs are for for that.
765
01:02:25.270 --> 01:02:26.410
I mean, I guess that divides
766
01:02:26.789 --> 01:02:29.289
LSPs a little bit even further. Right? From,
767
01:02:29.885 --> 01:02:33.105
from from service providers who might be providing service to,
768
01:02:34.205 --> 01:02:52.135
hobbyist nodes or plug in nodes or always online nodes versus service providers who might be providing services to to mobile where, you know, some people might expect to use your experience where your client accepts the 0 cons thing. Right? Where suddenly you you need to actually know who your counterparty is. You can't just, you know, go to a liquidity ad and and select whoever.
769
01:02:52.515 --> 01:03:03.330
You do actually have to have some counterparty you have some amount of trust in. But but I mean that's that's very much part of signaling. Right? Their kind of channels are basically just a feature that you can signal.
770
01:03:04.385 --> 01:03:12.165
Having an identity attached to a liquidity add is something that you can use to basically make a decision of hey is this provider
771
01:03:12.640 --> 01:03:17.200
well connected in the network? Do I do I trust him to be a good,
772
01:03:17.599 --> 01:03:19.220
good counterparty for my channel?
773
01:03:20.455 --> 01:03:21.835
And that is
774
01:03:22.455 --> 01:03:28.315
basically just an additional information that we have to convey to whoever might take you up on the offer.
775
01:03:29.360 --> 01:03:33.380
So I don't think that different protocols here are in the solution.
776
01:03:35.360 --> 01:03:37.860
Yeah. No. I so I think
777
01:03:40.335 --> 01:03:43.955
it is ultimately up to the people building the user experiences, building the apps,
778
01:03:44.655 --> 01:03:46.970
what kind of UX they want there.
779
01:03:47.590 --> 01:03:48.730
Obviously, exposing
780
01:03:49.750 --> 01:03:50.250
different
781
01:03:50.630 --> 01:03:54.890
possible trust relationships to users tends to be a pretty poor user experience.
782
01:03:55.734 --> 01:04:00.214
Like, hey, you can pick between these nodes, and here's some information about whether you should trust them.
783
01:04:00.695 --> 01:04:08.069
You know, PGP Web of Trust kind of failed for a reason. PGP is great, but the Web of Trust part never went anywhere. Well, you know, the average user,
784
01:04:08.369 --> 01:04:27.750
you know, at least I think going forward in the future, right, the average user doesn't, you know, want to know anything about what's going on underneath. So it's important to extract that away for people as the Lightning Network continues to grow in use. But also with the different ways to do liquidity, again, you know, there's different use cases and different, you know, different users are gonna have different,
785
01:04:28.385 --> 01:04:29.925
you know, things they care about,
786
01:04:30.225 --> 01:04:45.390
in get gathering liquidity. And why do we need the liquidity? Is this a business that's accepting incoming payments? Is it a routing node? Like, what's the use case? So it's just things are getting just bigger and bigger. So it's, you know, now we get little pockets and different use cases here and there. Yeah. And, I mean, I think
787
01:04:45.885 --> 01:04:50.625
in the medium term and definitely in the long term, one thing I'm I'm really looking forward to the most
788
01:04:50.925 --> 01:05:16.350
is a proliferation of more different lightning apps and different lightning user experiences. And I think Yeah. You know, certainly that's that's kind of our pitch. Right? I mean, speaking from the LDK end, it's kind of our pitch of, like, look, we're gonna, like, do all the hard parts for you, and then you focus on how do you want to build a user experience around lightning? How do you want to, you know, do you wanna have 0Conf with which nodes? And do you want to use liquidity ads? And do you want to use this or that and whatever?
789
01:05:18.010 --> 01:05:23.875
And so, you know, maybe I'm a little biased, but like I'm looking forward to a world where we have, like, you know, some
790
01:05:24.255 --> 01:05:26.835
apps and some desktop clients, or
791
01:05:27.380 --> 01:05:32.359
browser extensions or mobile clients or whatever that use greenlight, and some of them that that
792
01:05:32.660 --> 01:05:44.305
let you choose which node to connect to and expose this whole, like, market place of liquidity ads, and some that, like, abstract a lot of that away, and then some that, like, just always connect to the predetermined LSP or whatever. Right.
793
01:05:44.684 --> 01:05:46.065
And kind of this this
794
01:05:47.310 --> 01:05:56.295
Cambrian explosion, I hope, is coming eventually, where we can have a lot of different options, and we can kind of see what succeeds in the marketplace while all still having,
795
01:05:56.835 --> 01:05:57.494
you know,
796
01:05:57.954 --> 01:06:19.525
this common base of, you know, one of these lightning implementations that's robust and tested and and has implements a lot of these features so that users can pick and choose kind of which ones they want. Kind of developers can pick and choose which ones they want. And the more tools that are out there, you know, the better to fit different use cases and all of this stuff. And it's yeah. I I also foresee sort of this explosion where I just
797
01:06:19.980 --> 01:06:29.775
imagine, you know, 5, 10 years from now, we'll have we'll be using lightning, you know, on the back end of quite a lot of different services, whether it's, you know, buying things online,
798
01:06:30.555 --> 01:06:31.695
streaming things,
799
01:06:32.315 --> 01:06:32.815
authenticating,
800
01:06:33.595 --> 01:06:34.975
for services, etcetera.
801
01:06:35.470 --> 01:06:36.670
So Yeah. Definitely.
802
01:06:37.150 --> 01:06:43.970
So so I definitely do share your your sentiment that, that we sort of will have a common core that we can pick and choose from.
803
01:06:44.845 --> 01:06:46.385
With Greenlight, we chose to
804
01:06:46.845 --> 01:06:52.625
take a bit of a different cut, where you guys are doing API level composition, basically.
805
01:06:53.570 --> 01:06:57.110
The thing that, that we want to do is basically provide a core node,
806
01:06:57.890 --> 01:06:58.790
hence the name,
807
01:07:00.265 --> 01:07:06.365
and, and allow users to, basically, then connect to it and, and experiment with different use cases.
808
01:07:07.224 --> 01:07:10.910
So we are going back to, basically, this topic of special, specialization
809
01:07:11.290 --> 01:07:11.790
where,
810
01:07:12.090 --> 01:07:24.095
where we as the lightning developers are sort of in charge of, of operating lightning node, the stuff that we do best, and freeing developers from actually having to even learn all of the intricacies
811
01:07:24.474 --> 01:07:24.795
of,
812
01:07:25.275 --> 01:07:26.015
of building
813
01:07:26.474 --> 01:07:29.055
both a beautiful UI and UX
814
01:07:29.560 --> 01:07:33.820
and managing a lightning node that has has to be bundled with with your app. So,
815
01:07:34.360 --> 01:07:39.100
and hopefully by by basically removing this this need to bundle
816
01:07:39.464 --> 01:07:44.984
a lightning node with your app, you're also freeing the user to basically experiment and jump from 1,
817
01:07:45.545 --> 01:07:47.565
front end application to another one
818
01:07:47.910 --> 01:07:53.130
And, whereas if you bundle the node with with the, with the app itself,
819
01:07:53.990 --> 01:07:57.565
trying out a new app means setting up a full, you know, so
820
01:07:58.205 --> 01:07:59.425
Yeah. I mean, that's that's
821
01:07:59.885 --> 01:08:24.030
always that that kinda highlights that debate that's been around forever in the lightning world of, like, do you have, you know where do you put the the node? Right? Do you have kind of the, I would say, the earliest designs and the earliest focus was kind of you everyone would host their own node at home on our Raspberry Pi, and everyone would give kind of part partial remote control access to that node to every app or whatever via, you know, this
822
01:08:24.889 --> 01:08:26.989
this the LND has the macro and system and
823
01:08:27.449 --> 01:08:31.389
and Corelightning has some similar stuff. Now you can do it over onion messages too.
824
01:08:33.175 --> 01:08:44.579
And you have kind of that world, and then you have this kind of movement towards well, you know, people actually seem to really like this UX of having a a node or at least having payment channels locally in in Moon or Breeze
825
01:08:44.880 --> 01:08:45.699
or or Phoenix,
826
01:08:46.559 --> 01:08:48.179
or maybe there's a few others.
827
01:08:49.405 --> 01:08:50.065
And then,
828
01:08:50.365 --> 01:08:52.305
kind of, maybe moving back,
829
01:08:52.685 --> 01:09:01.140
like, kind of the the core lightning, the the green light design's a little bit in between. Right? It's, hosted, but some of the signing is local, so there's less trust in the server.
830
01:09:01.600 --> 01:09:07.219
Or, you know, you keep it all hosted locally and do it. So I think,
831
01:09:07.824 --> 01:09:09.764
you know, as much as there's
832
01:09:10.945 --> 01:09:21.929
value in there being a standard and everyone doing the same thing, I think we're just gonna see different experiment. We're different we're gonna see different things. We're gonna see people use green light, and that's gonna be great. And then we're gonna see people who continue to have the the
833
01:09:22.230 --> 01:09:26.250
channels on the phone, and that's gonna be great for for those. And so, you know Well,
834
01:09:26.605 --> 01:09:43.290
and and and we have by no means seen all of the possible combinations. Right? No. A lightning node is very complex. It has very, very many, components, and you can basically distribute these components however you want. Right. With with Greenlight, we chose to have the node itself on, on a hosted system
835
01:09:43.665 --> 01:09:47.844
and the signer and the front end on on a different device. Maybe some, some other combination
836
01:09:48.145 --> 01:09:55.080
makes more sense. Yep. And, and we're just starting to see how these deployment strategies can work out.
837
01:09:55.460 --> 01:09:55.860
And,
838
01:09:56.260 --> 01:10:02.680
I'm very much looking forward to to seeing how all of this works out. Yeah. So we spent a little time talking about
839
01:10:03.275 --> 01:10:05.375
mobile and then a little bit of time talking about
840
01:10:05.915 --> 01:10:09.615
LSPs and getting into this kind of mobile and and server assisted model.
841
01:10:10.235 --> 01:10:18.320
Let's let's switch gears and talk a little bit about, like, what future designs and what future things have to come for the kind of enthusiasts to plug that nodes,
842
01:10:19.100 --> 01:10:20.560
this world. You know, what
843
01:10:20.865 --> 01:10:27.685
what what do we need to add to make that even better experience, and and where does that world go in the next year or 3?
844
01:10:28.040 --> 01:10:30.540
Yeah. Yeah. Pubnet is is awesome,
845
01:10:31.000 --> 01:10:49.460
especially, I think, because they're just enthusiasts that, like, test things out for us. You know? Like, they're just trying all the things, and then they report back. You know? You yeah. Go in the, Telegram groups, you know, and see what people are having trouble with, and it it's fabulous. You know, to have this group of enthusiasts that test things out. I think there's a lot of tools,
846
01:10:50.080 --> 01:10:51.060
you know, for,
847
01:10:51.680 --> 01:10:52.260
you know,
848
01:10:53.235 --> 01:10:58.455
for those enthusiasts, you know, things like Umbrel and, you know, my note and all those sorts of things.
849
01:10:58.755 --> 01:11:00.215
And I think a lot of them,
850
01:11:00.835 --> 01:11:01.330
wants
851
01:11:01.730 --> 01:11:03.430
to, you know, they get to sort of
852
01:11:03.810 --> 01:11:07.590
build with lightning. Right? And so when you make things that are really reliable,
853
01:11:08.130 --> 01:11:09.350
that they can just reliably
854
01:11:09.890 --> 01:11:20.600
use this to run their node or to manage their node and have these tools for liquidity. And then they get to experiment with building things on top of that. And that's really, really valuable, I think, to have that constant experimentation and testing
855
01:11:20.980 --> 01:11:21.720
in the space.
856
01:11:22.740 --> 01:11:30.315
Yeah. I think there, there is a point to be made that that we definitely need more tooling to to surface some of the information about your node as well,
857
01:11:31.815 --> 01:11:35.994
to really have an objective measure on, on what works and what doesn't.
858
01:11:36.620 --> 01:11:46.364
For the longest time we have, we have heard that rebalancings work, rebalancings don't work. How do how much do you spend on rebalancing? Should we make rebalancing free?
859
01:11:47.065 --> 01:11:49.485
How much privacy do we leak with that?
860
01:11:50.264 --> 01:11:54.780
Do we even care about leaking some privacy if it's not our own payments?
861
01:11:55.480 --> 01:11:58.680
Or do we use rebalancings to provide cover,
862
01:11:59.080 --> 01:12:00.995
traffic for really private,
863
01:12:01.455 --> 01:12:01.955
transfers?
864
01:12:02.495 --> 01:12:03.935
So all of these kinds of,
865
01:12:04.335 --> 01:12:04.575
of,
866
01:12:05.615 --> 01:12:08.355
details, that we want to surface to the user,
867
01:12:08.940 --> 01:12:16.400
to help them make an informed decision about whether something is for them or not is something that we definitely need to work on and
868
01:12:16.700 --> 01:12:18.000
make available to users
869
01:12:18.795 --> 01:12:21.054
in the future to help them
870
01:12:21.435 --> 01:12:22.975
make their own experiments, basically.
871
01:12:24.315 --> 01:12:36.115
Cool. Yeah. I don't think I have very much to add here because this is the one market that LDK just, you know, I think LND, Core Lightning work great for this market, so don't we don't really focus on it. Focus on your market. Yep.
872
01:12:38.335 --> 01:12:40.035
So let's let's talk.
873
01:12:40.430 --> 01:12:47.650
We have a ton of time left, but let's talk really briefly about enterprise, and then we'll see if we can talk a little bit about spec in the future too.
874
01:12:48.190 --> 01:12:49.490
So what what do we
875
01:12:49.950 --> 01:12:50.255
you
876
01:12:51.935 --> 01:12:56.835
you know, I we have a little bit of experience on the Cash App side, but, you know, what what do we need for enterprises,
877
01:12:57.375 --> 01:13:01.960
you know, as we just saw Kraken launch, Cash App only launched whatever a few months ago.
878
01:13:02.420 --> 01:13:19.080
As these enterprises, big enterprises, start really coming online in a big way, you know, what do we need for the next year for them? This is sorry. I'll jump in quickly. But this I love this one because this has been the past year of my life. I've seen a lot of this, and people are asking me, like, okay. You get businesses
879
01:13:19.460 --> 01:13:20.679
that, you know,
880
01:13:21.300 --> 01:13:40.655
need a really reliable service. Like, okay. We wanna use lightning. We need something really reliable, and, you know, we are expecting this volume or that, and we need it to be scalable. And then just like, you know, the amount of times I've had to explain to why you can't use Amazon Web Services horizontal scaling on, like, a lightning node. You know? Like, these sorts of things. Or you just I think
881
01:13:41.215 --> 01:13:42.514
scaling that infrastructure,
882
01:13:43.454 --> 01:13:50.890
for some of these use cases is gonna be something that'll be important in the next year or 2 as, you know, bigger businesses take this on.
883
01:13:51.610 --> 01:14:03.344
And then just, you know, reliability. You know, if you're tinkering with something and it works 90% of the time, you know, that's that's awesome. If you're a business and it only works 90% of the time, that's a big problem. So I think, you know, reliability and scalability
884
01:14:03.965 --> 01:14:10.210
are big things for for businesses that are trying to take on lightning. Yeah. Absolutely. I mean, one of the,
885
01:14:11.389 --> 01:14:19.635
one of the prototypes we had, we had internally for a long time is basically a system that, that is truly highly available for liking nodes.
886
01:14:20.255 --> 01:14:21.455
And, Val,
887
01:14:22.015 --> 01:14:25.060
recently published a a system that very much looks like it.
888
01:14:25.540 --> 01:14:33.960
Where you have where you have a set of boundary nodes and a virtual node behind it. And that that is definitely something that, that we are looking into because
889
01:14:34.925 --> 01:14:36.465
this reliability and availability
890
01:14:37.725 --> 01:14:54.195
is paramount for for big businesses. Imagine that if Amazon was unreachable 1% of the time. Right. All the money they would lose by just not being able to process payments. For a 100th of a percent of a time, they would still have Yeah. A huge problem. And and and this kind of this kind of innovation,
891
01:14:54.735 --> 01:15:00.160
is is is something that, that that we definitely need to look into, and we've come a long way.
892
01:15:00.620 --> 01:15:03.360
We we've very early on had a failover.
893
01:15:04.620 --> 01:15:08.875
A clear hat, had an implementation of failover that, that could take,
894
01:15:09.255 --> 01:15:11.515
30 seconds to recover if I'm not mistaken,
895
01:15:12.935 --> 01:15:15.515
which is good. I mean, 30 seconds,
896
01:15:16.150 --> 01:15:17.830
that's that's quite good. We,
897
01:15:18.870 --> 01:15:19.750
we can now,
898
01:15:20.470 --> 01:15:22.730
basically reduce that to a couple of seconds,
899
01:15:23.405 --> 01:15:23.905
failover.
900
01:15:24.284 --> 01:15:26.224
And with high availability setups,
901
01:15:26.925 --> 01:15:29.585
we can ensure that no single payment gets lost,
902
01:15:30.045 --> 01:15:33.890
because if any particular node is offline at the time,
903
01:15:34.510 --> 01:15:45.075
the sender will basically retry through a different route. And as long as any of these is online, then then you can you can still process payments. And that also gives you operational flexibility,
904
01:15:45.935 --> 01:15:48.035
because it means that you can basically just
905
01:15:48.495 --> 01:15:53.179
restart a node or upgrade a node and, and if, and do operational,
906
01:15:53.719 --> 01:15:57.739
management of of the node while still being, being overall available.
907
01:15:58.199 --> 01:16:19.155
Yeah. That's that's something that we didn't kind of appreciate going into LDK. We kind of built this thinking about kind of the mobile world and thinking about, like, people who want to integrate, especially integrate Lightning into existing on chain wallets. You know, you wanna hook it into your existing chain sync and your existing key store and blah blah blah. And that's kind of where we came at it, and then, you know, Cash App came to us. We didn't
908
01:16:19.535 --> 01:16:38.065
pitch them, really. We'd explain what what LEK was, and they came to us, and they said, hey. We're actually we wanna use this. We have a ton of you know, Cash App's a little unique. It's a lot of Bitcoin exchanges are more kind of standard infrastructure, and they're set up to run a lot of daemons and interact via RPC. Cash App's not. They're a big company with, you know,
909
01:16:38.525 --> 01:16:43.390
separate services for everything already in place that they already use for all of their existing
910
01:16:43.770 --> 01:16:44.270
web
911
01:16:44.570 --> 01:16:45.630
and and whatever services.
912
01:16:46.810 --> 01:16:50.925
And so they came to us and they said, you know, we want to use Total Decay with this, we think it makes sense.
913
01:16:52.284 --> 01:16:52.784
And
914
01:16:54.125 --> 01:16:57.344
so they ended up building a lot of that stuff using their existing
915
01:16:58.469 --> 01:17:03.210
platform. Right? So they already had high availability stuff and failover and all that kind of stuff. So they built
916
01:17:03.590 --> 01:17:07.475
a Lightning node custom with LDK doing kind of all all the
917
01:17:07.775 --> 01:17:19.219
Lightning specific stuff into their infrastructure and as a part a core part of their infrastructure instead of kind of having a daemon they talk to. And so then we have like the hand availability stuff that that we've
918
01:17:19.920 --> 01:17:22.260
shipped that they've looked at testing.
919
01:17:22.560 --> 01:17:33.365
It turns out once you start adding too many route hints in the the QR code just blow up and it it so we need we need bolt 12. We need the the onion messages so that we can request an invoice or
920
01:17:34.060 --> 01:17:38.000
because it doesn't really you get too big an invoice for a QR code
921
01:17:38.780 --> 01:17:43.360
or or l and URL. I guess both work in this in a kind of server assistant setup,
922
01:17:43.955 --> 01:17:44.455
But,
923
01:17:45.155 --> 01:17:47.095
yeah. So that's that's something that
924
01:17:47.475 --> 01:17:52.860
we didn't anticipate, but turns out LDKs works fairly well for them or at least they're pretty happy with it.
925
01:17:53.560 --> 01:17:54.060
So
926
01:17:56.040 --> 01:17:56.540
Awesome.
927
01:17:57.320 --> 01:18:01.395
I don't know how to read this clock. It went to 0 and now it says one minute. But Yeah.
928
01:18:01.855 --> 01:18:06.835
But it's going up. Yeah. It's not 11:30 yet. So I think we can keep going for a minute. Let's let's
929
01:18:07.450 --> 01:18:11.550
take another minute and talk about, the future of kind of the spec process,
930
01:18:12.890 --> 01:18:22.335
the the bolts process. You know, we talked a little bit about kind of having a common core and these things that that all the lightning node nodes implement, and then having users kind of experiment
931
01:18:22.635 --> 01:18:25.790
using those different kind of building blocks that exist within lightning.
932
01:18:27.770 --> 01:18:31.630
How does that fit into the future of how, kind of, the bolts evolve,
933
01:18:32.090 --> 01:18:34.190
and then there's now this new blip process
934
01:18:34.785 --> 01:18:36.565
to standardize some of these extensions.
935
01:18:37.425 --> 01:18:41.205
How do we see that process evolving over the next few years?
936
01:18:42.640 --> 01:18:57.045
Well, I think we have to, you know, see how it goes. Right? We just started using, you know, GLPs and all that. And I think that that gets more and more important as we get more and more activity, you know, and more and more innovation on Lightning. Trying to have a a method in a process
937
01:18:57.409 --> 01:18:59.110
gets, be very important.
938
01:18:59.489 --> 01:19:00.949
Right. Yeah. I mean, we've
939
01:19:01.330 --> 01:19:02.550
already we've already seen
940
01:19:03.010 --> 01:19:09.325
issue, you know, things getting exposed to users where it's like, well, you you wanna receive a payment. Okay. Now you have to pick,
941
01:19:09.705 --> 01:19:29.135
and you have to negotiate with the sender. Do you wanna receive Onchain? Do you wanna receive Lightning? And now there's, you know, some apps have added. You can you can pick lnurl, and then you can pick bolt 12, and, like, the user has to know these things, and they have to select the one that the sender can send, And like so, you know, that this there's there's a certain value to to standardization,
942
01:19:29.515 --> 01:19:32.735
but then kind of how do we balance that with
943
01:19:33.300 --> 01:19:39.960
experimentation and letting people run wild and and, you know, we don't know what the answer should be. So how do we balance
944
01:19:40.565 --> 01:19:43.705
having a standard that people can rely on with
945
01:19:44.245 --> 01:19:49.940
enabling people to experiment and try new things so that we can find a solution that works better in the market. Yeah.
946
01:19:50.320 --> 01:19:55.540
So so it's it's always been sort of this this, this process of expansion first during
947
01:20:05.120 --> 01:20:07.540
for from the for the lightning specification.
948
01:20:08.080 --> 01:20:11.060
I remember when we first met in Milan 2016,
949
01:20:11.895 --> 01:20:15.835
we all had different implementations. We all were experimenting on different, things,
950
01:20:16.135 --> 01:20:22.300
and we basically sat down and hammered out all of the different, different trade offs and came to what now is,
951
01:20:22.700 --> 01:20:24.240
is is the bold process
952
01:20:24.700 --> 01:20:28.060
and, the set of documents that we have for the bold process. And,
953
01:20:28.780 --> 01:20:55.655
so I'm pretty happy with the way it works. Basically, giving giving everybody the ability to experiment. You're the only one who's ever expressed happiness about the way it works. I've heard people think it works poorly for very different and divergent and opposite reasons, but you're the first person to ever say, oh this works great. Oh, I I definitely have my pet peeves too. Overall, the process works. It's Well, I mean, we're building and things are getting built, so it can't be that bad. Right? Yeah. Yeah.
954
01:20:56.390 --> 01:21:01.930
But I'm curious you're talking about this expansion and then consolidation. Where do you think we are right now in that?
955
01:21:03.985 --> 01:21:06.645
Probably just about to start the next expansion.
956
01:21:06.945 --> 01:21:07.445
Okay.
957
01:21:08.065 --> 01:21:14.840
So with all the excitement going on with all of the different use cases that that are being presented, with all of the different,
958
01:21:15.540 --> 01:21:16.260
ways to,
959
01:21:16.740 --> 01:21:41.105
to achieve the same thing, we are, we are now sort of seeing what, what this will eventually, look like. And from these learnings, we can then go back to the table and basically say, okay, this is the way we are going to do do it because of these trade offs that we've learned, while experimenting with And and and what so, I mean, obviously, the the big debate is that the invoice format and payment formats and payment protocols,
960
01:21:42.284 --> 01:21:46.625
being a key example of that. Are there other ones that you're thinking of too here?
961
01:21:49.570 --> 01:21:59.555
Yeah. I mean, part part of that discussion is, is the use of whether we want to use the Lightning Network itself to do negotiation of of payments. So the whole, onion messages process,
962
01:21:59.875 --> 01:22:00.375
over
963
01:22:00.755 --> 01:22:05.255
over the l n URL stack of, protocols is definitely something,
964
01:22:05.555 --> 01:22:07.175
to be to be looked at here.
965
01:22:08.099 --> 01:22:14.435
We are looking at replacing the gossip protocol. We were just talking about, this before that we have this gossip protocol that
966
01:22:14.835 --> 01:22:15.575
grew organically,
967
01:22:16.115 --> 01:22:17.575
for the last couple of years
968
01:22:18.595 --> 01:22:19.255
and has
969
01:22:19.795 --> 01:22:21.575
has shown its age by now
970
01:22:22.920 --> 01:22:27.500
with several different implementations sort of interpreting it slightly differently as well.
971
01:22:28.200 --> 01:22:31.340
And so it's time for us now to basically go
972
01:22:31.720 --> 01:22:38.845
and try to find a new protocol that sort of encompasses all of the good and leaves all of the bad behind.
973
01:22:40.185 --> 01:22:40.685
So
974
01:22:41.540 --> 01:22:45.480
inter message dependencies should be dropped. So you'd say we're we're kind of at a different,
975
01:22:46.020 --> 01:22:54.725
place in some of these different protocols is like we're Yeah. Absolutely. Yeah. So it's definitely different lanes that expand and contract in in different times. Yeah.
976
01:22:55.105 --> 01:23:00.250
Awesome. So I think we're getting waived off. I still don't know how to read this timer, but
977
01:23:01.590 --> 01:23:04.835
so, yeah, thank you, guys. Alright. Thank you. Thank you.
978
01:23:08.915 --> 01:23:14.775
Greetings everyone. Welcome to the roll your own crypto panel where we have a bunch of
979
01:23:15.780 --> 01:23:16.280
cryptographers
980
01:23:16.739 --> 01:23:19.000
or people that work on signature libraries
981
01:23:19.540 --> 01:23:23.545
and, you know, they're kind of unsung heroes when things go right
982
01:23:24.025 --> 01:23:25.485
and if things go wrong,
983
01:23:25.945 --> 01:23:27.725
they end up like Sony completely,
984
01:23:28.265 --> 01:23:28.765
pwned.
985
01:23:29.785 --> 01:23:33.020
So I'd like to first, like, get started
986
01:23:33.400 --> 01:23:41.100
in what is a signature? How does it work? Like, you know, are we are we using DocuSign here in Bitcoin Core? Like, what's going on?
987
01:23:42.265 --> 01:23:46.125
How do signatures work, Pionis? Like, what are the functions? What's needed?
988
01:23:47.375 --> 01:23:52.830
Mhmm. Okay. So what is a signature? A signature is something that in Bitcoin authorizes
989
01:23:53.210 --> 01:23:53.950
the spend
990
01:23:54.410 --> 01:23:59.065
of a coin such that the person who received the Bitcoin,
991
01:24:00.005 --> 01:24:03.545
can spend the coin and no one else. And
992
01:24:03.845 --> 01:24:04.345
this
993
01:24:05.560 --> 01:24:09.820
idea that no one else can spend the coin we call that, unforgeability.
994
01:24:10.440 --> 01:24:12.380
So we say the signature scheme,
995
01:24:12.840 --> 01:24:14.485
is not forgeable and,
996
01:24:15.105 --> 01:24:16.485
that means no one
997
01:24:16.785 --> 01:24:22.005
except the person with a secret key belonging to a public key can
998
01:24:24.350 --> 01:24:31.090
create a signature over a certain message, and in the case of Bitcoin the message is usually some
999
01:24:32.074 --> 01:24:34.094
variant of a transaction hash.
1000
01:24:34.715 --> 01:24:36.415
Got it. Got it. So
1001
01:24:37.435 --> 01:24:40.495
how has that maybe changed? You know, we recently activated
1002
01:24:40.875 --> 01:24:41.375
Taproot.
1003
01:24:42.060 --> 01:24:43.920
There's a bunch of new interesting
1004
01:24:45.260 --> 01:24:45.760
signature
1005
01:24:46.540 --> 01:24:47.040
interactivity
1006
01:24:47.420 --> 01:24:51.485
stuff I'll like to get into eventually. But what's the difference between ECDSA
1007
01:24:51.945 --> 01:24:52.845
and Schnorr?
1008
01:24:54.025 --> 01:24:58.365
And can you briefly touch on anyone here, can you briefly touch on, like, the discrete log problem?
1009
01:24:59.350 --> 01:25:00.090
That might too.
1010
01:25:00.470 --> 01:25:01.450
Go. I'll take that.
1011
01:25:02.150 --> 01:25:06.970
So as part of the new Taproot upgrade to Bitcoin, we have a new signature algorithm
1012
01:25:07.435 --> 01:25:08.255
called Schnorr.
1013
01:25:09.195 --> 01:25:12.415
The previous algorithm that was used in Bitcoin was called ECGSA.
1014
01:25:12.954 --> 01:25:19.190
And so as Jonas just said, right, the point of a signature algorithm, you take the message, which is your transaction,
1015
01:25:19.570 --> 01:25:33.895
you mix it up somehow with secret data in a way that anyone can verify. And the idea is that you have this unforgeability property. So only the person who have access to the secret data is able to sign the transaction. And if any part of the transaction changes, the signature is no longer valid.
1016
01:25:34.630 --> 01:25:38.810
And the specific way that that's done is by an algorithm called ECGSA,
1017
01:25:39.190 --> 01:25:40.730
which uses a whole bunch of
1018
01:25:41.245 --> 01:25:45.345
crazy moon math involving elliptic curves and complicated algorithms and stuff.
1019
01:25:45.885 --> 01:25:46.385
And
1020
01:25:47.405 --> 01:25:51.119
in the Taproot upgrade, we have replaced ECDSA
1021
01:25:51.739 --> 01:25:53.679
for Taproot output with Schnorr.
1022
01:25:54.139 --> 01:25:56.719
And the difference between the two is actually fairly subtle.
1023
01:25:57.035 --> 01:26:09.469
They both use elliptic curve. They both use a sort of linear ish equation. They both have a very simple algebraic expression, which if we were doing like a math talk I could write them both on the board and you'd almost wonder,
1024
01:26:10.409 --> 01:26:11.630
what the difference was.
1025
01:26:13.130 --> 01:26:17.265
And the difference is the difference ultimately comes down to history, I'd say, which is
1026
01:26:17.645 --> 01:26:20.465
that back in 1989 or so when EC
1027
01:26:20.845 --> 01:26:25.185
Schnorr was first developed by Klaus Schnorr, who is still a professor in Germany, by the way,
1028
01:26:25.540 --> 01:26:30.599
He developed this signature scheme. He put a number of patents on it. 1, that was the number. And
1029
01:26:31.059 --> 01:26:44.190
he then tried to collect royalties on the signature scheme and because it wasn't widely used anywhere it got no use. Right? Nobody wants to start using a cryptographic scheme that you have to pay to use basically and that's always been true pretty much for the history of modern cryptography.
1030
01:26:44.730 --> 01:26:46.730
Then nobody used this. So then,
1031
01:26:47.130 --> 01:26:48.030
a few folks
1032
01:26:48.489 --> 01:26:51.150
at NIST and particularly Neil Koeblets, I think,
1033
01:26:52.525 --> 01:26:53.665
developed ECDSA,
1034
01:26:53.965 --> 01:27:04.840
where they took the Schnorr signature algorithm, they rearranged it a little bit, and they made it just different enough that it no longer violated the patents. And so this then became a standard both because there was a big standard body behind it and,
1035
01:27:05.539 --> 01:27:15.645
also because it was patent free. And that was kind of the design. Right? It was supposed to have all the efficiency and security and all those good properties of Schnorr, but not be encumbered by this patent. But as it happened,
1036
01:27:16.360 --> 01:27:20.620
well, in practice that is true. In practice it accomplished all of those things. But
1037
01:27:21.000 --> 01:27:25.655
Schnorr's system, by being kind of designed for for cryptographic
1038
01:27:26.215 --> 01:27:29.115
with cryptographic goals in mind is a fair bit more elegant.
1039
01:27:29.495 --> 01:27:31.900
It has a security proof and
1040
01:27:32.280 --> 01:27:32.760
a,
1041
01:27:33.160 --> 01:27:37.740
theoretical model, which is much more plausibly related to real life.
1042
01:27:38.120 --> 01:27:38.620
It
1043
01:27:40.125 --> 01:27:51.120
also has a bunch of algebraic simplicity and that's the big thing that I think we'll get into a bit later that makes it possible to do all sorts of cool advanced tricks like multi signatures and threshold signatures and adapter signatures,
1044
01:27:51.580 --> 01:27:52.560
and all these different
1045
01:27:52.860 --> 01:27:58.125
new signature types. You can build them on top of Schnorr, and and it wasn't really practical to build them on top of ECDSA.
1046
01:27:59.785 --> 01:28:00.285
So
1047
01:28:00.665 --> 01:28:02.765
what is the difference between
1048
01:28:03.385 --> 01:28:06.520
multi signature and threshold signature?
1049
01:28:08.900 --> 01:28:16.074
Yeah. So kind of what was alluded to is one of the things that is much simpler to do now that we're using instead of ECDSA
1050
01:28:17.175 --> 01:28:18.474
is that you can have,
1051
01:28:19.415 --> 01:28:22.240
so I think most people who use Bitcoin are used
1052
01:28:23.100 --> 01:28:35.865
to having, like, a public key and that's like an address. It's where your funds are stored And then your private key is like the secret you know that then you can generate a digital signature in order to spend those funds from that address.
1053
01:28:36.620 --> 01:28:40.400
And now you can kind of have shared ownership of a single pub key.
1054
01:28:42.380 --> 01:28:47.525
Most Bitcoiners are well, some Bitcoiners are probably aware that you can have shared ownership
1055
01:28:47.985 --> 01:28:48.485
using
1056
01:28:48.785 --> 01:28:49.845
a Bitcoin script.
1057
01:28:50.225 --> 01:28:51.605
It's usually called multisig,
1058
01:28:53.200 --> 01:28:56.580
and that's kind of enabled by just putting multiple public keys on chain.
1059
01:28:56.960 --> 01:29:00.980
But what these kind of new protocols enable is
1060
01:29:01.875 --> 01:29:04.135
a way for multiple people to share,
1061
01:29:05.155 --> 01:29:13.170
just one public key that kind of represents all of them. But everyone who isn't involved doesn't need to know that it's multiple multiple people. It just looks like a normal public key.
1062
01:29:13.470 --> 01:29:14.130
And then,
1063
01:29:15.070 --> 01:29:24.565
multi signature is when you have say, like, 2 people and both of them need to kind of work together in order to generate just one signature for their one key.
1064
01:29:25.185 --> 01:29:34.860
And then threshold as the name suggests would be something more like you have 3 people, but only 2 of them are needed in order to generate. So it's like a subset of,
1065
01:29:35.500 --> 01:29:41.054
the parties involved in making that. Yeah. So in some sense, threshold is kind of this general thing and multisignatures
1066
01:29:41.514 --> 01:29:42.155
are just,
1067
01:29:42.475 --> 01:29:45.054
the special case where everyone needs to sign,
1068
01:29:45.380 --> 01:29:55.135
which is kind of confusing because object multisig, like, the way that we previously had of doing multisig on Bitcoin or what's called multisig is actually a threshold signature.
1069
01:29:56.155 --> 01:29:56.975
But yes.
1070
01:29:57.594 --> 01:29:58.975
So I think it's,
1071
01:29:59.594 --> 01:30:00.415
it's a different
1072
01:30:01.060 --> 01:30:09.480
state of mind now to perceive, like, the change from, like, a multi signature to now what's more like a interactive aggregate signature.
1073
01:30:10.304 --> 01:30:17.925
Can we briefly expand on how it works? The combination process, like, what are these rounds I hear of?
1074
01:30:19.930 --> 01:30:29.835
So right now in Bitcoin, if you want to create a multi signature, you use a check multisig opcode or in the Taproot world how it's called, check
1075
01:30:30.315 --> 01:30:31.375
sig sig add.
1076
01:30:32.155 --> 01:30:32.655
And,
1077
01:30:33.275 --> 01:30:34.235
the way that,
1078
01:30:35.835 --> 01:30:41.750
you are able to spend a coin is that you need to So everyone who is,
1079
01:30:42.630 --> 01:30:43.929
involved in that setup
1080
01:30:44.230 --> 01:30:48.170
needs to agree on a message which would be some kind of transaction
1081
01:30:48.655 --> 01:30:49.475
in our
1082
01:30:49.775 --> 01:30:50.415
case and,
1083
01:30:51.215 --> 01:30:52.435
then they just
1084
01:30:52.815 --> 01:30:55.475
sign with a secret key and send the signature
1085
01:30:55.855 --> 01:30:58.355
to some person that will aggregate the signatures
1086
01:30:58.880 --> 01:30:59.380
and,
1087
01:31:00.400 --> 01:31:04.660
then broadcast the transaction to the Bitcoin network, for example.
1088
01:31:06.365 --> 01:31:08.785
Now, if we want to use, the tricks,
1089
01:31:09.405 --> 01:31:10.705
that Nadav mentioned,
1090
01:31:12.445 --> 01:31:15.345
doing a real multi signature where
1091
01:31:15.710 --> 01:31:17.570
even though it's multiple people,
1092
01:31:18.270 --> 01:31:22.210
there is only one public key involved and there's only one signature,
1093
01:31:23.205 --> 01:31:26.505
the setup becomes a bit more complicated
1094
01:31:27.205 --> 01:31:28.105
because now,
1095
01:31:30.389 --> 01:31:31.349
we call this,
1096
01:31:32.230 --> 01:31:33.130
signing process
1097
01:31:33.670 --> 01:31:34.170
interactive,
1098
01:31:35.670 --> 01:31:38.570
because there are now multiple rounds involved,
1099
01:31:40.545 --> 01:31:41.505
Which means that,
1100
01:31:42.065 --> 01:31:44.005
the potential signers first
1101
01:31:44.545 --> 01:31:45.925
send some data around,
1102
01:31:46.385 --> 01:31:46.885
then
1103
01:31:47.500 --> 01:31:51.200
they receive the message and then they sign and,
1104
01:31:51.820 --> 01:31:54.320
this way we have like a a 2 step
1105
01:31:54.735 --> 01:31:56.995
process, you could say, in order,
1106
01:31:57.535 --> 01:31:59.795
to create a multi signature.
1107
01:32:01.135 --> 01:32:02.835
So are there some challenges,
1108
01:32:03.135 --> 01:32:07.360
I guess, like, if I had, like, a key and a safe, or
1109
01:32:07.740 --> 01:32:15.185
do they need to all be online, like, in certain instances? Like, how does this, like, look for, like, the average person? Yeah. There are,
1110
01:32:15.965 --> 01:32:16.945
some challenges
1111
01:32:17.405 --> 01:32:19.105
definitely which is why
1112
01:32:19.565 --> 01:32:23.680
we when designing these things we try to remove these
1113
01:32:24.320 --> 01:32:24.820
challenges
1114
01:32:25.440 --> 01:32:29.460
as much as possible but unfortunately they cannot be
1115
01:32:29.760 --> 01:32:30.740
removed entirely
1116
01:32:31.280 --> 01:32:32.260
in our universe,
1117
01:32:33.205 --> 01:32:35.385
in our laws of nature as far,
1118
01:32:36.245 --> 01:32:37.625
as as we know.
1119
01:32:39.285 --> 01:32:44.160
So just yesterday we published a Bitcoin improvement proposal draft
1120
01:32:44.620 --> 01:32:47.340
on the Bitcoin mailing list that,
1121
01:32:48.060 --> 01:32:50.880
contains a standard for how to create,
1122
01:32:51.485 --> 01:32:52.785
these multi signatures.
1123
01:32:54.125 --> 01:32:55.725
It's a 2 round variant,
1124
01:32:57.565 --> 01:32:59.505
as kind of the state of the art
1125
01:32:59.829 --> 01:33:03.289
research that we did previously. It was 3 rounds
1126
01:33:03.750 --> 01:33:04.150
and,
1127
01:33:04.869 --> 01:33:06.650
it tries to explain
1128
01:33:07.515 --> 01:33:13.455
all the different footguns. There aren't that many but you still need to understand if you want to implement this.
1129
01:33:14.074 --> 01:33:18.460
I'm not talking about users or anything, I'm talking about implementers of this specification.
1130
01:33:18.920 --> 01:33:24.360
There are a few things that you need to be absolutely aware of. You need to read certain parts of this,
1131
01:33:25.125 --> 01:33:27.145
Bitcoin Improvement Proposal. I think
1132
01:33:27.525 --> 01:33:29.784
if you boil it down it's just 2 or 3 things.
1133
01:33:30.645 --> 01:33:37.790
But if you follow them you will be able to create a Schnorr signature, so a signature for a transaction
1134
01:33:38.090 --> 01:33:40.590
that spends a Taproot output.
1135
01:33:41.344 --> 01:33:50.005
Got it. Got it. So what are some attacks? You know, I hear this thing called rogue key attack or some guy named Wagner, like, what is?
1136
01:33:50.989 --> 01:33:58.745
Alright. Yeah. 3 months to 10. Yeah. I'll I'll take the rogue queue 1, and then I'm I'm gonna Alright. I'm gonna make you talk about Wagner. That's a hard one to explain.
1137
01:33:59.844 --> 01:34:08.860
So the way that these signature schemes work, both ECDSA and Schnorr is that you have this what's called a linear equation. We have some secret data, you have a message digest,
1138
01:34:09.400 --> 01:34:17.455
you have, basically an ephemeral key that we call a nonce. You put them together into a simple equation, you add all the pieces together, and you're off to the races. And
1139
01:34:18.555 --> 01:34:29.780
when I say add there, I mean, like, something a little more technical than than familiar edition, but still it behaves algebraically in the same way. Right? If you add 3 things together, it doesn't matter what order you put them in. You can rearrange them, all that good stuff.
1140
01:34:30.275 --> 01:34:32.295
So what a rogue key attack is
1141
01:34:32.755 --> 01:34:35.735
is when you take one of these multi signature schemes
1142
01:34:36.115 --> 01:34:38.060
that Nadav and Jonas was talking about
1143
01:34:38.540 --> 01:34:39.840
where you combine
1144
01:34:40.700 --> 01:34:50.684
3 keys from 3 different parties, say, however many you want. Let's say you have 3 parties, they all combine the keys into 1. So the goal is you have one key, one signature, but you have 3 people behind it. Right?
1145
01:34:51.304 --> 01:34:51.804
And
1146
01:34:52.425 --> 01:34:54.425
the goal, of course, is that you don't want
1147
01:34:55.260 --> 01:35:01.200
you want the one key to actually represent the 3 people. Right? Like, certainly, they should believe that, but also it should be a true belief.
1148
01:35:01.580 --> 01:35:22.835
So what you can do during setup, if you're participating in this, say that we wanted to do like Vivek and me and Jonas, we're all doing one of these setups. The idea is that we would each throw a key in the pot, we would add them all together, and then we'd have our combined key. And then later when we're signing, we would each do a signature. We'd add the signatures together and then we get a single signature. We actually have to do that
1149
01:35:23.614 --> 01:36:03.275
in 2 stages. We throw some nonces in the pot, add them up. We throw some signatures in the pot, add them up. Everything's great. The rogue key attack is where what I can do instead is I can wait for both Vivek and Jonas to give me their keys. And then what I do is I make a key and then I subtract their keys from my key. And then I put that in the path. And so if you've been following everything what gets mixed together is my key minus Jonas plus Jonas minus Vivek plus Vivek and what's left is just me. And so all 3 of us, well all 3 of us contributed something and we added up something from all 3 of us, but I kind of ginned things up so that everyone else's contributions would be canceled
1150
01:36:03.575 --> 01:36:17.225
out. And now if I want to go move the coins without consent from either of them I can go ahead and do that because ultimately the final key is just me. So that's a rogue T attack. And the way to avoid it is to do what's called a re randomization
1151
01:36:18.085 --> 01:36:20.505
where when we mix the keys together we need to,
1152
01:36:21.739 --> 01:36:28.719
rather than directly adding them, we need to first multiply them by a random factor and you have to choose that random factor in a way that
1153
01:36:29.099 --> 01:36:39.905
that whenever I try to change what my contribution is it changes the random factors for every other party. So I can't wait for everyone else to do stuff and then contribute my thing. We have to
1154
01:36:40.530 --> 01:36:45.750
have to mix contributions from everybody. And so if I try to gin sync up my active ginning it up will change
1155
01:36:46.050 --> 01:36:46.790
3 randomizers
1156
01:36:47.330 --> 01:36:48.470
and thereby undermine
1157
01:36:48.850 --> 01:36:49.565
my gin.
1158
01:36:50.605 --> 01:36:55.425
So that's the RoTEA attack. So that's one thing that we've had to address as we've developed these multi signature schemes.
1159
01:36:56.205 --> 01:36:57.425
Wagner Okay.
1160
01:37:00.639 --> 01:37:06.079
First, perhaps, just to be clear, these attacks, they don't apply to the BIP that,
1161
01:37:06.560 --> 01:37:08.020
were proposed yesterday.
1162
01:37:09.185 --> 01:37:11.365
We're talking about this I think because,
1163
01:37:13.265 --> 01:37:15.445
these kinds of schemes they have a history
1164
01:37:16.100 --> 01:37:18.360
and these attacks were discovered
1165
01:37:18.980 --> 01:37:19.800
on the way,
1166
01:37:20.340 --> 01:37:20.840
to
1167
01:37:21.219 --> 01:37:22.199
to the standardization
1168
01:37:23.465 --> 01:37:29.244
of of these schemes. One of these attacks would be a rogue key attack, but there are also other
1169
01:37:30.770 --> 01:37:32.790
attacks. Perhaps you are aware
1170
01:37:33.170 --> 01:37:33.650
that,
1171
01:37:34.130 --> 01:37:34.630
given
1172
01:37:34.930 --> 01:37:37.750
some byte string and a hash function,
1173
01:37:38.335 --> 01:37:39.555
let's say SHA 256,
1174
01:37:40.575 --> 01:37:43.475
it's very hard to find a pre image
1175
01:37:44.175 --> 01:37:47.235
or an input to that hash function that hashes
1176
01:37:47.640 --> 01:37:49.580
to a specific output.
1177
01:37:50.760 --> 01:37:51.659
That is hard.
1178
01:37:52.360 --> 01:37:58.395
However, what not many people are aware of is that if you have a sum of multiple hashes
1179
01:37:59.255 --> 01:38:06.739
that should sum into a value, a specific value, then finding the pre image for that sum of hashes
1180
01:38:07.120 --> 01:38:09.860
is actually not that hard.
1181
01:38:10.215 --> 01:38:17.095
And, in order to find these inputs to the hash functions, you can use Wagner's algorithm, but there are also,
1182
01:38:17.815 --> 01:38:18.315
more
1183
01:38:19.020 --> 01:38:20.800
efficient algorithms out
1184
01:38:21.260 --> 01:38:22.800
that have just been discovered,
1185
01:38:23.100 --> 01:38:24.719
last year. But this attack,
1186
01:38:25.805 --> 01:38:32.225
actually appears quite often in crypto systems that, we are interested in in in the Bitcoin world.
1187
01:38:33.060 --> 01:38:42.040
So just to I'm not sure if this is going to be helpful. This is a very technical thing. But one example of where that would appear is when you're trying to
1188
01:38:42.415 --> 01:38:43.875
do a multi signature,
1189
01:38:44.494 --> 01:38:49.074
what you're combining is a linear combination, of course, of secret data, but also the hashes of the transactions.
1190
01:38:49.375 --> 01:38:51.315
So if you can find a number of transactions
1191
01:38:52.130 --> 01:38:55.510
whose hashes all add up to the hash of another target transaction,
1192
01:38:56.130 --> 01:38:59.510
you can potentially get signatures on a bunch of good transactions
1193
01:39:00.065 --> 01:39:01.685
where the good ones were chosen
1194
01:39:02.065 --> 01:39:12.550
such as those signatures could be added up to get a signature on a bad one. And so that, and that is actually connecting this to a real system gets pretty hairy and technical, but because of this linearity property
1195
01:39:13.010 --> 01:39:18.685
that I haven't defined, but I'm gonna keep coming back to over and over, You can you can use this very abstract
1196
01:39:19.065 --> 01:39:22.685
Winger attack and actually produce forged signatures using it,
1197
01:39:23.065 --> 01:39:23.885
in some
1198
01:39:24.344 --> 01:39:25.804
long, like some previous
1199
01:39:26.880 --> 01:39:28.820
iterations of of this kind of research.
1200
01:39:29.360 --> 01:39:32.260
So now that that state of art research is out,
1201
01:39:33.225 --> 01:39:37.405
what are some efficiencies gained? Like, I like to sync my full node and,
1202
01:39:37.865 --> 01:39:41.325
you know, really brag about it. Is it faster now? Like, what's going on?
1203
01:39:43.810 --> 01:39:45.350
So it won't change,
1204
01:39:46.370 --> 01:39:50.310
past transactions, obviously. So the the kind of current sync time,
1205
01:39:51.055 --> 01:39:54.355
isn't all that affected by by Taproot. But new,
1206
01:39:55.215 --> 01:39:57.635
transactions, if people are using Taproot,
1207
01:39:58.610 --> 01:39:59.670
are going to,
1208
01:40:00.130 --> 01:40:05.190
well, I mean, Schnorr itself is just faster to verify already on its own,
1209
01:40:05.885 --> 01:40:07.344
by a little bit. But then,
1210
01:40:07.965 --> 01:40:09.505
with kind of the new standardization
1211
01:40:09.885 --> 01:40:10.385
process,
1212
01:40:10.925 --> 01:40:15.390
you can also now kind of aggregate a bunch of signatures that you want to verify
1213
01:40:16.590 --> 01:40:23.010
together in a way that then you can verify them all at once in a way that's faster than verifying each signature individually,
1214
01:40:23.815 --> 01:40:25.195
and that'll lead to,
1215
01:40:26.215 --> 01:40:28.555
I mean, it it will mean that
1216
01:40:29.175 --> 01:40:32.235
as opposed to the universe in which we didn't implement Schnorr,
1217
01:40:33.410 --> 01:40:36.790
we're we're faster than that universe in in syncing.
1218
01:40:37.490 --> 01:40:38.950
So I can essentially
1219
01:40:40.575 --> 01:40:45.315
verify maybe one signature for a whole block or one signature for entire, like,
1220
01:40:46.094 --> 01:40:57.489
15 multi sig, something like that? Well, all of them do have to be Schnorr signatures. So people who are still using EC and VSA, you still have to verify each of those individually. But I believe, and I guess correct me if I'm wrong,
1221
01:40:57.915 --> 01:41:21.885
that you can kind of just batch in as many of these Schnorr signatures that are using the same standard together. And kind of get benefits that grow with the number of signatures that you're verifying at once. So there there are actually there are 2 pieces to that just to to clarify. So one is this notion of batch verification where if you have a whole pile of signatures in a block and they're all snore signatures, you can verify that much faster than just verifying each one in a row.
1222
01:41:22.270 --> 01:41:40.440
And if you've got, like, 3 or 4 of these, you can probably verify it, like, twice as fast, but if you've got a 1,000 of them, you could potentially verify it, something like 8 or 10 times as fast. It's not a simple curve. It can just give you a multiplier, but it gets better the bigger your batch is. The other cool thing though that we'll see with Schnorr signatures is because we can do this multisig
1223
01:41:41.060 --> 01:41:42.040
kind of constructions,
1224
01:41:42.660 --> 01:41:46.200
oftentimes you won't even have so many signatures to verify.
1225
01:41:46.545 --> 01:41:53.925
And I think that's probably in practice where we're going to see the bulk of the savings is in the signatures that aren't even on the blockchain because they no longer need to be. Yeah.
1226
01:41:54.909 --> 01:41:55.489
I think
1227
01:41:55.869 --> 01:41:56.769
one of the,
1228
01:41:57.949 --> 01:42:01.650
more immediate applications of this multi signature
1229
01:42:02.190 --> 01:42:02.690
technology
1230
01:42:03.150 --> 01:42:03.650
is
1231
01:42:03.955 --> 01:42:06.295
opening and closing lightning channels
1232
01:42:06.835 --> 01:42:11.494
because there you are already in the setting where you have a 2 of 2 and,
1233
01:42:13.860 --> 01:42:14.920
the Lightning Network,
1234
01:42:15.540 --> 01:42:20.520
already is a very interactive and, stateful process, very
1235
01:42:20.915 --> 01:42:24.675
different to, like, hardware wallets signing in your,
1236
01:42:25.075 --> 01:42:27.895
bank using your bank vault or or whatever.
1237
01:42:28.275 --> 01:42:28.775
And
1238
01:42:31.390 --> 01:42:32.590
this would, I think,
1239
01:42:32.990 --> 01:42:33.490
benefit,
1240
01:42:34.910 --> 01:42:46.125
Lightning quite a bit because right now you need to, write 2 public keys to the, chain as well as 2 signatures when you want to close a Lightning channel,
1241
01:42:46.510 --> 01:42:47.250
And, with
1242
01:42:48.110 --> 01:42:49.010
multi signature
1243
01:42:50.030 --> 01:42:55.170
schemes, you can reduce that to 1 public key, 1 signature, which would make it cheaper
1244
01:42:56.344 --> 01:42:57.244
to, use Lightning.
1245
01:42:59.545 --> 01:43:01.724
Are there any other cool applications,
1246
01:43:02.665 --> 01:43:05.380
with these? I know Nadav works on DLCs.
1247
01:43:07.040 --> 01:43:09.220
I know, like, there's also a preimage
1248
01:43:09.600 --> 01:43:11.860
or hash reuse along the path.
1249
01:43:12.535 --> 01:43:13.835
What what's possible now?
1250
01:43:14.935 --> 01:43:16.795
Yeah. So one really exciting
1251
01:43:17.655 --> 01:43:18.155
application,
1252
01:43:19.095 --> 01:43:21.355
that is made much easier by Schnorr signatures,
1253
01:43:22.410 --> 01:43:28.270
is a variance that I believe Andrew came up with called adapter signatures. Oh, yes.
1254
01:43:29.130 --> 01:43:30.910
And they kind of allow
1255
01:43:31.735 --> 01:43:32.875
you to,
1256
01:43:34.775 --> 01:43:37.035
say, bake in some more
1257
01:43:38.615 --> 01:43:39.115
logic
1258
01:43:39.510 --> 01:43:51.265
in into your signatures than just kind of saying like, yes, this person can spend this, you can kind of make it a bit more complicated. So essentially, what DLCs do is we utilize adapter signatures
1259
01:43:51.965 --> 01:43:53.025
in order to,
1260
01:43:54.525 --> 01:43:55.025
make
1261
01:43:55.560 --> 01:43:56.060
Bitcoin
1262
01:43:56.600 --> 01:43:57.100
payments
1263
01:43:57.720 --> 01:43:58.220
that,
1264
01:43:58.760 --> 01:44:01.100
pay different amounts depending on
1265
01:44:01.400 --> 01:44:04.380
what, say, an oracle says happened in the real world.
1266
01:44:04.695 --> 01:44:13.595
So say like if, someone won an election or something like this then, you know, there might have been multiple candidates, people can put money into a Bitcoin address
1267
01:44:13.960 --> 01:44:20.140
that will pay to a different person depending on who wins that election or all sorts of variants on this kind of thing.
1268
01:44:21.385 --> 01:44:24.925
And, I believe this also affects lightning. You can essentially
1269
01:44:25.465 --> 01:44:29.165
perform lightning routing in a much better way than previously
1270
01:44:29.465 --> 01:44:31.165
or than it currently is done
1271
01:44:31.690 --> 01:44:36.590
using these adapter signatures. And one of the main benefits of this is that you don't have to use,
1272
01:44:36.890 --> 01:44:37.950
Bitcoin's native
1273
01:44:38.645 --> 01:44:46.505
scripting language, you kind of bake it all into the math of the signature itself and it all kind of just looks like normal signature activity on chain,
1274
01:44:47.239 --> 01:44:53.659
but it kind of makes it so that only the people who need to know kind of do the math and and do all of the contract
1275
01:44:54.395 --> 01:44:56.175
logic and everything else.
1276
01:44:56.955 --> 01:44:59.295
Really, you only use the Bitcoin blockchain
1277
01:44:59.835 --> 01:45:03.135
for the actual transfer of funds, which is what it's best at.
1278
01:45:03.890 --> 01:45:04.390
Yeah.
1279
01:45:04.850 --> 01:45:12.070
So one thing that we've been dancing around through a lot of this conversation is that there's not just a scalability benefit here, there's a privacy benefit as well.
1280
01:45:12.530 --> 01:45:26.620
So one place that the privacy comes from is just like, just from using multisix directly. That already gives you a privacy benefit if you've got one key that potentially represents multiple people and potentially represents some complicated policy where it could be a threshold or
1281
01:45:27.080 --> 01:45:39.645
some other arbitrary set of signers. In the lightning case, things get a lot more interesting because as you say, with these adapter signature constructions, you're able to start embedding some kind of non trivial logic into the signatures themselves.
1282
01:45:40.425 --> 01:45:40.925
And
1283
01:45:41.300 --> 01:45:42.760
adaptive signatures themselves,
1284
01:45:43.620 --> 01:45:49.080
what they are one way to think of them is a form of verifiable encryption. And what I mean by that is that I can take a signature,
1285
01:45:49.385 --> 01:45:54.205
I can encrypt it in some way where I can prove that the data that I'm encrypting
1286
01:45:54.905 --> 01:46:03.710
satisfies some algebraic properties that let me hook it into some other cryptosystem somewhere or something. But ordinarily, the point of encryption, right, is that you basically completely scramble your data.
1287
01:46:04.010 --> 01:46:04.510
And
1288
01:46:05.450 --> 01:46:05.850
if you
1289
01:46:06.875 --> 01:46:17.030
the idea is that this intended recipient can decrypt it and get the data out. But until they do the decryption, if they don't have a decryption of queues, there's nothing they can, they can't even tell that it is encrypted data, right, it could just be noise.
1290
01:46:17.330 --> 01:46:18.630
With verifiable encryption,
1291
01:46:19.250 --> 01:46:20.550
you can,
1292
01:46:21.145 --> 01:46:24.045
you know, provide some more substance to that. So in particular,
1293
01:46:24.585 --> 01:46:26.845
when you are using the lightning network,
1294
01:46:27.225 --> 01:46:35.800
the way that your payment channels work, well, the way that Lightning works is you're actually chaining multiple payment channels off of each other and you have these paths through Lightning Network and you're routing money through all this.
1295
01:46:36.395 --> 01:46:37.935
And along a certain path,
1296
01:46:38.315 --> 01:46:40.495
you have to maintain this,
1297
01:46:41.355 --> 01:46:51.260
kind of fixed identifier. I think it's an invoice ID or something in the UX. But what it is in the current lightning indication is it's some hash, some random hash of some data.
1298
01:46:51.719 --> 01:47:10.670
And this hash is put into the scripts in all the payment channels and it has to be the same and that's how the payment channels are linked. The idea is that when you update 1 payment channel, it causes a preimage that has to be revealed and the revelation can then be used in the previous payment channel, which then, you know, and everyone before that. With adaptive signatures,
1299
01:47:11.455 --> 01:47:17.315
rather than using script to require that your signature has to come along with revealing this hash privilege,
1300
01:47:18.255 --> 01:47:27.620
you can use this form of verifiable encryption. You can say by signing, you can say my signature itself is an encryption key or a decryption key, more importantly, it's both.
1301
01:47:28.305 --> 01:47:34.725
So by signing this update to this payment channel, I am now revealing a decryption key in the form of a signature
1302
01:47:35.160 --> 01:47:50.795
and that decryption key can be used to reveal some secret data, which I can then take and use in the previous payment channel and chain it forward. And even cooler is that you can actually re randomize it at each step. So now rather than having a whole path, we have the same random ID in each one
1303
01:47:51.150 --> 01:47:58.610
that somebody who had a God's eye view of the network could tell that it was all one path. You now have this re randomization where even the people in the path itself
1304
01:47:59.114 --> 01:48:09.490
might not know where it starts and where it ends because there's re randomization happening at the hop after them and the hop before them. So there's a privacy benefit there even within the Lightning Network. So
1305
01:48:09.970 --> 01:48:15.465
That sounds interesting. Pretty cool. So we have about 15 minutes left, and,
1306
01:48:16.085 --> 01:48:18.745
I'd definitely like to discuss scriptless scripts,
1307
01:48:20.725 --> 01:48:21.225
MUSIG
1308
01:48:21.525 --> 01:48:24.345
DN, or perhaps even CISA.
1309
01:48:25.370 --> 01:48:25.870
And
1310
01:48:26.330 --> 01:48:28.510
then, there was a recent paper put out,
1311
01:48:29.210 --> 01:48:32.110
and also some libraries from, Jesse Posner
1312
01:48:32.650 --> 01:48:35.085
regarding a threshold scheme called frost.
1313
01:48:35.385 --> 01:48:35.705
So,
1314
01:48:36.585 --> 01:48:38.205
let's try to rush through this.
1315
01:48:39.465 --> 01:48:45.200
Well, scriptless scripts generally refers to the use of adapter signatures. So I think we've covered that one.
1316
01:48:45.580 --> 01:48:46.320
Makes sense.
1317
01:48:46.700 --> 01:48:58.870
Well, I have one more minute. Okay. Yeah. Go for it. I'll be quick though. I promise. Yeah. I was I was on another panel a couple of weeks ago, and I gave a 28 minute answer to the question, how long have you been writing software? So, but I'll try to
1318
01:48:59.490 --> 01:49:00.790
I'm sorry, I'm doing it now.
1319
01:49:01.970 --> 01:49:06.070
To finish my spiel about adaptive signatures. So adaptive signatures give you this kind of,
1320
01:49:07.175 --> 01:49:18.840
this verifiable encryption property, which you can use in the Lightning Network just to feed data through there. But what you can also do is encrypt other signatures, for example. So you can do arbitrary forms of atomic swaps and stuff
1321
01:49:19.300 --> 01:49:20.200
where you
1322
01:49:22.500 --> 01:49:25.000
where you have, say, 2 transactions on 2 different blockchains,
1323
01:49:25.445 --> 01:49:34.520
for example, and you want to swap. Right? You're trying to trade some Bitcoin for some something worthless. Right? And the the worthless thing has its own chain. Right? That they do usually.
1324
01:49:34.980 --> 01:49:35.300
And,
1325
01:49:35.940 --> 01:49:52.980
so you want to do this fairly. Right? You don't want, you know, one person to give their money away and then the other to just take it and then walk away. So the way that you do this is you set things up so that when the first person signs to take their money, that signature then decrypts a signature that gives the other asset away on the other side. So you get this atomicity
1326
01:49:53.599 --> 01:49:54.420
in that form.
1327
01:49:54.880 --> 01:49:55.380
Another
1328
01:49:56.159 --> 01:50:01.305
more general application of this would be something called a 0 knowledge contingent payment.
1329
01:50:03.445 --> 01:50:03.945
ZKCP.
1330
01:50:04.805 --> 01:50:06.265
ZKCP. Thank you.
1331
01:50:07.460 --> 01:50:07.960
Where
1332
01:50:08.820 --> 01:50:34.620
what you are encrypting rather than being another signature or something is basically some arbitrary piece of data and you provide this extra object called a zero knowledge proof. And a 0 knowledge proof is a very general, very powerful cryptographic object, which are very slow to create. They have weird security models. There's lots of questionable things about 0 knowledge proof. But the cool thing here is we don't put them on the blockchain and we don't need them for long. They're kind of an ephemeral thing here. So what I could do is supposing
1333
01:50:34.920 --> 01:50:35.980
say that
1334
01:50:36.360 --> 01:50:36.860
I
1335
01:50:37.465 --> 01:50:46.285
meaning of trying to come up with a noncontracted example. Right? I have some satellite imagery. Okay? And I claim that I found some oil deposits. Okay? And I'm trying to sell those to Chevron
1336
01:50:48.170 --> 01:50:52.670
and I don't want to just give them the satellite images because then they'll take it and run away.
1337
01:50:53.130 --> 01:51:00.574
And for some reason they're really into high-tech, like bleeding edge cryptography and wanna play games with me, even though that's really not what they do.
1338
01:51:01.195 --> 01:51:05.454
And, so what I can do is I can take this satellite image, I can somehow
1339
01:51:06.010 --> 01:51:07.309
describe the
1340
01:51:07.690 --> 01:51:09.389
evidence of oil in
1341
01:51:09.929 --> 01:51:13.949
a verifiable computationally verifiable way and produce a zero knowledge proof.
1342
01:51:14.865 --> 01:51:26.949
Well, I'll take the image, I'll encrypt it. I'll produce a 0 knowledge proof that what I encrypted is a satellite image, which satisfies these criteria, which Chevron agrees actually indicates evidence of oil. And Now we do a 0 knowledge contingent payment
1343
01:51:27.330 --> 01:51:29.590
where the 2 of us jointly create a transaction
1344
01:51:30.130 --> 01:51:32.710
where in order for them to take my money,
1345
01:51:33.315 --> 01:51:36.135
I have to sign a transaction and my signing of that transaction,
1346
01:51:36.514 --> 01:51:42.970
well, I know it's going to give me the money because that's the transaction that gives me money. My signing will then decrypt the image,
1347
01:51:43.350 --> 01:52:00.260
which Chevron knows will be what they expect, and so we can execute a transaction that way, even if the 2 of us don't really trust each other, and even if, like, nobody should trust either of us. The the zero knowledge proof will step in there. So this general framework of of playing games like this with adaptive signatures is what we call scriptless scripts.
1348
01:52:00.800 --> 01:52:09.625
Got it. Got it. So we're gonna take a step back. Actually, no more music DN. I think we got our z k p, crypto cat out of the way.
1349
01:52:10.405 --> 01:52:11.705
Let's let's take
1350
01:52:12.085 --> 01:52:12.905
a bit more
1351
01:52:13.365 --> 01:52:18.185
applicable thing. Like, I know, you and Tim Rufing also work on
1352
01:52:18.600 --> 01:52:20.699
half ag music too. What are these,
1353
01:52:21.400 --> 01:52:27.820
advantages and, efficiencies potentially gained for things like lightning gossip? Can you touch on this? From, aggregation?
1354
01:52:29.094 --> 01:52:29.994
You mean? Okay.
1355
01:52:31.175 --> 01:52:36.394
I think would make first sense to distinguish what we call signature aggregation
1356
01:52:36.830 --> 01:52:39.890
from, multi signatures or threshold signatures.
1357
01:52:40.510 --> 01:52:43.170
And, for us, the main distinction
1358
01:52:43.870 --> 01:52:45.375
is that in multisignatures
1359
01:52:45.915 --> 01:52:47.135
or threshold signatures,
1360
01:52:47.515 --> 01:52:49.855
you only have a single message.
1361
01:52:50.955 --> 01:52:51.515
In the,
1362
01:52:52.155 --> 01:52:53.455
Bitcoin use case,
1363
01:52:53.770 --> 01:52:54.429
that is
1364
01:52:55.130 --> 01:52:57.949
dependent on the input that you're spending,
1365
01:52:58.809 --> 01:53:03.309
or dependent on the coin that you're spending, which means you have some
1366
01:53:04.155 --> 01:53:08.575
set of people and they have shared ownership over a single coin.
1367
01:53:09.035 --> 01:53:11.695
Now when we go to the signature aggregation world,
1368
01:53:12.090 --> 01:53:16.990
there are multiple signers and each with different messages.
1369
01:53:18.010 --> 01:53:22.245
Right? So this corresponds to a transaction with multiple inputs,
1370
01:53:22.785 --> 01:53:23.025
and,
1371
01:53:23.745 --> 01:53:26.165
this transaction must have multiple signatures,
1372
01:53:26.625 --> 01:53:29.605
and each signature will be over a different message
1373
01:53:30.050 --> 01:53:30.550
because,
1374
01:53:32.210 --> 01:53:36.390
because the signature is used to authorize the spend of a different coin.
1375
01:53:37.775 --> 01:53:39.935
So we call this, these schemes,
1376
01:53:40.335 --> 01:53:41.395
signature aggregation.
1377
01:53:43.695 --> 01:53:46.755
What they are doing is they act really aggregate
1378
01:53:47.230 --> 01:53:48.270
signatures and,
1379
01:53:48.910 --> 01:53:51.090
this doesn't have privacy benefits,
1380
01:53:52.110 --> 01:53:54.690
in general at least, but it has
1381
01:53:55.045 --> 01:53:56.265
scalability benefits
1382
01:53:56.885 --> 01:53:57.385
because,
1383
01:53:58.965 --> 01:54:00.665
a big part of transactions
1384
01:54:01.125 --> 01:54:03.145
right now are actually signatures.
1385
01:54:03.845 --> 01:54:04.345
So
1386
01:54:06.590 --> 01:54:07.730
what would be
1387
01:54:08.590 --> 01:54:13.730
we could try to aggregate these signatures into a smaller signature.
1388
01:54:14.865 --> 01:54:15.185
And,
1389
01:54:15.745 --> 01:54:18.245
there we again basically distinguish
1390
01:54:18.545 --> 01:54:20.405
2 different types of schemes,
1391
01:54:21.905 --> 01:54:23.525
mainly half aggregation
1392
01:54:24.400 --> 01:54:28.960
and full aggregation. And full aggregation is a bit simpler to explain because,
1393
01:54:30.240 --> 01:54:31.280
that works by
1394
01:54:31.945 --> 01:54:38.525
or or the output of the full, signature aggregation algorithm is a single signature. So in an ideal world,
1395
01:54:38.985 --> 01:54:42.628
every Bitcoin transaction would have a single signature,
1396
01:54:43.504 --> 01:54:45.380
unlike today where,
1397
01:54:45.760 --> 01:54:48.580
there's a signature for every input, basically.
1398
01:54:51.715 --> 01:54:52.935
But creating these
1399
01:54:53.315 --> 01:54:53.815
signatures
1400
01:54:54.435 --> 01:54:54.935
has
1401
01:54:56.994 --> 01:54:57.494
similar
1402
01:54:57.960 --> 01:54:58.460
interactivity
1403
01:54:58.840 --> 01:55:00.140
properties than,
1404
01:55:00.760 --> 01:55:01.660
multi signatures.
1405
01:55:02.120 --> 01:55:08.755
So it's not so easy to do, and how to exactly do that is, still an open research problem.
1406
01:55:10.255 --> 01:55:11.795
For half aggregation,
1407
01:55:12.335 --> 01:55:17.630
we don't get the benefits of having only a single signature in the end. We basically
1408
01:55:18.250 --> 01:55:22.830
are only able to aggregate half of the original signatures together,
1409
01:55:23.135 --> 01:55:25.715
but this process is non interactive,
1410
01:55:26.095 --> 01:55:28.815
so anyone can do that. And,
1411
01:55:29.855 --> 01:55:31.075
that would be something,
1412
01:55:32.020 --> 01:55:33.719
that could be added to
1413
01:55:34.020 --> 01:55:35.960
Bitcoin consensus perhaps,
1414
01:55:36.579 --> 01:55:37.559
at some point
1415
01:55:37.860 --> 01:55:38.760
in the future,
1416
01:55:39.165 --> 01:55:39.665
but,
1417
01:55:40.205 --> 01:55:42.225
it may have also implications
1418
01:55:42.925 --> 01:55:43.985
on protocols
1419
01:55:44.364 --> 01:55:47.425
on top of the Bitcoin network such as,
1420
01:55:48.450 --> 01:55:48.950
Lightning
1421
01:55:49.810 --> 01:55:55.670
because, Lightning, at least right now, gossips a lot of signatures around to prove,
1422
01:55:56.844 --> 01:55:59.905
that nodes actually have open channels.
1423
01:56:01.485 --> 01:56:04.545
And these signatures are just bare single signatures,
1424
01:56:05.270 --> 01:56:10.650
So what could happen is that instead of each sending a single signature for,
1425
01:56:11.270 --> 01:56:13.050
in order to do a single proof
1426
01:56:13.425 --> 01:56:13.585
that,
1427
01:56:14.305 --> 01:56:15.445
a channel exists,
1428
01:56:16.385 --> 01:56:18.965
some party, could be anyone, could just aggregate
1429
01:56:19.425 --> 01:56:23.140
these signatures into a single half aggregated signature then,
1430
01:56:23.780 --> 01:56:25.080
in order to reduce,
1431
01:56:25.780 --> 01:56:30.120
the size of the messages that need to be sent around in the Lightning Network.
1432
01:56:32.324 --> 01:56:32.824
Fascinating.
1433
01:56:33.445 --> 01:56:35.545
Hopefully, we'll get that sooner than later.
1434
01:56:36.405 --> 01:56:38.425
Alright. Nadav, what is frost?
1435
01:56:39.670 --> 01:56:41.290
Well, frost is a specific
1436
01:56:41.989 --> 01:56:45.290
proposal for threshold signatures on top of Schnorr.
1437
01:56:45.909 --> 01:56:47.610
I believe it stands for
1438
01:56:48.175 --> 01:56:49.395
flexible around
1439
01:56:50.255 --> 01:56:50.755
optimized,
1440
01:56:52.495 --> 01:56:53.315
what's the s?
1441
01:56:55.590 --> 01:56:58.010
The signing signature. Something threshold.
1442
01:56:58.710 --> 01:57:01.210
Oh, Schnorr threshold signatures. There we go.
1443
01:57:03.105 --> 01:57:04.245
Yeah. So essentially,
1444
01:57:05.905 --> 01:57:06.565
it is,
1445
01:57:06.945 --> 01:57:08.085
so it's a 2 round,
1446
01:57:08.865 --> 01:57:10.485
proposal meaning that,
1447
01:57:11.500 --> 01:57:12.239
well, I
1448
01:57:12.699 --> 01:57:17.840
guess there's a pre computation you can do so that it kind of looks like there's only a single round where,
1449
01:57:18.219 --> 01:57:19.039
that kind of
1450
01:57:19.385 --> 01:57:24.365
looks like normal signing where you just do something once, like, everyone generates their,
1451
01:57:24.745 --> 01:57:27.805
part of the signature and then someone puts it all together.
1452
01:57:28.620 --> 01:57:29.340
But really,
1453
01:57:30.380 --> 01:57:36.480
there's also kind of like a setup round. So there's a setup round and then a signing round. It's maybe a high level way to think about it.
1454
01:57:37.505 --> 01:57:38.005
Essentially,
1455
01:57:38.625 --> 01:57:40.165
what you do is,
1456
01:57:40.865 --> 01:57:43.685
everyone kind of generate or has their own
1457
01:57:44.385 --> 01:57:49.790
private key is how you could think of it or or secret share and then, together they they
1458
01:57:50.730 --> 01:57:52.590
have one private key.
1459
01:57:52.935 --> 01:57:56.155
It's not as simple as just adding all of those keys in a pot,
1460
01:57:56.775 --> 01:58:00.074
but you you do a little bit more math and you end up getting
1461
01:58:00.375 --> 01:58:01.594
a key which
1462
01:58:02.280 --> 01:58:09.340
then could in theory be derived by any, say, 2 of 3 participants or 3 of 5 or t of n.
1463
01:58:10.625 --> 01:58:18.325
But then rather than actually doing that because you don't want people to just know what this private key is because then they can sign for the group. So what you do instead
1464
01:58:18.750 --> 01:58:19.650
is you collaboratively
1465
01:58:20.030 --> 01:58:20.530
any,
1466
01:58:20.989 --> 01:58:25.489
2 or 3 2 of 3 or 3 of 5 or whatever threshold you want
1467
01:58:25.844 --> 01:58:29.545
of all of the people can get together and collaboratively generate,
1468
01:58:30.565 --> 01:58:33.225
like, they each person generates a partial signature
1469
01:58:33.765 --> 01:58:34.985
using their own
1470
01:58:35.820 --> 01:58:38.960
secret share and then it's all put together
1471
01:58:39.260 --> 01:58:40.560
and if you have
1472
01:58:40.860 --> 01:58:44.480
at least t people, at least 3 of the 5 people, for example,
1473
01:58:45.365 --> 01:58:51.065
then you generate just one normal looking Schnorr signature for the one kind of group key.
1474
01:58:52.725 --> 01:58:53.225
And
1475
01:58:54.790 --> 01:59:00.570
it's kind of done in a a simple enough way that it it works well with a lot of other
1476
01:59:01.945 --> 01:59:03.645
things that you might wanna do.
1477
01:59:04.985 --> 01:59:09.325
I actually I don't know if it works with adapter signatures. I imagine that you would be able
1478
01:59:09.889 --> 01:59:19.265
to hack that together if you wanted or similar approaches could Adaptive signatures mostly only work with 2 of 2 set up. There's not room to do a threshold.
1479
01:59:20.125 --> 01:59:22.545
Right. Right. Right. Right. Okay. Yeah. Well, it
1480
01:59:23.245 --> 01:59:24.305
kind of is
1481
01:59:24.740 --> 01:59:27.960
similar in nature to how multi signatures look, but it's
1482
01:59:28.340 --> 01:59:29.480
done more generally.
1483
01:59:29.860 --> 01:59:39.515
And I guess if Jonas wants to talk about the trade offs between using something like music and frog. We can have a bonus round about blind signatures or ring signatures if you'd like to.
1484
01:59:41.130 --> 01:59:42.909
I think one thing that's also,
1485
01:59:43.369 --> 01:59:43.869
interesting
1486
01:59:44.170 --> 01:59:48.820
to to get across is what are the different stages that these proposals are,
1487
01:59:49.935 --> 01:59:55.074
right now. Because people in the audience might be interested to to use this eventually.
1488
01:59:55.455 --> 01:59:56.495
Mhmm. And,
1489
01:59:57.215 --> 01:59:57.715
so
1490
01:59:58.190 --> 02:00:03.409
what we're mostly talking about right now is only the lowest level that you're really interested in,
1491
02:00:03.869 --> 02:00:04.610
which is
1492
02:00:05.575 --> 02:00:12.715
the cryptography part. Right? But there are more parts before you can actually use this in your wallet. Right? There needs to be standardization
1493
02:00:13.175 --> 02:00:14.715
first of the crypto scheme,
1494
02:00:15.170 --> 02:00:15.410
And,
1495
02:00:16.010 --> 02:00:17.510
in for multisignatures,
1496
02:00:18.610 --> 02:00:19.350
we are
1497
02:00:19.810 --> 02:00:22.550
as I said, we we published a standard yesterday
1498
02:00:22.930 --> 02:00:23.990
for Frost.
1499
02:00:25.114 --> 02:00:29.355
I would say there it's, a bit more early, but there are also standards,
1500
02:00:30.395 --> 02:00:30.895
progressing,
1501
02:00:31.650 --> 02:00:36.390
that will be eventually usable with, Taproot and tweaking and and whatnot.
1502
02:00:37.170 --> 02:00:43.405
But then there is also the other layer of how does this integrate with wallets really, that you can have multiple wallets
1503
02:00:43.945 --> 02:00:44.445
independently,
1504
02:00:45.705 --> 02:00:47.245
or independently implemented
1505
02:00:47.705 --> 02:00:50.719
from different vendors that work together and create,
1506
02:00:51.099 --> 02:00:52.159
such a signature.
1507
02:00:52.539 --> 02:00:52.860
And,
1508
02:00:54.139 --> 02:00:55.280
that is, I think,
1509
02:00:55.739 --> 02:01:00.045
a really interesting thing in the future how to exactly do that.
1510
02:01:01.065 --> 02:01:01.305
And,
1511
02:01:02.505 --> 02:01:08.850
that might be more difficult for some schemes than for others. Right? For multi signature, which is a more,
1512
02:01:09.710 --> 02:01:13.310
specific scheme, n of n, that might be a little bit more,
1513
02:01:13.875 --> 02:01:15.895
a little bit easier to do for,
1514
02:01:16.595 --> 02:01:19.655
wallet implementers than something, for example,
1515
02:01:20.035 --> 02:01:21.495
like, like Frost.
1516
02:01:22.699 --> 02:01:33.594
And you asked about blind signatures? Blind and ring. Whatever you think we can kill a minute 30 with. Okay. I say ring. Do rain. I I I'd say blind signatures. Let's do it. Yep. Blind.
1517
02:01:34.775 --> 02:01:37.255
Okay. So what blind signatures are, they,
1518
02:01:38.700 --> 02:01:41.040
are basically a client in a server protocol
1519
02:01:41.420 --> 02:01:45.040
where the server signs some sign signs some message
1520
02:01:45.795 --> 02:01:49.335
that came from the client without knowing what this message is.
1521
02:01:49.875 --> 02:01:51.895
And also such that the signature
1522
02:01:52.355 --> 02:01:52.995
won't be,
1523
02:01:53.715 --> 02:01:54.215
correlated
1524
02:01:54.770 --> 02:01:59.010
with, the message in the future or even the signature in in the future. And,
1525
02:02:00.690 --> 02:02:01.829
how is this used?
1526
02:02:02.145 --> 02:02:10.005
This can be used for example for Federated e cash or e cash in in general, which is I think one of the interesting
1527
02:02:10.920 --> 02:02:13.420
direction that the Bitcoin community
1528
02:02:13.800 --> 02:02:17.739
is is looking into where you have much better privacy,
1529
02:02:18.695 --> 02:02:22.155
guarantees than anything you could achieve with, blockchains
1530
02:02:22.534 --> 02:02:23.034
or
1531
02:02:23.494 --> 02:02:24.074
or Bitcoin
1532
02:02:25.014 --> 02:02:25.675
in particular,
1533
02:02:26.969 --> 02:02:28.349
but you have other
1534
02:02:29.050 --> 02:02:33.550
trade offs. And, these blind signature schemes, they don't need to be
1535
02:02:34.325 --> 02:02:35.305
part of,
1536
02:02:35.765 --> 02:02:36.745
Bitcoin consensus,
1537
02:02:37.685 --> 02:02:41.545
which means that we could use can use more exotic schemes
1538
02:02:41.870 --> 02:02:43.489
that don't have the trade offs,
1539
02:02:43.949 --> 02:02:44.690
of interactivity
1540
02:02:45.070 --> 02:02:46.190
that we discussed with,
1541
02:02:46.750 --> 02:02:51.170
multi signatures or complicated setup like in, threshold signatures,
1542
02:02:51.505 --> 02:02:53.585
but, we can have more,
1543
02:02:53.905 --> 02:02:56.485
exotic cryptographic assumptions and then,
1544
02:02:57.025 --> 02:03:01.660
have a simp a scheme that is simpler to implement and harder,
1545
02:03:02.280 --> 02:03:03.340
to mess up,
1546
02:03:04.040 --> 02:03:09.340
and also that has properties like threshold blind signing, where you have a whole federation
1547
02:03:09.995 --> 02:03:10.554
that would,
1548
02:03:11.435 --> 02:03:12.655
require a signature,
1549
02:03:13.435 --> 02:03:15.215
on a token or whatever,
1550
02:03:16.715 --> 02:03:19.295
yeah. So that's, that's I think the
1551
02:03:20.020 --> 02:03:23.640
the the way how you could use blind signatures in in Bitcoin.
1552
02:03:24.500 --> 02:03:24.820
And,
1553
02:03:25.460 --> 02:03:28.360
this is essentially Mini Mint or similar applications.
1554
02:03:29.685 --> 02:03:31.065
Yep. Exactly. It is.
1555
02:03:31.525 --> 02:03:32.025
Well,
1556
02:03:33.285 --> 02:03:33.945
I guess
1557
02:03:34.645 --> 02:03:42.600
that's pretty much it. I'd like conclude this panel. Let's get a huge round of applause for Andrew Polstra, Jonas Nyck, and Nadav Cohen.
1558
02:03:50.065 --> 02:03:56.085
Thank you so much for joining, and, Lisa, thank you for coming in last minute as a co moderator.
1559
02:03:58.239 --> 02:04:00.020
I I wanna start off by
1560
02:04:00.560 --> 02:04:01.860
I I I would assume
1561
02:04:02.239 --> 02:04:07.114
a lot of people here don't know what covenants are. I, myself, have never even
1562
02:04:08.295 --> 02:04:09.355
really studied covenants
1563
02:04:09.815 --> 02:04:12.955
really, really deeply. I know about them, obviously, but
1564
02:04:13.370 --> 02:04:22.350
I wanna take this time where we can all learn you can essentially teach Lisa and I about covenants. This can be an educational panel so then the audience can learn with us what are covenants.
1565
02:04:23.035 --> 02:04:28.175
And I wanna start with when I first started doing research, I said, what was the first covenant?
1566
02:04:28.875 --> 02:04:34.420
And what came up with what came up on Google was the first covenant was between God and Abraham,
1567
02:04:35.040 --> 02:04:37.780
and the way this this covenant is satisfied is
1568
02:04:38.400 --> 02:04:39.780
Jewish men got circumcised.
1569
02:04:40.285 --> 02:04:41.505
So I wanna know
1570
02:04:41.965 --> 02:04:49.505
how how does this relate to Bitcoin? Maybe we can start there, work our way from, you know, a few 1000 years ago, and work our way here to Bitcoin.
1571
02:04:50.200 --> 02:04:50.920
Just kidding. But,
1572
02:04:52.120 --> 02:04:52.920
like I said,
1573
02:04:53.320 --> 02:04:56.620
few minutes on the clock. Let's do very, very quick introductions,
1574
02:04:57.115 --> 02:05:04.235
10 words or less kind of thing, and let's get rolling into the education. So let's start with Lisa. Hi. I'm I'm Lisa, also in.
1575
02:05:05.040 --> 02:05:08.820
I work on Nikon. Is we need mic for Lisa.
1576
02:05:10.240 --> 02:05:17.935
I'll I'll introduce myself in the meantime while we figure that out. Hi. I'm Jeremy. I like Bitcoin, and I like covenants, and I hope Bitcoin can one day have covenants.
1577
02:05:19.915 --> 02:05:21.534
Amazing. So my name is Burak.
1578
02:05:22.050 --> 02:05:31.095
I'm a Bitcoiner on Bitcoin dev. I think I started in Bitcoin, like, 5 years ago or more or less, you know, initially exploring and building around mining, wallets, payments,
1579
02:05:31.475 --> 02:05:39.255
and I initial and and I, you know, finally ended in this covenants rabbit hole. So it's it's a really interesting place.
1580
02:05:40.100 --> 02:05:40.600
Exciting
1581
02:05:41.140 --> 02:05:48.040
times. Yeah. Hello. I'm Sanket, and I'm excited about governance. And I like Jeremy, I want to see governance in Bitcoin.
1582
02:05:48.594 --> 02:05:49.975
Cool. Anyone on test the mic?
1583
02:05:50.355 --> 02:05:51.655
Hello? Hello? Okay.
1584
02:05:52.355 --> 02:05:52.855
Hello?
1585
02:05:53.395 --> 02:05:55.815
I think there's feedback. So so so,
1586
02:05:56.420 --> 02:06:01.639
Misty, if if you want, for now, if you, when you have a question, we'll just, yeah, we'll just repeat. Alright.
1587
02:06:02.179 --> 02:06:11.095
And then in in the sake of time, maybe we just kinda skip a little bit of the 2000 years of history of covenants and just kinda jump in it, for the sake of time. So,
1588
02:06:12.800 --> 02:06:19.395
how do we where are we at right now? How do we get here? Like what is a covenant in terms of Bitcoin, Jeremy? Yeah.
1589
02:06:19.955 --> 02:06:29.095
So one of the things that I use to explain covenants is that Bitcoin UTXOs, which hopefully we know what those are. That's like a a coin that you have. It's a little bit like a treasure chest,
1590
02:06:29.590 --> 02:06:31.530
and when you open it up usually
1591
02:06:31.910 --> 02:07:34.120
you get some coins out and you can put those into whatever new treasure chest you want, and that treasure chest could have whatever locks you wanna have on it. A covenant is like when you open it up, and then instead of gold coins or something, you see it's like Jimmy Hendrix's guitar, and it says please only put this into a guitar case in the future. And you're like, okay. So if I open this up, then you're gonna leave a little note maybe that says, yeah, when you open this up, please put it into a guitar case. Maybe after it's been opened 10 times, you say something like, take it to the guitar shop to get tuned. That's a covenant. It's like you open up these treasure tests, and then you find something that maybe has some additional restriction of what you can do with it, and that's maybe a little bit heady, but you can imagine in Bitcoin we would have something like, hey, open this up and then move it, and then after you've moved it you have 6 months before some other action can happen. Once you take that action, you have a 2 week grace period, that type of thing when because we're only thinking about Bitcoin. You can't transact Jimmy Hendrix's guitar on the blockchain. I I like that analogy. You have to put a guitar in a guitar good guitar case that's kinda like provisioning it. Did you Hello? Hello? Hello?
1592
02:07:34.755 --> 02:07:38.135
Hello? Hello? Can you hear me? Oh, great. Oh, sorry. Okay. Cool.
1593
02:07:38.595 --> 02:07:55.615
Try to do a quick end so Do do do a quick intro. Yeah. Yeah. I'm Lisa also, and I work on lightning at core lightning at. Cool. And I I didn't really do an intro for myself. So we'll we'll we'll be asking the questions here trying to learn with you guys about these covenants. I'm I'm Michael Tidwell. I work at Souty as an infrastructure engineer.
1594
02:07:56.950 --> 02:07:58.490
And and what you missed is,
1595
02:07:59.030 --> 02:08:05.050
Jimmy Hendrix guitar case. The the analogy here is if I give you this guitar, then you have to put it in a guitar
1596
02:08:05.405 --> 02:08:15.890
guitar case. Can't say that word today. Is that kind of Yeah. Like, you know, you have a special object, and you've gotta, like, preserve something of it's gotta be in a guitar case. You have keep it under some sort of special rule.
1597
02:08:16.270 --> 02:08:26.395
And, you know, rather than just, like, you know, gold coins that you could take out of your treasure chest and put into another treasure chest of your choosing, you You gotta keep it in something that has a special format. So is this I mean,
1598
02:08:27.175 --> 02:08:29.515
I think, like, most people have heard of NFTs,
1599
02:08:29.930 --> 02:08:36.750
which are, like, non fungible tokens. Right? So how are you gonna take Bitcoin and make it look like a guitar?
1600
02:08:37.050 --> 02:08:37.550
Like,
1601
02:08:38.105 --> 02:08:56.525
you know, like, like, why you know, the nice thing about Bitcoin is every Bitcoin is a Bitcoin. Right? Like, you can exchange 1 Bitcoin with another person. We call that fungible because you know that when you get Bitcoin it's the same as, like, any other Bitcoin and all Bitcoin is, like, pretty much equal. Right? So I'm willing to transact on Bitcoin
1602
02:08:56.905 --> 02:08:59.885
because I know that I'm gonna get Bitcoin in return. Right?
1603
02:09:00.185 --> 02:09:05.020
Like, if you're turning Bitcoin into guitar, like, how does Bitcoin become a guitar, 1?
1604
02:09:05.320 --> 02:09:28.935
And, like, 2, like yeah. Isn't that, like are you making, like, NFTs then? Like Yeah. Yeah. So we're just using the guitar as an example of something that has some additional restriction. Mhmm. An example of Bitcoin that's more like a guitar might be Bitcoin that you intend to give to your spouse when you die. Mhmm. And you might wanna have an additional covenant on that that says, well, if you claim access to this because you're claiming that I'm dead,
1605
02:09:29.475 --> 02:09:41.040
maybe there should be some time out period where I can say I'm not actually dead. And that would be more like, you know, there's some restriction on that. But why are you giving your money your Bitcoin to your spouse, Jeremy? Like, I don't have a spouse. I see. Thanks.
1606
02:09:41.580 --> 02:09:48.445
Otherwise, my spouse would have all my So so let me let me ask kind of, like, a higher level question. Do covenants do covenants currently exist in Bitcoin?
1607
02:09:52.105 --> 02:09:56.190
I can go with this, And the answer is we don't know.
1608
02:09:56.570 --> 02:09:57.070
Like,
1609
02:09:57.610 --> 02:09:59.390
Bitcoin script is,
1610
02:09:59.850 --> 02:10:03.275
like, complicated. We have this opcode called op check sig
1611
02:10:03.915 --> 02:10:12.015
which allows which is most fundamental opcode to Bitcoin where you check a signature, then the transaction has valid signature with respect to
1612
02:10:12.540 --> 02:10:13.760
the given public key.
1613
02:10:14.220 --> 02:10:16.640
And by its nature, this opcode
1614
02:10:17.020 --> 02:10:19.520
relies on some data from the transaction itself.
1615
02:10:20.204 --> 02:10:21.585
And in some way,
1616
02:10:22.844 --> 02:10:25.744
the the data from the transaction is available to the script.
1617
02:10:26.045 --> 02:10:31.410
And given all the different op codes we have today, there may be covenants may be possible.
1618
02:10:31.790 --> 02:10:33.730
We just don't know how to do them yet.
1619
02:10:34.750 --> 02:10:39.375
Good way might be to cleanly add support for covenants, but do we have covenants today or no?
1620
02:10:40.475 --> 02:10:51.640
I don't know. Like, for example, Andrew Postra has a good blog post on if you just had op cat, which is looks like a simple op code where you just add 2 concatenate 2 elements on stack,
1621
02:10:52.260 --> 02:10:54.200
with that, you can have covenants. Like,
1622
02:10:54.615 --> 02:11:05.830
yeah, just the nature of Bitcoin script itself is, like, I we can't answer this question. So I I would actually take the side of saying, that we that and this is maybe an important second topic is that we do have covenants,
1623
02:11:06.450 --> 02:11:13.875
that like, a a lock time, check lock time verify, or check sequence verify, in my opinion, are a covenant because it's saying here's a coin
1624
02:11:14.175 --> 02:11:22.100
that you can only spend after a certain amount of time. So it's something beyond just who the owner is about how the coin can be spent. I would consider that a covenant. The
1625
02:11:22.480 --> 02:11:28.305
thing that we're that we're talking about when we say we're not sure and we usually shorthand covenants for this is covenants that really restrict
1626
02:11:28.785 --> 02:11:30.485
where you can spend the coin to,
1627
02:11:31.345 --> 02:11:32.485
not just the how.
1628
02:11:32.865 --> 02:11:33.365
And,
1629
02:11:34.065 --> 02:11:37.285
that yeah. We don't know. As far as I can tell, we don't have them
1630
02:11:37.790 --> 02:11:44.050
at this point, but maybe somebody would find something we could do. Right. But, but by by the definition that we're kinda talking about, it seems
1631
02:11:44.670 --> 02:11:46.050
covenants, by definition,
1632
02:11:47.125 --> 02:12:03.680
have some kind of condition on how they're spent or how Bitcoin is spent. Is that is that okay as a layman term definition? I think you just wanna add more so than something like a simple list of signatures. Okay. Because that that's kind of like that's just who owns it. Because because that's every Bitcoin. And you can say that's a covenant, but that's just like who owns it. It is like an additional restriction.
1633
02:12:04.005 --> 02:12:16.489
Okay. And, Brock, did you wanna add anything? Oh, I think, we don't have NFTs on Bitcoin yet, but you take those or NFTs when you think about it. And I think, yeah, here's Jeremy's saying guitar analogy is, you know, the stuff. Yeah. You can constrain
1634
02:12:17.110 --> 02:12:27.175
in how they can spend. Right? Mhmm. And, yeah, and you can do covenants with some additional codes like checks not tricks, but the entry barrier of that doing that is extremely high. Right?
1635
02:12:27.795 --> 02:12:33.980
But, you know, covenants, in short, is pre committing to a transaction in advance of creating address. Right? In short.
1636
02:12:35.000 --> 02:12:43.035
And I think from what I, like, observe from the community, I think we'll get there at some point. Right? But the question is really in what capacity?
1637
02:12:43.735 --> 02:12:46.875
We we are seeing many competing ideas and proposals,
1638
02:12:47.335 --> 02:12:49.195
and more and more to come. Right?
1639
02:12:49.530 --> 02:12:53.070
But, you know, each proposal have a different level of complexity
1640
02:12:53.370 --> 02:12:54.510
and, you know, flexibility.
1641
02:12:55.370 --> 02:13:00.515
You know, each have their own trade offs. It will be interesting to see which ones pay the way for Bitcoin.
1642
02:13:01.054 --> 02:13:03.235
And can we talk about some of the proposals
1643
02:13:03.695 --> 02:13:06.355
that for covenants? I I know, what, in
1644
02:13:06.780 --> 02:13:15.760
2013 or some some Greg Maxwell made a post back in the day. There's been I don't know if that was quite a proposal, more of just an idea, but what proposals currently exist today
1645
02:13:16.275 --> 02:13:19.095
that are covenant proposals, I guess, you could say?
1646
02:13:19.955 --> 02:13:26.120
Is that for me? Alright. So anyone that wants to answer. I have a favorite one, which I'll tell you about last, but,
1647
02:13:26.840 --> 02:13:35.395
there are a lot of I think one thing that's important to understand when we say the word proposal, it means different things. So there is a BIP, which is a Bitcoin improvement proposal,
1648
02:13:36.014 --> 02:13:39.554
and that is a proposal that is it is, like, very structured,
1649
02:13:40.179 --> 02:13:45.159
and, they can be at different levels of readiness. And so when you talk about a proposal,
1650
02:13:46.179 --> 02:13:53.565
there's also a sort of idea, right, of, hey. What if we did this? So there are a lot right now of what if we did this's.
1651
02:13:53.945 --> 02:13:56.765
And as far as I'm aware, there's only, like, one
1652
02:13:57.270 --> 02:14:03.369
or maybe 2 things that are kind of more on the side of, like, here is a concrete thing that we could do.
1653
02:14:03.670 --> 02:14:09.534
So in the the scope of things that are, like, here are ideas, people are talking about what if we added, like,
1654
02:14:09.914 --> 02:14:10.414
a
1655
02:14:10.875 --> 02:14:20.400
language that itself in scripting was maybe, you know, like a lisp or some sort of, like, actual programming language to Bitcoin, then we could compute
1656
02:14:20.795 --> 02:14:40.565
any arbitrary covenant we ever could want. We could say all the possible covenants we could express. That's something people are thinking about, but nobody has, like, a code sample that you could run and try with. And then, there are some maybe, like, application specific covenants that are, like, rather than this big general purpose thing. Like, what if we just had a covenant that let us manipulate
1657
02:14:40.945 --> 02:14:56.065
Tapscript and manipulate the tree that we've seen? There's one called Taplyk update verify that people are getting maybe a little excited about. There are some other ones people have talked about as well, but all those things are kind of in the space of, hey. I've got a cool idea. Don't know exactly what it would look like.
1658
02:14:56.605 --> 02:15:00.945
The the 2 that have, some potential for covenants that are in the more concrete
1659
02:15:01.390 --> 02:15:01.890
phase
1660
02:15:02.270 --> 02:15:05.090
where it's something maybe that could be considered for merging,
1661
02:15:05.390 --> 02:15:25.490
and activation at some point in the next, like, year or 2 would be check template verify, which is the proposal that I work on. And Anyprevent, which is one that is in the Lightning community primarily, but has applications for covenants that are not, like, if you said we can remove covenants from any prevout, the Lightning community probably would do it because they're focused on it for a different application. So it's sort of a side effect.
1662
02:15:26.830 --> 02:15:29.155
And so for Check Template Verify,
1663
02:15:30.495 --> 02:15:32.995
I like covenants, and I think that generally covenants
1664
02:15:33.455 --> 02:15:47.605
are something we should explore, But a lot of people in the community, like Greg Maxwell in this original post where he shared it, had a lot of reservations around, are covenants good? Are they bad? Can they have bad, you know, bad things happen? And so when I designed CTV in 2019,
1665
02:15:48.545 --> 02:15:52.805
I said, can I make a covenant that is the simplest possible thing that
1666
02:15:53.150 --> 02:15:54.930
that basically if you don't
1667
02:15:55.230 --> 02:16:07.255
want CTV, then you will not want any covenant system ever, at least in terms of functionality? Maybe you'll disagree from a product management point of view. But if you say, CTV is bad, here's why CTV is bad, then we can rule out all covenants forever.
1668
02:16:07.555 --> 02:16:41.035
But if you're like, CTV is good, like, well, we'll get something done maybe, and then we can talk about the more sophisticated things. So so it's like CTV is, like, the smallest unit of covenant where it's like, hey. If we can prove that this is bad, then we know covenants are bad. But if this is good, there might be more opportunity. Yeah. I I think that's how I would describe it. And just in terms of, you know, like, the doneness of the proposal, it it is in a form where, like, you could merge, activate, and release it, you know, starting now if you wanted to. So it's more in the category of product management decision rather than there's still an engineering question around how would we actually implement this thing.
1669
02:16:42.774 --> 02:16:59.694
I Yeah. I think that's I think those are all really interesting things about how we, like, kinda move Bitcoin forward, etcetera, and, you know, this covenant proposal covenants will have to go through that process at some point. I think, like, as, like, a as a person who works on Bitcoin stuff though, I'm gonna be honest, like,
1670
02:16:59.995 --> 02:17:02.734
I'm not totally I think covenants are cool
1671
02:17:04.020 --> 02:17:07.561
technically. There's literally cool stuff I think that they enable
1672
02:17:08.101 --> 02:17:13.561
but I'm not totally sold that we need to make Bitcoin more complicated and add more
1673
02:17:14.165 --> 02:17:16.904
ways of making it harder to spend bitcoin.
1674
02:17:18.245 --> 02:17:23.225
So maybe I think there's 2 things here is like, you know, there's much different proposals about how to do covenants.
1675
02:17:24.020 --> 02:17:28.120
I think maybe we could talk about, like, what's how accessible are these? Like,
1676
02:17:28.740 --> 02:17:37.835
how, like, in terms of, like, you know, like, is it are these things that like everyday bitcoiners are gonna are we gonna make it easier for the is this gonna make it easier for them to, like,
1677
02:17:38.695 --> 02:17:39.755
secure their bitcoin?
1678
02:17:40.056 --> 02:17:40.775
Is it like
1679
02:17:41.720 --> 02:17:43.880
I don't know. Yeah. Like, if like, why
1680
02:17:44.439 --> 02:17:48.300
what about coming into, like So so let's let's start with, like, the major,
1681
02:17:48.815 --> 02:17:56.755
like, beneficial use cases maybe, where y'all can talk about, like, one one that you're interested in, for instance, is security. Like, how how does this benefit us?
1682
02:17:57.135 --> 02:18:23.070
Yeah. I think, yeah, we have some very I have some favorite proposals like CTV. I think it has many it enables many use cases. I think the primary one my favorite one is channel factories so that you can, you know, open thousands of channels in a single UTXO. And you you don't necessarily need to close them because they can they can source you in more liquidity later. But also I also, Tableau update verify also can, potentially bring, you know, channel factories as well,
1683
02:18:23.610 --> 02:18:38.540
so that you can open it's a shared UTXO model. You can open, like, tons of channels as well. But I think when you wanna close them, you only close the channel you are interested in as opposed to CTV when you have to you have to declare all channels first to call some. But, anyway,
1684
02:18:39.340 --> 02:18:39.920
I think,
1685
02:18:40.380 --> 02:18:43.120
one other interesting use case of CTV is vaults.
1686
02:18:43.820 --> 02:18:46.235
You can, as well as channel factories again.
1687
02:18:46.716 --> 02:18:49.056
But I think, you know, overall, when you look at covenants,
1688
02:18:49.596 --> 02:18:53.855
everyone can benefit from it. Like, if you're a Lightning enthusiast, you can benefit
1689
02:18:54.421 --> 02:19:03.320
because it can bring l 2 to channel factories and noninteractive channel setups. If you're a self custody guy, great. It's for you. It's it's great for you. I mean, it could bring bring Vols to Bitcoin,
1690
02:19:04.056 --> 02:19:07.035
and I don't know, some sort of advanced self custody.
1691
02:19:07.575 --> 02:19:16.091
If you're, you know, Bitcoin scaling nerd, it's good for you. Maybe it could bring later on, you know, some points to Bitcoin, maybe trust those SPV side chains and us.
1692
02:19:16.471 --> 02:19:17.211
Yeah. So,
1693
02:19:17.591 --> 02:19:20.171
yeah, first responding to Lisa's question,
1694
02:19:21.085 --> 02:19:29.105
where, like, why are we adding this complicated stuff? So, like, definitely, it should be determined like, defined by what use case you're adding.
1695
02:19:29.410 --> 02:19:40.585
So in this case, we have some scaling benefits by proposals like coin pools where one UTX source would be this is not specific to check template verify or any single proposal, but with generally
1696
02:19:41.205 --> 02:19:47.109
some governance. Suppose we could have coin pools where you have one UTXO, which is controlled by multiple parties.
1697
02:19:47.729 --> 02:19:51.909
Like, if you imagine Bitcoin scaling to the world, we need some sort of coin pool proposals.
1698
02:19:52.705 --> 02:19:53.364
Then secondly,
1699
02:19:54.064 --> 02:19:54.465
vaults.
1700
02:19:55.024 --> 02:19:59.845
And I'd like to, like, distinguish between CTV vaults and more powerful vaults.
1701
02:20:00.385 --> 02:20:01.205
And I think,
1702
02:20:01.950 --> 02:20:02.510
like, for
1703
02:20:02.990 --> 02:20:05.090
at least for me, covenants are kinda
1704
02:20:05.470 --> 02:20:06.609
like the end game.
1705
02:20:07.069 --> 02:20:13.565
Like, I like, we need to have some sort of self custody solution more powerful than you
1706
02:20:14.185 --> 02:20:17.965
than what we have today. I would not be comfortable, like, storing
1707
02:20:18.351 --> 02:20:20.830
huge amount of Bitcoins in what we have,
1708
02:20:21.471 --> 02:20:25.570
like, in the recommended security setups today. For example, in
1709
02:20:25.905 --> 02:20:30.385
governance, which were suggested in the original paper by our favorite professor,
1710
02:20:32.226 --> 02:20:35.686
we had a design where even if you lose your cold keys,
1711
02:20:36.690 --> 02:20:38.311
you could still, like,
1712
02:20:38.931 --> 02:20:47.165
get in a race with the attacker and try to burn your phones. So that offers a new level of security, which we currently don't have with,
1713
02:20:48.265 --> 02:20:52.525
like, any form of governance. Or even with CDB, we don't get that form of security.
1714
02:20:53.181 --> 02:20:56.720
And so there are these new use cases which governance
1715
02:20:57.420 --> 02:21:01.760
enable that we that we don't get if we don't have them. Secondly,
1716
02:21:03.205 --> 02:21:18.710
it is often. That's the most fundamental part. Like, if people are using covenants, and if you're not using covenants, then it doesn't affect you. Like, new proposals, sure. They do affect you. You should care about a few things when new proposals are suggested. Like, is your full not doing more work than
1717
02:21:19.255 --> 02:21:23.515
what it is getting like, is are there any denial of service concerns,
1718
02:21:24.055 --> 02:21:25.034
about it? Maybe
1719
02:21:25.415 --> 02:21:32.329
like, you could do weird funky stuff with, covenants, but when we suggest proposals, we should make sure that, you know, those concerns
1720
02:21:32.869 --> 02:21:34.090
are addressed properly.
1721
02:21:34.470 --> 02:21:34.710
So
1722
02:21:35.825 --> 02:21:36.325
Before
1723
02:21:37.104 --> 02:21:50.860
just just to kinda rephrase what we're talking about. I mean, we've talked about channel factories, so opening up thousands of channels in one transaction. Right now, if you open up a a channel on Lightning, that's one transaction. Right? So we we're we're talking about general scale.
1724
02:21:51.320 --> 02:21:52.301
We're talking about,
1725
02:21:53.000 --> 02:21:53.500
vaults,
1726
02:21:54.346 --> 02:22:00.365
which enable security. You you even said right now you don't feel comfortable with what's available. So you would actually
1727
02:22:01.760 --> 02:22:10.180
you you feel uncomfortable being a Bitcoin right now with the current technology is what is what you're saying, and and and you would feel more comfortable with vaults and and covenants that enable those things. So
1728
02:22:10.625 --> 02:22:22.119
those are those are some of the bit did you did you wanna add anything? Well, yeah. I I was just gonna add maybe 2 quick points. Sure. One is that, like, I hope in the next couple years we're able to add, like, tens or 100 of 1,000,000 of more Bitcoiners.
1729
02:22:22.659 --> 02:22:47.450
And even if we're, like, coming up with better things in the long run, I would really like if the story that we have for every one of those users coming on is that we get them started with something that's more secure or more scalable. And I think that that's why I, at least, you know, people critique that I say maybe, like, urgency, but, like, I try to do these things with urgency because for every user coming in, I wanna give them the best that we know how to do. And the second point that I would make, which is like should we be adding more complexity,
1730
02:22:48.105 --> 02:22:53.885
is, you know, like, sorry. The complexity is already here and people are doing these things, but either in more centralized,
1731
02:22:54.186 --> 02:22:54.686
trusted,
1732
02:22:55.511 --> 02:22:56.971
trusted means not trustworthy,
1733
02:22:57.590 --> 02:23:00.811
maybe a linguistic quirk, but using a trusted party
1734
02:23:01.431 --> 02:23:01.931
ways,
1735
02:23:02.870 --> 02:23:12.165
and these things I think are just completely worse. So if the market's already adopting solutions like that, we should do something that reduces the amount of trusted parties required for things people are already doing. So
1736
02:23:12.705 --> 02:23:14.245
now are you convinced?
1737
02:23:15.060 --> 02:23:18.200
I mean, it sounds like we're making a trade off here between complexity
1738
02:23:18.580 --> 02:23:22.580
and some amount of, like, security or, like, functionality. Right? So,
1739
02:23:24.186 --> 02:23:29.485
yeah, I don't know. I no. I don't I don't know if I am totally convinced. It is opt in though. Right? Well, actually,
1740
02:23:29.865 --> 02:23:31.645
just on the specific word complexity,
1741
02:23:33.051 --> 02:23:36.830
the the the protocol, for example, for opening up lightning channels with covenants is
1742
02:23:37.210 --> 02:23:49.436
simpler than the protocol for opening lightning channels without covenants. And so that's something where, actually, by having a slightly better technology, we can reduce complexity in other parts of the stack. So the overall complexity goes down. So I have a question for you, Lisa.
1743
02:23:51.220 --> 02:23:51.960
Is there
1744
02:23:52.500 --> 02:24:01.035
and maybe there's another way, but how do you how how can you open up and scale Lightning in terms of opening up a ton of channels without covenants? Is there another way?
1745
02:24:02.295 --> 02:24:05.755
Right now, every channel is represented by a UTXO.
1746
02:24:06.215 --> 02:24:06.615
Mhmm.
1747
02:24:07.250 --> 02:24:22.635
Which I I would say that's kinda simple in terms of, like, when people are in a channel, they understand what they own. It's a shared UTXO. Right? So maybe the complexity in opening it is a little hard, but the simplicity of what you own when you open a channel is very straightforward, I would say.
1748
02:24:23.780 --> 02:24:29.320
So, like, it's an on you know, it's on chain thing. You can go look it up on a block explorer. You can see where your channel funds are.
1749
02:24:30.580 --> 02:24:32.280
Yeah. So, like,
1750
02:24:32.645 --> 02:24:39.545
that's so it but that the limit on that then is that every channel open must be represented by an on chain
1751
02:24:40.085 --> 02:24:48.850
output. Is this, like, dichotomy or is this, like, trade off here, complexity versus scale? And is that kinda how we would see this, or is that not is that a bad
1752
02:24:49.455 --> 02:24:49.955
simplification?
1753
02:24:50.415 --> 02:24:54.415
Well well well, so one one of the things that I try to emphasize is that,
1754
02:24:55.455 --> 02:24:56.755
when you create a channel,
1755
02:24:57.135 --> 02:24:58.755
let's say that there are,
1756
02:24:59.681 --> 02:25:19.005
the maximum is something around, like, 20,000 people trying to open channels in a given block. Like, it's it's probably a little bit less than that, probably more like 5,000 people trying to open up channels. Sure. Probably, like, 4 or 5000. Yeah. That would be, like, the maximum. Right? And then what's interesting is as soon as you have 5,001 people, you will now over a long time have an infinite list of people trying to open channels.
1757
02:25:19.370 --> 02:25:57.920
And so you end up in a world where everybody who wants a channel is now not gonna have a channel. They're gonna have to go to, like, a trusted service that says, yeah. We're not gonna rug you on opening this channel. And then that, you can't look up in a block explorer either because it's and then you might say, oh, well, we can only support this many users. So I would rather have a pathway to supporting a larger number of users where they have to do something slightly different than, say, we're bounded by this constraint of Bitcoin, and we can only support top tier users at this amount. And I think we can still support people who are willing to pay for that 5,000 per block space if they want it, but now we're able to grow the pie and support more users overall. So so the human humanitarian
1758
02:25:58.540 --> 02:26:02.395
Jeremy Rubin wants even poor people to use Bitcoin. I'm for the.
1759
02:26:02.855 --> 02:26:04.855
Okay. Understood. So again, like
1760
02:26:05.815 --> 02:26:07.035
Thank you. This is
1761
02:26:07.815 --> 02:26:11.000
this is often, so you can still do what you are doing today. Like
1762
02:26:12.040 --> 02:26:20.540
and as long as what other people are doing with their UTXOs, you should only be concerned that it does not increase your verification costs, which can be evaluated per proposal.
1763
02:26:20.920 --> 02:26:34.880
It It actually should decrease your costs because, like, if there's 5,000 people, presumably, like, you know, half of them are probably okay with using the more scalable thing that, you know, it doesn't decrease block space demand, but it, like, lets you have more priority for if you really do need that space for an immediate open.
1764
02:26:35.635 --> 02:26:45.335
Yeah. But I guess, like so it sounds like if we're adding all this if we're but then you're changing the model then so it's not one UTXO per channel. Right? It's something else. So now you need, like,
1765
02:26:45.700 --> 02:26:46.520
more tooling and more,
1766
02:26:47.220 --> 02:27:03.870
like, ways to see, like, the visibility, etcetera. Right? So I think, like, adding adding cabinets is more like, you need more there's gonna be more we need more infrastructure for these things. Right? Yep. It's kind of what I think. We need more tooling for these kind of use cases.
1767
02:27:04.410 --> 02:27:06.330
And I think that this is sort of the,
1768
02:27:06.811 --> 02:27:12.305
and maybe this is, like, the magic of CTV as a covenant solution is that the thing that CTV expresses
1769
02:27:12.685 --> 02:27:24.650
is purely just a list of transactions that would get played in the future. And so there's no sort of really complicated infrastructural need for something like a Lightning node. All you have to do is say, okay. We're aware of these things that are pending transactions,
1770
02:27:25.030 --> 02:27:53.574
and we're able to see that they're CTV, so we can prove that they would happen in the future. And then you would just count those as fully confirmed rather than just sitting in the mempool unconfirmed. And that that's the only difference. For the more interpretive things, like, even things based in, like, any prevout or, like, those types of channel factories, well, then you've gotta, like, be, like, constantly, like, rebinding and scanning and things like that. And those have a lot more infrastructure requirements. But in terms of, like, an immediate migration path, we can, like, probably get something working pretty easily and then do the more complicated stuff in, like, the span of, like, decades or whatever.
1771
02:27:54.630 --> 02:27:59.370
I I kinda want oh, sorry. Go for it. Sounds good. Yeah. So, like, in terms of,
1772
02:28:00.480 --> 02:28:02.705
like, like, I know we are discussing CTV
1773
02:28:03.165 --> 02:28:05.345
a lot, but in like, I just like
1774
02:28:05.725 --> 02:28:06.945
to, like, you know, highlight
1775
02:28:07.325 --> 02:28:08.705
one of the things where,
1776
02:28:09.245 --> 02:28:10.790
like, I'm sort of,
1777
02:28:11.170 --> 02:28:14.069
trying to address to the crowd who think that
1778
02:28:14.609 --> 02:28:18.775
covenants or, in particular, some form of covenants are dangerous. And,
1779
02:28:19.716 --> 02:28:29.390
CTV in one proposal is, like, motivated by the design to avoid certain set of covenants, which we call as we don't have the time to get into it, but recursive covenants or unenumerated
1780
02:28:29.770 --> 02:28:30.270
covenants.
1781
02:28:31.050 --> 02:28:33.150
I think rather we should, as a community,
1782
02:28:33.610 --> 02:28:39.756
like, regardless we should have CTV or should not have CTV, we should try to address those concerns of people who are
1783
02:28:40.615 --> 02:28:41.115
against,
1784
02:28:41.655 --> 02:28:43.756
like, recursive covenant because they enable
1785
02:28:44.270 --> 02:28:46.110
new use cases, then,
1786
02:28:47.150 --> 02:28:52.290
like, c t it is independent of the issue of CTV, but I don't want the motivation for CTV to be,
1787
02:28:53.086 --> 02:29:01.426
oh, look. We are trying to avoid these dangerous things. The motivation can be, look. This is simpler. That's why we should do it. It's fine. But there are a lot of people who are advocating this because
1788
02:29:02.050 --> 02:29:03.510
they want to avoid something,
1789
02:29:04.850 --> 02:29:10.630
seemingly the dangers of recursive covenants. And if you refer back to the post from Greg Maxwell, you'd see that,
1790
02:29:11.364 --> 02:29:18.345
he does not say that there are dangerous thing. He actually chats in some way challenges everyone, like, what dangerous things can you do with governance?
1791
02:29:19.440 --> 02:29:54.025
So, yeah, I can't get into the technical details right now, but that's just Well, I I I kinda disagree. We're we're already over time, and I say we just keep going till we get kicked off because because I think this is kinda interesting. On time. So Yeah. So so, I mean, if y'all are cool with it I mean, if the audience is cool with it, I I I think this is super important to talk about because I was actually wanting to bring that up, the recurse like, let's play devil's advocate just a little bit here and talk about maybe some potential security issues with covenants, maybe are addressed with the idea, you know, with CTV or with other ideas. What what what could go wrong
1792
02:29:54.630 --> 02:29:55.449
with covenants?
1793
02:29:56.630 --> 02:30:11.905
Is there potentially a bounty? You know? Like, you know what I mean? Like I I think one thing that, like, look look, I actually believe in, like, doing this process to get towards as much covenants as we can do. So, like, I'm on board with that. I think I just wanna be a friend to the people who are, like, more conservative.
1794
02:30:12.340 --> 02:30:21.475
And I think a fair thing that they can ask is, okay, it's not enough that you can say there's some argument that, like, these things aren't bad. Please prove to me that it's safe.
1795
02:30:21.955 --> 02:30:23.494
And until we get to that level
1796
02:30:23.875 --> 02:30:24.534
of sophistication,
1797
02:30:25.314 --> 02:30:29.895
I think that a more conservative approach is ultimately what the community wants,
1798
02:30:30.435 --> 02:30:30.935
and
1799
02:30:31.260 --> 02:30:38.479
I am trying to cater to the community more than I'm trying to do the thing that I want, even though I I might want something more personally.
1800
02:30:38.895 --> 02:30:55.279
Overall, I just want something that's gonna let us do at least, like, half of the cool things. Okay. So I kinda disagree. Yeah. I kinda disagree with this over here. Let's, for example, take the example of, this is not a good analogy, but just for argument's sake, let's take the example of the tap root. If we
1801
02:30:55.705 --> 02:31:25.820
just, like, tried to address a subset of community that said that this is not quantum secure, for example, and we modified the route to, you know, do something dangerous and try to get everyone in. We would not have this proposal that we have today. Instead, what we work towards is, like, addressing concerns of people like, look. Quantum computers are going to come tomorrow. And even if we have them, we have bigger problems. Right? So it's not a fair critique because that would also make a complicated solution where a CTV is simpler. So coming back to the point, I think we should, like,
1802
02:31:27.240 --> 02:31:28.380
suggesting the community,
1803
02:31:30.395 --> 02:31:45.485
like, a wrong idea might get like, might backfire in future. Maybe earlier people believed that Bitcoin is free and had businesses built on top of it. And maybe today people think that, you know, recursive covenants are not secured and that's why we are supporting this. I,
1804
02:31:45.806 --> 02:31:49.825
like, I think I agree that CDP is simple and that is a good enough merit, but
1805
02:31:50.285 --> 02:32:06.075
we should also, like, address the community that, look, this is not dangerous and maybe we need more time for it. That's okay. Yeah. So so so I think one thing that's kind of interesting about that is that, like, you might you can agree or disagree, but at any point in getting the community convinced on the more complicated things, there will be a checkpoint
1806
02:32:06.455 --> 02:32:09.195
where you pass people being comfortable with CTV's functionality.
1807
02:32:09.575 --> 02:32:14.630
I agree with that. And then if that's true, the question becomes once we've surpassed that threshold,
1808
02:32:15.810 --> 02:32:30.904
how much time do we get to the point that we actually might want to go to, and then how many users come on board with, like, less secure, you know, custody solutions in the meantime between those two things. Why why would people be uncomfortable with this recursive stuff? Like, what are we what's the undiscomfort
1809
02:32:31.590 --> 02:32:32.250
that we're
1810
02:32:32.710 --> 02:32:34.490
like talking about here? So,
1811
02:32:34.950 --> 02:32:36.649
let's Good question. Yeah.
1812
02:32:37.430 --> 02:32:40.330
So this recursive covenants in particular,
1813
02:32:41.046 --> 02:32:48.360
they allow you to, like, wall guard on your coins. Maybe you can you can get into a covenant that you cannot escape out of.
1814
02:32:49.320 --> 02:32:59.075
And this, like yeah. This sounds dangerous. Right? Why would you put your coins into something which you cannot get out of? Like, you know, you're just We're not trying to make Bitcoin like Ethereum.
1815
02:32:59.455 --> 02:33:00.915
Yeah. Or maybe like you,
1816
02:33:01.295 --> 02:33:10.965
like one of the concerns is like just the US government goes to Coinbase and says put all your coins in this covenant, and it's a recursive covenant. So whenever you spend those coins, you need the signature of,
1817
02:33:11.925 --> 02:33:26.180
like, a cc. And whenever you want to transact you have to send a copy to them, and now they have everything. Why are we building this technology to help? That's a valid question. Right? And that's why people are scared. But the bad news is they can already do that today.
1818
02:33:27.085 --> 02:33:29.265
They can just do it with what we call multisync.
1819
02:33:29.645 --> 02:33:31.265
But but the well,
1820
02:33:31.645 --> 02:33:36.850
I was gonna say I think to address the question, I think it's like the idea of the recursiveness. It's like
1821
02:33:37.229 --> 02:33:51.315
you you pretty much have, like, a deadlock on that contract, which does what? Does that break Bitcoin, or does that just break that transaction? What does that actually do? Yeah. You know what I mean? So so I think that rec recursive is just, like, a little bit of a stand in for, like, hard to analyze.
1822
02:33:51.720 --> 02:33:57.180
And I think we're okay with any covenant that we know how to analyze to show that it's safe or that it's good or beneficial.
1823
02:33:57.800 --> 02:33:58.300
And
1824
02:33:59.655 --> 02:34:43.355
that that I think is is why, like, for for for certain purposes, something like CTV is okay because it's very easy to analyze. So we're saying, okay. The analyzability of this is very basic. So we could say we know all possible state transitions. We're good. For me, the concern with recursiveness is that when you have these more flexible things, like, you might not have properly proved that the covenant is actually correct and there might be some sort of like Ethereum has these things with, like, you know, recursive reentrant, you know, contracts where you call the thing and then you call into the thing and then the number doesn't get updated properly and then you burn all the money or you steal the money. And those are the at least from my perspective, those are the types of issues that our ability to prove and reason about these things. Like, we would need a lot better tooling and infrastructure to do it, safely. So so so no loops are,
1825
02:34:43.730 --> 02:34:59.965
like, enabled? Is that, like, a easy layman way of Yeah. No loops. It's you gotta know the entire Yeah. You you know the you know the Yeah. The whole span of the tree of possible states. And and that's a huge trade off to get that analyzability. There are other things that also might have some similar analyzability, but are more flexible.
1826
02:35:00.345 --> 02:35:02.910
But on all the choices, I just did conservative,
1827
02:35:03.450 --> 02:35:16.355
for this. And, you know, I I do think the conversation and defining the properties and not just having, like, one big stand in of recursive bad, you know, like, is is really important, but it's the analyzability I think is really the the thing we need. Yeah. So we can have analyzability
1828
02:35:16.735 --> 02:35:22.800
in, like, per particular smart contract basis. If user just want like, if they want to shoot themselves in the foot, they can do that today with
1829
02:35:23.600 --> 02:35:35.240
They should know if they're shooting themselves in the foot. That's that's, I think, the thing. Right? Yeah. If you if you are dealing with these type of things, you should know. Like, for example, there are, I think, could be things in lightning contracts which you can mess up. Right?
1830
02:35:36.440 --> 02:35:39.020
So, like You would hate that. Yeah.
1831
02:35:40.280 --> 02:35:42.061
So whenever you're dealing with scripts,
1832
02:35:42.695 --> 02:35:47.195
you can mess up. It's just the the thing sounds scary. It's like if you mess up, your coins are gone forever.
1833
02:35:47.655 --> 02:35:51.275
There are also similar, like, risks associated with smart contracts today.
1834
02:35:51.600 --> 02:36:05.125
So it isn't that we are adding some new thing which was not, like, some new attack vector which was not present today. And as I mentioned, like, for example, using maybe just a single signature today with music, maybe covenants are already on the way. Like, we
1835
02:36:05.585 --> 02:36:09.450
like, what what I I think the thing with lightning is actually kind of interesting
1836
02:36:14.263 --> 02:36:14.763
with
1837
02:36:19.155 --> 02:36:31.860
just with people enforcing it, and if you've got automated things running this, it's just a question of like, is it the Bitcoin blockchain shooting you in the foot, or is it the automated services you have that are doing it? And I think for an end user, it might not be terribly different.
1838
02:36:32.240 --> 02:36:38.585
The the the covenants and this is similar to what we said earlier. It would just be like while we're shifting it to something that requires less signatures.
1839
02:36:39.205 --> 02:36:55.955
I have, like, sort of a do we have time for, like, good? We're going till they kick us off. Okay. Yeah. If you're in the back and you're like, we need to kick us off, worry about until When they when they cut off the mics, we'll walk off stage. Okay. Sounds good. So, like, the so my question is, like, is this kinda maybe this is, like, totally not related, but I'd really like to hear
1840
02:36:56.915 --> 02:36:59.495
so Lightning Labs just released this thing
1841
02:36:59.796 --> 02:37:05.730
that they're gonna add to the annexes of Taproots, which is like a whole new UTXO tree
1842
02:37:06.351 --> 02:37:08.610
and, like, a whole new scripting language,
1843
02:37:09.631 --> 02:37:10.770
this thing called tarot.
1844
02:37:11.551 --> 02:37:12.530
Is that a covenant?
1845
02:37:13.065 --> 02:37:35.625
Like, maybe this is too I know it just got announced yesterday. You guys haven't had a chance to look into it. Is that are those covenants? It's like coloring it's kinda like coloring Bitcoins. Right? Is that is that does that count as covenants? Has, like, labs, like, basically launched covenants on Bitcoin already with their Taro stuff and their color coin things? Or is this stuff that we're talking about covenants wise, like, totally different?
1846
02:37:37.030 --> 02:37:41.610
I I have reviewed it, so I don't know if you guys have had No. No. I didn't have Okay. So, Jeremy,
1847
02:37:42.870 --> 02:37:51.016
you've been you haven't been doing any talking on this panel. Why don't you go ahead and Yeah. Also, I know I've talked too much, so like that's fine, like hopefully one of you had read it, but I've read it. So,
1848
02:37:52.695 --> 02:37:54.395
I would answer that
1849
02:37:54.830 --> 02:37:55.649
it is not
1850
02:37:56.189 --> 02:37:56.689
Bitcoin
1851
02:37:56.990 --> 02:38:02.905
validated covenants. It is client side validated covenants, which means that you're free
1852
02:38:03.285 --> 02:38:06.425
to if you own one of these things, you can definitely
1853
02:38:06.885 --> 02:38:07.385
burn
1854
02:38:08.085 --> 02:38:17.289
all the coins, and that will, you know, escape because you've just messed it up. Mhmm. But if you're running the the software, you will generate artifacts that somebody else could verify.
1855
02:38:18.149 --> 02:38:24.604
And that and, also, also, just a technical note, they're not in the annexes, which is important for something. But, anyways, they're
1856
02:38:25.785 --> 02:38:26.185
they are
1857
02:38:27.200 --> 02:38:37.226
they they internally can have their own covenants and things, but there's always a top level clause which says basically, well, you're free to mess it up if you want to. And so Bitcoin does not have covenants, but in their system,
1858
02:38:37.605 --> 02:38:52.466
it is kind of a covenant, if that makes sense. So if you could do covenants that way, why do we need to change the Bitcoin script itself if we can You could not build a vault with, with Terra. I see. So the one of the benefits of adding covenants to Bitcoin, like,
1859
02:38:53.006 --> 02:38:53.506
as
1860
02:38:54.086 --> 02:38:54.586
of
1861
02:38:55.165 --> 02:38:57.346
infra- inside, like, the Bitcoin infrastructure
1862
02:38:57.726 --> 02:39:03.390
itself is that now we can express things about Bitcoin, like your Bitcoin
1863
02:39:04.010 --> 02:39:05.310
hoard so to speak,
1864
02:39:06.010 --> 02:39:09.865
whereas adding stuff like the project that Lightning Labs announced,
1865
02:39:10.565 --> 02:39:13.545
doesn't give you that level of control is my understanding.
1866
02:39:13.925 --> 02:39:17.760
I'd say that's a correct understanding. I just wanna just to kinda
1867
02:39:18.140 --> 02:39:31.556
put a cherry on top of in terms of the devil's advocate stuff for CTV or whatever, I I just wanna include Barak here just a little bit here. I know I know you're currently using blockchain product liquid. Yes. What is something like CTV potentially missing
1868
02:39:32.000 --> 02:39:45.515
that you would wanna see? Or or what where how are you using covenants? Or how are you using liquid where it's maybe not even gonna be satisfied by some of the stuff? Oh, yeah. I think we can I just wanna Yeah? We can already, I think, emulate CTV in to some extent in the element subcodes, but I think
1869
02:39:45.895 --> 02:39:50.830
with CTV, that emulation would be more efficient because you can do, like,
1870
02:39:51.230 --> 02:39:53.971
the channel factories, for instance, in 1 byte
1871
02:39:54.645 --> 02:39:57.225
as opposed to, you know, 100 lines of bytes. Right?
1872
02:39:58.165 --> 02:40:09.131
I think, you know, elements of codes, right, are less controversial to maybe to bait pay it on some of them to pay the bill for Bitcoin because they are pretty much not well tested yet, but they're being tested.
1873
02:40:09.591 --> 02:40:14.905
And elements is based on a Bitcoin core code base and I think are less less controversial
1874
02:40:15.285 --> 02:40:25.660
to my observation. Like, things like c from stack for checking arbitrary signatures and caps, like data manipulations. And maybe some arabatics, right, could maybe potentially come to Bitcoin.
1875
02:40:26.520 --> 02:40:32.540
But I think CTV, I think, is really simple. Right? And from what I observed, like, from the community,
1876
02:40:33.596 --> 02:40:38.895
people don't really Bitcoiners don't really want these highly expressive, I mean, very complicated
1877
02:40:39.275 --> 02:40:41.296
proposals. Right? They rather
1878
02:40:42.260 --> 02:40:54.415
powerful yet simple proposals. And I think, you know, when you think about it, covenants, this whole thing is really a spectrum. Right? I think CTV per I mean, it fits really in this middle of the spectrum. Right?
1879
02:40:54.955 --> 02:41:03.279
Whereas, you know, we could have, very expressive stuff, on the high high end of the spectrum, but it doesn't really make sense to, you know, merge into Bitcoin.
1880
02:41:03.979 --> 02:41:05.039
Thank you. And,
1881
02:41:05.510 --> 02:41:06.010
in
1882
02:41:06.635 --> 02:41:13.215
60 seconds or less, what does CTV need to cross into Bitcoin? What does it need going forward?
1883
02:41:13.811 --> 02:41:15.430
Maybe you can talk a little bit about that
1884
02:41:15.970 --> 02:41:18.710
very quickly. So there's a website, utxos.org/signals.
1885
02:41:20.130 --> 02:41:29.414
This is kinda the best effort that I'm doing, which is just, like, making sure more people in the community want it, and if anybody doesn't want it, they express in a coherent way what their opposition is.
1886
02:41:29.795 --> 02:41:31.910
Right now, there's, like, a 130
1887
02:41:32.770 --> 02:41:42.345
people in organizations who have been, like, yeah. Seems good. There's, like, 2 people or 3 people who've been, like, I don't want it because I think we have enough to work on with Taproot.
1888
02:41:43.045 --> 02:41:50.425
That's been the main, you know, kinda complaint. I think there are other people who might say they don't want it for various reasons. They like, I would really like to see more people
1889
02:41:50.760 --> 02:41:59.580
give one of these things like, oh, we don't want top group because of quantum things so that we can actually rebut the arguments. If you don't make the argument in the, you know, right forum, then it can't be rebutted.
1890
02:41:59.915 --> 02:42:09.295
And then beyond that, I just need to do, like, a a binary release and pick some parameters, and that's it. You know? And it's like then the community can decide to signal for it. We'll do a soft fork just like Taproot.
1891
02:42:10.681 --> 02:42:17.580
Lisa, did we learn anything? I learned a lot. This is really informative. A ton as well. Yeah. I really quickly wanna go through,
1892
02:42:18.275 --> 02:42:21.495
show how people can contact you, your Twitter, whatever.
1893
02:42:22.515 --> 02:42:25.415
Lisa, we can start, and we'll work together. I'm on Twitter at nifty,
1894
02:42:25.720 --> 02:42:28.060
n I f t I n e I, nifty nye.
1895
02:42:28.600 --> 02:42:30.779
Also work on core lightning. That's core_ln.
1896
02:42:31.720 --> 02:42:32.955
So I'm just there.
1897
02:42:33.355 --> 02:42:36.895
I'm, at Jeremy Rubin on Twitter, and,
1898
02:42:37.675 --> 02:42:41.775
yeah, you can find me there. Yeah. I am Burak. Like, simple as that. Burak,
NOTE
Transcription provided by Podhome.fm
Created: 3/17/2024 8:10:48 PM
Duration: 18351.203
Channels: 1
1
00:00:00.560 --> 00:00:01.380
2
00:00:02.560 --> 00:00:03.780
Good morning, Miami.
3
00:00:09.405 --> 00:00:11.665
By a show of hands, who was here last year?
4
00:00:13.245 --> 00:00:16.065
I can't see any of your hands, so that's a bad idea.
5
00:00:16.580 --> 00:00:21.720
Well, we've come a long way from last year. Last year, we were in a little tent. We called it the Fostome.
6
00:00:23.460 --> 00:00:25.320
It was more of a tent than a dome,
7
00:00:26.705 --> 00:00:34.645
but it was very active and we had a lot of people there and people were very excited about it. So this year, it was important for us to do it bigger.
8
00:00:36.440 --> 00:00:39.820
Might have overshot it a little bit. It's pretty, pretty huge.
9
00:00:40.840 --> 00:00:46.705
But at the end of the day, I hope you fill up this stage every day. We're gonna have it today, tomorrow,
10
00:00:47.085 --> 00:00:47.585
Friday.
11
00:00:49.165 --> 00:00:52.545
Really fantastic lineup. Absolute all star developers,
12
00:00:52.910 --> 00:00:55.250
open source contributors joining us.
13
00:00:57.230 --> 00:01:01.250
I imagine since most of you are here bright and early on the first day
14
00:01:01.715 --> 00:01:03.895
that you understand the importance of open source.
15
00:01:04.995 --> 00:01:10.695
I was gonna ask you how many of you are open source contributors to raise your hand, but I'm not gonna be able to see your hands. So
16
00:01:12.100 --> 00:01:18.040
I just wanted to say that I really do appreciate all the work that all of our contributors do in this space.
17
00:01:19.215 --> 00:01:22.034
They are what makes this this movement possible.
18
00:01:23.055 --> 00:01:23.795
Open source,
19
00:01:24.415 --> 00:01:25.395
you know, has
20
00:01:27.220 --> 00:01:29.880
obviously two main benefits to society.
21
00:01:30.820 --> 00:01:35.240
One being that we don't have to trust the code we run, that we can verify it ourselves,
22
00:01:36.685 --> 00:01:37.585
that it's independent
23
00:01:38.045 --> 00:01:39.025
of any corporation
24
00:01:41.325 --> 00:01:43.425
or entity that's in control of it,
25
00:01:44.765 --> 00:01:47.969
and that at the end of the day, this code
26
00:01:48.670 --> 00:01:49.810
can all be modified,
27
00:01:50.590 --> 00:01:51.090
distributed,
28
00:01:51.549 --> 00:01:52.049
improved,
29
00:01:54.204 --> 00:01:58.704
and will outlive any of the individual creators. It's very viral in nature.
30
00:01:59.645 --> 00:02:00.145
And
31
00:02:02.470 --> 00:02:03.290
I just
32
00:02:04.150 --> 00:02:08.170
am absolutely moved by everyone who continues to work in the space,
33
00:02:08.550 --> 00:02:09.850
work in open source,
34
00:02:10.584 --> 00:02:11.084
oftentimes
35
00:02:11.465 --> 00:02:13.005
for very little compensation
36
00:02:13.385 --> 00:02:14.444
when they could have,
37
00:02:15.145 --> 00:02:16.765
you know, a big paying job
38
00:02:17.785 --> 00:02:19.245
with some major corporation
39
00:02:20.220 --> 00:02:22.000
that is KYC ing you
40
00:02:22.700 --> 00:02:26.000
and trying to control everything you do and lock you into a system.
41
00:02:27.655 --> 00:02:32.955
I also wanna say just a huge thanks to the Bitcoin Magazine team for putting this together
42
00:02:34.215 --> 00:02:38.740
and really trying to make this a first class experience for open source.
43
00:02:39.280 --> 00:02:40.020
We have
44
00:02:40.960 --> 00:02:43.700
obviously the largest Bitcoin event in history
45
00:02:45.075 --> 00:02:47.095
happening in this venue today
46
00:02:47.635 --> 00:02:49.415
or and over the next few days,
47
00:02:50.515 --> 00:02:51.735
but this room
48
00:02:52.990 --> 00:03:01.010
believe there's about 1100 chairs in here, is larger than most conferences on its own, and we cannot have the largest Bitcoin event in history
49
00:03:01.630 --> 00:03:02.130
without
50
00:03:03.455 --> 00:03:06.035
the largest focus on open source in history.
51
00:03:06.735 --> 00:03:11.955
So I'm really grateful for them to make it happen. This has been months in the process.
52
00:03:12.620 --> 00:03:15.680
Big thank you to Cash App for actually sponsoring it,
53
00:03:16.780 --> 00:03:19.280
because this was a very expensive room to book.
54
00:03:22.775 --> 00:03:23.255
And,
55
00:03:23.735 --> 00:03:26.475
I appreciate you all for showing up because,
56
00:03:27.015 --> 00:03:29.195
you know, this is a movement of people.
57
00:03:30.570 --> 00:03:31.070
Without
58
00:03:31.650 --> 00:03:32.150
people,
59
00:03:32.730 --> 00:03:34.030
the code is just words.
60
00:03:34.330 --> 00:03:38.990
Right? We need the people to actually run it, build it, use it, support it,
61
00:03:39.615 --> 00:03:41.474
and that's what makes this movement great.
62
00:03:45.215 --> 00:03:48.035
I love you all. This is a very big moment.
63
00:03:48.540 --> 00:03:50.160
We're gonna have a lot of fun together.
64
00:03:50.620 --> 00:03:54.640
We have some really great programming today. Today is gonna be more technical focused.
65
00:03:56.115 --> 00:04:01.895
The next 2 days will be a little bit more accessible and a little bit more mainstream focused, but we have some really
66
00:04:03.530 --> 00:04:07.630
all star all star open source contributors that will be on panels today.
67
00:04:09.975 --> 00:04:17.035
And, I'm looking forward to it, and I hope you're looking forward to it as well. I got this big screen that's just me in front of me, which is kinda weird.
68
00:04:19.129 --> 00:04:20.669
I have 5 more minutes,
69
00:04:21.530 --> 00:04:26.590
but I'm not I don't think I'm just gonna, like, walk on stage and just keep talking. We're running a little bit behind,
70
00:04:27.884 --> 00:04:31.664
which is natural for these types of things right in the beginning. So we're gonna get started
71
00:04:32.365 --> 00:04:32.845
and,
72
00:04:33.805 --> 00:04:36.140
keep on building. I appreciate you all. Thanks, guys.
73
00:04:45.775 --> 00:04:52.115
74
00:04:54.020 --> 00:04:55.000
Welcome, everybody.
75
00:04:55.300 --> 00:04:57.960
Let's do quick intros for the people,
76
00:04:58.900 --> 00:05:00.120
the people of the audience
77
00:05:00.635 --> 00:05:01.135
specifically,
78
00:05:01.675 --> 00:05:03.215
and you, the viewer. Yes.
79
00:05:05.115 --> 00:05:06.895
I'm just so happy to be here with everyone.
80
00:05:07.740 --> 00:05:13.040
Zhuang, do you wanna maybe say your name correctly and also give a quick intro? Let's maybe,
81
00:05:14.140 --> 00:05:15.905
we have a little bit of time, but,
82
00:05:16.385 --> 00:05:20.165
maybe keep intro short so we can get to the the good stuff. I'm Zhuang.
83
00:05:21.585 --> 00:05:24.245
84
00:05:24.560 --> 00:05:25.780
in the Bitcoin space.
85
00:05:26.400 --> 00:05:29.620
One of the first to do lining. I'm happy to be here.
86
00:05:31.805 --> 00:05:35.905
87
00:05:36.365 --> 00:05:38.705
on core lightning, recently renamed.
88
00:05:39.645 --> 00:05:40.145
Yeah.
89
00:05:41.480 --> 00:05:42.220
90
00:05:42.600 --> 00:05:45.820
I'm building Breeze. Breeze is a lightning wallet and a platform
91
00:05:46.200 --> 00:05:48.380
to interact with the lightning economy.
92
00:05:49.405 --> 00:05:50.465
93
00:05:50.845 --> 00:06:03.479
I do business development at Lightning Labs, where we develop L and D and, you know, liquidity services, which is the topic of the panel. Perfect. I'm glad you I'm glad you're able to make it. No. Absolutely. Thank you for having and I'm I'm Michael Tidwell,
94
00:06:04.900 --> 00:06:09.685
95
00:06:10.625 --> 00:06:11.845
I I run infrastructure
96
00:06:12.145 --> 00:06:14.405
at Zebedee, a gaming platform company.
97
00:06:14.785 --> 00:06:15.285
So,
98
00:06:16.270 --> 00:06:20.610
let's let's jump into it. And, I think the first thing I wanna do is
99
00:06:21.390 --> 00:06:24.370
let's maybe talk about a little bit of history of LSPs.
100
00:06:24.974 --> 00:06:25.634
You know,
101
00:06:26.014 --> 00:06:33.634
this you know, I have no idea what an LSP is being fairly new to lightning myself. Maybe someone on the panel, someone maybe Roy Yeah. Can break down.
102
00:06:33.950 --> 00:06:38.370
What is an LSP? Who who even made up this term? What what is this? That's a good question.
103
00:06:39.550 --> 00:06:42.095
104
00:06:42.975 --> 00:06:44.995
LSP is a lightning service provider.
105
00:06:45.695 --> 00:06:46.655
It's kind of,
106
00:06:47.295 --> 00:06:48.515
the way that
107
00:06:48.895 --> 00:06:51.475
everyone can plug into the lightning network.
108
00:06:52.319 --> 00:06:59.939
Similarly to the way that you have an ISP and you plug your router in your home and you're plugged in into the, in Internet,
109
00:07:00.305 --> 00:07:06.164
the same way we need an infrastructure in Lightning that allows you to be connected to the network
110
00:07:06.625 --> 00:07:12.550
in as seamlessly as possible. So that's why wait. I remember. I coined the term LSC.
111
00:07:13.090 --> 00:07:14.310
Yeah. So
112
00:07:15.170 --> 00:07:17.350
that that's why I came up with this
113
00:07:17.705 --> 00:07:24.205
concept of a a Lightning service provider, and that's the service that facilitate this connectivity to the Lightning
114
00:07:24.585 --> 00:07:26.125
115
00:07:26.990 --> 00:07:33.970
I I just wanna say it it seems I I feel like we could talk about this stuff maybe for, like, an hour and a half because just because we're we're all doing
116
00:07:34.545 --> 00:07:40.885
pretty different things with lightning, like, LSPs and and and whatnot. Like, for instance, Zebedee is doing custodial
117
00:07:41.505 --> 00:07:42.965
LSP stuff, and
118
00:07:43.289 --> 00:07:44.909
Breeze, on the other hand, noncustodial.
119
00:07:45.530 --> 00:07:49.710
And we have a lot of cool things in between. I mean, there's so much to dig into. Yeah.
120
00:07:50.655 --> 00:08:00.500
I I kinda wanna maybe maybe we can kinda piecemeal this and kinda see where it goes, but, because these topics because within LSPs, there's there's so many different kind of, I guess you can
121
00:08:00.800 --> 00:08:01.120
say,
122
00:08:01.680 --> 00:08:02.420
use cases
123
00:08:02.800 --> 00:08:05.540
and and and implementations, I guess you could say.
124
00:08:07.074 --> 00:08:09.095
Maybe we start with with
125
00:08:09.875 --> 00:08:15.360
non custodial breeze route and then kinda work our way to what everyone else is doing. Yeah. Okay. Sure.
126
00:08:15.740 --> 00:08:20.639
127
00:08:21.020 --> 00:08:24.754
Lightning is in a noncustodial fashion. Lightning is the extension of Bitcoin.
128
00:08:25.134 --> 00:08:25.615
Bitcoin
129
00:08:25.935 --> 00:08:28.595
all the properties of Bitcoin of being censorship resistant,
130
00:08:29.055 --> 00:08:29.555
open,
131
00:08:30.095 --> 00:08:30.595
borderless,
132
00:08:31.055 --> 00:08:31.955
etcetera, etcetera.
133
00:08:32.319 --> 00:08:37.139
We need to bring that to the to the lightning network. So the only way that you can do
134
00:08:37.759 --> 00:08:38.259
really
135
00:08:39.815 --> 00:08:45.355
lightning is in a non custodial fashion, and and and the function of an LSP in just in that
136
00:08:46.055 --> 00:08:47.274
topology is
137
00:08:47.899 --> 00:08:57.279
how do you, as a user, how do you connect to the network? You actually need to run a node. Right? The node is the entity that facilitates your participant
138
00:08:57.645 --> 00:08:58.545
in the network.
139
00:08:58.925 --> 00:09:06.065
So you let's say you were able to run a node, and in Breeze, for example, we allow you to run a node on your mobile device.
140
00:09:07.050 --> 00:09:07.790
A node
141
00:09:08.410 --> 00:09:11.630
can do anything with the inside the lightning network without
142
00:09:12.250 --> 00:09:17.475
the ability to plug in to the network. So the LSP is the bridge between the network
143
00:09:17.855 --> 00:09:21.005
and the end user node. And the way that the
144
00:09:23.030 --> 00:09:28.090
LSP needs to connect the user to the Lightning Network is by opening a channel.
145
00:09:28.550 --> 00:09:30.250
There's an entity in Lightning Network,
146
00:09:30.710 --> 00:09:36.055
which is called the payment channel. The LSP needs to open a payment channel and provide liquidity
147
00:09:36.835 --> 00:09:38.135
to the end user.
148
00:09:38.995 --> 00:09:41.175
149
00:09:41.490 --> 00:09:42.230
does anyone
150
00:09:43.250 --> 00:09:48.950
have a different take? Like like, for instance, the thing that Roy just described, does it scale? Does anyone have any, like,
151
00:09:49.445 --> 00:09:49.945
maybe
152
00:09:50.325 --> 00:10:02.200
counter objection or slightly different angle that they would want to talk about here? Or do does everyone just 100% agree with Roy? I'm just curious. Anything? I think the the the key thing that Roy said that I definitely agree with is,
153
00:10:02.680 --> 00:10:16.180
154
00:10:16.800 --> 00:10:19.620
operating on a custodial node, some will be on non custodial,
155
00:10:19.935 --> 00:10:31.950
but that function of connecting the core to the edge, that is the service that's provided. It's connecting you to the broader lighting network, which you know, I particularly work with a bunch of like a cross section of a bunch of different LSPs,
156
00:10:33.370 --> 00:10:35.870
like everybody on the stage, Lisa aside.
157
00:10:36.410 --> 00:10:36.910
But
158
00:10:37.450 --> 00:10:37.950
we
159
00:10:39.305 --> 00:10:43.805
there's all sorts of different use cases and different things that people are doing on lightning from sending funds
160
00:10:44.665 --> 00:11:00.725
to emerging markets, from playing games, from playing podcasts, etcetera. And the function of making that connection seamless of making sure that you can get from stats from the edge of the network through the core to some other destination like that function at its core is is what the Lightning Service Provider does.
161
00:11:01.505 --> 00:11:05.310
162
00:11:06.250 --> 00:11:08.269
of a big company, publicly traded
163
00:11:08.649 --> 00:11:12.029
company, they might not, at this time, be ready to run a non custodial,
164
00:11:12.569 --> 00:11:13.470
you know, infrastructure.
165
00:11:14.485 --> 00:11:19.065
They need some compliance stuff. You know? The the stuff we don't like, but that is necessary.
166
00:11:19.685 --> 00:11:22.345
So they might come, in this case, to us, you know,
167
00:11:22.885 --> 00:11:23.720
because that's
168
00:11:24.120 --> 00:11:29.740
that's what they need to show to the regulators to, like, oh, we're legit. We're running a service that
169
00:11:30.120 --> 00:11:35.125
complies to all the stuff that you need. So at the end of the day, it really depends on the end user. Right? From
170
00:11:35.425 --> 00:11:39.045
for me, from my perspective, obviously, I would want this to be all noncustodial.
171
00:11:39.900 --> 00:11:40.720
But sometimes,
172
00:11:41.180 --> 00:11:42.720
you know, if you're like McDonald's,
173
00:11:43.260 --> 00:11:47.520
they cannot run a noncustodial service today because they don't have an empty up, for instance.
174
00:11:47.834 --> 00:11:54.815
They're in the food business or real estate business, maybe. They're not in the finance business. So it it really depends on where your,
175
00:11:55.120 --> 00:12:06.605
you know, where your goals as a company. Like, do you wanna waste time pursuing that license, or do you just wanna get a quick shortcut and get into the big plugged into the Bitcoin network? So I feel like there's service for everything.
176
00:12:08.105 --> 00:12:12.080
177
00:12:12.480 --> 00:12:18.900
178
00:12:21.225 --> 00:12:22.925
broadly about, like, what is liquidity
179
00:12:23.625 --> 00:12:24.365
on lightning?
180
00:12:24.904 --> 00:12:28.125
181
00:12:30.610 --> 00:12:31.270
182
00:12:31.730 --> 00:12:35.890
183
00:12:37.730 --> 00:12:39.350
So so do you feel like
184
00:12:40.615 --> 00:12:46.475
companies will probably even long term will probably be noncustodial, and then maybe, like, your end users, like, your actual
185
00:12:46.990 --> 00:12:50.930
nonbusiness users are gonna be noncustodial, or do you not see it that way?
186
00:12:51.390 --> 00:12:58.795
187
00:12:59.335 --> 00:13:02.315
to be able for the business to build self serve. Right?
188
00:13:02.775 --> 00:13:12.269
And, ideally, the utopia is like every business runs their own infrastructure. They're in control of their money. I mean but the reality is I don't see that happening very soon.
189
00:13:13.115 --> 00:13:21.214
So, like, 2 weeks, 2 years, 20 years? I wanna give a timeline. That's like asking what's the price of Bitcoin to be here. Well, I was gonna ask that next. You know?
190
00:13:22.020 --> 00:13:22.520
191
00:13:23.300 --> 00:13:25.640
Well, may maybe we jump into the other l,
192
00:13:26.180 --> 00:13:26.760
the liquidity.
193
00:13:27.300 --> 00:13:28.840
194
00:13:29.380 --> 00:13:30.200
195
00:13:30.505 --> 00:13:41.700
196
00:13:42.080 --> 00:13:45.280
that the l and liquidity service provider stands for?
197
00:13:45.920 --> 00:13:47.860
And it kinda goes back to how
198
00:13:48.225 --> 00:13:51.205
the lightning network is set up and what, like,
199
00:13:52.145 --> 00:13:55.045
it's when we're talking about liquidity, we're literally talking about
200
00:13:55.410 --> 00:13:59.030
Bitcoin that's being committed to lightning channels. Right?
201
00:13:59.490 --> 00:14:01.590
And there's kind of this, like, inherent
202
00:14:02.645 --> 00:14:06.985
problem with moving money over Lightning Network, and that is
203
00:14:07.445 --> 00:14:13.770
who and where is that Bitcoin that's been committed to Lightning Channels locked up? Who's got it?
204
00:14:14.150 --> 00:14:27.154
Who's got the ability to use that locked of Bitcoin to pay someone else? Right? This is, like, becomes a kind of complicated problem. Right? There's only so much Bitcoin in the world. We well, what is it? Do we hit 18? Is it 19,000,000?
205
00:14:27.850 --> 00:14:28.350
19,000,000
206
00:14:28.650 --> 00:14:31.790
was the thing? So there's only 19,000,000 Bitcoin.
207
00:14:32.490 --> 00:14:34.670
A lot of that Bitcoin lives in,
208
00:14:35.524 --> 00:14:37.545
cold storage or exchanges
209
00:14:38.805 --> 00:14:50.970
or, you know, people's, like, wallets at home, whatever. And then there's even a smaller part of that, like, ends up getting locked into Lightning Channels. Right? So I think one thing is, like, okay, there's only so much Bitcoin available to be used,
210
00:14:51.589 --> 00:14:55.805
Lightning, etcetera. Okay. So then you've got the amount of Bitcoin that's locked into Lightning channels.
211
00:14:56.985 --> 00:15:02.845
Then in order like, once you're operating on the Lightning Network, your ability to send and receive payments,
212
00:15:03.790 --> 00:15:21.570
sending payments is, like, I wanna say a little bit easier. You can buy some Bitcoin, lock it into a Lightning channel, and then send it. So that's kind of like sending Bitcoin, sending Lightning over Bitcoin to some extent is bring your own stats. Like, you've got some money and you're probably gonna, like, put it in and send it out somewhere else.
213
00:15:22.350 --> 00:15:33.185
The harder problem is receiving money on Lightning. This is this is, like, tends to be and you guys should definitely correct me if I'm wrong. This tends to be kind of the gap. The liquidity service providers,
214
00:15:33.910 --> 00:15:38.090
fill in for that edge network that Ryan is was talking about earlier.
215
00:15:38.550 --> 00:15:39.050
So
216
00:15:39.750 --> 00:15:40.230
the,
217
00:15:40.630 --> 00:15:46.315
the work of figuring out, like, okay. We only have so much Bitcoin locked into channels or, like, as a service
218
00:15:46.855 --> 00:15:50.154
provider. You know? If if someone wants to receive a payment,
219
00:15:50.509 --> 00:15:53.970
the liquidity service provider has to figure out how to get
220
00:15:54.350 --> 00:15:55.730
Bitcoin to them
221
00:15:56.269 --> 00:15:56.769
from
222
00:15:57.635 --> 00:16:04.935
whatever channels etcetera. They've they've got Bitcoin locked into already, etcetera. So we call this So this problem of, like,
223
00:16:05.270 --> 00:16:08.650
getting the ability to receive Bitcoin over Lightning,
224
00:16:09.030 --> 00:16:10.730
we call that inbound liquidity.
225
00:16:11.670 --> 00:16:16.555
Inbound liquidity is, like, kind of a valuable difficult thing to get on Lightning.
226
00:16:17.015 --> 00:16:22.635
Part of the reason for this is you have to convince someone else to make that Bitcoin available to you
227
00:16:22.960 --> 00:16:41.825
before you can receive payments. So LSPs help solve this problem. And, again, please, like, help correct me if I'm wrong here. You guys have a lot more hands on experience with us than I do. But getting LSPs are the the service that provides basically the ability to receive and send, but the receive part is the really difficult part of,
228
00:16:42.240 --> 00:16:43.940
payments over lightning. So,
229
00:16:44.800 --> 00:16:55.535
some of the work that goes into that is, like, okay, where do you have all this Bitcoin available? So, like, if you have Bitcoin available such that you can then pay it out to people. Right? Someone else is gonna pay you on the other end, but,
230
00:16:56.840 --> 00:17:00.460
I think another, like, this is a little bit of a tangent, but sort of similar.
231
00:17:01.320 --> 00:17:06.885
Another thing about Bitcoin liquidity on Lightning is that I would call Lightning a over collateralized
232
00:17:07.345 --> 00:17:10.245
network. If you wanna send a bitcoin from
233
00:17:10.705 --> 00:17:12.805
your node to 3 hops away
234
00:17:13.230 --> 00:17:14.690
because Lightning is routed,
235
00:17:15.230 --> 00:17:16.690
you need 3 Bitcoin
236
00:17:17.389 --> 00:17:20.289
of Bitcoin already locked into Lightning
237
00:17:20.835 --> 00:17:31.260
before you can send 1 bitcoin 3 hops away. So every payment that's made over lightning requires a multiple of bitcoin to already be committed to the lightning network.
238
00:17:32.120 --> 00:17:43.885
So liquidity management and how do you so then so, you know, you kinda step back a little bit. It's okay. Like, we need a lot more Bitcoin on the network in order to make payments work than the actual volume of the payments that are going through the network
239
00:17:44.424 --> 00:17:48.125
currently as it stands. Maybe we'll come up with some really fancy ways to do rehypothecation
240
00:17:51.070 --> 00:17:55.740
241
00:17:56.715 --> 00:17:58.095
So you mean there'll be 22,000,000
242
00:17:58.475 --> 00:17:59.455
Bitcoin? Yeah.
243
00:18:00.075 --> 00:18:07.000
244
00:18:08.100 --> 00:18:16.455
So, like, then, you know, you're doing liquidity. It's like, okay. You're providing liquidity to people. People. Like, how much Bitcoin do you have? How do you attract more people that have Bitcoin that isn't on lightning
245
00:18:16.835 --> 00:18:24.080
to bring their Bitcoin into the lightning network such that we can use it as payment rails to move, you know, value around between people,
246
00:18:24.860 --> 00:18:25.360
etcetera.
247
00:18:25.660 --> 00:18:39.370
248
00:18:39.750 --> 00:18:42.169
how is this challenge being addressed, the inbound liquidity
249
00:18:42.470 --> 00:18:44.745
challenge. You know, and and what what are
250
00:18:45.125 --> 00:18:52.105
what are we doing to, you know, tackle this problem because there's a couple different ways. Right? So So one thing that I think is was really interesting,
251
00:18:53.110 --> 00:18:54.730
252
00:18:55.270 --> 00:18:57.850
finally turned on their node and
253
00:18:58.150 --> 00:19:09.705
got on and joined the Lightning Network, their node, like last I looked, they had like rocketed up to something like number 10 in total capacity on the network. Everyone here is probably guilty of helping that. Not a failure.
254
00:19:10.725 --> 00:19:15.559
But I think what was what's really interesting is like the inbound liquidity problem
255
00:19:15.940 --> 00:19:16.440
is
256
00:19:16.740 --> 00:19:17.240
generally
257
00:19:18.100 --> 00:19:19.080
absolutely agreed
258
00:19:19.565 --> 00:19:31.960
with Lisa that it is like the scarce resource and the hard thing to acquire. But then you have an entity like Kraken where people are like hey, we want them to succeed, we think there's gonna be a ton of fees to be earned by routing payments
259
00:19:32.419 --> 00:19:33.640
to the Kraken node,
260
00:19:33.975 --> 00:19:48.480
like let's allocate a ton of capital to them or they don't even have to pay for it, we'll just kinda like optimistically think that that's where we're gonna earn a return from. It's like it's like if you're so cool and popular, it's like life is easy for you. You know what I mean? I know. I don't know anything about that. That must be nice.
261
00:19:49.875 --> 00:19:54.295
So I think that's been like a really interesting thing, and we've seen that a couple times where
262
00:19:54.675 --> 00:20:11.605
there are like new services that pop up on Lightning and they ask like how can I go and get connected to the network? And we're just still in these early days where kind of the best solution still is like put up the bat signal on Twitter and say like hey, we have a new node, can you please connect to us and the community will generally
263
00:20:11.985 --> 00:20:13.205
open the channels to you.
264
00:20:13.970 --> 00:20:18.950
As it matures and the network gets bigger, I think it's fundamentally, it's a market problem.
265
00:20:19.650 --> 00:20:30.855
As Lisa said, well you're trying to convince somebody to allocate capital to your direction, and like what's the best way to do that? Well, you just pay them. Right? I agree, because right now it's I feel like for
266
00:20:31.220 --> 00:20:39.480
267
00:20:39.805 --> 00:20:43.265
I suddenly have plenty of capital to deploy. You know? And,
268
00:20:43.725 --> 00:20:54.320
I think I think we're kinda past, like, the 2019, 2020, 2021 where we just wanna open up random channels to everyone. We wanna be a little bit more thoughtful on that, so It has it definitely has matured for sure.
269
00:20:54.860 --> 00:21:04.765
270
00:21:05.110 --> 00:21:10.330
271
00:21:10.789 --> 00:21:15.155
272
00:21:15.695 --> 00:21:18.835
onboarding edges and connecting to other nodes
273
00:21:19.215 --> 00:21:23.075
in the network, these are completely 2 separate problems. And and
274
00:21:23.535 --> 00:21:34.355
I don't know if it's easy to send in the Lightning Network right now because in order to send, you need to first receive. And then before you're able to send, you need to receive and and to solve the inbound liquidity
275
00:21:34.655 --> 00:21:35.155
problem.
276
00:21:35.455 --> 00:21:38.915
So I think there are what what's cool about the inbound liquidity,
277
00:21:39.935 --> 00:21:47.559
problem that is it's being solved for end users at least. Like, we want we don't have enough tools to manage liquidity
278
00:21:47.940 --> 00:21:51.960
efficiently currently in the Lightning Network, but at least to onboard users,
279
00:21:52.325 --> 00:21:54.024
there are set of solutions
280
00:21:54.404 --> 00:21:57.465
that, were put into place in order to facilitate
281
00:21:58.245 --> 00:22:01.385
this, out of the box inbound liquidity issue.
282
00:22:01.850 --> 00:22:08.270
One of the solutions is what we're doing at Breeze, opening 0 confirmation channels. So we're actually utilizing
283
00:22:08.835 --> 00:22:12.215
the liquidity of the end user in order to open
284
00:22:12.675 --> 00:22:13.175
liquidity,
285
00:22:13.715 --> 00:22:14.855
to allocate liquidity
286
00:22:15.315 --> 00:22:24.440
to the user end. So we open a channel and we push liquidity, the same liquidity that the user used to top up the wallet. We use it in order to provide
287
00:22:25.435 --> 00:22:27.375
inbound liquidity. That's one solution.
288
00:22:28.795 --> 00:22:33.855
Another solution is pool solution like pool from Lightning Labs is the ability to lease
289
00:22:34.620 --> 00:22:35.120
liquidity
290
00:22:35.740 --> 00:22:36.720
and to open
291
00:22:37.820 --> 00:22:38.480
a channel
292
00:22:38.940 --> 00:22:41.040
which is a list for by default,
293
00:22:41.660 --> 00:22:43.565
a month, 2 weeks, what's the default?
294
00:22:43.865 --> 00:22:49.200
295
00:22:50.000 --> 00:22:51.539
296
00:22:52.799 --> 00:22:59.085
Lisa I think worked on it, it's liquidity ads where nodes can announce that they are willing
297
00:23:00.424 --> 00:23:00.924
to
298
00:23:01.625 --> 00:23:04.765
rent you liquidity for such and such
299
00:23:05.145 --> 00:23:05.645
price.
300
00:23:06.720 --> 00:23:15.139
301
00:23:15.525 --> 00:23:27.309
302
00:23:27.610 --> 00:23:35.035
That means that we are working with other lightning implementations so that, hopefully, it'll be supported by every node on the Lightning Network.
303
00:23:35.815 --> 00:23:37.735
It's basically act a way to
304
00:23:38.615 --> 00:23:40.930
I call it like a billboard system of advertising
305
00:23:41.309 --> 00:23:44.050
that you've got liquidity that you're looking to deploy.
306
00:23:44.910 --> 00:23:53.784
This billboard ad that you can put up, you can put in, like, how much you're looking to get for the capital that you have available. So you set your own rate of how much that your
307
00:23:54.245 --> 00:23:59.320
available capital is worth to you, and you can set that. You put it into a little advertisement.
308
00:23:59.940 --> 00:24:06.420
Those advertisements go into something in lightning we call the gossip network, which every node on the network sends and receives.
309
00:24:07.140 --> 00:24:11.955
So so you can advertise. You put a little bit of information, this little kind of, like, classified ad
310
00:24:12.255 --> 00:24:26.534
called liquidity ads into your gossip goes out to every node on the network. So if you're running a node right now, you're currently getting all the liquidity ad data. It's on your node. Whether or not your node exposes that to you is a different question, but if you're on core lightning, you can see them.
311
00:24:27.015 --> 00:24:29.434
They're also available to see on lnrouter.app,
312
00:24:31.015 --> 00:24:35.419
which is like a little there's a little dashboard. You can go look at all the liquidity ads that are currently available.
313
00:24:35.879 --> 00:24:50.925
Anyway, so this is the way you advertise, like, hey. I've got some capital. I'd like to deploy it. Here's how much I want you to pay for me. And then you can if you're trying to buy or get inbound liquidity, you can go look at all the nodes that are offering liquidity, where they are on the network, whether it's worth, what they're offering to you or not, and then
314
00:24:51.305 --> 00:24:55.600
decide whether or not to take them up on their ads. So it's a it's super decentralized.
315
00:24:55.900 --> 00:25:10.525
I have no information for you. It's been out for maybe, like, 7 months now. I have no information for you about how many people have used it, or how much capital has been allocated using that market because that data only exists between the buyer and seller.
316
00:25:11.140 --> 00:25:15.400
You can go look at I think the number of ads is, like, we're close to, like, 15, 20 these days.
317
00:25:15.780 --> 00:25:17.320
So it's, like, small but growing.
318
00:25:18.100 --> 00:25:29.549
319
00:25:30.649 --> 00:25:31.149
liquidity
320
00:25:31.690 --> 00:25:40.325
industry, the leasing channel market? What what do you what is it like now? What was it before? What's what's it gonna become? Maybe you can talk a little bit about that since you're familiar. Sure.
321
00:25:40.885 --> 00:25:41.385
322
00:25:41.765 --> 00:25:43.850
what it was previously was, like,
323
00:25:44.169 --> 00:25:45.150
before we had,
324
00:25:45.690 --> 00:25:54.785
you know, channel leases as like a formal kind of financial product on lightning, it was all handshake agreements between, you know, people on the stage, right, saying like, hey
325
00:25:55.405 --> 00:25:59.985
message you on Telegram, hey can you please open 1 Bitcoin channel to me, like we're expecting
326
00:26:00.285 --> 00:26:03.030
a lot of volume this weekend or something like that. Right?
327
00:26:03.410 --> 00:26:08.150
That obviously doesn't scale if we think flight in network is gonna be tens to hundreds of thousands
328
00:26:08.610 --> 00:26:09.350
of nodes,
329
00:26:10.050 --> 00:26:10.550
businesses
330
00:26:11.485 --> 00:26:18.545
being able to interact. So turning that kind of interaction into more of a market interaction saying, you know, I will pay you
331
00:26:18.880 --> 00:26:23.059
x amount or x percent of the capital that you, commit to me,
332
00:26:23.600 --> 00:26:30.655
as long as you keep that channel open for say a 3 month period. Right, and I think the cool thing that that both pool and,
333
00:26:31.515 --> 00:26:38.070
the liquidity edge construction does is that that lease term is actually secured by Bitcoin script. Right. So if the channel is opened,
334
00:26:38.850 --> 00:26:42.790
it actually, you know, those funds can't be decommitted from that channel.
335
00:26:43.170 --> 00:26:48.745
Bitcoin itself will not allow that channel to be closed until the duration is up, which I think is a really cool construction.
336
00:26:49.205 --> 00:26:50.745
337
00:26:51.365 --> 00:26:55.385
use, like, something like pool or like a commit or whatever to get, like, inbound liquidity,
338
00:26:55.710 --> 00:27:07.475
or I can just start an exchange and get really popular and get a bunch of users, and they get free inbound liquidity. Yeah. Or just, like, a bunch of Twitter users and just say, hey. I need inbound liquidity. Or we can or we can download reason. Or we can
339
00:27:08.595 --> 00:27:12.434
340
00:27:12.995 --> 00:27:13.495
is,
341
00:27:15.290 --> 00:27:16.030
we've seen
342
00:27:17.130 --> 00:27:19.150
in pool, the lease rates are public.
343
00:27:20.170 --> 00:27:28.475
If you're running a node you can download all the data and read through all the history. And so we've seen over the last like couple months or this year that like
344
00:27:28.990 --> 00:27:34.210
demand is starting to is like really starting to pick up, rates are starting to get, like, pretty sustainably high,
345
00:27:34.670 --> 00:27:40.674
which means that there is now, like, you know, well maybe in the early days there was an overabundance of supply,
346
00:27:41.535 --> 00:27:58.525
like demand is starting to kind of pick up and push prices up, which should in theory then induce kind of more supply coming on the network. Because if you can earn, you know, 6% annualized on your Bitcoin for opening a channel to a node that wants it, like, that's a pretty good deal. Or you can trust all your money with, like, a custodial
347
00:27:59.305 --> 00:28:06.760
348
00:28:07.220 --> 00:28:18.195
this might be the only thing I can think of that's, like, noncustodial, actually, like, providing a service where you can get a little bit of income on your Bitcoin potentially. Right? Absolutely. And, like, you know And that's key. We need to break a myth here. Like, there's a misconception
349
00:28:19.135 --> 00:28:20.995
350
00:28:21.320 --> 00:28:25.019
Yes. And and in order for Lightning to be successful,
351
00:28:26.039 --> 00:28:28.539
the the routing fees need to go higher
352
00:28:29.185 --> 00:28:30.725
and and lightning needs
353
00:28:31.345 --> 00:28:33.525
basically, the the entire thing about liquidity
354
00:28:34.065 --> 00:28:44.149
is is why would people allocate liquidity to going back to what Lisa said, like what's the reason that people will put their liquidity in lightning? They want to generate yield, right?
355
00:28:44.575 --> 00:28:46.434
So if people put liquidity
356
00:28:46.735 --> 00:28:47.235
in
357
00:28:47.535 --> 00:28:56.990
lightning and they they are able to generate yield, then people will put more liquidity in lightning. So there there's a circle here of like traffic
358
00:28:57.690 --> 00:28:58.590
brings liquidity,
359
00:28:59.245 --> 00:29:09.400
liquidity provides yield, yield provides more traffic, traffic provides more liquidity. So we need to start thinking about lightning as an economical tool,
360
00:29:10.500 --> 00:29:11.000
and
361
00:29:11.460 --> 00:29:16.280
lightning, like long term, if we all want Bitcoin and lightning to be successful,
362
00:29:16.934 --> 00:29:19.755
it can't be as cheap as it is now.
363
00:29:20.774 --> 00:29:21.335
364
00:29:21.894 --> 00:29:26.080
Can you scoot forward just a little bit? What's that? Just scoot forward a little bit. I need to tell
365
00:29:26.780 --> 00:29:27.840
you. These guys
366
00:29:28.620 --> 00:29:29.360
think, like,
367
00:29:29.660 --> 00:29:39.475
noncustodial lightning will scale, and I just wanna talk, like, real between you between Zebi and OpenNode right now about how, like, Lightning will actually work in the future. Actually, we've, full story about liquidity.
368
00:29:39.855 --> 00:29:45.870
369
00:29:46.250 --> 00:29:50.270
And we're doing is they actually are connecting to us saying, yo,
370
00:29:50.645 --> 00:30:07.680
we need to connect for launching our product. That's to some private channels because they don't want to announce first their node on network because they don't wanna get attacked like the OS. Mhmm. And then so we're doing we actually sign contracts, like legal contracts about channels, which is smart contracts, dumb real contracts? Contracts. Yeah.
371
00:30:08.035 --> 00:30:09.095
Like, real contracts.
372
00:30:09.715 --> 00:30:15.975
So it's it's a it's a trend, we're seeing. Like, we're actually, like, signing contracts about opening channels to these service providers.
373
00:30:16.770 --> 00:30:22.549
374
00:30:22.850 --> 00:30:32.255
375
00:30:32.895 --> 00:30:33.875
last week. So
376
00:30:34.470 --> 00:30:35.370
Visa, Mastercard
377
00:30:35.830 --> 00:30:42.784
kind of average rates that they charge for domestic payments is like and you would know this better than me probably is you know, 1.29%
378
00:30:43.645 --> 00:30:44.625
plus 5.5¢,
379
00:30:46.044 --> 00:30:46.945
for per payment.
380
00:30:47.565 --> 00:30:52.580
I looked at, like, the top five biggest nodes on the Lightning Network, and it just so happens
381
00:30:53.039 --> 00:30:54.580
that the average fee rate,
382
00:30:55.039 --> 00:30:58.019
across those 5 nodes is, like, exactly
383
00:30:58.320 --> 00:30:58.820
90%
384
00:30:59.205 --> 00:31:05.144
of that. So it's it's the the 10 x difference. It was, like, 13 depths or something Okay. Which I think is just, like, a very interesting
385
00:31:05.765 --> 00:31:10.030
way that, you know, this this free market decentralized ecosystem has kind of coalesced,
386
00:31:10.890 --> 00:31:14.669
at a rate that is, you know, typical venture capital wisdom
387
00:31:15.125 --> 00:31:31.149
is, you know, in order for something to, you know, a new network to disrupt the incumbent, it has to be 10x better Yeah. In fees. And so I thought that was just interesting that that is kind of where the rates are right now. And it's happened it it happens very naturally because fees are your only 2 currently within the Lightning Network
388
00:31:31.450 --> 00:31:34.705
389
00:31:35.804 --> 00:31:37.585
to be. Like if I want
390
00:31:38.044 --> 00:31:40.625
the liquidity to flow from one end to another,
391
00:31:41.485 --> 00:31:42.465
I need to have
392
00:31:42.909 --> 00:31:43.809
lower fees.
393
00:31:44.590 --> 00:31:49.250
And if I wanted the liquidity to flow in the other way from B to A,
394
00:31:50.110 --> 00:31:54.015
if I don't want the liquidity to flow from B to A, I need to set high fees.
395
00:31:54.475 --> 00:31:54.975
So
396
00:31:56.555 --> 00:31:59.135
it's it's it's it's basically represent, like, the opportunity
397
00:31:59.435 --> 00:32:00.370
cost of
398
00:32:00.850 --> 00:32:02.309
of the liquidity. So
399
00:32:02.850 --> 00:32:04.550
and fees are the only way to control
400
00:32:05.010 --> 00:32:05.830
the the how
401
00:32:06.210 --> 00:32:11.975
402
00:32:12.595 --> 00:32:27.955
I talk about how the channels are like roads and your fees are like your traffic lights. Okay. Right? Where it's like if you if you don't want traffic to flow down this way, you gotta hike the rate, which is like turning the light red. And if you want traffic to flow, you lower lower the rate and make the light green,
403
00:32:28.515 --> 00:32:30.855
which I think is accurate. Yeah. Yeah.
404
00:32:31.955 --> 00:32:32.755
405
00:32:33.715 --> 00:32:37.409
I love that analogy. Really good. Yeah. He runs red lights. Yeah.
406
00:32:37.870 --> 00:32:43.250
Better better than my beads on a string analogy. Well, you know, but we it takes all kinds. Yeah.
407
00:32:45.424 --> 00:32:50.085
I I I did wanna talk a little bit I wanna I wanna involve this this gentleman right here
408
00:32:50.785 --> 00:32:55.820
and and say, what are what do you think the challenges are? You know, we we talked a bit about noncustodial
409
00:32:56.440 --> 00:32:58.620
liquidity, lightning service provider challenges.
410
00:32:59.720 --> 00:33:09.120
Although it doesn't fit Roy's definition to a t, the we can maybe caveat it with the non, you know, custodial Lightning providers. What what do you think the challenges are
411
00:33:09.920 --> 00:33:21.445
412
00:33:23.185 --> 00:33:30.970
You know, and once you're holding Bitcoin from someone's else, there is compliance risks. There is all certain of legal stuff that you have to
413
00:33:31.270 --> 00:33:34.010
to go through, especially if your company is in the United States.
414
00:33:34.825 --> 00:33:38.125
That's why a lot of people do not make their company in the United States.
415
00:33:40.025 --> 00:33:43.645
But I would say the biggest challenge is definitely the the user onboarding
416
00:33:44.140 --> 00:33:44.640
today.
417
00:33:44.940 --> 00:33:47.840
Obviously, Kustodil makes it easier. It makes it simple.
418
00:33:48.780 --> 00:33:54.295
Is it the the solution? I don't think so it is. I think you're you guys are doing a really good job on that.
419
00:33:55.715 --> 00:34:04.610
But so far, we're still in a transition period. Right? And if you want to involve certain parties in this economy, we need to make tools that are,
420
00:34:05.150 --> 00:34:05.650
you
421
00:34:06.750 --> 00:34:07.650
know, somehow,
422
00:34:08.350 --> 00:34:09.730
easy enough for them.
423
00:34:10.395 --> 00:34:16.494
And it's a transition period. I would say, obviously, long term, the idea is to everything to make a trustless system
424
00:34:17.275 --> 00:34:17.775
noncustodial.
425
00:34:18.650 --> 00:34:20.809
But right now, we still have to go through this
426
00:34:21.289 --> 00:34:24.270
Transition phase. Transition phase. Like, people still need the dollars.
427
00:34:24.809 --> 00:34:25.390
You know?
428
00:34:25.885 --> 00:34:27.425
429
00:34:27.885 --> 00:34:29.745
cold wallet kind of concern
430
00:34:30.525 --> 00:34:31.905
that concern you?
431
00:34:32.580 --> 00:34:36.840
That's what I was saying. It's about the risk When you look just explain the others that when you lock liquidity
432
00:34:37.300 --> 00:34:40.440
in lightning, it's being locked in a hot wallet currently.
433
00:34:41.045 --> 00:34:51.280
434
00:34:51.660 --> 00:34:53.360
While when you're doing cold storage,
435
00:34:54.220 --> 00:34:57.815
you know, the Bitcoin, your your secret, your c, your password,
436
00:34:58.435 --> 00:34:59.335
it was never,
437
00:34:59.635 --> 00:35:04.295
like, interactive maybe with a computer. So there is no way for anyone to know that password.
438
00:35:04.610 --> 00:35:06.790
And so when you're locking up funds in Lightning,
439
00:35:07.490 --> 00:35:08.790
those funds are somehow
440
00:35:09.970 --> 00:35:12.390
exposed, or there is a there is a chance,
441
00:35:13.455 --> 00:35:18.595
that, eventually, they might get stolen or not, depending on security practices. Right?
442
00:35:18.975 --> 00:35:25.530
And but I think we're coming up with tools like the remote signing, you know, things that are improving. You know,
443
00:35:27.109 --> 00:35:32.165
the the the software is is going through another phase now where, like, okay, Things are being pretty,
444
00:35:32.485 --> 00:35:35.625
risky now. Let's let's decouple the stuff
445
00:35:35.925 --> 00:35:39.225
and try to make the signing stuff like a cold storage offline,
446
00:35:39.980 --> 00:35:46.319
where you like because you every time you do a transaction aligning, you have to update the channel. And to update the channel, you need to sign a transaction.
447
00:35:46.755 --> 00:35:49.975
So, eventually, that software needs to have access to to the signer.
448
00:35:50.275 --> 00:36:02.260
The problem here is the signer. Right? You don't want to expose that entity to the outs to the Internet because then you have a threat. If you expose your password or you're not exposing your password, but there is
449
00:36:02.960 --> 00:36:05.220
there is a way that eventually someone,
450
00:36:05.785 --> 00:36:14.985
if they know enough about you, might be able to get that password. And when you do cold storage, that information is not accessible anywhere. But with the remote signing tools, I think we're,
451
00:36:16.050 --> 00:36:22.310
we're getting there. Yeah. We're getting there. Not there yet, but we'll get there. We're getting there. On the Hot Wallet risk, one
452
00:36:22.664 --> 00:36:23.665
453
00:36:24.105 --> 00:36:31.484
we have a service liquidity service we provide called Loop, not to be confused with pool. Just you spell it backwards. You spell it backwards. Yeah. Something.
454
00:36:31.790 --> 00:36:37.310
And so Loop is, a submarine swap provider where it's a it's a bridge between on chain Bitcoin and off chain Bitcoin,
455
00:36:38.589 --> 00:36:41.575
where if you if you need more inbound liquidity, you
456
00:36:42.055 --> 00:36:45.355
send funds to Lightning Labs, and then in a noncustodial way,
457
00:36:45.815 --> 00:36:50.155
we return the funds to you on chain. One interesting use case for that,
458
00:36:50.609 --> 00:37:07.244
more so than just needing to acquire invalid liquidity is actually risk management. Mhmm. Right? If you wanna make sure that the amount of capital that you have on your node stays low that's on your side of the channels. One thing that we're seeing a lot of folks do is just continually make sure to loop out to send funds
459
00:37:08.160 --> 00:37:15.940
out of out of their custody and return it back to their on chain wallet, which I think is an interesting thing that, you know, as the network has grown,
460
00:37:16.454 --> 00:37:27.540
has become something yeah. Like, you know, all of a sudden, certain providers say, man, we have, like, a 100 Bitcoin in this node. Like, we gotta be careful. We gotta, like Start looping out. Start start looping out and start using some risk management practices, which I think is very interesting.
461
00:37:28.160 --> 00:37:31.060
462
00:37:31.360 --> 00:37:37.115
remote signing and the what in in terms of the future of LSPs and and things to look forward to,
463
00:37:37.495 --> 00:37:39.995
what kinda like, I know we have
464
00:37:40.615 --> 00:37:41.435
Nifty here,
465
00:37:41.895 --> 00:37:43.115
Blockchain. We have
466
00:37:43.430 --> 00:37:43.930
Ryan,
467
00:37:44.470 --> 00:37:47.450
Lightning Labs that are working on implementations of Lightning,
468
00:37:48.230 --> 00:38:00.005
that kinda help enable some of these things. What what what can what can I'll tell you from a user, like, from a He's gonna tell you what he needs, and then you'll have to call it. Yeah. Exactly. The guy that's running an LSP,
469
00:38:00.310 --> 00:38:00.970
470
00:38:01.270 --> 00:38:02.890
better control of my liquidity.
471
00:38:03.270 --> 00:38:04.410
I need better flexibility
472
00:38:04.790 --> 00:38:07.610
to manage my liquidity. So I think in that regard,
473
00:38:07.990 --> 00:38:09.370
I'm looking forward to splicing.
474
00:38:09.815 --> 00:38:12.875
The ability splicing is the ability to change the capacity
475
00:38:13.175 --> 00:38:14.474
of the channel dynamically
476
00:38:14.855 --> 00:38:16.234
without closing the channel.
477
00:38:16.535 --> 00:38:26.039
And, basically, if you let's say, I'll give you a very simple use case. Let's say we have a user. The user is is using Breeze to get inbound liquidity.
478
00:38:26.525 --> 00:38:27.345
So we open
479
00:38:27.885 --> 00:38:39.090
a one BTC channel to the end user. The the Bitcoin are on the user side. The user used the entire BTC to to pay for stuff. And now I I got one BTC
480
00:38:39.390 --> 00:38:46.695
locked in the channel on my end of the channel. And the user stopped using Breeze for some reason. I don't know why it's a great product, but
481
00:38:47.235 --> 00:38:47.735
but
482
00:38:48.115 --> 00:38:53.849
they stopped they stopped using Breeze, and now I got liquidity locked on my end of the channel as an LSP.
483
00:38:54.150 --> 00:38:59.210
And I need to reallocate this liquidity because I want to onboard new user using this
484
00:38:59.695 --> 00:39:04.115
BTC or I want to put this liquidity somewhere else where it generate
485
00:39:04.495 --> 00:39:08.035
a much better yield than than the user that doesn't use
486
00:39:08.415 --> 00:39:15.940
Prism anymore. So in order to take this liquidity out of the channel, I need a way to splice out, I need a way to dynamically
487
00:39:16.400 --> 00:39:18.740
configure the channel to have a lower capacity
488
00:39:19.125 --> 00:39:21.385
so I'll be able to reallocate this liquidity
489
00:39:21.845 --> 00:39:22.744
someplace else.
490
00:39:23.125 --> 00:39:31.140
491
00:39:32.079 --> 00:39:39.955
492
00:39:41.215 --> 00:39:47.700
lends itself real easily to making splicing happen. So we are actively working on making splicing happen.
493
00:39:48.720 --> 00:39:51.140
Hopefully, that will come out at some point.
494
00:39:52.095 --> 00:39:56.915
In 2 weeks? 2 weeks. Yeah. 2 weeks. So look for it in 2 weeks. We're great. Yeah.
495
00:39:57.295 --> 00:40:06.590
So, yeah, we hear this. And I'm like, man, it's so much fun to think through all the ways that splicing lets you do wild stuff with your channels when you get it going.
496
00:40:07.690 --> 00:40:14.285
Yeah. The way that we wrote, like, some of the so the precursor stuff we had to do before we get liquidity ads is this thing that,
497
00:40:14.905 --> 00:40:19.545
calling collaborative channel opens. It used to be called dual funding, but that got a little,
498
00:40:20.810 --> 00:40:21.790
let's see, the namespace
499
00:40:22.090 --> 00:40:25.530
collision started happening so we're calling it collaborative channel opens now.
500
00:40:26.010 --> 00:40:32.035
Anyways, so all that work that we did to make that happen, you can use cool stuff where you can splice across multiple channels on the same transaction
501
00:40:32.655 --> 00:40:33.714
with multiple peers,
502
00:40:34.415 --> 00:40:35.714
on Lightning, decentralized,
503
00:40:36.015 --> 00:40:38.849
it's like cool stuff. So we're hoping to bring that to splicing
504
00:40:39.150 --> 00:40:39.809
real soon.
505
00:40:40.349 --> 00:40:42.049
506
00:40:43.390 --> 00:40:43.890
Brian?
507
00:40:44.269 --> 00:40:44.769
Yeah.
508
00:40:46.029 --> 00:40:47.170
509
00:40:47.855 --> 00:40:52.835
One is like another another side of this and as an infrastructure guy, I imagine you have thoughts on this.
510
00:40:54.015 --> 00:41:03.690
One really funny thing that happened like a year ago, as I remember talking with a bunch of lightning companies about kind of like what they what they wanted from l and d,
511
00:41:04.365 --> 00:41:05.665
in the year 2021.
512
00:41:06.525 --> 00:41:15.430
And it was the first time that instead of it being, you know, new features and and new techniques and and new cool bells and whistles, it was, you know, can we have,
513
00:41:16.290 --> 00:41:22.925
accounting software? Yeah. Can we have, you know, like, a more scalable database? Right? It's like very, like, adult requests instead.
514
00:41:23.464 --> 00:41:30.340
And so I think that's like the other lens of this is running the infrastructure and and scaling like your back end and, you know, like the post stuff,
515
00:41:31.200 --> 00:41:33.845
that we're working on, that kind of making sure that,
516
00:41:34.405 --> 00:41:39.545
just your nodes stay online, that they're, you know, easy to manage, that you have all the data that you need,
517
00:41:39.845 --> 00:41:46.910
as well, like, you know, data that you need for reporting requirements and, you know, accounting stuff, like, all of those kind of boring,
518
00:41:47.529 --> 00:41:53.535
tools as well as something that, you know, is is increasingly more in demand as lightning companies get bigger, succeed, raise money,
519
00:41:54.075 --> 00:41:57.830
520
00:41:58.790 --> 00:41:59.290
So
521
00:41:59.670 --> 00:42:01.290
522
00:42:01.910 --> 00:42:03.430
523
00:42:03.830 --> 00:42:06.970
Maybe this is something that anyone can talk about. Does
524
00:42:07.475 --> 00:42:08.935
Bolt 12 or Taproot
525
00:42:09.475 --> 00:42:14.615
affect LSPs? And if so, what way what what does what's better? Because I know, like, for instance,
526
00:42:14.920 --> 00:42:19.579
LMD is a little bit more or sorry. Not LLD. Lightning Labs is a little bit more focused on,
527
00:42:19.960 --> 00:42:20.940
supporting Taproot.
528
00:42:21.559 --> 00:42:22.059
And
529
00:42:23.414 --> 00:42:28.055
and I was just curious. Maybe we can talk about that a little bit. How in in in its relation to,
530
00:42:29.414 --> 00:42:31.170
providing service like LSP?
531
00:42:32.190 --> 00:42:35.310
532
00:42:36.270 --> 00:42:40.984
just opens up, like, a a brand of much bigger design space for what can be done,
533
00:42:41.605 --> 00:42:55.795
on lightning. I think it it enables a lot more use cases just kinda upgrading the channel commitment types and and things like that to supporting Taproot. It just it it it's more of like kind of like a a platform upgrade, so to speak, the to think of. Right? And I think,
534
00:42:56.255 --> 00:43:00.755
you know, that's kind of like a little bit of a of a longer term thing where you can think of, you know,
535
00:43:01.300 --> 00:43:06.360
for instance, I know one thing that that roast beef is working on, is the concept of dynamic commitments
536
00:43:06.740 --> 00:43:09.320
where, like, right now if you wanted to upgrade a channel,
537
00:43:10.045 --> 00:43:19.185
that's a a a normal, you know, pre Taproot channel, you would need to close the channel and then reopen a new Taproot one and spend to a new Taproot output.
538
00:43:19.720 --> 00:43:32.305
You know, working on a proposal to be able to allow that to happen. If you think about that at scale, right, there's something like 80,000 channels on the network right now, public channels, like 80,000 bitcoin transactions closing channels and then reopening would be like pretty heavy.
539
00:43:32.685 --> 00:43:37.710
But with dynamic commitments being able to do that kind of on the fly and upgrading your commitment output,
540
00:43:38.109 --> 00:43:46.355
without changing the channel is is, you know, a cool thing that then allows for, you know, wacky things like, you know, our proposal yesterday,
541
00:43:46.895 --> 00:43:49.795
Taro, which which leverages it will be Taproot Channels,
542
00:43:50.175 --> 00:43:52.915
where you can send, you know, assets that aren't Bitcoin,
543
00:43:53.530 --> 00:43:57.950
you know, say, you know, a a Fiat backed stablecoin or something like that, you could send those
544
00:43:58.410 --> 00:43:59.550
over the lightning network.
545
00:43:59.930 --> 00:44:13.060
546
00:44:13.760 --> 00:44:14.260
Bitcoinized.
547
00:44:14.720 --> 00:44:19.244
Bitcoinizing the dollar. Yeah, exactly. That's the meme. So we need more Bitcoin
548
00:44:19.625 --> 00:44:22.285
collateral in order to facilitate new assets
549
00:44:22.744 --> 00:44:27.050
that will increase the demand of having more liquidity in the Lightning Network.
550
00:44:27.690 --> 00:44:28.190
551
00:44:29.690 --> 00:44:31.930
Nifi or John, did did you wanna chime in on
552
00:44:32.650 --> 00:44:50.340
553
00:44:50.800 --> 00:44:52.480
So I think that's a big win. With,
554
00:44:53.585 --> 00:44:54.484
555
00:44:55.105 --> 00:45:03.125
we're gonna talk about privacy more on Friday. I'm doing a privacy panel. We'll get way into that. I'm gonna push back and say that just upgrading the Taproot
556
00:45:03.730 --> 00:45:07.970
outputs isn't actually gonna solve the privacy problem. It's
557
00:45:08.610 --> 00:45:11.990
I think the biggest thing is moving to blinded routes in bolt 12.
558
00:45:13.015 --> 00:45:22.950
Right now, no one cares about on chain footprint. If you're handing them an invoice, it tells you where the payment's going, what you're paying for, how much it's for. Like, you don't even have to look at the chain if you give someone an invoice.
559
00:45:23.329 --> 00:45:23.829
Like,
560
00:45:24.690 --> 00:45:27.270
so I think Taproot's cool. I think, like,
561
00:45:27.855 --> 00:45:29.955
lightning's gonna get to Taproot soon.
562
00:45:31.055 --> 00:45:39.760
Upgrading it, doing dynamic commitments is, like, an awesome thing. Miners might not like it so much, as the people running the channels, but, you know, that's fine.
563
00:45:40.859 --> 00:45:44.515
But yeah. Anyways, like, Taproot's cool. It's coming.
564
00:45:44.915 --> 00:45:46.535
Really excited about the,
565
00:45:47.075 --> 00:45:52.710
novel engineering that Labs is doing with Taproot stuff, and excited to see how that goes. But
566
00:45:53.990 --> 00:46:02.570
567
00:46:03.005 --> 00:46:10.225
Oh, okay. Well, let's rephrase the question real quick. Instead of doing closing thoughts, let's just do lnurl versus ball 12. Let's get into it.
568
00:46:12.260 --> 00:46:20.265
569
00:46:20.585 --> 00:46:23.085
So I know lining at Lightning Labs is a position.
570
00:46:23.865 --> 00:46:26.525
See, lining has the the other position. So I'm
571
00:46:26.984 --> 00:46:30.045
just curious to hear both your thoughts about why
572
00:46:30.410 --> 00:46:36.350
you want to invest in Bold 12 and why you don't want to invest in Bold 12 right now. Just curious. I'm the moderator now.
573
00:46:40.735 --> 00:46:44.435
574
00:46:44.895 --> 00:46:47.855
on this, and I think he stated it well. It's like we're,
575
00:46:48.750 --> 00:46:53.170
you know, a small team. We have something like 26 people. There's there's only so many engineers,
576
00:46:53.870 --> 00:46:55.490
and, like, the priority is
577
00:46:55.790 --> 00:46:58.565
is doing Taproot stuff. And I think in particular
578
00:46:59.265 --> 00:47:01.365
one thing that we've talked a lot about
579
00:47:01.744 --> 00:47:02.244
is
580
00:47:03.664 --> 00:47:14.240
responding to the developers in particular that are building on our stuff. And we haven't had a bunch of developers beating down our door saying, this is wrong, we need you to focus on Vault 12 instead,
581
00:47:14.565 --> 00:47:16.665
Right? Because they're kinda happy with lnurl.
582
00:47:17.365 --> 00:47:21.940
Right? And I you know, like, it's it's it's bad business to tell your customers that they're wrong.
583
00:47:22.579 --> 00:47:31.855
And so that's you know, we're we're focused on Taproot, and I think that's that's gonna it. I think I don't I don't and I I wanna be clear. Like, I don't think we think whole 12 is necessarily
584
00:47:32.395 --> 00:47:37.055
a bad proposal. I think blinded routes are great. I think the static invoice is great.
585
00:47:37.995 --> 00:47:42.450
There's a bunch of good stuff in there. It's just not the priority for this quarter.
586
00:47:43.870 --> 00:47:46.530
587
00:47:47.365 --> 00:47:49.065
will facilitate payments between
588
00:47:49.365 --> 00:47:53.945
peers in the network without the need to have an HTTP web server.
589
00:47:55.280 --> 00:47:57.380
And Allen URL is great for
590
00:47:57.920 --> 00:48:07.444
for custodial services that has that have online presence, and it's great for merchants that have web presence. So whenever you have a web server,
591
00:48:07.744 --> 00:48:12.039
you can definitely build on ln, ln URL, but it doesn't solve
592
00:48:12.339 --> 00:48:14.680
the problem of the the ability
593
00:48:15.299 --> 00:48:18.839
to send payments to other user in the network without
594
00:48:19.214 --> 00:48:22.434
creating an invoice first. And for that, we need bolt well.
595
00:48:23.454 --> 00:48:24.994
596
00:48:25.375 --> 00:48:36.935
generate an invoice, Right? For both of them. Like, you have the static part, but you still need to go and actually fetch You need a pointer you need a pointer to to begin with, but the pointer doesn't need to be, like,
597
00:48:37.555 --> 00:48:51.760
598
00:48:52.060 --> 00:48:52.560
AMP
599
00:48:53.244 --> 00:48:58.065
600
00:48:58.605 --> 00:49:08.530
invoice fetching with both 12. Right? Like, you still do need to, like, get a secret to pay whereas with amp it's actually static like there is no interaction required you can just pay to a
601
00:49:09.835 --> 00:49:13.454
602
00:49:14.315 --> 00:49:17.775
603
00:49:18.315 --> 00:49:21.559
because I I I love this. And and and, you know, I feel like,
604
00:49:22.900 --> 00:49:27.720
we we we should have a bolt 12, l and euro pay kind of discussion, maybe. Fight.
605
00:49:28.225 --> 00:49:35.765
We need we need fiat, Jeff. We we we need yeah. We need we should like, WWE people start sliding in, bringing in chairs and stuff. But
606
00:49:36.380 --> 00:49:39.920
I we're we're out of time. I wanna I just wanna give everyone
607
00:49:40.380 --> 00:49:45.519
a few seconds just to do, like, a closing. How do people know about you if you wanna show your Twitter, if you wanna
608
00:49:46.015 --> 00:49:48.755
let people know how to follow you, whatever it might be?
609
00:49:49.055 --> 00:49:52.994
610
00:49:53.359 --> 00:49:57.380
You can find me, Zhuang Almeida. It's a hard name, so you're not gonna find it.
611
00:49:58.320 --> 00:49:59.859
Yeah. You can find me on Twitter.
612
00:50:01.904 --> 00:50:03.684
613
00:50:04.065 --> 00:50:06.244
f t y n e I, if you wanna,
614
00:50:06.785 --> 00:50:07.845
follow my Twitter.
615
00:50:09.020 --> 00:50:11.680
I also work with core lightning. So core_ln
616
00:50:12.780 --> 00:50:15.440
is our lightning node implementation. I work at Blockstream
617
00:50:15.740 --> 00:50:17.599
who obviously is also on Twitter.
618
00:50:18.895 --> 00:50:23.635
619
00:50:24.895 --> 00:50:25.395
Breeze.technology.
620
00:50:26.335 --> 00:50:28.119
That's our website. You
621
00:50:28.579 --> 00:50:30.280
can join our Telegram group,
622
00:50:31.859 --> 00:50:32.359
Breeze.
623
00:50:32.819 --> 00:50:35.799
624
00:50:36.135 --> 00:50:37.675
625
00:50:37.975 --> 00:50:39.595
626
00:50:40.135 --> 00:50:42.155
Ryan the Gentry on Twitter.
627
00:50:43.015 --> 00:50:44.075
Follow us on
628
00:50:44.530 --> 00:50:46.150
on Twitter as well at at lightning,
629
00:50:46.850 --> 00:50:48.790
and the website is lightning dot engineering.
630
00:50:49.890 --> 00:50:51.250
Thank you, Michael, for,
631
00:50:51.755 --> 00:50:55.454
632
00:50:55.914 --> 00:50:59.855
633
00:51:00.359 --> 00:51:00.759
And,
634
00:51:01.160 --> 00:51:01.660
I'm
635
00:51:02.200 --> 00:51:13.335
not that popular, but for some reason, they have tons of scammers. I'm not giving away free Bitcoin. And when when when's the Tapcom? The next Tabconf? If you well, not to shill too much because we're at a conference, but,
636
00:51:13.975 --> 00:51:19.359
Tabconf is a technical focused conference in Atlanta, Georgia. It's gonna be in October. Tabconf, tabconf.com.
637
00:51:22.140 --> 00:51:25.119
Yeah. Thanks for helping me show that, I guess. Yeah. Just go on.
638
00:51:27.075 --> 00:51:29.575
Yeah. Oh, alright. Thank you, everybody. Thanks for coming.
639
00:51:35.970 --> 00:51:36.470
640
00:51:38.050 --> 00:51:44.230
So this is the future of lightning development panel. Sadly, we lost our our illustrious moderator,
641
00:51:45.005 --> 00:51:51.184
who couldn't make it to Miami in time. So instead, I get to moderate these these two lovely folks.
642
00:51:52.390 --> 00:51:55.450
So why don't we start with Hannah and we can do quick intros
643
00:51:55.830 --> 00:52:05.025
644
00:52:05.885 --> 00:52:11.540
say, in the Bitcoin space a while and obsessed with Lightning since it came out. So delighted to be here talking about it.
645
00:52:12.320 --> 00:52:14.260
646
00:52:14.880 --> 00:52:18.445
been in this space for a long long long
647
00:52:18.905 --> 00:52:20.525
time, 20, 2009.
648
00:52:21.465 --> 00:52:27.005
And my hobby became my job. So now I'm working for Blockstream on for Lightning.
649
00:52:28.090 --> 00:52:29.150
650
00:52:29.850 --> 00:52:33.390
Sadly, Christian predates me a little bit, but I did get into Bitcoin in in 2011.
651
00:52:34.090 --> 00:52:35.390
I have the the illustrious
652
00:52:35.785 --> 00:52:39.165
claim to fame of I actually wrote the 1st payments channel implementation
653
00:52:39.945 --> 00:52:45.160
anywhere long before lightning and before we had routing or or in fact bidirectional payment channels.
654
00:52:45.540 --> 00:52:52.523
And I don't think anyone ever used it. But that's okay. Oh, that's good. You're you're the only one. We had a student project working on it. So
655
00:52:52.927 --> 00:53:00.200
656
00:53:01.160 --> 00:53:02.619
657
00:53:03.240 --> 00:53:05.020
talk very briefly about,
658
00:53:05.400 --> 00:53:09.900
kind of the history of lightning and how how it's grown, and then we're gonna get into
659
00:53:10.345 --> 00:53:11.725
how we see it maturing
660
00:53:12.025 --> 00:53:12.925
and and
661
00:53:13.705 --> 00:53:14.605
going from there.
662
00:53:15.065 --> 00:53:20.770
So I don't know if who wants to start with Hannah, you can start with that one. This one. This I think the past year
663
00:53:21.150 --> 00:53:23.490
664
00:53:23.869 --> 00:53:30.065
last year and until now, like, just watching the explosion in lightning. And it's been really interesting to me
665
00:53:30.444 --> 00:53:35.980
to watch lightning progress from, you know, just a proof of concept where everyone was like, is this even going to work?
666
00:53:36.280 --> 00:53:38.859
To, you know, then being very much in the hobbyist
667
00:53:39.480 --> 00:53:40.619
enthusiast territory,
668
00:53:40.920 --> 00:53:52.230
you know, where you're on the command line and, you know, only people that are, you know, nerdy enough to be on the command line can use it. So then we get much more user friendly stuff going on. And then now it's moved from
669
00:53:52.770 --> 00:53:53.270
hobbyists
670
00:53:53.570 --> 00:54:05.860
more into, you know, businesses really attempting to use this in their products and services and just spend this huge explosion, and and it's been really amazing to watch and to think about where it might go from here.
671
00:54:07.780 --> 00:54:08.280
672
00:54:09.380 --> 00:54:19.825
I would I would go further and say, like, yeah, it it's specializing. Right? So it it's it's gone from hobbyist, but they still exist. They're still there. They're still running running ClubNet and it's still routing a lot of payments.
673
00:54:20.365 --> 00:54:22.385
And we have so I I now work for
674
00:54:22.839 --> 00:54:28.460
for, I guess, Block is now our name, not on Cash App, but but, you know, Cash App now it's deployed
675
00:54:28.839 --> 00:54:29.660
deployed lightning,
676
00:54:29.960 --> 00:54:38.325
and that's that's a whole different world. And we just had the LSP panel and the mobile lightning world and the the LSPs also need a whole different set of things.
677
00:54:39.480 --> 00:54:43.820
So let's let's kinda split up the future of lightning development by those categories
678
00:54:44.120 --> 00:54:46.060
and then kinda dive in from there.
679
00:54:47.435 --> 00:54:49.775
So let's let's start with mobile. So,
680
00:54:50.555 --> 00:55:01.329
you know, we just had a bunch of discussion about LSPs and what they need, but maybe let's look more towards the future and talk about, you know, what what do these mobile clients themselves need. Yeah.
681
00:55:02.485 --> 00:55:03.465
682
00:55:04.485 --> 00:55:06.505
LDK is a fabulous
683
00:55:07.045 --> 00:55:11.970
tool for mobile. That's really cool. And we're also talking about the problems,
684
00:55:12.990 --> 00:55:14.530
with mobile payments,
685
00:55:15.150 --> 00:55:25.695
enlightening, sort of sort of an app having to be on, you know, to receive a payment, which is a big issue at the moment. And then just trying to shove a lightning node
686
00:55:26.430 --> 00:55:29.650
into a mobile application is certainly quite a challenge.
687
00:55:30.510 --> 00:55:31.410
But that's why
688
00:55:31.710 --> 00:55:55.255
you know all the time you know it's like sorry I'm just gonna go off on this tangent, but it's like I love that, you know, I've spent so much time being obsessed with lightning and it's only been in the past year that when people come up to me and ask me, hey, Hannah, can you do x y and z on Lightning? I don't have to tell them theoretically, yes. I can tell them, yes, you can, and here's the library you should use to do that. And so that's been a really amazing change in the past year. But there's still
689
00:55:55.795 --> 00:55:56.695
this big issue,
690
00:55:57.155 --> 00:56:24.890
with with mobile payments that I don't know if any want to dive into that a little bit. But essentially, I think one of the problems there is just getting an app to, you know, because you have to be online to have payments. And one of the issues there is just how do you get that app to be online to receive payments? How do you solve that problem? And then shoving a note into a mobile application is not a problem. Yeah. Yeah. I I think we do see a lot of experimentation going on especially now, with regards to how do we want to integrate lightning into
691
00:56:25.224 --> 00:56:27.964
692
00:56:29.224 --> 00:56:38.359
And, the experimentation we're seeing right now is, is going in direction of do we want to really want to shove a full node into, into a mobile app,
693
00:56:38.819 --> 00:56:39.880
potentially segmenting
694
00:56:40.180 --> 00:56:47.145
your funds across a multitude of app, basically locking in, the users into an individual app so making it hard to experiment.
695
00:56:48.085 --> 00:56:50.825
Or do we want to have a more centralized node
696
00:56:51.285 --> 00:57:02.945
that is still operated and run by you and where we just remote into it and, and I think those those are the trade offs we are currently seeing explored and we will see, how these work out in the future.
697
00:57:03.565 --> 00:57:22.244
698
00:57:22.865 --> 00:57:25.025
So having having better logic there and then,
699
00:57:26.610 --> 00:57:37.775
enabling more you know, we've kind of seen this this first generation of mobile wallets that all kind of have this simple, you know, we took a lightning node or at least a payment channel and we put it in an app,
700
00:57:38.475 --> 00:57:42.415
and we shipped it and it works pretty well and we have this LSP and we wrote out payments through it and whatever.
701
00:57:42.875 --> 00:57:51.190
But, you know, we haven't gone down the route of, like, okay, well, what if we have, like, a server assist more server assisted lightning node, like,
702
00:57:51.515 --> 00:57:54.575
green light and like some of the other things core lightning is working on,
703
00:57:54.875 --> 00:57:56.575
and what it you know, do we have,
704
00:57:57.435 --> 00:57:58.895
better protocols for,
705
00:57:59.549 --> 00:58:00.770
papering over this,
706
00:58:01.150 --> 00:58:07.965
on chain requirement? Right? So I I had that proposal, whatever, 6 months ago, and we're still long ways from implementing it
707
00:58:08.685 --> 00:58:12.305
to do use onion messages as a base for doing,
708
00:58:14.285 --> 00:58:15.425
on doing payments
709
00:58:15.740 --> 00:58:19.440
such that you can kind of hide the fact that the nodes have to be online
710
00:58:19.820 --> 00:58:21.440
synchronously to receive the payment.
711
00:58:22.060 --> 00:58:24.080
And and you can actually do
712
00:58:24.914 --> 00:58:35.410
offline kind of payments, but, like, you know, it goes out and it sits pending, and then, you can actually receive it without it sitting pending across an entire route across the lightning network, and holding that capacity
713
00:58:35.869 --> 00:58:39.569
for, you know, potentially hours or days until the user opens their phone.
714
00:58:40.575 --> 00:58:47.635
So there's still, you know, we we finally have lightning on on phones, but we still have a lot to go to actually
715
00:58:48.089 --> 00:58:51.150
fix a lot of these UX issues that we've run into.
716
00:58:52.730 --> 00:58:57.230
717
00:58:57.735 --> 00:59:00.795
like in production in real services but just barely.
718
00:59:01.575 --> 00:59:06.850
719
00:59:07.970 --> 00:59:12.150
and I'm speaking for all implementations here of course not just just core lightning.
720
00:59:12.930 --> 00:59:13.430
That
721
00:59:14.215 --> 00:59:17.995
where we are learning from the experience of operating lightning nodes
722
00:59:18.375 --> 00:59:18.695
of,
723
00:59:19.255 --> 00:59:19.915
of basically
724
00:59:20.295 --> 00:59:24.880
providing users with the ability to to make more of their lightning nodes
725
00:59:25.340 --> 00:59:25.840
and
726
00:59:26.300 --> 00:59:29.440
this experience will flow back into the spec process as well
727
00:59:31.195 --> 00:59:34.735
and inform where the directions are going to go in the future.
728
00:59:35.595 --> 00:59:36.495
729
00:59:38.890 --> 00:59:44.190
it is going to continue to be interesting, you know, as the the amount of resources required
730
00:59:44.650 --> 00:59:46.430
to kind of maintain a lightning node
731
00:59:47.515 --> 00:59:56.970
will only continue to grow as we have multiple different completely divergent use cases for lightning. We have, you know, whether it's people trying to run it in enterprise
732
00:59:57.430 --> 01:00:19.670
and who want, you know, features that might help them, people trying to run it on mobile. And then you want to add onion messages and, like, onion message mailboxes so that you can do, you know, be offline all the time. All of a sudden you have all of these new features coming in that all the lightning implementations are at least kind of mostly need to support or at least look at it and and add chunks of it so that things can be interoperable.
733
01:00:21.250 --> 01:00:25.875
Just the the amount of resources required to maintain a lightning node is only gonna continue to increase.
734
01:00:26.655 --> 01:00:27.694
It's already whatever
735
01:00:28.255 --> 01:00:36.079
I think all the major implementations have at least 3 or 4 engineers full time on it, and that presumably will only continue to grow.
736
01:00:36.405 --> 01:00:41.385
737
01:00:42.165 --> 01:00:58.325
but I do think that, by us basically, as as Lightning implementations, concentrating on a common kernel that sort of builds the basis for all of the applications that we build on top. And I've been often asked what what sort of is the coolest thing you can imagine doing with lightning, and I usually
738
01:00:58.705 --> 01:01:05.180
say that I'm not the right one to ask. I'm I'm I'm the kernel guy. I'm not I'm not the cool fancy UI guy. So,
739
01:01:06.119 --> 01:01:12.825
but I think that, that keeping that kernel small will help us basically provide a basis for for whatever comes next
740
01:01:13.125 --> 01:01:13.785
and whatever
741
01:01:14.405 --> 01:01:16.345
maybe these guys will build here.
742
01:01:16.799 --> 01:01:17.299
743
01:01:17.760 --> 01:01:25.380
744
01:01:25.955 --> 01:01:26.855
but but what
745
01:01:27.955 --> 01:01:29.895
features in the lightning protocol
746
01:01:30.355 --> 01:01:31.175
might be needed,
747
01:01:31.875 --> 01:01:32.375
for
748
01:01:32.700 --> 01:01:36.000
looking towards LSPs and but the future of development
749
01:01:36.620 --> 01:01:37.120
that
750
01:01:37.420 --> 01:01:40.080
we have to do on a lower level might be needed for
751
01:01:40.445 --> 01:01:40.945
those
752
01:01:41.245 --> 01:01:43.825
services in the, over the next few years?
753
01:01:44.605 --> 01:01:47.185
754
01:01:47.885 --> 01:01:49.105
is already started
755
01:01:49.610 --> 01:02:01.225
with with the liquidity ads, which is, which is a way for you to signal the availability of funds and the, and the readiness of of allocating those funds to a, to a channel that you'd
756
01:02:01.625 --> 01:02:03.165
that somebody would like to open.
757
01:02:03.839 --> 01:02:06.099
And I think that is sort of the direction that
758
01:02:06.400 --> 01:02:08.420
I would like to see things going forward
759
01:02:08.720 --> 01:02:12.180
where we have an open marketplace where everybody can participate,
760
01:02:12.515 --> 01:02:13.815
where there is no mediator,
761
01:02:14.675 --> 01:02:16.135
where we can
762
01:02:16.515 --> 01:02:18.615
just exchange our interest in
763
01:02:18.915 --> 01:02:21.495
opening or closing channels and what
764
01:02:22.230 --> 01:02:24.809
the set of costs are for for that.
765
01:02:25.270 --> 01:02:26.410
766
01:02:26.789 --> 01:02:29.289
LSPs a little bit even further. Right? From,
767
01:02:29.885 --> 01:02:33.105
from from service providers who might be providing service to,
768
01:02:34.205 --> 01:02:52.135
hobbyist nodes or plug in nodes or always online nodes versus service providers who might be providing services to to mobile where, you know, some people might expect to use your experience where your client accepts the 0 cons thing. Right? Where suddenly you you need to actually know who your counterparty is. You can't just, you know, go to a liquidity ad and and select whoever.
769
01:02:52.515 --> 01:03:03.330
770
01:03:04.385 --> 01:03:12.165
Having an identity attached to a liquidity add is something that you can use to basically make a decision of hey is this provider
771
01:03:12.640 --> 01:03:17.200
well connected in the network? Do I do I trust him to be a good,
772
01:03:17.599 --> 01:03:19.220
good counterparty for my channel?
773
01:03:20.455 --> 01:03:21.835
And that is
774
01:03:22.455 --> 01:03:28.315
basically just an additional information that we have to convey to whoever might take you up on the offer.
775
01:03:29.360 --> 01:03:33.380
So I don't think that different protocols here are in the solution.
776
01:03:35.360 --> 01:03:37.860
777
01:03:40.335 --> 01:03:43.955
it is ultimately up to the people building the user experiences, building the apps,
778
01:03:44.655 --> 01:03:46.970
what kind of UX they want there.
779
01:03:47.590 --> 01:03:48.730
Obviously, exposing
780
01:03:49.750 --> 01:03:50.250
different
781
01:03:50.630 --> 01:03:54.890
possible trust relationships to users tends to be a pretty poor user experience.
782
01:03:55.734 --> 01:04:00.214
Like, hey, you can pick between these nodes, and here's some information about whether you should trust them.
783
01:04:00.695 --> 01:04:08.069
You know, PGP Web of Trust kind of failed for a reason. PGP is great, but the Web of Trust part never went anywhere. Well, you know, the average user,
784
01:04:08.369 --> 01:04:27.750
785
01:04:28.385 --> 01:04:29.925
you know, things they care about,
786
01:04:30.225 --> 01:04:45.390
in get gathering liquidity. And why do we need the liquidity? Is this a business that's accepting incoming payments? Is it a routing node? Like, what's the use case? So it's just things are getting just bigger and bigger. So it's, you know, now we get little pockets and different use cases here and there. Yeah. And, I mean, I think
787
01:04:45.885 --> 01:04:50.625
788
01:04:50.925 --> 01:05:16.350
is a proliferation of more different lightning apps and different lightning user experiences. And I think Yeah. You know, certainly that's that's kind of our pitch. Right? I mean, speaking from the LDK end, it's kind of our pitch of, like, look, we're gonna, like, do all the hard parts for you, and then you focus on how do you want to build a user experience around lightning? How do you want to, you know, do you wanna have 0Conf with which nodes? And do you want to use liquidity ads? And do you want to use this or that and whatever?
789
01:05:18.010 --> 01:05:23.875
And so, you know, maybe I'm a little biased, but like I'm looking forward to a world where we have, like, you know, some
790
01:05:24.255 --> 01:05:26.835
apps and some desktop clients, or
791
01:05:27.380 --> 01:05:32.359
browser extensions or mobile clients or whatever that use greenlight, and some of them that that
792
01:05:32.660 --> 01:05:44.305
let you choose which node to connect to and expose this whole, like, market place of liquidity ads, and some that, like, abstract a lot of that away, and then some that, like, just always connect to the predetermined LSP or whatever. Right.
793
01:05:44.684 --> 01:05:46.065
And kind of this this
794
01:05:47.310 --> 01:05:56.295
Cambrian explosion, I hope, is coming eventually, where we can have a lot of different options, and we can kind of see what succeeds in the marketplace while all still having,
795
01:05:56.835 --> 01:05:57.494
you know,
796
01:05:57.954 --> 01:06:19.525
this common base of, you know, one of these lightning implementations that's robust and tested and and has implements a lot of these features so that users can pick and choose kind of which ones they want. Kind of developers can pick and choose which ones they want. And the more tools that are out there, you know, the better to fit different use cases and all of this stuff. And it's yeah. I I also foresee sort of this explosion where I just
797
01:06:19.980 --> 01:06:29.775
798
01:06:30.555 --> 01:06:31.695
streaming things,
799
01:06:32.315 --> 01:06:32.815
authenticating,
800
01:06:33.595 --> 01:06:34.975
for services, etcetera.
801
01:06:35.470 --> 01:06:36.670
802
01:06:37.150 --> 01:06:43.970
So so I definitely do share your your sentiment that, that we sort of will have a common core that we can pick and choose from.
803
01:06:44.845 --> 01:06:46.385
With Greenlight, we chose to
804
01:06:46.845 --> 01:06:52.625
take a bit of a different cut, where you guys are doing API level composition, basically.
805
01:06:53.570 --> 01:06:57.110
The thing that, that we want to do is basically provide a core node,
806
01:06:57.890 --> 01:06:58.790
hence the name,
807
01:07:00.265 --> 01:07:06.365
and, and allow users to, basically, then connect to it and, and experiment with different use cases.
808
01:07:07.224 --> 01:07:10.910
So we are going back to, basically, this topic of special, specialization
809
01:07:11.290 --> 01:07:11.790
where,
810
01:07:12.090 --> 01:07:24.095
where we as the lightning developers are sort of in charge of, of operating lightning node, the stuff that we do best, and freeing developers from actually having to even learn all of the intricacies
811
01:07:24.474 --> 01:07:24.795
of,
812
01:07:25.275 --> 01:07:26.015
of building
813
01:07:26.474 --> 01:07:29.055
both a beautiful UI and UX
814
01:07:29.560 --> 01:07:33.820
and managing a lightning node that has has to be bundled with with your app. So,
815
01:07:34.360 --> 01:07:39.100
and hopefully by by basically removing this this need to bundle
816
01:07:39.464 --> 01:07:44.984
a lightning node with your app, you're also freeing the user to basically experiment and jump from 1,
817
01:07:45.545 --> 01:07:47.565
front end application to another one
818
01:07:47.910 --> 01:07:53.130
And, whereas if you bundle the node with with the, with the app itself,
819
01:07:53.990 --> 01:07:57.565
trying out a new app means setting up a full, you know, so
820
01:07:58.205 --> 01:07:59.425
821
01:07:59.885 --> 01:08:24.030
always that that kinda highlights that debate that's been around forever in the lightning world of, like, do you have, you know where do you put the the node? Right? Do you have kind of the, I would say, the earliest designs and the earliest focus was kind of you everyone would host their own node at home on our Raspberry Pi, and everyone would give kind of part partial remote control access to that node to every app or whatever via, you know, this
822
01:08:24.889 --> 01:08:26.989
this the LND has the macro and system and
823
01:08:27.449 --> 01:08:31.389
and Corelightning has some similar stuff. Now you can do it over onion messages too.
824
01:08:33.175 --> 01:08:44.579
And you have kind of that world, and then you have this kind of movement towards well, you know, people actually seem to really like this UX of having a a node or at least having payment channels locally in in Moon or Breeze
825
01:08:44.880 --> 01:08:45.699
or or Phoenix,
826
01:08:46.559 --> 01:08:48.179
or maybe there's a few others.
827
01:08:49.405 --> 01:08:50.065
And then,
828
01:08:50.365 --> 01:08:52.305
kind of, maybe moving back,
829
01:08:52.685 --> 01:09:01.140
like, kind of the the core lightning, the the green light design's a little bit in between. Right? It's, hosted, but some of the signing is local, so there's less trust in the server.
830
01:09:01.600 --> 01:09:07.219
Or, you know, you keep it all hosted locally and do it. So I think,
831
01:09:07.824 --> 01:09:09.764
you know, as much as there's
832
01:09:10.945 --> 01:09:21.929
value in there being a standard and everyone doing the same thing, I think we're just gonna see different experiment. We're different we're gonna see different things. We're gonna see people use green light, and that's gonna be great. And then we're gonna see people who continue to have the the
833
01:09:22.230 --> 01:09:26.250
channels on the phone, and that's gonna be great for for those. And so, you know Well,
834
01:09:26.605 --> 01:09:43.290
835
01:09:43.665 --> 01:09:47.844
and the signer and the front end on on a different device. Maybe some, some other combination
836
01:09:48.145 --> 01:09:55.080
makes more sense. Yep. And, and we're just starting to see how these deployment strategies can work out.
837
01:09:55.460 --> 01:09:55.860
And,
838
01:09:56.260 --> 01:10:02.680
I'm very much looking forward to to seeing how all of this works out. Yeah. So we spent a little time talking about
839
01:10:03.275 --> 01:10:05.375
840
01:10:05.915 --> 01:10:09.615
LSPs and getting into this kind of mobile and and server assisted model.
841
01:10:10.235 --> 01:10:18.320
Let's let's switch gears and talk a little bit about, like, what future designs and what future things have to come for the kind of enthusiasts to plug that nodes,
842
01:10:19.100 --> 01:10:20.560
this world. You know, what
843
01:10:20.865 --> 01:10:27.685
what what do we need to add to make that even better experience, and and where does that world go in the next year or 3?
844
01:10:28.040 --> 01:10:30.540
845
01:10:31.000 --> 01:10:49.460
especially, I think, because they're just enthusiasts that, like, test things out for us. You know? Like, they're just trying all the things, and then they report back. You know? You yeah. Go in the, Telegram groups, you know, and see what people are having trouble with, and it it's fabulous. You know, to have this group of enthusiasts that test things out. I think there's a lot of tools,
846
01:10:50.080 --> 01:10:51.060
you know, for,
847
01:10:51.680 --> 01:10:52.260
you know,
848
01:10:53.235 --> 01:10:58.455
for those enthusiasts, you know, things like Umbrel and, you know, my note and all those sorts of things.
849
01:10:58.755 --> 01:11:00.215
And I think a lot of them,
850
01:11:00.835 --> 01:11:01.330
wants
851
01:11:01.730 --> 01:11:03.430
to, you know, they get to sort of
852
01:11:03.810 --> 01:11:07.590
build with lightning. Right? And so when you make things that are really reliable,
853
01:11:08.130 --> 01:11:09.350
that they can just reliably
854
01:11:09.890 --> 01:11:20.600
use this to run their node or to manage their node and have these tools for liquidity. And then they get to experiment with building things on top of that. And that's really, really valuable, I think, to have that constant experimentation and testing
855
01:11:20.980 --> 01:11:21.720
in the space.
856
01:11:22.740 --> 01:11:30.315
857
01:11:31.815 --> 01:11:35.994
to really have an objective measure on, on what works and what doesn't.
858
01:11:36.620 --> 01:11:46.364
For the longest time we have, we have heard that rebalancings work, rebalancings don't work. How do how much do you spend on rebalancing? Should we make rebalancing free?
859
01:11:47.065 --> 01:11:49.485
How much privacy do we leak with that?
860
01:11:50.264 --> 01:11:54.780
Do we even care about leaking some privacy if it's not our own payments?
861
01:11:55.480 --> 01:11:58.680
Or do we use rebalancings to provide cover,
862
01:11:59.080 --> 01:12:00.995
traffic for really private,
863
01:12:01.455 --> 01:12:01.955
transfers?
864
01:12:02.495 --> 01:12:03.935
So all of these kinds of,
865
01:12:04.335 --> 01:12:04.575
of,
866
01:12:05.615 --> 01:12:08.355
details, that we want to surface to the user,
867
01:12:08.940 --> 01:12:16.400
to help them make an informed decision about whether something is for them or not is something that we definitely need to work on and
868
01:12:16.700 --> 01:12:18.000
make available to users
869
01:12:18.795 --> 01:12:21.054
in the future to help them
870
01:12:21.435 --> 01:12:22.975
make their own experiments, basically.
871
01:12:24.315 --> 01:12:36.115
872
01:12:38.335 --> 01:12:40.035
So let's let's talk.
873
01:12:40.430 --> 01:12:47.650
We have a ton of time left, but let's talk really briefly about enterprise, and then we'll see if we can talk a little bit about spec in the future too.
874
01:12:48.190 --> 01:12:49.490
So what what do we
875
01:12:49.950 --> 01:12:50.255
you
876
01:12:51.935 --> 01:12:56.835
you know, I we have a little bit of experience on the Cash App side, but, you know, what what do we need for enterprises,
877
01:12:57.375 --> 01:13:01.960
you know, as we just saw Kraken launch, Cash App only launched whatever a few months ago.
878
01:13:02.420 --> 01:13:19.080
879
01:13:19.460 --> 01:13:20.679
that, you know,
880
01:13:21.300 --> 01:13:40.655
need a really reliable service. Like, okay. We wanna use lightning. We need something really reliable, and, you know, we are expecting this volume or that, and we need it to be scalable. And then just like, you know, the amount of times I've had to explain to why you can't use Amazon Web Services horizontal scaling on, like, a lightning node. You know? Like, these sorts of things. Or you just I think
881
01:13:41.215 --> 01:13:42.514
scaling that infrastructure,
882
01:13:43.454 --> 01:13:50.890
for some of these use cases is gonna be something that'll be important in the next year or 2 as, you know, bigger businesses take this on.
883
01:13:51.610 --> 01:14:03.344
And then just, you know, reliability. You know, if you're tinkering with something and it works 90% of the time, you know, that's that's awesome. If you're a business and it only works 90% of the time, that's a big problem. So I think, you know, reliability and scalability
884
01:14:03.965 --> 01:14:10.210
are big things for for businesses that are trying to take on lightning. Yeah. Absolutely. I mean, one of the,
885
01:14:11.389 --> 01:14:19.635
886
01:14:20.255 --> 01:14:21.455
And, Val,
887
01:14:22.015 --> 01:14:25.060
recently published a a system that very much looks like it.
888
01:14:25.540 --> 01:14:33.960
Where you have where you have a set of boundary nodes and a virtual node behind it. And that that is definitely something that, that we are looking into because
889
01:14:34.925 --> 01:14:36.465
this reliability and availability
890
01:14:37.725 --> 01:14:54.195
is paramount for for big businesses. Imagine that if Amazon was unreachable 1% of the time. Right. All the money they would lose by just not being able to process payments. For a 100th of a percent of a time, they would still have Yeah. A huge problem. And and and this kind of this kind of innovation,
891
01:14:54.735 --> 01:15:00.160
is is is something that, that that we definitely need to look into, and we've come a long way.
892
01:15:00.620 --> 01:15:03.360
We we've very early on had a failover.
893
01:15:04.620 --> 01:15:08.875
A clear hat, had an implementation of failover that, that could take,
894
01:15:09.255 --> 01:15:11.515
30 seconds to recover if I'm not mistaken,
895
01:15:12.935 --> 01:15:15.515
which is good. I mean, 30 seconds,
896
01:15:16.150 --> 01:15:17.830
that's that's quite good. We,
897
01:15:18.870 --> 01:15:19.750
we can now,
898
01:15:20.470 --> 01:15:22.730
basically reduce that to a couple of seconds,
899
01:15:23.405 --> 01:15:23.905
failover.
900
01:15:24.284 --> 01:15:26.224
And with high availability setups,
901
01:15:26.925 --> 01:15:29.585
we can ensure that no single payment gets lost,
902
01:15:30.045 --> 01:15:33.890
because if any particular node is offline at the time,
903
01:15:34.510 --> 01:15:45.075
the sender will basically retry through a different route. And as long as any of these is online, then then you can you can still process payments. And that also gives you operational flexibility,
904
01:15:45.935 --> 01:15:48.035
because it means that you can basically just
905
01:15:48.495 --> 01:15:53.179
restart a node or upgrade a node and, and if, and do operational,
906
01:15:53.719 --> 01:15:57.739
management of of the node while still being, being overall available.
907
01:15:58.199 --> 01:16:19.155
908
01:16:19.535 --> 01:16:38.065
pitch them, really. We'd explain what what LEK was, and they came to us, and they said, hey. We're actually we wanna use this. We have a ton of you know, Cash App's a little unique. It's a lot of Bitcoin exchanges are more kind of standard infrastructure, and they're set up to run a lot of daemons and interact via RPC. Cash App's not. They're a big company with, you know,
909
01:16:38.525 --> 01:16:43.390
separate services for everything already in place that they already use for all of their existing
910
01:16:43.770 --> 01:16:44.270
web
911
01:16:44.570 --> 01:16:45.630
and and whatever services.
912
01:16:46.810 --> 01:16:50.925
And so they came to us and they said, you know, we want to use Total Decay with this, we think it makes sense.
913
01:16:52.284 --> 01:16:52.784
And
914
01:16:54.125 --> 01:16:57.344
so they ended up building a lot of that stuff using their existing
915
01:16:58.469 --> 01:17:03.210
platform. Right? So they already had high availability stuff and failover and all that kind of stuff. So they built
916
01:17:03.590 --> 01:17:07.475
a Lightning node custom with LDK doing kind of all all the
917
01:17:07.775 --> 01:17:19.219
Lightning specific stuff into their infrastructure and as a part a core part of their infrastructure instead of kind of having a daemon they talk to. And so then we have like the hand availability stuff that that we've
918
01:17:19.920 --> 01:17:22.260
shipped that they've looked at testing.
919
01:17:22.560 --> 01:17:33.365
It turns out once you start adding too many route hints in the the QR code just blow up and it it so we need we need bolt 12. We need the the onion messages so that we can request an invoice or
920
01:17:34.060 --> 01:17:38.000
because it doesn't really you get too big an invoice for a QR code
921
01:17:38.780 --> 01:17:43.360
or or l and URL. I guess both work in this in a kind of server assistant setup,
922
01:17:43.955 --> 01:17:44.455
But,
923
01:17:45.155 --> 01:17:47.095
yeah. So that's that's something that
924
01:17:47.475 --> 01:17:52.860
we didn't anticipate, but turns out LDKs works fairly well for them or at least they're pretty happy with it.
925
01:17:53.560 --> 01:17:54.060
So
926
01:17:56.040 --> 01:17:56.540
927
01:17:57.320 --> 01:18:01.395
928
01:18:01.855 --> 01:18:06.835
But it's going up. Yeah. It's not 11:30 yet. So I think we can keep going for a minute. Let's let's
929
01:18:07.450 --> 01:18:11.550
take another minute and talk about, the future of kind of the spec process,
930
01:18:12.890 --> 01:18:22.335
the the bolts process. You know, we talked a little bit about kind of having a common core and these things that that all the lightning node nodes implement, and then having users kind of experiment
931
01:18:22.635 --> 01:18:25.790
using those different kind of building blocks that exist within lightning.
932
01:18:27.770 --> 01:18:31.630
How does that fit into the future of how, kind of, the bolts evolve,
933
01:18:32.090 --> 01:18:34.190
and then there's now this new blip process
934
01:18:34.785 --> 01:18:36.565
to standardize some of these extensions.
935
01:18:37.425 --> 01:18:41.205
How do we see that process evolving over the next few years?
936
01:18:42.640 --> 01:18:57.045
937
01:18:57.409 --> 01:18:59.110
gets, be very important.
938
01:18:59.489 --> 01:19:00.949
939
01:19:01.330 --> 01:19:02.550
already we've already seen
940
01:19:03.010 --> 01:19:09.325
issue, you know, things getting exposed to users where it's like, well, you you wanna receive a payment. Okay. Now you have to pick,
941
01:19:09.705 --> 01:19:29.135
and you have to negotiate with the sender. Do you wanna receive Onchain? Do you wanna receive Lightning? And now there's, you know, some apps have added. You can you can pick lnurl, and then you can pick bolt 12, and, like, the user has to know these things, and they have to select the one that the sender can send, And like so, you know, that this there's there's a certain value to to standardization,
942
01:19:29.515 --> 01:19:32.735
but then kind of how do we balance that with
943
01:19:33.300 --> 01:19:39.960
experimentation and letting people run wild and and, you know, we don't know what the answer should be. So how do we balance
944
01:19:40.565 --> 01:19:43.705
having a standard that people can rely on with
945
01:19:44.245 --> 01:19:49.940
enabling people to experiment and try new things so that we can find a solution that works better in the market. Yeah.
946
01:19:50.320 --> 01:19:55.540
947
01:20:05.120 --> 01:20:07.540
for from the for the lightning specification.
948
01:20:08.080 --> 01:20:11.060
I remember when we first met in Milan 2016,
949
01:20:11.895 --> 01:20:15.835
we all had different implementations. We all were experimenting on different, things,
950
01:20:16.135 --> 01:20:22.300
and we basically sat down and hammered out all of the different, different trade offs and came to what now is,
951
01:20:22.700 --> 01:20:24.240
is is the bold process
952
01:20:24.700 --> 01:20:28.060
and, the set of documents that we have for the bold process. And,
953
01:20:28.780 --> 01:20:55.655
954
01:20:56.390 --> 01:21:01.930
955
01:21:03.985 --> 01:21:06.645
956
01:21:06.945 --> 01:21:07.445
957
01:21:08.065 --> 01:21:14.840
958
01:21:15.540 --> 01:21:16.260
ways to,
959
01:21:16.740 --> 01:21:41.105
to achieve the same thing, we are, we are now sort of seeing what, what this will eventually, look like. And from these learnings, we can then go back to the table and basically say, okay, this is the way we are going to do do it because of these trade offs that we've learned, while experimenting with And and and what so, I mean, obviously, the the big debate is that the invoice format and payment formats and payment protocols,
960
01:21:42.284 --> 01:21:46.625
961
01:21:49.570 --> 01:21:59.555
962
01:21:59.875 --> 01:22:00.375
over
963
01:22:00.755 --> 01:22:05.255
over the l n URL stack of, protocols is definitely something,
964
01:22:05.555 --> 01:22:07.175
to be to be looked at here.
965
01:22:08.099 --> 01:22:14.435
We are looking at replacing the gossip protocol. We were just talking about, this before that we have this gossip protocol that
966
01:22:14.835 --> 01:22:15.575
grew organically,
967
01:22:16.115 --> 01:22:17.575
for the last couple of years
968
01:22:18.595 --> 01:22:19.255
and has
969
01:22:19.795 --> 01:22:21.575
has shown its age by now
970
01:22:22.920 --> 01:22:27.500
with several different implementations sort of interpreting it slightly differently as well.
971
01:22:28.200 --> 01:22:31.340
And so it's time for us now to basically go
972
01:22:31.720 --> 01:22:38.845
and try to find a new protocol that sort of encompasses all of the good and leaves all of the bad behind.
973
01:22:40.185 --> 01:22:40.685
So
974
01:22:41.540 --> 01:22:45.480
975
01:22:46.020 --> 01:22:54.725
976
01:22:55.105 --> 01:23:00.250
977
01:23:01.590 --> 01:23:04.835
so, yeah, thank you, guys. Alright. Thank you. Thank you.
978
01:23:08.915 --> 01:23:14.775
979
01:23:15.780 --> 01:23:16.280
cryptographers
980
01:23:16.739 --> 01:23:19.000
or people that work on signature libraries
981
01:23:19.540 --> 01:23:23.545
and, you know, they're kind of unsung heroes when things go right
982
01:23:24.025 --> 01:23:25.485
and if things go wrong,
983
01:23:25.945 --> 01:23:27.725
they end up like Sony completely,
984
01:23:28.265 --> 01:23:28.765
pwned.
985
01:23:29.785 --> 01:23:33.020
So I'd like to first, like, get started
986
01:23:33.400 --> 01:23:41.100
in what is a signature? How does it work? Like, you know, are we are we using DocuSign here in Bitcoin Core? Like, what's going on?
987
01:23:42.265 --> 01:23:46.125
How do signatures work, Pionis? Like, what are the functions? What's needed?
988
01:23:47.375 --> 01:23:52.830
989
01:23:53.210 --> 01:23:53.950
the spend
990
01:23:54.410 --> 01:23:59.065
of a coin such that the person who received the Bitcoin,
991
01:24:00.005 --> 01:24:03.545
can spend the coin and no one else. And
992
01:24:03.845 --> 01:24:04.345
this
993
01:24:05.560 --> 01:24:09.820
idea that no one else can spend the coin we call that, unforgeability.
994
01:24:10.440 --> 01:24:12.380
So we say the signature scheme,
995
01:24:12.840 --> 01:24:14.485
is not forgeable and,
996
01:24:15.105 --> 01:24:16.485
that means no one
997
01:24:16.785 --> 01:24:22.005
except the person with a secret key belonging to a public key can
998
01:24:24.350 --> 01:24:31.090
create a signature over a certain message, and in the case of Bitcoin the message is usually some
999
01:24:32.074 --> 01:24:34.094
variant of a transaction hash.
1000
01:24:34.715 --> 01:24:36.415
1001
01:24:37.435 --> 01:24:40.495
how has that maybe changed? You know, we recently activated
1002
01:24:40.875 --> 01:24:41.375
Taproot.
1003
01:24:42.060 --> 01:24:43.920
There's a bunch of new interesting
1004
01:24:45.260 --> 01:24:45.760
signature
1005
01:24:46.540 --> 01:24:47.040
interactivity
1006
01:24:47.420 --> 01:24:51.485
stuff I'll like to get into eventually. But what's the difference between ECDSA
1007
01:24:51.945 --> 01:24:52.845
and Schnorr?
1008
01:24:54.025 --> 01:24:58.365
And can you briefly touch on anyone here, can you briefly touch on, like, the discrete log problem?
1009
01:24:59.350 --> 01:25:00.090
1010
01:25:00.470 --> 01:25:01.450
Go. I'll take that.
1011
01:25:02.150 --> 01:25:06.970
So as part of the new Taproot upgrade to Bitcoin, we have a new signature algorithm
1012
01:25:07.435 --> 01:25:08.255
called Schnorr.
1013
01:25:09.195 --> 01:25:12.415
The previous algorithm that was used in Bitcoin was called ECGSA.
1014
01:25:12.954 --> 01:25:19.190
And so as Jonas just said, right, the point of a signature algorithm, you take the message, which is your transaction,
1015
01:25:19.570 --> 01:25:33.895
you mix it up somehow with secret data in a way that anyone can verify. And the idea is that you have this unforgeability property. So only the person who have access to the secret data is able to sign the transaction. And if any part of the transaction changes, the signature is no longer valid.
1016
01:25:34.630 --> 01:25:38.810
And the specific way that that's done is by an algorithm called ECGSA,
1017
01:25:39.190 --> 01:25:40.730
which uses a whole bunch of
1018
01:25:41.245 --> 01:25:45.345
crazy moon math involving elliptic curves and complicated algorithms and stuff.
1019
01:25:45.885 --> 01:25:46.385
And
1020
01:25:47.405 --> 01:25:51.119
in the Taproot upgrade, we have replaced ECDSA
1021
01:25:51.739 --> 01:25:53.679
for Taproot output with Schnorr.
1022
01:25:54.139 --> 01:25:56.719
And the difference between the two is actually fairly subtle.
1023
01:25:57.035 --> 01:26:09.469
They both use elliptic curve. They both use a sort of linear ish equation. They both have a very simple algebraic expression, which if we were doing like a math talk I could write them both on the board and you'd almost wonder,
1024
01:26:10.409 --> 01:26:11.630
what the difference was.
1025
01:26:13.130 --> 01:26:17.265
And the difference is the difference ultimately comes down to history, I'd say, which is
1026
01:26:17.645 --> 01:26:20.465
that back in 1989 or so when EC
1027
01:26:20.845 --> 01:26:25.185
Schnorr was first developed by Klaus Schnorr, who is still a professor in Germany, by the way,
1028
01:26:25.540 --> 01:26:30.599
He developed this signature scheme. He put a number of patents on it. 1, that was the number. And
1029
01:26:31.059 --> 01:26:44.190
he then tried to collect royalties on the signature scheme and because it wasn't widely used anywhere it got no use. Right? Nobody wants to start using a cryptographic scheme that you have to pay to use basically and that's always been true pretty much for the history of modern cryptography.
1030
01:26:44.730 --> 01:26:46.730
Then nobody used this. So then,
1031
01:26:47.130 --> 01:26:48.030
a few folks
1032
01:26:48.489 --> 01:26:51.150
at NIST and particularly Neil Koeblets, I think,
1033
01:26:52.525 --> 01:26:53.665
developed ECDSA,
1034
01:26:53.965 --> 01:27:04.840
where they took the Schnorr signature algorithm, they rearranged it a little bit, and they made it just different enough that it no longer violated the patents. And so this then became a standard both because there was a big standard body behind it and,
1035
01:27:05.539 --> 01:27:15.645
also because it was patent free. And that was kind of the design. Right? It was supposed to have all the efficiency and security and all those good properties of Schnorr, but not be encumbered by this patent. But as it happened,
1036
01:27:16.360 --> 01:27:20.620
well, in practice that is true. In practice it accomplished all of those things. But
1037
01:27:21.000 --> 01:27:25.655
Schnorr's system, by being kind of designed for for cryptographic
1038
01:27:26.215 --> 01:27:29.115
with cryptographic goals in mind is a fair bit more elegant.
1039
01:27:29.495 --> 01:27:31.900
It has a security proof and
1040
01:27:32.280 --> 01:27:32.760
a,
1041
01:27:33.160 --> 01:27:37.740
theoretical model, which is much more plausibly related to real life.
1042
01:27:38.120 --> 01:27:38.620
It
1043
01:27:40.125 --> 01:27:51.120
also has a bunch of algebraic simplicity and that's the big thing that I think we'll get into a bit later that makes it possible to do all sorts of cool advanced tricks like multi signatures and threshold signatures and adapter signatures,
1044
01:27:51.580 --> 01:27:52.560
and all these different
1045
01:27:52.860 --> 01:27:58.125
new signature types. You can build them on top of Schnorr, and and it wasn't really practical to build them on top of ECDSA.
1046
01:27:59.785 --> 01:28:00.285
1047
01:28:00.665 --> 01:28:02.765
what is the difference between
1048
01:28:03.385 --> 01:28:06.520
multi signature and threshold signature?
1049
01:28:08.900 --> 01:28:16.074
1050
01:28:17.175 --> 01:28:18.474
is that you can have,
1051
01:28:19.415 --> 01:28:22.240
so I think most people who use Bitcoin are used
1052
01:28:23.100 --> 01:28:35.865
to having, like, a public key and that's like an address. It's where your funds are stored And then your private key is like the secret you know that then you can generate a digital signature in order to spend those funds from that address.
1053
01:28:36.620 --> 01:28:40.400
And now you can kind of have shared ownership of a single pub key.
1054
01:28:42.380 --> 01:28:47.525
Most Bitcoiners are well, some Bitcoiners are probably aware that you can have shared ownership
1055
01:28:47.985 --> 01:28:48.485
using
1056
01:28:48.785 --> 01:28:49.845
a Bitcoin script.
1057
01:28:50.225 --> 01:28:51.605
It's usually called multisig,
1058
01:28:53.200 --> 01:28:56.580
and that's kind of enabled by just putting multiple public keys on chain.
1059
01:28:56.960 --> 01:29:00.980
But what these kind of new protocols enable is
1060
01:29:01.875 --> 01:29:04.135
a way for multiple people to share,
1061
01:29:05.155 --> 01:29:13.170
just one public key that kind of represents all of them. But everyone who isn't involved doesn't need to know that it's multiple multiple people. It just looks like a normal public key.
1062
01:29:13.470 --> 01:29:14.130
And then,
1063
01:29:15.070 --> 01:29:24.565
multi signature is when you have say, like, 2 people and both of them need to kind of work together in order to generate just one signature for their one key.
1064
01:29:25.185 --> 01:29:34.860
And then threshold as the name suggests would be something more like you have 3 people, but only 2 of them are needed in order to generate. So it's like a subset of,
1065
01:29:35.500 --> 01:29:41.054
the parties involved in making that. Yeah. So in some sense, threshold is kind of this general thing and multisignatures
1066
01:29:41.514 --> 01:29:42.155
are just,
1067
01:29:42.475 --> 01:29:45.054
the special case where everyone needs to sign,
1068
01:29:45.380 --> 01:29:55.135
which is kind of confusing because object multisig, like, the way that we previously had of doing multisig on Bitcoin or what's called multisig is actually a threshold signature.
1069
01:29:56.155 --> 01:29:56.975
But yes.
1070
01:29:57.594 --> 01:29:58.975
1071
01:29:59.594 --> 01:30:00.415
it's a different
1072
01:30:01.060 --> 01:30:09.480
state of mind now to perceive, like, the change from, like, a multi signature to now what's more like a interactive aggregate signature.
1073
01:30:10.304 --> 01:30:17.925
Can we briefly expand on how it works? The combination process, like, what are these rounds I hear of?
1074
01:30:19.930 --> 01:30:29.835
1075
01:30:30.315 --> 01:30:31.375
sig sig add.
1076
01:30:32.155 --> 01:30:32.655
And,
1077
01:30:33.275 --> 01:30:34.235
the way that,
1078
01:30:35.835 --> 01:30:41.750
you are able to spend a coin is that you need to So everyone who is,
1079
01:30:42.630 --> 01:30:43.929
involved in that setup
1080
01:30:44.230 --> 01:30:48.170
needs to agree on a message which would be some kind of transaction
1081
01:30:48.655 --> 01:30:49.475
in our
1082
01:30:49.775 --> 01:30:50.415
case and,
1083
01:30:51.215 --> 01:30:52.435
then they just
1084
01:30:52.815 --> 01:30:55.475
sign with a secret key and send the signature
1085
01:30:55.855 --> 01:30:58.355
to some person that will aggregate the signatures
1086
01:30:58.880 --> 01:30:59.380
and,
1087
01:31:00.400 --> 01:31:04.660
then broadcast the transaction to the Bitcoin network, for example.
1088
01:31:06.365 --> 01:31:08.785
Now, if we want to use, the tricks,
1089
01:31:09.405 --> 01:31:10.705
that Nadav mentioned,
1090
01:31:12.445 --> 01:31:15.345
doing a real multi signature where
1091
01:31:15.710 --> 01:31:17.570
even though it's multiple people,
1092
01:31:18.270 --> 01:31:22.210
there is only one public key involved and there's only one signature,
1093
01:31:23.205 --> 01:31:26.505
the setup becomes a bit more complicated
1094
01:31:27.205 --> 01:31:28.105
because now,
1095
01:31:30.389 --> 01:31:31.349
we call this,
1096
01:31:32.230 --> 01:31:33.130
signing process
1097
01:31:33.670 --> 01:31:34.170
interactive,
1098
01:31:35.670 --> 01:31:38.570
because there are now multiple rounds involved,
1099
01:31:40.545 --> 01:31:41.505
Which means that,
1100
01:31:42.065 --> 01:31:44.005
the potential signers first
1101
01:31:44.545 --> 01:31:45.925
send some data around,
1102
01:31:46.385 --> 01:31:46.885
then
1103
01:31:47.500 --> 01:31:51.200
they receive the message and then they sign and,
1104
01:31:51.820 --> 01:31:54.320
this way we have like a a 2 step
1105
01:31:54.735 --> 01:31:56.995
process, you could say, in order,
1106
01:31:57.535 --> 01:31:59.795
to create a multi signature.
1107
01:32:01.135 --> 01:32:02.835
1108
01:32:03.135 --> 01:32:07.360
I guess, like, if I had, like, a key and a safe, or
1109
01:32:07.740 --> 01:32:15.185
do they need to all be online, like, in certain instances? Like, how does this, like, look for, like, the average person? Yeah. There are,
1110
01:32:15.965 --> 01:32:16.945
1111
01:32:17.405 --> 01:32:19.105
definitely which is why
1112
01:32:19.565 --> 01:32:23.680
we when designing these things we try to remove these
1113
01:32:24.320 --> 01:32:24.820
challenges
1114
01:32:25.440 --> 01:32:29.460
as much as possible but unfortunately they cannot be
1115
01:32:29.760 --> 01:32:30.740
removed entirely
1116
01:32:31.280 --> 01:32:32.260
in our universe,
1117
01:32:33.205 --> 01:32:35.385
in our laws of nature as far,
1118
01:32:36.245 --> 01:32:37.625
as as we know.
1119
01:32:39.285 --> 01:32:44.160
So just yesterday we published a Bitcoin improvement proposal draft
1120
01:32:44.620 --> 01:32:47.340
on the Bitcoin mailing list that,
1121
01:32:48.060 --> 01:32:50.880
contains a standard for how to create,
1122
01:32:51.485 --> 01:32:52.785
these multi signatures.
1123
01:32:54.125 --> 01:32:55.725
It's a 2 round variant,
1124
01:32:57.565 --> 01:32:59.505
as kind of the state of the art
1125
01:32:59.829 --> 01:33:03.289
research that we did previously. It was 3 rounds
1126
01:33:03.750 --> 01:33:04.150
and,
1127
01:33:04.869 --> 01:33:06.650
it tries to explain
1128
01:33:07.515 --> 01:33:13.455
all the different footguns. There aren't that many but you still need to understand if you want to implement this.
1129
01:33:14.074 --> 01:33:18.460
I'm not talking about users or anything, I'm talking about implementers of this specification.
1130
01:33:18.920 --> 01:33:24.360
There are a few things that you need to be absolutely aware of. You need to read certain parts of this,
1131
01:33:25.125 --> 01:33:27.145
Bitcoin Improvement Proposal. I think
1132
01:33:27.525 --> 01:33:29.784
if you boil it down it's just 2 or 3 things.
1133
01:33:30.645 --> 01:33:37.790
But if you follow them you will be able to create a Schnorr signature, so a signature for a transaction
1134
01:33:38.090 --> 01:33:40.590
that spends a Taproot output.
1135
01:33:41.344 --> 01:33:50.005
1136
01:33:50.989 --> 01:33:58.745
1137
01:33:59.844 --> 01:34:08.860
So the way that these signature schemes work, both ECDSA and Schnorr is that you have this what's called a linear equation. We have some secret data, you have a message digest,
1138
01:34:09.400 --> 01:34:17.455
you have, basically an ephemeral key that we call a nonce. You put them together into a simple equation, you add all the pieces together, and you're off to the races. And
1139
01:34:18.555 --> 01:34:29.780
when I say add there, I mean, like, something a little more technical than than familiar edition, but still it behaves algebraically in the same way. Right? If you add 3 things together, it doesn't matter what order you put them in. You can rearrange them, all that good stuff.
1140
01:34:30.275 --> 01:34:32.295
So what a rogue key attack is
1141
01:34:32.755 --> 01:34:35.735
is when you take one of these multi signature schemes
1142
01:34:36.115 --> 01:34:38.060
that Nadav and Jonas was talking about
1143
01:34:38.540 --> 01:34:39.840
where you combine
1144
01:34:40.700 --> 01:34:50.684
3 keys from 3 different parties, say, however many you want. Let's say you have 3 parties, they all combine the keys into 1. So the goal is you have one key, one signature, but you have 3 people behind it. Right?
1145
01:34:51.304 --> 01:34:51.804
And
1146
01:34:52.425 --> 01:34:54.425
the goal, of course, is that you don't want
1147
01:34:55.260 --> 01:35:01.200
you want the one key to actually represent the 3 people. Right? Like, certainly, they should believe that, but also it should be a true belief.
1148
01:35:01.580 --> 01:35:22.835
So what you can do during setup, if you're participating in this, say that we wanted to do like Vivek and me and Jonas, we're all doing one of these setups. The idea is that we would each throw a key in the pot, we would add them all together, and then we'd have our combined key. And then later when we're signing, we would each do a signature. We'd add the signatures together and then we get a single signature. We actually have to do that
1149
01:35:23.614 --> 01:36:03.275
in 2 stages. We throw some nonces in the pot, add them up. We throw some signatures in the pot, add them up. Everything's great. The rogue key attack is where what I can do instead is I can wait for both Vivek and Jonas to give me their keys. And then what I do is I make a key and then I subtract their keys from my key. And then I put that in the path. And so if you've been following everything what gets mixed together is my key minus Jonas plus Jonas minus Vivek plus Vivek and what's left is just me. And so all 3 of us, well all 3 of us contributed something and we added up something from all 3 of us, but I kind of ginned things up so that everyone else's contributions would be canceled
1150
01:36:03.575 --> 01:36:17.225
out. And now if I want to go move the coins without consent from either of them I can go ahead and do that because ultimately the final key is just me. So that's a rogue T attack. And the way to avoid it is to do what's called a re randomization
1151
01:36:18.085 --> 01:36:20.505
where when we mix the keys together we need to,
1152
01:36:21.739 --> 01:36:28.719
rather than directly adding them, we need to first multiply them by a random factor and you have to choose that random factor in a way that
1153
01:36:29.099 --> 01:36:39.905
that whenever I try to change what my contribution is it changes the random factors for every other party. So I can't wait for everyone else to do stuff and then contribute my thing. We have to
1154
01:36:40.530 --> 01:36:45.750
have to mix contributions from everybody. And so if I try to gin sync up my active ginning it up will change
1155
01:36:46.050 --> 01:36:46.790
3 randomizers
1156
01:36:47.330 --> 01:36:48.470
and thereby undermine
1157
01:36:48.850 --> 01:36:49.565
my gin.
1158
01:36:50.605 --> 01:36:55.425
So that's the RoTEA attack. So that's one thing that we've had to address as we've developed these multi signature schemes.
1159
01:36:56.205 --> 01:36:57.425
1160
01:37:00.639 --> 01:37:06.079
1161
01:37:06.560 --> 01:37:08.020
were proposed yesterday.
1162
01:37:09.185 --> 01:37:11.365
We're talking about this I think because,
1163
01:37:13.265 --> 01:37:15.445
these kinds of schemes they have a history
1164
01:37:16.100 --> 01:37:18.360
and these attacks were discovered
1165
01:37:18.980 --> 01:37:19.800
on the way,
1166
01:37:20.340 --> 01:37:20.840
to
1167
01:37:21.219 --> 01:37:22.199
to the standardization
1168
01:37:23.465 --> 01:37:29.244
of of these schemes. One of these attacks would be a rogue key attack, but there are also other
1169
01:37:30.770 --> 01:37:32.790
attacks. Perhaps you are aware
1170
01:37:33.170 --> 01:37:33.650
that,
1171
01:37:34.130 --> 01:37:34.630
given
1172
01:37:34.930 --> 01:37:37.750
some byte string and a hash function,
1173
01:37:38.335 --> 01:37:39.555
let's say SHA 256,
1174
01:37:40.575 --> 01:37:43.475
it's very hard to find a pre image
1175
01:37:44.175 --> 01:37:47.235
or an input to that hash function that hashes
1176
01:37:47.640 --> 01:37:49.580
to a specific output.
1177
01:37:50.760 --> 01:37:51.659
That is hard.
1178
01:37:52.360 --> 01:37:58.395
However, what not many people are aware of is that if you have a sum of multiple hashes
1179
01:37:59.255 --> 01:38:06.739
that should sum into a value, a specific value, then finding the pre image for that sum of hashes
1180
01:38:07.120 --> 01:38:09.860
is actually not that hard.
1181
01:38:10.215 --> 01:38:17.095
And, in order to find these inputs to the hash functions, you can use Wagner's algorithm, but there are also,
1182
01:38:17.815 --> 01:38:18.315
more
1183
01:38:19.020 --> 01:38:20.800
efficient algorithms out
1184
01:38:21.260 --> 01:38:22.800
that have just been discovered,
1185
01:38:23.100 --> 01:38:24.719
last year. But this attack,
1186
01:38:25.805 --> 01:38:32.225
actually appears quite often in crypto systems that, we are interested in in in the Bitcoin world.
1187
01:38:33.060 --> 01:38:42.040
1188
01:38:42.415 --> 01:38:43.875
do a multi signature,
1189
01:38:44.494 --> 01:38:49.074
what you're combining is a linear combination, of course, of secret data, but also the hashes of the transactions.
1190
01:38:49.375 --> 01:38:51.315
So if you can find a number of transactions
1191
01:38:52.130 --> 01:38:55.510
whose hashes all add up to the hash of another target transaction,
1192
01:38:56.130 --> 01:38:59.510
you can potentially get signatures on a bunch of good transactions
1193
01:39:00.065 --> 01:39:01.685
where the good ones were chosen
1194
01:39:02.065 --> 01:39:12.550
such as those signatures could be added up to get a signature on a bad one. And so that, and that is actually connecting this to a real system gets pretty hairy and technical, but because of this linearity property
1195
01:39:13.010 --> 01:39:18.685
that I haven't defined, but I'm gonna keep coming back to over and over, You can you can use this very abstract
1196
01:39:19.065 --> 01:39:22.685
Winger attack and actually produce forged signatures using it,
1197
01:39:23.065 --> 01:39:23.885
in some
1198
01:39:24.344 --> 01:39:25.804
long, like some previous
1199
01:39:26.880 --> 01:39:28.820
iterations of of this kind of research.
1200
01:39:29.360 --> 01:39:32.260
1201
01:39:33.225 --> 01:39:37.405
what are some efficiencies gained? Like, I like to sync my full node and,
1202
01:39:37.865 --> 01:39:41.325
you know, really brag about it. Is it faster now? Like, what's going on?
1203
01:39:43.810 --> 01:39:45.350
1204
01:39:46.370 --> 01:39:50.310
past transactions, obviously. So the the kind of current sync time,
1205
01:39:51.055 --> 01:39:54.355
isn't all that affected by by Taproot. But new,
1206
01:39:55.215 --> 01:39:57.635
transactions, if people are using Taproot,
1207
01:39:58.610 --> 01:39:59.670
are going to,
1208
01:40:00.130 --> 01:40:05.190
well, I mean, Schnorr itself is just faster to verify already on its own,
1209
01:40:05.885 --> 01:40:07.344
by a little bit. But then,
1210
01:40:07.965 --> 01:40:09.505
with kind of the new standardization
1211
01:40:09.885 --> 01:40:10.385
process,
1212
01:40:10.925 --> 01:40:15.390
you can also now kind of aggregate a bunch of signatures that you want to verify
1213
01:40:16.590 --> 01:40:23.010
together in a way that then you can verify them all at once in a way that's faster than verifying each signature individually,
1214
01:40:23.815 --> 01:40:25.195
and that'll lead to,
1215
01:40:26.215 --> 01:40:28.555
I mean, it it will mean that
1216
01:40:29.175 --> 01:40:32.235
as opposed to the universe in which we didn't implement Schnorr,
1217
01:40:33.410 --> 01:40:36.790
we're we're faster than that universe in in syncing.
1218
01:40:37.490 --> 01:40:38.950
1219
01:40:40.575 --> 01:40:45.315
verify maybe one signature for a whole block or one signature for entire, like,
1220
01:40:46.094 --> 01:40:57.489
1221
01:40:57.915 --> 01:41:21.885
1222
01:41:22.270 --> 01:41:40.440
And if you've got, like, 3 or 4 of these, you can probably verify it, like, twice as fast, but if you've got a 1,000 of them, you could potentially verify it, something like 8 or 10 times as fast. It's not a simple curve. It can just give you a multiplier, but it gets better the bigger your batch is. The other cool thing though that we'll see with Schnorr signatures is because we can do this multisig
1223
01:41:41.060 --> 01:41:42.040
kind of constructions,
1224
01:41:42.660 --> 01:41:46.200
oftentimes you won't even have so many signatures to verify.
1225
01:41:46.545 --> 01:41:53.925
And I think that's probably in practice where we're going to see the bulk of the savings is in the signatures that aren't even on the blockchain because they no longer need to be. Yeah.
1226
01:41:54.909 --> 01:41:55.489
1227
01:41:55.869 --> 01:41:56.769
one of the,
1228
01:41:57.949 --> 01:42:01.650
more immediate applications of this multi signature
1229
01:42:02.190 --> 01:42:02.690
technology
1230
01:42:03.150 --> 01:42:03.650
is
1231
01:42:03.955 --> 01:42:06.295
opening and closing lightning channels
1232
01:42:06.835 --> 01:42:11.494
because there you are already in the setting where you have a 2 of 2 and,
1233
01:42:13.860 --> 01:42:14.920
the Lightning Network,
1234
01:42:15.540 --> 01:42:20.520
already is a very interactive and, stateful process, very
1235
01:42:20.915 --> 01:42:24.675
different to, like, hardware wallets signing in your,
1236
01:42:25.075 --> 01:42:27.895
bank using your bank vault or or whatever.
1237
01:42:28.275 --> 01:42:28.775
And
1238
01:42:31.390 --> 01:42:32.590
this would, I think,
1239
01:42:32.990 --> 01:42:33.490
benefit,
1240
01:42:34.910 --> 01:42:46.125
Lightning quite a bit because right now you need to, write 2 public keys to the, chain as well as 2 signatures when you want to close a Lightning channel,
1241
01:42:46.510 --> 01:42:47.250
And, with
1242
01:42:48.110 --> 01:42:49.010
multi signature
1243
01:42:50.030 --> 01:42:55.170
schemes, you can reduce that to 1 public key, 1 signature, which would make it cheaper
1244
01:42:56.344 --> 01:42:57.244
to, use Lightning.
1245
01:42:59.545 --> 01:43:01.724
1246
01:43:02.665 --> 01:43:05.380
with these? I know Nadav works on DLCs.
1247
01:43:07.040 --> 01:43:09.220
I know, like, there's also a preimage
1248
01:43:09.600 --> 01:43:11.860
or hash reuse along the path.
1249
01:43:12.535 --> 01:43:13.835
What what's possible now?
1250
01:43:14.935 --> 01:43:16.795
1251
01:43:17.655 --> 01:43:18.155
application,
1252
01:43:19.095 --> 01:43:21.355
that is made much easier by Schnorr signatures,
1253
01:43:22.410 --> 01:43:28.270
is a variance that I believe Andrew came up with called adapter signatures. Oh, yes.
1254
01:43:29.130 --> 01:43:30.910
And they kind of allow
1255
01:43:31.735 --> 01:43:32.875
you to,
1256
01:43:34.775 --> 01:43:37.035
say, bake in some more
1257
01:43:38.615 --> 01:43:39.115
logic
1258
01:43:39.510 --> 01:43:51.265
in into your signatures than just kind of saying like, yes, this person can spend this, you can kind of make it a bit more complicated. So essentially, what DLCs do is we utilize adapter signatures
1259
01:43:51.965 --> 01:43:53.025
in order to,
1260
01:43:54.525 --> 01:43:55.025
make
1261
01:43:55.560 --> 01:43:56.060
Bitcoin
1262
01:43:56.600 --> 01:43:57.100
payments
1263
01:43:57.720 --> 01:43:58.220
that,
1264
01:43:58.760 --> 01:44:01.100
pay different amounts depending on
1265
01:44:01.400 --> 01:44:04.380
what, say, an oracle says happened in the real world.
1266
01:44:04.695 --> 01:44:13.595
So say like if, someone won an election or something like this then, you know, there might have been multiple candidates, people can put money into a Bitcoin address
1267
01:44:13.960 --> 01:44:20.140
that will pay to a different person depending on who wins that election or all sorts of variants on this kind of thing.
1268
01:44:21.385 --> 01:44:24.925
And, I believe this also affects lightning. You can essentially
1269
01:44:25.465 --> 01:44:29.165
perform lightning routing in a much better way than previously
1270
01:44:29.465 --> 01:44:31.165
or than it currently is done
1271
01:44:31.690 --> 01:44:36.590
using these adapter signatures. And one of the main benefits of this is that you don't have to use,
1272
01:44:36.890 --> 01:44:37.950
Bitcoin's native
1273
01:44:38.645 --> 01:44:46.505
scripting language, you kind of bake it all into the math of the signature itself and it all kind of just looks like normal signature activity on chain,
1274
01:44:47.239 --> 01:44:53.659
but it kind of makes it so that only the people who need to know kind of do the math and and do all of the contract
1275
01:44:54.395 --> 01:44:56.175
logic and everything else.
1276
01:44:56.955 --> 01:44:59.295
Really, you only use the Bitcoin blockchain
1277
01:44:59.835 --> 01:45:03.135
for the actual transfer of funds, which is what it's best at.
1278
01:45:03.890 --> 01:45:04.390
Yeah.
1279
01:45:04.850 --> 01:45:12.070
1280
01:45:12.530 --> 01:45:26.620
So one place that the privacy comes from is just like, just from using multisix directly. That already gives you a privacy benefit if you've got one key that potentially represents multiple people and potentially represents some complicated policy where it could be a threshold or
1281
01:45:27.080 --> 01:45:39.645
some other arbitrary set of signers. In the lightning case, things get a lot more interesting because as you say, with these adapter signature constructions, you're able to start embedding some kind of non trivial logic into the signatures themselves.
1282
01:45:40.425 --> 01:45:40.925
And
1283
01:45:41.300 --> 01:45:42.760
adaptive signatures themselves,
1284
01:45:43.620 --> 01:45:49.080
what they are one way to think of them is a form of verifiable encryption. And what I mean by that is that I can take a signature,
1285
01:45:49.385 --> 01:45:54.205
I can encrypt it in some way where I can prove that the data that I'm encrypting
1286
01:45:54.905 --> 01:46:03.710
satisfies some algebraic properties that let me hook it into some other cryptosystem somewhere or something. But ordinarily, the point of encryption, right, is that you basically completely scramble your data.
1287
01:46:04.010 --> 01:46:04.510
And
1288
01:46:05.450 --> 01:46:05.850
if you
1289
01:46:06.875 --> 01:46:17.030
the idea is that this intended recipient can decrypt it and get the data out. But until they do the decryption, if they don't have a decryption of queues, there's nothing they can, they can't even tell that it is encrypted data, right, it could just be noise.
1290
01:46:17.330 --> 01:46:18.630
With verifiable encryption,
1291
01:46:19.250 --> 01:46:20.550
you can,
1292
01:46:21.145 --> 01:46:24.045
you know, provide some more substance to that. So in particular,
1293
01:46:24.585 --> 01:46:26.845
when you are using the lightning network,
1294
01:46:27.225 --> 01:46:35.800
the way that your payment channels work, well, the way that Lightning works is you're actually chaining multiple payment channels off of each other and you have these paths through Lightning Network and you're routing money through all this.
1295
01:46:36.395 --> 01:46:37.935
And along a certain path,
1296
01:46:38.315 --> 01:46:40.495
you have to maintain this,
1297
01:46:41.355 --> 01:46:51.260
kind of fixed identifier. I think it's an invoice ID or something in the UX. But what it is in the current lightning indication is it's some hash, some random hash of some data.
1298
01:46:51.719 --> 01:47:10.670
And this hash is put into the scripts in all the payment channels and it has to be the same and that's how the payment channels are linked. The idea is that when you update 1 payment channel, it causes a preimage that has to be revealed and the revelation can then be used in the previous payment channel, which then, you know, and everyone before that. With adaptive signatures,
1299
01:47:11.455 --> 01:47:17.315
rather than using script to require that your signature has to come along with revealing this hash privilege,
1300
01:47:18.255 --> 01:47:27.620
you can use this form of verifiable encryption. You can say by signing, you can say my signature itself is an encryption key or a decryption key, more importantly, it's both.
1301
01:47:28.305 --> 01:47:34.725
So by signing this update to this payment channel, I am now revealing a decryption key in the form of a signature
1302
01:47:35.160 --> 01:47:50.795
and that decryption key can be used to reveal some secret data, which I can then take and use in the previous payment channel and chain it forward. And even cooler is that you can actually re randomize it at each step. So now rather than having a whole path, we have the same random ID in each one
1303
01:47:51.150 --> 01:47:58.610
that somebody who had a God's eye view of the network could tell that it was all one path. You now have this re randomization where even the people in the path itself
1304
01:47:59.114 --> 01:48:09.490
might not know where it starts and where it ends because there's re randomization happening at the hop after them and the hop before them. So there's a privacy benefit there even within the Lightning Network. So
1305
01:48:09.970 --> 01:48:15.465
1306
01:48:16.085 --> 01:48:18.745
I'd definitely like to discuss scriptless scripts,
1307
01:48:20.725 --> 01:48:21.225
MUSIG
1308
01:48:21.525 --> 01:48:24.345
DN, or perhaps even CISA.
1309
01:48:25.370 --> 01:48:25.870
And
1310
01:48:26.330 --> 01:48:28.510
then, there was a recent paper put out,
1311
01:48:29.210 --> 01:48:32.110
and also some libraries from, Jesse Posner
1312
01:48:32.650 --> 01:48:35.085
regarding a threshold scheme called frost.
1313
01:48:35.385 --> 01:48:35.705
So,
1314
01:48:36.585 --> 01:48:38.205
let's try to rush through this.
1315
01:48:39.465 --> 01:48:45.200
1316
01:48:45.580 --> 01:48:46.320
1317
01:48:46.700 --> 01:48:58.870
1318
01:48:59.490 --> 01:49:00.790
I'm sorry, I'm doing it now.
1319
01:49:01.970 --> 01:49:06.070
To finish my spiel about adaptive signatures. So adaptive signatures give you this kind of,
1320
01:49:07.175 --> 01:49:18.840
this verifiable encryption property, which you can use in the Lightning Network just to feed data through there. But what you can also do is encrypt other signatures, for example. So you can do arbitrary forms of atomic swaps and stuff
1321
01:49:19.300 --> 01:49:20.200
where you
1322
01:49:22.500 --> 01:49:25.000
where you have, say, 2 transactions on 2 different blockchains,
1323
01:49:25.445 --> 01:49:34.520
for example, and you want to swap. Right? You're trying to trade some Bitcoin for some something worthless. Right? And the the worthless thing has its own chain. Right? That they do usually.
1324
01:49:34.980 --> 01:49:35.300
And,
1325
01:49:35.940 --> 01:49:52.980
so you want to do this fairly. Right? You don't want, you know, one person to give their money away and then the other to just take it and then walk away. So the way that you do this is you set things up so that when the first person signs to take their money, that signature then decrypts a signature that gives the other asset away on the other side. So you get this atomicity
1326
01:49:53.599 --> 01:49:54.420
in that form.
1327
01:49:54.880 --> 01:49:55.380
Another
1328
01:49:56.159 --> 01:50:01.305
more general application of this would be something called a 0 knowledge contingent payment.
1329
01:50:03.445 --> 01:50:03.945
ZKCP.
1330
01:50:04.805 --> 01:50:06.265
ZKCP. Thank you.
1331
01:50:07.460 --> 01:50:07.960
Where
1332
01:50:08.820 --> 01:50:34.620
what you are encrypting rather than being another signature or something is basically some arbitrary piece of data and you provide this extra object called a zero knowledge proof. And a 0 knowledge proof is a very general, very powerful cryptographic object, which are very slow to create. They have weird security models. There's lots of questionable things about 0 knowledge proof. But the cool thing here is we don't put them on the blockchain and we don't need them for long. They're kind of an ephemeral thing here. So what I could do is supposing
1333
01:50:34.920 --> 01:50:35.980
say that
1334
01:50:36.360 --> 01:50:36.860
I
1335
01:50:37.465 --> 01:50:46.285
meaning of trying to come up with a noncontracted example. Right? I have some satellite imagery. Okay? And I claim that I found some oil deposits. Okay? And I'm trying to sell those to Chevron
1336
01:50:48.170 --> 01:50:52.670
and I don't want to just give them the satellite images because then they'll take it and run away.
1337
01:50:53.130 --> 01:51:00.574
And for some reason they're really into high-tech, like bleeding edge cryptography and wanna play games with me, even though that's really not what they do.
1338
01:51:01.195 --> 01:51:05.454
And, so what I can do is I can take this satellite image, I can somehow
1339
01:51:06.010 --> 01:51:07.309
describe the
1340
01:51:07.690 --> 01:51:09.389
evidence of oil in
1341
01:51:09.929 --> 01:51:13.949
a verifiable computationally verifiable way and produce a zero knowledge proof.
1342
01:51:14.865 --> 01:51:26.949
Well, I'll take the image, I'll encrypt it. I'll produce a 0 knowledge proof that what I encrypted is a satellite image, which satisfies these criteria, which Chevron agrees actually indicates evidence of oil. And Now we do a 0 knowledge contingent payment
1343
01:51:27.330 --> 01:51:29.590
where the 2 of us jointly create a transaction
1344
01:51:30.130 --> 01:51:32.710
where in order for them to take my money,
1345
01:51:33.315 --> 01:51:36.135
I have to sign a transaction and my signing of that transaction,
1346
01:51:36.514 --> 01:51:42.970
well, I know it's going to give me the money because that's the transaction that gives me money. My signing will then decrypt the image,
1347
01:51:43.350 --> 01:52:00.260
which Chevron knows will be what they expect, and so we can execute a transaction that way, even if the 2 of us don't really trust each other, and even if, like, nobody should trust either of us. The the zero knowledge proof will step in there. So this general framework of of playing games like this with adaptive signatures is what we call scriptless scripts.
1348
01:52:00.800 --> 01:52:09.625
1349
01:52:10.405 --> 01:52:11.705
Let's let's take
1350
01:52:12.085 --> 01:52:12.905
a bit more
1351
01:52:13.365 --> 01:52:18.185
applicable thing. Like, I know, you and Tim Rufing also work on
1352
01:52:18.600 --> 01:52:20.699
half ag music too. What are these,
1353
01:52:21.400 --> 01:52:27.820
advantages and, efficiencies potentially gained for things like lightning gossip? Can you touch on this? From, aggregation?
1354
01:52:29.094 --> 01:52:29.994
1355
01:52:31.175 --> 01:52:36.394
I think would make first sense to distinguish what we call signature aggregation
1356
01:52:36.830 --> 01:52:39.890
from, multi signatures or threshold signatures.
1357
01:52:40.510 --> 01:52:43.170
And, for us, the main distinction
1358
01:52:43.870 --> 01:52:45.375
is that in multisignatures
1359
01:52:45.915 --> 01:52:47.135
or threshold signatures,
1360
01:52:47.515 --> 01:52:49.855
you only have a single message.
1361
01:52:50.955 --> 01:52:51.515
In the,
1362
01:52:52.155 --> 01:52:53.455
Bitcoin use case,
1363
01:52:53.770 --> 01:52:54.429
that is
1364
01:52:55.130 --> 01:52:57.949
dependent on the input that you're spending,
1365
01:52:58.809 --> 01:53:03.309
or dependent on the coin that you're spending, which means you have some
1366
01:53:04.155 --> 01:53:08.575
set of people and they have shared ownership over a single coin.
1367
01:53:09.035 --> 01:53:11.695
Now when we go to the signature aggregation world,
1368
01:53:12.090 --> 01:53:16.990
there are multiple signers and each with different messages.
1369
01:53:18.010 --> 01:53:22.245
Right? So this corresponds to a transaction with multiple inputs,
1370
01:53:22.785 --> 01:53:23.025
and,
1371
01:53:23.745 --> 01:53:26.165
this transaction must have multiple signatures,
1372
01:53:26.625 --> 01:53:29.605
and each signature will be over a different message
1373
01:53:30.050 --> 01:53:30.550
because,
1374
01:53:32.210 --> 01:53:36.390
because the signature is used to authorize the spend of a different coin.
1375
01:53:37.775 --> 01:53:39.935
So we call this, these schemes,
1376
01:53:40.335 --> 01:53:41.395
signature aggregation.
1377
01:53:43.695 --> 01:53:46.755
What they are doing is they act really aggregate
1378
01:53:47.230 --> 01:53:48.270
signatures and,
1379
01:53:48.910 --> 01:53:51.090
this doesn't have privacy benefits,
1380
01:53:52.110 --> 01:53:54.690
in general at least, but it has
1381
01:53:55.045 --> 01:53:56.265
scalability benefits
1382
01:53:56.885 --> 01:53:57.385
because,
1383
01:53:58.965 --> 01:54:00.665
a big part of transactions
1384
01:54:01.125 --> 01:54:03.145
right now are actually signatures.
1385
01:54:03.845 --> 01:54:04.345
So
1386
01:54:06.590 --> 01:54:07.730
what would be
1387
01:54:08.590 --> 01:54:13.730
we could try to aggregate these signatures into a smaller signature.
1388
01:54:14.865 --> 01:54:15.185
And,
1389
01:54:15.745 --> 01:54:18.245
there we again basically distinguish
1390
01:54:18.545 --> 01:54:20.405
2 different types of schemes,
1391
01:54:21.905 --> 01:54:23.525
mainly half aggregation
1392
01:54:24.400 --> 01:54:28.960
and full aggregation. And full aggregation is a bit simpler to explain because,
1393
01:54:30.240 --> 01:54:31.280
that works by
1394
01:54:31.945 --> 01:54:38.525
or or the output of the full, signature aggregation algorithm is a single signature. So in an ideal world,
1395
01:54:38.985 --> 01:54:42.628
every Bitcoin transaction would have a single signature,
1396
01:54:43.504 --> 01:54:45.380
unlike today where,
1397
01:54:45.760 --> 01:54:48.580
there's a signature for every input, basically.
1398
01:54:51.715 --> 01:54:52.935
But creating these
1399
01:54:53.315 --> 01:54:53.815
signatures
1400
01:54:54.435 --> 01:54:54.935
has
1401
01:54:56.994 --> 01:54:57.494
similar
1402
01:54:57.960 --> 01:54:58.460
interactivity
1403
01:54:58.840 --> 01:55:00.140
properties than,
1404
01:55:00.760 --> 01:55:01.660
multi signatures.
1405
01:55:02.120 --> 01:55:08.755
So it's not so easy to do, and how to exactly do that is, still an open research problem.
1406
01:55:10.255 --> 01:55:11.795
For half aggregation,
1407
01:55:12.335 --> 01:55:17.630
we don't get the benefits of having only a single signature in the end. We basically
1408
01:55:18.250 --> 01:55:22.830
are only able to aggregate half of the original signatures together,
1409
01:55:23.135 --> 01:55:25.715
but this process is non interactive,
1410
01:55:26.095 --> 01:55:28.815
so anyone can do that. And,
1411
01:55:29.855 --> 01:55:31.075
that would be something,
1412
01:55:32.020 --> 01:55:33.719
that could be added to
1413
01:55:34.020 --> 01:55:35.960
Bitcoin consensus perhaps,
1414
01:55:36.579 --> 01:55:37.559
at some point
1415
01:55:37.860 --> 01:55:38.760
in the future,
1416
01:55:39.165 --> 01:55:39.665
but,
1417
01:55:40.205 --> 01:55:42.225
it may have also implications
1418
01:55:42.925 --> 01:55:43.985
on protocols
1419
01:55:44.364 --> 01:55:47.425
on top of the Bitcoin network such as,
1420
01:55:48.450 --> 01:55:48.950
Lightning
1421
01:55:49.810 --> 01:55:55.670
because, Lightning, at least right now, gossips a lot of signatures around to prove,
1422
01:55:56.844 --> 01:55:59.905
that nodes actually have open channels.
1423
01:56:01.485 --> 01:56:04.545
And these signatures are just bare single signatures,
1424
01:56:05.270 --> 01:56:10.650
So what could happen is that instead of each sending a single signature for,
1425
01:56:11.270 --> 01:56:13.050
in order to do a single proof
1426
01:56:13.425 --> 01:56:13.585
that,
1427
01:56:14.305 --> 01:56:15.445
a channel exists,
1428
01:56:16.385 --> 01:56:18.965
some party, could be anyone, could just aggregate
1429
01:56:19.425 --> 01:56:23.140
these signatures into a single half aggregated signature then,
1430
01:56:23.780 --> 01:56:25.080
in order to reduce,
1431
01:56:25.780 --> 01:56:30.120
the size of the messages that need to be sent around in the Lightning Network.
1432
01:56:32.324 --> 01:56:32.824
1433
01:56:33.445 --> 01:56:35.545
Hopefully, we'll get that sooner than later.
1434
01:56:36.405 --> 01:56:38.425
Alright. Nadav, what is frost?
1435
01:56:39.670 --> 01:56:41.290
1436
01:56:41.989 --> 01:56:45.290
proposal for threshold signatures on top of Schnorr.
1437
01:56:45.909 --> 01:56:47.610
I believe it stands for
1438
01:56:48.175 --> 01:56:49.395
flexible around
1439
01:56:50.255 --> 01:56:50.755
optimized,
1440
01:56:52.495 --> 01:56:53.315
what's the s?
1441
01:56:55.590 --> 01:56:58.010
1442
01:56:58.710 --> 01:57:01.210
1443
01:57:03.105 --> 01:57:04.245
Yeah. So essentially,
1444
01:57:05.905 --> 01:57:06.565
it is,
1445
01:57:06.945 --> 01:57:08.085
so it's a 2 round,
1446
01:57:08.865 --> 01:57:10.485
proposal meaning that,
1447
01:57:11.500 --> 01:57:12.239
well, I
1448
01:57:12.699 --> 01:57:17.840
guess there's a pre computation you can do so that it kind of looks like there's only a single round where,
1449
01:57:18.219 --> 01:57:19.039
that kind of
1450
01:57:19.385 --> 01:57:24.365
looks like normal signing where you just do something once, like, everyone generates their,
1451
01:57:24.745 --> 01:57:27.805
part of the signature and then someone puts it all together.
1452
01:57:28.620 --> 01:57:29.340
But really,
1453
01:57:30.380 --> 01:57:36.480
there's also kind of like a setup round. So there's a setup round and then a signing round. It's maybe a high level way to think about it.
1454
01:57:37.505 --> 01:57:38.005
Essentially,
1455
01:57:38.625 --> 01:57:40.165
what you do is,
1456
01:57:40.865 --> 01:57:43.685
everyone kind of generate or has their own
1457
01:57:44.385 --> 01:57:49.790
private key is how you could think of it or or secret share and then, together they they
1458
01:57:50.730 --> 01:57:52.590
have one private key.
1459
01:57:52.935 --> 01:57:56.155
It's not as simple as just adding all of those keys in a pot,
1460
01:57:56.775 --> 01:58:00.074
but you you do a little bit more math and you end up getting
1461
01:58:00.375 --> 01:58:01.594
a key which
1462
01:58:02.280 --> 01:58:09.340
then could in theory be derived by any, say, 2 of 3 participants or 3 of 5 or t of n.
1463
01:58:10.625 --> 01:58:18.325
But then rather than actually doing that because you don't want people to just know what this private key is because then they can sign for the group. So what you do instead
1464
01:58:18.750 --> 01:58:19.650
is you collaboratively
1465
01:58:20.030 --> 01:58:20.530
any,
1466
01:58:20.989 --> 01:58:25.489
2 or 3 2 of 3 or 3 of 5 or whatever threshold you want
1467
01:58:25.844 --> 01:58:29.545
of all of the people can get together and collaboratively generate,
1468
01:58:30.565 --> 01:58:33.225
like, they each person generates a partial signature
1469
01:58:33.765 --> 01:58:34.985
using their own
1470
01:58:35.820 --> 01:58:38.960
secret share and then it's all put together
1471
01:58:39.260 --> 01:58:40.560
and if you have
1472
01:58:40.860 --> 01:58:44.480
at least t people, at least 3 of the 5 people, for example,
1473
01:58:45.365 --> 01:58:51.065
then you generate just one normal looking Schnorr signature for the one kind of group key.
1474
01:58:52.725 --> 01:58:53.225
And
1475
01:58:54.790 --> 01:59:00.570
it's kind of done in a a simple enough way that it it works well with a lot of other
1476
01:59:01.945 --> 01:59:03.645
things that you might wanna do.
1477
01:59:04.985 --> 01:59:09.325
I actually I don't know if it works with adapter signatures. I imagine that you would be able
1478
01:59:09.889 --> 01:59:19.265
1479
01:59:20.125 --> 01:59:22.545
1480
01:59:23.245 --> 01:59:24.305
kind of is
1481
01:59:24.740 --> 01:59:27.960
similar in nature to how multi signatures look, but it's
1482
01:59:28.340 --> 01:59:29.480
done more generally.
1483
01:59:29.860 --> 01:59:39.515
And I guess if Jonas wants to talk about the trade offs between using something like music and frog. We can have a bonus round about blind signatures or ring signatures if you'd like to.
1484
01:59:41.130 --> 01:59:42.909
1485
01:59:43.369 --> 01:59:43.869
interesting
1486
01:59:44.170 --> 01:59:48.820
to to get across is what are the different stages that these proposals are,
1487
01:59:49.935 --> 01:59:55.074
right now. Because people in the audience might be interested to to use this eventually.
1488
01:59:55.455 --> 01:59:56.495
Mhmm. And,
1489
01:59:57.215 --> 01:59:57.715
so
1490
01:59:58.190 --> 02:00:03.409
what we're mostly talking about right now is only the lowest level that you're really interested in,
1491
02:00:03.869 --> 02:00:04.610
which is
1492
02:00:05.575 --> 02:00:12.715
the cryptography part. Right? But there are more parts before you can actually use this in your wallet. Right? There needs to be standardization
1493
02:00:13.175 --> 02:00:14.715
first of the crypto scheme,
1494
02:00:15.170 --> 02:00:15.410
And,
1495
02:00:16.010 --> 02:00:17.510
in for multisignatures,
1496
02:00:18.610 --> 02:00:19.350
we are
1497
02:00:19.810 --> 02:00:22.550
as I said, we we published a standard yesterday
1498
02:00:22.930 --> 02:00:23.990
for Frost.
1499
02:00:25.114 --> 02:00:29.355
I would say there it's, a bit more early, but there are also standards,
1500
02:00:30.395 --> 02:00:30.895
progressing,
1501
02:00:31.650 --> 02:00:36.390
that will be eventually usable with, Taproot and tweaking and and whatnot.
1502
02:00:37.170 --> 02:00:43.405
But then there is also the other layer of how does this integrate with wallets really, that you can have multiple wallets
1503
02:00:43.945 --> 02:00:44.445
independently,
1504
02:00:45.705 --> 02:00:47.245
or independently implemented
1505
02:00:47.705 --> 02:00:50.719
from different vendors that work together and create,
1506
02:00:51.099 --> 02:00:52.159
such a signature.
1507
02:00:52.539 --> 02:00:52.860
And,
1508
02:00:54.139 --> 02:00:55.280
that is, I think,
1509
02:00:55.739 --> 02:01:00.045
a really interesting thing in the future how to exactly do that.
1510
02:01:01.065 --> 02:01:01.305
And,
1511
02:01:02.505 --> 02:01:08.850
that might be more difficult for some schemes than for others. Right? For multi signature, which is a more,
1512
02:01:09.710 --> 02:01:13.310
specific scheme, n of n, that might be a little bit more,
1513
02:01:13.875 --> 02:01:15.895
a little bit easier to do for,
1514
02:01:16.595 --> 02:01:19.655
wallet implementers than something, for example,
1515
02:01:20.035 --> 02:01:21.495
like, like Frost.
1516
02:01:22.699 --> 02:01:33.594
1517
02:01:34.775 --> 02:01:37.255
1518
02:01:38.700 --> 02:01:41.040
are basically a client in a server protocol
1519
02:01:41.420 --> 02:01:45.040
where the server signs some sign signs some message
1520
02:01:45.795 --> 02:01:49.335
that came from the client without knowing what this message is.
1521
02:01:49.875 --> 02:01:51.895
And also such that the signature
1522
02:01:52.355 --> 02:01:52.995
won't be,
1523
02:01:53.715 --> 02:01:54.215
correlated
1524
02:01:54.770 --> 02:01:59.010
with, the message in the future or even the signature in in the future. And,
1525
02:02:00.690 --> 02:02:01.829
how is this used?
1526
02:02:02.145 --> 02:02:10.005
This can be used for example for Federated e cash or e cash in in general, which is I think one of the interesting
1527
02:02:10.920 --> 02:02:13.420
direction that the Bitcoin community
1528
02:02:13.800 --> 02:02:17.739
is is looking into where you have much better privacy,
1529
02:02:18.695 --> 02:02:22.155
guarantees than anything you could achieve with, blockchains
1530
02:02:22.534 --> 02:02:23.034
or
1531
02:02:23.494 --> 02:02:24.074
or Bitcoin
1532
02:02:25.014 --> 02:02:25.675
in particular,
1533
02:02:26.969 --> 02:02:28.349
but you have other
1534
02:02:29.050 --> 02:02:33.550
trade offs. And, these blind signature schemes, they don't need to be
1535
02:02:34.325 --> 02:02:35.305
part of,
1536
02:02:35.765 --> 02:02:36.745
Bitcoin consensus,
1537
02:02:37.685 --> 02:02:41.545
which means that we could use can use more exotic schemes
1538
02:02:41.870 --> 02:02:43.489
that don't have the trade offs,
1539
02:02:43.949 --> 02:02:44.690
of interactivity
1540
02:02:45.070 --> 02:02:46.190
that we discussed with,
1541
02:02:46.750 --> 02:02:51.170
multi signatures or complicated setup like in, threshold signatures,
1542
02:02:51.505 --> 02:02:53.585
but, we can have more,
1543
02:02:53.905 --> 02:02:56.485
exotic cryptographic assumptions and then,
1544
02:02:57.025 --> 02:03:01.660
have a simp a scheme that is simpler to implement and harder,
1545
02:03:02.280 --> 02:03:03.340
to mess up,
1546
02:03:04.040 --> 02:03:09.340
and also that has properties like threshold blind signing, where you have a whole federation
1547
02:03:09.995 --> 02:03:10.554
that would,
1548
02:03:11.435 --> 02:03:12.655
require a signature,
1549
02:03:13.435 --> 02:03:15.215
on a token or whatever,
1550
02:03:16.715 --> 02:03:19.295
1551
02:03:20.020 --> 02:03:23.640
1552
02:03:24.500 --> 02:03:24.820
1553
02:03:25.460 --> 02:03:28.360
this is essentially Mini Mint or similar applications.
1554
02:03:29.685 --> 02:03:31.065
1555
02:03:31.525 --> 02:03:32.025
1556
02:03:33.285 --> 02:03:33.945
I guess
1557
02:03:34.645 --> 02:03:42.600
that's pretty much it. I'd like conclude this panel. Let's get a huge round of applause for Andrew Polstra, Jonas Nyck, and Nadav Cohen.
1558
02:03:50.065 --> 02:03:56.085
1559
02:03:58.239 --> 02:04:00.020
I I wanna start off by
1560
02:04:00.560 --> 02:04:01.860
I I I would assume
1561
02:04:02.239 --> 02:04:07.114
a lot of people here don't know what covenants are. I, myself, have never even
1562
02:04:08.295 --> 02:04:09.355
really studied covenants
1563
02:04:09.815 --> 02:04:12.955
really, really deeply. I know about them, obviously, but
1564
02:04:13.370 --> 02:04:22.350
I wanna take this time where we can all learn you can essentially teach Lisa and I about covenants. This can be an educational panel so then the audience can learn with us what are covenants.
1565
02:04:23.035 --> 02:04:28.175
And I wanna start with when I first started doing research, I said, what was the first covenant?
1566
02:04:28.875 --> 02:04:34.420
And what came up with what came up on Google was the first covenant was between God and Abraham,
1567
02:04:35.040 --> 02:04:37.780
and the way this this covenant is satisfied is
1568
02:04:38.400 --> 02:04:39.780
Jewish men got circumcised.
1569
02:04:40.285 --> 02:04:41.505
So I wanna know
1570
02:04:41.965 --> 02:04:49.505
how how does this relate to Bitcoin? Maybe we can start there, work our way from, you know, a few 1000 years ago, and work our way here to Bitcoin.
1571
02:04:50.200 --> 02:04:50.920
Just kidding. But,
1572
02:04:52.120 --> 02:04:52.920
like I said,
1573
02:04:53.320 --> 02:04:56.620
few minutes on the clock. Let's do very, very quick introductions,
1574
02:04:57.115 --> 02:05:04.235
10 words or less kind of thing, and let's get rolling into the education. So let's start with Lisa. Hi. I'm I'm Lisa, also in.
1575
02:05:05.040 --> 02:05:08.820
I work on Nikon. Is we need mic for Lisa.
1576
02:05:10.240 --> 02:05:17.935
1577
02:05:19.915 --> 02:05:21.534
1578
02:05:22.050 --> 02:05:31.095
I'm a Bitcoiner on Bitcoin dev. I think I started in Bitcoin, like, 5 years ago or more or less, you know, initially exploring and building around mining, wallets, payments,
1579
02:05:31.475 --> 02:05:39.255
and I initial and and I, you know, finally ended in this covenants rabbit hole. So it's it's a really interesting place.
1580
02:05:40.100 --> 02:05:40.600
Exciting
1581
02:05:41.140 --> 02:05:48.040
1582
02:05:48.594 --> 02:05:49.975
1583
02:05:50.355 --> 02:05:51.655
Hello? Hello? Okay.
1584
02:05:52.355 --> 02:05:52.855
1585
02:05:53.395 --> 02:05:55.815
1586
02:05:56.420 --> 02:06:01.639
1587
02:06:02.179 --> 02:06:11.095
And then in in the sake of time, maybe we just kinda skip a little bit of the 2000 years of history of covenants and just kinda jump in it, for the sake of time. So,
1588
02:06:12.800 --> 02:06:19.395
how do we where are we at right now? How do we get here? Like what is a covenant in terms of Bitcoin, Jeremy? Yeah.
1589
02:06:19.955 --> 02:06:29.095
1590
02:06:29.590 --> 02:06:31.530
and when you open it up usually
1591
02:06:31.910 --> 02:07:34.120
you get some coins out and you can put those into whatever new treasure chest you want, and that treasure chest could have whatever locks you wanna have on it. A covenant is like when you open it up, and then instead of gold coins or something, you see it's like Jimmy Hendrix's guitar, and it says please only put this into a guitar case in the future. And you're like, okay. So if I open this up, then you're gonna leave a little note maybe that says, yeah, when you open this up, please put it into a guitar case. Maybe after it's been opened 10 times, you say something like, take it to the guitar shop to get tuned. That's a covenant. It's like you open up these treasure tests, and then you find something that maybe has some additional restriction of what you can do with it, and that's maybe a little bit heady, but you can imagine in Bitcoin we would have something like, hey, open this up and then move it, and then after you've moved it you have 6 months before some other action can happen. Once you take that action, you have a 2 week grace period, that type of thing when because we're only thinking about Bitcoin. You can't transact Jimmy Hendrix's guitar on the blockchain. I I like that analogy. You have to put a guitar in a guitar good guitar case that's kinda like provisioning it. Did you Hello? Hello? Hello?
1592
02:07:34.755 --> 02:07:38.135
1593
02:07:38.595 --> 02:07:55.615
1594
02:07:56.950 --> 02:07:58.490
And and what you missed is,
1595
02:07:59.030 --> 02:08:05.050
Jimmy Hendrix guitar case. The the analogy here is if I give you this guitar, then you have to put it in a guitar
1596
02:08:05.405 --> 02:08:15.890
1597
02:08:16.270 --> 02:08:26.395
And, you know, rather than just, like, you know, gold coins that you could take out of your treasure chest and put into another treasure chest of your choosing, you You gotta keep it in something that has a special format. So is this I mean,
1598
02:08:27.175 --> 02:08:29.515
1599
02:08:29.930 --> 02:08:36.750
which are, like, non fungible tokens. Right? So how are you gonna take Bitcoin and make it look like a guitar?
1600
02:08:37.050 --> 02:08:37.550
Like,
1601
02:08:38.105 --> 02:08:56.525
you know, like, like, why you know, the nice thing about Bitcoin is every Bitcoin is a Bitcoin. Right? Like, you can exchange 1 Bitcoin with another person. We call that fungible because you know that when you get Bitcoin it's the same as, like, any other Bitcoin and all Bitcoin is, like, pretty much equal. Right? So I'm willing to transact on Bitcoin
1602
02:08:56.905 --> 02:08:59.885
because I know that I'm gonna get Bitcoin in return. Right?
1603
02:09:00.185 --> 02:09:05.020
Like, if you're turning Bitcoin into guitar, like, how does Bitcoin become a guitar, 1?
1604
02:09:05.320 --> 02:09:28.935
1605
02:09:29.475 --> 02:09:41.040
maybe there should be some time out period where I can say I'm not actually dead. And that would be more like, you know, there's some restriction on that. But why are you giving your money your Bitcoin to your spouse, Jeremy? Like, I don't have a spouse. I see. Thanks.
1606
02:09:41.580 --> 02:09:48.445
1607
02:09:52.105 --> 02:09:56.190
1608
02:09:56.570 --> 02:09:57.070
Like,
1609
02:09:57.610 --> 02:09:59.390
Bitcoin script is,
1610
02:09:59.850 --> 02:10:03.275
like, complicated. We have this opcode called op check sig
1611
02:10:03.915 --> 02:10:12.015
which allows which is most fundamental opcode to Bitcoin where you check a signature, then the transaction has valid signature with respect to
1612
02:10:12.540 --> 02:10:13.760
the given public key.
1613
02:10:14.220 --> 02:10:16.640
And by its nature, this opcode
1614
02:10:17.020 --> 02:10:19.520
relies on some data from the transaction itself.
1615
02:10:20.204 --> 02:10:21.585
And in some way,
1616
02:10:22.844 --> 02:10:25.744
the the data from the transaction is available to the script.
1617
02:10:26.045 --> 02:10:31.410
And given all the different op codes we have today, there may be covenants may be possible.
1618
02:10:31.790 --> 02:10:33.730
We just don't know how to do them yet.
1619
02:10:34.750 --> 02:10:39.375
Good way might be to cleanly add support for covenants, but do we have covenants today or no?
1620
02:10:40.475 --> 02:10:51.640
I don't know. Like, for example, Andrew Postra has a good blog post on if you just had op cat, which is looks like a simple op code where you just add 2 concatenate 2 elements on stack,
1621
02:10:52.260 --> 02:10:54.200
with that, you can have covenants. Like,
1622
02:10:54.615 --> 02:11:05.830
1623
02:11:06.450 --> 02:11:13.875
that like, a a lock time, check lock time verify, or check sequence verify, in my opinion, are a covenant because it's saying here's a coin
1624
02:11:14.175 --> 02:11:22.100
that you can only spend after a certain amount of time. So it's something beyond just who the owner is about how the coin can be spent. I would consider that a covenant. The
1625
02:11:22.480 --> 02:11:28.305
thing that we're that we're talking about when we say we're not sure and we usually shorthand covenants for this is covenants that really restrict
1626
02:11:28.785 --> 02:11:30.485
where you can spend the coin to,
1627
02:11:31.345 --> 02:11:32.485
not just the how.
1628
02:11:32.865 --> 02:11:33.365
And,
1629
02:11:34.065 --> 02:11:37.285
that yeah. We don't know. As far as I can tell, we don't have them
1630
02:11:37.790 --> 02:11:44.050
1631
02:11:44.670 --> 02:11:46.050
covenants, by definition,
1632
02:11:47.125 --> 02:12:03.680
1633
02:12:04.005 --> 02:12:16.489
1634
02:12:17.110 --> 02:12:27.175
in how they can spend. Right? Mhmm. And, yeah, and you can do covenants with some additional codes like checks not tricks, but the entry barrier of that doing that is extremely high. Right?
1635
02:12:27.795 --> 02:12:33.980
But, you know, covenants, in short, is pre committing to a transaction in advance of creating address. Right? In short.
1636
02:12:35.000 --> 02:12:43.035
And I think from what I, like, observe from the community, I think we'll get there at some point. Right? But the question is really in what capacity?
1637
02:12:43.735 --> 02:12:46.875
We we are seeing many competing ideas and proposals,
1638
02:12:47.335 --> 02:12:49.195
and more and more to come. Right?
1639
02:12:49.530 --> 02:12:53.070
But, you know, each proposal have a different level of complexity
1640
02:12:53.370 --> 02:12:54.510
and, you know, flexibility.
1641
02:12:55.370 --> 02:13:00.515
You know, each have their own trade offs. It will be interesting to see which ones pay the way for Bitcoin.
1642
02:13:01.054 --> 02:13:03.235
1643
02:13:03.695 --> 02:13:06.355
that for covenants? I I know, what, in
1644
02:13:06.780 --> 02:13:15.760
2013 or some some Greg Maxwell made a post back in the day. There's been I don't know if that was quite a proposal, more of just an idea, but what proposals currently exist today
1645
02:13:16.275 --> 02:13:19.095
that are covenant proposals, I guess, you could say?
1646
02:13:19.955 --> 02:13:26.120
1647
02:13:26.840 --> 02:13:35.395
there are a lot of I think one thing that's important to understand when we say the word proposal, it means different things. So there is a BIP, which is a Bitcoin improvement proposal,
1648
02:13:36.014 --> 02:13:39.554
and that is a proposal that is it is, like, very structured,
1649
02:13:40.179 --> 02:13:45.159
and, they can be at different levels of readiness. And so when you talk about a proposal,
1650
02:13:46.179 --> 02:13:53.565
there's also a sort of idea, right, of, hey. What if we did this? So there are a lot right now of what if we did this's.
1651
02:13:53.945 --> 02:13:56.765
And as far as I'm aware, there's only, like, one
1652
02:13:57.270 --> 02:14:03.369
or maybe 2 things that are kind of more on the side of, like, here is a concrete thing that we could do.
1653
02:14:03.670 --> 02:14:09.534
So in the the scope of things that are, like, here are ideas, people are talking about what if we added, like,
1654
02:14:09.914 --> 02:14:10.414
a
1655
02:14:10.875 --> 02:14:20.400
language that itself in scripting was maybe, you know, like a lisp or some sort of, like, actual programming language to Bitcoin, then we could compute
1656
02:14:20.795 --> 02:14:40.565
any arbitrary covenant we ever could want. We could say all the possible covenants we could express. That's something people are thinking about, but nobody has, like, a code sample that you could run and try with. And then, there are some maybe, like, application specific covenants that are, like, rather than this big general purpose thing. Like, what if we just had a covenant that let us manipulate
1657
02:14:40.945 --> 02:14:56.065
Tapscript and manipulate the tree that we've seen? There's one called Taplyk update verify that people are getting maybe a little excited about. There are some other ones people have talked about as well, but all those things are kind of in the space of, hey. I've got a cool idea. Don't know exactly what it would look like.
1658
02:14:56.605 --> 02:15:00.945
The the 2 that have, some potential for covenants that are in the more concrete
1659
02:15:01.390 --> 02:15:01.890
phase
1660
02:15:02.270 --> 02:15:05.090
where it's something maybe that could be considered for merging,
1661
02:15:05.390 --> 02:15:25.490
and activation at some point in the next, like, year or 2 would be check template verify, which is the proposal that I work on. And Anyprevent, which is one that is in the Lightning community primarily, but has applications for covenants that are not, like, if you said we can remove covenants from any prevout, the Lightning community probably would do it because they're focused on it for a different application. So it's sort of a side effect.
1662
02:15:26.830 --> 02:15:29.155
And so for Check Template Verify,
1663
02:15:30.495 --> 02:15:32.995
I like covenants, and I think that generally covenants
1664
02:15:33.455 --> 02:15:47.605
are something we should explore, But a lot of people in the community, like Greg Maxwell in this original post where he shared it, had a lot of reservations around, are covenants good? Are they bad? Can they have bad, you know, bad things happen? And so when I designed CTV in 2019,
1665
02:15:48.545 --> 02:15:52.805
I said, can I make a covenant that is the simplest possible thing that
1666
02:15:53.150 --> 02:15:54.930
that basically if you don't
1667
02:15:55.230 --> 02:16:07.255
want CTV, then you will not want any covenant system ever, at least in terms of functionality? Maybe you'll disagree from a product management point of view. But if you say, CTV is bad, here's why CTV is bad, then we can rule out all covenants forever.
1668
02:16:07.555 --> 02:16:41.035
But if you're like, CTV is good, like, well, we'll get something done maybe, and then we can talk about the more sophisticated things. So so it's like CTV is, like, the smallest unit of covenant where it's like, hey. If we can prove that this is bad, then we know covenants are bad. But if this is good, there might be more opportunity. Yeah. I I think that's how I would describe it. And just in terms of, you know, like, the doneness of the proposal, it it is in a form where, like, you could merge, activate, and release it, you know, starting now if you wanted to. So it's more in the category of product management decision rather than there's still an engineering question around how would we actually implement this thing.
1669
02:16:42.774 --> 02:16:59.694
1670
02:16:59.995 --> 02:17:02.734
I'm not totally I think covenants are cool
1671
02:17:04.020 --> 02:17:07.561
technically. There's literally cool stuff I think that they enable
1672
02:17:08.101 --> 02:17:13.561
but I'm not totally sold that we need to make Bitcoin more complicated and add more
1673
02:17:14.165 --> 02:17:16.904
ways of making it harder to spend bitcoin.
1674
02:17:18.245 --> 02:17:23.225
So maybe I think there's 2 things here is like, you know, there's much different proposals about how to do covenants.
1675
02:17:24.020 --> 02:17:28.120
I think maybe we could talk about, like, what's how accessible are these? Like,
1676
02:17:28.740 --> 02:17:37.835
how, like, in terms of, like, you know, like, is it are these things that like everyday bitcoiners are gonna are we gonna make it easier for the is this gonna make it easier for them to, like,
1677
02:17:38.695 --> 02:17:39.755
secure their bitcoin?
1678
02:17:40.056 --> 02:17:40.775
Is it like
1679
02:17:41.720 --> 02:17:43.880
I don't know. Yeah. Like, if like, why
1680
02:17:44.439 --> 02:17:48.300
1681
02:17:48.815 --> 02:17:56.755
like, beneficial use cases maybe, where y'all can talk about, like, one one that you're interested in, for instance, is security. Like, how how does this benefit us?
1682
02:17:57.135 --> 02:18:23.070
1683
02:18:23.610 --> 02:18:38.540
so that you can open it's a shared UTXO model. You can open, like, tons of channels as well. But I think when you wanna close them, you only close the channel you are interested in as opposed to CTV when you have to you have to declare all channels first to call some. But, anyway,
1684
02:18:39.340 --> 02:18:39.920
I think,
1685
02:18:40.380 --> 02:18:43.120
one other interesting use case of CTV is vaults.
1686
02:18:43.820 --> 02:18:46.235
You can, as well as channel factories again.
1687
02:18:46.716 --> 02:18:49.056
But I think, you know, overall, when you look at covenants,
1688
02:18:49.596 --> 02:18:53.855
everyone can benefit from it. Like, if you're a Lightning enthusiast, you can benefit
1689
02:18:54.421 --> 02:19:03.320
because it can bring l 2 to channel factories and noninteractive channel setups. If you're a self custody guy, great. It's for you. It's it's great for you. I mean, it could bring bring Vols to Bitcoin,
1690
02:19:04.056 --> 02:19:07.035
and I don't know, some sort of advanced self custody.
1691
02:19:07.575 --> 02:19:16.091
If you're, you know, Bitcoin scaling nerd, it's good for you. Maybe it could bring later on, you know, some points to Bitcoin, maybe trust those SPV side chains and us.
1692
02:19:16.471 --> 02:19:17.211
1693
02:19:17.591 --> 02:19:20.171
yeah, first responding to Lisa's question,
1694
02:19:21.085 --> 02:19:29.105
where, like, why are we adding this complicated stuff? So, like, definitely, it should be determined like, defined by what use case you're adding.
1695
02:19:29.410 --> 02:19:40.585
So in this case, we have some scaling benefits by proposals like coin pools where one UTX source would be this is not specific to check template verify or any single proposal, but with generally
1696
02:19:41.205 --> 02:19:47.109
some governance. Suppose we could have coin pools where you have one UTXO, which is controlled by multiple parties.
1697
02:19:47.729 --> 02:19:51.909
Like, if you imagine Bitcoin scaling to the world, we need some sort of coin pool proposals.
1698
02:19:52.705 --> 02:19:53.364
Then secondly,
1699
02:19:54.064 --> 02:19:54.465
vaults.
1700
02:19:55.024 --> 02:19:59.845
And I'd like to, like, distinguish between CTV vaults and more powerful vaults.
1701
02:20:00.385 --> 02:20:01.205
And I think,
1702
02:20:01.950 --> 02:20:02.510
like, for
1703
02:20:02.990 --> 02:20:05.090
at least for me, covenants are kinda
1704
02:20:05.470 --> 02:20:06.609
like the end game.
1705
02:20:07.069 --> 02:20:13.565
Like, I like, we need to have some sort of self custody solution more powerful than you
1706
02:20:14.185 --> 02:20:17.965
than what we have today. I would not be comfortable, like, storing
1707
02:20:18.351 --> 02:20:20.830
huge amount of Bitcoins in what we have,
1708
02:20:21.471 --> 02:20:25.570
like, in the recommended security setups today. For example, in
1709
02:20:25.905 --> 02:20:30.385
governance, which were suggested in the original paper by our favorite professor,
1710
02:20:32.226 --> 02:20:35.686
we had a design where even if you lose your cold keys,
1711
02:20:36.690 --> 02:20:38.311
you could still, like,
1712
02:20:38.931 --> 02:20:47.165
get in a race with the attacker and try to burn your phones. So that offers a new level of security, which we currently don't have with,
1713
02:20:48.265 --> 02:20:52.525
like, any form of governance. Or even with CDB, we don't get that form of security.
1714
02:20:53.181 --> 02:20:56.720
And so there are these new use cases which governance
1715
02:20:57.420 --> 02:21:01.760
enable that we that we don't get if we don't have them. Secondly,
1716
02:21:03.205 --> 02:21:18.710
it is often. That's the most fundamental part. Like, if people are using covenants, and if you're not using covenants, then it doesn't affect you. Like, new proposals, sure. They do affect you. You should care about a few things when new proposals are suggested. Like, is your full not doing more work than
1717
02:21:19.255 --> 02:21:23.515
what it is getting like, is are there any denial of service concerns,
1718
02:21:24.055 --> 02:21:25.034
about it? Maybe
1719
02:21:25.415 --> 02:21:32.329
like, you could do weird funky stuff with, covenants, but when we suggest proposals, we should make sure that, you know, those concerns
1720
02:21:32.869 --> 02:21:34.090
are addressed properly.
1721
02:21:34.470 --> 02:21:34.710
So
1722
02:21:35.825 --> 02:21:36.325
1723
02:21:37.104 --> 02:21:50.860
just just to kinda rephrase what we're talking about. I mean, we've talked about channel factories, so opening up thousands of channels in one transaction. Right now, if you open up a a channel on Lightning, that's one transaction. Right? So we we're we're talking about general scale.
1724
02:21:51.320 --> 02:21:52.301
We're talking about,
1725
02:21:53.000 --> 02:21:53.500
vaults,
1726
02:21:54.346 --> 02:22:00.365
which enable security. You you even said right now you don't feel comfortable with what's available. So you would actually
1727
02:22:01.760 --> 02:22:10.180
you you feel uncomfortable being a Bitcoin right now with the current technology is what is what you're saying, and and and you would feel more comfortable with vaults and and covenants that enable those things. So
1728
02:22:10.625 --> 02:22:22.119
1729
02:22:22.659 --> 02:22:47.450
And even if we're, like, coming up with better things in the long run, I would really like if the story that we have for every one of those users coming on is that we get them started with something that's more secure or more scalable. And I think that that's why I, at least, you know, people critique that I say maybe, like, urgency, but, like, I try to do these things with urgency because for every user coming in, I wanna give them the best that we know how to do. And the second point that I would make, which is like should we be adding more complexity,
1730
02:22:48.105 --> 02:22:53.885
is, you know, like, sorry. The complexity is already here and people are doing these things, but either in more centralized,
1731
02:22:54.186 --> 02:22:54.686
trusted,
1732
02:22:55.511 --> 02:22:56.971
trusted means not trustworthy,
1733
02:22:57.590 --> 02:23:00.811
maybe a linguistic quirk, but using a trusted party
1734
02:23:01.431 --> 02:23:01.931
ways,
1735
02:23:02.870 --> 02:23:12.165
and these things I think are just completely worse. So if the market's already adopting solutions like that, we should do something that reduces the amount of trusted parties required for things people are already doing. So
1736
02:23:12.705 --> 02:23:14.245
1737
02:23:15.060 --> 02:23:18.200
1738
02:23:18.580 --> 02:23:22.580
and some amount of, like, security or, like, functionality. Right? So,
1739
02:23:24.186 --> 02:23:29.485
yeah, I don't know. I no. I don't I don't know if I am totally convinced. It is opt in though. Right? Well, actually,
1740
02:23:29.865 --> 02:23:31.645
1741
02:23:33.051 --> 02:23:36.830
the the the protocol, for example, for opening up lightning channels with covenants is
1742
02:23:37.210 --> 02:23:49.436
simpler than the protocol for opening lightning channels without covenants. And so that's something where, actually, by having a slightly better technology, we can reduce complexity in other parts of the stack. So the overall complexity goes down. So I have a question for you, Lisa.
1743
02:23:51.220 --> 02:23:51.960
1744
02:23:52.500 --> 02:24:01.035
and maybe there's another way, but how do you how how can you open up and scale Lightning in terms of opening up a ton of channels without covenants? Is there another way?
1745
02:24:02.295 --> 02:24:05.755
1746
02:24:06.215 --> 02:24:06.615
Mhmm.
1747
02:24:07.250 --> 02:24:22.635
Which I I would say that's kinda simple in terms of, like, when people are in a channel, they understand what they own. It's a shared UTXO. Right? So maybe the complexity in opening it is a little hard, but the simplicity of what you own when you open a channel is very straightforward, I would say.
1748
02:24:23.780 --> 02:24:29.320
So, like, it's an on you know, it's on chain thing. You can go look it up on a block explorer. You can see where your channel funds are.
1749
02:24:30.580 --> 02:24:32.280
Yeah. So, like,
1750
02:24:32.645 --> 02:24:39.545
that's so it but that the limit on that then is that every channel open must be represented by an on chain
1751
02:24:40.085 --> 02:24:48.850
1752
02:24:49.455 --> 02:24:49.955
simplification?
1753
02:24:50.415 --> 02:24:54.415
1754
02:24:55.455 --> 02:24:56.755
when you create a channel,
1755
02:24:57.135 --> 02:24:58.755
let's say that there are,
1756
02:24:59.681 --> 02:25:19.005
the maximum is something around, like, 20,000 people trying to open channels in a given block. Like, it's it's probably a little bit less than that, probably more like 5,000 people trying to open up channels. Sure. Probably, like, 4 or 5000. Yeah. That would be, like, the maximum. Right? And then what's interesting is as soon as you have 5,001 people, you will now over a long time have an infinite list of people trying to open channels.
1757
02:25:19.370 --> 02:25:57.920
And so you end up in a world where everybody who wants a channel is now not gonna have a channel. They're gonna have to go to, like, a trusted service that says, yeah. We're not gonna rug you on opening this channel. And then that, you can't look up in a block explorer either because it's and then you might say, oh, well, we can only support this many users. So I would rather have a pathway to supporting a larger number of users where they have to do something slightly different than, say, we're bounded by this constraint of Bitcoin, and we can only support top tier users at this amount. And I think we can still support people who are willing to pay for that 5,000 per block space if they want it, but now we're able to grow the pie and support more users overall. So so the human humanitarian
1758
02:25:58.540 --> 02:26:02.395
1759
02:26:02.855 --> 02:26:04.855
1760
02:26:05.815 --> 02:26:07.035
1761
02:26:07.815 --> 02:26:11.000
1762
02:26:12.040 --> 02:26:20.540
and as long as what other people are doing with their UTXOs, you should only be concerned that it does not increase your verification costs, which can be evaluated per proposal.
1763
02:26:20.920 --> 02:26:34.880
1764
02:26:35.635 --> 02:26:45.335
1765
02:26:45.700 --> 02:26:46.520
more tooling and more,
1766
02:26:47.220 --> 02:27:03.870
like, ways to see, like, the visibility, etcetera. Right? So I think, like, adding adding cabinets is more like, you need more there's gonna be more we need more infrastructure for these things. Right? Yep. It's kind of what I think. We need more tooling for these kind of use cases.
1767
02:27:04.410 --> 02:27:06.330
1768
02:27:06.811 --> 02:27:12.305
and maybe this is, like, the magic of CTV as a covenant solution is that the thing that CTV expresses
1769
02:27:12.685 --> 02:27:24.650
is purely just a list of transactions that would get played in the future. And so there's no sort of really complicated infrastructural need for something like a Lightning node. All you have to do is say, okay. We're aware of these things that are pending transactions,
1770
02:27:25.030 --> 02:27:53.574
and we're able to see that they're CTV, so we can prove that they would happen in the future. And then you would just count those as fully confirmed rather than just sitting in the mempool unconfirmed. And that that's the only difference. For the more interpretive things, like, even things based in, like, any prevout or, like, those types of channel factories, well, then you've gotta, like, be, like, constantly, like, rebinding and scanning and things like that. And those have a lot more infrastructure requirements. But in terms of, like, an immediate migration path, we can, like, probably get something working pretty easily and then do the more complicated stuff in, like, the span of, like, decades or whatever.
1771
02:27:54.630 --> 02:27:59.370
1772
02:28:00.480 --> 02:28:02.705
1773
02:28:03.165 --> 02:28:05.345
a lot, but in like, I just like
1774
02:28:05.725 --> 02:28:06.945
to, like, you know, highlight
1775
02:28:07.325 --> 02:28:08.705
one of the things where,
1776
02:28:09.245 --> 02:28:10.790
like, I'm sort of,
1777
02:28:11.170 --> 02:28:14.069
trying to address to the crowd who think that
1778
02:28:14.609 --> 02:28:18.775
covenants or, in particular, some form of covenants are dangerous. And,
1779
02:28:19.716 --> 02:28:29.390
CTV in one proposal is, like, motivated by the design to avoid certain set of covenants, which we call as we don't have the time to get into it, but recursive covenants or unenumerated
1780
02:28:29.770 --> 02:28:30.270
covenants.
1781
02:28:31.050 --> 02:28:33.150
I think rather we should, as a community,
1782
02:28:33.610 --> 02:28:39.756
like, regardless we should have CTV or should not have CTV, we should try to address those concerns of people who are
1783
02:28:40.615 --> 02:28:41.115
against,
1784
02:28:41.655 --> 02:28:43.756
like, recursive covenant because they enable
1785
02:28:44.270 --> 02:28:46.110
new use cases, then,
1786
02:28:47.150 --> 02:28:52.290
like, c t it is independent of the issue of CTV, but I don't want the motivation for CTV to be,
1787
02:28:53.086 --> 02:29:01.426
oh, look. We are trying to avoid these dangerous things. The motivation can be, look. This is simpler. That's why we should do it. It's fine. But there are a lot of people who are advocating this because
1788
02:29:02.050 --> 02:29:03.510
they want to avoid something,
1789
02:29:04.850 --> 02:29:10.630
seemingly the dangers of recursive covenants. And if you refer back to the post from Greg Maxwell, you'd see that,
1790
02:29:11.364 --> 02:29:18.345
he does not say that there are dangerous thing. He actually chats in some way challenges everyone, like, what dangerous things can you do with governance?
1791
02:29:19.440 --> 02:29:54.025
1792
02:29:54.630 --> 02:29:55.449
with covenants?
1793
02:29:56.630 --> 02:30:11.905
1794
02:30:12.340 --> 02:30:21.475
And I think a fair thing that they can ask is, okay, it's not enough that you can say there's some argument that, like, these things aren't bad. Please prove to me that it's safe.
1795
02:30:21.955 --> 02:30:23.494
And until we get to that level
1796
02:30:23.875 --> 02:30:24.534
of sophistication,
1797
02:30:25.314 --> 02:30:29.895
I think that a more conservative approach is ultimately what the community wants,
1798
02:30:30.435 --> 02:30:30.935
and
1799
02:30:31.260 --> 02:30:38.479
I am trying to cater to the community more than I'm trying to do the thing that I want, even though I I might want something more personally.
1800
02:30:38.895 --> 02:30:55.279
1801
02:30:55.705 --> 02:31:25.820
just, like, tried to address a subset of community that said that this is not quantum secure, for example, and we modified the route to, you know, do something dangerous and try to get everyone in. We would not have this proposal that we have today. Instead, what we work towards is, like, addressing concerns of people like, look. Quantum computers are going to come tomorrow. And even if we have them, we have bigger problems. Right? So it's not a fair critique because that would also make a complicated solution where a CTV is simpler. So coming back to the point, I think we should, like,
1802
02:31:27.240 --> 02:31:28.380
suggesting the community,
1803
02:31:30.395 --> 02:31:45.485
like, a wrong idea might get like, might backfire in future. Maybe earlier people believed that Bitcoin is free and had businesses built on top of it. And maybe today people think that, you know, recursive covenants are not secured and that's why we are supporting this. I,
1804
02:31:45.806 --> 02:31:49.825
like, I think I agree that CDP is simple and that is a good enough merit, but
1805
02:31:50.285 --> 02:32:06.075
1806
02:32:06.455 --> 02:32:09.195
where you pass people being comfortable with CTV's functionality.
1807
02:32:09.575 --> 02:32:14.630
I agree with that. And then if that's true, the question becomes once we've surpassed that threshold,
1808
02:32:15.810 --> 02:32:30.904
how much time do we get to the point that we actually might want to go to, and then how many users come on board with, like, less secure, you know, custody solutions in the meantime between those two things. Why why would people be uncomfortable with this recursive stuff? Like, what are we what's the undiscomfort
1809
02:32:31.590 --> 02:32:32.250
1810
02:32:32.710 --> 02:32:34.490
like talking about here? So,
1811
02:32:34.950 --> 02:32:36.649
1812
02:32:37.430 --> 02:32:40.330
So this recursive covenants in particular,
1813
02:32:41.046 --> 02:32:48.360
they allow you to, like, wall guard on your coins. Maybe you can you can get into a covenant that you cannot escape out of.
1814
02:32:49.320 --> 02:32:59.075
And this, like yeah. This sounds dangerous. Right? Why would you put your coins into something which you cannot get out of? Like, you know, you're just We're not trying to make Bitcoin like Ethereum.
1815
02:32:59.455 --> 02:33:00.915
Yeah. Or maybe like you,
1816
02:33:01.295 --> 02:33:10.965
like one of the concerns is like just the US government goes to Coinbase and says put all your coins in this covenant, and it's a recursive covenant. So whenever you spend those coins, you need the signature of,
1817
02:33:11.925 --> 02:33:26.180
like, a cc. And whenever you want to transact you have to send a copy to them, and now they have everything. Why are we building this technology to help? That's a valid question. Right? And that's why people are scared. But the bad news is they can already do that today.
1818
02:33:27.085 --> 02:33:29.265
They can just do it with what we call multisync.
1819
02:33:29.645 --> 02:33:31.265
1820
02:33:31.645 --> 02:33:36.850
I was gonna say I think to address the question, I think it's like the idea of the recursiveness. It's like
1821
02:33:37.229 --> 02:33:51.315
you you pretty much have, like, a deadlock on that contract, which does what? Does that break Bitcoin, or does that just break that transaction? What does that actually do? Yeah. You know what I mean? So so I think that rec recursive is just, like, a little bit of a stand in for, like, hard to analyze.
1822
02:33:51.720 --> 02:33:57.180
1823
02:33:57.800 --> 02:33:58.300
And
1824
02:33:59.655 --> 02:34:43.355
that that I think is is why, like, for for for certain purposes, something like CTV is okay because it's very easy to analyze. So we're saying, okay. The analyzability of this is very basic. So we could say we know all possible state transitions. We're good. For me, the concern with recursiveness is that when you have these more flexible things, like, you might not have properly proved that the covenant is actually correct and there might be some sort of like Ethereum has these things with, like, you know, recursive reentrant, you know, contracts where you call the thing and then you call into the thing and then the number doesn't get updated properly and then you burn all the money or you steal the money. And those are the at least from my perspective, those are the types of issues that our ability to prove and reason about these things. Like, we would need a lot better tooling and infrastructure to do it, safely. So so so no loops are,
1825
02:34:43.730 --> 02:34:59.965
like, enabled? Is that, like, a easy layman way of Yeah. No loops. It's you gotta know the entire Yeah. You you know the you know the Yeah. The whole span of the tree of possible states. And and that's a huge trade off to get that analyzability. There are other things that also might have some similar analyzability, but are more flexible.
1826
02:35:00.345 --> 02:35:02.910
But on all the choices, I just did conservative,
1827
02:35:03.450 --> 02:35:16.355
for this. And, you know, I I do think the conversation and defining the properties and not just having, like, one big stand in of recursive bad, you know, like, is is really important, but it's the analyzability I think is really the the thing we need. Yeah. So we can have analyzability
1828
02:35:16.735 --> 02:35:22.800
1829
02:35:23.600 --> 02:35:35.240
They should know if they're shooting themselves in the foot. That's that's, I think, the thing. Right? Yeah. If you if you are dealing with these type of things, you should know. Like, for example, there are, I think, could be things in lightning contracts which you can mess up. Right?
1830
02:35:36.440 --> 02:35:39.020
So, like You would hate that. Yeah.
1831
02:35:40.280 --> 02:35:42.061
So whenever you're dealing with scripts,
1832
02:35:42.695 --> 02:35:47.195
you can mess up. It's just the the thing sounds scary. It's like if you mess up, your coins are gone forever.
1833
02:35:47.655 --> 02:35:51.275
There are also similar, like, risks associated with smart contracts today.
1834
02:35:51.600 --> 02:36:05.125
So it isn't that we are adding some new thing which was not, like, some new attack vector which was not present today. And as I mentioned, like, for example, using maybe just a single signature today with music, maybe covenants are already on the way. Like, we
1835
02:36:05.585 --> 02:36:09.450
1836
02:36:14.263 --> 02:36:14.763
with
1837
02:36:19.155 --> 02:36:31.860
just with people enforcing it, and if you've got automated things running this, it's just a question of like, is it the Bitcoin blockchain shooting you in the foot, or is it the automated services you have that are doing it? And I think for an end user, it might not be terribly different.
1838
02:36:32.240 --> 02:36:38.585
The the the covenants and this is similar to what we said earlier. It would just be like while we're shifting it to something that requires less signatures.
1839
02:36:39.205 --> 02:36:55.955
1840
02:36:56.915 --> 02:36:59.495
so Lightning Labs just released this thing
1841
02:36:59.796 --> 02:37:05.730
that they're gonna add to the annexes of Taproots, which is like a whole new UTXO tree
1842
02:37:06.351 --> 02:37:08.610
and, like, a whole new scripting language,
1843
02:37:09.631 --> 02:37:10.770
this thing called tarot.
1844
02:37:11.551 --> 02:37:12.530
Is that a covenant?
1845
02:37:13.065 --> 02:37:35.625
Like, maybe this is too I know it just got announced yesterday. You guys haven't had a chance to look into it. Is that are those covenants? It's like coloring it's kinda like coloring Bitcoins. Right? Is that is that does that count as covenants? Has, like, labs, like, basically launched covenants on Bitcoin already with their Taro stuff and their color coin things? Or is this stuff that we're talking about covenants wise, like, totally different?
1846
02:37:37.030 --> 02:37:41.610
1847
02:37:42.870 --> 02:37:51.016
you've been you haven't been doing any talking on this panel. Why don't you go ahead and Yeah. Also, I know I've talked too much, so like that's fine, like hopefully one of you had read it, but I've read it. So,
1848
02:37:52.695 --> 02:37:54.395
I would answer that
1849
02:37:54.830 --> 02:37:55.649
it is not
1850
02:37:56.189 --> 02:37:56.689
Bitcoin
1851
02:37:56.990 --> 02:38:02.905
validated covenants. It is client side validated covenants, which means that you're free
1852
02:38:03.285 --> 02:38:06.425
to if you own one of these things, you can definitely
1853
02:38:06.885 --> 02:38:07.385
burn
1854
02:38:08.085 --> 02:38:17.289
all the coins, and that will, you know, escape because you've just messed it up. Mhmm. But if you're running the the software, you will generate artifacts that somebody else could verify.
1855
02:38:18.149 --> 02:38:24.604
And that and, also, also, just a technical note, they're not in the annexes, which is important for something. But, anyways, they're
1856
02:38:25.785 --> 02:38:26.185
they are
1857
02:38:27.200 --> 02:38:37.226
they they internally can have their own covenants and things, but there's always a top level clause which says basically, well, you're free to mess it up if you want to. And so Bitcoin does not have covenants, but in their system,
1858
02:38:37.605 --> 02:38:52.466
1859
02:38:53.006 --> 02:38:53.506
as
1860
02:38:54.086 --> 02:38:54.586
of
1861
02:38:55.165 --> 02:38:57.346
infra- inside, like, the Bitcoin infrastructure
1862
02:38:57.726 --> 02:39:03.390
itself is that now we can express things about Bitcoin, like your Bitcoin
1863
02:39:04.010 --> 02:39:05.310
hoard so to speak,
1864
02:39:06.010 --> 02:39:09.865
whereas adding stuff like the project that Lightning Labs announced,
1865
02:39:10.565 --> 02:39:13.545
doesn't give you that level of control is my understanding.
1866
02:39:13.925 --> 02:39:17.760
1867
02:39:18.140 --> 02:39:31.556
put a cherry on top of in terms of the devil's advocate stuff for CTV or whatever, I I just wanna include Barak here just a little bit here. I know I know you're currently using blockchain product liquid. Yes. What is something like CTV potentially missing
1868
02:39:32.000 --> 02:39:45.515
that you would wanna see? Or or what where how are you using covenants? Or how are you using liquid where it's maybe not even gonna be satisfied by some of the stuff? Oh, yeah. I think we can I just wanna Yeah? We can already, I think, emulate CTV in to some extent in the element subcodes, but I think
1869
02:39:45.895 --> 02:39:50.830
1870
02:39:51.230 --> 02:39:53.971
the channel factories, for instance, in 1 byte
1871
02:39:54.645 --> 02:39:57.225
as opposed to, you know, 100 lines of bytes. Right?
1872
02:39:58.165 --> 02:40:09.131
I think, you know, elements of codes, right, are less controversial to maybe to bait pay it on some of them to pay the bill for Bitcoin because they are pretty much not well tested yet, but they're being tested.
1873
02:40:09.591 --> 02:40:14.905
And elements is based on a Bitcoin core code base and I think are less less controversial
1874
02:40:15.285 --> 02:40:25.660
to my observation. Like, things like c from stack for checking arbitrary signatures and caps, like data manipulations. And maybe some arabatics, right, could maybe potentially come to Bitcoin.
1875
02:40:26.520 --> 02:40:32.540
But I think CTV, I think, is really simple. Right? And from what I observed, like, from the community,
1876
02:40:33.596 --> 02:40:38.895
people don't really Bitcoiners don't really want these highly expressive, I mean, very complicated
1877
02:40:39.275 --> 02:40:41.296
proposals. Right? They rather
1878
02:40:42.260 --> 02:40:54.415
powerful yet simple proposals. And I think, you know, when you think about it, covenants, this whole thing is really a spectrum. Right? I think CTV per I mean, it fits really in this middle of the spectrum. Right?
1879
02:40:54.955 --> 02:41:03.279
Whereas, you know, we could have, very expressive stuff, on the high high end of the spectrum, but it doesn't really make sense to, you know, merge into Bitcoin.
1880
02:41:03.979 --> 02:41:05.039
1881
02:41:05.510 --> 02:41:06.010
1882
02:41:06.635 --> 02:41:13.215
60 seconds or less, what does CTV need to cross into Bitcoin? What does it need going forward?
1883
02:41:13.811 --> 02:41:15.430
Maybe you can talk a little bit about that
1884
02:41:15.970 --> 02:41:18.710
1885
02:41:20.130 --> 02:41:29.414
This is kinda the best effort that I'm doing, which is just, like, making sure more people in the community want it, and if anybody doesn't want it, they express in a coherent way what their opposition is.
1886
02:41:29.795 --> 02:41:31.910
Right now, there's, like, a 130
1887
02:41:32.770 --> 02:41:42.345
people in organizations who have been, like, yeah. Seems good. There's, like, 2 people or 3 people who've been, like, I don't want it because I think we have enough to work on with Taproot.
1888
02:41:43.045 --> 02:41:50.425
That's been the main, you know, kinda complaint. I think there are other people who might say they don't want it for various reasons. They like, I would really like to see more people
1889
02:41:50.760 --> 02:41:59.580
give one of these things like, oh, we don't want top group because of quantum things so that we can actually rebut the arguments. If you don't make the argument in the, you know, right forum, then it can't be rebutted.
1890
02:41:59.915 --> 02:42:09.295
And then beyond that, I just need to do, like, a a binary release and pick some parameters, and that's it. You know? And it's like then the community can decide to signal for it. We'll do a soft fork just like Taproot.
1891
02:42:10.681 --> 02:42:17.580
1892
02:42:18.275 --> 02:42:21.495
show how people can contact you, your Twitter, whatever.
1893
02:42:22.515 --> 02:42:25.415
Lisa, we can start, and we'll work together. I'm on Twitter at nifty,
1894
02:42:25.720 --> 02:42:28.060
1895
02:42:28.600 --> 02:42:30.779
Also work on core lightning. That's core_ln.
1896
02:42:31.720 --> 02:42:32.955
So I'm just there.
1897
02:42:33.355 --> 02:42:36.895
1898
02:42:37.675 --> 02:42:41.775