summaryrefslogtreecommitdiff
path: root/cf/7b687781b6eca295c95a09460080ec03b3da54
blob: ce239dd58268d6246d48a153361ea7c94864cd76 (plain)
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
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
Return-Path: <antoine.riard@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3EA44C07FF;
 Sat,  9 May 2020 07:23:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 3A66688CC9;
 Sat,  9 May 2020 07:23:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0h2Mx3SXvxEo; Sat,  9 May 2020 07:23:04 +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-pf1-f172.google.com (mail-pf1-f172.google.com
 [209.85.210.172])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 4F65988CB4;
 Sat,  9 May 2020 07:23:04 +0000 (UTC)
Received: by mail-pf1-f172.google.com with SMTP id z1so2181472pfn.3;
 Sat, 09 May 2020 00:23:04 -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=3BrB+llrWT6UlzVRlF4ANF66KEiGtm78vy7jlMU5eJM=;
 b=i5t066z2XS6KKWUKKWopgU+R+R4koMsu1nbYXx8ldhHopOAHgubuaYKk0kUjleNzfd
 uZVVz9l/kY/AHEBTNLQSJ3OyRTh2Qw6Tmfc9sfrn6yIdszL/Nr7jxUVTJ8AN/jyeLmGt
 /2n+rmyddF2dh3KBc26D7P2T2h6hMUbtpvcpW3wyGBBiHDAt3bhnNQt1qFU2S1QCVrpA
 yB08+m+eSxV2EyOGAQ1lHbYTCCYu+awOjbzW0gbTNgIJqHR6fNYp9O7fVL9B5K3hUHRV
 le0ZKGoYQ6jfAo1GvESEI3sDIYa+iP/Sf3rnw9t0VkKAoVuLBMePsS2mHkwZD7/np8VK
 zdBw==
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=3BrB+llrWT6UlzVRlF4ANF66KEiGtm78vy7jlMU5eJM=;
 b=FNhSfIRWkkKhysc23mQ7LrKYzBI2PfWvEOc6EXxqP/Cv1iKDnQQIuXhcRffeBDaNPW
 0gzCdhhmegGcxqIL3KzojzMpDBR7qcM1WdHSabvd9mg6zNrYhnXzumqCQiOylj/0Xxus
 AWti0C5vFwqLvDuiA31VN5kL27oL6YzB6cpoZE3QJ2FpkBNJ+XU9jdBhknIch8OIGlyi
 VlIsdYFhL6S/6sM+pQpOtJLIN0Y9Jajhop4E9QKsPXylEAJIL9oNQD+uaGM613LnJE4N
 lInbX8XfphdNEoISqMdMJch2IENUTsTU74szpjC2xQB8RW29vdGUJcCaIDu5S9gpmOrr
 reNQ==
X-Gm-Message-State: AGi0PuYm9TfSjSuH5C8R1gTe/ZF3Uz7ub4qWYbdnUYbBTgoo8MszFZGU
 TBEMWo766u/ErOrM+QC7/h7iO6N8JcAtGmfFF0F2kBSn
X-Google-Smtp-Source: APiQypKyNkFMvO5ASkLyasaeN4GmcB8niQXA8wBX5pz7Yqc62lvBHbdteB7gZqz4swqO7aKNJ4AzPsnYs+wth9vGay8=
X-Received: by 2002:a63:5a5d:: with SMTP id k29mr5366652pgm.176.1589008983781; 
 Sat, 09 May 2020 00:23:03 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <CAJx8jdwHF3wF+q+JafuDhMtca45Wb2vS_gvB0yw71jNGz=ZHzA@mail.gmail.com>
In-Reply-To: <CAJx8jdwHF3wF+q+JafuDhMtca45Wb2vS_gvB0yw71jNGz=ZHzA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 9 May 2020 03:22:52 -0400
Message-ID: <CALZpt+FH10XgPsGZn_kgzrzObjvpnB-j3sh8C=ytBXatPzacYg@mail.gmail.com>
To: Igor Cota <igor@codexapertus.com>
Content-Type: multipart/alternative; boundary="00000000000005fb0b05a531fc74"
X-Mailman-Approved-At: Sat, 09 May 2020 07:24:34 +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: Sat, 09 May 2020 07:23:06 -0000

