path: root/8e/37f452cd6918770d7f476775f5312fa5e0360b

Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D30B6C016F;
 Sun, 17 May 2020 03:38:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id B76A0203AF;
 Sun, 17 May 2020 03:38:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nkMJO4OUaNnN; Sun, 17 May 2020 03:37:59 +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-f180.google.com (mail-pf1-f180.google.com
 [209.85.210.180])
 by silver.osuosl.org (Postfix) with ESMTPS id B88082039D;
 Sun, 17 May 2020 03:37:59 +0000 (UTC)
Received: by mail-pf1-f180.google.com with SMTP id x2so3083318pfx.7;
 Sat, 16 May 2020 20:37:59 -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=0KNYFrkLG+IpvD1snzGl73x8nd2mA6KSO3qkLjbwSFk=;
 b=ZvpB+9te37/SMFw3VGB6oFzAFcX66f/C+ZrOAEvRhTi+dCx0YzQWaVTsLjDHgWa64X
 1Vty+5P3gvPLPZJZuzrBiod05KGKjYbDOYUWDNyuBrT9vVTTxu9g5ROEct/zb5IWkRIz
 4sZ+xRRbjMSucJPBVTWh+bu0On4li/qxZDSODEjNLt3BgqIjqs1P4PRxpTGLDDhFJQp3
 K+YCv7O7FXRRLMjQub+/qxT0EghgyK5Sitt2nJvY4OogDe2wF8ewk3/66WUrRmrn+6H9
 raKAwszbaFd9a+4O3rTzoNW+//Fhfy3DREcaYnFVS9PlOC22DO5pwWb0Tuby5jVxNyYA
 txIg==
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=0KNYFrkLG+IpvD1snzGl73x8nd2mA6KSO3qkLjbwSFk=;
 b=bTXvrtAuUkCosMDjJtY7b1nQ7NemE//NKA1Sk48LPnZ13NsUZmC3HhAoIGhTJFtAHY
 AGLZ+r07MoqkeeMi67RDOBFJF67dR+NKt+PHQ81BozAVHEJqE2qicDWPoncGFkbj/nHr
 OzmUazBvp5ch+tMWTl/i/Yc3dBsB5aDwVbS/HRJyZN6k4AJjcnMzJ31leDVQJK0I4+64
 8NToRM6SKQQPK+IJpQW/Vo8JjbeBgkcB/LC+K23JR+2VgubSxGqZqD6onICgksgf/I+K
 5e5+LqI/SIc22JeFK5qnSir1dASpoCaXeU5ZduUgpg7WPF8kUSDl7cX+xFkupyv2deW1
 SwhQ==
X-Gm-Message-State: AOAM531T1pIypaCF48lpC5Q319xoSNx+/Q+Ocd55tay6UrSe2tsHWw1x
 xXMXX15h2XJBEO7+FJKcKfNlQ0tMJ/eXRqgwAC0=
X-Google-Smtp-Source: ABdhPJzkLXjUWck0UqnpfjBFLV50fcPtsB21SIVuPwnBeaf+bDDOEMseIdeVkCJKVy/iOkYACALp4TbRpkJwm4fYrhA=
X-Received: by 2002:a62:29c3:: with SMTP id
 p186mr10877648pfp.237.1589686679245; 
 Sat, 16 May 2020 20:37:59 -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>
In-Reply-To: <uOUyhfZ-Ti4E4sQn_Cap6Em_pqVc-p2INXoBLIEKsiOWpWKT-WNeqUge902E-HU0wWWWo4onr8UQTNKg5YmVkUWfrlNVJkkMSWYCnoj2WVY=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 16 May 2020 23:37:46 -0400
Message-ID: <CALZpt+EOWiw0p12u6J7TyN8+-u5yjDzcFFbkoRaj3cTWNwtOHg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000d2161805a5cfc5e5"
X-Mailman-Approved-At: Sun, 17 May 2020 08:12:59 +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: Sun, 17 May 2020 03:38:02 -0000

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

> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.

Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step before
running a full-node and getting a more full-fledged key management solution=
.

> It may even be possible, that the Lightning future with massive SPV might
end up with more economic weight in SPV nodes, than in the world without
Lightning and dependent on centralized custodial services to scale.

Even evaluating economic weight in Lightning is hard, both parties have
their own chain view, and it's likely if you assume a hub-and-spoke
topology, leaf nodes are going to be SPV and internal nodes full-nodes ?

> Money makes the world go round, so such backup servers that are
publicly-facing rather than privately-owned should be somehow incentivized
to do so, or else they would not exist in the first place.

I was thinking about the current workflow, Alice downloads her New Shiny
LN-wallet, she is asked to backup the seed, she is asked to pick-up
backup(s) nodes among her friends, relatives or business partners and is
NOT provided any automatic hint and register backup nodes addresses, maybe
even do out-of-band key exchange with this full-node operator. Therefore
you may avoid centralization by having not such publicly-facing servers. Of
course, Alice can still scrawl the web to and be lured to pickup malicious
public servers but if she is severely notified to not do so that may be
enough.

