path: root/5b/5b7dc1f8282f147a7e79e4b3bed838cf80c8f0

Return-Path: <antoine.riard@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9D58FC07FF;
 Thu,  7 May 2020 03:56:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 869F587C70;
 Thu,  7 May 2020 03:56:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VJke8OzCaolN; Thu,  7 May 2020 03:56:30 +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-pj1-f67.google.com (mail-pj1-f67.google.com
 [209.85.216.67])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 5882687BC0;
 Thu,  7 May 2020 03:56:30 +0000 (UTC)
Received: by mail-pj1-f67.google.com with SMTP id h12so3309634pjz.1;
 Wed, 06 May 2020 20:56:30 -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=qi/GqcsAo6W173yuysyPUUhL6QxOsr6lerMemHbUWjo=;
 b=cJQJAG27pX+A3gRehZG1FlaDOj+V8NPVrjrpTYCBeRnY4uQpsGRvvDGzgeGH38qNXl
 77WEf7LNZ72osjqmCbkmB4V+AnOnWcJbk8XUbPuO7pNgPI+5GVTbRhNAxkmNBxCC7r++
 DiJPw2GLj+ilw0S7nZSOXJkXDPMHmaltSuVL9YBWv9m7U4XgRB8sIgXDPblLpvDqC/rJ
 mFsos/FlgkkEJOdc/hkQqy3HpGqkHNVg0atnFqtfqhxht/ircelHQUykCvCNmzzF5Wl8
 nmqBuyNgguArGVDLpeF9hjzH26vo7H0RI4c203yRdb8FMiZ9Mq73x4LtJDwL9U5EP4wN
 ywbw==
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=qi/GqcsAo6W173yuysyPUUhL6QxOsr6lerMemHbUWjo=;
 b=kdZzZD3AAb7kCQnqxoBzwND148BU1eD4tt4Dl2uWRDa9dbHJJJoiAkBDDs7mMZOeW3
 CBHNeC9G+LG+zpuxRUJ64y7nPX9at7NmwhIR7dQUvj8/B6DwCvOWeq3SJfPYfT2vEGvy
 wsUzRSp+uVzoVBntai/aXRl7x+erja/3FotwDp7CTivFNqEultURAcgWJY1LxgEx3Jg7
 UrI+BN5OUzJJsY2scOQCeUuhHSHlnayUvQdwk63rnthzwAkHOmGNGWc3tru808gyqRzY
 GL3RwfJmghWT1Mejb5xOvJQEMsv8LdCII58+mRPXNLeaMrjxUzpKnUCfDCdCzItZnz09
 qOGA==
X-Gm-Message-State: AGi0PuYKbzhpj5VZBgWQYj7455vmJDbXBw9kKpR1018ccg+XQ9TOEyk3
 VxXF3Pt0MyDI1OSM7N0wFqIlTbAHghYnhBI+6Yc=
X-Google-Smtp-Source: APiQypLf9uwYi3SYyFvsWzs3O/aWBnmRnf9faZheEik4jf/lq7D07ZcFcH0V4aq3VwB9U+kKdNbdi4/y+AhsEmaD8u8=
X-Received: by 2002:a17:902:a40e:: with SMTP id
 p14mr11957649plq.132.1588823789832; 
 Wed, 06 May 2020 20:56:29 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
 <CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com>
 <CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
In-Reply-To: <CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 6 May 2020 23:56:17 -0400
Message-ID: <CALZpt+Fmv3d-J69uyoJ5XB9hP78vqoS76Y2OVmHWqafkHTm5ZQ@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009a8d9a05a506dd2a"
X-Mailman-Approved-At: Thu, 07 May 2020 08:04:42 +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, 07 May 2020 03:56:31 -0000

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

What I'm thinking more is if the costs of security are being too much
externalized from the light clients onto full nodes, nodes operators are
just going to stop servicing light clients `peercfilters=3Dfalse`. The
backbone p2p network is going to be fine. But the massive LN light clients
network built on top is going to rely on centralized services for its chain
access and now you may have consensus capture by those..

Le mer. 6 mai 2020 =C3=A0 12:00, Keagan McClelland <keagan.mcclelland@gmail=
.com>
a =C3=A9crit :