--00000000000005fb0b05a531fc74
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Igor,

Thanks for sharing about what it's technically possible to do for a
full-node on phone, specially with regards to lower grade devices.

I do see 2 limitations for sleeping nodes:
- a lightning specific one, i.e you need to process block data real-time in
case of incoming HTLC you need to claim on chain or a HTLC timeout. There
is a bunch of timelocks implications in LN,  with regards to CSV,
CLTV_DELTA, incoming policy, outgoing policy, ... and you can't really
afford to be late without loosing a payment. I don't see timelocks being
increase, that would hinder liquidity.
- a p2p bandwidth concern, even if this new class of nodes turn as public
ones, they would still have a heavy sync period due to be fallen-behind
during the day, so you would have huge bandwidth spikes every a timezone
falls asleep and a risk of choking upload links of stable full-nodes.

I think assume-utxo may be interesting in the future in case of long-fork
detection, you may be able to download a utxo-set on the fly, and fall-back
to a full-node. But that would be only an emergency measure, not a regular
cost on the backbone network.

Antoine


Le jeu. 7 mai 2020 =C3=A0 12:41, Igor Cota <igor@codexapertus.com> a =C3=A9=
crit :

> Hi Antoine et al,
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servici=
ng
>> friendly millions of LN mobiles clients. But just in case it may be good=
 to
>> consider a reasonable alternative.
>>
>
>
>> So you may want to separate control/data plane, get filters from CDN and
>> headers as check-and-control directly from the backbone network. "Hybrid=
"
>> models should clearly be explored.
>
>
> For some months now I've been exploring the feasibility of running full
> nodes on everyday phones [1]. One of my first thoughts was how to avoid t=
he
> phones mooching off the network. Obviously due to battery, storage and
> bandwidth constraints it is not reasonable to expect pocket full nodes to
> serve blocks during day time.
>
> Huge exception to this is the time we are asleep and our phones are
> connected to wifi and charging. IMO this is a huge untapped resource that
> would allow mobile nodes to earn their keep. If we limit full node
> operation to sleepy night time the only constraining resource is storage:
> 512 gb of internal storage in phones is quite rare, probably about $100 f=
or
> an SD card with full archival node capacity but phones with memory card
> slots rarer still - no one is going to bother.
>
> So depending on their storage capacity phone nodes could decide to store
> and serve just a randomly selected range of blocks during their nighttime
> operation. With trivial changes to P2P they could advertise the blocks th=
ey
> are able to serve.
> If there comes a time that normal full nodes feel DoS'ed they can
> challenge such nodes to produce the blocks they advertise and ban them as
> moochers if they fail to do so. Others may elect to be more charitable an=
d
> serve everyone.
>
> These types of nodes would truly be part-timing since they only carry a
> subset of the blockchain and work while their operator is asleep. Probabl=
y
> should be called part-time or Sleeper Nodes=E2=84=A2.
>
> They could be user friendly as well, with Assume UTXO they could be
> bootstrapped quickly and while they do the IBD in the background instead =
of
> traditional pruning they can keep the randomly assigned bit of blockchain
> to later serve the network.
>
> Save for the elderly, all the people I know could run such a node, and I
> don't live in a first world country.
>
> There is also the feel-good kumbaya aspect of American phone nodes servin=
g
> the African continent while the Americans are asleep, Africans and
> Europeans serving the Asians in kind. By plugging in our phones and going
> to sleep we could blanket the whole world in (somewhat) full nodes!
>
> Cheers,
> Igor
>
> [1] https://icota.github.io/
>
> On Tue, 5 May 2020 at 12:18, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use t=
his
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> Trust-minimization of Bitcoin security model has always relied first and
>> above on running a full-node. This current paradigm may be shifted by LN
>> where fast, affordable, confidential, censorship-resistant payment servi=
ces
>> may attract a lot of adoption without users running a full-node. Assumin=
g 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. It doesn't mean we shouldn't foster nod=
e
>> adoption when people are able to do so, and having a LN wallet maybe eve=
n a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped a=
s
>> how to build a scalable, secure, private chain access backend for millio=
ns
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used)=
,
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted =
fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ =
for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/header=
s,
>> that means you're asking 1PB/month of traffic to the backbone network. I=
f
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in t=
o
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running=
 an
