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
|
Return-Path: <keagan.mcclelland@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6069FC016F;
Thu, 14 May 2020 15:26:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 5B61E889F4;
Thu, 14 May 2020 15:26:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id sOed6v6orQ87; Thu, 14 May 2020 15:26:10 +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-f65.google.com (mail-ed1-f65.google.com
[209.85.208.65])
by whitealder.osuosl.org (Postfix) with ESMTPS id 8C2B188A06;
Thu, 14 May 2020 15:26:10 +0000 (UTC)
Received: by mail-ed1-f65.google.com with SMTP id g9so2690121edw.10;
Thu, 14 May 2020 08:26:10 -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=99y6DOJPPfTS6OYqlEsDCX5Q4gvnR0TIP5tpAhs7iLU=;
b=KQ+v+XOm+I1+Z8fRrl5D+AYoWYH5RCU/fwyr8jR4p0EYE+wUqvzvns/SDM5RVZblqo
+KawSv5sXE1+ULo07ZtzDM/+zih3KEouBPutibqZ2sMQdl24TssSjykTujCk8m69N2hc
w8uGwDBrYpTA1MxmEBVJ3Gy44fNe2L0kxPXiAnJ7bgrmH+UB3eYE7qaa8ZxYst+BMCls
hQft8OhV4aznydlT7E5LyiBbaiYZJLw75QaUQ0HbF2iCPF5MEob3oD8lU7dgbx4JfmqE
Bps79sTAp5pZ43iaiKD+6rNyseHLmKgDv56JjmRmn9SdvzYQf11NfRhyiTshWHTbc4P8
AbDg==
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=99y6DOJPPfTS6OYqlEsDCX5Q4gvnR0TIP5tpAhs7iLU=;
b=QhYII5+wmu8/cFSLPJx2uaB7KxJqPPPd7idtHmTXvEkZj7ArkBNAGc2G9tKWFZwNhC
9nNYw6QDbR9otXD1P1vHI5tH962SA3Hj4AGHaGFRMvSHMLK8sKGJWPuAnPm+cqj7KCaA
OxTDHocvxXfS3MBJmEVP1yuXKy9txtHURhm/eO8v18KEdNi7Thb1CJemsBNKKDe7Mvcr
I9+2m7JRMuQJuw1Y2gXHwuEqhwDn05BSYKZWHqS+PWpLDjMqhYj4Kjp4vkQDkJkV361D
Y2KYcDkNOVYnxHLatUYAEYcuTnsZ6IXGJFrAUhVYWfNVGS+q3LhsvGewg+/1hsjCd7Ev
UfpA==
X-Gm-Message-State: AOAM532BL8nb4aYwLI6cvABx34BVWzbpzBzuagXb2ixy1zy9q2ulhR1b
vQmZ0SL1Y1ZWvlRgGP7Yj1nSTO8WaKeGmnKzKjl7IIDgDAM=
X-Google-Smtp-Source: ABdhPJwBX2jCyH1lL2qAoW2XgYo+8nmE60fv/ppxtKOGw+FuOJo118ANJLjNbf1/tJVfoRelUxPMIyQnS9HmusN13jk=
X-Received: by 2002:a50:e70a:: with SMTP id a10mr4278295edn.38.1589469968769;
Thu, 14 May 2020 08:26:08 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
<202005051300.38836.luke@dashjr.org>
<CAH5Bsr27rN1SE166ON_q49=MNti0v7Vyn6s6T5R3=LC69K2QdQ@mail.gmail.com>
<6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net>
<CALZpt+G8SzeX4U-VBhEZqQ0ApwAs_jKkKe7aeZEQZ5KcJaMjCg@mail.gmail.com>
<uOUyhfZ-Ti4E4sQn_Cap6Em_pqVc-p2INXoBLIEKsiOWpWKT-WNeqUge902E-HU0wWWWo4onr8UQTNKg5YmVkUWfrlNVJkkMSWYCnoj2WVY=@protonmail.com>
<45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>
In-Reply-To: <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Thu, 14 May 2020 09:25:57 -0600
Message-ID: <CALeFGL1ZNrXBB31SScgP3BvKsiTDF-DSDj6Wf-QbPJc6E8t3iQ@mail.gmail.com>
To: Orfeas Stefanos Thyfronitis Litos <o.thyfronitis@ed.ac.uk>
Content-Type: multipart/alternative; boundary="000000000000dea55c05a59d50fb"
X-Mailman-Approved-At: Thu, 14 May 2020 15:30:18 +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, 14 May 2020 15:26:15 -0000
--000000000000dea55c05a59d50fb
Content-Type: text/plain; charset="UTF-8"
> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that centralised
services can't improve much on that step. Especially if I already run a
full node.
For what it's worth, this is a main research area for us at Start9 Labs.
> Could someone briefly describe how this UX looks currently? And if it's
not as seamless as it could, what blockers are there?
At the root of all of these problems is that a "private server" is
considered inconvenient. There is no fundamental reason this has to be the
case. The main UX challenges we've found are around installation and
configuration of server applications, not to mention, that users don't have
an existing mental model for how to imagine applications. Most people who
do not work on computers for a living have heard of servers but their
firsthand experience with software is "apps". The fact that there is a
component of their applications that runs remotely on computers they don't
own.
So in short:
1. Educating on the distinction between client and server apps is an open
question whose burden will likely fall on the entire industry if we want to
get this right and not have an exchange takeover of Bitcoin.
2. Apps that either require "zero configuration" or have very easy in-app
walkthroughs of the bare essentials of configuration
3. GUI style installs of server applications familiar to those who have
installed desktop or mobile software.
I'm sure there are more things we'll learn as we grow but these are the top
three observations we've made and this is our primary area of work.
> Private full nodes serving headers to a handful of weak devices have been
mentioned many times as a good solution against all sorts of problems in a
future full of LN + SPV nodes. I agree.
This is the main thesis I've been going on for a while. Once your full node
has synced the whole blockchain and the total set of headers is known, you
don't actually even need to carry 100% of the block data, as you can
re-fetch a needed block from elsewhere and verify the block data matches
the header you've already checked for consensus. From there the header
chain can serve as base truth for a whole set of L2+ services or L1 SPV
wallets. Ideally, in a model like this, more expensive peer services would
be authenticated so that your other applications could get the data they
need without exposing your full node to the extra costs of those who are
not running their own nodes. Typically we've used Core's RPC API for this
but as others have mentioned upthread JSON is a wasteful format and there
are good reasons that you'd want Lightning to be able to request peer
services without necessarily having ownership control over the node.
The other thing I wanted to note is the fact that the issue isn't that
Lightning does SPV, the issue is around whether or not the node it is
tethered to is *actually* trusted since SPV necessarily trusts some
dimensions of the information supplied to it. Doing SPV against a full node
you own is no more dangerous than indexing watch only addresses in Core and
then asking for wallet/utxo information over RPC.
Keagan
On Thu, May 14, 2020 at 12:50 AM Orfeas Stefanos Thyfronitis Litos <
o.thyfronitis@ed.ac.uk> wrote:
>
>
> >If everyone runs such a privately-owned server, on the other hand, this
> >is not so different from having a Lightning node you run at your home
> >that has a fullnode as well and which you access via a remote control
> >mobile device, and it is the inconvenience of having such a server at
> >your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have been
> mentioned many times as a good solution against all sorts of problems in a
> future full of LN + SPV nodes. I agree. It should be therefore a top
> priority to make the UX of connecting my mobile LN client to my home full
> node extremely easy, so that centralised services can't improve much on
> that step. Especially if I already run a full node.
>
> Could someone briefly describe how this UX looks currently? And if it's
> not as seamless as it could, what blockers are there?
>
> Best,
> Orfeas
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--000000000000dea55c05a59d50fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> It should be therefore a top priority to make th=
e UX of connecting my=20
mobile LN client to my home full node extremely easy, so that=20
centralised services can't improve much on that step. Especially if I=
=20
already run a full node.</div><div><br></div><div>For what it's worth, =
this is a main research area for us at Start9 Labs. <br></div><div><br></di=
v><div>> Could someone briefly describe how this UX looks currently? And=
if it's not as seamless as it could, what blockers are there?</div><di=
v><br></div><div>At the root of all of these problems is that a "priva=
te server" is considered inconvenient. There is no fundamental reason =
this has to be the case. The main UX challenges we've found are around =
installation and configuration of server applications, not to mention, that=
users don't have an existing mental model for how to imagine applicati=
ons. Most people who do not work on computers for a living have heard of se=
rvers but their firsthand experience with software is "apps". The=
fact that there is a component of their applications that runs remotely on=
computers they don't own.</div><div><br></div><div>So in short:</div><=
div>1. Educating on the distinction between client and server apps is an op=
en question whose burden will likely fall on the entire industry if we want=
to get this right and not have an exchange takeover of Bitcoin.</div><div>=
2. Apps that either require "zero configuration" or have very eas=
y in-app walkthroughs of the bare essentials of configuration</div><div>3. =
GUI style installs of server applications familiar to those who have instal=
led desktop or mobile software.</div><div><br></div><div>I'm sure there=
are more things we'll learn as we grow but these are the top three obs=
ervations we've made and this is our primary area of work.<br></div><di=
v><br></div><div>> Private full nodes serving headers to a handful of we=
ak devices have=20
been mentioned many times as a good solution against all sorts of=20
problems in a future full of LN + SPV nodes. I agree.</div><div><br></div><=
div>This is the main thesis I've been going on for a while. Once your f=
ull node has synced the whole blockchain and the total set of headers is kn=
own, you don't actually even need to carry 100% of the block data, as y=
ou can re-fetch a needed block from elsewhere and verify the block data mat=
ches the header you've already checked for consensus. From there the he=
ader chain can serve as base truth for a whole set of L2+ services or L1 SP=
V wallets. Ideally, in a model like this, more expensive peer services woul=
d be authenticated so that your other applications could get the data they =
need without exposing your full node to the extra costs of those who are no=
t running their own nodes. Typically we've used Core's RPC API for =
this but as others have mentioned upthread JSON is a wasteful format and th=
ere are good reasons that you'd want Lightning to be able to request pe=
er services without necessarily having ownership control over the node.<br>=
</div><div><br></div><div>The other thing I wanted to note is the fact that=
the issue isn't that Lightning does SPV, the issue is around whether o=
r not the node it is tethered to is <i>actually</i> trusted since SPV neces=
sarily trusts some dimensions of the information supplied to it. Doing SPV =
against a full node you own is no more dangerous than indexing watch only a=
ddresses in Core and then asking for wallet/utxo information over RPC.</div=
><div><br></div><div>Keagan<br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 14, 2020 at 12:50 AM Orfea=
s Stefanos Thyfronitis Litos <<a href=3D"mailto:o.thyfronitis@ed.ac.uk">=
o.thyfronitis@ed.ac.uk</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>
<br>
>If everyone runs such a privately-owned server, on the other hand, this=
<br>
>is not so different from having a Lightning node you run at your home<b=
r>
>that has a fullnode as well and which you access via a remote control<b=
r>
>mobile device, and it is the inconvenience of having such a server at<b=
r>
>your home that prevents this in the first place.<br>
<br>
Private full nodes serving headers to a handful of weak devices have been m=
entioned many times as a good solution against all sorts of problems in a f=
uture full of LN + SPV nodes. I agree. It should be therefore a top priorit=
y to make the UX of connecting my mobile LN client to my home full node ext=
remely easy, so that centralised services can't improve much on that st=
ep. Especially if I already run a full node.<br>
<br>
Could someone briefly describe how this UX looks currently? And if it's=
not as seamless as it could, what blockers are there?<br>
<br>
Best,<br>
Orfeas<br>
<br>
-- <br>
The University of Edinburgh is a charitable body, registered in<br>
Scotland, with registration number SC005336.<br>
<br>
_______________________________________________<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>
--000000000000dea55c05a59d50fb--
|