So it would be a combination of UX+user education+fallback security
mechanism to avoid economy hijack. That maybe a better solution rather than
PoW-only SPV. We have an open network so you can't prevent someone to run
such type of client but at least if they have to do so you can provide them
with a better option ?

Antoine




Le jeu. 14 mai 2020 =C3=A0 00:02, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :

> Good morning Antoine,
>
>
> > While approaching this question, I think you should consider economic
> weight of nodes in evaluating miner consensus-hijack success. Even if you
> expect a disproportionate ratio of full-nodes-vs-SPV, they may not have t=
he
> same  economic weight at all, therefore even if miners are able to lure a
> majority of SPV clients they may not be able to stir economic nodes. SPV
> clients users will now have an incentive to cancel their hijacked history
> to stay on the most economic meaningful chain. And it's already assumed,
> that if you run a bitcoin business or LN routing node, you do want to run
> your own full-node.
>
> One hope I have for Lightning is that it will replace centralized
> custodial services, because:
>
> * Lightning gains some of the scalability advantage of centralized
> custodial services, because you can now transfer to any Lightning client
> without touching the blockchain, for much reduced transfer fees.
> * At the same time, it retains your-keys-your-coins noncustodiality,
> because every update of a Lightning channel requires your keys to sign of=
f
> on it.
>
> If most Lightning clients are SPV, then if we compare these two worlds:
>
> * There are a few highly-important centralized custodial services with
> significant economic weight running fullnodes (i.e. now).
> * There are no highly-important centralized custodial services, and most
> everyone uses Lightning, but with SPV (i.e. a Lightning future).
>
> Then the distribution of economic weight would be different between these
> two worlds.
> It may even be possible, that the Lightning future with massive SPV might
> end up with more economic weight in SPV nodes, than in the world without
> Lightning and dependent on centralized custodial services to scale.
>
>
> It is also entirely possible that custodial services for Lightning will
> arise anyway and my hope is already dashed, come on universe, work harder
> will you, would you really disappoint some randomly-generated Internet
> person like that.
>
>
> >
> > I agree it may be hard to evaluate economic-weight-to-chain-backend
> segments, specially with offchain you disentangle an onchain output value
> from its real payment traffic. To strengthen SPV, you may implement forks
> detection and fallback to some backup node(s) which would serve as an
> authoritative source to arbiter between branches. Such backup node(s) mus=
t
> be picked up manually at client initialization, before any risk of confli=
ct
> to avoid Reddit-style of hijack during contentious period or other massiv=
e
> social engineering. You don't want autopilot-style of recommendations for
> picking up a backup nodes and avoid cenralization of backups, but somehow=
 a
> uniform distribution. A backup node may be a private one, it won't serve
> you any data beyond headers, and therefore you preserve public nodes
> bandwidth, which IMO is the real bottleneck. I concede it won't work well
> if you have a ratio of 1000-SPV for 1-full-node and people are not
> effectively able to pickup a backup among their social environment.
> > What do you think about this model ?
>
> Money makes the world go round, so such backup servers that are
> publicly-facing rather than privately-owned should be somehow incentivize=
d
> to do so, or else they would not exist in the first place.
> Of course, a free market tends towards monopoly, because any entity that
> happens to have even a slight advantage at the business will have more
> money to use towards business reinvestment and increase its advantage
> further, until they beat the competition to dust, anyone who has won a 4X
> game knows to search for and stack those little advantages until you
> snowball and conquer the world/galaxy/petri dish which is why the endgame
> of 4X games is so boring compared to the start, we have seen this happen =
in
> mining and exchanges and so on, and this works against your desire to hav=
e
> a uniform distribution.
>
> If everyone runs such a privately-owned server, on the other hand, this i=
s
> not so different from having a Lightning node you run at your home that h=
as
> a fullnode as well and which you access via a remote control mobile devic=
e,
> and it is the inconvenience of having such a server at your home that
> prevents this in the first place.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div><div><div><div>&gt; * At the same time, it retains yo=
ur-keys-your-coins noncustodiality,=20
because every update of a Lightning channel requires your keys to sign=20
off on it.<br><br></div><div>Yes I agree, I can foresee an easier step wher=
e managing low-value channel and get your familiar with smooth key manageme=
nt maybe a first step before running a full-node and getting a more full-fl=
edged key management solution.<br></div><div><br>&gt; It may even be possib=
le, that the Lightning future with massive SPV=20
might end up with more economic weight in SPV nodes, than in the world=20
without Lightning and dependent on centralized custodial services to=20
scale.<br><br></div>Even evaluating economic weight in Lightning is hard, b=
oth parties have their own chain view, and it&#39;s likely if you assume a =
hub-and-spoke topology, leaf nodes are going to be SPV and internal nodes f=
ull-nodes ?<br><br>&gt; Money makes the world go round, so such backup serv=
ers that are=20
publicly-facing rather than privately-owned should be somehow=20
incentivized to do so, or else they would not exist in the first place.<br>=
<br></div>I was thinking about the current workflow, Alice downloads her Ne=
w Shiny LN-wallet, she is asked to backup the seed, she is asked to pick-up=
 backup(s) nodes among her friends, relatives or business partners and is N=