>> actual public node. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to incre=
ase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium betwe=
en
>> numbers of clients and numbers of full-node, even worst their growth rat=
e
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers o=
f
>> BIP157 clients is still pretty low, but what is worrying is  wallet vend=
ors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses..=
.
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wid=
er
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied =
to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligne=
d,
>> like spying on your transaction broadcast or block fetched. And you do w=
ant
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?
>>
>> Moreover, the LN security model diverges hugely from basic on-chain
>> transactions. Worst-case attack on-chain a malicious light client server
>> showing a longest, invalid, PoW-signed chain to double-spend the user. O=
n
>> LN, the *liveliness* requirement means the entity owning your view of th=
e
>> chain can lie to you on whether your channel has been spent by a revoked
>> commitment, the real tip of the blockchain or even dry-up block
>> announcement to trigger unexpected behavior in the client logic. A
>> malicious light client server may just drop any filters/utxos spends, wh=
at
>> your LN client should do in this case ? [1]
>>
>> Therefore, you may want to introduce monetary compensation in exchange o=
f
>> servicing filters. Light client not dedicating resources to maintain the
>> network but free-riding on it, you may use their micro-payment capabilit=
ies
>> to price chain access resources [3]. This proposition may suit within th=
e
>> watchtower paradigm, where another entity is delegated some part of
>> protocol execution, alleviating client onliness requirement. It needs
>> further analysis but how your funds may be compromised by a watchtower a=
re
>> likely to be the same scenario that how a chain validation provider can
>> compromise you. That said, how do you avoid such "chain access" market
>> turning as an oligopoly is an open question. You may "bind" them to
>> internet topology or ask for fidelity bonds and create some kind of
>> scarcity but still...
>>
>> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servici=
ng
>> friendly millions of LN mobiles clients. But just in case it may be good=
 to
>> consider a reasonable alternative.
>>
>> Thanks Gleb for many points exposed here but all mistakes are my own.
>>
>> Cheers,
>>
>> Antoine
>>
>> [0] UTXO set size may be a bottleneck, but still if you have 2 channels
>> by clients that's 20M utxos, just roughly ~x3 than today.
>>
>> [1] And committing filters as part of headers may not solve everything a=
s
>> an attacker can just delay or slow announcements to you, so you still ne=
ed
>> network access to at least one honest node.
>>
>> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
>> you may start as a client and start synchronizing the chain, relaying
>> blocks, etc. AFAIK, there is no such hybrid implementation and that's no=
t
>> what you want to run in a mobile.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> *Igor Cota*
> Codex Apertus Ltd
>

--00000000000005fb0b05a531fc74
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>Hi Igor,<br><br></div>Thanks=
 for sharing about what it&#39;s technically possible to do for a full-node=
 on phone, specially with regards to lower grade devices.<br><br></div>I do=
 see 2 limitations for sleeping nodes:<br></div>- a lightning specific one,=
 i.e you need to process block data real-time in case of incoming HTLC you =
need to claim on chain or a HTLC timeout. There is a bunch of timelocks imp=
lications in LN,=C2=A0 with regards to CSV, CLTV_DELTA, incoming policy, ou=
tgoing policy, ... and you can&#39;t really afford to be late without loosi=
ng a payment. I don&#39;t see timelocks being increase, that would hinder l=
iquidity.<br></div>- a p2p bandwidth concern, even if this new class of nod=
es turn as public ones, they would still have a heavy sync period due to be=
 fallen-behind during the day, so you would have huge bandwidth spikes ever=