> Hi Antoine,
>
> Consensus capture by miners isn't the only concern here. Consensus captur=
e
> by any subset of users whose interests diverge from the overall consensus
> is equally damaging. The scenario I can imagine here is that the more lig=
ht
> clients outpace full nodes, the more the costs of security are being
> externalized from the light clients onto the full nodes. In this situatio=
n,
> it can make full nodes harder to run. If they are harder to run it will
> price out some marginal set of full node operators, which causes a net ne=
w
> increase in light clients (as the disaffected full nodes convert), AND a
> redistribution of load onto a smaller surface area. This is a naturally
> unstable process. It is safe to say that as node counts drop, the set of
> node operators will increasingly represent economic actors with extreme
> weight. The more this process unfolds, the more likely their interests wi=
ll
> diverge from the population at large, and also the more likely they can b=
e
> coerced into behavior they otherwise wouldn't. After all it is easier to
> find agents who carry lots of economic weight. This is true independent o=
f
> their mining status, we should be just as wary of consensus capture by
> exchanges or HNWI's as we are about miners.
>
> Keagan
>
> On Wed, May 6, 2020 at 3:06 AM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> I do see the consensus capture argument by miners but in reality isn't
>> this attack scenario have a lot of assumptions on topology an deployment=
 ?
>>
>> For such attack to succeed you need miners nodes to be connected to
>> clients to feed directly the invalid headers and if these ones are
>> connected to headers/filters gateways, themselves doing full-nodes
>> validation invalid chain is going to be sanitized out ?
>>
>> Sure now you trust these gateways, but if you have multiple connections
>> to them and can guarantee they aren't run by the same entity, that maybe=
 an
>> acceptable security model, depending of staked amount and your
>> expectations. I more concerned of having a lot of them and being
>> diversified enough to avoid collusion between gateways/chain access
>> providers/miners.
>>
>> But even if you light clients is directly connected to the backbone
>> network and may be reached by miners you can implement fork anomalies
>> detection and from then you may have multiples options:
>> * halt the wallet, wait for human intervention
>> * fallback connection to a trusted server, authoritative on your chain
>> view
>> * invalidity proofs?
>>
>> Now I agree you need a wide-enough, sane backbone network to build on
>> top, and we should foster node adoption as much as we can.
>>
>> Le mar. 5 mai 2020 =C3=A0 09:01, Luke Dashjr <luke@dashjr.org> a =C3=A9c=
rit :
>>
>>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> > Trust-minimization of Bitcoin security model has always relied first
>>> and
>>> > above on running a full-node. This current paradigm may be shifted by
>>> LN
>>> > where fast, affordable, confidential, censorship-resistant payment
>>> services
>>> > may attract a lot of adoption without users running a full-node.
>>>
>>> No, it cannot be shifted. This would compromise Bitcoin itself, which
>>> for
>>> security depends on the assumption that a supermajority of the economy
>>> is
>>> verifying their incoming transactions using their own full node.
>>>
>>> The past few years has seen severe regressions in this area, to the
>>> point
>>> where Bitcoin's future seems quite bleak. Without serious improvements
>>> to the
>>> full node ratio, Bitcoin is likely to fail.
>>>
>>> Therefore, all efforts to improve the "full node-less" experience are
>>> harmful,
>>> and should be actively avoided. BIP 157 improves privacy of fn-less
>>> usage,
>>> while providing no real benefits to full node users (compared to more
>>> efficient protocols like Stratum/Electrum).
>>>
>>> For this reason, myself and a few others oppose merging support for BIP
>>> 157 in
>>> Core.
>>>
>>> > Assuming a user adoption path where a full-node is required to benefi=
t
>>> for
>>> > LN may deprive a lot of users, especially those who are already denie=
d
>>> a
>>> > real financial infrastructure access.
>>>
>>> If Bitcoin can't do it, then Bitcoin can't do it.
>>> Bitcoin can't solve *any* problem if it becomes insecure itself.
>>>
>>> Luke
>>>
>>> P.S. See also
>>>
>>> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa=
5fda0
>>>
>>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sov=
ereignty-18fac5bcdc25
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

<div dir=3D"ltr"><div>What I&#39;m thinking more is if the costs of securit=
y are being too much externalized from the light clients onto full nodes, n=
odes operators are just going to stop servicing light clients `peercfilters=
=3Dfalse`. The backbone p2p network is going to be fine. But the massive LN=
 light clients network built on top is going to rely on centralized service=
s for its chain access and now you may have consensus capture by those..<br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">Le=C2=A0mer. 6 mai 2020 =C3=A0=C2=A012:00, Keagan McClelland &lt;<a =
href=3D"mailto:keagan.mcclelland@gmail.com">keagan.mcclelland@gmail.com</a>=
&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Conse=
nsus capture by miners isn&#39;t the only concern here. Consensus capture b=
y any subset of users whose interests diverge from the overall consensus is=
 equally damaging. The scenario I can imagine here is that the more light c=
