Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

From: Keagan McClelland <keagan.mcclelland@gmail•com>
To: Orfeas Stefanos Thyfronitis Litos <o.thyfronitis@ed•ac.uk>
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
Date: Thu, 14 May 2020 09:25:57 -0600	[thread overview]
Message-ID: <CALeFGL1ZNrXBB31SScgP3BvKsiTDF-DSDj6Wf-QbPJc6E8t3iQ@mail.gmail.com> (raw)
In-Reply-To: <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>

[-- Attachment #1: Type: text/plain, Size: 4524 bytes --]

> 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
>

[-- Attachment #2: Type: text/html, Size: 5472 bytes --]