path: root/75/3eab8ac100b9549ddfc1200d87f397b3573bc0

Return-Path: <keagan.mcclelland@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C1DC8C0859;
 Wed,  6 May 2020 16:00:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id B0C0D878B7;
 Wed,  6 May 2020 16:00:31 +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 Gk+O2xz1JeXE; Wed,  6 May 2020 16:00:29 +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-ej1-f68.google.com (mail-ej1-f68.google.com
 [209.85.218.68])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 597FE87673;
 Wed,  6 May 2020 16:00:29 +0000 (UTC)
Received: by mail-ej1-f68.google.com with SMTP id o10so1399307ejn.10;
 Wed, 06 May 2020 09:00:29 -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=Wv8KhaDO+UV2DwzrzlyhThATO145X7CWn0BQjpHHfmw=;
 b=qDka9rCQMU5MvgA4EF4y9H5C74AM1dp8DnPBaySaIDjzA4ZM4M+mk/9azukdSp8vdh
 CCwv5Xpo0vYN1d1bVDZxK3H7zX/0tYUZO2pbGkhj3YRDBFjRyStCwdXS3CoW/Q3cnvv2
 euqT3VrUa9iYhbEVsBhNgAO2Zv0ccO0fP6IhuFgN/eJDzZ8Ianj0tjDYrmJDc8FQzwPn
 yTeIdcX7eAOifeXxVUR2SnhxNlNtb5hQkrzYSM3zgjPmj0qr1mRc5BHX2FZgIeI9d9Px
 9T++kJd+W3PvUW7+pdQYZwCChy7SnQ7fJmduZL+R5weVKY8PT5d/XkQ3lDv2wjl8bf1w
 yQpg==
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=Wv8KhaDO+UV2DwzrzlyhThATO145X7CWn0BQjpHHfmw=;
 b=BXKG91/gppsJ6y9FhI4T4KMaQpZRw9iE7QRCzaQuKrD7iOlf5giKWNdAITn9zdkiPM
 MkICqV2iD6GbzdFFamXE8pyEJ6e4vn3M8LWZwSlTy4LSeY9ZKaoaJan/ksD/jHZpcLBN
 99ksFOymWqE2EfKStMhJgZoJ8dfPw6sqlTwUE8GUjzVZhy0We8hX1DidC08Z8tii4bxs
 gcDvuN4zFg1hzToILCBa58PB6ZmBsV+oHiCfwpnyfyg+ujlx9ENjIRbCvwdTS6SM7VOW
 IAw+dI+naTmrsVpq3uvDIob2CYnKTrJ4Y9fW9lP2kPWc4W8+i2wzQqFpw15gtffJ86DU
 +ZAg==
X-Gm-Message-State: AGi0PuYskMK69tTsuhYLOu05cjYHZntD/8r/ASXirkSE5V+IMqu/Wne9
 +pqKiazy2eXqwc4cx9Sx8mSjMum93CqT+nTWguU=
X-Google-Smtp-Source: APiQypKAZIxAROn9ItisdeWWAJyDP4eEPiUhVaAoptkE2qwuJfr0rOZ4rywt3l+CNAs2etyT6qWMuw7LkA5x1JN7D2Q=
X-Received: by 2002:a17:906:2b02:: with SMTP id
 a2mr2614078ejg.323.1588780827533; 
 Wed, 06 May 2020 09:00:27 -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>
In-Reply-To: <CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Wed, 6 May 2020 10:00:15 -0600
Message-ID: <CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d9e6ea05a4fcdcae"
X-Mailman-Approved-At: Wed, 06 May 2020 16:08:22 +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: Wed, 06 May 2020 16:00:31 -0000

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

Hi Antoine,

Consensus capture by miners isn't the only concern here. Consensus capture
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 light
clients outpace full nodes, the more the costs of security are being
externalized 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
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 will
diverge from the population at large, and also the more likely they can be
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 of
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 t=
o
> 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 vi=
ew
> * 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=A9cr=
it :
>
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>> > Trust-minimization of Bitcoin security model has always relied first a=
nd
>> > 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 fo=
r
>> security depends on the assumption that a supermajority of the economy i=
s
>> verifying their incoming transactions using their own full node.
>>
>> The past few years has seen severe regressions in this area, to the poin=
t
>> where Bitcoin's future seems quite bleak. Without serious improvements t=
o
>> 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 benefit
>> for
>> > LN may deprive a lot of users, especially those who are already denied=
 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-206bafa5=
fda0
>>
>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sove=
reignty-18fac5bcdc25
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Consensus captur=
e by miners isn&#39;t the only concern here. Consensus capture by any subse=
t of users whose interests diverge from the overall consensus is equally da=
maging. The scenario I can imagine here is that the more light clients outp=
ace full nodes, the more the costs of security are being externalized 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 margi=
nal set of full node operators, which causes a net new increase in light cl=
ients (as the disaffected full nodes convert), AND a redistribution of load=
 onto a smaller surface area. This is a naturally unstable process. It is s=
afe to say that as node counts drop, the set of node operators will increas=
ingly represent economic actors with extreme weight. The more this process =
unfolds, the more likely their interests will diverge from the population a=
t large, and also the more likely they can be coerced into behavior they ot=
herwise wouldn&#39;t. After all it is easier to find agents who carry lots =
of economic weight. This is true independent of their mining status, we sho=
uld be just as wary of consensus capture by exchanges or HNWI&#39;s as we a=
re about miners.</div><div><br></div><div>Keagan<br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 6, 20=
20 at 3:06 AM Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">=
antoine.riard@gmail.com</a>&gt; wrote:<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>I do see the consensus capture=
 argument by miners but in reality isn&#39;t this attack scenario have a lo=
t of assumptions on topology an deployment ?<br><br></div><div>For such att=
ack to succeed you need miners nodes to be connected to clients to feed dir=
ectly the invalid headers and if these ones are connected to headers/filter=
s gateways, themselves doing full-nodes validation invalid chain is going t=
o be sanitized out ?<br><br></div><div>Sure now you trust these gateways, b=
ut if you have multiple connections to them and can guarantee they aren&#39=
;t run by the same entity, that maybe an acceptable security model, dependi=
ng of staked amount and your expectations. I more concerned of having a lot=
 of them and being diversified enough to avoid collusion between gateways/c=
hain access providers/miners.<br><br></div><div>But even if you light clien=
ts is directly connected to the backbone network and may be reached by mine=
rs you can implement fork anomalies detection and from then you may have mu=
ltiples options:<br></div><div>* halt the wallet, wait for human interventi=
on<br></div><div>* fallback connection to a trusted server, authoritative o=
n your chain view<br></div><div>* invalidity proofs?<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 can.<br></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 5 m=
ai 2020 =C3=A0=C2=A009:01, Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.or=
g" target=3D"_blank">luke@dashjr.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">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>

--000000000000d9e6ea05a4fcdcae--