Nov. 12, 2022
CD79: lightning development, bugs, and the path forward
EPISODE: 79
BLOCK: 762763
PRICE: 5945 sats per dollar
TOPICS: recent lightning bugs, impact, responsible disclosures, adversarial environment, tradeoffs, path forward
GUESTS: @brqgoo, @thebluematt, @benthecarman, @evankaloudis, @seardsalmon, and tony g
support dispatch: https://geyser.fund/project/citadel
twitch: https://twitch.tv/citadeldispatch
youtube: https://www.youtube.com/@citadeldispatch
bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos
podcast: https://www.podpage.com/citadeldispatch
telegram: https://t.me/citadeldispatch
stream sats to the show: https://www.fountain.fm/
join the chat: https://matrix.to/#/#citadeldispatch:bitcoin.kyoto
00:33 - Introduction
01:10 - Supporting the podcast through podcasting 2.0
03:11 - Introduction to the panel and topic of discussion
46:49 - The default values and configuration options for HTLCs and commitment outputs
48:49 - The process of responsible disclosure and how to proceed when discovering a bug
01:34:14 - Responsible disclosure and user risk
01:36:32 - Vendor approach to disclosure
01:39:47 - Duty of care and disclosure
01:49:01 - The importance of responsible disclosure and communication in the lightning network
WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 3/25/2024 10:10:55 PM
Duration: 6541.427
Channels: 1
1
00:00:33.250 --> 00:00:39.190
Happy Bitcoin Friday, freaks. It's your boy, Odell, here for another Citadel Dispatch.
2
00:00:40.285 --> 00:00:40.945
Citadel Dispatch
3
00:00:41.325 --> 00:00:45.505
is a interactive live show about Bitcoin and Freedom Tech.
4
00:00:45.885 --> 00:00:47.905
We have no ads, no sponsors.
5
00:00:48.680 --> 00:00:49.180
It
6
00:00:49.560 --> 00:00:54.620
is only possible thanks to our great listeners who continue to support the podcast,
7
00:00:55.320 --> 00:01:00.775
whether that's with stats through podcasting 2.0. Podcasting 2.0 allows you to just
8
00:01:01.715 --> 00:01:02.775
download an app.
9
00:01:03.155 --> 00:01:05.175
Big ones are fountain podcast, Breezewallet,
10
00:01:05.530 --> 00:01:06.030
podverse.fm,
11
00:01:06.890 --> 00:01:07.390
echoln.com,
12
00:01:08.409 --> 00:01:09.229
and others.
13
00:01:10.250 --> 00:01:14.670
You download the app. You load it up with stats. You search Siddle Dispatch. You press subscribe.
14
00:01:15.325 --> 00:01:20.305
Choose how many sats per minute you think this show is worth, and then those sats automatically,
15
00:01:21.725 --> 00:01:28.780
get streamed directly to my lightning node. It is extremely cool seeing all the sats come in. You can also
16
00:01:29.479 --> 00:01:30.520
support the pod,
17
00:01:30.920 --> 00:01:33.740
through podcasting 2.0 through something called boostograms.
18
00:01:34.345 --> 00:01:36.205
Boostagrams are a single payment
19
00:01:36.585 --> 00:01:39.645
that include a comment or message with,
20
00:01:40.345 --> 00:01:42.925
the payment. I read the top 4 Boostagrams
21
00:01:43.610 --> 00:01:44.909
from the last episode.
22
00:01:45.850 --> 00:01:48.270
Every week, it's really great to see,
23
00:01:49.610 --> 00:01:51.150
your comments and your support.
24
00:01:51.665 --> 00:01:55.205
Before I read those Boostagrams, you can also support the show by going to sidildispatch.com/contribute.
25
00:01:57.104 --> 00:01:58.965
I have a BTC pay server there.
26
00:02:00.040 --> 00:02:04.700
You can support that using that either via via Onchain or Lightning.
27
00:02:05.400 --> 00:02:08.865
And I also have my BIP 47 payment code there,
28
00:02:09.565 --> 00:02:17.105
which you can support via Samurais or Sparrow wallets, and, that's attached to the associated pay name, Odell. Very easy to remember.
29
00:02:17.440 --> 00:02:20.260
I know it's a bear market. You can also support the show
30
00:02:20.640 --> 00:02:23.060
by simply sharing it with friends and family.
31
00:02:23.520 --> 00:02:26.180
Citadel dispatch is available on all major platforms,
32
00:02:27.205 --> 00:02:28.505
every podcast app,
33
00:02:28.885 --> 00:02:29.385
Twitch,
34
00:02:29.845 --> 00:02:30.905
Twitter, YouTube,
35
00:02:31.925 --> 00:02:36.030
Rumble, Bitcoin TV. You just search Citadel Dispatch, press subscribe, reviews help
36
00:02:36.330 --> 00:02:37.070
as well.
37
00:02:39.130 --> 00:02:44.190
Yeah. So thank you for your support, Freaks. I really do appreciate it. The show would not be possible
38
00:02:45.125 --> 00:02:45.865
without it.
39
00:02:46.325 --> 00:02:50.105
I also wanna thank the Freaks who joined us in the live chat.
40
00:02:50.805 --> 00:02:54.505
You're able to join the live chat either via YouTube or Twitch
41
00:02:55.030 --> 00:02:55.690
or Twitter
42
00:02:56.230 --> 00:02:57.530
or via Matrix.
43
00:02:57.910 --> 00:02:58.970
We have a Matrix
44
00:02:59.270 --> 00:03:00.890
chat that runs 247,
45
00:03:01.430 --> 00:03:01.930
365.
46
00:03:02.985 --> 00:03:08.125
Lot of great conversation there on and off the show. You can find links to all of these things
47
00:03:08.745 --> 00:03:10.205
at citadel dispatch.com.
48
00:03:11.569 --> 00:03:12.870
So with all that said,
49
00:03:14.050 --> 00:03:16.709
we have a great panel lined up.
50
00:03:17.410 --> 00:03:20.790
It's been about a week and a half in the making.
51
00:03:21.425 --> 00:03:25.845
We've been trying to get it out there ASAP because it's a very important topic.
52
00:03:26.145 --> 00:03:28.645
Ironically enough, in classic Bitcoin fashion,
53
00:03:30.090 --> 00:03:33.630
a bunch of things have happened over the last week as many of you are known.
54
00:03:34.010 --> 00:03:36.270
And, you guys might forget that
55
00:03:38.254 --> 00:03:40.114
that we had 2 major,
56
00:03:40.575 --> 00:03:44.834
lightning bugs over the last month or so, maybe, like, last 2 months,
57
00:03:45.375 --> 00:03:46.674
with one of them happening
58
00:03:47.360 --> 00:03:59.435
last week where we all had to update our l and d notes. So this topic will be focused on that plus lightning development going forward and just the current state of lightning development. Before I introduce our guests, I just wanna read the boostograms,
59
00:03:59.735 --> 00:04:00.955
the top 4 boostograms
60
00:04:01.334 --> 00:04:04.075
from last week. Once again, thank you, Freak, for your support.
61
00:04:04.549 --> 00:04:06.090
We have at Humble Pleb,
62
00:04:06.950 --> 00:04:08.489
gave 69 420.
63
00:04:10.069 --> 00:04:10.569
Nice.
64
00:04:11.564 --> 00:04:17.905
69 420 sats. I don't know. It looks like he tried to put some kinda emoji there that I can't read on Android,
65
00:04:18.925 --> 00:04:30.665
a bunch of times. Appreciate you, Freak. We have Eric 99 with 50,000 sats saying, stay humble, stack sats. Great advice. We have Chad Farrell with 50,000 sats saying, thanks for all that you do, Matt. And we have 8,
66
00:04:32.005 --> 00:04:32.825
with 7,778
67
00:04:34.165 --> 00:04:34.665
saying,
68
00:04:38.139 --> 00:04:39.680
I've been listening to a new
69
00:04:40.139 --> 00:04:49.985
privacy podcast, Watchmen Privacy. It could be interesting for you to appear on this pod or vice versa. He has a strong Bitcoin focus in his podcast when speaking on cryptocurrencies, which is rare for privacy gurus.
70
00:04:50.365 --> 00:04:51.985
His past guests include NVK,
71
00:04:52.445 --> 00:04:58.889
LOP, Zelco, s 21, Seth for privacy, Bitcoin q and a, and Eco. Wow. I'll go check that out. It was not on my radar.
72
00:04:59.430 --> 00:05:05.615
Appreciate you, Freaks. And, also, we have Vic in here, honorary mention with 5,000 sats. Right or die freak. Appreciate you, Veek.
73
00:05:06.875 --> 00:05:13.199
So thank you, Freaks, for supporting the show. We have Tony jumping in and out trying to troubleshoot. Tony, can you hear me?
74
00:05:16.060 --> 00:05:17.599
We cannot hear you, Tony.
75
00:05:18.575 --> 00:05:21.395
So I'm gonna introduce our guests. We have
76
00:05:23.695 --> 00:05:29.030
a long time listener and often guest of the podcast, Ben Carmen. How's it going, Ben?
77
00:05:34.290 --> 00:05:35.510
Can't hear you, Ben.
78
00:05:37.505 --> 00:05:38.005
Classic.
79
00:05:39.185 --> 00:05:44.005
We have Barack who I had the pleasure of meeting in Miami on the open source stage,
80
00:05:44.385 --> 00:05:45.685
that I helped coordinate.
81
00:05:46.300 --> 00:05:50.480
Barak was the one who discovered the last two lightning bugs. How's it going, Barak?
82
00:05:51.180 --> 00:05:55.040
Yo. Hey. I can perfectly hear you. Hopefully, you guys can hear me too.
83
00:05:55.485 --> 00:05:57.505
Yes, sir. We can hear you. You rejoined.
84
00:05:58.205 --> 00:06:00.384
Yo. Hey. So, yeah, my name is.
85
00:06:01.565 --> 00:06:05.330
So I'm a Bitcoin dev. I mostly do some stuff on Liquid,
86
00:06:06.030 --> 00:06:08.290
and recently discovering Lightning Space.
87
00:06:09.310 --> 00:06:14.694
So I'm also known as the LND slayer, and I'm this bug eating this burger eating guy on Twitter.
88
00:06:15.235 --> 00:06:20.455
And happy to be here, guys, and add some you know, maybe give some details on what have happened,
89
00:06:21.770 --> 00:06:25.550
over the last few weeks and, you know, give some inputs and, you know,
90
00:06:25.930 --> 00:06:33.025
I'm not here to tell, you know, to tell whether my actions were good or bad. I think it's up to community to tell and, but I I can't tell you guys,
91
00:06:33.725 --> 00:06:36.065
what did happen and what my motive was.
92
00:06:36.445 --> 00:06:36.945
So,
93
00:06:37.860 --> 00:06:38.819
happy to be here.
94
00:06:39.539 --> 00:06:42.360
Hopefully, this is gonna be a a friendly conversation.
95
00:06:43.060 --> 00:06:44.360
Thank you for joining, Barak.
96
00:06:45.845 --> 00:06:47.225
We got Evan Kaludis,
97
00:06:48.325 --> 00:06:52.745
also rider die freak, common common guest on the podcast. How's it going, Evan?
98
00:06:53.125 --> 00:06:54.905
Hey. Great, Matt. How are you doing today?
99
00:06:55.630 --> 00:06:59.890
Doing doing great. Doing great. Yeah. Happy to be back on the show.
100
00:07:00.350 --> 00:07:03.570
Wish we were talking about a more positive topic,
101
00:07:03.884 --> 00:07:17.509
But, nonetheless, I think we're gonna have some, you know, great, very important discussion today. Well, compared to all the other podcast topics of insolvent exchanges and people losing their life savings, I feel like focusing on lightning development is a very positive topic.
102
00:07:20.055 --> 00:07:21.835
You know, when it's not getting attacked,
103
00:07:22.775 --> 00:07:23.275
unnecessarily,
104
00:07:23.815 --> 00:07:28.730
but, we'll get to that soon. Fair enough. Thank you, Evan. We have Matt Corallo.
105
00:07:29.430 --> 00:07:35.735
He's been on the podcast before and also has joined me with Marty on TFTC. How's it going, Matt?
106
00:07:36.534 --> 00:07:38.875
Pretty good. Pretty good. Thanks for allowing me on.
107
00:07:39.895 --> 00:07:41.914
And, Matt is, very,
108
00:07:43.390 --> 00:07:47.250
what's your what's your role at LDK? What would I call your role at LDK?
109
00:07:49.950 --> 00:07:52.290
I don't know. I work on it like everybody else.
110
00:07:53.275 --> 00:07:55.695
Matt works on LDK like everybody else.
111
00:07:56.155 --> 00:07:59.535
LDK is one of, one of the top lightning implementations.
112
00:08:00.690 --> 00:08:01.490
We have,
113
00:08:01.889 --> 00:08:03.430
Vivek here, also
114
00:08:04.129 --> 00:08:06.710
repeat guest on the podcast. How's it going, Vivek?
115
00:08:08.025 --> 00:08:08.765
It is
116
00:08:09.545 --> 00:08:10.365
going well.
117
00:08:11.705 --> 00:08:12.445
Just this
118
00:08:13.065 --> 00:08:13.565
and,
119
00:08:14.265 --> 00:08:15.245
yeah, explore
120
00:08:16.620 --> 00:08:18.639
is, and and
121
00:08:18.940 --> 00:08:19.419
what
122
00:08:22.915 --> 00:08:25.415
Yeah. So Vivek's Internet connection is horrible.
123
00:08:26.355 --> 00:08:29.655
It's probably because he stopped paying it because of the bear market.
124
00:08:31.099 --> 00:08:33.440
I don't know how we can fix that, Vivek.
125
00:08:33.899 --> 00:08:34.640
We have
126
00:08:35.260 --> 00:08:38.560
who did I not introduce? Tony. Can we hear you now?
127
00:08:38.995 --> 00:08:42.615
Can you? Yeah. We can. Long time since this is a podcast.
128
00:08:43.315 --> 00:08:44.215
How's it going?
129
00:08:44.755 --> 00:08:59.125
I'm good. I'm good. I'm excited to be here. I'm trying to refresh my memory on what happened, but other than that, I'm happy to be here and talk about this. So, Tony I mean, if if you have been listening to dispatch, you know what Tony's been up to. He's been working on basically
130
00:08:59.665 --> 00:09:00.725
attacking lightning,
131
00:09:01.825 --> 00:09:04.405
and he has this new tool called Ellen's Ploit,
132
00:09:05.130 --> 00:09:06.910
which makes it easier to attack
133
00:09:07.450 --> 00:09:07.950
lightning.
134
00:09:09.610 --> 00:09:12.590
So we will be talking all about that. And then I think
135
00:09:13.475 --> 00:09:16.935
Carmen didn't wasn't able to speak last time I introduced Carmen.
136
00:09:19.635 --> 00:09:21.894
Carmen, can you hear me? Carmen, can you speak?
137
00:09:24.720 --> 00:09:27.300
Okay. Well, we still cannot hear Carmen.
138
00:09:27.680 --> 00:09:28.740
Test. Test.
139
00:09:29.040 --> 00:09:30.100
We can hear Vivek.
140
00:09:30.480 --> 00:09:30.980
Cool.
141
00:09:32.175 --> 00:09:36.115
Okay. So we have Ben's, issue is that he's on Linux, and sound never
142
00:09:36.574 --> 00:09:37.555
works on Linux.
143
00:09:38.735 --> 00:09:41.235
I mean, I ran the show I'm on Linux.
144
00:09:41.710 --> 00:09:44.530
I ran the show from Linux for, like, 2 years.
145
00:09:46.510 --> 00:09:49.010
Ben is gonna switch switch computers.
146
00:09:49.390 --> 00:09:51.615
Okay, Ben. Switch computers and come back.
147
00:09:52.175 --> 00:09:53.154
Let's get started.
148
00:09:54.095 --> 00:09:56.675
I wanna thank the Freaks for for,
149
00:09:57.855 --> 00:09:59.530
this is a this is a big group,
150
00:10:00.010 --> 00:10:02.910
but it's a it's a great group, and I'm happy to have them here.
151
00:10:07.185 --> 00:10:08.225
Okay. And,
152
00:10:09.345 --> 00:10:16.230
so just I appreciate the freaks for sticking with us during connection issues and whatnot, considering we have so many people here.
153
00:10:17.350 --> 00:10:19.690
I guess I guess where to start is,
154
00:10:20.709 --> 00:10:23.529
Barack, you want to give us a basic
155
00:10:24.310 --> 00:10:24.810
overview
156
00:10:25.190 --> 00:10:25.690
of
157
00:10:26.265 --> 00:10:26.925
both bugs
158
00:10:27.865 --> 00:10:30.525
or Yeah. Or at least how you how you created
159
00:10:30.905 --> 00:10:32.285
what led to both bugs?
160
00:10:32.905 --> 00:10:33.725
Yeah. Sure.
161
00:10:34.570 --> 00:10:38.510
Yeah. I can give it a bit give a bit of a history what happened. So, obviously,
162
00:10:39.209 --> 00:10:49.345
it was around a month ago or something. Yeah. I did this first large multi tap script transaction on Mainnet. I did it on Testnet first, though,
163
00:10:49.920 --> 00:10:54.900
and then it was unintentionally broke LND due to a pricing issue in BTCD.
164
00:10:56.240 --> 00:10:56.740
And,
165
00:10:58.035 --> 00:11:00.775
I I, obviously, it made a lot of trouble at the time.
166
00:11:01.395 --> 00:11:03.175
I guess I feel sorry about that.
167
00:11:03.955 --> 00:11:05.610
And then in the following ways,
168
00:11:06.570 --> 00:11:07.470
I had this
169
00:11:08.170 --> 00:11:09.070
this this,
170
00:11:09.529 --> 00:11:11.390
this urge, this inner feeling
171
00:11:12.170 --> 00:11:14.670
to my gut telling me to break it more.
172
00:11:16.375 --> 00:11:21.435
And, like, like, I did once, when, or twice. I'm not sure, like, if
173
00:11:22.399 --> 00:11:24.000
that sounds weird, but,
174
00:11:24.399 --> 00:11:25.060
I guess,
175
00:11:25.440 --> 00:11:27.860
yeah, I'm discovering the dark side in me.
176
00:11:28.959 --> 00:11:33.125
Yeah. Maybe I'm a bad actor. Who knows? But, yeah, I just I just
177
00:11:33.505 --> 00:11:35.045
I just wanted to break more,
178
00:11:35.665 --> 00:11:40.199
and I did it only for fun. Not well, for nothing. Just for fun.
179
00:11:40.819 --> 00:11:42.199
And then I dig into
180
00:11:42.660 --> 00:11:44.839
the consensus code of BTCD.
181
00:11:45.779 --> 00:11:49.785
1st and foremost, I'm not a software engineer, although I did some programming in the past.
182
00:11:50.265 --> 00:11:52.125
I I think I'm not qualified
183
00:11:52.584 --> 00:11:53.084
for
184
00:11:53.545 --> 00:11:54.265
the title, but,
185
00:11:55.305 --> 00:11:55.805
I,
186
00:11:56.265 --> 00:11:57.485
I'm a Bitcoin dev.
187
00:11:58.949 --> 00:12:07.370
That's what I can tell. And I dig into consensus code and for weeks. Right? And then I couldn't really find find any exploit, like, any conflict,
188
00:12:07.735 --> 00:12:09.515
consensus conflict between BTCD
189
00:12:10.375 --> 00:12:11.115
and core.
190
00:12:11.495 --> 00:12:12.955
And from what I can tell,
191
00:12:13.335 --> 00:12:15.595
BTCD is actually a very well,
192
00:12:16.670 --> 00:12:19.330
written implementation. It's it it it's
193
00:12:19.950 --> 00:12:25.495
it's it complies with the Bitcoin consensus rules bit by bits. I I couldn't really find any exploit.
194
00:12:26.115 --> 00:12:27.735
I need to dig more into it,
195
00:12:29.875 --> 00:12:32.375
to find more, but, yeah, I'm not sure if I can
196
00:12:32.709 --> 00:12:33.449
find a
197
00:12:33.750 --> 00:12:34.329
third. Also,
198
00:12:34.949 --> 00:12:35.769
the yeah.
199
00:12:36.310 --> 00:12:38.810
So the first bug the first bug, essentially,
200
00:12:39.189 --> 00:12:40.685
you used functionality
201
00:12:40.985 --> 00:12:46.685
that was enabled by Taproot that allowed you to do a massive multisig transaction.
202
00:12:46.985 --> 00:12:47.485
Right?
203
00:12:48.185 --> 00:12:49.165
Yeah. That's true.
204
00:12:49.850 --> 00:12:50.350
And
205
00:12:50.970 --> 00:12:55.389
Tap with yes. And then and so LND had some BTCD
206
00:12:56.089 --> 00:12:57.389
libraries in it.
207
00:12:57.714 --> 00:12:58.214
BTCD
208
00:12:58.675 --> 00:12:59.175
is
209
00:12:59.714 --> 00:13:00.454
a Bitcoin
210
00:13:00.915 --> 00:13:01.415
implementation
211
00:13:01.954 --> 00:13:03.334
that is written in Go,
212
00:13:03.875 --> 00:13:05.654
and those libraries
213
00:13:06.115 --> 00:13:07.175
made it so
214
00:13:08.190 --> 00:13:09.870
l and d nodes can no longer
215
00:13:10.510 --> 00:13:16.850
essentially, were no longer synced to the Bitcoin chain. They can no longer see what was going on in the Bitcoin chain. Is that a good overview?
216
00:13:17.385 --> 00:13:22.665
Yeah. That's correct. So layer 2's obvious landing is the only layer 2 in my book, and layer 2's,
217
00:13:23.305 --> 00:13:26.685
inherit the security properties of layer 1, and it depends on,
218
00:13:27.530 --> 00:13:33.870
it relies I mean, BTC in Lendly, in particular, it relies on the BTCD, which is an alternative implementation of Bitcoin.
219
00:13:35.825 --> 00:13:45.285
For the record, I'm not against alternative implementations. In fact, I'm in favor. I think diversity is overall good for Bitcoin, whether it's Lightning implementations or Bitcoin.
220
00:13:46.150 --> 00:13:49.930
Think more diversity is good for the long term, although it may be,
221
00:13:50.310 --> 00:13:51.770
scary for the short term.
222
00:13:52.150 --> 00:13:57.755
So yeah. So the the the first part was unintentional. It was due to a parsing issue.
223
00:13:58.615 --> 00:14:01.195
We had it had a cons it had a parsing,
224
00:14:01.655 --> 00:14:02.155
check
225
00:14:02.940 --> 00:14:08.560
from SegWit SegWit scripts I mean, the scripts are limited to, 10 k, 10 kilobytes.
226
00:14:09.500 --> 00:14:16.855
Sorry. 10 kilobytes. And, I I I managed to make a large I did a large multi transaction, which consumed, like,
227
00:14:17.555 --> 00:14:23.250
1 out of 8 block space or something. And and, yeah, it's it's it's couldn't pass this pre check.
228
00:14:23.709 --> 00:14:26.769
And, yeah, it's unintentionally broke LND the first time.
229
00:14:27.390 --> 00:14:32.215
And the second time, I I tried to look a second look for a second's conflicts,
230
00:14:32.915 --> 00:14:38.055
and I couldn't find any in the consensus the in the actual interrupt repo code, the TX script code.
231
00:14:39.210 --> 00:14:44.510
And from what I can tell, yeah, I think b two c d is is a it's a good implementation.
232
00:14:45.610 --> 00:14:47.515
Then I when I couldn't find,
233
00:14:48.215 --> 00:14:55.435
any conflict, then I come back to then I go back to the wire code, the the the the TX parsing code, and I realized, okay, there is another
234
00:14:55.920 --> 00:14:58.260
conflict in the literally the above line.
235
00:14:58.640 --> 00:15:01.220
The the line above the previous pipeline,
236
00:15:02.000 --> 00:15:04.420
which was also a Taproot related issue.
237
00:15:05.505 --> 00:15:11.365
So in Bitcoin, we have a consensus rule in place that limits number of SEC elements in the row of
238
00:15:12.440 --> 00:15:14.779
a thousand. Right? You cannot exceed that.
239
00:15:15.400 --> 00:15:19.740
Although I'm not sure why it had why this limit was 500 k.
240
00:15:20.235 --> 00:15:28.415
Not sure about that, but it's we, you know, we have another rule in template that says, okay. If you encounter an op success x op occurred in scripts,
241
00:15:29.000 --> 00:15:30.940
it's past the validation regardless.
242
00:15:31.640 --> 00:15:35.020
So it these rule does not does do no longer apply.
243
00:15:35.400 --> 00:15:36.380
So I
244
00:15:37.005 --> 00:15:40.145
I then I when I realized, I tried to first
245
00:15:40.605 --> 00:15:45.320
create a template output, a funding and ops success x, literally, script path.
246
00:15:45.880 --> 00:15:52.060
And maybe it's a bit of technical, but I then I tweak this output with my own inner key. I thought I did.
247
00:15:52.495 --> 00:15:56.515
But it apparently, I tweaked this output with an unspendable inner key.
248
00:15:57.375 --> 00:16:00.755
And then I found this, like, 3 weeks ago or something.
249
00:16:01.680 --> 00:16:03.380
I discovered the bug myself,
250
00:16:03.920 --> 00:16:04.420
and
251
00:16:04.880 --> 00:16:06.020
and found this address,
252
00:16:06.480 --> 00:16:08.020
and then I reach out.
253
00:16:08.345 --> 00:16:09.805
I I build this transaction
254
00:16:10.425 --> 00:16:11.084
by hand
255
00:16:12.264 --> 00:16:13.644
and placing 500,
256
00:16:14.824 --> 00:16:15.324
500,000
257
00:16:15.785 --> 00:16:16.605
stake elements.
258
00:16:25.595 --> 00:16:32.335
And he said, yeah. He didn't question it. He said just pay extra fees for the manual work
259
00:16:32.850 --> 00:16:37.350
and then email us. And then yeah. I emailed them my rolled transaction.
260
00:16:38.370 --> 00:16:41.190
It was like it was paying overpaying, like, 3 x.
261
00:16:42.355 --> 00:16:42.855
And
262
00:16:43.475 --> 00:16:44.855
yeah. And then, obviously,
263
00:16:45.394 --> 00:16:47.654
it was invalid because my my
264
00:16:48.035 --> 00:16:52.400
my control block was incorrect because I thought I tweeted what my inner keypad.
265
00:16:53.260 --> 00:16:54.480
Then, you know,
266
00:16:55.339 --> 00:16:58.855
then they they said, okay. We need to patch. We couldn't broadcast it, whatever.
267
00:16:59.635 --> 00:17:03.735
And then, like, on November 1st, 12 days ago,
268
00:17:04.730 --> 00:17:15.945
I was in need of some money, and then I I wanted to revert the money back to myself. But then I realized, okay, my transactions was wasn't correct. It was tweaked with was tweaked with an in unspendable inner key.
269
00:17:16.405 --> 00:17:20.985
Then, okay, let's, then let's let's make some chaos. Then I fix
270
00:17:21.559 --> 00:17:27.419
the evolved transaction and send back to f two pool in then in within an hour or something. Yeah.
271
00:17:27.960 --> 00:17:29.899
They it ended up in a Bitcoin block.
272
00:17:30.945 --> 00:17:37.525
So it was a bit of a mistake, but not not really. I think yeah. I did it by I did it with my.
273
00:17:39.420 --> 00:17:40.640
I I did it intentionally.
274
00:17:43.660 --> 00:17:44.560
Then, yeah,
275
00:17:45.340 --> 00:17:47.684
then you all know the rest.
276
00:17:48.385 --> 00:17:50.085
So both were triggered
277
00:17:50.385 --> 00:17:51.205
by different
278
00:17:51.745 --> 00:17:52.804
on chain transactions.
279
00:17:53.745 --> 00:17:55.445
Both have the same end result
280
00:17:55.860 --> 00:17:59.780
that l and d nodes fell out of sync. Yeah. Both were based
281
00:18:00.980 --> 00:18:03.080
both of the issues stemmed from
282
00:18:03.895 --> 00:18:05.835
the use of the BTCD library.
283
00:18:07.895 --> 00:18:14.880
I it's interesting that you say you're for I one of the interesting things about this situation is depending on your bias,
284
00:18:15.340 --> 00:18:20.240
I've noticed people using it to argue against multiple implementations and for multiple implementations,
285
00:18:22.385 --> 00:18:24.485
which is just fun. It's just classic Bitcoin.
286
00:18:26.625 --> 00:18:27.605
So we have,
287
00:18:28.225 --> 00:18:31.685
well, first of all, Ben, can you communicate with us now?
288
00:18:36.290 --> 00:18:37.190
No. You can't.
289
00:18:37.570 --> 00:18:39.830
Wow. They're trying to silence him.
290
00:18:41.755 --> 00:18:44.255
Okay. Well, we'll get back to Ben. We have Tony here.
291
00:18:45.035 --> 00:18:47.215
Tony, you wanna talk about how,
292
00:18:48.419 --> 00:18:51.880
how how someone could have used if if Barack was malicious,
293
00:18:53.059 --> 00:18:55.480
you did a you did a guide, basically,
294
00:18:56.755 --> 00:19:02.055
in reg test, which I guess so unlike Bitcoin test net one of the Bitcoin test nets,
295
00:19:02.755 --> 00:19:07.880
for how someone could exploit this attack to steal funds. You wanna talk about that real quick? Yeah.
296
00:19:08.680 --> 00:19:15.035
And and props props to Ben. He he's pretty much the one that wrote all these exploits. So Alan's point,
297
00:19:15.895 --> 00:19:19.410
I kinda made it you know, I've been doing these, like, you you know, lightning
298
00:19:19.950 --> 00:19:20.450
abusing
299
00:19:21.070 --> 00:19:24.030
projects, I guess, to to to say kind of being,
300
00:19:24.350 --> 00:19:26.910
along the same lines of, like, a bad actor in a way. But,
301
00:19:29.295 --> 00:19:35.635
so I decided, that it was time to, like, finally do Alan's point and write something that, like, actually tried to, you
302
00:19:36.080 --> 00:19:40.720
know, exploit some of these things that we keep talking about and that keep not getting fixed.
303
00:19:41.920 --> 00:19:50.965
And it was it it was with the intention of doing it at the Atlanta tab comp. There was, was in a workshop there, but I had you know, it takes a while to build,
304
00:19:51.905 --> 00:19:58.480
you know, some of the things that I've been building on, and I didn't have any exploits in there by the time. It was the week of the conference.
305
00:19:59.180 --> 00:20:05.785
And then, week of the conference comes on Sunday, and and this this this bug breaks L and D. And,
306
00:20:06.885 --> 00:20:11.110
of course, like, I was like, Ben texted me and said, okay. Can we reproduce this,
307
00:20:12.390 --> 00:20:15.690
then put it into Ellen's point? And I was like, yeah. Let's let's do it. So
308
00:20:15.990 --> 00:20:24.895
we we did that. And over the course of that week, I was like, okay. Well, how do we actually, like, exploit this? Like, I got a reproducing that works on regs test. Of course, you can't
309
00:20:25.275 --> 00:20:42.625
reproduce it on main net, like, once it's already, you know, once it's already out there and being fixed. It just takes that one transaction to, like, break it. But, essentially, I broadcast you you basically if if you're in the same block as this transaction that, like, can't be, you know, one of Barak's transactions,
310
00:20:44.200 --> 00:20:46.460
You know, the node can't process it.
311
00:20:46.920 --> 00:20:50.860
And if you're not running LND and bit, with with Bitcoin
312
00:20:51.160 --> 00:20:52.059
0 mq,
313
00:20:53.155 --> 00:20:56.775
then then LND actually doesn't process any blocks after that either.
314
00:20:57.075 --> 00:21:02.610
So, which is something I found out by actually reproducing this, and and figuring out that,
315
00:21:03.550 --> 00:21:06.610
it wasn't just that block that it wasn't processing.
316
00:21:06.990 --> 00:21:13.555
If you didn't run-in 0MQ mode, it wouldn't it it thought there was a chain split, and it wouldn't process any other blocks beyond that.
317
00:21:14.255 --> 00:21:14.995
But, essentially,
318
00:21:15.375 --> 00:21:23.190
you know, I just went ahead and just put it in the same block in my reg test scenario. And I have a whole guide on this. It's, you can go to Bytes journey.com.
319
00:21:23.890 --> 00:21:25.910
It's one of the top top blogs.
320
00:21:26.770 --> 00:21:27.510
But, essentially,
321
00:21:27.914 --> 00:21:31.774
after that, after you after your channel peer can't process the block,
322
00:21:33.355 --> 00:21:35.534
the block with the with with the
323
00:21:36.130 --> 00:21:38.550
transaction and at that old channel state,
324
00:21:39.090 --> 00:21:41.430
it doesn't know how to do the justice transaction.
325
00:21:41.890 --> 00:21:49.545
So in Lightning, if if someone were to try to cheat you, your node this is why nodes has to be, you know, pretty much always online or have a watchtower.
326
00:21:50.405 --> 00:21:53.145
But, you know, there's problems with watchtowers too. But
327
00:21:54.340 --> 00:22:05.455
if if you're not online and you don't see that transaction, you can't broadcast justice transactions, which basically take all of the other person's funds even if, you know, even if you weren't rightfully owed all of them.
328
00:22:05.835 --> 00:22:07.775
You do get all of the cheaters funds,
329
00:22:08.555 --> 00:22:12.809
that they have locked up in that channel. So if they're not online, they don't get to see that,
330
00:22:13.590 --> 00:22:17.690
and then I demonstrate. It was actually kinda cool too because I got to demonstrate, like,
331
00:22:18.070 --> 00:22:20.485
how an LND node you know, there's
332
00:22:21.424 --> 00:22:28.645
part of my tutorial walks through, like, okay. Here's a a patched LND node, and here's a non patched LND node. Let's, like, see what
333
00:22:28.950 --> 00:22:29.770
each of them
334
00:22:30.070 --> 00:22:38.310
do under this scenario. And the, you know, the patched one, you know, says, you know, stuff like, oh, your your peer is being fishy in the logs, and it's, like, broadcasting a transaction.
335
00:22:39.565 --> 00:22:42.385
But the other one doesn't. It just says, oh, there's a chain reorg,
336
00:22:42.845 --> 00:22:44.065
and it's none the wiser.
337
00:22:44.685 --> 00:22:45.585
And then eventually,
338
00:22:46.250 --> 00:22:53.309
you might have enough blocks, and and you should get you know, you should be able to redeem those funds on chain. But if the other peer
339
00:22:54.010 --> 00:22:55.150
patches in time,
340
00:22:55.795 --> 00:22:56.674
even if we did
341
00:22:57.554 --> 00:23:01.015
even if someone did exploit this in the same block as as Barak's,
342
00:23:02.980 --> 00:23:05.960
All it takes is you updating your l and d note in time.
343
00:23:06.260 --> 00:23:16.205
Now there there's some questions there on, like, how soon you need to actually update it under all the scenarios. But if you do update in time, you do get to submit that justice transaction.
344
00:23:16.905 --> 00:23:23.780
But if you don't, then then you're kinda shit out of luck, and there's nothing once once enough blocks pass, you don't you don't get those funds back.
345
00:23:25.120 --> 00:23:27.860
It it may be useful to to point out that,
346
00:23:28.635 --> 00:23:32.655
in order to exploit this bug, you don't have to take that risk of broadcasting
347
00:23:33.115 --> 00:23:36.655
a a stale state where someone can steal all of your funds.
348
00:23:37.330 --> 00:23:42.950
But in fact, you can do it using HTLCs as well. So you can send an HTLC through the target node through the victim
349
00:23:43.490 --> 00:23:44.985
and then force
350
00:23:45.445 --> 00:23:46.825
close. And that victim,
351
00:23:47.365 --> 00:23:51.465
if you claim that HTLC on chain, the victim won't learn the preimage
352
00:23:52.440 --> 00:23:57.820
from that HTLC or at least in this class of bugs in general, the victim won't learn that preimage from that HTLC.
353
00:23:58.679 --> 00:24:01.899
And then after the HTLC times out, you can just take funds.
354
00:24:02.395 --> 00:24:10.815
So that not only allows you to do it, allows you to exploit this this class of bugs risk free, but it also allows you to exploit this class of bugs,
355
00:24:11.480 --> 00:24:11.980
without,
356
00:24:14.120 --> 00:24:15.740
what was the point I was gonna make?
357
00:24:16.040 --> 00:24:18.860
And Without exposing yourself to the justice transaction?
358
00:24:19.765 --> 00:24:23.465
Oh, no. Sorry. I was gonna point, and and also in a much shorter time horizon.
359
00:24:23.925 --> 00:24:26.985
So that that's where you see the difference between 40 blocks,
360
00:24:27.365 --> 00:24:28.184
which is
361
00:24:28.570 --> 00:24:36.269
the default in most lightning nodes for the time that you have to claim an HDLC that's been routed through you versus,
362
00:24:37.294 --> 00:24:38.995
I think the default for
363
00:24:39.375 --> 00:24:45.715
doing justice transactions and broadcasting in old state is usually, like, 144. Some nodes set it to a full week.
364
00:24:46.470 --> 00:24:53.210
But when you're talking about HTLCs, you can exploit this bug much faster, and the victim has a much shorter time around time,
365
00:24:54.054 --> 00:24:57.195
to turn around where they need to upgrade their node and and catch it in time.
366
00:24:57.654 --> 00:25:02.235
And what was I was looking into this. What was the reason again, Matt, for why,
367
00:25:03.380 --> 00:25:09.960
it defaults to a low value? Like, people routing through you want that value to be lower in a normal situation. Right?
368
00:25:10.355 --> 00:25:12.695
Yeah. Yeah. So that that's basically the stuckness.
369
00:25:13.155 --> 00:25:16.055
So, like, if if you have an HTLC that gets stuck,
370
00:25:16.675 --> 00:25:31.904
that's how that's the total number of these, you know, it's normally 40 blocks per hop. So if you send a payment that's, you know, 3 hops, then it's 3 times 40, a 120 blocks that you have to wait before you're sure that that payment's gonna come back and get unstuck.
371
00:25:33.059 --> 00:25:37.640
Luckily, stuck payments aren't as big a deal as they used to be. We don't see them as much,
372
00:25:38.500 --> 00:25:50.180
but a node can always make a payment, get stuck for that amount of time. So if you're sending a payment, you care about that number being really low. Now the lightning protocol, and I don't know what settings different nodes expose,
373
00:25:51.120 --> 00:25:51.780
allows someone,
374
00:25:52.400 --> 00:25:54.020
opening a channel to say,
375
00:25:54.320 --> 00:25:55.380
you know, I
376
00:25:55.840 --> 00:26:06.904
only want to expose myself to up to this amount of funds in HTLCs at any given time, and that would allow you to limit your exposure to these kinds of attacks that are exploiting against HTLCs
377
00:26:07.365 --> 00:26:08.264
rather than
378
00:26:09.160 --> 00:26:10.300
exploiting against,
379
00:26:12.600 --> 00:26:15.980
the the the stale closing or the the stale commitment transaction.
380
00:26:16.404 --> 00:26:26.340
But I think, most people don't bother sending that. Most people set that to, the full channel value. You should also not do this because it's bad for everyone else's privacy. And in fact, LDK,
381
00:26:27.120 --> 00:26:28.419
and thus Cash App
382
00:26:28.799 --> 00:26:29.299
use,
383
00:26:30.480 --> 00:26:35.895
prefer to route over channels or very slightly prefer to route over channels that do not set their HTLC
384
00:26:36.835 --> 00:26:42.480
max to the total value of the or the their total HTLC max in flight to the value of the channel,
385
00:26:43.020 --> 00:26:46.960
because it's actually better for the sender's privacy, in order for you to do that.
386
00:26:51.595 --> 00:26:52.475
Thanks, Matt.
387
00:26:52.955 --> 00:26:56.815
While we have you, LDK was also affected but only by the second bug.
388
00:26:57.220 --> 00:26:57.720
Right?
389
00:26:59.380 --> 00:27:05.640
For old versions? Yeah. So, I mean, the the this class of issue has bitten a number of,
390
00:27:07.675 --> 00:27:08.175
various,
391
00:27:09.915 --> 00:27:10.415
Bitcoin
392
00:27:10.795 --> 00:27:11.775
library deserialization
393
00:27:12.155 --> 00:27:18.680
libraries. Right? This this this kind of you know, when you're deserializing untrusted input, you have to make sure you're not gonna over allocate memory
394
00:27:19.060 --> 00:27:21.640
and crash yourself by by allocating gigabytes.
395
00:27:22.885 --> 00:27:36.809
You know, there there are better ways to design this code. There are worse ways to design this code, but a number of implementations, you know, BDCV has had more of these class of bugs than just these two bugs. You know, they've they've had some of these classes of bugs since before l and d.
396
00:27:37.565 --> 00:27:49.410
But yeah. So Rust so LDK uses Rust Bitcoin under the hood. Rust Bitcoin had a similar bug, that we caught internally, so we didn't we actually caught it, someone while one of the developers working on it was reading the code,
397
00:27:49.790 --> 00:27:53.250
not when it went to chain. And we fixed it at that time,
398
00:27:53.735 --> 00:27:55.195
by rewriting a bunch of the deserialization
399
00:27:55.495 --> 00:27:59.035
pipeline to just be more robust against this whole class of issues.
400
00:28:00.535 --> 00:28:06.610
But old versions did have that issue, and so some people some users were using old versions of Rust Bitcoin.
401
00:28:07.790 --> 00:28:11.655
I don't know that any LDK LK users were using old versions of Rust Bitcoin, but,
402
00:28:12.035 --> 00:28:18.260
you saw some people running mempool and and running, Elect RS. We're using old versions of Rust Bitcoin, which did get bit
403
00:28:18.740 --> 00:28:20.840
by this bug when the second
404
00:28:21.300 --> 00:28:22.520
transaction was broadcasted.
405
00:28:23.220 --> 00:28:24.280
Right. Yeah. Actually,
406
00:28:24.820 --> 00:28:34.304
I I do have one project that's still on an old version of LDK, and I I found that out yesterday when, my hidden lighting network project, the project that does probes,
407
00:28:34.840 --> 00:28:35.980
for private channels.
408
00:28:36.679 --> 00:28:38.700
I launched it yesterday because Ben
409
00:28:39.240 --> 00:28:39.640
Ben,
410
00:28:40.120 --> 00:28:42.059
Ben had his first successful vortex
411
00:28:42.375 --> 00:28:45.355
channel open. So I wanted to see if I could figure out,
412
00:28:46.215 --> 00:28:50.715
which output was his that he opened the channel with because he didn't use sort channel ID aliases.
413
00:28:51.500 --> 00:28:56.799
So I launched up that LDK project, and then it's it's fetching the blocks, and then it crashes. So,
414
00:28:57.659 --> 00:29:02.255
but that's an unmaintained, you know, kind of like a throwaway project at this point, but that's,
415
00:29:02.735 --> 00:29:11.900
that that it was kind of funny that came back full circle on that. So, Tony, in either situation, an attacker had to essentially be set up as your channel peer
416
00:29:12.280 --> 00:29:16.700
before the transaction goes out. Correct? Like, they have to have a channel with you.
417
00:29:17.475 --> 00:29:23.575
Well, I think I think how Matt kinda described it earlier, I I think you can even just route through
418
00:29:24.700 --> 00:29:40.475
any node that has a problem, right, with the HDLs. I I was a little fuzzy on how you could exploit it under the HTLC path. But, Matt, for at least the way I have implemented the exploit, it does require the the the you'd have a channel with the peer. Well, call us Corallo and Odell.
419
00:29:41.950 --> 00:29:43.090
Yeah. Corallo.
420
00:29:43.390 --> 00:29:46.289
So is that correct? Like, you wouldn't to use the HTLC
421
00:29:46.590 --> 00:29:53.985
attack vector, you could just if you just had a channel open with someone I have a channel open, you could potentially exploit me on that?
422
00:29:57.700 --> 00:30:04.580
You know, I don't it it a lot depends on exact details of the bug and what what does or doesn't happen in the node.
423
00:30:05.140 --> 00:30:07.085
I think it it did. So
424
00:30:07.385 --> 00:30:14.765
in the general like, I could imagine in going both ways. I don't know the details of lnd and how it might have have operated in this case.
425
00:30:15.544 --> 00:30:20.510
I think for LDK, that might have been the case, if you were using a a really old version of LDK.
426
00:30:22.090 --> 00:30:23.789
But, you know, in general,
427
00:30:24.250 --> 00:30:28.965
that is a possible outcome depending on some of the the nuances how the note is implemented.
428
00:30:30.065 --> 00:30:30.805
Got it.
429
00:30:31.585 --> 00:30:33.285
Ben, are you here with us now?
430
00:30:34.430 --> 00:30:35.330
You hear me
431
00:30:35.710 --> 00:30:39.490
now? Yes. Yeah. We can. Alright. Do you wanna introduce yourself?
432
00:30:40.910 --> 00:30:42.085
A half hour late,
433
00:30:42.885 --> 00:30:44.664
but, I've been the car man.
434
00:30:45.365 --> 00:30:49.385
My company, but did kind of open source stuff on.
435
00:30:50.725 --> 00:30:52.460
And work with the.
436
00:30:55.640 --> 00:30:59.420
Awesome. Well, it's a pleasure to have you, and I'm glad you can finally speak.
437
00:31:01.715 --> 00:31:08.135
I guess, Kaludis, what are your thoughts here as the lead maintainer of Zeus, the number one way people interact with their
438
00:31:08.435 --> 00:31:10.615
node at home during all of this?
439
00:31:12.020 --> 00:31:12.520
So,
440
00:31:13.140 --> 00:31:13.800
when this
441
00:31:14.580 --> 00:31:15.720
second exploit
442
00:31:16.820 --> 00:31:18.600
dropped, I was sort of
443
00:31:19.495 --> 00:31:20.795
like a double
444
00:31:21.415 --> 00:31:27.595
take, like, on Twitter and in, like, a few chats that I'm in, including, like, you know, the Zeus Telegram.
445
00:31:28.740 --> 00:31:35.780
I'm like, what is everyone talking about? You know, this is the exploit from, like, we're still patching this up. And then it hit me that,
446
00:31:36.385 --> 00:31:38.725
you know, a second exploit had dropped.
447
00:31:39.505 --> 00:31:40.005
And,
448
00:31:40.945 --> 00:31:44.245
you know, I wasn't super surprised, but it was a huge
449
00:31:45.220 --> 00:31:48.600
huge inconvenience, I feel, for a whole lot of different parties.
450
00:31:49.460 --> 00:31:50.760
You know, from, you
451
00:31:51.300 --> 00:31:55.125
know, the BTCD and LND guys who had to patch up their code,
452
00:31:56.485 --> 00:31:56.985
to,
453
00:31:57.445 --> 00:31:59.305
the maintainers of, like, node projects
454
00:31:59.685 --> 00:32:00.085
and,
455
00:32:00.885 --> 00:32:02.265
you know, Lightning wallets,
456
00:32:03.110 --> 00:32:04.649
who had to update their releases,
457
00:32:05.909 --> 00:32:10.090
individual users who were asking, hey. What's going on? Why do I have to update my note again?
458
00:32:12.195 --> 00:32:17.015
You know, it it really shook a lot of things up and, you know, ate up a lot of people's time.
459
00:32:21.370 --> 00:32:27.965
Matt, I wanted to add that Rust Elements was also affected, but the attack is obviously harder to do,
460
00:32:28.585 --> 00:32:31.245
because of Liquid's functionary model instead of,
461
00:32:31.625 --> 00:32:35.245
reaching out of band to a minor. Yeah. You wanna go into that?
462
00:32:35.580 --> 00:32:38.560
Like, what was the what was the impact on liquid?
463
00:32:39.340 --> 00:32:49.665
Well, it's it's the same bug, and it just needs to be patched. But Rust Elements also had it, and I wanted to add that because, you know, we said LDK had it, and LDK is using Rust Bitcoin and
464
00:32:49.965 --> 00:32:51.505
Matt mentioned for the older versions.
465
00:32:51.965 --> 00:32:54.545
And Greenlight also for its watch tower,
466
00:32:54.980 --> 00:32:58.279
was using rustic wood, so it also was impacted.
467
00:32:58.820 --> 00:33:01.480
But, I mean, these are remedied now, and,
468
00:33:02.715 --> 00:33:04.255
I guess we're good. But,
469
00:33:04.875 --> 00:33:06.815
just like Evan said, we were also
470
00:33:07.595 --> 00:33:12.790
a bit inconvenienced in trying to scramble to figure out, what exactly needs to be done.
471
00:33:13.410 --> 00:33:15.910
It wasn't just an LND bug.
472
00:33:17.490 --> 00:33:22.785
Yeah. It was, like, a general block parsing error that, you know, a lot of people had looked over in implementing
473
00:33:23.245 --> 00:33:25.825
a Taproot, it seems like. And and then
474
00:33:26.365 --> 00:33:28.630
It it wasn't a Taproot thing. No.
475
00:33:29.090 --> 00:33:33.030
It was a a segwit thing, a witness witness side. Yeah.
476
00:33:33.650 --> 00:33:39.105
I think it looks like and it just made it easier to to create that that large webinar.
477
00:33:39.885 --> 00:33:40.385
Yeah.
478
00:33:40.845 --> 00:33:47.230
That's what Barack was mentioning earlier, someone, where they're wondering why the original size limit. And I believe
479
00:33:47.769 --> 00:33:49.470
Laulu's explanation was,
480
00:33:49.850 --> 00:33:52.590
because when he originally added the SegWit code
481
00:33:53.049 --> 00:33:54.830
a long time ago for parsing,
482
00:33:55.145 --> 00:33:57.325
like, in v zero. That's what it was.
483
00:33:59.465 --> 00:33:59.965
Gotcha.
484
00:34:00.505 --> 00:34:04.045
But so what does that mean for liquid users at the time?
485
00:34:06.330 --> 00:34:08.970
Liquid users, everything was fine, but,
486
00:34:09.850 --> 00:34:11.390
because of the multisig
487
00:34:12.010 --> 00:34:15.065
and other things, you know, all of that needs to be
488
00:34:15.845 --> 00:34:18.904
updated, whether it's the functionaries or the on chain multisig.
489
00:34:20.404 --> 00:34:20.904
Yeah.
490
00:34:21.500 --> 00:34:23.440
And there was, like, also a scramble,
491
00:34:23.820 --> 00:34:25.280
by a certain amount of blocks,
492
00:34:25.820 --> 00:34:27.520
things that needed to be updated.
493
00:34:28.575 --> 00:34:29.075
So,
494
00:34:29.695 --> 00:34:30.675
yeah, I think
495
00:34:31.214 --> 00:34:32.035
I think we,
496
00:34:32.335 --> 00:34:34.515
Blockstream formally released a statement.
497
00:34:34.815 --> 00:34:35.315
So
498
00:34:35.750 --> 00:34:38.890
I can, post it in the elements chat, but
499
00:34:39.990 --> 00:34:44.170
I'll leave the exact details to that. But similar issue, witness size,
500
00:34:44.805 --> 00:34:45.305
parsing.
501
00:34:46.405 --> 00:34:50.345
Did it halt liquid, or is it just, like, the peg in, peg out stuff got broken?
502
00:34:51.365 --> 00:34:54.890
It it didn't halt liquid, but, yeah, it's the peg in, peg out. Exactly.
503
00:34:56.630 --> 00:34:57.130
What
504
00:34:57.430 --> 00:34:59.210
so the connection to the chain?
505
00:34:59.990 --> 00:35:02.890
Yeah. I saw a side swap had some issues.
506
00:35:04.865 --> 00:35:08.085
I didn't really see any other people complain too much.
507
00:35:09.025 --> 00:35:12.885
I think Barack would also know a lot about, the impact to Liquid because
508
00:35:13.280 --> 00:35:16.100
he's probably the most knowledgeable in Liquid script.
509
00:35:16.560 --> 00:35:20.340
Yeah. And his project bit matrix is runs on Liquid, so he kind of
510
00:35:21.245 --> 00:35:25.425
Barak, did you did you bork your own project when you sent out the transaction?
511
00:35:26.285 --> 00:35:39.245
No. Bitmetrics, 4 g, and, you know, other that like, TDEC are not they they were not affected. The I mean, the the liquid network functioned well. I think, yeah, it only apparently, it only affected Pagan and Paycard functionality,
512
00:35:40.425 --> 00:35:42.765
and, obviously, Rust Bitcoin and few other
513
00:35:43.890 --> 00:35:54.635
infrastructure projects in the space. And in fact, I mean, I wasn't I was only targeting BTCD and LND. I wasn't aware this would cost I mean, this could have caused, any other issues.
514
00:35:57.735 --> 00:36:00.315
So we got caught up in the lateral damage.
515
00:36:01.349 --> 00:36:01.849
So
516
00:36:03.349 --> 00:36:03.849
Yeah.
517
00:36:04.710 --> 00:36:06.569
Do you wanna talk about real quickly,
518
00:36:08.685 --> 00:36:15.665
the tweet you sent out when you when you sent out that transaction? What was it? In order to find the light, you need to touch the darkness?
519
00:36:16.010 --> 00:36:20.830
Yeah. That was basically a joke maybe, but I think it has also a truth in it. Right?
520
00:36:21.690 --> 00:36:23.390
Obviously, I did it for fun.
521
00:36:23.850 --> 00:36:24.430
I guess,
522
00:36:25.085 --> 00:36:31.265
yeah, I love making cows. I guess I crave for cows maybe. Yeah. It makes me feel good.
523
00:36:32.760 --> 00:36:33.340
I guess,
524
00:36:33.800 --> 00:36:37.980
that's you know, good or bad, that was the most meaningful thing I did in my life,
525
00:36:39.490 --> 00:36:41.565
regardless the outcome. But,
526
00:36:43.065 --> 00:36:44.205
yeah, basically,
527
00:36:46.265 --> 00:36:48.765
I did it for fun, but I think it also had,
528
00:36:51.130 --> 00:36:55.630
it will have also have good, you know, consequences or, like like, long long term benefits
529
00:36:56.090 --> 00:36:58.990
in in the long in the long run, I would say.
530
00:36:59.755 --> 00:37:06.255
Bringing into chaos into into software, I think, yeah, makes everything else more robust in the long run. Maybe
531
00:37:06.795 --> 00:37:07.775
causing some,
532
00:37:08.920 --> 00:37:12.140
damage in the short term, but, yeah, making everything more robust.
533
00:37:13.560 --> 00:37:18.245
Brock, did I, grok the transaction page right? Like, the transaction cost something like $750?
534
00:37:22.625 --> 00:37:24.405
Sorry. What what was that again?
535
00:37:24.830 --> 00:37:27.390
The fee for the transaction to broadcast it
536
00:37:28.030 --> 00:37:29.490
Yeah. I paid it $750
537
00:37:30.030 --> 00:37:39.325
out of your own pocket. Got you. I did it for fun. And, yeah, I was actually in order of money as I told. And I I was revert I was trying to revert that money back to my myself, but
538
00:37:39.625 --> 00:37:41.805
I think I could I could.
539
00:37:42.170 --> 00:37:47.710
Was an off success anyway. I could have done that, but I I realized I couldn't. I mean, I didn't realize that at the time.
540
00:37:48.730 --> 00:37:51.470
And then I just I I choose the cows.
541
00:37:52.015 --> 00:38:05.240
I I I want to make cows. Gotcha. I I just think it's funny because most people are receiving money when they're burning their reputation instead of having to spend out of their own pocket. It was a reverse rug pull. I'll yeah. I like that.
542
00:38:05.540 --> 00:38:06.760
Yeah. I guess so.
543
00:38:07.220 --> 00:38:10.025
I I would love to possibly kinda get into,
544
00:38:11.445 --> 00:38:12.345
because because
545
00:38:12.965 --> 00:38:16.825
I agree. Like like, what doesn't kill you makes you stronger. Right?
546
00:38:17.630 --> 00:38:20.930
But there's you know, I'm curious of the balance here between,
547
00:38:23.310 --> 00:38:28.974
you know, causing chaos and in the end goal, we're all I I think we can all agree that, you know,
548
00:38:32.060 --> 00:38:36.320
I don't know, code wise, you know, or or ecosystem wise, we're we're
549
00:38:36.620 --> 00:38:38.000
better for it probably.
550
00:38:38.620 --> 00:38:45.105
But, I mean, what you know, is there a balance there at all? Like like, doing stuff like this versus
551
00:38:45.724 --> 00:38:46.785
responsible disclosure,
552
00:38:47.885 --> 00:38:51.825
because, you know, I I don't know where I land, like, on it. But
553
00:38:52.270 --> 00:38:55.810
because it does I think fire drills do make us better.
554
00:38:56.510 --> 00:39:00.930
In the end, we need fire drills. Anyone could have done this for $750.
555
00:39:02.974 --> 00:39:04.994
It's just the matter of, like,
556
00:39:07.055 --> 00:39:12.000
well, yeah, when to you know, at least going forward in the future, you know, when when to do this
557
00:39:12.880 --> 00:39:19.460
versus versus responsibility, the skill. So I wonder if we can, like, have a conversation around that. It's probably useful
558
00:39:19.765 --> 00:39:20.265
it's
559
00:39:21.444 --> 00:39:23.385
probably useful just to kind of
560
00:39:24.005 --> 00:39:28.825
high just to to quickly make sure we're on the same page about what responsible disclosure is.
561
00:39:29.440 --> 00:39:42.935
There's there's a lot of people who get confused and think, like, responsible disclosure is all about, like, protecting the vendor and making sure you you disclose appropriately to the vendor and whatever. And that's not at all what responsible disclosure is. Right? Responsible disclosure is all about
562
00:39:44.835 --> 00:39:47.734
highlighting that you have a duty of care to their users.
563
00:39:48.440 --> 00:40:03.205
It doesn't matter what the vendor wants or what the vendor thinks or, like, you know, if you wanna do something that makes a vendor look like shit or and look like an idiot because of some bug they had, you know, it'll probably backfire, but you're welcome to try. And it doesn't really matter. It's not it's not related to responsible disclosure.
564
00:40:03.905 --> 00:40:09.480
What responsible disclosure is is saying, like, look. There's some users out there. They're running the software.
565
00:40:09.940 --> 00:40:20.385
You know, for whatever reason, they decided to run the software. They they decided that it was worth worth running because, you know, maybe there's some risk some risk to running any software, but they decided that
566
00:40:20.685 --> 00:40:37.825
that they needed to run the software and that, you know, you have to do right by them. So that means, you know, responsible disclosure can mean going public if the vendor refuses to fix an issue. You know, that is a part of responsible disclosure, but it does mean making sure that the vendor has a chance to fix the issue so that users
567
00:40:38.125 --> 00:40:39.665
don't get hurt and aren't,
568
00:40:40.525 --> 00:40:49.530
hurt more than they need to be. You know, another part of responsible disclosure is is, reporting the issue publicly after it has been fixed to encourage people to,
569
00:40:50.070 --> 00:41:02.730
upgrade. And so that that's that's something where you can say, like, okay. After it's been fixed, exploiting it to to force users to upgrade, you know, is is an option, and that that's a legitimate part of responsible disclosure. But it's never,
570
00:41:03.430 --> 00:41:05.849
you know, putting users at risk when
571
00:41:06.655 --> 00:41:07.155
when
572
00:41:07.535 --> 00:41:12.275
just by taking action, you know, before there's even a patch or before users have a chance to upgrade.
573
00:41:13.960 --> 00:41:17.240
Yeah. I think I I agree on that definition, and I would definitely pick,
574
00:41:18.520 --> 00:41:23.635
responsible disclosure if this was Bitcoin Core. And I would definitely pick, again,
575
00:41:24.095 --> 00:41:28.494
this approach if this if Lightning is in production. I mean, is
576
00:41:29.490 --> 00:41:31.829
if Lightning is used by a lot of people,
577
00:41:32.210 --> 00:41:41.885
I think, like, the way I see Lightning is it's really a beta software, and it has, like, this public capacity of 5,000 or something. Even Liquid has, like, 35100
578
00:41:42.425 --> 00:41:42.925
Bitcoin.
579
00:41:43.465 --> 00:41:44.125
I think,
580
00:41:45.320 --> 00:41:51.420
I don't really take lightning seriously at this at this very stage, and I I kind of see this as a playground.
581
00:41:51.875 --> 00:41:52.375
And
582
00:41:52.675 --> 00:41:54.375
I don't think that's fair at all.
583
00:41:54.675 --> 00:41:57.815
I mean, there there are large companies who use lightning now,
584
00:41:58.595 --> 00:42:01.495
and and see material transaction volume. I mean,
585
00:42:01.940 --> 00:42:10.200
I think I I don't know about Cash App, but I know, like, River disclosed their transaction volume on lightning. And it's not a joke anymore. It's not it's not trivial.
586
00:42:10.715 --> 00:42:16.255
They have a lot of funds locked up in lightning that are put at risk in something like this.
587
00:42:17.490 --> 00:42:18.309
And that's something too
588
00:42:18.609 --> 00:42:24.710
where, like, you know, if lightning were were super alpha and everyone was on the same page there, it'd be one thing.
589
00:42:25.170 --> 00:42:25.670
But
590
00:42:26.035 --> 00:42:33.095
when there's large corporates who have money locked up or considering deploying Lightning, you know, because they see their peers deploying Lightning,
591
00:42:33.860 --> 00:42:37.880
and they're they're trying to decide whether it makes sense to deploy Lightning right now.
592
00:42:39.140 --> 00:42:57.500
You see these kinds of things and it it it makes corporates think twice. It it it really hurts the deployment of lightning even if we assume that there's no no material funds at risk here. But that's not not accurate anymore either that there there are there is a relatively significant amount of money locked up in Lightning and especially, you know, I lot I know a lot of,
593
00:42:58.285 --> 00:42:58.785
individuals
594
00:42:59.085 --> 00:43:15.430
who who put a lot of money in their lightning node, who put a large amount of their Bitcoin stack in their lightning node. And, you we can agree or disagree about whether that's a great idea. I obviously don't think that's a great idea. I agree. So, like, yeah, there there is a lot of Yeah. I think the I don't know. Well, I mean,
595
00:43:15.914 --> 00:43:16.414
Yep.
596
00:43:17.515 --> 00:43:23.855
Yeah. So, yeah, I think there is a little relatively large on Bitcoin, yeah, in in Lightning. But, yeah, I think, yeah, the corporate's using
597
00:43:24.279 --> 00:43:28.380
Lightning infrastructure, I think, yeah, they can easily upgrade to a new version and, you know,
598
00:43:29.000 --> 00:43:31.740
and and and the other folks, perhaps, you know,
599
00:43:32.704 --> 00:43:38.405
can simply use watchtowers to avoid these kind of attacks. And, you know, when when I text right.
600
00:43:38.865 --> 00:43:40.420
Sorry. What? There's
601
00:43:41.520 --> 00:43:42.740
no watchtower implementation
602
00:43:43.200 --> 00:43:45.859
that exists that would have avoided this issue because
603
00:43:46.359 --> 00:43:46.859
the,
604
00:43:47.359 --> 00:43:49.460
a, the l watchtower is,
605
00:43:50.184 --> 00:43:54.684
uses the same code, but, b, all of the current watchtower implementations don't enforce HTLC,
606
00:43:55.625 --> 00:43:58.840
HTLC forwards. So the watchtower is don't,
607
00:43:59.540 --> 00:44:01.220
address the issue even if
608
00:44:02.020 --> 00:44:06.840
and and doing that would be a very non private watchtower. You can give up a lot of your privacy to the watchtower.
609
00:44:07.365 --> 00:44:10.345
So there's no code to do HTLC enforcements,
610
00:44:11.285 --> 00:44:14.340
even if you even if you wanted to. Not in the watchtower.
611
00:44:14.900 --> 00:44:24.994
Yeah. Okay. Good to know that. I didn't know this. So okay. But it's not more so easy. You can yeah. For HDLCs, I think, yeah, there is a tech point with HDLCs, which has a is a shorter
612
00:44:25.454 --> 00:44:31.795
abstract walk time in it. But I think when the HDLCs claim, the preimage is revealed on chain anyway.
613
00:44:32.839 --> 00:44:38.779
But, as for, you know, the actual commitment outputs, these outputs have a relatively larger
614
00:44:39.585 --> 00:44:44.885
relative walk time in it anyway. So no other runners can easily upgrade to the newer version
615
00:44:45.585 --> 00:44:46.805
and avoid these,
616
00:44:47.185 --> 00:44:48.085
attack vectors.
617
00:44:48.810 --> 00:44:52.350
So when I did attack this when I created this, the second,
618
00:44:53.690 --> 00:44:56.190
transaction, I was aware of this, and
619
00:44:56.570 --> 00:44:59.895
I I knew there wouldn't be any there wouldn't be any
620
00:45:00.515 --> 00:45:06.270
potential loss of funds, and it appeared, though, we haven't I I personally haven't seen any
621
00:45:06.750 --> 00:45:22.335
any loss of funds. That's that's not true. Right? That even though there wasn't loss of funds in the first one, there couldn't be loss of funds in the second one. I I would I would push back and say, in fact, that because there wasn't because there there was a recent bug of the same class, they're substantially more likely to be loss of funds,
622
00:45:22.955 --> 00:45:29.770
in the second case because people are aware of it. People are are aware of how to exploit it. In fact, there's sample code to exploit it,
623
00:45:30.070 --> 00:45:31.850
that the the folks here worked on
624
00:45:32.835 --> 00:45:37.415
because of the first bug. Because, you know, once the first bug's out there, of course, you just write sample code, whatever. It's,
625
00:45:38.035 --> 00:45:41.415
not not making the exploit all that much easier or harder.
626
00:45:42.349 --> 00:45:46.849
But that because of the first one, it makes it substantially easier to exploit the second one,
627
00:45:47.150 --> 00:45:50.930
which which put a substantially higher risk on the second one. No?
628
00:45:51.994 --> 00:45:56.575
Yeah. I I totally agree that phone files are totally at risk due to the interactive model of lightning.
629
00:45:57.115 --> 00:46:01.900
And I still see these attacks as more of a denial of service type of attack
630
00:46:02.680 --> 00:46:12.365
than an than, like That's yeah. But, I mean, that's not how lightning works. Right? Lightning has always been denial of service attacks allow you to steal funds. That's that's the lightning security model for better or for worse.
631
00:46:13.225 --> 00:46:17.645
So there's there's basically no such thing as a denial of service attack against a lightning node.
632
00:46:21.000 --> 00:46:30.184
Yeah. But, again, you have still you see this as kinda, a type as long service attacks because of the large relative work time in commitment happens in front runners.
633
00:46:30.884 --> 00:46:33.944
Forty blocks. Right? Forty blocks is like,
634
00:46:34.884 --> 00:46:36.424
the time during which you're asleep.
635
00:46:38.150 --> 00:46:39.450
Is is that default?
636
00:46:40.230 --> 00:46:44.170
For a for HCLCs. Yeah. It's 41. It's default for LND.
637
00:46:44.869 --> 00:46:47.369
I think core lightning, the default is 144.
638
00:46:49.575 --> 00:46:57.660
It might be. The the default for I mean, 40, I think, is the the most common default is the most common value on the network. It may just be for LND.
639
00:46:59.420 --> 00:47:02.400
But that is for the HTLCs. Right? How about the commitment outputs?
640
00:47:03.500 --> 00:47:09.964
That's true. But the HTLCs are how you would choose to exploit this kind of bug, because there's no risk to the the x the attacker.
641
00:47:10.585 --> 00:47:15.404
It wouldn't make sense to to exploit via the commitment output. But you're right. The the commitment output
642
00:47:16.770 --> 00:47:17.990
the commitment output
643
00:47:18.369 --> 00:47:19.990
historical state of broadcasting
644
00:47:20.530 --> 00:47:29.255
is a much higher value. I'm not sure what the default is there. I think it might be a day. It might be a week. I I keep hearing 2 weeks. Is 2 weeks not true for the commitment outputs?
645
00:47:31.155 --> 00:47:41.020
I think it's configurable. I I heard I thought the most common was a week, but it it may be 2 weeks. I don't know. That's totally within would be within reason for for a value to choose.
646
00:47:42.175 --> 00:47:44.994
I've been hearing a week and 2 weeks also, Matt.
647
00:47:45.615 --> 00:47:47.555
Both, Matt. Which is it?
648
00:47:49.990 --> 00:47:51.850
I don't know. Pull up the source yourself.
649
00:47:52.150 --> 00:47:53.770
Yeah. I know. I know. I'm
650
00:47:55.030 --> 00:48:00.145
just saying, you know, I mean, there's definitely there's gotta be a bright side here on, you know,
651
00:48:01.005 --> 00:48:04.145
on on Barack's side, right, that we're actually having this conversation.
652
00:48:06.370 --> 00:48:07.350
Yeah. I mean, it's
653
00:48:07.730 --> 00:48:15.785
it's healthy for the community to have a conversation about what responsible disclosure is or isn't so that people are are aware of this kind of thing and so that we can
654
00:48:17.285 --> 00:48:17.785
be
655
00:48:18.165 --> 00:48:25.609
be more you know, have the community have a a more common understanding of what what responsible disclosure means and and how it should look,
656
00:48:26.069 --> 00:48:39.365
so that hopefully we as a community kind of are all on a on a similar page. I mean, I certainly through the course of this this exercise, it it became very clear that the the Bitcoin community has very different ideas of of both what responsible disclosure are and what people's
657
00:48:40.190 --> 00:48:40.690
responsibilities
658
00:48:40.990 --> 00:48:49.135
are. And I think having a a a more common understanding of what responsible disclosure is should get us hopefully to a a more common page.
659
00:48:49.855 --> 00:48:54.435
So what would you wanna see here? Let's say you're Barack and you discover the second exploit.
660
00:48:56.095 --> 00:48:56.595
Presumably,
661
00:48:58.010 --> 00:49:00.750
you wouldn't do what Barack did. What how would you proceed?
662
00:49:03.130 --> 00:49:12.785
I mean, I think what you do is certainly, the first thing you do is you reach out to the vendor and you make sure you give them a reasonable amount of time to to patch it. Right? Which vendor? To all the lightning implementations
663
00:49:13.085 --> 00:49:18.190
or just l and d? Or If it if it affects more than one that you're aware of, certainly, you let
664
00:49:18.730 --> 00:49:23.175
you know, for for security issues, you tell the minimal number of people
665
00:49:23.555 --> 00:49:24.055
required,
666
00:49:24.595 --> 00:49:27.335
in order for the the the issue to get patched.
667
00:49:27.635 --> 00:49:31.015
So you start with l and d because that's the only one you're aware of has this problem.
668
00:49:32.450 --> 00:49:44.665
And then And to be clear, it's like you would you would reach out to them privately. You wouldn't just, you know, go post, like, an issue on GitHub. Right? Right. Yeah. Yeah. Which is what Anthony Towns did, right, about 10 days before this happened?
669
00:49:45.205 --> 00:49:55.680
Yeah. I mean, I don't think I think he he also I I think he'd said that he'd screwed up. He he didn't realize that this was a a a major security issue. But, yeah, I mean, that's also not the correct Yeah. He hung up here.
670
00:49:57.985 --> 00:50:08.069
But then so so I think an important part of of understanding responsible disclosure is is that you coordinate with the vendor about release timeline. Right? So so if you're the one reporting a bug,
671
00:50:09.010 --> 00:50:11.109
you are allowed to say to the vendor,
672
00:50:11.410 --> 00:50:13.270
hey. I think this is really critical.
673
00:50:13.805 --> 00:50:16.145
I think I should go public with this in 2 weeks.
674
00:50:17.005 --> 00:50:20.625
Can you get a patch together and and make sure you get that shipped ASAP?
675
00:50:21.300 --> 00:50:25.640
And then that's a conversation that you have with the vendor. It's not like the vendor gets to say, like,
676
00:50:26.020 --> 00:50:32.055
no. This has to stay private or here's the release timeline. Take it or leave it. You know, that's a conversation you have with them.
677
00:50:33.075 --> 00:50:36.215
And then I think once the the fix is released,
678
00:50:36.675 --> 00:50:43.880
it be that, at that point, it becomes a question of, like, what you think is the makes the most sense for for users. So,
679
00:50:45.494 --> 00:50:48.315
really, you know, patching a a an issue quietly
680
00:50:49.095 --> 00:50:57.960
does not get the most people to upgrade. And so, you know, you've seen this con we've had, you know, back when I worked a bunch on Bitcoin Core, we had these kinds of conversations a lot.
681
00:50:58.740 --> 00:51:00.200
You know, when you have an issue,
682
00:51:00.805 --> 00:51:02.025
do you tell people
683
00:51:02.725 --> 00:51:03.465
about it
684
00:51:03.765 --> 00:51:08.665
so that people go and upgrade really quickly, or do you not tell people about it because,
685
00:51:09.365 --> 00:51:11.240
you don't wanna give attackers
686
00:51:11.540 --> 00:51:13.720
enough information to go exploit the vulnerability?
687
00:51:15.460 --> 00:51:24.535
And so it becomes a a balancing act. And, again, this is where, you know, you, the reporter, get to have a conversation with the vendor and where you, the reporter, gets to ultimately decide.
688
00:51:25.075 --> 00:51:26.454
And I think it would be
689
00:51:27.100 --> 00:51:32.080
I I don't know if I would have decided to do that, but it would have been totally reasonable or at least totally justified
690
00:51:32.620 --> 00:51:40.815
to go exploit the issue after the patch had been released or maybe maybe a few days after the patch had been released so the people had a chance to upgrade on their own,
691
00:51:41.835 --> 00:51:45.615
to highlight the issue and and to for kinda force people to upgrade, quote, unquote.
692
00:51:46.869 --> 00:51:47.369
But,
693
00:51:47.750 --> 00:51:53.690
you know, prior to there being a patch and prior to people having at least a small window of time to to upgrade themselves,
694
00:51:54.994 --> 00:51:59.414
actually exploiting it just just seems like putting users at more risk than is necessary.
695
00:52:01.350 --> 00:52:03.930
Well, isn't that kinda just, like, the sad
696
00:52:04.230 --> 00:52:15.875
truth, the sad reality of the situation? Like, we talk about we're just just saying that, like, oh, because there are significant volumes on Lightning now, and there are big companies and corporations looking at Lightning.
697
00:52:16.735 --> 00:52:19.155
And then things like this overall hurt
698
00:52:19.530 --> 00:52:26.830
the perception of Lightning. I mean but isn't the perception of Lightning just wrong currently? Like, we live in this happy little
699
00:52:27.425 --> 00:52:35.950
lightning world that, like, all of our payments are fast and easy. We can do 0 conf atomic swaps. We can do all this other fancy shit, but, like,
700
00:52:36.349 --> 00:52:40.770
Lightning's pretty broken. I mean, Matt, your talk, Crowley, your talk
701
00:52:41.310 --> 00:52:47.964
at, Atlanta was, like, a really good talk, and it just kinda highlighted that lightning is kind of broken in its current state.
702
00:52:48.825 --> 00:53:00.910
Yeah. I mean, to add to you, as well, like, this is literally a valid transaction on chain. Right? I think that's the way certain people are framing it. So if your l two is affected by it, they feel like,
703
00:53:01.370 --> 00:53:02.970
in essence, it was your fault.
704
00:53:03.370 --> 00:53:04.430
Bitcoin Core
705
00:53:04.915 --> 00:53:09.335
thought this was valid, and I think that's where some people are drawing the line.
706
00:53:10.275 --> 00:53:17.200
Yeah. Totally. I mean, like, if you're if you're, a it was LND's bug. It was Rust Lightning's bug. It's not like the the the
707
00:53:17.660 --> 00:53:32.980
the foundational issue was that there was a bug. The foundational issue was not that it was exploited. The only the only question then is, like, okay. There is a bug. Given there is a bug, should you exploit it? That's a very different question from, like, whose fault is the fact that there is a bug. Right?
708
00:53:33.520 --> 00:53:38.260
And bugs happen. You know, that's not gonna not gonna change. That's the reality of software development.
709
00:53:39.680 --> 00:54:02.965
But but yeah. So, you know, I I think to the point about lightning being broken and the perception of lightning being wrong, I think it is important to to highlight the difference between, your counterparty and, like, you know, I always kinda make the point that you shouldn't open channels with a counterparty you don't know or at least don't trust enough that they're not gonna, like, try to steal your money and, like, put in a bunch of effort to steal your money. I think this is a very different world from
710
00:54:04.300 --> 00:54:19.325
and then there's denial of service attacks against Lightning, not in the, like, take your note offline, but in the, like, saturate your liquidity so that you can't send payments. So let me I guess I should rephrase my earlier statement about there not being denial of service attacks against Lightning. Just that the the the,
711
00:54:19.645 --> 00:54:22.145
saturating liquidity denial of service attacks.
712
00:54:22.480 --> 00:54:24.020
So there's a lot of things that
713
00:54:24.480 --> 00:54:37.255
are broken with lightning and where the perception is maybe wrong, but I think those are different from you're going to lose funds maybe because your counterparty did something without them even being involved. So when we were talking about, you know, routing an HDL
714
00:54:37.560 --> 00:54:48.285
through multiple hops and then stealing funds, that's something where like your counterparty can be totally honest and they go to chain and then your node doesn't see it and then you still lose funds. Right? So I think that's
715
00:54:48.585 --> 00:54:50.045
the kind of thing where,
716
00:54:51.225 --> 00:54:57.030
you know, aside from these bugs, generally, I think there's not really much in the way of known issues,
717
00:54:57.810 --> 00:54:59.190
for lightning for
718
00:54:59.810 --> 00:55:04.865
why this might be why you might lose funds if your counterpart is, like, completely honest.
719
00:55:09.870 --> 00:55:12.130
And regarding previous bugs, Matt,
720
00:55:12.910 --> 00:55:15.890
it's not our first bug on lightning. Right? There's one in 2019,
721
00:55:17.070 --> 00:55:17.730
and then
722
00:55:18.395 --> 00:55:29.650
Antoine Riard and Gleb also found a dust one last year that, I guess, they responsibly disclosed. Like, do you remember how that process was, and maybe we can, like, touch on that?
723
00:55:30.510 --> 00:55:34.130
Yeah. That was across the whole that was basically on every lightning note.
724
00:55:35.285 --> 00:55:39.305
So they they reached out to everyone. They emailed, you know, I guess, all of the
725
00:55:39.685 --> 00:55:42.825
I don't know who all was on the email list. But, you know, basically, all the
726
00:55:43.859 --> 00:55:50.520
maintainers or the kind of lead maintainer or 2 of all the lightning implementations and kinda describe the issue. They describe the
727
00:55:50.980 --> 00:55:57.474
basically, the issue was that, because lightning has some concept dust outputs. If an if an output is dust, if an HTLC
728
00:55:57.775 --> 00:55:59.875
the value of the HTLC is dust
729
00:56:01.000 --> 00:56:02.140
below some threshold,
730
00:56:02.920 --> 00:56:04.700
then it just gets burned to feeds.
731
00:56:05.000 --> 00:56:12.095
So, a counterparty could send a bunch of HTLCs that were just barely below this threshold. And in fact, they can even do things to,
732
00:56:12.555 --> 00:56:13.775
increase this threshold,
733
00:56:14.394 --> 00:56:16.015
that nodes will currently accept.
734
00:56:16.560 --> 00:56:26.405
And then if they do that, then they can burn a lot of your money to fees. And I guess if they're a minor, they get free money then because they burn the money to fees and then they get to claim the fees because they're a minor.
735
00:56:27.825 --> 00:56:36.370
So the they they reached out to all the lightning implementations. All the lightning implementations added a bunch of code to, patch it and then ship that code.
736
00:56:37.470 --> 00:56:41.890
And then I think after everyone had shipped or some period of time afterwards,
737
00:56:42.755 --> 00:56:44.915
they disclosed it publicly. And and,
738
00:56:45.315 --> 00:56:53.099
Antoine wrote up a a a change to the bolts and described this issue and and note that that implementers of the bolt spec need to,
739
00:56:53.800 --> 00:56:56.300
do something to to ameliorate this issue.
740
00:56:57.800 --> 00:57:10.130
Unlike the kind of on chain stuff that we've been talking about, there's no way to go, like, exploit the issue to force people to upgrade. There's nothing like that. We can only, like, write code and and tell people that this
741
00:57:10.430 --> 00:57:16.609
this issue exists and you should upgrade. And then, like, if you were to exploit this issue, you have to actually go steal funds.
742
00:57:17.235 --> 00:57:18.435
You you couldn't just, like,
743
00:57:19.155 --> 00:57:21.975
cause the issue and then and then get no stuff.
744
00:57:22.275 --> 00:57:26.380
And then there was the there was the other bug where none of the lightning implementations
745
00:57:27.240 --> 00:57:36.165
were actually checking the chain for commitment transactions. Right? For funding, I believe. And that was the For funding. Yep. The funding transaction had the right script and the right value.
746
00:57:36.465 --> 00:57:47.700
Actually, that's all I we were. So before LDK was LDK, Rust Lightning existed and it was a joke. It was like a tiny project, and and no one used it, and it wasn't even ready for production. But but we were checking it. So Mhmm.
747
00:57:50.795 --> 00:58:01.210
But but yeah. I mean, that that was another again, that was another case where you couldn't do something to actively force everyone to upgrade, and you could only actually go steal funds, which obviously has a has a very different moral question.
748
00:58:02.790 --> 00:58:05.130
So it seems that the heart of all these
749
00:58:05.670 --> 00:58:07.849
attacks is a security assumption
750
00:58:08.715 --> 00:58:10.095
that your peer,
751
00:58:10.555 --> 00:58:15.695
ideally, will not be a lightning node peer as well as a miner.
752
00:58:16.369 --> 00:58:21.670
I know there's a lot of stuff being kinda shuffled around with the mempool and Bitcoin Core right now.
753
00:58:22.450 --> 00:58:26.025
People happy or unhappy about the RBF policies.
754
00:58:26.485 --> 00:58:28.265
How do you think this will affect,
755
00:58:29.845 --> 00:58:32.185
any other things, any other new potential
756
00:58:33.240 --> 00:58:34.460
dust issues, HCLCs,
757
00:58:34.760 --> 00:58:35.819
anything? Does anything
758
00:58:36.119 --> 00:58:36.940
come to
759
00:58:37.400 --> 00:58:41.819
your mind, Matt? Anything about, like, l two that's needed or penalty transactions?
760
00:58:43.545 --> 00:58:46.045
Yeah. I mean, we know a lot of stuff needs to change.
761
00:58:46.985 --> 00:58:52.605
And this isn't even so that there's questions about minors, but also just around mempool policy like you mentioned.
762
00:58:53.680 --> 00:59:05.734
We know a lot of stuff has to change. We have ideas for how that stuff changes. All of it to exploit it though, like I mentioned, requires some amount of effort on the part of your counterparty. They have to, like, do a bunch of work writing a bunch of software, coding stuff,
763
00:59:07.714 --> 00:59:08.214
to
764
00:59:08.515 --> 00:59:19.880
to actually go steal funds, you know, anchor outputs. As long as you have anchor outputs in your channels. So anchor outputs don't prevent don't protect you against an actively malicious counterparty, but they do protect you against,
765
00:59:20.645 --> 00:59:23.224
the just the fees going up in the network.
766
00:59:24.165 --> 00:59:29.065
So the the kind of straightforward issues that existed prior to Anchor, solved by Anchor,
767
00:59:29.940 --> 00:59:35.079
you know, encourage you to make sure your opening channels that support Anchor outputs that have the Anchor flight turned on.
768
00:59:36.500 --> 00:59:37.000
And
769
00:59:37.435 --> 00:59:50.040
aside from that, you know, there there's things that need to happen, but they they do require some amount of effort to to exploit. So also just make sure you know who your channel counterparties are. You trust them not to to do a bunch of work to steal your money.
770
00:59:50.660 --> 00:59:52.600
Trust them to at least be kind of honest.
771
00:59:56.645 --> 01:00:02.744
Well and and then maybe that's just, like, the thing that should be highlighted more because I don't think that's, like, the current
772
01:00:03.400 --> 01:00:07.020
situation today. I mean, where people just, like, open channels with,
773
01:00:08.520 --> 01:00:09.900
pretty much anyone, really.
774
01:00:10.520 --> 01:00:11.420
Any random
775
01:00:11.800 --> 01:00:12.620
on the Internet,
776
01:00:13.035 --> 01:00:22.740
they kind of just, like, go and open channels, and they let their little Raspberry Pi sit in the closet for months that they don't touch. And then that's kind of the end of the story there. So, you know, hopefully
777
01:00:23.040 --> 01:00:25.460
I mean, I would say, you know,
778
01:00:26.240 --> 01:00:26.740
after,
779
01:00:27.200 --> 01:00:37.315
you know, some, you know, person that just had their lightning note in the closet for 2 months, and they had to go figure out how to update it and then having to do it again in the same month. I mean, you know, if they're
780
01:00:38.310 --> 01:00:47.235
not ready to sign up for that life, then maybe they they really should consider. Like, okay. Maybe I shouldn't shouldn't be running this lightning note,
781
01:00:48.195 --> 01:00:54.055
you know, after after all of this. Because that's kind of the reality. You don't just, like, throw it in a closet and, like, you know,
782
01:00:54.550 --> 01:00:56.010
don't come back to it again.
783
01:00:58.070 --> 01:01:00.250
And your your blog, Tony,
784
01:01:00.550 --> 01:01:01.485
you said it well.
785
01:01:02.685 --> 01:01:03.185
Don't
786
01:01:03.485 --> 01:01:05.825
open or if you're gonna go into a coma
787
01:01:06.365 --> 01:01:10.945
because, like, it's not just something you can like, you know, lighting a car that you can
788
01:01:11.670 --> 01:01:12.170
maintain
789
01:01:12.470 --> 01:01:15.370
personally, then it's just, like, you're running up cold
790
01:01:15.910 --> 01:01:18.090
yourself. Like, figure out how to
791
01:01:18.525 --> 01:01:19.485
either study lighting
792
01:01:20.045 --> 01:01:24.705
all of sucks or, like, something that's like like a analysis or something.
793
01:01:30.260 --> 01:01:40.645
Yeah. And that's also another question about, like, how do how do the developers communicate the safety of the the products they built? That's something I struggle with a lot. I don't know. There's no easy answer,
794
01:01:42.465 --> 01:01:53.829
but how do and this is, like, a very, very broad question too. Right? And and maybe this is something worth discussing, but, like, if you're writing software, you're writing a wallet, how do you communicate to users what the relative risks
795
01:01:54.345 --> 01:02:02.685
of all these different attacks are, especially when you don't know for sure? You know, you you have some idea of how to exploit it, but, like, will it work in practice or not? It's a whole other question.
796
01:02:03.225 --> 01:02:05.230
And then, you know, how do you
797
01:02:05.930 --> 01:02:13.290
how do you evaluate this and how do you communicate it to users? I mean, this is another thing, you know, I think I always say that the only two things
798
01:02:13.795 --> 01:02:20.215
the only thing in the entire kind of quote, unquote cryptocurrency space that's in competition with Bitcoin is stable coins in practice
799
01:02:20.515 --> 01:02:26.420
because people do wanna you know, the only thing that works that does payments is is stable coins and people use stable coins for payments.
800
01:02:27.360 --> 01:02:38.760
And so how does how do you if you're, like, writing a wallet that supports Bitcoin and stablecoins, how do you communicate to users that, like, this stablecoin exposes you to risk of, you know, Tether going under
801
01:02:39.220 --> 01:02:46.200
and stealing all the funds. It exposes you to risk of, like, the blockchain it's on and it's like Tron and it might just, like, randomly implode
802
01:02:46.740 --> 01:02:54.425
and, like, you know, it also exposes you to the risk of of just US dollar and sanctions and, like, maybe the US government decides to, like,
803
01:02:54.805 --> 01:03:06.555
this this stable coin is not enforcing sanctions and suddenly all the money is taken. Or you can use Bitcoin and the the the risk here is the volatility. Like, how do you communicate that to users in a way that they understand that intuitively
804
01:03:07.095 --> 01:03:07.755
and then
805
01:03:08.295 --> 01:03:11.674
make a decision that makes sense based on that communication?
806
01:03:12.135 --> 01:03:21.250
Or do you just say, like, here's stable coins and here's Bitcoin. Use what you want. And then users just assume that the stable coin is, like, gonna keep working and has no risk associated with it.
807
01:03:24.894 --> 01:03:28.194
I think that's too many options. They can only do swipe.
808
01:03:32.670 --> 01:03:35.010
So it kinda seems like the conclusion is,
809
01:03:36.270 --> 01:03:36.770
that
810
01:03:37.790 --> 01:03:44.715
at least Sovereign Lightning usage is not in the cards or should be dissuaded from end users right now.
811
01:03:47.255 --> 01:03:48.295
Or or at least
812
01:03:48.780 --> 01:03:51.119
make sure you know who your channel counterparty is.
813
01:03:53.980 --> 01:03:58.240
Yeah. I mean, that almost feels like like, I don't know who my channel counter parties are.
814
01:03:59.875 --> 01:04:02.295
Well, you started your node at a different
815
01:04:02.915 --> 01:04:05.494
time. You know, like, you were one of the earlier nodes,
816
01:04:05.930 --> 01:04:10.110
and it was, quote, unquote, reckless, have fun. Like, you're just trying to
817
01:04:10.410 --> 01:04:11.390
test the technology.
818
01:04:12.090 --> 01:04:14.190
I think now we're in a more
819
01:04:14.645 --> 01:04:16.185
mature state where,
820
01:04:16.805 --> 01:04:19.145
I guess, it is still reckless, but
821
01:04:19.605 --> 01:04:20.425
you should
822
01:04:20.725 --> 01:04:20.965
not
823
01:04:21.560 --> 01:04:22.520
you should do your,
824
01:04:23.320 --> 01:04:25.740
best efforts to know your peers and,
825
01:04:26.760 --> 01:04:32.885
update your software, all that. Like, it's no longer SpongeBob memes. You have Tony and Brock out here now.
826
01:04:33.905 --> 01:04:35.045
So I have a question,
827
01:04:36.465 --> 01:04:39.605
which I asked on the open source stage in Miami this year.
828
01:04:41.550 --> 01:04:45.330
So in my Bitcoin experience, one of the things that I learned early on
829
01:04:45.630 --> 01:04:47.250
is that unlike traditional
830
01:04:48.404 --> 01:04:52.585
proprietary software that people are comfortable with or or used to, I guess,
831
01:04:53.684 --> 01:04:58.940
we intentionally do not have auto updates on Bitcoin Core because it's an attack vector. If if
832
01:04:59.400 --> 01:05:02.540
if you just update blindly, then you might update,
833
01:05:03.000 --> 01:05:05.340
a malicious update. You might update an attack.
834
01:05:06.705 --> 01:05:13.525
So a lot of people with with Bitcoin Core specifically, they're they're they're slow to update. They don't update very quickly.
835
01:05:13.985 --> 01:05:15.445
On the Lightning side,
836
01:05:16.650 --> 01:05:27.724
there seems like I know it's still early days in Lightning, but it seems like there's been many, many, many times where, like, the community has been, like, pushed to to update ASAP. There's something critical you have to update ASAP.
837
01:05:28.345 --> 01:05:28.845
Now,
838
01:05:30.424 --> 01:05:30.924
enthusiasts,
839
01:05:31.305 --> 01:05:33.805
like, hardcore Bitcoiners that are not necessarily,
840
01:05:34.105 --> 01:05:37.340
you know, fluid in code or whatnot, but they live and breathe Bitcoin,
841
01:05:37.960 --> 01:05:38.620
are running
842
01:05:39.240 --> 01:05:41.900
their lightning nodes on Umbrel and RaspiBlitz
843
01:05:42.745 --> 01:05:43.965
and Start 9
844
01:05:44.265 --> 01:05:45.005
and Noddle.
845
01:05:46.585 --> 01:05:48.605
So they're they're running these, like, prepackaged
846
01:05:48.985 --> 01:05:50.205
node projects,
847
01:05:51.260 --> 01:05:57.839
and then they see that there has to be an update, and they just go to them, and they just quickly, like, blindly click the update button.
848
01:05:59.674 --> 01:06:01.135
Is there I'm
849
01:06:01.595 --> 01:06:04.655
1 I'm curious if anyone here supports the idea of
850
01:06:05.275 --> 01:06:09.510
an opt in ability to auto update, Because they're practically doing it anyway.
851
01:06:10.690 --> 01:06:15.430
Like, what is the negative of giving them the option to auto update instead of, like,
852
01:06:15.835 --> 01:06:22.690
you know, being traveling, being away from your node, not being able to update for 2 weeks even if they're just gonna blindly up press the update button anyway.
853
01:06:28.210 --> 01:06:32.230
I mean, I I'll I'll go first. I mean, I think it's a super valid
854
01:06:32.645 --> 01:06:40.105
conversation. I mean, I also hate the idea about updates, but that is the reality of the situation is that they're just clicking update anyways.
855
01:06:42.240 --> 01:06:44.180
I mean, when you even think about mobile
856
01:06:44.640 --> 01:06:53.724
apps and and mobile phones and, like, no one, for 1, like, make it incredibly hard to actually verify any source code at all if you're going through app stores.
857
01:06:54.825 --> 01:06:58.430
And for 2, you know, some of the app stores even auto update anyways.
858
01:06:58.970 --> 01:07:06.430
So, like, there's there's there's nothing they they really do there either. So and and most people's lightning nodes are probably mobile phones,
859
01:07:06.765 --> 01:07:12.145
mobile phone apps anyway. So I I think it's a valid talking point. I don't know if I would
860
01:07:12.605 --> 01:07:23.170
go far go as far to say, like, there should be an auto update option in in apps like Umbrel, but I think it's a definitely a valid conversation to have. I'm curious what other people think on that.
861
01:07:23.550 --> 01:07:24.964
So I would
862
01:07:25.425 --> 01:07:26.244
say that's
863
01:07:26.785 --> 01:07:29.845
fine, Matt, but I would then also
864
01:07:30.224 --> 01:07:31.285
insist a contingency
865
01:07:31.585 --> 01:07:43.735
that there's an atomic rollback feature. I'm a big fan of Nix Bitcoin and NixOS for this reason, and I believe Bitcoin Core uses geeks also for reproducible and deterministic builds.
866
01:07:45.075 --> 01:07:50.740
So as long as there's a rollback option after that auto update, they can immediately go back if there's something wrong.
867
01:07:51.040 --> 01:07:52.500
They can rush to unupdate.
868
01:07:52.880 --> 01:07:54.260
Correct. So rush to update.
869
01:07:54.720 --> 01:07:56.820
Correct. The soft so the the
870
01:07:58.045 --> 01:08:04.900
rollbacks are hard too though because you might have, like, updated your state. Like, your local database might have gotten upgraded or something, and then, like,
871
01:08:05.940 --> 01:08:09.640
you're gonna try to roll back, and then it's not gonna be able to read the new the new
872
01:08:10.020 --> 01:08:10.520
stuff.
873
01:08:12.075 --> 01:08:20.790
That that's actually something that LDK supports that's maybe a little unique, but it's a lot of effort to support, and I wouldn't necessarily say that that all developers should support it.
874
01:08:21.090 --> 01:08:23.510
One other point I I would also highlight that,
875
01:08:23.890 --> 01:08:30.625
Bitcoin Core is very different in the the requirements here because there's not only a cost to you personally. If you like auto update
876
01:08:31.005 --> 01:08:32.945
and the the software is now,
877
01:08:33.805 --> 01:08:36.860
malicious and steals your keys, That's one thing.
878
01:08:37.320 --> 01:08:38.540
But it's there's also
879
01:08:39.400 --> 01:08:40.700
issue with,
880
01:08:41.560 --> 01:08:56.840
if you auto update and there's a consensus rule change and all the nodes auto update, suddenly someone can for example, like, BSV pushed an update today to to be able to steal arbitrary coins so that Craig can go just steal your coins if he doesn't like you.
881
01:08:57.380 --> 01:09:01.480
You know, suddenly you could do something like that if there were, like, a real auto update mechanism.
882
01:09:01.985 --> 01:09:09.605
So there's additional social costs in Bitcoin Core for that kind of thing that maybe don't apply in lightning or in kind of other wallet software cases.
883
01:09:17.265 --> 01:09:24.085
Yeah. I don't think there's, like, a real clear, clean answer about what the best behavior here would be. Obviously, any opportunity
884
01:09:24.385 --> 01:09:26.385
you have to let the user verify,
885
01:09:27.470 --> 01:09:31.250
that they're running, like, a specific version, like, a deterministic build
886
01:09:31.550 --> 01:09:37.795
is always welcome, but, you know, much easier said than done. Like, an iOS app, like, you can't do that at all. Right? And,
887
01:09:38.175 --> 01:09:41.555
you know, Bitcoin wallets, like, only a handful are, you
888
01:09:41.935 --> 01:09:42.515
know, deterministically
889
01:09:43.055 --> 01:09:44.435
reproducible on Android.
890
01:09:45.700 --> 01:09:50.760
But I think there might be value in some of these node platforms giving users the ability
891
01:09:51.380 --> 01:09:52.520
to, manually
892
01:09:52.980 --> 01:09:55.465
upgrade to certain releases perhaps before,
893
01:09:56.085 --> 01:09:59.065
you know, like, a maintainer can, like, bundle it back up again.
894
01:10:00.244 --> 01:10:01.685
I think that's a feature that,
895
01:10:02.244 --> 01:10:03.225
my node has,
896
01:10:03.685 --> 01:10:09.820
that I think is pretty underrated. Like, you could just pop in a version number, and it'll fetch and try to build it and install it on your machine.
897
01:10:11.080 --> 01:10:11.560
But,
898
01:10:12.199 --> 01:10:14.205
you know, depending on these architectures,
899
01:10:14.825 --> 01:10:21.305
it might not be so easy for a lot of these projects to transition to that. So Evan also has the room for user error too. So
900
01:10:22.750 --> 01:10:26.929
So, Evan, I mean, out of everyone in this roundtable right now, you have,
901
01:10:28.510 --> 01:10:31.810
the most exposure directly to end users of Lightning,
902
01:10:32.475 --> 01:10:33.455
because of Zeus.
903
01:10:33.915 --> 01:10:34.415
Yep.
904
01:10:35.915 --> 01:10:40.335
Like, what has what are your after these bugs and and the reaction
905
01:10:40.860 --> 01:10:44.000
among the Zeus community and how everything went there,
906
01:10:44.620 --> 01:10:45.020
how do you,
907
01:10:48.115 --> 01:10:50.215
I guess, you and Ben do because
908
01:10:50.595 --> 01:10:51.095
of,
909
01:10:51.555 --> 01:10:52.695
the Bitcoin company.
910
01:10:53.555 --> 01:10:55.735
How do you how do you how do you feel about
911
01:10:56.500 --> 01:11:00.920
Lightning going forward? Like, how do you think about actually developing for end users?
912
01:11:02.340 --> 01:11:04.760
Yeah. I mean, there's a lot of complexities here.
913
01:11:05.535 --> 01:11:07.715
You know, we're definitely seeing a
914
01:11:08.095 --> 01:11:10.355
lot of users that are frustrated by
915
01:11:11.215 --> 01:11:12.835
a lot of different things. Like,
916
01:11:13.370 --> 01:11:17.870
you know, 1st and foremost, this year, Tor has been really awful in providing a really bad
917
01:11:18.250 --> 01:11:19.230
user experience
918
01:11:21.344 --> 01:11:25.844
for people who want to sovereignly run their own node at home, able to,
919
01:11:26.145 --> 01:11:28.780
you know, test when they're out in a meat space. Right?
920
01:11:30.139 --> 01:11:34.800
Something like, you know, these l and d exploits are are sort of exacerbating,
921
01:11:35.659 --> 01:11:37.840
a lot of the frustrations these users have.
922
01:11:39.125 --> 01:11:39.785
You know,
923
01:11:40.565 --> 01:11:45.545
while some users may be technical enough to put together their own node and run something like
924
01:11:46.210 --> 01:11:55.270
Umbrell. They might not, you know, be following or have the understanding to see what's going on with, these exploits and and the real nuance about what's happening.
925
01:11:56.755 --> 01:11:58.455
And that's unfortunate because,
926
01:11:59.235 --> 01:11:59.975
the alternative
927
01:12:00.355 --> 01:12:02.455
is, you know, these users putting
928
01:12:02.915 --> 01:12:04.215
more trust in other
929
01:12:04.540 --> 01:12:06.700
third parties or, you know, running,
930
01:12:07.420 --> 01:12:10.460
you know, just a prebuilt version of,
931
01:12:10.780 --> 01:12:13.955
like, a lightning wallet on their phone that they might not verify.
932
01:12:15.135 --> 01:12:19.554
A lot of users might just be falling back on LSPs as their only peers now.
933
01:12:20.735 --> 01:12:22.994
You know, there's there's a lot of complexity whether
934
01:12:24.640 --> 01:12:27.220
that's a good or a bad thing. But I think, ultimately,
935
01:12:28.000 --> 01:12:35.665
what we're seeing from exploits like this, we have people that are less willing to run Lightning and and are dissuaded from using it at all.
936
01:12:36.285 --> 01:12:40.545
And, I think that's ultimately a bad thing because we have a network that's less distributed
937
01:12:41.220 --> 01:12:42.600
where, you know, these
938
01:12:43.380 --> 01:12:43.880
big
939
01:12:44.500 --> 01:12:49.225
intermediaries are, you know, playing even bigger roles than we'd like them to.
940
01:12:57.900 --> 01:13:00.159
Yeah. I mean, I see that trend kind of happening
941
01:13:00.540 --> 01:13:01.280
as well.
942
01:13:02.735 --> 01:13:05.555
I just wonder how, like, how that can really be avoided.
943
01:13:07.295 --> 01:13:14.210
Right. Like, on on one hand, it's like, you don't want people running these setups that are uncapable of doing it, that are just gonna be neglecting it.
944
01:13:15.230 --> 01:13:17.250
But on the other, you just don't want,
945
01:13:17.710 --> 01:13:19.650
like, these centralizing factors.
946
01:13:19.995 --> 01:13:25.695
I mean, obviously, there's, like, a degree of centralization that's gonna happen. Like, you're gonna have, like, these big hubs on the network.
947
01:13:25.995 --> 01:13:28.655
They're gonna use the SSPs or, you know, maybe,
948
01:13:29.400 --> 01:13:35.020
you know, use them as introduction points on blinded past. They offer up a plethora of services. Like, that's unavoidable.
949
01:13:35.719 --> 01:13:37.980
But, like, we also want to make,
950
01:13:40.135 --> 01:13:41.114
you know, having,
951
01:13:41.655 --> 01:13:52.140
having the ability to, you know, be as sovereign as possible and and run this infrastructure out of your house possible and also, like, appealing. Like, we we didn't want this to be something that's that's commonplace.
952
01:13:53.000 --> 01:13:53.320
And,
953
01:13:53.960 --> 01:13:58.060
you know, it's it's it's happening in a lot of ways. Like, something like Umbrell is
954
01:13:58.745 --> 01:14:03.145
a consumer facing product. It's not just corporations that are running this thing. You know? And,
955
01:14:04.185 --> 01:14:05.485
you know, a lot of users
956
01:14:05.850 --> 01:14:08.110
in some nation states like El Salvador
957
01:14:08.730 --> 01:14:12.030
are dependent on lightning to to live every day. Right?
958
01:14:12.570 --> 01:14:20.655
So when we have someone, like, go and exploit something like this and, you know, there's a risk of actual people who are dependent on this stuff
959
01:14:21.275 --> 01:14:22.495
losing savings,
960
01:14:23.420 --> 01:14:25.040
it's, really frustrating,
961
01:14:25.820 --> 01:14:38.795
especially considering all the effort that people are putting into this on the lightning side to make Bitcoin something viable that we could be using in our day to day lives. Was Chivo down during the lnd or block parsing bugs?
962
01:14:41.400 --> 01:14:44.380
I don't know. Jivo is actually just, like, public,
963
01:14:45.080 --> 01:14:52.614
is just powered by somebody's back end. It's not it's just it's it's a database, but it also somebody else does their lightning in and out.
964
01:14:53.235 --> 01:14:56.855
I don't know if it's public who does that, so I'm not gonna mention it.
965
01:14:58.210 --> 01:15:00.869
But I know I think they announced it.
966
01:15:01.250 --> 01:15:02.630
Do that. It's River.
967
01:15:03.809 --> 01:15:06.710
Yeah. It used to be a scene. Now now it's now River
968
01:15:07.075 --> 01:15:12.675
announce that they're doing it. Yeah. It used to be some other folks. Now it's River. I I I know River was able to update pretty quick. So
969
01:15:14.490 --> 01:15:18.910
Yeah. They're doing a pretty good job with your infrastructure, so that was good to see at least.
970
01:15:19.610 --> 01:15:28.055
I think, Chivo's problems really rely on Beyond chain stuff that they've been doing where people will receive a or send a transaction, and then Chivo says it's canceled
971
01:15:28.435 --> 01:15:30.295
despite it being confirmed on the blockchain.
972
01:15:31.955 --> 01:15:32.455
Wow.
973
01:15:32.960 --> 01:15:34.660
That's pretty bad. I was unaware.
974
01:15:36.000 --> 01:15:43.825
Yeah. It's, they're not really helping themselves out over there in El Salvador from, you know, governments and Elis. My understanding is they've gotten a lot better.
975
01:15:44.445 --> 01:15:54.830
That that it was a it was a trash fire for the first while after it launched, but it it had gotten a lot better. But I haven't tried it. I don't know. Yeah. I mean, I think I think people have just
976
01:15:55.210 --> 01:15:57.485
given up on it at that point, though.
977
01:15:58.045 --> 01:16:03.744
There's a good Bitcoin Magazine article. I know it's kinda getting off in the weeds, but there's a good Bitcoin Magazine article
978
01:16:04.284 --> 01:16:14.930
of people trying to use it now, like, 1 year later, and and people have just sort of given up on on Bitcoin because of the Chivo experiences. So, I mean, that I mean, that kinda relates to Lightning. Right? Like, we have so many,
979
01:16:16.184 --> 01:16:18.764
bugs and exploits and issues with lightning,
980
01:16:19.304 --> 01:16:22.204
that we're that we're all kinda aping into
981
01:16:22.640 --> 01:16:31.540
right now too early, it's gonna leave a bad taste in the mouth. So maybe, like, the more responsible thing to do is kind of have a slow roller a a slow,
982
01:16:32.245 --> 01:16:35.865
rollout of of lightning instead of just jumping into it.
983
01:16:36.725 --> 01:16:39.070
Yeah. I mean, it's also important to note that
984
01:16:39.550 --> 01:16:40.690
folks in El Salvador
985
01:16:41.550 --> 01:16:42.929
some parts of El Salvador
986
01:16:43.469 --> 01:16:43.969
had
987
01:16:44.429 --> 01:16:48.210
real demand for the features that Bitcoin can provide for people.
988
01:16:48.614 --> 01:16:51.994
Others not so much. You know, it is a US dollar based economy.
989
01:16:52.375 --> 01:16:53.114
There wasn't
990
01:16:53.494 --> 01:17:02.730
you know, inflation's now high with dollars, but especially when that first rolled out, it wasn't, and there wasn't, you know, a lot of of user demand for it.
991
01:17:03.349 --> 01:17:10.075
You know, I'm much more interested in in parts of the world where where there is real user demand because Bitcoin provides a much more compelling,
992
01:17:10.855 --> 01:17:19.110
service compared to the alternatives. You know, your places like Nigeria, your places, you know, with there there's real issue with especially financial seizure,
993
01:17:19.730 --> 01:17:20.790
but also hyperinflation.
994
01:17:21.650 --> 01:17:24.230
And in those places, I think it's it's,
995
01:17:24.845 --> 01:17:35.040
you know, you you can't blame Chivo for all the problems is my point. It's also just that, like, for the most part, people in El Salvador didn't need Bitcoin. They didn't care about Bitcoin. Some people
996
01:17:35.340 --> 01:17:38.960
care about it now, and maybe with the the dollar inflation,
997
01:17:39.260 --> 01:17:40.720
they might care about it more.
998
01:17:41.100 --> 01:17:46.565
But in most parts of El Salvador, there wasn't you know, there are a lot of problems, but financial
999
01:17:47.265 --> 01:17:51.540
like, seizure of of financial assets was not not high on the list.
1000
01:17:52.660 --> 01:18:03.635
Well well, what about us, you know, United States citizens? I mean, do we need do we need Bitcoin, and do we need lightning at all? I mean, you could almost, like, say the same thing right there.
1001
01:18:06.095 --> 01:18:07.235
Yeah. That's true.
1002
01:18:07.535 --> 01:18:08.675
You know, I think
1003
01:18:09.320 --> 01:18:11.820
what what does need Bitcoin mean? You know, people
1004
01:18:12.360 --> 01:18:15.500
care about different things. And if
1005
01:18:15.880 --> 01:18:16.380
you
1006
01:18:16.965 --> 01:18:24.745
care about something that Bitcoin provides, it's great. You should totally use it. I think my point was more that the average person isn't sitting there considering,
1007
01:18:25.320 --> 01:18:28.380
you know, who their counterparty risk is when they're using the dollar.
1008
01:18:29.240 --> 01:18:40.445
And so to them, Bitcoin's not compelling. It's not solving a problem they see in their daily lives. You know, to those of us Bitcoin is in the west, you know, we might see real you know, like, personally,
1009
01:18:40.825 --> 01:18:52.915
I use lightning to pay for some server bills, not because, like, I don't like the dollar, but actually because it provides a better user experience and it's faster and more reliable than paying with a freaking credit card. And, like,
1010
01:18:53.235 --> 01:18:56.935
that's actually solving a problem for me that I had, you know.
1011
01:18:57.475 --> 01:18:58.295
And and,
1012
01:18:58.595 --> 01:19:08.900
you know, the to to folks in the US who are worried about all kinds of other issues, you know, Bitcoin is providing something that that is an issue to you. It's a little different if,
1013
01:19:10.204 --> 01:19:16.385
you you know, someone's telling you to adopt Bitcoin to solve something that is not already an issue in your mind.
1014
01:19:18.060 --> 01:19:34.545
And and so I I just I care more about places where, like, some people are already thinking about these issues and and the normal average person is already, like, this is a major issue. I need something to solve this issue. Oh, Bitcoin is a solution to this issue rather than
1015
01:19:34.930 --> 01:19:42.790
this isn't a problem for me. Why are you telling me to use Bitcoin? And then maybe a handful of people are like, oh, yeah. This is something I was thinking about and concerned about.
1016
01:19:52.470 --> 01:19:54.250
I guess another data point,
1017
01:19:55.270 --> 01:19:56.650
you know, just because
1018
01:19:57.030 --> 01:19:58.070
Matt brought up,
1019
01:19:58.550 --> 01:19:59.050
Nigeria,
1020
01:19:59.495 --> 01:20:00.555
There was that partnership,
1021
01:20:00.935 --> 01:20:01.995
with M Pesa,
1022
01:20:02.775 --> 01:20:08.155
that's now going to essentially open up Bitcoin to a lot more users through Bitnub,
1023
01:20:08.660 --> 01:20:10.840
and I believe that opens it up to,
1024
01:20:11.140 --> 01:20:15.800
like, 50,000,000 people. And then Cash App, previously, was probably the largest
1025
01:20:16.100 --> 01:20:16.920
with 44,000,000.
1026
01:20:18.645 --> 01:20:19.304
And then,
1027
01:20:20.324 --> 01:20:25.545
just understanding those, I guess, aren't necessarily, like, daily active users or whatever VCs,
1028
01:20:26.324 --> 01:20:27.784
wanna attribute them to,
1029
01:20:28.290 --> 01:20:31.730
but there might not be addresses either. It's in a weird,
1030
01:20:32.050 --> 01:20:33.670
metric they use where, essentially,
1031
01:20:34.130 --> 01:20:35.270
they have the capability
1032
01:20:35.810 --> 01:20:37.495
of buying it or doing something
1033
01:20:38.215 --> 01:20:38.855
with it. And,
1034
01:20:39.495 --> 01:20:41.275
that says something. Right? Like,
1035
01:20:41.735 --> 01:20:48.700
I don't know. It's, like, for them or they need it, but someone wants to build a service for that market.
1036
01:20:49.960 --> 01:20:59.965
But they couldn't I mean, they would experience downtime in the case of Barack's 2 bugs, but they wouldn't have they wouldn't lose money in that situation because, I mean,
1037
01:21:00.505 --> 01:21:02.685
all the all the major players updated
1038
01:21:03.065 --> 01:21:03.885
really quickly.
1039
01:21:04.860 --> 01:21:08.480
And they all, like, limit who their counterparties are on Lightning.
1040
01:21:10.139 --> 01:21:13.840
Yeah. And, I mean, if we wanna talk about, you know, positive outcomes here,
1041
01:21:14.265 --> 01:21:18.925
I don't know if if LND has done it, but certainly one thing we've been thinking about more,
1042
01:21:19.305 --> 01:21:22.685
to some extent as a result of this, but also just software maturing,
1043
01:21:23.460 --> 01:21:24.680
is how how we better
1044
01:21:25.140 --> 01:21:26.840
communicate quickly with people
1045
01:21:27.140 --> 01:21:27.640
when,
1046
01:21:29.300 --> 01:21:29.800
when
1047
01:21:30.525 --> 01:21:33.665
something like this happens or when you people need to upgrade urgently.
1048
01:21:34.765 --> 01:21:35.605
There's not
1049
01:21:36.045 --> 01:21:36.945
to my knowledge,
1050
01:21:37.620 --> 01:21:47.244
I don't know if if LND has, like, a a mailing list you can subscribe to or what. But, like, you know, how do you make sure engineers at Cash App and at Kraken and at River
1051
01:21:47.545 --> 01:21:48.284
get paged
1052
01:21:48.665 --> 01:21:54.125
when something like this happened and and and are are told to to move to a computer quickly. Right?
1053
01:21:54.670 --> 01:21:59.410
Versus just like, well, you gotta be following us on Twitter and and make sure you see it,
1054
01:21:59.870 --> 01:22:02.585
which isn't really a a sustainable outcome. And and,
1055
01:22:03.145 --> 01:22:05.725
you know, some companies have engineers who follow
1056
01:22:06.105 --> 01:22:11.245
Bitcoin Twitter personalities, but but others don't. And they shouldn't necessarily need to in order to discover,
1057
01:22:11.719 --> 01:22:13.659
issues that they need to to patch quickly.
1058
01:22:17.800 --> 01:22:24.025
Yeah. I think that's a fair point. I mean, I'm I'm not on Twitter myself. And if that's the only way to hear about these things, then,
1059
01:22:24.725 --> 01:22:36.990
you know, they they they do have a very extensive email list that they send out every other month to get feedback from people, but haven't heard anything from that about security patches.
1060
01:22:37.675 --> 01:22:41.135
So, Tony, I mean, you're not on Twitter. How did you find out about the bug?
1061
01:22:41.755 --> 01:22:44.015
I get people on Twitter to tell me things.
1062
01:22:44.750 --> 01:22:48.030
Ben Ben Carm, it's always telling me about l and d bugs.
1063
01:22:48.590 --> 01:22:50.369
So he's he's my source.
1064
01:22:51.150 --> 01:22:55.365
And then I'm Ben's source, and shout out to Richard Saffer
1065
01:22:55.825 --> 01:22:56.325
who's,
1066
01:22:56.705 --> 01:23:02.310
DevOps at Zebedee. He's the one who filed the original issue for the first block parsing bug,
1067
01:23:02.790 --> 01:23:03.850
on l and d.
1068
01:23:07.190 --> 01:23:13.795
So it's all personal connections. And if you don't know enough, big partners, you're, you're gonna get your money stolen because you're not gonna know the upgrade.
1069
01:23:14.415 --> 01:23:16.835
So you won't discover it
1070
01:23:17.250 --> 01:23:22.950
as fast as you might have otherwise. But I'm sure if you hung out in the l and d Slack, you are fine.
1071
01:23:23.410 --> 01:23:30.555
So there's wait. There's 2 there's 2 different when we're talking about bugs like this, there's there's basically 2 different classes of users. There's, like,
1072
01:23:32.375 --> 01:23:33.675
the almost, like, institutionalized
1073
01:23:34.055 --> 01:23:35.755
user or the corporate user,
1074
01:23:36.760 --> 01:23:39.500
and then there is that end user.
1075
01:23:41.960 --> 01:23:42.940
The end user,
1076
01:23:43.275 --> 01:23:49.215
like, the sovereign node runner, like, we have obviously some issues there in communication.
1077
01:23:51.650 --> 01:23:54.710
But on the on, like, the corporate side
1078
01:23:56.370 --> 01:23:58.550
on the corporate side, is there
1079
01:23:59.745 --> 01:24:02.085
is there something to be said about,
1080
01:24:02.785 --> 01:24:09.420
like, what bottle pay was I I think Youse released it. I think he called it multiplexer where essentially
1081
01:24:10.040 --> 01:24:11.580
you're running multiple nodes,
1082
01:24:12.120 --> 01:24:15.180
of different implementations. Like, Corelightning didn't go down here.
1083
01:24:16.275 --> 01:24:18.135
Is there is there a strong argument
1084
01:24:18.435 --> 01:24:23.895
that the corporate users should essentially just be running multiple lightning implementations at the same time?
1085
01:24:24.940 --> 01:24:27.600
So I don't think use multi I think use multiplexer,
1086
01:24:28.380 --> 01:24:30.640
supports running multiple LND nodes.
1087
01:24:32.220 --> 01:24:32.720
So
1088
01:24:33.445 --> 01:24:34.985
I don't think that's that
1089
01:24:35.525 --> 01:24:39.465
helps here. I know some corporates have built their own solutions for running,
1090
01:24:40.164 --> 01:24:46.940
multiple nodes or at least have talked to me about it. I I don't know that they've actually built it fully or rolled it out.
1091
01:24:47.640 --> 01:25:00.739
I think that's a a valid a valid point to make sure you don't have downtime, but it doesn't protect you from funds loss. And in fact, it it makes your funds loss exposure worse. Right? Because then if any issue, any, implementation has has a bug, you can lose some money.
1092
01:25:02.160 --> 01:25:18.110
At at at the very least, we need we desperately need, like, multi node implementation watchtowers. Like and and I don't think we talked about it here yet, but or maybe we hinted at it. But, you know, l and d nodes can only talk to l and d watchtowers currently.
1093
01:25:18.810 --> 01:25:19.310
So,
1094
01:25:19.770 --> 01:25:20.350
you know,
1095
01:25:21.105 --> 01:25:34.950
you would be affected by this. And if you had your own watch tower running and you didn't update that in time either, then you would be you would you wouldn't be helped at all. Sure. If you outsource your watch tower to, like, a responsible node runner,
1096
01:25:35.570 --> 01:25:41.335
that is, like, servicing a bunch of users, you you could probably expect that they're at least doing a good service,
1097
01:25:42.355 --> 01:25:44.375
a good good service of running watchtowers,
1098
01:25:44.835 --> 01:25:47.495
even if they are on the same node implementation. But,
1099
01:25:48.130 --> 01:25:54.070
we we desperately need multi node watch towers, the very least. Because these bugs broke the watch towers as well.
1100
01:25:54.530 --> 01:26:00.055
Yeah. Well, the l and d watch tower was also broken, and l and d can only talk to l and d watchtowers.
1101
01:26:00.675 --> 01:26:03.735
Yeah. So there's two points here. There is actually a third party watchtower,
1102
01:26:04.355 --> 01:26:05.495
guy Guy Sergio,
1103
01:26:06.040 --> 01:26:16.615
who who Spiral has funded for, several years has won. I believe it currently only supports Core Lightning because Core Lightning is the only node implementation that has enough hooks,
1104
01:26:17.155 --> 01:26:21.655
for it to support. I'm kind of embarrassed that LDK doesn't, but LND certainly doesn't.
1105
01:26:23.210 --> 01:26:33.105
So you you can use that. That does exist. However, it is, again, useful to note that in order for a watchtower to you know, we mentioned that there's 2 kinds of,
1106
01:26:34.525 --> 01:26:37.425
ways you can exploit this class of vulnerability, both
1107
01:26:37.965 --> 01:26:39.335
stealing funds from,
1108
01:26:40.040 --> 01:26:47.020
by broadcasting an old revoked state, and there, a watchtower will get your money back. But if you steal funds using the HTLC,
1109
01:26:48.455 --> 01:26:53.675
logic, if you have a a an HTLC that's routed through you and then someone steals funds using that,
1110
01:26:54.055 --> 01:26:54.555
then,
1111
01:26:55.255 --> 01:26:56.075
you can't,
1112
01:26:58.110 --> 01:27:03.010
use a watchtower currently. And in order to use a watchtower, watchtowers would have to
1113
01:27:03.710 --> 01:27:04.210
expose
1114
01:27:04.510 --> 01:27:05.310
a lot of
1115
01:27:05.965 --> 01:27:09.184
you don't have to expose a lot of information about your channels to that watchtower.
1116
01:27:10.684 --> 01:27:17.570
Losing, you know, one of the pitch of watchtowers today is that they're they're private, that they don't learn about your payment history, about your,
1117
01:27:18.030 --> 01:27:23.730
all the details of your node, and you would have to actually expose all that information to a watchtower to enforce HTLC,
1118
01:27:24.695 --> 01:27:25.594
claims correctly.
1119
01:27:26.054 --> 01:27:31.310
So it would require a bit of a change to the watchtower model. Currently, I don't think anyone's working on that.
1120
01:27:32.270 --> 01:27:33.410
But in order to,
1121
01:27:34.670 --> 01:27:43.875
you know, I guess I guess the moral of the story is is set your HTLC maximum in flight configuration knobs down to a threshold you're okay with losing,
1122
01:27:44.335 --> 01:27:47.075
which is good for everyone's privacy in the network. So do it anyway.
1123
01:27:47.775 --> 01:27:49.235
Make sure you change that value.
1124
01:27:50.140 --> 01:28:05.835
Well, is it is it easy for people to change? That's always the the tough part for me. It's like I I have all these ideas of how to be how to have better privacy on lightning, and then it's like, well, none of these are easy to actually implement. I'm sure that Thank can do it. But yeah.
1125
01:28:06.650 --> 01:28:08.590
Yeah. I I don't know about lnd.
1126
01:28:09.290 --> 01:28:27.680
I assume at least Corelightning because it's very configurable, has the support for LDK does, if if you're using an LDK node, if you're writing code for an LDK node, you can do it. I would imagine LND does. I don't know for sure. If it doesn't, you should certainly nag them. But you should be able to configure this in your lightning node config or in your channel config to say, like,
1127
01:28:28.060 --> 01:28:30.160
max in flight lower than the total amount.
1128
01:28:30.725 --> 01:28:35.065
At least set it less than half. Ideally set it maybe to a quarter of your channel balance,
1129
01:28:35.685 --> 01:28:37.540
or the maximum you're willing to lose.
1130
01:28:38.100 --> 01:28:41.320
Or or maybe it should just be defaults even on a certain point.
1131
01:28:41.620 --> 01:28:51.055
It it really should be. This is only a more recent discussion that we had in the Oakland lightning dev lightning dev summit that we should default this to below,
1132
01:28:51.595 --> 01:28:54.530
below half the channel balance at least, if not less.
1133
01:28:55.150 --> 01:28:58.929
I don't know which nodes, if any, have deployed that default change.
1134
01:28:59.230 --> 01:29:01.345
I'm not even sure if we got around to it yet.
1135
01:29:01.905 --> 01:29:04.565
But but if you do have that setting set,
1136
01:29:04.945 --> 01:29:11.125
then LDK nodes, including Cash App, will slightly prefer to route through you. So maybe you'll actually
1137
01:29:12.200 --> 01:29:15.980
make some some additional get some additional HTLCs and routing revenue,
1138
01:29:16.440 --> 01:29:20.300
to pay for the the reduction in capacity that you that you have in the channel.
1139
01:29:21.045 --> 01:29:24.025
You can, actually set these values in your LDconf,
1140
01:29:24.565 --> 01:29:26.665
I believe, also with their API.
1141
01:29:27.205 --> 01:29:28.345
So I think,
1142
01:29:29.219 --> 01:29:31.320
the only one I'm unsure of is eclair,
1143
01:29:32.900 --> 01:29:35.640
but, I I think everyone allows you to set those values.
1144
01:29:39.335 --> 01:29:52.070
Yeah. But but, like, what Umbro user is, like, going into their their configs and, like, writing writing text into them? You know? That that's the only thing I have to say about that. Like, I I know defaults are very hot topic in Bitcoin,
1145
01:29:52.610 --> 01:30:00.985
but maybe it's one of those situations where, like, this is just better for the whole network. Let let's just go ahead and do it. But, I'm glad to know that there's there's conversations around it now.
1146
01:30:12.115 --> 01:30:14.055
Yeah. I mean, from that, like, that perspective,
1147
01:30:14.515 --> 01:30:16.135
like, I still feel like
1148
01:30:17.555 --> 01:30:18.055
I
1149
01:30:18.650 --> 01:30:24.030
like, Carollo, I'm I'm kind of curious. Like, so you you think just unequivocally
1150
01:30:24.730 --> 01:30:26.910
the way Barak proceeded with
1151
01:30:28.225 --> 01:30:31.765
just executing these bugs by issuing a transaction
1152
01:30:32.465 --> 01:30:37.470
was not the way of doing it. There was no benefit of doing it in that way rather than going through normal
1153
01:30:39.470 --> 01:30:39.970
channels.
1154
01:30:40.990 --> 01:30:43.650
Yeah. I I don't think there's any reason to
1155
01:30:44.350 --> 01:30:44.850
exploit
1156
01:30:45.235 --> 01:30:46.695
something like this unless,
1157
01:30:48.675 --> 01:30:53.415
unless it's already been patched, unless people have had, you know, at least a little bit of a chance to upgrade.
1158
01:30:53.980 --> 01:30:55.520
You know, you you can debate,
1159
01:30:55.900 --> 01:31:00.400
I think, what the time period after a release with a patch,
1160
01:31:00.835 --> 01:31:03.735
at what point it makes sense to exploit something like this,
1161
01:31:04.514 --> 01:31:06.135
after that patch has been shipped.
1162
01:31:08.440 --> 01:31:09.580
But I don't know
1163
01:31:09.960 --> 01:31:17.020
what that number is. And I I I think it's definitely not negative. It's definitely not before a patch has been made available or at least made public
1164
01:31:17.645 --> 01:31:20.945
that it makes sense to to do this kind of exploit.
1165
01:31:21.885 --> 01:31:32.449
You know, every exploit is unique. Every every vulnerability, every bug is unique in terms of what the specific outcomes are, what the specific, you know, ways it can be exploited,
1166
01:31:33.710 --> 01:31:46.275
ways you can potentially mitigate, all that kind of good stuff. So, you know, it depends a lot on the context. It always depends on the context, but I think that's even more reason to make sure you reach out to the vendor before you before you do anything
1167
01:31:46.750 --> 01:31:55.170
because the vendor you know, some vendors are shitty. I think in Bitcoin, we're pretty lucky. None of the vendors are are really shitty generally. At least to my knowledge, everyone
1168
01:31:55.475 --> 01:31:57.655
takes these kinds of things seriously and appreciates,
1169
01:31:59.555 --> 01:32:00.775
vulnerability reports
1170
01:32:01.155 --> 01:32:07.489
even if it's from somebody they don't like or if it's from someone who's be doing it, you know, rudely or whatever.
1171
01:32:08.190 --> 01:32:11.409
Obviously, that that doesn't apply here, but just, you know, in general,
1172
01:32:12.375 --> 01:32:22.020
vendors can be shitty when you report stuff to them and and some people are are shitty when they do report stuff to you. But I think everyone's pretty pretty chill in the Bitcoin world about this kind of thing.
1173
01:32:22.719 --> 01:32:35.415
So it always makes sense to to reach out to the vendor first. Get their take. Get make sure you're on the same page in terms of how this can be exploited, what the the consequences of it, what you can do to prevent
1174
01:32:35.875 --> 01:32:36.375
exploits,
1175
01:32:36.835 --> 01:32:37.655
taking off,
1176
01:32:38.350 --> 01:32:46.770
and then take action. And I don't I don't think it ever makes sense to take action before you've at least reached out to the vendor initially and and and flagged it to them.
1177
01:32:49.135 --> 01:32:50.755
So, I mean, from my perspective,
1178
01:32:52.335 --> 01:32:54.035
it kind of felt like
1179
01:32:54.415 --> 01:32:56.275
enlightening development world
1180
01:32:56.640 --> 01:32:59.620
or just like enlightening network land in general.
1181
01:33:00.480 --> 01:33:01.940
It it kind of felt like
1182
01:33:03.775 --> 01:33:04.675
it kind of felt
1183
01:33:05.135 --> 01:33:05.635
like,
1184
01:33:07.054 --> 01:33:07.554
assumptions
1185
01:33:08.014 --> 01:33:14.970
were a bit naive, and a lot of it was glossed over with, like, hashtag reckless or whatnot, but, like, real funds are on the line,
1186
01:33:15.430 --> 01:33:17.130
and they're all hot wallets.
1187
01:33:19.270 --> 01:33:23.015
This kind of the way Barack did it to me felt like
1188
01:33:23.475 --> 01:33:27.655
a shot across the bow, like, we are entering an adversarial environment.
1189
01:33:29.260 --> 01:33:30.400
Consider the risks.
1190
01:33:30.940 --> 01:33:33.200
And I think a lot of users, as a result,
1191
01:33:34.060 --> 01:33:40.815
now have a different feeling. Particularly, node runners have a different, you know, perspective on lightning. They're more aware of the trade offs.
1192
01:33:41.675 --> 01:33:51.520
But I think that that's separate. Right? That that's a separate question. Right? So, like, you know, should is the lightning development world not are lightning node vendors,
1193
01:33:52.460 --> 01:33:56.165
accurately communicating the risks? I think the answer you you're right. They're not,
1194
01:33:56.645 --> 01:34:02.025
and that that needs to change. And that's something that's that's frustrated me in a few contexts across the lightning space.
1195
01:34:03.045 --> 01:34:04.745
And so, you know, I I think
1196
01:34:05.460 --> 01:34:08.760
Lightning node vendors generally need to do a better job at that. Totally.
1197
01:34:09.620 --> 01:34:14.280
It's a separate question as to whether or not to exploit something before there's a patch.
1198
01:34:14.725 --> 01:34:21.065
And then, you know, if you if your goal is to have a similar outcome of, like, making sure it's clear
1199
01:34:21.764 --> 01:34:22.264
that
1200
01:34:22.659 --> 01:34:23.159
they,
1201
01:34:23.540 --> 01:34:27.400
that users see this and feel urgency to upgrade,
1202
01:34:28.340 --> 01:34:32.119
generating a similar feeling. You could say, you know, exploit it,
1203
01:34:32.785 --> 01:34:41.365
you know, 8 hours after the patch is released or something. You know? Make sure people have a have a chance to upgrade, you know, even the people who were asleep at the time the patch was released, whatever,
1204
01:34:42.160 --> 01:34:45.219
and and then do it. You know, I I I don't think that's
1205
01:34:46.000 --> 01:34:58.370
I don't know that I would decide to to exploit it that quickly, but you you could make an argument for that and that becomes more of a a value judgment that we'd have to debate. And I don't think there's, like, a correct answer. There's never a correct answer or you know?
1206
01:34:59.870 --> 01:35:00.350
So
1207
01:35:01.070 --> 01:35:04.450
but but doing it beforehand, I think, is a little different.
1208
01:35:05.035 --> 01:35:12.255
And and certainly, you know, another part of responsible something that's not a part of responsible disclosure is how it gets communicated. Right? So,
1209
01:35:13.190 --> 01:35:17.290
the vendor always vendors always wanna choose how something gets communicated,
1210
01:35:17.670 --> 01:35:23.275
but that's ultimately not just their choice. That's also the reporter's choice. Right? So if the reporter is like,
1211
01:35:23.975 --> 01:35:31.240
you know, I think this is a huge deal and you're not doing a good job of communicating it, the reporter is totally free to go on Twitter and say, like,
1212
01:35:31.800 --> 01:35:32.860
vendor is moron.
1213
01:35:33.320 --> 01:35:34.380
Screw this vendor.
1214
01:35:34.760 --> 01:35:42.515
They're not telling you the the real story, and this is a huge deal, and you need to upgrade ASAP and, like, your funds are at risk and look, here's why.
1215
01:35:43.235 --> 01:35:46.375
That's totally legitimate. That's that's not you know, how
1216
01:35:46.675 --> 01:35:47.815
an issue gets communicated
1217
01:35:48.195 --> 01:35:49.739
is not a part of responsible disclosure.
1218
01:35:50.360 --> 01:35:55.739
Your your duty is to the users to make sure you minimize the risk that users lose funds,
1219
01:35:56.365 --> 01:35:59.025
But there's a lot that goes into that
1220
01:35:59.325 --> 01:35:59.825
and,
1221
01:36:00.445 --> 01:36:03.345
you know, there's no correct answer. Again, everything's unique.
1222
01:36:05.005 --> 01:36:05.450
But
1223
01:36:06.330 --> 01:36:07.530
I I think it it it
1224
01:36:08.490 --> 01:36:12.510
I I think it's pretty clear that exploiting this before there's a patch
1225
01:36:12.890 --> 01:36:13.870
does not minimize
1226
01:36:14.410 --> 01:36:17.905
user risk. I think it it it's pretty clear that there are
1227
01:36:18.284 --> 01:36:21.025
many different ways to go about this that might get
1228
01:36:21.804 --> 01:36:26.440
similar responses in every way that would have minimized the risk a little more
1229
01:36:26.980 --> 01:36:29.880
by just waiting to exploit it until after there was a path.
1230
01:36:32.835 --> 01:36:38.295
What what about the scenario? So there there are multiple vendors here that that had the issue. Right?
1231
01:36:38.910 --> 01:36:41.890
Now, of course, Brock was honing on a specific one,
1232
01:36:43.230 --> 01:37:01.480
and and there's a lot more that that we found out. How from the vendor approach, what would have been what would have been, like, a reasonable thing to do? Because I I could be wrong, but I think I remember years back, Bitcoin Core had this scenario where there was a responsible disclosure to Bitcoin Core from from some shitcoin Bitcoin side chain thing.
1233
01:37:02.340 --> 01:37:07.554
And Bitcoin Core fixed it and then released, you know, released it, but the other chains,
1234
01:37:08.415 --> 01:37:17.610
were vulnerable to it. Now you could argue, you know, fuck those shit coins or whatever. But when there's an issue that could be affecting everyone, but only one party knows about it,
1235
01:37:18.230 --> 01:37:20.315
is is that a problem at all?
1236
01:37:21.835 --> 01:37:23.135
Yeah. Who who's
1237
01:37:23.675 --> 01:37:30.790
who do you owe a duty of care to is is a huge question that has no answer. There you're right. There were a lot of discussions
1238
01:37:31.730 --> 01:37:33.510
around that bug, around
1239
01:37:33.890 --> 01:37:37.805
do Bitcoin Core developers have a duty of care to every random,
1240
01:37:39.705 --> 01:37:43.245
fork of Bitcoin Core building any random coin.
1241
01:37:44.260 --> 01:37:44.840
You know,
1242
01:37:45.940 --> 01:37:47.320
I personally think they don't.
1243
01:37:48.260 --> 01:37:54.120
That's just my view. You know, I don't think I think Bitcoin Core developers have a duty of care to Bitcoin users,
1244
01:37:55.965 --> 01:38:00.185
and not a legal duty of care, mind you, but but, you know, a moral duty of care
1245
01:38:01.460 --> 01:38:08.199
and and not to anyone else. And that, you know, insofar as you can do anything to to avoid other people getting screwed,
1246
01:38:08.500 --> 01:38:09.239
you should.
1247
01:38:09.540 --> 01:38:12.415
But, certainly, you don't have a duty of care,
1248
01:38:13.835 --> 01:38:19.215
where it might impact where it might negatively impact Bitcoin users. And that includes, you know, if you tell
1249
01:38:19.970 --> 01:38:21.030
with any vulnerability
1250
01:38:22.210 --> 01:38:49.465
the, you know, one thing that that you have to maximize, you have to make sure you don't tell any more people that need to know. Right? That that kind of information should always be need to know because, you know, any additional people you tell, they might tell their friend and their friend might exploit it or they might have it up on their screen at a conference and somebody might read it and exploit it or or what have you. And especially when you're talking about other coins, you know, that that can be a very adversarial relationship. So I do know, you know, when it was
1251
01:38:50.245 --> 01:39:01.900
disclosed by Bitcoin Core or maybe kind of an hour before or something like that. You know, once once it was clear that Bitcoin was a little safer and then when it was going to go public anyway, a number of people were notified,
1252
01:39:02.245 --> 01:39:05.065
you know, kind of immediately prior or maybe an hour before,
1253
01:39:06.485 --> 01:39:11.865
to make sure they had at least a little bit of a chance to to catch up and and fix their own stuff.
1254
01:39:12.930 --> 01:39:20.790
I don't recall whether any other coins were. I think maybe, like, b cash was or something or, like, one
1255
01:39:21.715 --> 01:39:32.440
coin or 2 where there was, like, you know, at least a little bit larger market cap, at least a little bit larger user base, and some of the developers had had a history of being reasonable,
1256
01:39:32.820 --> 01:39:35.880
even if their community maybe wasn't, their their developers were.
1257
01:39:37.324 --> 01:39:42.545
But but no. I mean, I I don't think Bitcoin Core developers have a duty of care to other clients.
1258
01:39:44.500 --> 01:39:45.000
But
1259
01:39:45.380 --> 01:39:45.880
yeah.
1260
01:39:47.700 --> 01:39:48.200
Do
1261
01:39:48.580 --> 01:39:49.080
CLN
1262
01:39:49.700 --> 01:39:53.085
developers have any duty to to l and d developers?
1263
01:39:54.265 --> 01:39:55.725
I actually was just about
1264
01:39:56.185 --> 01:39:57.145
to bring that up.
1265
01:39:57.545 --> 01:39:58.765
Matt brought up communications
1266
01:39:59.780 --> 01:40:01.000
of, disclosures.
1267
01:40:02.020 --> 01:40:02.520
Brock,
1268
01:40:02.980 --> 01:40:05.000
why did you choose to
1269
01:40:05.380 --> 01:40:07.239
write what you did in the off return?
1270
01:40:11.125 --> 01:40:12.264
You still here, Brock?
1271
01:40:12.645 --> 01:40:20.559
Oh, yeah. I'm here. Yeah. It does for trolling. I just I just wanted to troll. I I guess yeah. I have a troll personality. I
1272
01:40:20.860 --> 01:40:26.315
just you know, I'm making this transaction and why not just put something in there? I just
1273
01:40:27.015 --> 01:40:28.555
yeah. I just put some message.
1274
01:40:29.175 --> 01:40:35.329
To to all the listeners tell the listeners you put in the op return, you'll run Core Lightning and be happy.
1275
01:40:35.869 --> 01:40:36.369
Yep.
1276
01:40:37.230 --> 01:40:39.170
It was, yeah, it was referenced to,
1277
01:40:40.429 --> 01:40:41.730
World Economic Forum.
1278
01:40:43.405 --> 01:40:43.905
Yeah.
1279
01:40:45.085 --> 01:40:48.900
That was for fun and for trolling. Yeah. Yeah. I I'm not sponsored
1280
01:40:57.295 --> 01:41:01.635
the message was for trolling. I have no problems whatsoever with Lining Labs.
1281
01:41:02.094 --> 01:41:04.114
I love folks working at Lining Labs.
1282
01:41:05.110 --> 01:41:07.370
In fact, in favor of multiple implementations,
1283
01:41:08.390 --> 01:41:12.970
whether it's LND and CLN or other Bitcoin query implement other Bitcoin implementations,
1284
01:41:13.785 --> 01:41:15.165
I don't have any problem.
1285
01:41:15.465 --> 01:41:15.965
I
1286
01:41:16.745 --> 01:41:17.725
I'm just trolling.
1287
01:41:21.469 --> 01:41:23.650
Well, Tony, there is your answer.
1288
01:41:24.190 --> 01:41:24.690
We
1289
01:41:25.310 --> 01:41:27.170
have a duty of care, but
1290
01:41:27.630 --> 01:41:28.849
that was just trolling.
1291
01:41:29.595 --> 01:41:35.135
We have a duty of care to each other. You know? As anyone that's part of the Bolt compliance spec,
1292
01:41:35.515 --> 01:41:36.495
we work together
1293
01:41:37.250 --> 01:41:39.110
as much as possible. I consider
1294
01:41:40.050 --> 01:41:43.110
Evan a good friend, Lalu as well, Con,
1295
01:41:44.905 --> 01:41:45.724
and, Sueb.
1296
01:41:46.344 --> 01:41:46.844
So,
1297
01:41:47.465 --> 01:41:48.125
you know,
1298
01:41:48.985 --> 01:41:52.284
we all, like, are in this community together, and I think
1299
01:41:52.830 --> 01:41:54.290
I also am a bit
1300
01:41:54.990 --> 01:41:57.650
guilty of this stirring the pot sometimes when,
1301
01:41:58.510 --> 01:42:00.610
you know, tempers get flared up about
1302
01:42:01.565 --> 01:42:02.945
decisions based on
1303
01:42:03.565 --> 01:42:07.485
upgrades or what priorities should be. But at the end of the day,
1304
01:42:08.125 --> 01:42:10.705
we're in this together, and I really value
1305
01:42:11.390 --> 01:42:13.570
everyone contributing to the Bolt specs.
1306
01:42:14.750 --> 01:42:18.040
I just wanted to say, you know, as a as a non dev,
1307
01:42:19.445 --> 01:42:21.065
who's been running lightning,
1308
01:42:21.685 --> 01:42:23.785
specifically l and d for 3 years,
1309
01:42:24.405 --> 01:42:26.105
extremely well connected node,
1310
01:42:27.760 --> 01:42:32.900
nearly 200 channels. I had more than that at one point. I have no idea who any of my counterparties are.
1311
01:42:34.160 --> 01:42:37.380
Part of the reason why I was running it was to see
1312
01:42:38.145 --> 01:42:41.844
if I would lose money, and I'm pretty sure I haven't lost money yet.
1313
01:42:44.465 --> 01:42:46.405
So, yeah, cheers to that.
1314
01:42:48.440 --> 01:42:49.820
Thank thank you for your service.
1315
01:42:51.960 --> 01:42:53.595
I mean, Matt, you kinda too.
1316
01:42:54.555 --> 01:42:59.455
Oh, yeah. Go ahead. Matt, you kinda brought it up earlier. We're saying, like, you know, we're not really in an adverse
1317
01:43:00.075 --> 01:43:02.840
sale environment at all. Barak's is, like,
1318
01:43:03.380 --> 01:43:09.400
quote, unquote attack is, like, signaling that. But, like, I mean, we definitely aren't. I I, like, when I went to Nashville,
1319
01:43:09.705 --> 01:43:13.085
like, earlier this year, my lightning node went down on the
1320
01:43:13.465 --> 01:43:14.585
plane over, and that was,
1321
01:43:15.545 --> 01:43:25.370
you know, I never I don't lose any money either. So, like, people could have clearly stolen from me and didn't. You know, it's it's definitely not a non air Australian environment and
1322
01:43:26.455 --> 01:43:27.755
I don't know. Hopefully hopefully
1323
01:43:28.135 --> 01:43:29.595
is is bad, but, like,
1324
01:43:30.295 --> 01:43:41.450
we need to get there. Like, if we're in there, that means it's like lightning is a lot more legit. It's not just like, you know, attacks or trolls anymore. It's like actually, like, people trying to steal money and potentially profiting
1325
01:43:41.815 --> 01:43:42.554
from it.
1326
01:43:42.934 --> 01:43:43.434
But
1327
01:43:43.815 --> 01:43:47.955
I don't know if we're there yet, but it'd be cool to actually see real
1328
01:43:48.295 --> 01:43:53.840
feel like you know, because, like, in the DeFi space, something like this is like a full time job of people
1329
01:43:54.300 --> 01:43:55.600
Bitcoin projects. So
1330
01:43:55.980 --> 01:44:00.665
it'd be, you know, scary but also cool to see people doing the same thing in light.
1331
01:44:04.725 --> 01:44:08.344
Yeah. I think we'll get there eventually, but I'm not in any rush.
1332
01:44:08.990 --> 01:44:20.995
Thanks for the conversation, Paul. I I actually have to dip. I've gotta go to a dinner. Which is cool. Yeah. I was the Matt, I was about to wrap up. Thank you for joining us. You wanna just give us your final thoughts real quick before you wrap?
1333
01:44:22.815 --> 01:44:33.435
You know, I don't I don't know if I had any specific final thoughts. No. These issues are tricky. There's there's a lot that goes into them. There's there's usually no no clear answer. There's there's better things. There's worse things.
1334
01:44:33.995 --> 01:44:41.135
But I just, you know, keep keep in mind that that as humans, we wanna we wanna help each other, at least as as non
1335
01:44:41.595 --> 01:44:52.675
you know, we we we should just, you know, do do what you think is right for the for the people, not for the vendor or anybody else. But thanks for having me on. Out. Thanks, Matt. Appreciate you. Evan, final thoughts.
1336
01:44:54.335 --> 01:44:55.155
Yeah. So,
1337
01:44:56.335 --> 01:44:58.435
you know, I think there's a great discussion today.
1338
01:44:59.220 --> 01:45:06.040
Barak, I think, you got your taste of the dark side. I hope moving forward, you consider coming back to the light.
1339
01:45:06.695 --> 01:45:12.074
I I know our community has a lot of values of, like, anarchism, but that still requires cooperation for,
1340
01:45:13.015 --> 01:45:15.195
you know, the benefit of the community.
1341
01:45:15.540 --> 01:45:17.080
And, you know, ultimately,
1342
01:45:17.620 --> 01:45:21.239
I think you're a really talented guy. Just, we hate for you to keep going down
1343
01:45:22.020 --> 01:45:22.760
on this
1344
01:45:23.805 --> 01:45:24.364
path and,
1345
01:45:25.805 --> 01:45:31.505
there's positives to this, but, you know, it's not something I would like to see happen again.
1346
01:45:32.949 --> 01:45:33.849
Thanks, Evan.
1347
01:45:36.469 --> 01:45:37.690
Vivek, final thoughts.
1348
01:45:39.545 --> 01:45:44.285
Thanks for having us on to even discuss this, man. I know it's kind of a touchy subject.
1349
01:45:45.305 --> 01:45:50.699
Wanted to thank everyone that actually joined. Felt it was great that, we had Evan and,
1350
01:45:51.960 --> 01:45:53.659
Matt Corallo here, especially.
1351
01:45:54.679 --> 01:46:00.495
Ben, fix your Internet, and thank you all freaks for listening to us. Thanks, Vivek. I hope,
1352
01:46:01.135 --> 01:46:08.500
I really want dispatch to be a place where people are comfortable having open discussion, and I really like wrangling people for these these round tables.
1353
01:46:09.280 --> 01:46:10.420
Ben, final thoughts.
1354
01:46:12.160 --> 01:46:14.660
Thought, fuck Google Fiber, and,
1355
01:46:16.255 --> 01:46:18.755
you know, that I'll I'll stick with that.
1356
01:46:20.175 --> 01:46:22.275
Thanks, Ben. Tony, final thoughts.
1357
01:46:23.535 --> 01:46:24.915
Great discussion, guys.
1358
01:46:26.640 --> 01:46:27.140
Yeah.
1359
01:46:27.520 --> 01:46:32.820
I I think I think all, you know, all things like this make Bitcoin better in the end. So,
1360
01:46:33.585 --> 01:46:37.684
Barak, if you wanna coordinate on more dark side things, let me know.
1361
01:46:39.665 --> 01:46:41.844
Thanks, Tony. Barak, final thoughts.
1362
01:46:42.320 --> 01:46:48.580
Yeah. I I I personally see Lightning as a better software, and it has a long way to go. I personally think 5,
1363
01:46:49.095 --> 01:46:52.875
5,000 Bitcoin is a joke number. I still see lightning as a playground.
1364
01:46:54.055 --> 01:46:58.235
And, yeah, I love breaking things and I besides, I believe,
1365
01:46:58.790 --> 01:46:59.930
attacks help Bitcoin,
1366
01:47:00.470 --> 01:47:00.970
helps,
1367
01:47:01.910 --> 01:47:05.290
hardening the the software, the infrastructure for long term stability.
1368
01:47:06.645 --> 01:47:13.225
I'm not saying this in defense of my actions. I'm just saying this as thought as my as as my thought thought consideration.
1369
01:47:15.619 --> 01:47:18.920
My only motive was for fun, and I guess,
1370
01:47:19.460 --> 01:47:22.840
I'll I'll dig more into codebase and see if there are any other exploits.
1371
01:47:24.185 --> 01:47:30.605
Thanks, Barack. I appreciate you. You're always welcome on dispatch, and I I hope you and Tony continue to, attack me.
1372
01:47:31.225 --> 01:47:35.840
I do appreciate it. To all the freaks, I wanna thank you for joining us for this conversation,
1373
01:47:37.100 --> 01:47:43.095
particularly the freaks who joined us in the live chat. I know it's a Friday evening. I know it's a crazy week,
1374
01:47:43.475 --> 01:47:45.895
but you guys make it special. Once again,
1375
01:47:46.275 --> 01:47:50.080
dispatch has no ads or sponsors. It's funded purely by you guys.
1376
01:47:50.699 --> 01:47:53.280
There's a lot of value for value haters out there,
1377
01:47:55.100 --> 01:48:08.310
including some people I've recorded podcasts with in the past. I think we can prove them wrong. I think most people are just half in, half out and not actually trying to make value for value work. So I do appreciate you guys seeing seeing the stats flow and seeing
1378
01:48:08.850 --> 01:48:20.515
dispatch consistently on the top of the fountain leaderboards really makes it all worth it. I appreciate you all. Once again, it is a bear market. If you can't contribute stats, sharing with your friends and family helps, subscribing in your favorite podcast app helps,
1379
01:48:20.990 --> 01:48:25.630
Subscribing on YouTube, Twitch. I mean, don't use YouTube. But if you are gonna use YouTube, subscribe to the channel.
1380
01:48:27.390 --> 01:48:34.955
It it is appreciated. Every little bit helps, and, it keeps us going forward. I wanna say to all the freaks, I know it's been a long week.
1381
01:48:35.970 --> 01:48:40.630
It's mostly Shitcoiners playing Shitcoin games. Fiat Maximal is playing Fiat games.
1382
01:48:41.970 --> 01:48:43.270
Bitcoin remains unaffected.
1383
01:48:43.935 --> 01:48:46.675
I love you all. We're gonna keep moving forward here.
1384
01:48:48.014 --> 01:48:52.594
We can't be stopped if we if if we work together. So I appreciate everybody.
1385
01:48:53.699 --> 01:48:54.679
Have a great weekend.
1386
01:48:55.699 --> 01:48:57.159
Stay humble, stack sets.
NOTE
Transcription provided by Podhome.fm
Created: 3/25/2024 10:10:55 PM
Duration: 6541.427
Channels: 1
1
00:00:33.250 --> 00:00:39.190
2
00:00:40.285 --> 00:00:40.945
Citadel Dispatch
3
00:00:41.325 --> 00:00:45.505
is a interactive live show about Bitcoin and Freedom Tech.
4
00:00:45.885 --> 00:00:47.905
We have no ads, no sponsors.
5
00:00:48.680 --> 00:00:49.180
It
6
00:00:49.560 --> 00:00:54.620
is only possible thanks to our great listeners who continue to support the podcast,
7
00:00:55.320 --> 00:01:00.775
whether that's with stats through podcasting 2.0. Podcasting 2.0 allows you to just
8
00:01:01.715 --> 00:01:02.775
download an app.
9
00:01:03.155 --> 00:01:05.175
Big ones are fountain podcast, Breezewallet,
10
00:01:05.530 --> 00:01:06.030
podverse.fm,
11
00:01:06.890 --> 00:01:07.390
echoln.com,
12
00:01:08.409 --> 00:01:09.229
and others.
13
00:01:10.250 --> 00:01:14.670
You download the app. You load it up with stats. You search Siddle Dispatch. You press subscribe.
14
00:01:15.325 --> 00:01:20.305
Choose how many sats per minute you think this show is worth, and then those sats automatically,
15
00:01:21.725 --> 00:01:28.780
get streamed directly to my lightning node. It is extremely cool seeing all the sats come in. You can also
16
00:01:29.479 --> 00:01:30.520
support the pod,
17
00:01:30.920 --> 00:01:33.740
through podcasting 2.0 through something called boostograms.
18
00:01:34.345 --> 00:01:36.205
Boostagrams are a single payment
19
00:01:36.585 --> 00:01:39.645
that include a comment or message with,
20
00:01:40.345 --> 00:01:42.925
the payment. I read the top 4 Boostagrams
21
00:01:43.610 --> 00:01:44.909
from the last episode.
22
00:01:45.850 --> 00:01:48.270
Every week, it's really great to see,
23
00:01:49.610 --> 00:01:51.150
your comments and your support.
24
00:01:51.665 --> 00:01:55.205
Before I read those Boostagrams, you can also support the show by going to sidildispatch.com/contribute.
25
00:01:57.104 --> 00:01:58.965
I have a BTC pay server there.
26
00:02:00.040 --> 00:02:04.700
You can support that using that either via via Onchain or Lightning.
27
00:02:05.400 --> 00:02:08.865
And I also have my BIP 47 payment code there,
28
00:02:09.565 --> 00:02:17.105
which you can support via Samurais or Sparrow wallets, and, that's attached to the associated pay name, Odell. Very easy to remember.
29
00:02:17.440 --> 00:02:20.260
I know it's a bear market. You can also support the show
30
00:02:20.640 --> 00:02:23.060
by simply sharing it with friends and family.
31
00:02:23.520 --> 00:02:26.180
Citadel dispatch is available on all major platforms,
32
00:02:27.205 --> 00:02:28.505
every podcast app,
33
00:02:28.885 --> 00:02:29.385
Twitch,
34
00:02:29.845 --> 00:02:30.905
Twitter, YouTube,
35
00:02:31.925 --> 00:02:36.030
Rumble, Bitcoin TV. You just search Citadel Dispatch, press subscribe, reviews help
36
00:02:36.330 --> 00:02:37.070
as well.
37
00:02:39.130 --> 00:02:44.190
Yeah. So thank you for your support, Freaks. I really do appreciate it. The show would not be possible
38
00:02:45.125 --> 00:02:45.865
without it.
39
00:02:46.325 --> 00:02:50.105
I also wanna thank the Freaks who joined us in the live chat.
40
00:02:50.805 --> 00:02:54.505
You're able to join the live chat either via YouTube or Twitch
41
00:02:55.030 --> 00:02:55.690
or Twitter
42
00:02:56.230 --> 00:02:57.530
or via Matrix.
43
00:02:57.910 --> 00:02:58.970
We have a Matrix
44
00:02:59.270 --> 00:03:00.890
chat that runs 247,
45
00:03:01.430 --> 00:03:01.930
365.
46
00:03:02.985 --> 00:03:08.125
Lot of great conversation there on and off the show. You can find links to all of these things
47
00:03:08.745 --> 00:03:10.205
at citadel dispatch.com.
48
00:03:11.569 --> 00:03:12.870
So with all that said,
49
00:03:14.050 --> 00:03:16.709
we have a great panel lined up.
50
00:03:17.410 --> 00:03:20.790
It's been about a week and a half in the making.
51
00:03:21.425 --> 00:03:25.845
We've been trying to get it out there ASAP because it's a very important topic.
52
00:03:26.145 --> 00:03:28.645
Ironically enough, in classic Bitcoin fashion,
53
00:03:30.090 --> 00:03:33.630
a bunch of things have happened over the last week as many of you are known.
54
00:03:34.010 --> 00:03:36.270
And, you guys might forget that
55
00:03:38.254 --> 00:03:40.114
that we had 2 major,
56
00:03:40.575 --> 00:03:44.834
lightning bugs over the last month or so, maybe, like, last 2 months,
57
00:03:45.375 --> 00:03:46.674
with one of them happening
58
00:03:47.360 --> 00:03:59.435
last week where we all had to update our l and d notes. So this topic will be focused on that plus lightning development going forward and just the current state of lightning development. Before I introduce our guests, I just wanna read the boostograms,
59
00:03:59.735 --> 00:04:00.955
the top 4 boostograms
60
00:04:01.334 --> 00:04:04.075
from last week. Once again, thank you, Freak, for your support.
61
00:04:04.549 --> 00:04:06.090
We have at Humble Pleb,
62
00:04:06.950 --> 00:04:08.489
gave 69 420.
63
00:04:10.069 --> 00:04:10.569
Nice.
64
00:04:11.564 --> 00:04:17.905
69 420 sats. I don't know. It looks like he tried to put some kinda emoji there that I can't read on Android,
65
00:04:18.925 --> 00:04:30.665
a bunch of times. Appreciate you, Freak. We have Eric 99 with 50,000 sats saying, stay humble, stack sats. Great advice. We have Chad Farrell with 50,000 sats saying, thanks for all that you do, Matt. And we have 8,
66
00:04:32.005 --> 00:04:32.825
with 7,778
67
00:04:34.165 --> 00:04:34.665
saying,
68
00:04:38.139 --> 00:04:39.680
I've been listening to a new
69
00:04:40.139 --> 00:04:49.985
privacy podcast, Watchmen Privacy. It could be interesting for you to appear on this pod or vice versa. He has a strong Bitcoin focus in his podcast when speaking on cryptocurrencies, which is rare for privacy gurus.
70
00:04:50.365 --> 00:04:51.985
His past guests include NVK,
71
00:04:52.445 --> 00:04:58.889
LOP, Zelco, s 21, Seth for privacy, Bitcoin q and a, and Eco. Wow. I'll go check that out. It was not on my radar.
72
00:04:59.430 --> 00:05:05.615
Appreciate you, Freaks. And, also, we have Vic in here, honorary mention with 5,000 sats. Right or die freak. Appreciate you, Veek.
73
00:05:06.875 --> 00:05:13.199
So thank you, Freaks, for supporting the show. We have Tony jumping in and out trying to troubleshoot. Tony, can you hear me?
74
00:05:16.060 --> 00:05:17.599
We cannot hear you, Tony.
75
00:05:18.575 --> 00:05:21.395
So I'm gonna introduce our guests. We have
76
00:05:23.695 --> 00:05:29.030
a long time listener and often guest of the podcast, Ben Carmen. How's it going, Ben?
77
00:05:34.290 --> 00:05:35.510
Can't hear you, Ben.
78
00:05:37.505 --> 00:05:38.005
Classic.
79
00:05:39.185 --> 00:05:44.005
We have Barack who I had the pleasure of meeting in Miami on the open source stage,
80
00:05:44.385 --> 00:05:45.685
that I helped coordinate.
81
00:05:46.300 --> 00:05:50.480
Barak was the one who discovered the last two lightning bugs. How's it going, Barak?
82
00:05:51.180 --> 00:05:55.040
83
00:05:55.485 --> 00:05:57.505
84
00:05:58.205 --> 00:06:00.384
85
00:06:01.565 --> 00:06:05.330
So I'm a Bitcoin dev. I mostly do some stuff on Liquid,
86
00:06:06.030 --> 00:06:08.290
and recently discovering Lightning Space.
87
00:06:09.310 --> 00:06:14.694
So I'm also known as the LND slayer, and I'm this bug eating this burger eating guy on Twitter.
88
00:06:15.235 --> 00:06:20.455
And happy to be here, guys, and add some you know, maybe give some details on what have happened,
89
00:06:21.770 --> 00:06:25.550
over the last few weeks and, you know, give some inputs and, you know,
90
00:06:25.930 --> 00:06:33.025
I'm not here to tell, you know, to tell whether my actions were good or bad. I think it's up to community to tell and, but I I can't tell you guys,
91
00:06:33.725 --> 00:06:36.065
what did happen and what my motive was.
92
00:06:36.445 --> 00:06:36.945
So,
93
00:06:37.860 --> 00:06:38.819
happy to be here.
94
00:06:39.539 --> 00:06:42.360
Hopefully, this is gonna be a a friendly conversation.
95
00:06:43.060 --> 00:06:44.360
96
00:06:45.845 --> 00:06:47.225
We got Evan Kaludis,
97
00:06:48.325 --> 00:06:52.745
also rider die freak, common common guest on the podcast. How's it going, Evan?
98
00:06:53.125 --> 00:06:54.905
99
00:06:55.630 --> 00:06:59.890
Doing doing great. Doing great. Yeah. Happy to be back on the show.
100
00:07:00.350 --> 00:07:03.570
Wish we were talking about a more positive topic,
101
00:07:03.884 --> 00:07:17.509
102
00:07:20.055 --> 00:07:21.835
103
00:07:22.775 --> 00:07:23.275
unnecessarily,
104
00:07:23.815 --> 00:07:28.730
105
00:07:29.430 --> 00:07:35.735
He's been on the podcast before and also has joined me with Marty on TFTC. How's it going, Matt?
106
00:07:36.534 --> 00:07:38.875
107
00:07:39.895 --> 00:07:41.914
108
00:07:43.390 --> 00:07:47.250
what's your what's your role at LDK? What would I call your role at LDK?
109
00:07:49.950 --> 00:07:52.290
110
00:07:53.275 --> 00:07:55.695
111
00:07:56.155 --> 00:07:59.535
LDK is one of, one of the top lightning implementations.
112
00:08:00.690 --> 00:08:01.490
We have,
113
00:08:01.889 --> 00:08:03.430
Vivek here, also
114
00:08:04.129 --> 00:08:06.710
repeat guest on the podcast. How's it going, Vivek?
115
00:08:08.025 --> 00:08:08.765
116
00:08:09.545 --> 00:08:10.365
going well.
117
00:08:11.705 --> 00:08:12.445
Just this
118
00:08:13.065 --> 00:08:13.565
and,
119
00:08:14.265 --> 00:08:15.245
yeah, explore
120
00:08:16.620 --> 00:08:18.639
is, and and
121
00:08:18.940 --> 00:08:19.419
what
122
00:08:22.915 --> 00:08:25.415
123
00:08:26.355 --> 00:08:29.655
It's probably because he stopped paying it because of the bear market.
124
00:08:31.099 --> 00:08:33.440
I don't know how we can fix that, Vivek.
125
00:08:33.899 --> 00:08:34.640
We have
126
00:08:35.260 --> 00:08:38.560
who did I not introduce? Tony. Can we hear you now?
127
00:08:38.995 --> 00:08:42.615
Can you? Yeah. We can. Long time since this is a podcast.
128
00:08:43.315 --> 00:08:44.215
How's it going?
129
00:08:44.755 --> 00:08:59.125
130
00:08:59.665 --> 00:09:00.725
131
00:09:01.825 --> 00:09:04.405
and he has this new tool called Ellen's Ploit,
132
00:09:05.130 --> 00:09:06.910
which makes it easier to attack
133
00:09:07.450 --> 00:09:07.950
lightning.
134
00:09:09.610 --> 00:09:12.590
So we will be talking all about that. And then I think
135
00:09:13.475 --> 00:09:16.935
Carmen didn't wasn't able to speak last time I introduced Carmen.
136
00:09:19.635 --> 00:09:21.894
Carmen, can you hear me? Carmen, can you speak?
137
00:09:24.720 --> 00:09:27.300
Okay. Well, we still cannot hear Carmen.
138
00:09:27.680 --> 00:09:28.740
139
00:09:29.040 --> 00:09:30.100
140
00:09:30.480 --> 00:09:30.980
141
00:09:32.175 --> 00:09:36.115
142
00:09:36.574 --> 00:09:37.555
works on Linux.
143
00:09:38.735 --> 00:09:41.235
144
00:09:41.710 --> 00:09:44.530
I ran the show from Linux for, like, 2 years.
145
00:09:46.510 --> 00:09:49.010
Ben is gonna switch switch computers.
146
00:09:49.390 --> 00:09:51.615
Okay, Ben. Switch computers and come back.
147
00:09:52.175 --> 00:09:53.154
Let's get started.
148
00:09:54.095 --> 00:09:56.675
I wanna thank the Freaks for for,
149
00:09:57.855 --> 00:09:59.530
this is a this is a big group,
150
00:10:00.010 --> 00:10:02.910
but it's a it's a great group, and I'm happy to have them here.
151
00:10:07.185 --> 00:10:08.225
Okay. And,
152
00:10:09.345 --> 00:10:16.230
so just I appreciate the freaks for sticking with us during connection issues and whatnot, considering we have so many people here.
153
00:10:17.350 --> 00:10:19.690
I guess I guess where to start is,
154
00:10:20.709 --> 00:10:23.529
Barack, you want to give us a basic
155
00:10:24.310 --> 00:10:24.810
overview
156
00:10:25.190 --> 00:10:25.690
of
157
00:10:26.265 --> 00:10:26.925
both bugs
158
00:10:27.865 --> 00:10:30.525
or Yeah. Or at least how you how you created
159
00:10:30.905 --> 00:10:32.285
what led to both bugs?
160
00:10:32.905 --> 00:10:33.725
161
00:10:34.570 --> 00:10:38.510
Yeah. I can give it a bit give a bit of a history what happened. So, obviously,
162
00:10:39.209 --> 00:10:49.345
it was around a month ago or something. Yeah. I did this first large multi tap script transaction on Mainnet. I did it on Testnet first, though,
163
00:10:49.920 --> 00:10:54.900
and then it was unintentionally broke LND due to a pricing issue in BTCD.
164
00:10:56.240 --> 00:10:56.740
And,
165
00:10:58.035 --> 00:11:00.775
I I, obviously, it made a lot of trouble at the time.
166
00:11:01.395 --> 00:11:03.175
I guess I feel sorry about that.
167
00:11:03.955 --> 00:11:05.610
And then in the following ways,
168
00:11:06.570 --> 00:11:07.470
I had this
169
00:11:08.170 --> 00:11:09.070
this this,
170
00:11:09.529 --> 00:11:11.390
this urge, this inner feeling
171
00:11:12.170 --> 00:11:14.670
to my gut telling me to break it more.
172
00:11:16.375 --> 00:11:21.435
And, like, like, I did once, when, or twice. I'm not sure, like, if
173
00:11:22.399 --> 00:11:24.000
that sounds weird, but,
174
00:11:24.399 --> 00:11:25.060
I guess,
175
00:11:25.440 --> 00:11:27.860
yeah, I'm discovering the dark side in me.
176
00:11:28.959 --> 00:11:33.125
Yeah. Maybe I'm a bad actor. Who knows? But, yeah, I just I just
177
00:11:33.505 --> 00:11:35.045
I just wanted to break more,
178
00:11:35.665 --> 00:11:40.199
and I did it only for fun. Not well, for nothing. Just for fun.
179
00:11:40.819 --> 00:11:42.199
And then I dig into
180
00:11:42.660 --> 00:11:44.839
the consensus code of BTCD.
181
00:11:45.779 --> 00:11:49.785
1st and foremost, I'm not a software engineer, although I did some programming in the past.
182
00:11:50.265 --> 00:11:52.125
I I think I'm not qualified
183
00:11:52.584 --> 00:11:53.084
for
184
00:11:53.545 --> 00:11:54.265
the title, but,
185
00:11:55.305 --> 00:11:55.805
I,
186
00:11:56.265 --> 00:11:57.485
I'm a Bitcoin dev.
187
00:11:58.949 --> 00:12:07.370
That's what I can tell. And I dig into consensus code and for weeks. Right? And then I couldn't really find find any exploit, like, any conflict,
188
00:12:07.735 --> 00:12:09.515
consensus conflict between BTCD
189
00:12:10.375 --> 00:12:11.115
and core.
190
00:12:11.495 --> 00:12:12.955
And from what I can tell,
191
00:12:13.335 --> 00:12:15.595
BTCD is actually a very well,
192
00:12:16.670 --> 00:12:19.330
written implementation. It's it it it's
193
00:12:19.950 --> 00:12:25.495
it's it complies with the Bitcoin consensus rules bit by bits. I I couldn't really find any exploit.
194
00:12:26.115 --> 00:12:27.735
I need to dig more into it,
195
00:12:29.875 --> 00:12:32.375
to find more, but, yeah, I'm not sure if I can
196
00:12:32.709 --> 00:12:33.449
find a
197
00:12:33.750 --> 00:12:34.329
198
00:12:34.949 --> 00:12:35.769
the yeah.
199
00:12:36.310 --> 00:12:38.810
So the first bug the first bug, essentially,
200
00:12:39.189 --> 00:12:40.685
you used functionality
201
00:12:40.985 --> 00:12:46.685
that was enabled by Taproot that allowed you to do a massive multisig transaction.
202
00:12:46.985 --> 00:12:47.485
Right?
203
00:12:48.185 --> 00:12:49.165
204
00:12:49.850 --> 00:12:50.350
205
00:12:50.970 --> 00:12:55.389
206
00:12:56.089 --> 00:12:57.389
libraries in it.
207
00:12:57.714 --> 00:12:58.214
BTCD
208
00:12:58.675 --> 00:12:59.175
is
209
00:12:59.714 --> 00:13:00.454
a Bitcoin
210
00:13:00.915 --> 00:13:01.415
implementation
211
00:13:01.954 --> 00:13:03.334
that is written in Go,
212
00:13:03.875 --> 00:13:05.654
and those libraries
213
00:13:06.115 --> 00:13:07.175
made it so
214
00:13:08.190 --> 00:13:09.870
l and d nodes can no longer
215
00:13:10.510 --> 00:13:16.850
essentially, were no longer synced to the Bitcoin chain. They can no longer see what was going on in the Bitcoin chain. Is that a good overview?
216
00:13:17.385 --> 00:13:22.665
217
00:13:23.305 --> 00:13:26.685
inherit the security properties of layer 1, and it depends on,
218
00:13:27.530 --> 00:13:33.870
it relies I mean, BTC in Lendly, in particular, it relies on the BTCD, which is an alternative implementation of Bitcoin.
219
00:13:35.825 --> 00:13:45.285
For the record, I'm not against alternative implementations. In fact, I'm in favor. I think diversity is overall good for Bitcoin, whether it's Lightning implementations or Bitcoin.
220
00:13:46.150 --> 00:13:49.930
Think more diversity is good for the long term, although it may be,
221
00:13:50.310 --> 00:13:51.770
scary for the short term.
222
00:13:52.150 --> 00:13:57.755
So yeah. So the the the first part was unintentional. It was due to a parsing issue.
223
00:13:58.615 --> 00:14:01.195
We had it had a cons it had a parsing,
224
00:14:01.655 --> 00:14:02.155
check
225
00:14:02.940 --> 00:14:08.560
from SegWit SegWit scripts I mean, the scripts are limited to, 10 k, 10 kilobytes.
226
00:14:09.500 --> 00:14:16.855
Sorry. 10 kilobytes. And, I I I managed to make a large I did a large multi transaction, which consumed, like,
227
00:14:17.555 --> 00:14:23.250
1 out of 8 block space or something. And and, yeah, it's it's it's couldn't pass this pre check.
228
00:14:23.709 --> 00:14:26.769
And, yeah, it's unintentionally broke LND the first time.
229
00:14:27.390 --> 00:14:32.215
And the second time, I I tried to look a second look for a second's conflicts,
230
00:14:32.915 --> 00:14:38.055
and I couldn't find any in the consensus the in the actual interrupt repo code, the TX script code.
231
00:14:39.210 --> 00:14:44.510
And from what I can tell, yeah, I think b two c d is is a it's a good implementation.
232
00:14:45.610 --> 00:14:47.515
Then I when I couldn't find,
233
00:14:48.215 --> 00:14:55.435
any conflict, then I come back to then I go back to the wire code, the the the the TX parsing code, and I realized, okay, there is another
234
00:14:55.920 --> 00:14:58.260
conflict in the literally the above line.
235
00:14:58.640 --> 00:15:01.220
The the line above the previous pipeline,
236
00:15:02.000 --> 00:15:04.420
which was also a Taproot related issue.
237
00:15:05.505 --> 00:15:11.365
So in Bitcoin, we have a consensus rule in place that limits number of SEC elements in the row of
238
00:15:12.440 --> 00:15:14.779
a thousand. Right? You cannot exceed that.
239
00:15:15.400 --> 00:15:19.740
Although I'm not sure why it had why this limit was 500 k.
240
00:15:20.235 --> 00:15:28.415
Not sure about that, but it's we, you know, we have another rule in template that says, okay. If you encounter an op success x op occurred in scripts,
241
00:15:29.000 --> 00:15:30.940
it's past the validation regardless.
242
00:15:31.640 --> 00:15:35.020
So it these rule does not does do no longer apply.
243
00:15:35.400 --> 00:15:36.380
So I
244
00:15:37.005 --> 00:15:40.145
I then I when I realized, I tried to first
245
00:15:40.605 --> 00:15:45.320
create a template output, a funding and ops success x, literally, script path.
246
00:15:45.880 --> 00:15:52.060
And maybe it's a bit of technical, but I then I tweak this output with my own inner key. I thought I did.
247
00:15:52.495 --> 00:15:56.515
But it apparently, I tweaked this output with an unspendable inner key.
248
00:15:57.375 --> 00:16:00.755
And then I found this, like, 3 weeks ago or something.
249
00:16:01.680 --> 00:16:03.380
I discovered the bug myself,
250
00:16:03.920 --> 00:16:04.420
and
251
00:16:04.880 --> 00:16:06.020
and found this address,
252
00:16:06.480 --> 00:16:08.020
and then I reach out.
253
00:16:08.345 --> 00:16:09.805
I I build this transaction
254
00:16:10.425 --> 00:16:11.084
by hand
255
00:16:12.264 --> 00:16:13.644
and placing 500,
256
00:16:14.824 --> 00:16:15.324
500,000
257
00:16:15.785 --> 00:16:16.605
stake elements.
258
00:16:25.595 --> 00:16:32.335
And he said, yeah. He didn't question it. He said just pay extra fees for the manual work
259
00:16:32.850 --> 00:16:37.350
and then email us. And then yeah. I emailed them my rolled transaction.
260
00:16:38.370 --> 00:16:41.190
It was like it was paying overpaying, like, 3 x.
261
00:16:42.355 --> 00:16:42.855
And
262
00:16:43.475 --> 00:16:44.855
yeah. And then, obviously,
263
00:16:45.394 --> 00:16:47.654
it was invalid because my my
264
00:16:48.035 --> 00:16:52.400
my control block was incorrect because I thought I tweeted what my inner keypad.
265
00:16:53.260 --> 00:16:54.480
Then, you know,
266
00:16:55.339 --> 00:16:58.855
then they they said, okay. We need to patch. We couldn't broadcast it, whatever.
267
00:16:59.635 --> 00:17:03.735
And then, like, on November 1st, 12 days ago,
268
00:17:04.730 --> 00:17:15.945
I was in need of some money, and then I I wanted to revert the money back to myself. But then I realized, okay, my transactions was wasn't correct. It was tweaked with was tweaked with an in unspendable inner key.
269
00:17:16.405 --> 00:17:20.985
Then, okay, let's, then let's let's make some chaos. Then I fix
270
00:17:21.559 --> 00:17:27.419
the evolved transaction and send back to f two pool in then in within an hour or something. Yeah.
271
00:17:27.960 --> 00:17:29.899
They it ended up in a Bitcoin block.
272
00:17:30.945 --> 00:17:37.525
So it was a bit of a mistake, but not not really. I think yeah. I did it by I did it with my.
273
00:17:39.420 --> 00:17:40.640
I I did it intentionally.
274
00:17:43.660 --> 00:17:44.560
Then, yeah,
275
00:17:45.340 --> 00:17:47.684
then you all know the rest.
276
00:17:48.385 --> 00:17:50.085
277
00:17:50.385 --> 00:17:51.205
by different
278
00:17:51.745 --> 00:17:52.804
on chain transactions.
279
00:17:53.745 --> 00:17:55.445
Both have the same end result
280
00:17:55.860 --> 00:17:59.780
that l and d nodes fell out of sync. Yeah. Both were based
281
00:18:00.980 --> 00:18:03.080
both of the issues stemmed from
282
00:18:03.895 --> 00:18:05.835
the use of the BTCD library.
283
00:18:07.895 --> 00:18:14.880
I it's interesting that you say you're for I one of the interesting things about this situation is depending on your bias,
284
00:18:15.340 --> 00:18:20.240
I've noticed people using it to argue against multiple implementations and for multiple implementations,
285
00:18:22.385 --> 00:18:24.485
which is just fun. It's just classic Bitcoin.
286
00:18:26.625 --> 00:18:27.605
So we have,
287
00:18:28.225 --> 00:18:31.685
well, first of all, Ben, can you communicate with us now?
288
00:18:36.290 --> 00:18:37.190
No. You can't.
289
00:18:37.570 --> 00:18:39.830
Wow. They're trying to silence him.
290
00:18:41.755 --> 00:18:44.255
Okay. Well, we'll get back to Ben. We have Tony here.
291
00:18:45.035 --> 00:18:47.215
Tony, you wanna talk about how,
292
00:18:48.419 --> 00:18:51.880
how how someone could have used if if Barack was malicious,
293
00:18:53.059 --> 00:18:55.480
you did a you did a guide, basically,
294
00:18:56.755 --> 00:19:02.055
in reg test, which I guess so unlike Bitcoin test net one of the Bitcoin test nets,
295
00:19:02.755 --> 00:19:07.880
for how someone could exploit this attack to steal funds. You wanna talk about that real quick? Yeah.
296
00:19:08.680 --> 00:19:15.035
297
00:19:15.895 --> 00:19:19.410
I kinda made it you know, I've been doing these, like, you you know, lightning
298
00:19:19.950 --> 00:19:20.450
abusing
299
00:19:21.070 --> 00:19:24.030
projects, I guess, to to to say kind of being,
300
00:19:24.350 --> 00:19:26.910
along the same lines of, like, a bad actor in a way. But,
301
00:19:29.295 --> 00:19:35.635
so I decided, that it was time to, like, finally do Alan's point and write something that, like, actually tried to, you
302
00:19:36.080 --> 00:19:40.720
know, exploit some of these things that we keep talking about and that keep not getting fixed.
303
00:19:41.920 --> 00:19:50.965
And it was it it was with the intention of doing it at the Atlanta tab comp. There was, was in a workshop there, but I had you know, it takes a while to build,
304
00:19:51.905 --> 00:19:58.480
you know, some of the things that I've been building on, and I didn't have any exploits in there by the time. It was the week of the conference.
305
00:19:59.180 --> 00:20:05.785
And then, week of the conference comes on Sunday, and and this this this bug breaks L and D. And,
306
00:20:06.885 --> 00:20:11.110
of course, like, I was like, Ben texted me and said, okay. Can we reproduce this,
307
00:20:12.390 --> 00:20:15.690
then put it into Ellen's point? And I was like, yeah. Let's let's do it. So
308
00:20:15.990 --> 00:20:24.895
we we did that. And over the course of that week, I was like, okay. Well, how do we actually, like, exploit this? Like, I got a reproducing that works on regs test. Of course, you can't
309
00:20:25.275 --> 00:20:42.625
reproduce it on main net, like, once it's already, you know, once it's already out there and being fixed. It just takes that one transaction to, like, break it. But, essentially, I broadcast you you basically if if you're in the same block as this transaction that, like, can't be, you know, one of Barak's transactions,
310
00:20:44.200 --> 00:20:46.460
You know, the node can't process it.
311
00:20:46.920 --> 00:20:50.860
And if you're not running LND and bit, with with Bitcoin
312
00:20:51.160 --> 00:20:52.059
0 mq,
313
00:20:53.155 --> 00:20:56.775
then then LND actually doesn't process any blocks after that either.
314
00:20:57.075 --> 00:21:02.610
So, which is something I found out by actually reproducing this, and and figuring out that,
315
00:21:03.550 --> 00:21:06.610
it wasn't just that block that it wasn't processing.
316
00:21:06.990 --> 00:21:13.555
If you didn't run-in 0MQ mode, it wouldn't it it thought there was a chain split, and it wouldn't process any other blocks beyond that.
317
00:21:14.255 --> 00:21:14.995
But, essentially,
318
00:21:15.375 --> 00:21:23.190
you know, I just went ahead and just put it in the same block in my reg test scenario. And I have a whole guide on this. It's, you can go to Bytes journey.com.
319
00:21:23.890 --> 00:21:25.910
It's one of the top top blogs.
320
00:21:26.770 --> 00:21:27.510
But, essentially,
321
00:21:27.914 --> 00:21:31.774
after that, after you after your channel peer can't process the block,
322
00:21:33.355 --> 00:21:35.534
the block with the with with the
323
00:21:36.130 --> 00:21:38.550
transaction and at that old channel state,
324
00:21:39.090 --> 00:21:41.430
it doesn't know how to do the justice transaction.
325
00:21:41.890 --> 00:21:49.545
So in Lightning, if if someone were to try to cheat you, your node this is why nodes has to be, you know, pretty much always online or have a watchtower.
326
00:21:50.405 --> 00:21:53.145
But, you know, there's problems with watchtowers too. But
327
00:21:54.340 --> 00:22:05.455
if if you're not online and you don't see that transaction, you can't broadcast justice transactions, which basically take all of the other person's funds even if, you know, even if you weren't rightfully owed all of them.
328
00:22:05.835 --> 00:22:07.775
You do get all of the cheaters funds,
329
00:22:08.555 --> 00:22:12.809
that they have locked up in that channel. So if they're not online, they don't get to see that,
330
00:22:13.590 --> 00:22:17.690
and then I demonstrate. It was actually kinda cool too because I got to demonstrate, like,
331
00:22:18.070 --> 00:22:20.485
how an LND node you know, there's
332
00:22:21.424 --> 00:22:28.645
part of my tutorial walks through, like, okay. Here's a a patched LND node, and here's a non patched LND node. Let's, like, see what
333
00:22:28.950 --> 00:22:29.770
each of them
334
00:22:30.070 --> 00:22:38.310
do under this scenario. And the, you know, the patched one, you know, says, you know, stuff like, oh, your your peer is being fishy in the logs, and it's, like, broadcasting a transaction.
335
00:22:39.565 --> 00:22:42.385
But the other one doesn't. It just says, oh, there's a chain reorg,
336
00:22:42.845 --> 00:22:44.065
and it's none the wiser.
337
00:22:44.685 --> 00:22:45.585
And then eventually,
338
00:22:46.250 --> 00:22:53.309
you might have enough blocks, and and you should get you know, you should be able to redeem those funds on chain. But if the other peer
339
00:22:54.010 --> 00:22:55.150
patches in time,
340
00:22:55.795 --> 00:22:56.674
even if we did
341
00:22:57.554 --> 00:23:01.015
even if someone did exploit this in the same block as as Barak's,
342
00:23:02.980 --> 00:23:05.960
All it takes is you updating your l and d note in time.
343
00:23:06.260 --> 00:23:16.205
Now there there's some questions there on, like, how soon you need to actually update it under all the scenarios. But if you do update in time, you do get to submit that justice transaction.
344
00:23:16.905 --> 00:23:23.780
But if you don't, then then you're kinda shit out of luck, and there's nothing once once enough blocks pass, you don't you don't get those funds back.
345
00:23:25.120 --> 00:23:27.860
346
00:23:28.635 --> 00:23:32.655
in order to exploit this bug, you don't have to take that risk of broadcasting
347
00:23:33.115 --> 00:23:36.655
a a stale state where someone can steal all of your funds.
348
00:23:37.330 --> 00:23:42.950
But in fact, you can do it using HTLCs as well. So you can send an HTLC through the target node through the victim
349
00:23:43.490 --> 00:23:44.985
and then force
350
00:23:45.445 --> 00:23:46.825
close. And that victim,
351
00:23:47.365 --> 00:23:51.465
if you claim that HTLC on chain, the victim won't learn the preimage
352
00:23:52.440 --> 00:23:57.820
from that HTLC or at least in this class of bugs in general, the victim won't learn that preimage from that HTLC.
353
00:23:58.679 --> 00:24:01.899
And then after the HTLC times out, you can just take funds.
354
00:24:02.395 --> 00:24:10.815
So that not only allows you to do it, allows you to exploit this this class of bugs risk free, but it also allows you to exploit this class of bugs,
355
00:24:11.480 --> 00:24:11.980
without,
356
00:24:14.120 --> 00:24:15.740
what was the point I was gonna make?
357
00:24:16.040 --> 00:24:18.860
358
00:24:19.765 --> 00:24:23.465
359
00:24:23.925 --> 00:24:26.985
So that that's where you see the difference between 40 blocks,
360
00:24:27.365 --> 00:24:28.184
which is
361
00:24:28.570 --> 00:24:36.269
the default in most lightning nodes for the time that you have to claim an HDLC that's been routed through you versus,
362
00:24:37.294 --> 00:24:38.995
I think the default for
363
00:24:39.375 --> 00:24:45.715
doing justice transactions and broadcasting in old state is usually, like, 144. Some nodes set it to a full week.
364
00:24:46.470 --> 00:24:53.210
But when you're talking about HTLCs, you can exploit this bug much faster, and the victim has a much shorter time around time,
365
00:24:54.054 --> 00:24:57.195
to turn around where they need to upgrade their node and and catch it in time.
366
00:24:57.654 --> 00:25:02.235
367
00:25:03.380 --> 00:25:09.960
it defaults to a low value? Like, people routing through you want that value to be lower in a normal situation. Right?
368
00:25:10.355 --> 00:25:12.695
369
00:25:13.155 --> 00:25:16.055
So, like, if if you have an HTLC that gets stuck,
370
00:25:16.675 --> 00:25:31.904
that's how that's the total number of these, you know, it's normally 40 blocks per hop. So if you send a payment that's, you know, 3 hops, then it's 3 times 40, a 120 blocks that you have to wait before you're sure that that payment's gonna come back and get unstuck.
371
00:25:33.059 --> 00:25:37.640
Luckily, stuck payments aren't as big a deal as they used to be. We don't see them as much,
372
00:25:38.500 --> 00:25:50.180
but a node can always make a payment, get stuck for that amount of time. So if you're sending a payment, you care about that number being really low. Now the lightning protocol, and I don't know what settings different nodes expose,
373
00:25:51.120 --> 00:25:51.780
allows someone,
374
00:25:52.400 --> 00:25:54.020
opening a channel to say,
375
00:25:54.320 --> 00:25:55.380
you know, I
376
00:25:55.840 --> 00:26:06.904
only want to expose myself to up to this amount of funds in HTLCs at any given time, and that would allow you to limit your exposure to these kinds of attacks that are exploiting against HTLCs
377
00:26:07.365 --> 00:26:08.264
rather than
378
00:26:09.160 --> 00:26:10.300
exploiting against,
379
00:26:12.600 --> 00:26:15.980
the the the stale closing or the the stale commitment transaction.
380
00:26:16.404 --> 00:26:26.340
But I think, most people don't bother sending that. Most people set that to, the full channel value. You should also not do this because it's bad for everyone else's privacy. And in fact, LDK,
381
00:26:27.120 --> 00:26:28.419
and thus Cash App
382
00:26:28.799 --> 00:26:29.299
use,
383
00:26:30.480 --> 00:26:35.895
prefer to route over channels or very slightly prefer to route over channels that do not set their HTLC
384
00:26:36.835 --> 00:26:42.480
max to the total value of the or the their total HTLC max in flight to the value of the channel,
385
00:26:43.020 --> 00:26:46.960
because it's actually better for the sender's privacy, in order for you to do that.
386
00:26:51.595 --> 00:26:52.475
387
00:26:52.955 --> 00:26:56.815
While we have you, LDK was also affected but only by the second bug.
388
00:26:57.220 --> 00:26:57.720
Right?
389
00:26:59.380 --> 00:27:05.640
390
00:27:07.675 --> 00:27:08.175
various,
391
00:27:09.915 --> 00:27:10.415
Bitcoin
392
00:27:10.795 --> 00:27:11.775
library deserialization
393
00:27:12.155 --> 00:27:18.680
libraries. Right? This this this kind of you know, when you're deserializing untrusted input, you have to make sure you're not gonna over allocate memory
394
00:27:19.060 --> 00:27:21.640
and crash yourself by by allocating gigabytes.
395
00:27:22.885 --> 00:27:36.809
You know, there there are better ways to design this code. There are worse ways to design this code, but a number of implementations, you know, BDCV has had more of these class of bugs than just these two bugs. You know, they've they've had some of these classes of bugs since before l and d.
396
00:27:37.565 --> 00:27:49.410
But yeah. So Rust so LDK uses Rust Bitcoin under the hood. Rust Bitcoin had a similar bug, that we caught internally, so we didn't we actually caught it, someone while one of the developers working on it was reading the code,
397
00:27:49.790 --> 00:27:53.250
not when it went to chain. And we fixed it at that time,
398
00:27:53.735 --> 00:27:55.195
by rewriting a bunch of the deserialization
399
00:27:55.495 --> 00:27:59.035
pipeline to just be more robust against this whole class of issues.
400
00:28:00.535 --> 00:28:06.610
But old versions did have that issue, and so some people some users were using old versions of Rust Bitcoin.
401
00:28:07.790 --> 00:28:11.655
I don't know that any LDK LK users were using old versions of Rust Bitcoin, but,
402
00:28:12.035 --> 00:28:18.260
you saw some people running mempool and and running, Elect RS. We're using old versions of Rust Bitcoin, which did get bit
403
00:28:18.740 --> 00:28:20.840
by this bug when the second
404
00:28:21.300 --> 00:28:22.520
transaction was broadcasted.
405
00:28:23.220 --> 00:28:24.280
406
00:28:24.820 --> 00:28:34.304
I I do have one project that's still on an old version of LDK, and I I found that out yesterday when, my hidden lighting network project, the project that does probes,
407
00:28:34.840 --> 00:28:35.980
for private channels.
408
00:28:36.679 --> 00:28:38.700
I launched it yesterday because Ben
409
00:28:39.240 --> 00:28:39.640
Ben,
410
00:28:40.120 --> 00:28:42.059
Ben had his first successful vortex
411
00:28:42.375 --> 00:28:45.355
channel open. So I wanted to see if I could figure out,
412
00:28:46.215 --> 00:28:50.715
which output was his that he opened the channel with because he didn't use sort channel ID aliases.
413
00:28:51.500 --> 00:28:56.799
So I launched up that LDK project, and then it's it's fetching the blocks, and then it crashes. So,
414
00:28:57.659 --> 00:29:02.255
but that's an unmaintained, you know, kind of like a throwaway project at this point, but that's,
415
00:29:02.735 --> 00:29:11.900
416
00:29:12.280 --> 00:29:16.700
before the transaction goes out. Correct? Like, they have to have a channel with you.
417
00:29:17.475 --> 00:29:23.575
418
00:29:24.700 --> 00:29:40.475
any node that has a problem, right, with the HDLs. I I was a little fuzzy on how you could exploit it under the HTLC path. But, Matt, for at least the way I have implemented the exploit, it does require the the the you'd have a channel with the peer. Well, call us Corallo and Odell.
419
00:29:41.950 --> 00:29:43.090
420
00:29:43.390 --> 00:29:46.289
So is that correct? Like, you wouldn't to use the HTLC
421
00:29:46.590 --> 00:29:53.985
attack vector, you could just if you just had a channel open with someone I have a channel open, you could potentially exploit me on that?
422
00:29:57.700 --> 00:30:04.580
423
00:30:05.140 --> 00:30:07.085
I think it it did. So
424
00:30:07.385 --> 00:30:14.765
in the general like, I could imagine in going both ways. I don't know the details of lnd and how it might have have operated in this case.
425
00:30:15.544 --> 00:30:20.510
I think for LDK, that might have been the case, if you were using a a really old version of LDK.
426
00:30:22.090 --> 00:30:23.789
But, you know, in general,
427
00:30:24.250 --> 00:30:28.965
that is a possible outcome depending on some of the the nuances how the note is implemented.
428
00:30:30.065 --> 00:30:30.805
429
00:30:31.585 --> 00:30:33.285
Ben, are you here with us now?
430
00:30:34.430 --> 00:30:35.330
431
00:30:35.710 --> 00:30:39.490
432
00:30:40.910 --> 00:30:42.085
433
00:30:42.885 --> 00:30:44.664
434
00:30:45.365 --> 00:30:49.385
435
00:30:50.725 --> 00:30:52.460
And work with the.
436
00:30:55.640 --> 00:30:59.420
437
00:31:01.715 --> 00:31:08.135
I guess, Kaludis, what are your thoughts here as the lead maintainer of Zeus, the number one way people interact with their
438
00:31:08.435 --> 00:31:10.615
node at home during all of this?
439
00:31:12.020 --> 00:31:12.520
440
00:31:13.140 --> 00:31:13.800
when this
441
00:31:14.580 --> 00:31:15.720
second exploit
442
00:31:16.820 --> 00:31:18.600
dropped, I was sort of
443
00:31:19.495 --> 00:31:20.795
like a double
444
00:31:21.415 --> 00:31:27.595
take, like, on Twitter and in, like, a few chats that I'm in, including, like, you know, the Zeus Telegram.
445
00:31:28.740 --> 00:31:35.780
I'm like, what is everyone talking about? You know, this is the exploit from, like, we're still patching this up. And then it hit me that,
446
00:31:36.385 --> 00:31:38.725
you know, a second exploit had dropped.
447
00:31:39.505 --> 00:31:40.005
And,
448
00:31:40.945 --> 00:31:44.245
you know, I wasn't super surprised, but it was a huge
449
00:31:45.220 --> 00:31:48.600
huge inconvenience, I feel, for a whole lot of different parties.
450
00:31:49.460 --> 00:31:50.760
You know, from, you
451
00:31:51.300 --> 00:31:55.125
know, the BTCD and LND guys who had to patch up their code,
452
00:31:56.485 --> 00:31:56.985
to,
453
00:31:57.445 --> 00:31:59.305
the maintainers of, like, node projects
454
00:31:59.685 --> 00:32:00.085
and,
455
00:32:00.885 --> 00:32:02.265
you know, Lightning wallets,
456
00:32:03.110 --> 00:32:04.649
who had to update their releases,
457
00:32:05.909 --> 00:32:10.090
individual users who were asking, hey. What's going on? Why do I have to update my note again?
458
00:32:12.195 --> 00:32:17.015
You know, it it really shook a lot of things up and, you know, ate up a lot of people's time.
459
00:32:21.370 --> 00:32:27.965
460
00:32:28.585 --> 00:32:31.245
because of Liquid's functionary model instead of,
461
00:32:31.625 --> 00:32:35.245
reaching out of band to a minor. Yeah. You wanna go into that?
462
00:32:35.580 --> 00:32:38.560
463
00:32:39.340 --> 00:32:49.665
464
00:32:49.965 --> 00:32:51.505
Matt mentioned for the older versions.
465
00:32:51.965 --> 00:32:54.545
And Greenlight also for its watch tower,
466
00:32:54.980 --> 00:32:58.279
was using rustic wood, so it also was impacted.
467
00:32:58.820 --> 00:33:01.480
But, I mean, these are remedied now, and,
468
00:33:02.715 --> 00:33:04.255
I guess we're good. But,
469
00:33:04.875 --> 00:33:06.815
just like Evan said, we were also
470
00:33:07.595 --> 00:33:12.790
a bit inconvenienced in trying to scramble to figure out, what exactly needs to be done.
471
00:33:13.410 --> 00:33:15.910
It wasn't just an LND bug.
472
00:33:17.490 --> 00:33:22.785
473
00:33:23.245 --> 00:33:25.825
a Taproot, it seems like. And and then
474
00:33:26.365 --> 00:33:28.630
475
00:33:29.090 --> 00:33:33.030
It was a a segwit thing, a witness witness side. Yeah.
476
00:33:33.650 --> 00:33:39.105
I think it looks like and it just made it easier to to create that that large webinar.
477
00:33:39.885 --> 00:33:40.385
478
00:33:40.845 --> 00:33:47.230
That's what Barack was mentioning earlier, someone, where they're wondering why the original size limit. And I believe
479
00:33:47.769 --> 00:33:49.470
Laulu's explanation was,
480
00:33:49.850 --> 00:33:52.590
because when he originally added the SegWit code
481
00:33:53.049 --> 00:33:54.830
a long time ago for parsing,
482
00:33:55.145 --> 00:33:57.325
like, in v zero. That's what it was.
483
00:33:59.465 --> 00:33:59.965
484
00:34:00.505 --> 00:34:04.045
485
00:34:06.330 --> 00:34:08.970
486
00:34:09.850 --> 00:34:11.390
because of the multisig
487
00:34:12.010 --> 00:34:15.065
and other things, you know, all of that needs to be
488
00:34:15.845 --> 00:34:18.904
updated, whether it's the functionaries or the on chain multisig.
489
00:34:20.404 --> 00:34:20.904
Yeah.
490
00:34:21.500 --> 00:34:23.440
And there was, like, also a scramble,
491
00:34:23.820 --> 00:34:25.280
by a certain amount of blocks,
492
00:34:25.820 --> 00:34:27.520
things that needed to be updated.
493
00:34:28.575 --> 00:34:29.075
So,
494
00:34:29.695 --> 00:34:30.675
yeah, I think
495
00:34:31.214 --> 00:34:32.035
I think we,
496
00:34:32.335 --> 00:34:34.515
Blockstream formally released a statement.
497
00:34:34.815 --> 00:34:35.315
So
498
00:34:35.750 --> 00:34:38.890
I can, post it in the elements chat, but
499
00:34:39.990 --> 00:34:44.170
I'll leave the exact details to that. But similar issue, witness size,
500
00:34:44.805 --> 00:34:45.305
parsing.
501
00:34:46.405 --> 00:34:50.345
502
00:34:51.365 --> 00:34:54.890
503
00:34:56.630 --> 00:34:57.130
504
00:34:57.430 --> 00:34:59.210
so the connection to the chain?
505
00:34:59.990 --> 00:35:02.890
506
00:35:04.865 --> 00:35:08.085
I didn't really see any other people complain too much.
507
00:35:09.025 --> 00:35:12.885
I think Barack would also know a lot about, the impact to Liquid because
508
00:35:13.280 --> 00:35:16.100
he's probably the most knowledgeable in Liquid script.
509
00:35:16.560 --> 00:35:20.340
510
00:35:21.245 --> 00:35:25.425
Barak, did you did you bork your own project when you sent out the transaction?
511
00:35:26.285 --> 00:35:39.245
512
00:35:40.425 --> 00:35:42.765
and, obviously, Rust Bitcoin and few other
513
00:35:43.890 --> 00:35:54.635
infrastructure projects in the space. And in fact, I mean, I wasn't I was only targeting BTCD and LND. I wasn't aware this would cost I mean, this could have caused, any other issues.
514
00:35:57.735 --> 00:36:00.315
515
00:36:01.349 --> 00:36:01.849
516
00:36:03.349 --> 00:36:03.849
Yeah.
517
00:36:04.710 --> 00:36:06.569
518
00:36:08.685 --> 00:36:15.665
the tweet you sent out when you when you sent out that transaction? What was it? In order to find the light, you need to touch the darkness?
519
00:36:16.010 --> 00:36:20.830
520
00:36:21.690 --> 00:36:23.390
Obviously, I did it for fun.
521
00:36:23.850 --> 00:36:24.430
I guess,
522
00:36:25.085 --> 00:36:31.265
yeah, I love making cows. I guess I crave for cows maybe. Yeah. It makes me feel good.
523
00:36:32.760 --> 00:36:33.340
I guess,
524
00:36:33.800 --> 00:36:37.980
that's you know, good or bad, that was the most meaningful thing I did in my life,
525
00:36:39.490 --> 00:36:41.565
regardless the outcome. But,
526
00:36:43.065 --> 00:36:44.205
yeah, basically,
527
00:36:46.265 --> 00:36:48.765
I did it for fun, but I think it also had,
528
00:36:51.130 --> 00:36:55.630
it will have also have good, you know, consequences or, like like, long long term benefits
529
00:36:56.090 --> 00:36:58.990
in in the long in the long run, I would say.
530
00:36:59.755 --> 00:37:06.255
Bringing into chaos into into software, I think, yeah, makes everything else more robust in the long run. Maybe
531
00:37:06.795 --> 00:37:07.775
causing some,
532
00:37:08.920 --> 00:37:12.140
damage in the short term, but, yeah, making everything more robust.
533
00:37:13.560 --> 00:37:18.245
534
00:37:22.625 --> 00:37:24.405
535
00:37:24.830 --> 00:37:27.390
536
00:37:28.030 --> 00:37:29.490
537
00:37:30.030 --> 00:37:39.325
538
00:37:39.625 --> 00:37:41.805
I think I could I could.
539
00:37:42.170 --> 00:37:47.710
Was an off success anyway. I could have done that, but I I realized I couldn't. I mean, I didn't realize that at the time.
540
00:37:48.730 --> 00:37:51.470
And then I just I I choose the cows.
541
00:37:52.015 --> 00:38:05.240
542
00:38:05.540 --> 00:38:06.760
Yeah. I guess so.
543
00:38:07.220 --> 00:38:10.025
544
00:38:11.445 --> 00:38:12.345
because because
545
00:38:12.965 --> 00:38:16.825
I agree. Like like, what doesn't kill you makes you stronger. Right?
546
00:38:17.630 --> 00:38:20.930
But there's you know, I'm curious of the balance here between,
547
00:38:23.310 --> 00:38:28.974
you know, causing chaos and in the end goal, we're all I I think we can all agree that, you know,
548
00:38:32.060 --> 00:38:36.320
I don't know, code wise, you know, or or ecosystem wise, we're we're
549
00:38:36.620 --> 00:38:38.000
better for it probably.
550
00:38:38.620 --> 00:38:45.105
But, I mean, what you know, is there a balance there at all? Like like, doing stuff like this versus
551
00:38:45.724 --> 00:38:46.785
responsible disclosure,
552
00:38:47.885 --> 00:38:51.825
because, you know, I I don't know where I land, like, on it. But
553
00:38:52.270 --> 00:38:55.810
because it does I think fire drills do make us better.
554
00:38:56.510 --> 00:39:00.930
In the end, we need fire drills. Anyone could have done this for $750.
555
00:39:02.974 --> 00:39:04.994
It's just the matter of, like,
556
00:39:07.055 --> 00:39:12.000
well, yeah, when to you know, at least going forward in the future, you know, when when to do this
557
00:39:12.880 --> 00:39:19.460
versus versus responsibility, the skill. So I wonder if we can, like, have a conversation around that. It's probably useful
558
00:39:19.765 --> 00:39:20.265
559
00:39:21.444 --> 00:39:23.385
560
00:39:24.005 --> 00:39:28.825
high just to to quickly make sure we're on the same page about what responsible disclosure is.
561
00:39:29.440 --> 00:39:42.935
There's there's a lot of people who get confused and think, like, responsible disclosure is all about, like, protecting the vendor and making sure you you disclose appropriately to the vendor and whatever. And that's not at all what responsible disclosure is. Right? Responsible disclosure is all about
562
00:39:44.835 --> 00:39:47.734
highlighting that you have a duty of care to their users.
563
00:39:48.440 --> 00:40:03.205
It doesn't matter what the vendor wants or what the vendor thinks or, like, you know, if you wanna do something that makes a vendor look like shit or and look like an idiot because of some bug they had, you know, it'll probably backfire, but you're welcome to try. And it doesn't really matter. It's not it's not related to responsible disclosure.
564
00:40:03.905 --> 00:40:09.480
What responsible disclosure is is saying, like, look. There's some users out there. They're running the software.
565
00:40:09.940 --> 00:40:20.385
You know, for whatever reason, they decided to run the software. They they decided that it was worth worth running because, you know, maybe there's some risk some risk to running any software, but they decided that
566
00:40:20.685 --> 00:40:37.825
that they needed to run the software and that, you know, you have to do right by them. So that means, you know, responsible disclosure can mean going public if the vendor refuses to fix an issue. You know, that is a part of responsible disclosure, but it does mean making sure that the vendor has a chance to fix the issue so that users
567
00:40:38.125 --> 00:40:39.665
don't get hurt and aren't,
568
00:40:40.525 --> 00:40:49.530
hurt more than they need to be. You know, another part of responsible disclosure is is, reporting the issue publicly after it has been fixed to encourage people to,
569
00:40:50.070 --> 00:41:02.730
upgrade. And so that that's that's something where you can say, like, okay. After it's been fixed, exploiting it to to force users to upgrade, you know, is is an option, and that that's a legitimate part of responsible disclosure. But it's never,
570
00:41:03.430 --> 00:41:05.849
you know, putting users at risk when
571
00:41:06.655 --> 00:41:07.155
when
572
00:41:07.535 --> 00:41:12.275
just by taking action, you know, before there's even a patch or before users have a chance to upgrade.
573
00:41:13.960 --> 00:41:17.240
574
00:41:18.520 --> 00:41:23.635
responsible disclosure if this was Bitcoin Core. And I would definitely pick, again,
575
00:41:24.095 --> 00:41:28.494
this approach if this if Lightning is in production. I mean, is
576
00:41:29.490 --> 00:41:31.829
if Lightning is used by a lot of people,
577
00:41:32.210 --> 00:41:41.885
I think, like, the way I see Lightning is it's really a beta software, and it has, like, this public capacity of 5,000 or something. Even Liquid has, like, 35100
578
00:41:42.425 --> 00:41:42.925
Bitcoin.
579
00:41:43.465 --> 00:41:44.125
I think,
580
00:41:45.320 --> 00:41:51.420
I don't really take lightning seriously at this at this very stage, and I I kind of see this as a playground.
581
00:41:51.875 --> 00:41:52.375
And
582
00:41:52.675 --> 00:41:54.375
583
00:41:54.675 --> 00:41:57.815
I mean, there there are large companies who use lightning now,
584
00:41:58.595 --> 00:42:01.495
and and see material transaction volume. I mean,
585
00:42:01.940 --> 00:42:10.200
I think I I don't know about Cash App, but I know, like, River disclosed their transaction volume on lightning. And it's not a joke anymore. It's not it's not trivial.
586
00:42:10.715 --> 00:42:16.255
They have a lot of funds locked up in lightning that are put at risk in something like this.
587
00:42:17.490 --> 00:42:18.309
And that's something too
588
00:42:18.609 --> 00:42:24.710
where, like, you know, if lightning were were super alpha and everyone was on the same page there, it'd be one thing.
589
00:42:25.170 --> 00:42:25.670
But
590
00:42:26.035 --> 00:42:33.095
when there's large corporates who have money locked up or considering deploying Lightning, you know, because they see their peers deploying Lightning,
591
00:42:33.860 --> 00:42:37.880
and they're they're trying to decide whether it makes sense to deploy Lightning right now.
592
00:42:39.140 --> 00:42:57.500
You see these kinds of things and it it it makes corporates think twice. It it it really hurts the deployment of lightning even if we assume that there's no no material funds at risk here. But that's not not accurate anymore either that there there are there is a relatively significant amount of money locked up in Lightning and especially, you know, I lot I know a lot of,
593
00:42:58.285 --> 00:42:58.785
individuals
594
00:42:59.085 --> 00:43:15.430
who who put a lot of money in their lightning node, who put a large amount of their Bitcoin stack in their lightning node. And, you we can agree or disagree about whether that's a great idea. I obviously don't think that's a great idea. I agree. So, like, yeah, there there is a lot of Yeah. I think the I don't know. Well, I mean,
595
00:43:15.914 --> 00:43:16.414
596
00:43:17.515 --> 00:43:23.855
Yeah. So, yeah, I think there is a little relatively large on Bitcoin, yeah, in in Lightning. But, yeah, I think, yeah, the corporate's using
597
00:43:24.279 --> 00:43:28.380
Lightning infrastructure, I think, yeah, they can easily upgrade to a new version and, you know,
598
00:43:29.000 --> 00:43:31.740
and and and the other folks, perhaps, you know,
599
00:43:32.704 --> 00:43:38.405
can simply use watchtowers to avoid these kind of attacks. And, you know, when when I text right.
600
00:43:38.865 --> 00:43:40.420
Sorry. What? There's
601
00:43:41.520 --> 00:43:42.740
602
00:43:43.200 --> 00:43:45.859
that exists that would have avoided this issue because
603
00:43:46.359 --> 00:43:46.859
the,
604
00:43:47.359 --> 00:43:49.460
a, the l watchtower is,
605
00:43:50.184 --> 00:43:54.684
uses the same code, but, b, all of the current watchtower implementations don't enforce HTLC,
606
00:43:55.625 --> 00:43:58.840
HTLC forwards. So the watchtower is don't,
607
00:43:59.540 --> 00:44:01.220
address the issue even if
608
00:44:02.020 --> 00:44:06.840
and and doing that would be a very non private watchtower. You can give up a lot of your privacy to the watchtower.
609
00:44:07.365 --> 00:44:10.345
So there's no code to do HTLC enforcements,
610
00:44:11.285 --> 00:44:14.340
even if you even if you wanted to. Not in the watchtower.
611
00:44:14.900 --> 00:44:24.994
612
00:44:25.454 --> 00:44:31.795
abstract walk time in it. But I think when the HDLCs claim, the preimage is revealed on chain anyway.
613
00:44:32.839 --> 00:44:38.779
But, as for, you know, the actual commitment outputs, these outputs have a relatively larger
614
00:44:39.585 --> 00:44:44.885
relative walk time in it anyway. So no other runners can easily upgrade to the newer version
615
00:44:45.585 --> 00:44:46.805
and avoid these,
616
00:44:47.185 --> 00:44:48.085
attack vectors.
617
00:44:48.810 --> 00:44:52.350
So when I did attack this when I created this, the second,
618
00:44:53.690 --> 00:44:56.190
transaction, I was aware of this, and
619
00:44:56.570 --> 00:44:59.895
I I knew there wouldn't be any there wouldn't be any
620
00:45:00.515 --> 00:45:06.270
potential loss of funds, and it appeared, though, we haven't I I personally haven't seen any
621
00:45:06.750 --> 00:45:22.335
622
00:45:22.955 --> 00:45:29.770
in the second case because people are aware of it. People are are aware of how to exploit it. In fact, there's sample code to exploit it,
623
00:45:30.070 --> 00:45:31.850
that the the folks here worked on
624
00:45:32.835 --> 00:45:37.415
because of the first bug. Because, you know, once the first bug's out there, of course, you just write sample code, whatever. It's,
625
00:45:38.035 --> 00:45:41.415
not not making the exploit all that much easier or harder.
626
00:45:42.349 --> 00:45:46.849
But that because of the first one, it makes it substantially easier to exploit the second one,
627
00:45:47.150 --> 00:45:50.930
which which put a substantially higher risk on the second one. No?
628
00:45:51.994 --> 00:45:56.575
629
00:45:57.115 --> 00:46:01.900
And I still see these attacks as more of a denial of service type of attack
630
00:46:02.680 --> 00:46:12.365
631
00:46:13.225 --> 00:46:17.645
So there's there's basically no such thing as a denial of service attack against a lightning node.
632
00:46:21.000 --> 00:46:30.184
633
00:46:30.884 --> 00:46:33.944
634
00:46:34.884 --> 00:46:36.424
the time during which you're asleep.
635
00:46:38.150 --> 00:46:39.450
636
00:46:40.230 --> 00:46:44.170
637
00:46:44.869 --> 00:46:47.369
638
00:46:49.575 --> 00:46:57.660
639
00:46:59.420 --> 00:47:02.400
640
00:47:03.500 --> 00:47:09.964
641
00:47:10.585 --> 00:47:15.404
It wouldn't make sense to to exploit via the commitment output. But you're right. The the commitment output
642
00:47:16.770 --> 00:47:17.990
the commitment output
643
00:47:18.369 --> 00:47:19.990
historical state of broadcasting
644
00:47:20.530 --> 00:47:29.255
is a much higher value. I'm not sure what the default is there. I think it might be a day. It might be a week. I I keep hearing 2 weeks. Is 2 weeks not true for the commitment outputs?
645
00:47:31.155 --> 00:47:41.020
I think it's configurable. I I heard I thought the most common was a week, but it it may be 2 weeks. I don't know. That's totally within would be within reason for for a value to choose.
646
00:47:42.175 --> 00:47:44.994
647
00:47:45.615 --> 00:47:47.555
648
00:47:49.990 --> 00:47:51.850
649
00:47:52.150 --> 00:47:53.770
650
00:47:55.030 --> 00:48:00.145
just saying, you know, I mean, there's definitely there's gotta be a bright side here on, you know,
651
00:48:01.005 --> 00:48:04.145
on on Barack's side, right, that we're actually having this conversation.
652
00:48:06.370 --> 00:48:07.350
653
00:48:07.730 --> 00:48:15.785
it's healthy for the community to have a conversation about what responsible disclosure is or isn't so that people are are aware of this kind of thing and so that we can
654
00:48:17.285 --> 00:48:17.785
be
655
00:48:18.165 --> 00:48:25.609
be more you know, have the community have a a more common understanding of what what responsible disclosure means and and how it should look,
656
00:48:26.069 --> 00:48:39.365
so that hopefully we as a community kind of are all on a on a similar page. I mean, I certainly through the course of this this exercise, it it became very clear that the the Bitcoin community has very different ideas of of both what responsible disclosure are and what people's
657
00:48:40.190 --> 00:48:40.690
responsibilities
658
00:48:40.990 --> 00:48:49.135
are. And I think having a a a more common understanding of what responsible disclosure is should get us hopefully to a a more common page.
659
00:48:49.855 --> 00:48:54.435
660
00:48:56.095 --> 00:48:56.595
Presumably,
661
00:48:58.010 --> 00:49:00.750
you wouldn't do what Barack did. What how would you proceed?
662
00:49:03.130 --> 00:49:12.785
663
00:49:13.085 --> 00:49:18.190
or just l and d? Or If it if it affects more than one that you're aware of, certainly, you let
664
00:49:18.730 --> 00:49:23.175
you know, for for security issues, you tell the minimal number of people
665
00:49:23.555 --> 00:49:24.055
required,
666
00:49:24.595 --> 00:49:27.335
in order for the the the issue to get patched.
667
00:49:27.635 --> 00:49:31.015
So you start with l and d because that's the only one you're aware of has this problem.
668
00:49:32.450 --> 00:49:44.665
669
00:49:45.205 --> 00:49:55.680
670
00:49:57.985 --> 00:50:08.069
But then so so I think an important part of of understanding responsible disclosure is is that you coordinate with the vendor about release timeline. Right? So so if you're the one reporting a bug,
671
00:50:09.010 --> 00:50:11.109
you are allowed to say to the vendor,
672
00:50:11.410 --> 00:50:13.270
hey. I think this is really critical.
673
00:50:13.805 --> 00:50:16.145
I think I should go public with this in 2 weeks.
674
00:50:17.005 --> 00:50:20.625
Can you get a patch together and and make sure you get that shipped ASAP?
675
00:50:21.300 --> 00:50:25.640
And then that's a conversation that you have with the vendor. It's not like the vendor gets to say, like,
676
00:50:26.020 --> 00:50:32.055
no. This has to stay private or here's the release timeline. Take it or leave it. You know, that's a conversation you have with them.
677
00:50:33.075 --> 00:50:36.215
And then I think once the the fix is released,
678
00:50:36.675 --> 00:50:43.880
it be that, at that point, it becomes a question of, like, what you think is the makes the most sense for for users. So,
679
00:50:45.494 --> 00:50:48.315
really, you know, patching a a an issue quietly
680
00:50:49.095 --> 00:50:57.960
does not get the most people to upgrade. And so, you know, you've seen this con we've had, you know, back when I worked a bunch on Bitcoin Core, we had these kinds of conversations a lot.
681
00:50:58.740 --> 00:51:00.200
You know, when you have an issue,
682
00:51:00.805 --> 00:51:02.025
do you tell people
683
00:51:02.725 --> 00:51:03.465
about it
684
00:51:03.765 --> 00:51:08.665
so that people go and upgrade really quickly, or do you not tell people about it because,
685
00:51:09.365 --> 00:51:11.240
you don't wanna give attackers
686
00:51:11.540 --> 00:51:13.720
enough information to go exploit the vulnerability?
687
00:51:15.460 --> 00:51:24.535
And so it becomes a a balancing act. And, again, this is where, you know, you, the reporter, get to have a conversation with the vendor and where you, the reporter, gets to ultimately decide.
688
00:51:25.075 --> 00:51:26.454
And I think it would be
689
00:51:27.100 --> 00:51:32.080
I I don't know if I would have decided to do that, but it would have been totally reasonable or at least totally justified
690
00:51:32.620 --> 00:51:40.815
to go exploit the issue after the patch had been released or maybe maybe a few days after the patch had been released so the people had a chance to upgrade on their own,
691
00:51:41.835 --> 00:51:45.615
to highlight the issue and and to for kinda force people to upgrade, quote, unquote.
692
00:51:46.869 --> 00:51:47.369
But,
693
00:51:47.750 --> 00:51:53.690
you know, prior to there being a patch and prior to people having at least a small window of time to to upgrade themselves,
694
00:51:54.994 --> 00:51:59.414
actually exploiting it just just seems like putting users at more risk than is necessary.
695
00:52:01.350 --> 00:52:03.930
696
00:52:04.230 --> 00:52:15.875
truth, the sad reality of the situation? Like, we talk about we're just just saying that, like, oh, because there are significant volumes on Lightning now, and there are big companies and corporations looking at Lightning.
697
00:52:16.735 --> 00:52:19.155
And then things like this overall hurt
698
00:52:19.530 --> 00:52:26.830
the perception of Lightning. I mean but isn't the perception of Lightning just wrong currently? Like, we live in this happy little
699
00:52:27.425 --> 00:52:35.950
lightning world that, like, all of our payments are fast and easy. We can do 0 conf atomic swaps. We can do all this other fancy shit, but, like,
700
00:52:36.349 --> 00:52:40.770
Lightning's pretty broken. I mean, Matt, your talk, Crowley, your talk
701
00:52:41.310 --> 00:52:47.964
at, Atlanta was, like, a really good talk, and it just kinda highlighted that lightning is kind of broken in its current state.
702
00:52:48.825 --> 00:53:00.910
703
00:53:01.370 --> 00:53:02.970
in essence, it was your fault.
704
00:53:03.370 --> 00:53:04.430
Bitcoin Core
705
00:53:04.915 --> 00:53:09.335
thought this was valid, and I think that's where some people are drawing the line.
706
00:53:10.275 --> 00:53:17.200
707
00:53:17.660 --> 00:53:32.980
the foundational issue was that there was a bug. The foundational issue was not that it was exploited. The only the only question then is, like, okay. There is a bug. Given there is a bug, should you exploit it? That's a very different question from, like, whose fault is the fact that there is a bug. Right?
708
00:53:33.520 --> 00:53:38.260
And bugs happen. You know, that's not gonna not gonna change. That's the reality of software development.
709
00:53:39.680 --> 00:54:02.965
But but yeah. So, you know, I I think to the point about lightning being broken and the perception of lightning being wrong, I think it is important to to highlight the difference between, your counterparty and, like, you know, I always kinda make the point that you shouldn't open channels with a counterparty you don't know or at least don't trust enough that they're not gonna, like, try to steal your money and, like, put in a bunch of effort to steal your money. I think this is a very different world from
710
00:54:04.300 --> 00:54:19.325
and then there's denial of service attacks against Lightning, not in the, like, take your note offline, but in the, like, saturate your liquidity so that you can't send payments. So let me I guess I should rephrase my earlier statement about there not being denial of service attacks against Lightning. Just that the the the,
711
00:54:19.645 --> 00:54:22.145
saturating liquidity denial of service attacks.
712
00:54:22.480 --> 00:54:24.020
So there's a lot of things that
713
00:54:24.480 --> 00:54:37.255
are broken with lightning and where the perception is maybe wrong, but I think those are different from you're going to lose funds maybe because your counterparty did something without them even being involved. So when we were talking about, you know, routing an HDL
714
00:54:37.560 --> 00:54:48.285
through multiple hops and then stealing funds, that's something where like your counterparty can be totally honest and they go to chain and then your node doesn't see it and then you still lose funds. Right? So I think that's
715
00:54:48.585 --> 00:54:50.045
the kind of thing where,
716
00:54:51.225 --> 00:54:57.030
you know, aside from these bugs, generally, I think there's not really much in the way of known issues,
717
00:54:57.810 --> 00:54:59.190
for lightning for
718
00:54:59.810 --> 00:55:04.865
why this might be why you might lose funds if your counterpart is, like, completely honest.
719
00:55:09.870 --> 00:55:12.130
720
00:55:12.910 --> 00:55:15.890
it's not our first bug on lightning. Right? There's one in 2019,
721
00:55:17.070 --> 00:55:17.730
and then
722
00:55:18.395 --> 00:55:29.650
Antoine Riard and Gleb also found a dust one last year that, I guess, they responsibly disclosed. Like, do you remember how that process was, and maybe we can, like, touch on that?
723
00:55:30.510 --> 00:55:34.130
724
00:55:35.285 --> 00:55:39.305
So they they reached out to everyone. They emailed, you know, I guess, all of the
725
00:55:39.685 --> 00:55:42.825
I don't know who all was on the email list. But, you know, basically, all the
726
00:55:43.859 --> 00:55:50.520
maintainers or the kind of lead maintainer or 2 of all the lightning implementations and kinda describe the issue. They describe the
727
00:55:50.980 --> 00:55:57.474
basically, the issue was that, because lightning has some concept dust outputs. If an if an output is dust, if an HTLC
728
00:55:57.775 --> 00:55:59.875
the value of the HTLC is dust
729
00:56:01.000 --> 00:56:02.140
below some threshold,
730
00:56:02.920 --> 00:56:04.700
then it just gets burned to feeds.
731
00:56:05.000 --> 00:56:12.095
So, a counterparty could send a bunch of HTLCs that were just barely below this threshold. And in fact, they can even do things to,
732
00:56:12.555 --> 00:56:13.775
increase this threshold,
733
00:56:14.394 --> 00:56:16.015
that nodes will currently accept.
734
00:56:16.560 --> 00:56:26.405
And then if they do that, then they can burn a lot of your money to fees. And I guess if they're a minor, they get free money then because they burn the money to fees and then they get to claim the fees because they're a minor.
735
00:56:27.825 --> 00:56:36.370
So the they they reached out to all the lightning implementations. All the lightning implementations added a bunch of code to, patch it and then ship that code.
736
00:56:37.470 --> 00:56:41.890
And then I think after everyone had shipped or some period of time afterwards,
737
00:56:42.755 --> 00:56:44.915
they disclosed it publicly. And and,
738
00:56:45.315 --> 00:56:53.099
Antoine wrote up a a a change to the bolts and described this issue and and note that that implementers of the bolt spec need to,
739
00:56:53.800 --> 00:56:56.300
do something to to ameliorate this issue.
740
00:56:57.800 --> 00:57:10.130
Unlike the kind of on chain stuff that we've been talking about, there's no way to go, like, exploit the issue to force people to upgrade. There's nothing like that. We can only, like, write code and and tell people that this
741
00:57:10.430 --> 00:57:16.609
this issue exists and you should upgrade. And then, like, if you were to exploit this issue, you have to actually go steal funds.
742
00:57:17.235 --> 00:57:18.435
You you couldn't just, like,
743
00:57:19.155 --> 00:57:21.975
cause the issue and then and then get no stuff.
744
00:57:22.275 --> 00:57:26.380
745
00:57:27.240 --> 00:57:36.165
746
00:57:36.465 --> 00:57:47.700
Actually, that's all I we were. So before LDK was LDK, Rust Lightning existed and it was a joke. It was like a tiny project, and and no one used it, and it wasn't even ready for production. But but we were checking it. So Mhmm.
747
00:57:50.795 --> 00:58:01.210
But but yeah. I mean, that that was another again, that was another case where you couldn't do something to actively force everyone to upgrade, and you could only actually go steal funds, which obviously has a has a very different moral question.
748
00:58:02.790 --> 00:58:05.130
749
00:58:05.670 --> 00:58:07.849
attacks is a security assumption
750
00:58:08.715 --> 00:58:10.095
that your peer,
751
00:58:10.555 --> 00:58:15.695
ideally, will not be a lightning node peer as well as a miner.
752
00:58:16.369 --> 00:58:21.670
I know there's a lot of stuff being kinda shuffled around with the mempool and Bitcoin Core right now.
753
00:58:22.450 --> 00:58:26.025
People happy or unhappy about the RBF policies.
754
00:58:26.485 --> 00:58:28.265
How do you think this will affect,
755
00:58:29.845 --> 00:58:32.185
any other things, any other new potential
756
00:58:33.240 --> 00:58:34.460
dust issues, HCLCs,
757
00:58:34.760 --> 00:58:35.819
anything? Does anything
758
00:58:36.119 --> 00:58:36.940
come to
759
00:58:37.400 --> 00:58:41.819
your mind, Matt? Anything about, like, l two that's needed or penalty transactions?
760
00:58:43.545 --> 00:58:46.045
761
00:58:46.985 --> 00:58:52.605
And this isn't even so that there's questions about minors, but also just around mempool policy like you mentioned.
762
00:58:53.680 --> 00:59:05.734
We know a lot of stuff has to change. We have ideas for how that stuff changes. All of it to exploit it though, like I mentioned, requires some amount of effort on the part of your counterparty. They have to, like, do a bunch of work writing a bunch of software, coding stuff,
763
00:59:07.714 --> 00:59:08.214
to
764
00:59:08.515 --> 00:59:19.880
to actually go steal funds, you know, anchor outputs. As long as you have anchor outputs in your channels. So anchor outputs don't prevent don't protect you against an actively malicious counterparty, but they do protect you against,
765
00:59:20.645 --> 00:59:23.224
the just the fees going up in the network.
766
00:59:24.165 --> 00:59:29.065
So the the kind of straightforward issues that existed prior to Anchor, solved by Anchor,
767
00:59:29.940 --> 00:59:35.079
you know, encourage you to make sure your opening channels that support Anchor outputs that have the Anchor flight turned on.
768
00:59:36.500 --> 00:59:37.000
And
769
00:59:37.435 --> 00:59:50.040
aside from that, you know, there there's things that need to happen, but they they do require some amount of effort to to exploit. So also just make sure you know who your channel counterparties are. You trust them not to to do a bunch of work to steal your money.
770
00:59:50.660 --> 00:59:52.600
Trust them to at least be kind of honest.
771
00:59:56.645 --> 01:00:02.744
772
01:00:03.400 --> 01:00:07.020
situation today. I mean, where people just, like, open channels with,
773
01:00:08.520 --> 01:00:09.900
pretty much anyone, really.
774
01:00:10.520 --> 01:00:11.420
Any random
775
01:00:11.800 --> 01:00:12.620
on the Internet,
776
01:00:13.035 --> 01:00:22.740
they kind of just, like, go and open channels, and they let their little Raspberry Pi sit in the closet for months that they don't touch. And then that's kind of the end of the story there. So, you know, hopefully
777
01:00:23.040 --> 01:00:25.460
I mean, I would say, you know,
778
01:00:26.240 --> 01:00:26.740
after,
779
01:00:27.200 --> 01:00:37.315
you know, some, you know, person that just had their lightning note in the closet for 2 months, and they had to go figure out how to update it and then having to do it again in the same month. I mean, you know, if they're
780
01:00:38.310 --> 01:00:47.235
not ready to sign up for that life, then maybe they they really should consider. Like, okay. Maybe I shouldn't shouldn't be running this lightning note,
781
01:00:48.195 --> 01:00:54.055
you know, after after all of this. Because that's kind of the reality. You don't just, like, throw it in a closet and, like, you know,
782
01:00:54.550 --> 01:00:56.010
don't come back to it again.
783
01:00:58.070 --> 01:01:00.250
784
01:01:00.550 --> 01:01:01.485
you said it well.
785
01:01:02.685 --> 01:01:03.185
Don't
786
01:01:03.485 --> 01:01:05.825
open or if you're gonna go into a coma
787
01:01:06.365 --> 01:01:10.945
because, like, it's not just something you can like, you know, lighting a car that you can
788
01:01:11.670 --> 01:01:12.170
maintain
789
01:01:12.470 --> 01:01:15.370
personally, then it's just, like, you're running up cold
790
01:01:15.910 --> 01:01:18.090
yourself. Like, figure out how to
791
01:01:18.525 --> 01:01:19.485
either study lighting
792
01:01:20.045 --> 01:01:24.705
all of sucks or, like, something that's like like a analysis or something.
793
01:01:30.260 --> 01:01:40.645
794
01:01:42.465 --> 01:01:53.829
but how do and this is, like, a very, very broad question too. Right? And and maybe this is something worth discussing, but, like, if you're writing software, you're writing a wallet, how do you communicate to users what the relative risks
795
01:01:54.345 --> 01:02:02.685
of all these different attacks are, especially when you don't know for sure? You know, you you have some idea of how to exploit it, but, like, will it work in practice or not? It's a whole other question.
796
01:02:03.225 --> 01:02:05.230
And then, you know, how do you
797
01:02:05.930 --> 01:02:13.290
how do you evaluate this and how do you communicate it to users? I mean, this is another thing, you know, I think I always say that the only two things
798
01:02:13.795 --> 01:02:20.215
the only thing in the entire kind of quote, unquote cryptocurrency space that's in competition with Bitcoin is stable coins in practice
799
01:02:20.515 --> 01:02:26.420
because people do wanna you know, the only thing that works that does payments is is stable coins and people use stable coins for payments.
800
01:02:27.360 --> 01:02:38.760
And so how does how do you if you're, like, writing a wallet that supports Bitcoin and stablecoins, how do you communicate to users that, like, this stablecoin exposes you to risk of, you know, Tether going under
801
01:02:39.220 --> 01:02:46.200
and stealing all the funds. It exposes you to risk of, like, the blockchain it's on and it's like Tron and it might just, like, randomly implode
802
01:02:46.740 --> 01:02:54.425
and, like, you know, it also exposes you to the risk of of just US dollar and sanctions and, like, maybe the US government decides to, like,
803
01:02:54.805 --> 01:03:06.555
this this stable coin is not enforcing sanctions and suddenly all the money is taken. Or you can use Bitcoin and the the the risk here is the volatility. Like, how do you communicate that to users in a way that they understand that intuitively
804
01:03:07.095 --> 01:03:07.755
and then
805
01:03:08.295 --> 01:03:11.674
make a decision that makes sense based on that communication?
806
01:03:12.135 --> 01:03:21.250
Or do you just say, like, here's stable coins and here's Bitcoin. Use what you want. And then users just assume that the stable coin is, like, gonna keep working and has no risk associated with it.
807
01:03:24.894 --> 01:03:28.194
808
01:03:32.670 --> 01:03:35.010
809
01:03:36.270 --> 01:03:36.770
that
810
01:03:37.790 --> 01:03:44.715
at least Sovereign Lightning usage is not in the cards or should be dissuaded from end users right now.
811
01:03:47.255 --> 01:03:48.295
Or or at least
812
01:03:48.780 --> 01:03:51.119
813
01:03:53.980 --> 01:03:58.240
814
01:03:59.875 --> 01:04:02.295
815
01:04:02.915 --> 01:04:05.494
time. You know, like, you were one of the earlier nodes,
816
01:04:05.930 --> 01:04:10.110
and it was, quote, unquote, reckless, have fun. Like, you're just trying to
817
01:04:10.410 --> 01:04:11.390
test the technology.
818
01:04:12.090 --> 01:04:14.190
I think now we're in a more
819
01:04:14.645 --> 01:04:16.185
mature state where,
820
01:04:16.805 --> 01:04:19.145
I guess, it is still reckless, but
821
01:04:19.605 --> 01:04:20.425
you should
822
01:04:20.725 --> 01:04:20.965
not
823
01:04:21.560 --> 01:04:22.520
you should do your,
824
01:04:23.320 --> 01:04:25.740
best efforts to know your peers and,
825
01:04:26.760 --> 01:04:32.885
update your software, all that. Like, it's no longer SpongeBob memes. You have Tony and Brock out here now.
826
01:04:33.905 --> 01:04:35.045
827
01:04:36.465 --> 01:04:39.605
which I asked on the open source stage in Miami this year.
828
01:04:41.550 --> 01:04:45.330
So in my Bitcoin experience, one of the things that I learned early on
829
01:04:45.630 --> 01:04:47.250
is that unlike traditional
830
01:04:48.404 --> 01:04:52.585
proprietary software that people are comfortable with or or used to, I guess,
831
01:04:53.684 --> 01:04:58.940
we intentionally do not have auto updates on Bitcoin Core because it's an attack vector. If if
832
01:04:59.400 --> 01:05:02.540
if you just update blindly, then you might update,
833
01:05:03.000 --> 01:05:05.340
a malicious update. You might update an attack.
834
01:05:06.705 --> 01:05:13.525
So a lot of people with with Bitcoin Core specifically, they're they're they're slow to update. They don't update very quickly.
835
01:05:13.985 --> 01:05:15.445
On the Lightning side,
836
01:05:16.650 --> 01:05:27.724
there seems like I know it's still early days in Lightning, but it seems like there's been many, many, many times where, like, the community has been, like, pushed to to update ASAP. There's something critical you have to update ASAP.
837
01:05:28.345 --> 01:05:28.845
Now,
838
01:05:30.424 --> 01:05:30.924
enthusiasts,
839
01:05:31.305 --> 01:05:33.805
like, hardcore Bitcoiners that are not necessarily,
840
01:05:34.105 --> 01:05:37.340
you know, fluid in code or whatnot, but they live and breathe Bitcoin,
841
01:05:37.960 --> 01:05:38.620
are running
842
01:05:39.240 --> 01:05:41.900
their lightning nodes on Umbrel and RaspiBlitz
843
01:05:42.745 --> 01:05:43.965
and Start 9
844
01:05:44.265 --> 01:05:45.005
and Noddle.
845
01:05:46.585 --> 01:05:48.605
So they're they're running these, like, prepackaged
846
01:05:48.985 --> 01:05:50.205
node projects,
847
01:05:51.260 --> 01:05:57.839
and then they see that there has to be an update, and they just go to them, and they just quickly, like, blindly click the update button.
848
01:05:59.674 --> 01:06:01.135
Is there I'm
849
01:06:01.595 --> 01:06:04.655
1 I'm curious if anyone here supports the idea of
850
01:06:05.275 --> 01:06:09.510
an opt in ability to auto update, Because they're practically doing it anyway.
851
01:06:10.690 --> 01:06:15.430
Like, what is the negative of giving them the option to auto update instead of, like,
852
01:06:15.835 --> 01:06:22.690
you know, being traveling, being away from your node, not being able to update for 2 weeks even if they're just gonna blindly up press the update button anyway.
853
01:06:28.210 --> 01:06:32.230
854
01:06:32.645 --> 01:06:40.105
conversation. I mean, I also hate the idea about updates, but that is the reality of the situation is that they're just clicking update anyways.
855
01:06:42.240 --> 01:06:44.180
I mean, when you even think about mobile
856
01:06:44.640 --> 01:06:53.724
apps and and mobile phones and, like, no one, for 1, like, make it incredibly hard to actually verify any source code at all if you're going through app stores.
857
01:06:54.825 --> 01:06:58.430
And for 2, you know, some of the app stores even auto update anyways.
858
01:06:58.970 --> 01:07:06.430
So, like, there's there's there's nothing they they really do there either. So and and most people's lightning nodes are probably mobile phones,
859
01:07:06.765 --> 01:07:12.145
mobile phone apps anyway. So I I think it's a valid talking point. I don't know if I would
860
01:07:12.605 --> 01:07:23.170
go far go as far to say, like, there should be an auto update option in in apps like Umbrel, but I think it's a definitely a valid conversation to have. I'm curious what other people think on that.
861
01:07:23.550 --> 01:07:24.964
862
01:07:25.425 --> 01:07:26.244
say that's
863
01:07:26.785 --> 01:07:29.845
fine, Matt, but I would then also
864
01:07:30.224 --> 01:07:31.285
insist a contingency
865
01:07:31.585 --> 01:07:43.735
that there's an atomic rollback feature. I'm a big fan of Nix Bitcoin and NixOS for this reason, and I believe Bitcoin Core uses geeks also for reproducible and deterministic builds.
866
01:07:45.075 --> 01:07:50.740
So as long as there's a rollback option after that auto update, they can immediately go back if there's something wrong.
867
01:07:51.040 --> 01:07:52.500
868
01:07:52.880 --> 01:07:54.260
Correct. So rush to update.
869
01:07:54.720 --> 01:07:56.820
870
01:07:58.045 --> 01:08:04.900
rollbacks are hard too though because you might have, like, updated your state. Like, your local database might have gotten upgraded or something, and then, like,
871
01:08:05.940 --> 01:08:09.640
you're gonna try to roll back, and then it's not gonna be able to read the new the new
872
01:08:10.020 --> 01:08:10.520
stuff.
873
01:08:12.075 --> 01:08:20.790
That that's actually something that LDK supports that's maybe a little unique, but it's a lot of effort to support, and I wouldn't necessarily say that that all developers should support it.
874
01:08:21.090 --> 01:08:23.510
One other point I I would also highlight that,
875
01:08:23.890 --> 01:08:30.625
Bitcoin Core is very different in the the requirements here because there's not only a cost to you personally. If you like auto update
876
01:08:31.005 --> 01:08:32.945
and the the software is now,
877
01:08:33.805 --> 01:08:36.860
malicious and steals your keys, That's one thing.
878
01:08:37.320 --> 01:08:38.540
But it's there's also
879
01:08:39.400 --> 01:08:40.700
issue with,
880
01:08:41.560 --> 01:08:56.840
if you auto update and there's a consensus rule change and all the nodes auto update, suddenly someone can for example, like, BSV pushed an update today to to be able to steal arbitrary coins so that Craig can go just steal your coins if he doesn't like you.
881
01:08:57.380 --> 01:09:01.480
You know, suddenly you could do something like that if there were, like, a real auto update mechanism.
882
01:09:01.985 --> 01:09:09.605
So there's additional social costs in Bitcoin Core for that kind of thing that maybe don't apply in lightning or in kind of other wallet software cases.
883
01:09:17.265 --> 01:09:24.085
884
01:09:24.385 --> 01:09:26.385
you have to let the user verify,
885
01:09:27.470 --> 01:09:31.250
that they're running, like, a specific version, like, a deterministic build
886
01:09:31.550 --> 01:09:37.795
is always welcome, but, you know, much easier said than done. Like, an iOS app, like, you can't do that at all. Right? And,
887
01:09:38.175 --> 01:09:41.555
you know, Bitcoin wallets, like, only a handful are, you
888
01:09:41.935 --> 01:09:42.515
know, deterministically
889
01:09:43.055 --> 01:09:44.435
reproducible on Android.
890
01:09:45.700 --> 01:09:50.760
But I think there might be value in some of these node platforms giving users the ability
891
01:09:51.380 --> 01:09:52.520
to, manually
892
01:09:52.980 --> 01:09:55.465
upgrade to certain releases perhaps before,
893
01:09:56.085 --> 01:09:59.065
you know, like, a maintainer can, like, bundle it back up again.
894
01:10:00.244 --> 01:10:01.685
I think that's a feature that,
895
01:10:02.244 --> 01:10:03.225
my node has,
896
01:10:03.685 --> 01:10:09.820
that I think is pretty underrated. Like, you could just pop in a version number, and it'll fetch and try to build it and install it on your machine.
897
01:10:11.080 --> 01:10:11.560
But,
898
01:10:12.199 --> 01:10:14.205
you know, depending on these architectures,
899
01:10:14.825 --> 01:10:21.305
it might not be so easy for a lot of these projects to transition to that. So Evan also has the room for user error too. So
900
01:10:22.750 --> 01:10:26.929
901
01:10:28.510 --> 01:10:31.810
the most exposure directly to end users of Lightning,
902
01:10:32.475 --> 01:10:33.455
because of Zeus.
903
01:10:33.915 --> 01:10:34.415
904
01:10:35.915 --> 01:10:40.335
905
01:10:40.860 --> 01:10:44.000
among the Zeus community and how everything went there,
906
01:10:44.620 --> 01:10:45.020
how do you,
907
01:10:48.115 --> 01:10:50.215
I guess, you and Ben do because
908
01:10:50.595 --> 01:10:51.095
of,
909
01:10:51.555 --> 01:10:52.695
the Bitcoin company.
910
01:10:53.555 --> 01:10:55.735
How do you how do you how do you feel about
911
01:10:56.500 --> 01:11:00.920
Lightning going forward? Like, how do you think about actually developing for end users?
912
01:11:02.340 --> 01:11:04.760
913
01:11:05.535 --> 01:11:07.715
You know, we're definitely seeing a
914
01:11:08.095 --> 01:11:10.355
lot of users that are frustrated by
915
01:11:11.215 --> 01:11:12.835
a lot of different things. Like,
916
01:11:13.370 --> 01:11:17.870
you know, 1st and foremost, this year, Tor has been really awful in providing a really bad
917
01:11:18.250 --> 01:11:19.230
user experience
918
01:11:21.344 --> 01:11:25.844
for people who want to sovereignly run their own node at home, able to,
919
01:11:26.145 --> 01:11:28.780
you know, test when they're out in a meat space. Right?
920
01:11:30.139 --> 01:11:34.800
Something like, you know, these l and d exploits are are sort of exacerbating,
921
01:11:35.659 --> 01:11:37.840
a lot of the frustrations these users have.
922
01:11:39.125 --> 01:11:39.785
You know,
923
01:11:40.565 --> 01:11:45.545
while some users may be technical enough to put together their own node and run something like
924
01:11:46.210 --> 01:11:55.270
Umbrell. They might not, you know, be following or have the understanding to see what's going on with, these exploits and and the real nuance about what's happening.
925
01:11:56.755 --> 01:11:58.455
And that's unfortunate because,
926
01:11:59.235 --> 01:11:59.975
the alternative
927
01:12:00.355 --> 01:12:02.455
is, you know, these users putting
928
01:12:02.915 --> 01:12:04.215
more trust in other
929
01:12:04.540 --> 01:12:06.700
third parties or, you know, running,
930
01:12:07.420 --> 01:12:10.460
you know, just a prebuilt version of,
931
01:12:10.780 --> 01:12:13.955
like, a lightning wallet on their phone that they might not verify.
932
01:12:15.135 --> 01:12:19.554
A lot of users might just be falling back on LSPs as their only peers now.
933
01:12:20.735 --> 01:12:22.994
You know, there's there's a lot of complexity whether
934
01:12:24.640 --> 01:12:27.220
that's a good or a bad thing. But I think, ultimately,
935
01:12:28.000 --> 01:12:35.665
what we're seeing from exploits like this, we have people that are less willing to run Lightning and and are dissuaded from using it at all.
936
01:12:36.285 --> 01:12:40.545
And, I think that's ultimately a bad thing because we have a network that's less distributed
937
01:12:41.220 --> 01:12:42.600
where, you know, these
938
01:12:43.380 --> 01:12:43.880
big
939
01:12:44.500 --> 01:12:49.225
intermediaries are, you know, playing even bigger roles than we'd like them to.
940
01:12:57.900 --> 01:13:00.159
941
01:13:00.540 --> 01:13:01.280
as well.
942
01:13:02.735 --> 01:13:05.555
I just wonder how, like, how that can really be avoided.
943
01:13:07.295 --> 01:13:14.210
944
01:13:15.230 --> 01:13:17.250
But on the other, you just don't want,
945
01:13:17.710 --> 01:13:19.650
like, these centralizing factors.
946
01:13:19.995 --> 01:13:25.695
I mean, obviously, there's, like, a degree of centralization that's gonna happen. Like, you're gonna have, like, these big hubs on the network.
947
01:13:25.995 --> 01:13:28.655
They're gonna use the SSPs or, you know, maybe,
948
01:13:29.400 --> 01:13:35.020
you know, use them as introduction points on blinded past. They offer up a plethora of services. Like, that's unavoidable.
949
01:13:35.719 --> 01:13:37.980
But, like, we also want to make,
950
01:13:40.135 --> 01:13:41.114
you know, having,
951
01:13:41.655 --> 01:13:52.140
having the ability to, you know, be as sovereign as possible and and run this infrastructure out of your house possible and also, like, appealing. Like, we we didn't want this to be something that's that's commonplace.
952
01:13:53.000 --> 01:13:53.320
And,
953
01:13:53.960 --> 01:13:58.060
you know, it's it's it's happening in a lot of ways. Like, something like Umbrell is
954
01:13:58.745 --> 01:14:03.145
a consumer facing product. It's not just corporations that are running this thing. You know? And,
955
01:14:04.185 --> 01:14:05.485
you know, a lot of users
956
01:14:05.850 --> 01:14:08.110
in some nation states like El Salvador
957
01:14:08.730 --> 01:14:12.030
are dependent on lightning to to live every day. Right?
958
01:14:12.570 --> 01:14:20.655
So when we have someone, like, go and exploit something like this and, you know, there's a risk of actual people who are dependent on this stuff
959
01:14:21.275 --> 01:14:22.495
losing savings,
960
01:14:23.420 --> 01:14:25.040
it's, really frustrating,
961
01:14:25.820 --> 01:14:38.795
especially considering all the effort that people are putting into this on the lightning side to make Bitcoin something viable that we could be using in our day to day lives. Was Chivo down during the lnd or block parsing bugs?
962
01:14:41.400 --> 01:14:44.380
963
01:14:45.080 --> 01:14:52.614
is just powered by somebody's back end. It's not it's just it's it's a database, but it also somebody else does their lightning in and out.
964
01:14:53.235 --> 01:14:56.855
I don't know if it's public who does that, so I'm not gonna mention it.
965
01:14:58.210 --> 01:15:00.869
966
01:15:01.250 --> 01:15:02.630
Do that. It's River.
967
01:15:03.809 --> 01:15:06.710
968
01:15:07.075 --> 01:15:12.675
announce that they're doing it. Yeah. It used to be some other folks. Now it's River. I I I know River was able to update pretty quick. So
969
01:15:14.490 --> 01:15:18.910
970
01:15:19.610 --> 01:15:28.055
I think, Chivo's problems really rely on Beyond chain stuff that they've been doing where people will receive a or send a transaction, and then Chivo says it's canceled
971
01:15:28.435 --> 01:15:30.295
despite it being confirmed on the blockchain.
972
01:15:31.955 --> 01:15:32.455
973
01:15:32.960 --> 01:15:34.660
That's pretty bad. I was unaware.
974
01:15:36.000 --> 01:15:43.825
975
01:15:44.445 --> 01:15:54.830
976
01:15:55.210 --> 01:15:57.485
977
01:15:58.045 --> 01:16:03.744
There's a good Bitcoin Magazine article. I know it's kinda getting off in the weeds, but there's a good Bitcoin Magazine article
978
01:16:04.284 --> 01:16:14.930
of people trying to use it now, like, 1 year later, and and people have just sort of given up on on Bitcoin because of the Chivo experiences. So, I mean, that I mean, that kinda relates to Lightning. Right? Like, we have so many,
979
01:16:16.184 --> 01:16:18.764
bugs and exploits and issues with lightning,
980
01:16:19.304 --> 01:16:22.204
that we're that we're all kinda aping into
981
01:16:22.640 --> 01:16:31.540
right now too early, it's gonna leave a bad taste in the mouth. So maybe, like, the more responsible thing to do is kind of have a slow roller a a slow,
982
01:16:32.245 --> 01:16:35.865
rollout of of lightning instead of just jumping into it.
983
01:16:36.725 --> 01:16:39.070
984
01:16:39.550 --> 01:16:40.690
folks in El Salvador
985
01:16:41.550 --> 01:16:42.929
some parts of El Salvador
986
01:16:43.469 --> 01:16:43.969
had
987
01:16:44.429 --> 01:16:48.210
real demand for the features that Bitcoin can provide for people.
988
01:16:48.614 --> 01:16:51.994
Others not so much. You know, it is a US dollar based economy.
989
01:16:52.375 --> 01:16:53.114
There wasn't
990
01:16:53.494 --> 01:17:02.730
you know, inflation's now high with dollars, but especially when that first rolled out, it wasn't, and there wasn't, you know, a lot of of user demand for it.
991
01:17:03.349 --> 01:17:10.075
You know, I'm much more interested in in parts of the world where where there is real user demand because Bitcoin provides a much more compelling,
992
01:17:10.855 --> 01:17:19.110
service compared to the alternatives. You know, your places like Nigeria, your places, you know, with there there's real issue with especially financial seizure,
993
01:17:19.730 --> 01:17:20.790
but also hyperinflation.
994
01:17:21.650 --> 01:17:24.230
And in those places, I think it's it's,
995
01:17:24.845 --> 01:17:35.040
you know, you you can't blame Chivo for all the problems is my point. It's also just that, like, for the most part, people in El Salvador didn't need Bitcoin. They didn't care about Bitcoin. Some people
996
01:17:35.340 --> 01:17:38.960
care about it now, and maybe with the the dollar inflation,
997
01:17:39.260 --> 01:17:40.720
they might care about it more.
998
01:17:41.100 --> 01:17:46.565
But in most parts of El Salvador, there wasn't you know, there are a lot of problems, but financial
999
01:17:47.265 --> 01:17:51.540
like, seizure of of financial assets was not not high on the list.
1000
01:17:52.660 --> 01:18:03.635
1001
01:18:06.095 --> 01:18:07.235
1002
01:18:07.535 --> 01:18:08.675
You know, I think
1003
01:18:09.320 --> 01:18:11.820
what what does need Bitcoin mean? You know, people
1004
01:18:12.360 --> 01:18:15.500
care about different things. And if
1005
01:18:15.880 --> 01:18:16.380
you
1006
01:18:16.965 --> 01:18:24.745
care about something that Bitcoin provides, it's great. You should totally use it. I think my point was more that the average person isn't sitting there considering,
1007
01:18:25.320 --> 01:18:28.380
you know, who their counterparty risk is when they're using the dollar.
1008
01:18:29.240 --> 01:18:40.445
And so to them, Bitcoin's not compelling. It's not solving a problem they see in their daily lives. You know, to those of us Bitcoin is in the west, you know, we might see real you know, like, personally,
1009
01:18:40.825 --> 01:18:52.915
I use lightning to pay for some server bills, not because, like, I don't like the dollar, but actually because it provides a better user experience and it's faster and more reliable than paying with a freaking credit card. And, like,
1010
01:18:53.235 --> 01:18:56.935
that's actually solving a problem for me that I had, you know.
1011
01:18:57.475 --> 01:18:58.295
And and,
1012
01:18:58.595 --> 01:19:08.900
you know, the to to folks in the US who are worried about all kinds of other issues, you know, Bitcoin is providing something that that is an issue to you. It's a little different if,
1013
01:19:10.204 --> 01:19:16.385
you you know, someone's telling you to adopt Bitcoin to solve something that is not already an issue in your mind.
1014
01:19:18.060 --> 01:19:34.545
And and so I I just I care more about places where, like, some people are already thinking about these issues and and the normal average person is already, like, this is a major issue. I need something to solve this issue. Oh, Bitcoin is a solution to this issue rather than
1015
01:19:34.930 --> 01:19:42.790
this isn't a problem for me. Why are you telling me to use Bitcoin? And then maybe a handful of people are like, oh, yeah. This is something I was thinking about and concerned about.
1016
01:19:52.470 --> 01:19:54.250
1017
01:19:55.270 --> 01:19:56.650
you know, just because
1018
01:19:57.030 --> 01:19:58.070
Matt brought up,
1019
01:19:58.550 --> 01:19:59.050
Nigeria,
1020
01:19:59.495 --> 01:20:00.555
There was that partnership,
1021
01:20:00.935 --> 01:20:01.995
with M Pesa,
1022
01:20:02.775 --> 01:20:08.155
that's now going to essentially open up Bitcoin to a lot more users through Bitnub,
1023
01:20:08.660 --> 01:20:10.840
and I believe that opens it up to,
1024
01:20:11.140 --> 01:20:15.800
like, 50,000,000 people. And then Cash App, previously, was probably the largest
1025
01:20:16.100 --> 01:20:16.920
with 44,000,000.
1026
01:20:18.645 --> 01:20:19.304
And then,
1027
01:20:20.324 --> 01:20:25.545
just understanding those, I guess, aren't necessarily, like, daily active users or whatever VCs,
1028
01:20:26.324 --> 01:20:27.784
wanna attribute them to,
1029
01:20:28.290 --> 01:20:31.730
but there might not be addresses either. It's in a weird,
1030
01:20:32.050 --> 01:20:33.670
metric they use where, essentially,
1031
01:20:34.130 --> 01:20:35.270
they have the capability
1032
01:20:35.810 --> 01:20:37.495
of buying it or doing something
1033
01:20:38.215 --> 01:20:38.855
with it. And,
1034
01:20:39.495 --> 01:20:41.275
that says something. Right? Like,
1035
01:20:41.735 --> 01:20:48.700
I don't know. It's, like, for them or they need it, but someone wants to build a service for that market.
1036
01:20:49.960 --> 01:20:59.965
1037
01:21:00.505 --> 01:21:02.685
all the all the major players updated
1038
01:21:03.065 --> 01:21:03.885
really quickly.
1039
01:21:04.860 --> 01:21:08.480
And they all, like, limit who their counterparties are on Lightning.
1040
01:21:10.139 --> 01:21:13.840
1041
01:21:14.265 --> 01:21:18.925
I don't know if if LND has done it, but certainly one thing we've been thinking about more,
1042
01:21:19.305 --> 01:21:22.685
to some extent as a result of this, but also just software maturing,
1043
01:21:23.460 --> 01:21:24.680
is how how we better
1044
01:21:25.140 --> 01:21:26.840
communicate quickly with people
1045
01:21:27.140 --> 01:21:27.640
when,
1046
01:21:29.300 --> 01:21:29.800
when
1047
01:21:30.525 --> 01:21:33.665
something like this happens or when you people need to upgrade urgently.
1048
01:21:34.765 --> 01:21:35.605
There's not
1049
01:21:36.045 --> 01:21:36.945
to my knowledge,
1050
01:21:37.620 --> 01:21:47.244
I don't know if if LND has, like, a a mailing list you can subscribe to or what. But, like, you know, how do you make sure engineers at Cash App and at Kraken and at River
1051
01:21:47.545 --> 01:21:48.284
get paged
1052
01:21:48.665 --> 01:21:54.125
when something like this happened and and and are are told to to move to a computer quickly. Right?
1053
01:21:54.670 --> 01:21:59.410
Versus just like, well, you gotta be following us on Twitter and and make sure you see it,
1054
01:21:59.870 --> 01:22:02.585
which isn't really a a sustainable outcome. And and,
1055
01:22:03.145 --> 01:22:05.725
you know, some companies have engineers who follow
1056
01:22:06.105 --> 01:22:11.245
Bitcoin Twitter personalities, but but others don't. And they shouldn't necessarily need to in order to discover,
1057
01:22:11.719 --> 01:22:13.659
issues that they need to to patch quickly.
1058
01:22:17.800 --> 01:22:24.025
1059
01:22:24.725 --> 01:22:36.990
you know, they they they do have a very extensive email list that they send out every other month to get feedback from people, but haven't heard anything from that about security patches.
1060
01:22:37.675 --> 01:22:41.135
1061
01:22:41.755 --> 01:22:44.015
1062
01:22:44.750 --> 01:22:48.030
Ben Ben Carm, it's always telling me about l and d bugs.
1063
01:22:48.590 --> 01:22:50.369
1064
01:22:51.150 --> 01:22:55.365
And then I'm Ben's source, and shout out to Richard Saffer
1065
01:22:55.825 --> 01:22:56.325
who's,
1066
01:22:56.705 --> 01:23:02.310
DevOps at Zebedee. He's the one who filed the original issue for the first block parsing bug,
1067
01:23:02.790 --> 01:23:03.850
on l and d.
1068
01:23:07.190 --> 01:23:13.795
1069
01:23:14.415 --> 01:23:16.835
1070
01:23:17.250 --> 01:23:22.950
as fast as you might have otherwise. But I'm sure if you hung out in the l and d Slack, you are fine.
1071
01:23:23.410 --> 01:23:30.555
1072
01:23:32.375 --> 01:23:33.675
the almost, like, institutionalized
1073
01:23:34.055 --> 01:23:35.755
user or the corporate user,
1074
01:23:36.760 --> 01:23:39.500
and then there is that end user.
1075
01:23:41.960 --> 01:23:42.940
The end user,
1076
01:23:43.275 --> 01:23:49.215
like, the sovereign node runner, like, we have obviously some issues there in communication.
1077
01:23:51.650 --> 01:23:54.710
But on the on, like, the corporate side
1078
01:23:56.370 --> 01:23:58.550
on the corporate side, is there
1079
01:23:59.745 --> 01:24:02.085
is there something to be said about,
1080
01:24:02.785 --> 01:24:09.420
like, what bottle pay was I I think Youse released it. I think he called it multiplexer where essentially
1081
01:24:10.040 --> 01:24:11.580
you're running multiple nodes,
1082
01:24:12.120 --> 01:24:15.180
of different implementations. Like, Corelightning didn't go down here.
1083
01:24:16.275 --> 01:24:18.135
Is there is there a strong argument
1084
01:24:18.435 --> 01:24:23.895
that the corporate users should essentially just be running multiple lightning implementations at the same time?
1085
01:24:24.940 --> 01:24:27.600
1086
01:24:28.380 --> 01:24:30.640
supports running multiple LND nodes.
1087
01:24:32.220 --> 01:24:32.720
So
1088
01:24:33.445 --> 01:24:34.985
I don't think that's that
1089
01:24:35.525 --> 01:24:39.465
helps here. I know some corporates have built their own solutions for running,
1090
01:24:40.164 --> 01:24:46.940
multiple nodes or at least have talked to me about it. I I don't know that they've actually built it fully or rolled it out.
1091
01:24:47.640 --> 01:25:00.739
I think that's a a valid a valid point to make sure you don't have downtime, but it doesn't protect you from funds loss. And in fact, it it makes your funds loss exposure worse. Right? Because then if any issue, any, implementation has has a bug, you can lose some money.
1092
01:25:02.160 --> 01:25:18.110
1093
01:25:18.810 --> 01:25:19.310
So,
1094
01:25:19.770 --> 01:25:20.350
you know,
1095
01:25:21.105 --> 01:25:34.950
you would be affected by this. And if you had your own watch tower running and you didn't update that in time either, then you would be you would you wouldn't be helped at all. Sure. If you outsource your watch tower to, like, a responsible node runner,
1096
01:25:35.570 --> 01:25:41.335
that is, like, servicing a bunch of users, you you could probably expect that they're at least doing a good service,
1097
01:25:42.355 --> 01:25:44.375
a good good service of running watchtowers,
1098
01:25:44.835 --> 01:25:47.495
even if they are on the same node implementation. But,
1099
01:25:48.130 --> 01:25:54.070
we we desperately need multi node watch towers, the very least. Because these bugs broke the watch towers as well.
1100
01:25:54.530 --> 01:26:00.055
Yeah. Well, the l and d watch tower was also broken, and l and d can only talk to l and d watchtowers.
1101
01:26:00.675 --> 01:26:03.735
1102
01:26:04.355 --> 01:26:05.495
guy Guy Sergio,
1103
01:26:06.040 --> 01:26:16.615
who who Spiral has funded for, several years has won. I believe it currently only supports Core Lightning because Core Lightning is the only node implementation that has enough hooks,
1104
01:26:17.155 --> 01:26:21.655
for it to support. I'm kind of embarrassed that LDK doesn't, but LND certainly doesn't.
1105
01:26:23.210 --> 01:26:33.105
So you you can use that. That does exist. However, it is, again, useful to note that in order for a watchtower to you know, we mentioned that there's 2 kinds of,
1106
01:26:34.525 --> 01:26:37.425
ways you can exploit this class of vulnerability, both
1107
01:26:37.965 --> 01:26:39.335
stealing funds from,
1108
01:26:40.040 --> 01:26:47.020
by broadcasting an old revoked state, and there, a watchtower will get your money back. But if you steal funds using the HTLC,
1109
01:26:48.455 --> 01:26:53.675
logic, if you have a a an HTLC that's routed through you and then someone steals funds using that,
1110
01:26:54.055 --> 01:26:54.555
then,
1111
01:26:55.255 --> 01:26:56.075
you can't,
1112
01:26:58.110 --> 01:27:03.010
use a watchtower currently. And in order to use a watchtower, watchtowers would have to
1113
01:27:03.710 --> 01:27:04.210
expose
1114
01:27:04.510 --> 01:27:05.310
a lot of
1115
01:27:05.965 --> 01:27:09.184
you don't have to expose a lot of information about your channels to that watchtower.
1116
01:27:10.684 --> 01:27:17.570
Losing, you know, one of the pitch of watchtowers today is that they're they're private, that they don't learn about your payment history, about your,
1117
01:27:18.030 --> 01:27:23.730
all the details of your node, and you would have to actually expose all that information to a watchtower to enforce HTLC,
1118
01:27:24.695 --> 01:27:25.594
claims correctly.
1119
01:27:26.054 --> 01:27:31.310
So it would require a bit of a change to the watchtower model. Currently, I don't think anyone's working on that.
1120
01:27:32.270 --> 01:27:33.410
But in order to,
1121
01:27:34.670 --> 01:27:43.875
you know, I guess I guess the moral of the story is is set your HTLC maximum in flight configuration knobs down to a threshold you're okay with losing,
1122
01:27:44.335 --> 01:27:47.075
which is good for everyone's privacy in the network. So do it anyway.
1123
01:27:47.775 --> 01:27:49.235
Make sure you change that value.
1124
01:27:50.140 --> 01:28:05.835
1125
01:28:06.650 --> 01:28:08.590
1126
01:28:09.290 --> 01:28:27.680
I assume at least Corelightning because it's very configurable, has the support for LDK does, if if you're using an LDK node, if you're writing code for an LDK node, you can do it. I would imagine LND does. I don't know for sure. If it doesn't, you should certainly nag them. But you should be able to configure this in your lightning node config or in your channel config to say, like,
1127
01:28:28.060 --> 01:28:30.160
max in flight lower than the total amount.
1128
01:28:30.725 --> 01:28:35.065
At least set it less than half. Ideally set it maybe to a quarter of your channel balance,
1129
01:28:35.685 --> 01:28:37.540
or the maximum you're willing to lose.
1130
01:28:38.100 --> 01:28:41.320
1131
01:28:41.620 --> 01:28:51.055
1132
01:28:51.595 --> 01:28:54.530
below half the channel balance at least, if not less.
1133
01:28:55.150 --> 01:28:58.929
I don't know which nodes, if any, have deployed that default change.
1134
01:28:59.230 --> 01:29:01.345
I'm not even sure if we got around to it yet.
1135
01:29:01.905 --> 01:29:04.565
But but if you do have that setting set,
1136
01:29:04.945 --> 01:29:11.125
then LDK nodes, including Cash App, will slightly prefer to route through you. So maybe you'll actually
1137
01:29:12.200 --> 01:29:15.980
make some some additional get some additional HTLCs and routing revenue,
1138
01:29:16.440 --> 01:29:20.300
to pay for the the reduction in capacity that you that you have in the channel.
1139
01:29:21.045 --> 01:29:24.025
1140
01:29:24.565 --> 01:29:26.665
I believe, also with their API.
1141
01:29:27.205 --> 01:29:28.345
So I think,
1142
01:29:29.219 --> 01:29:31.320
the only one I'm unsure of is eclair,
1143
01:29:32.900 --> 01:29:35.640
but, I I think everyone allows you to set those values.
1144
01:29:39.335 --> 01:29:52.070
1145
01:29:52.610 --> 01:30:00.985
but maybe it's one of those situations where, like, this is just better for the whole network. Let let's just go ahead and do it. But, I'm glad to know that there's there's conversations around it now.
1146
01:30:12.115 --> 01:30:14.055
1147
01:30:14.515 --> 01:30:16.135
like, I still feel like
1148
01:30:17.555 --> 01:30:18.055
I
1149
01:30:18.650 --> 01:30:24.030
like, Carollo, I'm I'm kind of curious. Like, so you you think just unequivocally
1150
01:30:24.730 --> 01:30:26.910
the way Barak proceeded with
1151
01:30:28.225 --> 01:30:31.765
just executing these bugs by issuing a transaction
1152
01:30:32.465 --> 01:30:37.470
was not the way of doing it. There was no benefit of doing it in that way rather than going through normal
1153
01:30:39.470 --> 01:30:39.970
1154
01:30:40.990 --> 01:30:43.650
Yeah. I I don't think there's any reason to
1155
01:30:44.350 --> 01:30:44.850
exploit
1156
01:30:45.235 --> 01:30:46.695
something like this unless,
1157
01:30:48.675 --> 01:30:53.415
unless it's already been patched, unless people have had, you know, at least a little bit of a chance to upgrade.
1158
01:30:53.980 --> 01:30:55.520
You know, you you can debate,
1159
01:30:55.900 --> 01:31:00.400
I think, what the time period after a release with a patch,
1160
01:31:00.835 --> 01:31:03.735
at what point it makes sense to exploit something like this,
1161
01:31:04.514 --> 01:31:06.135
after that patch has been shipped.
1162
01:31:08.440 --> 01:31:09.580
But I don't know
1163
01:31:09.960 --> 01:31:17.020
what that number is. And I I I think it's definitely not negative. It's definitely not before a patch has been made available or at least made public
1164
01:31:17.645 --> 01:31:20.945
that it makes sense to to do this kind of exploit.
1165
01:31:21.885 --> 01:31:32.449
You know, every exploit is unique. Every every vulnerability, every bug is unique in terms of what the specific outcomes are, what the specific, you know, ways it can be exploited,
1166
01:31:33.710 --> 01:31:46.275
ways you can potentially mitigate, all that kind of good stuff. So, you know, it depends a lot on the context. It always depends on the context, but I think that's even more reason to make sure you reach out to the vendor before you before you do anything
1167
01:31:46.750 --> 01:31:55.170
because the vendor you know, some vendors are shitty. I think in Bitcoin, we're pretty lucky. None of the vendors are are really shitty generally. At least to my knowledge, everyone
1168
01:31:55.475 --> 01:31:57.655
takes these kinds of things seriously and appreciates,
1169
01:31:59.555 --> 01:32:00.775
vulnerability reports
1170
01:32:01.155 --> 01:32:07.489
even if it's from somebody they don't like or if it's from someone who's be doing it, you know, rudely or whatever.
1171
01:32:08.190 --> 01:32:11.409
Obviously, that that doesn't apply here, but just, you know, in general,
1172
01:32:12.375 --> 01:32:22.020
vendors can be shitty when you report stuff to them and and some people are are shitty when they do report stuff to you. But I think everyone's pretty pretty chill in the Bitcoin world about this kind of thing.
1173
01:32:22.719 --> 01:32:35.415
So it always makes sense to to reach out to the vendor first. Get their take. Get make sure you're on the same page in terms of how this can be exploited, what the the consequences of it, what you can do to prevent
1174
01:32:35.875 --> 01:32:36.375
exploits,
1175
01:32:36.835 --> 01:32:37.655
taking off,
1176
01:32:38.350 --> 01:32:46.770
and then take action. And I don't I don't think it ever makes sense to take action before you've at least reached out to the vendor initially and and and flagged it to them.
1177
01:32:49.135 --> 01:32:50.755
1178
01:32:52.335 --> 01:32:54.035
it kind of felt like
1179
01:32:54.415 --> 01:32:56.275
enlightening development world
1180
01:32:56.640 --> 01:32:59.620
or just like enlightening network land in general.
1181
01:33:00.480 --> 01:33:01.940
It it kind of felt like
1182
01:33:03.775 --> 01:33:04.675
it kind of felt
1183
01:33:05.135 --> 01:33:05.635
1184
01:33:07.054 --> 01:33:07.554
1185
01:33:08.014 --> 01:33:14.970
were a bit naive, and a lot of it was glossed over with, like, hashtag reckless or whatnot, but, like, real funds are on the line,
1186
01:33:15.430 --> 01:33:17.130
and they're all hot wallets.
1187
01:33:19.270 --> 01:33:23.015
This kind of the way Barack did it to me felt like
1188
01:33:23.475 --> 01:33:27.655
a shot across the bow, like, we are entering an adversarial environment.
1189
01:33:29.260 --> 01:33:30.400
Consider the risks.
1190
01:33:30.940 --> 01:33:33.200
And I think a lot of users, as a result,
1191
01:33:34.060 --> 01:33:40.815
now have a different feeling. Particularly, node runners have a different, you know, perspective on lightning. They're more aware of the trade offs.
1192
01:33:41.675 --> 01:33:51.520
1193
01:33:52.460 --> 01:33:56.165
accurately communicating the risks? I think the answer you you're right. They're not,
1194
01:33:56.645 --> 01:34:02.025
and that that needs to change. And that's something that's that's frustrated me in a few contexts across the lightning space.
1195
01:34:03.045 --> 01:34:04.745
And so, you know, I I think
1196
01:34:05.460 --> 01:34:08.760
Lightning node vendors generally need to do a better job at that. Totally.
1197
01:34:09.620 --> 01:34:14.280
It's a separate question as to whether or not to exploit something before there's a patch.
1198
01:34:14.725 --> 01:34:21.065
And then, you know, if you if your goal is to have a similar outcome of, like, making sure it's clear
1199
01:34:21.764 --> 01:34:22.264
that
1200
01:34:22.659 --> 01:34:23.159
they,
1201
01:34:23.540 --> 01:34:27.400
that users see this and feel urgency to upgrade,
1202
01:34:28.340 --> 01:34:32.119
generating a similar feeling. You could say, you know, exploit it,
1203
01:34:32.785 --> 01:34:41.365
you know, 8 hours after the patch is released or something. You know? Make sure people have a have a chance to upgrade, you know, even the people who were asleep at the time the patch was released, whatever,
1204
01:34:42.160 --> 01:34:45.219
and and then do it. You know, I I I don't think that's
1205
01:34:46.000 --> 01:34:58.370
I don't know that I would decide to to exploit it that quickly, but you you could make an argument for that and that becomes more of a a value judgment that we'd have to debate. And I don't think there's, like, a correct answer. There's never a correct answer or you know?
1206
01:34:59.870 --> 01:35:00.350
So
1207
01:35:01.070 --> 01:35:04.450
but but doing it beforehand, I think, is a little different.
1208
01:35:05.035 --> 01:35:12.255
And and certainly, you know, another part of responsible something that's not a part of responsible disclosure is how it gets communicated. Right? So,
1209
01:35:13.190 --> 01:35:17.290
the vendor always vendors always wanna choose how something gets communicated,
1210
01:35:17.670 --> 01:35:23.275
but that's ultimately not just their choice. That's also the reporter's choice. Right? So if the reporter is like,
1211
01:35:23.975 --> 01:35:31.240
you know, I think this is a huge deal and you're not doing a good job of communicating it, the reporter is totally free to go on Twitter and say, like,
1212
01:35:31.800 --> 01:35:32.860
vendor is moron.
1213
01:35:33.320 --> 01:35:34.380
Screw this vendor.
1214
01:35:34.760 --> 01:35:42.515
They're not telling you the the real story, and this is a huge deal, and you need to upgrade ASAP and, like, your funds are at risk and look, here's why.
1215
01:35:43.235 --> 01:35:46.375
That's totally legitimate. That's that's not you know, how
1216
01:35:46.675 --> 01:35:47.815
an issue gets communicated
1217
01:35:48.195 --> 01:35:49.739
is not a part of responsible disclosure.
1218
01:35:50.360 --> 01:35:55.739
Your your duty is to the users to make sure you minimize the risk that users lose funds,
1219
01:35:56.365 --> 01:35:59.025
But there's a lot that goes into that
1220
01:35:59.325 --> 01:35:59.825
and,
1221
01:36:00.445 --> 01:36:03.345
you know, there's no correct answer. Again, everything's unique.
1222
01:36:05.005 --> 01:36:05.450
But
1223
01:36:06.330 --> 01:36:07.530
I I think it it it
1224
01:36:08.490 --> 01:36:12.510
I I think it's pretty clear that exploiting this before there's a patch
1225
01:36:12.890 --> 01:36:13.870
does not minimize
1226
01:36:14.410 --> 01:36:17.905
user risk. I think it it it's pretty clear that there are
1227
01:36:18.284 --> 01:36:21.025
many different ways to go about this that might get
1228
01:36:21.804 --> 01:36:26.440
similar responses in every way that would have minimized the risk a little more
1229
01:36:26.980 --> 01:36:29.880
by just waiting to exploit it until after there was a path.
1230
01:36:32.835 --> 01:36:38.295
1231
01:36:38.910 --> 01:36:41.890
Now, of course, Brock was honing on a specific one,
1232
01:36:43.230 --> 01:37:01.480
and and there's a lot more that that we found out. How from the vendor approach, what would have been what would have been, like, a reasonable thing to do? Because I I could be wrong, but I think I remember years back, Bitcoin Core had this scenario where there was a responsible disclosure to Bitcoin Core from from some shitcoin Bitcoin side chain thing.
1233
01:37:02.340 --> 01:37:07.554
And Bitcoin Core fixed it and then released, you know, released it, but the other chains,
1234
01:37:08.415 --> 01:37:17.610
were vulnerable to it. Now you could argue, you know, fuck those shit coins or whatever. But when there's an issue that could be affecting everyone, but only one party knows about it,
1235
01:37:18.230 --> 01:37:20.315
is is that a problem at all?
1236
01:37:21.835 --> 01:37:23.135
1237
01:37:23.675 --> 01:37:30.790
who do you owe a duty of care to is is a huge question that has no answer. There you're right. There were a lot of discussions
1238
01:37:31.730 --> 01:37:33.510
around that bug, around
1239
01:37:33.890 --> 01:37:37.805
do Bitcoin Core developers have a duty of care to every random,
1240
01:37:39.705 --> 01:37:43.245
fork of Bitcoin Core building any random coin.
1241
01:37:44.260 --> 01:37:44.840
You know,
1242
01:37:45.940 --> 01:37:47.320
I personally think they don't.
1243
01:37:48.260 --> 01:37:54.120
That's just my view. You know, I don't think I think Bitcoin Core developers have a duty of care to Bitcoin users,
1244
01:37:55.965 --> 01:38:00.185
and not a legal duty of care, mind you, but but, you know, a moral duty of care
1245
01:38:01.460 --> 01:38:08.199
and and not to anyone else. And that, you know, insofar as you can do anything to to avoid other people getting screwed,
1246
01:38:08.500 --> 01:38:09.239
you should.
1247
01:38:09.540 --> 01:38:12.415
But, certainly, you don't have a duty of care,
1248
01:38:13.835 --> 01:38:19.215
where it might impact where it might negatively impact Bitcoin users. And that includes, you know, if you tell
1249
01:38:19.970 --> 01:38:21.030
with any vulnerability
1250
01:38:22.210 --> 01:38:49.465
the, you know, one thing that that you have to maximize, you have to make sure you don't tell any more people that need to know. Right? That that kind of information should always be need to know because, you know, any additional people you tell, they might tell their friend and their friend might exploit it or they might have it up on their screen at a conference and somebody might read it and exploit it or or what have you. And especially when you're talking about other coins, you know, that that can be a very adversarial relationship. So I do know, you know, when it was
1251
01:38:50.245 --> 01:39:01.900
disclosed by Bitcoin Core or maybe kind of an hour before or something like that. You know, once once it was clear that Bitcoin was a little safer and then when it was going to go public anyway, a number of people were notified,
1252
01:39:02.245 --> 01:39:05.065
you know, kind of immediately prior or maybe an hour before,
1253
01:39:06.485 --> 01:39:11.865
to make sure they had at least a little bit of a chance to to catch up and and fix their own stuff.
1254
01:39:12.930 --> 01:39:20.790
I don't recall whether any other coins were. I think maybe, like, b cash was or something or, like, one
1255
01:39:21.715 --> 01:39:32.440
coin or 2 where there was, like, you know, at least a little bit larger market cap, at least a little bit larger user base, and some of the developers had had a history of being reasonable,
1256
01:39:32.820 --> 01:39:35.880
even if their community maybe wasn't, their their developers were.
1257
01:39:37.324 --> 01:39:42.545
But but no. I mean, I I don't think Bitcoin Core developers have a duty of care to other clients.
1258
01:39:44.500 --> 01:39:45.000
But
1259
01:39:45.380 --> 01:39:45.880
yeah.
1260
01:39:47.700 --> 01:39:48.200
1261
01:39:48.580 --> 01:39:49.080
CLN
1262
01:39:49.700 --> 01:39:53.085
developers have any duty to to l and d developers?
1263
01:39:54.265 --> 01:39:55.725
1264
01:39:56.185 --> 01:39:57.145
to bring that up.
1265
01:39:57.545 --> 01:39:58.765
Matt brought up communications
1266
01:39:59.780 --> 01:40:01.000
of, disclosures.
1267
01:40:02.020 --> 01:40:02.520
Brock,
1268
01:40:02.980 --> 01:40:05.000
why did you choose to
1269
01:40:05.380 --> 01:40:07.239
write what you did in the off return?
1270
01:40:11.125 --> 01:40:12.264
1271
01:40:12.645 --> 01:40:20.559
1272
01:40:20.860 --> 01:40:26.315
just you know, I'm making this transaction and why not just put something in there? I just
1273
01:40:27.015 --> 01:40:28.555
yeah. I just put some message.
1274
01:40:29.175 --> 01:40:35.329
1275
01:40:35.869 --> 01:40:36.369
1276
01:40:37.230 --> 01:40:39.170
It was, yeah, it was referenced to,
1277
01:40:40.429 --> 01:40:41.730
World Economic Forum.
1278
01:40:43.405 --> 01:40:43.905
Yeah.
1279
01:40:45.085 --> 01:40:48.900
That was for fun and for trolling. Yeah. Yeah. I I'm not sponsored
1280
01:40:57.295 --> 01:41:01.635
the message was for trolling. I have no problems whatsoever with Lining Labs.
1281
01:41:02.094 --> 01:41:04.114
I love folks working at Lining Labs.
1282
01:41:05.110 --> 01:41:07.370
In fact, in favor of multiple implementations,
1283
01:41:08.390 --> 01:41:12.970
whether it's LND and CLN or other Bitcoin query implement other Bitcoin implementations,
1284
01:41:13.785 --> 01:41:15.165
I don't have any problem.
1285
01:41:15.465 --> 01:41:15.965
I
1286
01:41:16.745 --> 01:41:17.725
I'm just trolling.
1287
01:41:21.469 --> 01:41:23.650
1288
01:41:24.190 --> 01:41:24.690
We
1289
01:41:25.310 --> 01:41:27.170
have a duty of care, but
1290
01:41:27.630 --> 01:41:28.849
that was just trolling.
1291
01:41:29.595 --> 01:41:35.135
We have a duty of care to each other. You know? As anyone that's part of the Bolt compliance spec,
1292
01:41:35.515 --> 01:41:36.495
we work together
1293
01:41:37.250 --> 01:41:39.110
as much as possible. I consider
1294
01:41:40.050 --> 01:41:43.110
Evan a good friend, Lalu as well, Con,
1295
01:41:44.905 --> 01:41:45.724
and, Sueb.
1296
01:41:46.344 --> 01:41:46.844
So,
1297
01:41:47.465 --> 01:41:48.125
you know,
1298
01:41:48.985 --> 01:41:52.284
we all, like, are in this community together, and I think
1299
01:41:52.830 --> 01:41:54.290
I also am a bit
1300
01:41:54.990 --> 01:41:57.650
guilty of this stirring the pot sometimes when,
1301
01:41:58.510 --> 01:42:00.610
you know, tempers get flared up about
1302
01:42:01.565 --> 01:42:02.945
decisions based on
1303
01:42:03.565 --> 01:42:07.485
upgrades or what priorities should be. But at the end of the day,
1304
01:42:08.125 --> 01:42:10.705
we're in this together, and I really value
1305
01:42:11.390 --> 01:42:13.570
everyone contributing to the Bolt specs.
1306
01:42:14.750 --> 01:42:18.040
1307
01:42:19.445 --> 01:42:21.065
who's been running lightning,
1308
01:42:21.685 --> 01:42:23.785
specifically l and d for 3 years,
1309
01:42:24.405 --> 01:42:26.105
extremely well connected node,
1310
01:42:27.760 --> 01:42:32.900
nearly 200 channels. I had more than that at one point. I have no idea who any of my counterparties are.
1311
01:42:34.160 --> 01:42:37.380
Part of the reason why I was running it was to see
1312
01:42:38.145 --> 01:42:41.844
if I would lose money, and I'm pretty sure I haven't lost money yet.
1313
01:42:44.465 --> 01:42:46.405
So, yeah, cheers to that.
1314
01:42:48.440 --> 01:42:49.820
Thank thank you for your service.
1315
01:42:51.960 --> 01:42:53.595
1316
01:42:54.555 --> 01:42:59.455
1317
01:43:00.075 --> 01:43:02.840
sale environment at all. Barak's is, like,
1318
01:43:03.380 --> 01:43:09.400
quote, unquote attack is, like, signaling that. But, like, I mean, we definitely aren't. I I, like, when I went to Nashville,
1319
01:43:09.705 --> 01:43:13.085
like, earlier this year, my lightning node went down on the
1320
01:43:13.465 --> 01:43:14.585
plane over, and that was,
1321
01:43:15.545 --> 01:43:25.370
you know, I never I don't lose any money either. So, like, people could have clearly stolen from me and didn't. You know, it's it's definitely not a non air Australian environment and
1322
01:43:26.455 --> 01:43:27.755
I don't know. Hopefully hopefully
1323
01:43:28.135 --> 01:43:29.595
is is bad, but, like,
1324
01:43:30.295 --> 01:43:41.450
we need to get there. Like, if we're in there, that means it's like lightning is a lot more legit. It's not just like, you know, attacks or trolls anymore. It's like actually, like, people trying to steal money and potentially profiting
1325
01:43:41.815 --> 01:43:42.554
from it.
1326
01:43:42.934 --> 01:43:43.434
But
1327
01:43:43.815 --> 01:43:47.955
I don't know if we're there yet, but it'd be cool to actually see real
1328
01:43:48.295 --> 01:43:53.840
feel like you know, because, like, in the DeFi space, something like this is like a full time job of people
1329
01:43:54.300 --> 01:43:55.600
Bitcoin projects. So
1330
01:43:55.980 --> 01:44:00.665
it'd be, you know, scary but also cool to see people doing the same thing in light.
1331
01:44:04.725 --> 01:44:08.344
1332
01:44:08.990 --> 01:44:20.995
1333
01:44:22.815 --> 01:44:33.435
1334
01:44:33.995 --> 01:44:41.135
But I just, you know, keep keep in mind that that as humans, we wanna we wanna help each other, at least as as non
1335
01:44:41.595 --> 01:44:52.675
you know, we we we should just, you know, do do what you think is right for the for the people, not for the vendor or anybody else. But thanks for having me on. Out. Thanks, Matt. Appreciate you. Evan, final thoughts.
1336
01:44:54.335 --> 01:44:55.155
1337
01:44:56.335 --> 01:44:58.435
you know, I think there's a great discussion today.
1338
01:44:59.220 --> 01:45:06.040
Barak, I think, you got your taste of the dark side. I hope moving forward, you consider coming back to the light.
1339
01:45:06.695 --> 01:45:12.074
I I know our community has a lot of values of, like, anarchism, but that still requires cooperation for,
1340
01:45:13.015 --> 01:45:15.195
you know, the benefit of the community.
1341
01:45:15.540 --> 01:45:17.080
And, you know, ultimately,
1342
01:45:17.620 --> 01:45:21.239
I think you're a really talented guy. Just, we hate for you to keep going down
1343
01:45:22.020 --> 01:45:22.760
on this
1344
01:45:23.805 --> 01:45:24.364
path and,
1345
01:45:25.805 --> 01:45:31.505
there's positives to this, but, you know, it's not something I would like to see happen again.
1346
01:45:32.949 --> 01:45:33.849
1347
01:45:36.469 --> 01:45:37.690
Vivek, final thoughts.
1348
01:45:39.545 --> 01:45:44.285
1349
01:45:45.305 --> 01:45:50.699
Wanted to thank everyone that actually joined. Felt it was great that, we had Evan and,
1350
01:45:51.960 --> 01:45:53.659
Matt Corallo here, especially.
1351
01:45:54.679 --> 01:46:00.495
Ben, fix your Internet, and thank you all freaks for listening to us. Thanks, Vivek. I hope,
1352
01:46:01.135 --> 01:46:08.500
1353
01:46:09.280 --> 01:46:10.420
Ben, final thoughts.
1354
01:46:12.160 --> 01:46:14.660
1355
01:46:16.255 --> 01:46:18.755
you know, that I'll I'll stick with that.
1356
01:46:20.175 --> 01:46:22.275
1357
01:46:23.535 --> 01:46:24.915
1358
01:46:26.640 --> 01:46:27.140
Yeah.
1359
01:46:27.520 --> 01:46:32.820
I I think I think all, you know, all things like this make Bitcoin better in the end. So,
1360
01:46:33.585 --> 01:46:37.684
Barak, if you wanna coordinate on more dark side things, let me know.
1361
01:46:39.665 --> 01:46:41.844
1362
01:46:42.320 --> 01:46:48.580
1363
01:46:49.095 --> 01:46:52.875
5,000 Bitcoin is a joke number. I still see lightning as a playground.
1364
01:46:54.055 --> 01:46:58.235
And, yeah, I love breaking things and I besides, I believe,
1365
01:46:58.790 --> 01:46:59.930
attacks help Bitcoin,
1366
01:47:00.470 --> 01:47:00.970
helps,
1367
01:47:01.910 --> 01:47:05.290
hardening the the software, the infrastructure for long term stability.
1368
01:47:06.645 --> 01:47:13.225
I'm not saying this in defense of my actions. I'm just saying this as thought as my as as my thought thought consideration.
1369
01:47:15.619 --> 01:47:18.920
My only motive was for fun, and I guess,
1370
01:47:19.460 --> 01:47:22.840
I'll I'll dig more into codebase and see if there are any other exploits.
1371
01:47:24.185 --> 01:47:30.605
1372
01:47:31.225 --> 01:47:35.840
I do appreciate it. To all the freaks, I wanna thank you for joining us for this conversation,
1373
01:47:37.100 --> 01:47:43.095
particularly the freaks who joined us in the live chat. I know it's a Friday evening. I know it's a crazy week,
1374
01:47:43.475 --> 01:47:45.895
but you guys make it special. Once again,
1375
01:47:46.275 --> 01:47:50.080
dispatch has no ads or sponsors. It's funded purely by you guys.
1376
01:47:50.699 --> 01:47:53.280
There's a lot of value for value haters out there,
1377
01:47:55.100 --> 01:48:08.310
including some people I've recorded podcasts with in the past. I think we can prove them wrong. I think most people are just half in, half out and not actually trying to make value for value work. So I do appreciate you guys seeing seeing the stats flow and seeing
1378
01:48:08.850 --> 01:48:20.515
dispatch consistently on the top of the fountain leaderboards really makes it all worth it. I appreciate you all. Once again, it is a bear market. If you can't contribute stats, sharing with your friends and family helps, subscribing in your favorite podcast app helps,
1379
01:48:20.990 --> 01:48:25.630
Subscribing on YouTube, Twitch. I mean, don't use YouTube. But if you are gonna use YouTube, subscribe to the channel.
1380
01:48:27.390 --> 01:48:34.955
It it is appreciated. Every little bit helps, and, it keeps us going forward. I wanna say to all the freaks, I know it's been a long week.
1381
01:48:35.970 --> 01:48:40.630
It's mostly Shitcoiners playing Shitcoin games. Fiat Maximal is playing Fiat games.
1382
01:48:41.970 --> 01:48:43.270
Bitcoin remains unaffected.
1383
01:48:43.935 --> 01:48:46.675
I love you all. We're gonna keep moving forward here.
1384
01:48:48.014 --> 01:48:52.594
We can't be stopped if we if if we work together. So I appreciate everybody.
1385
01:48:53.699 --> 01:48:54.679
Have a great weekend.
1386
01:48:55.699 --> 01:48:57.159
Stay humble, stack sets.
