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"
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
Precedence: list

--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>&gt; 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&#39;t improve much on that step. Especially if I=
=20
already run a full node.</div><div><br></div><div>For what it&#39;s worth, =
this is a main research area for us at Start9 Labs. <br></div><div><br></di=
v><div>&gt; Could someone briefly describe how this UX looks currently? And=
 if it&#39;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 &quot;priva=
te server&quot; is considered inconvenient. There is no fundamental reason =
this has to be the case. The main UX challenges we&#39;ve found are around =
installation and configuration of server applications, not to mention, that=
 users don&#39;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 &quot;apps&quot;. The=
 fact that there is a component of their applications that runs remotely on=
 computers they don&#39;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 &quot;zero configuration&quot; 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&#39;m sure there=
 are more things we&#39;ll learn as we grow but these are the top three obs=
ervations we&#39;ve made and this is our primary area of work.<br></div><di=
v><br></div><div>&gt; 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&#39;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&#39;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&#39;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&#39;ve used Core&#39;s RPC API for =
this but as others have mentioned upthread JSON is a wasteful format and th=
ere are good reasons that you&#39;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&#39;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 &lt;<a href=3D"mailto:o.thyfronitis@ed.ac.uk">=
o.thyfronitis@ed.ac.uk</a>&gt; 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>
&gt;If everyone runs such a privately-owned server, on the other hand, this=
<br>
&gt;is not so different from having a Lightning node you run at your home<b=
r>
&gt;that has a fullnode as well and which you access via a remote control<b=
r>
&gt;mobile device, and it is the inconvenience of having such a server at<b=
r>
&gt;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&#39;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&#39;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--