OT provided any automatic hint and register backup nodes addresses, maybe e=
ven do out-of-band key exchange with this full-node operator. Therefore you=
 may avoid centralization by having not such publicly-facing servers. Of co=
urse, Alice can still scrawl the web to and be lured to pickup malicious pu=
blic servers but if she is severely notified to not do so that may be enoug=
h.<br><br></div>So it would be a combination of UX+user education+fallback =
security mechanism to avoid economy hijack. That maybe a better solution ra=
ther than PoW-only SPV. We have an open network so you can&#39;t prevent so=
meone to run such type of client but at least if they have to do so you can=
 provide them with a better option ?<br><br></div>Antoine<br><div><div><div=
><br><br><div><div><div><br>
</div></div></div></div></div></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 14 mai 2020 =C3=A0=C2=A000=
:02, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@proto=
nmail.com</a>&gt; a =C3=A9crit=C2=A0:<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">Good morning Antoine,<br>
<br>
<br>
&gt; While approaching this question, I think you should consider economic =
weight of nodes in evaluating miner consensus-hijack success. Even if you e=
xpect a disproportionate ratio of full-nodes-vs-SPV, they may not have the =
same =C2=A0economic weight at all, therefore even if miners are able to lur=
e a majority of SPV clients they may not be able to stir economic nodes. SP=
V clients users will now have an incentive to cancel their hijacked history=
 to stay on the most economic meaningful chain. And it&#39;s already assume=
d, that if you run a bitcoin business or LN routing node, you do want to ru=
n your own full-node.<br>
<br>
One hope I have for Lightning is that it will replace centralized custodial=
 services, because:<br>
<br>
* Lightning gains some of the scalability advantage of centralized custodia=
l services, because you can now transfer to any Lightning client without to=
uching the blockchain, for much reduced transfer fees.<br>
* At the same time, it retains your-keys-your-coins noncustodiality, becaus=
e every update of a Lightning channel requires your keys to sign off on it.=
<br>
<br>
If most Lightning clients are SPV, then if we compare these two worlds:<br>
<br>
* There are a few highly-important centralized custodial services with sign=
ificant economic weight running fullnodes (i.e. now).<br>
* There are no highly-important centralized custodial services, and most ev=
eryone uses Lightning, but with SPV (i.e. a Lightning future).<br>
<br>
Then the distribution of economic weight would be different between these t=
wo worlds.<br>
It may even be possible, that the Lightning future with massive SPV might e=
nd up with more economic weight in SPV nodes, than in the world without Lig=
htning and dependent on centralized custodial services to scale.<br>
<br>
<br>
It is also entirely possible that custodial services for Lightning will ari=
se anyway and my hope is already dashed, come on universe, work harder will=
 you, would you really disappoint some randomly-generated Internet person l=
ike that.<br>
<br>
<br>
&gt;<br>
&gt; I agree it may be hard to evaluate economic-weight-to-chain-backend se=
gments, specially with offchain you disentangle an onchain output value fro=
m its real payment traffic. To strengthen SPV, you may implement forks dete=
ction and fallback to some backup node(s) which would serve as an authorita=
tive source to arbiter between branches. Such backup node(s) must be picked=
 up manually at client initialization, before any risk of conflict to avoid=
 Reddit-style of hijack during contentious period or other massive social e=
ngineering. You don&#39;t want autopilot-style of recommendations for picki=
ng up a backup nodes and avoid cenralization of backups, but somehow a unif=
orm distribution. A backup node may be a private one, it won&#39;t serve yo=
u any data beyond headers, and therefore you preserve public nodes bandwidt=
h, which IMO is the real bottleneck. I concede it won&#39;t work well if yo=
u have a ratio of 1000-SPV for 1-full-node and people are not effectively a=
ble to pickup a backup among their social environment.<br>
&gt; What do you think about this model ?<br>
<br>
Money makes the world go round, so such backup servers that are publicly-fa=
cing rather than privately-owned should be somehow incentivized to do so, o=
r else they would not exist in the first place.<br>
Of course, a free market tends towards monopoly, because any entity that ha=
ppens to have even a slight advantage at the business will have more money =
to use towards business reinvestment and increase its advantage further, un=
til they beat the competition to dust, anyone who has won a 4X game knows t=
o search for and stack those little advantages until you snowball and conqu=
er the world/galaxy/petri dish which is why the endgame of 4X games is so b=
oring compared to the start, we have seen this happen in mining and exchang=
es and so on, and this works against your desire to have a uniform distribu=
tion.<br>
<br>
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 pre=
vents this in the first place.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000d2161805a5cfc5e5--