lients outpace full nodes, the more the costs of security are being externa=
lized from the light clients onto the full nodes. In this situation, it can=
 make full nodes harder to run. If they are harder to run it will price out=
 some marginal set of full node operators, which causes a net new increase =
in light clients (as the disaffected full nodes convert), AND a redistribut=
ion of load onto a smaller surface area. This is a naturally unstable proce=
ss. It is safe to say that as node counts drop, the set of node operators w=
ill increasingly represent economic actors with extreme weight. The more th=
is process unfolds, the more likely their interests will diverge from the p=
opulation at large, and also the more likely they can be coerced into behav=
ior they otherwise wouldn&#39;t. After all it is easier to find agents who =
carry lots of economic weight. This is true independent of their mining sta=
tus, we should be just as wary of consensus capture by exchanges or HNWI&#3=
9;s as we are about miners.</div><div><br></div><div>Keagan<br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed=
, May 6, 2020 at 3:06 AM Antoine Riard &lt;<a href=3D"mailto:antoine.riard@=
gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I=
 do see the consensus capture argument by miners but in reality isn&#39;t t=
his attack scenario have a lot of assumptions on topology an deployment ?<b=
r><br></div><div>For such attack to succeed you need miners nodes to be con=
nected to clients to feed directly the invalid headers and if these ones ar=
e connected to headers/filters gateways, themselves doing full-nodes valida=
tion invalid chain is going to be sanitized out ?<br><br></div><div>Sure no=
w you trust these gateways, but if you have multiple connections to them an=
d can guarantee they aren&#39;t run by the same entity, that maybe an accep=
table security model, depending of staked amount and your expectations. I m=
ore concerned of having a lot of them and being diversified enough to avoid=
 collusion between gateways/chain access providers/miners.<br><br></div><di=
v>But even if you light clients is directly connected to the backbone netwo=
rk and may be reached by miners you can implement fork anomalies detection =
and from then you may have multiples options:<br></div><div>* halt the wall=
et, wait for human intervention<br></div><div>* fallback connection to a tr=
usted server, authoritative on your chain view<br></div><div>* invalidity p=
roofs?<br><br></div><div>Now I agree you need a wide-enough, sane backbone =
network to build on top, and we should foster node adoption as much as we c=
an.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A009:01, Luke Dashjr &lt;<a =
href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt; a=
 =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:<br>
&gt; Trust-minimization of Bitcoin security model has always relied first a=
nd<br>
&gt; above on running a full-node. This current paradigm may be shifted by =
LN<br>
&gt; where fast, affordable, confidential, censorship-resistant payment ser=
vices<br>
&gt; may attract a lot of adoption without users running a full-node.<br>
<br>
No, it cannot be shifted. This would compromise Bitcoin itself, which for <=
br>
security depends on the assumption that a supermajority of the economy is <=
br>
verifying their incoming transactions using their own full node.<br>
<br>
The past few years has seen severe regressions in this area, to the point <=
br>
where Bitcoin&#39;s future seems quite bleak. Without serious improvements =
to the <br>
full node ratio, Bitcoin is likely to fail.<br>
<br>
Therefore, all efforts to improve the &quot;full node-less&quot; experience=
 are harmful, <br>
and should be actively avoided. BIP 157 improves privacy of fn-less usage, =
<br>
while providing no real benefits to full node users (compared to more <br>
efficient protocols like Stratum/Electrum).<br>
<br>
For this reason, myself and a few others oppose merging support for BIP 157=
 in <br>
Core.<br>
<br>
&gt; Assuming a user adoption path where a full-node is required to benefit=
 for<br>
&gt; LN may deprive a lot of users, especially those who are already denied=
 a<br>
&gt; real financial infrastructure access.<br>
<br>
If Bitcoin can&#39;t do it, then Bitcoin can&#39;t do it.<br>
Bitcoin can&#39;t solve *any* problem if it becomes insecure itself.<br>
<br>
Luke<br>
<br>
P.S. See also<br>
<a href=3D"https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-=
206bafa5fda0" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@nico=
lasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0</a><br>
<a href=3D"https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-s=
elf-sovereignty-18fac5bcdc25" rel=3D"noreferrer" target=3D"_blank">https://=
medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18f=
ac5bcdc25</a><br>
</blockquote></div>
_______________________________________________<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>
</blockquote></div>

--0000000000009a8d9a05a506dd2a--