1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
|
Return-Path: <keagan.mcclelland@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 54D5EC07FF;
Thu, 7 May 2020 04:07:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 4383986C76;
Thu, 7 May 2020 04:07:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qvj9OUfyNEos; Thu, 7 May 2020 04:07:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com
[209.85.208.53])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 29DEA86C6D;
Thu, 7 May 2020 04:07:23 +0000 (UTC)
Received: by mail-ed1-f53.google.com with SMTP id r7so4120653edo.11;
Wed, 06 May 2020 21:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=kIjCyXDsy/Qjt3TeGzEqYc9XwyrK0ecyyso5kSDEk7M=;
b=u2CWYY8E+IUZwlq3jKAeB+znx5wjLXV/yGH4hCcbgHAj7LinlhkkpZgxppQeVo9qhI
qtRiEgOz1xDKtHc9gn4kF3A3kEsbBZZhKM7jbQ3tuObgqvms/Yxcaub8vfU2ZkiKXZxd
AsRhMYwc7cZcwqn2tIFzZf7IY/BZcISAq3H0W9EUuzVOqXuAtSCoZN28enwKv7WP64LV
1r8l9dcB03Gnc1tNYZ0U5uf0EgJak7iXyI4GXwXcCezhmYwn+XpnsFBJrypPir9vxw1+
DeTsv1PzIk4M2WqCS5XhNaIScGSEv4nfBPpXnUn/u1M+6OYsEmQ/ne4+EkShz0zKOCrt
mCIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=kIjCyXDsy/Qjt3TeGzEqYc9XwyrK0ecyyso5kSDEk7M=;
b=RImv9Y3licKl9EANU3KuoTnQjlZiGGZvMlwZjsUbrUaK18JWFamyJ/f9MacsnpvlON
Zpm4BZhDnmQ6b9EMJOnOnodUooiU0boJiylFZ1K4TFwydLvJ5V1x45S3E6C3rD47Nn+O
tTCidqPRp/N0+5kHJX0oWktB0Dn8xLPeLMQ/Wah8I5clt87t3yDlU6pMWZig9Ddt+3NN
QBFzp2baMp83Z6yRUKnOdwP5yjLE2RPe7y6heUG8IsB/lV6Rp32MXkquKPHGF39FprfB
/KcypWEPrRHZmiqBN7AbhQiplfi7jP6owft6BM4jozRWCOaqEpNzn0FHFcn37ORAMB1b
1HWA==
X-Gm-Message-State: AGi0Pub6jsvspTbS1roZNpy3fI7h6pD7D/fH15Aibi1DUZaeuEcMpO5R
+vbHy+Z7Zg63naz8DixvCk5r5JY2N1tKP2tKeRg=
X-Google-Smtp-Source: APiQypIrjoeqaY+8Msm/ZfvM+nJGTLaHXdVVj49yTaK842Huymsd3jo47DFboWpkhLf9iFKhACAOprOY6ngFKdoJ2m8=
X-Received: by 2002:aa7:d311:: with SMTP id p17mr10025045edq.73.1588824441584;
Wed, 06 May 2020 21:07:21 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
<202005051300.38836.luke@dashjr.org>
<CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com>
<CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
<CALZpt+Fmv3d-J69uyoJ5XB9hP78vqoS76Y2OVmHWqafkHTm5ZQ@mail.gmail.com>
In-Reply-To: <CALZpt+Fmv3d-J69uyoJ5XB9hP78vqoS76Y2OVmHWqafkHTm5ZQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Wed, 6 May 2020 22:07:09 -0600
Message-ID: <CALeFGL3WRF11Q7d3Mea5nHS2da1atEfXArpdAfMfd1uJ+5f3JA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007381ac05a5070403"
X-Mailman-Approved-At: Thu, 07 May 2020 08:04:42 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of
onboarding millions of LN mobile clients
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 04:07:26 -0000
--0000000000007381ac05a5070403
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I think that one of the solutions here is to have light clients choose
their full node tethers explicitly. Even if you think it is unrealistic to
have everyone run their own node (fwiw, I don=E2=80=99t), there is still a =
trust
model where you can pick your trusted source.
This way you could have many light clients working off of a family node,
and the peer services could be limited to some sort of =E2=80=9Cauthenticat=
ed=E2=80=9D
peers. Perhaps this is better accomplished over the RPC interface in Core,
but the idea is to have some sort of peer service model between =E2=80=9Cfu=
ll
public=E2=80=9D and =E2=80=9Cowner only=E2=80=9D. This limits the amount of=
costs that can be
properly externalized, without exposing risk of consensus capture by
economically weighty institutions.
Keagan
On Wed, May 6, 2020 at 9:56 PM Antoine Riard <antoine.riard@gmail.com>
wrote:
> What I'm thinking more is if the costs of security are being too much
> externalized from the light clients onto full nodes, nodes operators are
> just going to stop servicing light clients `peercfilters=3Dfalse`. The
> backbone p2p network is going to be fine. But the massive LN light client=
s
> network built on top is going to rely on centralized services for its cha=
in
> access and now you may have consensus capture by those..
>
> Le mer. 6 mai 2020 =C3=A0 12:00, Keagan McClelland <keagan.mcclelland@gma=
il.com>
> a =C3=A9crit :
>
>> Hi Antoine,
>>
>> Consensus capture by miners isn't the only concern here. Consensus
>> capture by any subset of users whose interests diverge from the overall
>> consensus is equally damaging. The scenario I can imagine here is that t=
he
>> more light clients outpace full nodes, the more the costs of security ar=
e
>> being externalized from the light clients onto the full nodes. In this
>> situation, it can make full nodes harder to run. If they are harder to r=
un
>> it will price out some marginal set of full node operators, which causes=
a
>> net new increase in light clients (as the disaffected full nodes convert=
),
>> AND a redistribution of load onto a smaller surface area. This is a
>> naturally unstable process. It is safe to say that as node counts drop, =
the
>> set of node operators will increasingly represent economic actors with
>> extreme weight. The more this process unfolds, the more likely their
>> interests will diverge from the population at large, and also the more
>> likely they can be coerced into behavior they otherwise wouldn't. After =
all
>> it is easier to find agents who carry lots of economic weight. This is t=
rue
>> independent of their mining status, we should be just as wary of consens=
us
>> capture by exchanges or HNWI's as we are about miners.
>>
>> Keagan
>>
>> On Wed, May 6, 2020 at 3:06 AM Antoine Riard <antoine.riard@gmail.com>
>> wrote:
>>
>>> I do see the consensus capture argument by miners but in reality isn't
>>> this attack scenario have a lot of assumptions on topology an deploymen=
t ?
>>>
>>> For such attack to succeed you need miners nodes to be connected to
>>> clients to feed directly the invalid headers and if these ones are
>>> connected to headers/filters gateways, themselves doing full-nodes
>>> validation invalid chain is going to be sanitized out ?
>>>
>>> Sure now you trust these gateways, but if you have multiple connections
>>> to them and can guarantee they aren't run by the same entity, that mayb=
e an
>>> acceptable security model, depending of staked amount and your
>>> expectations. I more concerned of having a lot of them and being
>>> diversified enough to avoid collusion between gateways/chain access
>>> providers/miners.
>>>
>>> But even if you light clients is directly connected to the backbone
>>> network and may be reached by miners you can implement fork anomalies
>>> detection and from then you may have multiples options:
>>> * halt the wallet, wait for human intervention
>>> * fallback connection to a trusted server, authoritative on your chain
>>> view
>>> * invalidity proofs?
>>>
>>> Now I agree you need a wide-enough, sane backbone network to build on
>>> top, and we should foster node adoption as much as we can.
>>>
>>> Le mar. 5 mai 2020 =C3=A0 09:01, Luke Dashjr <luke@dashjr.org> a =C3=A9=
crit :
>>>
>>>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>>> > Trust-minimization of Bitcoin security model has always relied first
>>>> and
>>>> > above on running a full-node. This current paradigm may be shifted b=
y
>>>> LN
>>>> > where fast, affordable, confidential, censorship-resistant payment
>>>> services
>>>> > may attract a lot of adoption without users running a full-node.
>>>>
>>>> No, it cannot be shifted. This would compromise Bitcoin itself, which
>>>> for
>>>> security depends on the assumption that a supermajority of the economy
>>>> is
>>>> verifying their incoming transactions using their own full node.
>>>>
>>>> The past few years has seen severe regressions in this area, to the
>>>> point
>>>> where Bitcoin's future seems quite bleak. Without serious improvements
>>>> to the
>>>> full node ratio, Bitcoin is likely to fail.
>>>>
>>>> Therefore, all efforts to improve the "full node-less" experience are
>>>> harmful,
>>>> and should be actively avoided. BIP 157 improves privacy of fn-less
>>>> usage,
>>>> while providing no real benefits to full node users (compared to more
>>>> efficient protocols like Stratum/Electrum).
>>>>
>>>> For this reason, myself and a few others oppose merging support for BI=
P
>>>> 157 in
>>>> Core.
>>>>
>>>> > Assuming a user adoption path where a full-node is required to
>>>> benefit for
>>>> > LN may deprive a lot of users, especially those who are already
>>>> denied a
>>>> > real financial infrastructure access.
>>>>
>>>> If Bitcoin can't do it, then Bitcoin can't do it.
>>>> Bitcoin can't solve *any* problem if it becomes insecure itself.
>>>>
>>>> Luke
>>>>
>>>> P.S. See also
>>>>
>>>> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206baf=
a5fda0
>>>>
>>>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-so=
vereignty-18fac5bcdc25
>>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
--0000000000007381ac05a5070403
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div><div dir=3D"auto">I think that one of the solutions here is to have li=
ght clients choose their full node tethers explicitly. Even if you think it=
is unrealistic to have everyone run their own node (fwiw, I don=E2=80=99t)=
, there is still a trust model where you can pick your trusted source.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">This way you could h=
ave many light clients working off of a family node, and the peer services =
could be limited to some sort of =E2=80=9Cauthenticated=E2=80=9D peers. Per=
haps this is better accomplished over the RPC interface in Core, but the id=
ea is to have some sort of peer service model between =E2=80=9Cfull public=
=E2=80=9D and =E2=80=9Cowner only=E2=80=9D. This limits the amount of costs=
that can be properly externalized, without exposing risk of consensus capt=
ure by economically weighty institutions.</div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Keagan</div><div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, May 6, 2020 at 9:56 PM Antoine R=
iard <<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.com=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>What I'm thinking more is if the costs of security are being too muc=
h externalized from the light clients onto full nodes, nodes operators are =
just going to stop servicing light clients `peercfilters=3Dfalse`. The back=
bone p2p network is going to be fine. But the massive LN light clients netw=
ork built on top is going to rely on centralized services for its chain acc=
ess and now you may have consensus capture by those..<br></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer.=
6 mai 2020 =C3=A0=C2=A012:00, Keagan McClelland <<a href=3D"mailto:keag=
an.mcclelland@gmail.com" target=3D"_blank">keagan.mcclelland@gmail.com</a>&=
gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Consensu=
s capture by miners isn't the only concern here. Consensus capture by a=
ny subset of users whose interests diverge from the overall consensus is eq=
ually damaging. The scenario I can imagine here is that the more light clie=
nts outpace full nodes, the more the costs of security are being externaliz=
ed from the light clients onto the full nodes. In this situation, it can ma=
ke full nodes harder to run. If they are harder to run it will price out so=
me marginal set of full node operators, which causes a net new increase in =
light clients (as the disaffected full nodes convert), AND a redistribution=
of load onto a smaller surface area. This is a naturally unstable process.=
It is safe to say that as node counts drop, the set of node operators will=
increasingly represent economic actors with extreme weight. The more this =
process unfolds, the more likely their interests will diverge from the popu=
lation at large, and also the more likely they can be coerced into behavior=
they otherwise wouldn't. After all it is easier to find agents who car=
ry lots of economic weight. This is true independent of their mining status=
, we should be just as wary of consensus capture by exchanges or HNWI's=
as we are about miners.</div><div><br></div><div>Keagan<br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, M=
ay 6, 2020 at 3:06 AM Antoine Riard <<a href=3D"mailto:antoine.riard@gma=
il.com" target=3D"_blank">antoine.riard@gmail.com</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I do=
see the consensus capture argument by miners but in reality isn't this=
attack scenario have a lot of assumptions on topology an deployment ?<br><=
br></div><div>For such attack to succeed you need miners nodes to be connec=
ted to clients to feed directly the invalid headers and if these ones are c=
onnected to headers/filters gateways, themselves doing full-nodes validatio=
n invalid chain is going to be sanitized out ?<br><br></div><div>Sure now y=
ou trust these gateways, but if you have multiple connections to them and c=
an guarantee they aren't run by the same entity, that maybe an acceptab=
le security model, depending of staked amount and your expectations. I more=
concerned of having a lot of them and being diversified enough to avoid co=
llusion between gateways/chain access providers/miners.<br><br></div><div>B=
ut even if you light clients is directly connected to the backbone network =
and may be reached by miners you can implement fork anomalies detection and=
from then you may have multiples options:<br></div><div>* halt the wallet,=
wait for human intervention<br></div><div>* fallback connection to a trust=
ed server, authoritative on your chain view<br></div><div>* invalidity proo=
fs?<br><br></div><div>Now I agree you need a wide-enough, sane backbone net=
work to build on top, and we should foster node adoption as much as we can.=
<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A009:01, Luke Dashjr <<a hre=
f=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>> a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:<br>
> Trust-minimization of Bitcoin security model has always relied first a=
nd<br>
> above on running a full-node. This current paradigm may be shifted by =
LN<br>
> where fast, affordable, confidential, censorship-resistant payment ser=
vices<br>
> may attract a lot of adoption without users running a full-node.<br>
<br>
No, it cannot be shifted. This would compromise Bitcoin itself, which for <=
br>
security depends on the assumption that a supermajority of the economy is <=
br>
verifying their incoming transactions using their own full node.<br>
<br>
The past few years has seen severe regressions in this area, to the point <=
br>
where Bitcoin's future seems quite bleak. Without serious improvements =
to the <br>
full node ratio, Bitcoin is likely to fail.<br>
<br>
Therefore, all efforts to improve the "full node-less" experience=
are harmful, <br>
and should be actively avoided. BIP 157 improves privacy of fn-less usage, =
<br>
while providing no real benefits to full node users (compared to more <br>
efficient protocols like Stratum/Electrum).<br>
<br>
For this reason, myself and a few others oppose merging support for BIP 157=
in <br>
Core.<br>
<br>
> Assuming a user adoption path where a full-node is required to benefit=
for<br>
> LN may deprive a lot of users, especially those who are already denied=
a<br>
> real financial infrastructure access.<br>
<br>
If Bitcoin can't do it, then Bitcoin can't do it.<br>
Bitcoin can't solve *any* problem if it becomes insecure itself.<br>
<br>
Luke<br>
<br>
P.S. See also<br>
<a href=3D"https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-=
206bafa5fda0" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@nico=
lasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0</a><br>
<a href=3D"https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-s=
elf-sovereignty-18fac5bcdc25" rel=3D"noreferrer" target=3D"_blank">https://=
medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18f=
ac5bcdc25</a><br>
</blockquote></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
--0000000000007381ac05a5070403--
|