y a timezone falls asleep and a risk of choking upload links of stable full=
-nodes.<br><br></div>I think assume-utxo may be interesting in the future i=
n case of long-fork detection, you may be able to download a utxo-set on th=
e fly, and fall-back to a full-node. But that would be only an emergency me=
asure, not a regular cost on the backbone network.<br><br></div>Antoine<br>=
<div><div><div><div><div><br></div></div></div></div></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 7 m=
ai 2020 =C3=A0=C2=A012:41, Igor Cota &lt;<a href=3D"mailto:igor@codexapertu=
s.com">igor@codexapertus.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Antoine e=
t al,</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Maybe I&#39;m completely wrong, missing some numbers, and it&#39;s maybe f=
ine to just rely on few thousands of full-node operators being nice and ser=
vicing friendly millions of LN mobiles clients. But just in case it may be =
good to consider a reasonable alternative.<br></blockquote><div>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">So you may want to s=
eparate control/data plane, get filters from CDN and headers as check-and-c=
ontrol directly from the backbone network. &quot;Hybrid&quot; models should=
 clearly be explored.</blockquote><div></div><div><u><br></u></div><div><u>=
</u></div><div>For some months now I&#39;ve been exploring the feasibility =
of running full nodes on everyday phones [1]. One of my first thoughts was =
how to avoid the phones mooching off the network. Obviously due to battery,=
 storage and bandwidth constraints it is not reasonable to expect pocket fu=
ll nodes to serve blocks during day time.</div><div><br></div><div></div><d=
iv>Huge exception to this is the time we are asleep and our phones are conn=
ected to wifi and charging. IMO this is a huge untapped resource that would=
 allow mobile nodes to earn their keep. If we limit full node operation to =
sleepy night time the only constraining resource is storage: 512 gb of inte=
rnal storage in phones is quite rare, probably about $100 for an SD card wi=
th full archival node capacity but phones with memory card slots rarer stil=
l - no one is going to bother.</div><div><br></div><div></div><div>So depen=
ding on their storage capacity phone nodes could decide to store and serve =
just a randomly selected range of blocks during their nighttime operation. =
With trivial changes to P2P they could advertise the blocks they are able t=
o serve. </div><div></div><div>If there comes a time that normal full nodes=
 feel DoS&#39;ed they can challenge such nodes to produce the blocks they a=
dvertise and ban them as moochers if they fail to do so. Others may elect t=
o be more charitable and serve everyone.</div><div><br></div><div></div><di=
v>These types of nodes would truly be part-timing since they only carry a s=
ubset of the blockchain and work while their operator is asleep. Probably s=
hould be called part-time or Sleeper Nodes<span style=3D"color:rgb(32,33,34=
)">=E2=84=A2.</span></div><div><span style=3D"color:rgb(32,33,34)"><br></sp=
an></div><div><span style=3D"color:rgb(32,33,34)"></span></div><div><span s=
tyle=3D"color:rgb(32,33,34)">They could be user friendly as well, with Assu=
me UTXO they could be bootstrapped quickly and while they do the IBD in the=
 background instead of traditional pruning they can keep the randomly assig=
ned bit of blockchain to later serve the network.</span></div><div><span st=
yle=3D"color:rgb(32,33,34)"><br></span></div><div><span style=3D"color:rgb(=
32,33,34)"></span></div><div><span style=3D"color:rgb(32,33,34)">Save for t=
he elderly, all the people I know could run such a node, and I don&#39;t li=
ve in a first world country.</span></div><div><span style=3D"color:rgb(32,3=
3,34)"><br></span></div><div><span style=3D"color:rgb(32,33,34)"></span></d=
iv><div><span style=3D"color:rgb(32,33,34)">There is also the feel-good kum=
baya aspect of American phone nodes serving the African continent while the=
 Americans are asleep, Africans and Europeans serving the Asians in kind. B=
