Return-Path: 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: <202005051300.38836.luke@dashjr.org> <6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net> <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk> In-Reply-To: <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk> From: Keagan McClelland Date: Thu, 14 May 2020 09:25:57 -0600 Message-ID: To: Orfeas Stefanos Thyfronitis Litos Content-Type: multipart/alternative; boundary="000000000000dea55c05a59d50fb" X-Mailman-Approved-At: Thu, 14 May 2020 15:30:18 +0000 Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> 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.

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

So in short:
<= 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.
= 2. Apps that either require "zero configuration" or have very eas= y in-app walkthroughs of the bare essentials of configuration
3. = GUI style installs of server applications familiar to those who have instal= led desktop or mobile software.

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.

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

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

Keagan

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 14, 2020 at 12:50 AM Orfea= s 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 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.

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/ma= ilman/listinfo/lightning-dev
--000000000000dea55c05a59d50fb--