y plugging in our phones and going to sleep we could blanket the whole worl=
d in (somewhat) full nodes!</span></div><div><span style=3D"color:rgb(32,33=
,34)"><br></span></div><div><span style=3D"color:rgb(32,33,34)"></span></di=
v><div><span style=3D"color:rgb(32,33,34)">Cheers,</span></div><div><span s=
tyle=3D"color:rgb(32,33,34)">Igor</span></div><div><span style=3D"color:rgb=
(32,33,34)"><br></span></div><div><span style=3D"color:rgb(32,33,34)"></spa=
n></div><div><span style=3D"color:rgb(32,33,34)">[1] </span><a href=3D"http=
s://icota.github.io/" rev=3D"en_rl_none" target=3D"_blank">https://icota.gi=
thub.io/</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, 5 May 2020 at 12:18, Antoine Riard &lt;<a href=3D=
"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Hi,</div><div><br></div><div>(cross-posting as it&#39;=
s really both layers concerned)<br></div><div><div><br>Ongoing advancement =
of BIP 157 implementation in Core maybe the opportunity to reflect on the f=
uture of light client protocols and use this knowledge to make better-infor=
med decisions about what kind of infrastructure is needed to support mobile=
 clients at large scale.<br><br></div><div>Trust-minimization of Bitcoin se=
curity model has always relied first and above on running a full-node. This=
 current paradigm may be shifted by LN where fast, affordable, confidential=
, censorship-resistant payment services may attract a lot of adoption witho=
ut users running a full-node. Assuming a user adoption path where a full-no=
de is required to benefit for LN may deprive a lot of users, especially tho=
se who are already denied a real financial infrastructure access. It doesn&=
#39;t mean we shouldn&#39;t foster node adoption when people are able to do=
 so, and having a LN wallet maybe even a first-step to it.<br><br></div><di=
v>Designing a mobile-first LN experience opens its own gap of challenges es=
pecially in terms of security and privacy. The problem can be scoped as how=
 to build a scalable, secure, private chain access backend for millions of =
LN clients ?<br><br></div><div>Light client protocols for LN exist (either =
BIP157 or Electrum are used), although their privacy and security guarantee=
s with regards to implementation on the client-side may still be an object =
of concern (aggressive tx-rebroadcast, sybillable outbound peer selection, =
trusted fee estimation). That said, one of the bottlenecks is likely the nu=
mber of full-nodes being willingly to dedicate resources to serve those cli=
ents. It&#39;s not about _which_ protocol is deployed but more about _incen=
tives_ for node operators to dedicate long-term resources to client they ha=
ve lower reasons to care about otherwise.<br><br></div><div>Even with cheap=
er, more efficient protocols like BIP 157, you may have a huge discrepancy =
between what is asked and what is offered. Assuming 10M light clients [0] e=
ach of them consuming ~100MB/month for filters/headers, that means you&#39;=
re asking 1PB/month of traffic to the backbone network. If you assume 10K p=
ublic nodes, like today, assuming _all_ of them opt-in to signal BIP 157, t=
hat&#39;s an increase of 100GB/month for each. Which is consequent with reg=
ards to the estimated cost of 350GB/month for running an actual public node=
. Widening full-node adoption, specially in term of geographic distribution=
 means as much as we can to bound its operational cost.<br><br></div><div>O=
bviously,=C2=A0 deployment of more efficient tx-relay protocol like Erlay w=
ill free up some resources but it maybe wiser to dedicate them to increase =
health and security of the backbone network like deploying more outbound co=
nnections.<br><br></div><div>Unless your light client protocol is so ridicu=
lous cheap to rely on niceness of a subset of node operators offering free =
resources, it won&#39;t scale. And it&#39;s likely you will always have a r=
atio disequilibrium between numbers of clients and numbers of full-node, ev=
en worst their growth rate won&#39;t be the same, first ones are so much ea=
sier to setup.<br><br></div><div>It doesn&#39;t mean servicing filters for =
free won&#39;t work for now, numbers of BIP157 clients is still pretty low,=
 but what is worrying is=C2=A0 wallet vendors building such chain access ba=
ckend, hitting a bandwidth scalability wall few years from now instead of p=
ursuing better solutions. And if this happen, maybe suddenly, isn&#39;t the=
 quick fix going to be to rely on centralized services, so much easier to d=
eploy ?<br><br></div><div>Of course, it may be brought that actually curren=
t full-node operators don&#39;t get anything back from servicing blocks, tr=
ansactions, addresses... It may be replied that you have an indirect incent=
ive to participate in network relay and therefore guarantee censorship-resi=
stance, instead of directly connecting to miners. You do have today ways to=
 select your resources exposure like pruning, block-only or being private b=
ut the wider point is the current (non?)-incentives model seems to work for=
 the base layer. For light clients data, are node operators going to be sat=
isfied to serve this new *class* of traffic en masse ?<br><br>This doesn&#3=
9;t mean you won&#39;t find BIP157 servers, ready to serve you with unlimit=
ed credit, but it&#39;s more likely their intentions maybe not aligned, lik=
e spying on your transaction broadcast or block fetched. And you do want pe=
er diversity to avoid every BIP157 servers being on few ASNs for fault-tole=
rance. Do people expect a scenario a la Cloudflare, where everyone connecti=
ons is to far or less the same set of entities ?<br><br>Moreover, the LN se=
curity model diverges hugely from basic on-chain transactions. Worst-case a=
ttack on-chain a malicious light client server showing a longest, invalid, =
PoW-signed chain to double-spend the user. On LN, the *liveliness* requirem=
ent means the entity owning your view of the chain can lie to you on whethe=
r your channel has been spent by a revoked commitment, the real tip of the =
blockchain or even dry-up block announcement to trigger unexpected behavior=
 in the client logic. A malicious light client server may just drop any fil=
ters/utxos spends, what your LN client should do in this case ? [1]<br><br>=
Therefore, you may want to introduce monetary compensation in exchange of s=
ervicing filters. Light client not dedicating resources to maintain the net=
work but free-riding on it, you may use their micro-payment capabilities to=
 price chain access resources [3]. This proposition may suit within the wat=
chtower paradigm, where another entity is delegated some part of protocol e=
xecution, alleviating client onliness requirement. It needs further analysi=
s but how your funds may be compromised by a watchtower are likely to be th=
e same scenario that how a chain validation provider can compromise you. Th=
at said, how do you avoid such &quot;chain access&quot; market turning as a=
n oligopoly is an open question. You may &quot;bind&quot; them to internet =
topology or ask for fidelity bonds and create some kind of scarcity but sti=
ll...<br><br>Maybe I&#39;m completely wrong, missing some numbers, and it&#=
39;s maybe fine to just rely on few thousands of full-node operators being =
nice and servicing friendly millions of LN mobiles clients. But just in cas=
e it may be good to consider a reasonable alternative.<br><br>Thanks Gleb f=
or many points exposed here but all mistakes are my own.<br><br></div><div>=
Cheers,<br><br></div><div>Antoine<br><br>[0] UTXO set size may be a bottlen=
eck, but still if you have 2 channels by clients that&#39;s 20M utxos, just=
 roughly ~x3 than today.<br><br>[1] And committing filters as part of heade=
rs may not solve everything as an attacker can just delay or slow announcem=
ents to you, so you still need network access to at least one honest node.<=
br><br>[2]=C2=A0 It maybe argue that distinction client-vs-peer doesn&#39;t=
 hold because you may start as a client and start synchronizing the chain, =
relaying blocks, etc. AFAIK, there is no such hybrid implementation and tha=
t&#39;s not what you want to run in a mobile.<br><br></div></div></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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div><div dir=3D"ltr"><b>Igor Cota</b><div>Codex Apertus =
Ltd<br></div></div></div></div></div>
</blockquote></div>

--00000000000005fb0b05a531fc74--