path: root/30/60fec7de5314528c5e4193b2b7da38b84b8417

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 3A42CC016F;
 Wed, 13 May 2020 19:51:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 217C022744;
 Wed, 13 May 2020 19:51:44 +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 yvGneedKCaX8; Wed, 13 May 2020 19:51:42 +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-f46.google.com (mail-pj1-f46.google.com
 [209.85.216.46])
 by silver.osuosl.org (Postfix) with ESMTPS id 2F771204B0;
 Wed, 13 May 2020 19:51:42 +0000 (UTC)
Received: by mail-pj1-f46.google.com with SMTP id hi11so11548676pjb.3;
 Wed, 13 May 2020 12:51:42 -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=gOkLLQqMff+D3E/ic2Xwe8TftdP5OEK4i1yf72buLSk=;
 b=cZiBECVa0YiEWsr1XBoLAiVvHdKYL0WhDfIiyFUs/MMlt03xpm2/0bG98mEMFjoVm/
 GLTPNMl+8YL6t8iNENkRN0N566WdzTa5isWLHb6yAmYxaKPsqrmexGPE1mZ9jtG7S7u+
 a17uvYlJzVOjtz3TTQcVukyDp9/i84BN5C9vV4PCTZizKGhfup73g0TZRYtOVbAJzME6
 JTSvAWhITq4RhLEOHlX78JabiO0ALQ463GKXpha5XEdbajVNjQtNkkglV786kvP8pZMq
 Ijw0ud/f/z6p35NJ7Ea6f+0TI38Hr7mE4JJvANCpFrI4L7XFQG+5tWshcPjsYk793y4L
 VNkw==
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=gOkLLQqMff+D3E/ic2Xwe8TftdP5OEK4i1yf72buLSk=;
 b=JsxLyL2GFFImgjhWzl8d/uGQktkeceKO6FBymv23OI/vCHpi3dkSLnCic4sNTO+zkW
 k33EUWvy6hboqSELIrO+20USJcMl+gDZlomCKRU2HUmbhu7PyoidBW1SFD5llG8MEJfm
 e8N+5y1zAGwaz53NFZAuYPYvPvRz/Dy9Oy1MGRDXwR4+ugNcf2MYgwBG5zmSFYL2+Uwt
 z0aZ+Dc3qU6SVPf8ne2owwJwgB+uLL5YYdRp/j52e8iBJEnnoswEDW4qWUAMFFRXw74L
 PcW8K/SccXnUMMgubbka90+RJHgOuzmoC+Qm5UDdsYBL5BwnhUZSX9L6o0JdmdEklOSr
 QT0Q==
X-Gm-Message-State: AGi0PuZ6fsE4RP+JD1yOmlhVyK9JuOoysa+6clhYXhzarW6BUPm/MAVt
 BOTm2CswNcWEtff5wna2OOh6a2El/1fXFWKJIfI=
X-Google-Smtp-Source: APiQypI2p7pBVvpr9Wfuf17WrvfXxKWiC3BE0YdkPJlHg/HQSsSrPrXVxz1DrO/vtu9MUWiC8tOBEDrw5HkTiwVftpc=
X-Received: by 2002:a17:90a:8c9:: with SMTP id
 9mr36913611pjn.183.1589399501620; 
 Wed, 13 May 2020 12:51:41 -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>
In-Reply-To: <6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 13 May 2020 15:51:29 -0400
Message-ID: <CALZpt+G8SzeX4U-VBhEZqQ0ApwAs_jKkKe7aeZEQZ5KcJaMjCg@mail.gmail.com>
To: Chris Belcher <belcher@riseup.net>
Content-Type: multipart/alternative; boundary="000000000000b34ac705a58ce880"
X-Mailman-Approved-At: Wed, 13 May 2020 20:13:39 +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, 13 May 2020 19:51:44 -0000

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

Hi Chris,

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

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

Cheers,

Antoine

Le mar. 12 mai 2020 =C3=A0 17:06, Chris Belcher <belcher@riseup.net> a =C3=
=A9crit :

> On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 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.
> >>
> >
> > Hi Luke,
> >
> > I have heard this claim made several times but have never understood th=
e
> > argument behind it. The question I always have is: If I get scammed by
> not
> > verifying my incoming transactions properly how can this affect anyone
> > else? It's very unintuative.  I've been scammed several times in my lif=
e
> in
> > fiat currency transactions but as far as I could tell it never negative=
ly
> > affected the currency overall!
> >
> > The links you point and from what I've seen you say before refer to
> "miner
> > control" as the culprit. My only thought is that this is because a ligh=
t
> > client could follow a dishonest majority of hash power chain. But this
> just
> > brings me back to the question. If, instead of BTC, I get a payment in
> some
> > miner scamcoin on their dishonest fork (but I think it's BTC because I'=
m
> > running a light client) that still seems to only to damage me. Where do=
es
> > the side effect onto others on the network come from?
> >
> > Cheers,
> >
> > LL
> >
>
> Hello Lloyd,
>
> The problem comes when a large part of the ecosystem gets scammed at
> once, which is how such an attack would happen in practice.
>
> For example, consider if bitcoin had 10000 users. 10 of them use a full
> node wallet while the other 9990 use an SPV wallet. If a miner attacked
> the system by printing infinite bitcoins and spending coins without a
> valid signature, then the 9990 SPV wallets would accept those fake coins
> as payment, and trade the coins amongst themselves. After a time those
> coins would likely be the ancestors of most active coins in the
> 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
> full-node-coin and SPV-coin.
>
> Now the fraud miners may become well known, perhaps being published on
> bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
> incentive to be against any rollback. Their recent transactions would
> disappear and they'd lose money. They would argue that they've already
> been using the coin for a while, and it works perfectly fine, and anyway
> a coin that can be spent in 9990 places is more useful than one that can
> be spent in just 10 places. The SPV-wallet community might even decide
> to use something like `invalidateblock` to make sure their SPV-coin
> doesn't get reorg'd out of existence. There'd also likely be a social
> attack, with every bitcoin community portal being flooded with bots and
> shills advocating the merits of SPV-coin. This is not a hypothetical
> because we already saw the same thing during the scalability conflict
> 2015-2017.
>
> Before you know it, "Bitcoin" would become SPV-coin with inflation and
> arbitrary seizure. Any normal user could download software called
> "Bitcoin wallet" which they trust and have used before, but instead of
> using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
> backed by a full node, but that won't do much good to you when 9990
> users happily use another coin as their medium of exchange.
>
> Regards
> CB
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr"><div><div><div>Hi Chris,<br><br>While approaching this que=
stion, I think you should consider economic weight of nodes in evaluating m=
iner consensus-hijack success. Even if you expect a disproportionate ratio =
of full-nodes-vs-SPV, they may not have the same =C2=A0economic weight at a=
ll, therefore even if miners are able to lure a majority of SPV clients the=
y may not be able to stir economic nodes. SPV clients users will now have a=
n incentive to cancel their hijacked history to stay on the most economic m=
eaningful chain. And it&#39;s already assumed, that if you run a bitcoin bu=
siness or LN routing node, you do want to run your own full-node. <br><br>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 s=
ource to arbiter between branches. Such backup node(s) must be picked up ma=
nually at client initialization, before any risk of conflict to avoid Reddi=
t-style of hijack during contentious period or other massive social enginee=
ring. You don&#39;t want autopilot-style of recommendations for picking up =
a backup nodes and avoid cenralization of backups, but somehow a uniform di=
stribution. A backup node may be a private one, it won&#39;t serve you any =
data beyond headers, and therefore you preserve public nodes bandwidth, whi=
ch IMO is the real bottleneck. I concede it won&#39;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.<br><br></div>What do you t=
hink about this model ?<br><br></div>Cheers,<br><br></div>Antoine<br></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=
=A0mar. 12 mai 2020 =C3=A0=C2=A017:06, Chris Belcher &lt;<a href=3D"mailto:=
belcher@riseup.net">belcher@riseup.net</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">On 05/05/2020 16:16, Llo=
yd Fournier via bitcoin-dev wrote:<br>
&gt; On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt;&gt; On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrot=
e:<br>
&gt;&gt;&gt; Trust-minimization of Bitcoin security model has always relied=
 first and<br>
&gt;&gt;&gt; above on running a full-node. This current paradigm may be shi=
fted by LN<br>
&gt;&gt;&gt; where fast, affordable, confidential, censorship-resistant pay=
ment<br>
&gt;&gt; services<br>
&gt;&gt;&gt; may attract a lot of adoption without users running a full-nod=
e.<br>
&gt;&gt;<br>
&gt;&gt; No, it cannot be shifted. This would compromise Bitcoin itself, wh=
ich for<br>
&gt;&gt; security depends on the assumption that a supermajority of the eco=
nomy is<br>
&gt;&gt; verifying their incoming transactions using their own full node.<b=
r>
&gt;&gt;<br>
&gt; <br>
&gt; Hi Luke,<br>
&gt; <br>
&gt; I have heard this claim made several times but have never understood t=
he<br>
&gt; argument behind it. The question I always have is: If I get scammed by=
 not<br>
&gt; verifying my incoming transactions properly how can this affect anyone=
<br>
&gt; else? It&#39;s very unintuative.=C2=A0 I&#39;ve been scammed several t=
imes in my life in<br>
&gt; fiat currency transactions but as far as I could tell it never negativ=
ely<br>
&gt; affected the currency overall!<br>
&gt; <br>
&gt; The links you point and from what I&#39;ve seen you say before refer t=
o &quot;miner<br>
&gt; control&quot; as the culprit. My only thought is that this is because =
a light<br>
&gt; client could follow a dishonest majority of hash power chain. But this=
 just<br>
&gt; brings me back to the question. If, instead of BTC, I get a payment in=
 some<br>
&gt; miner scamcoin on their dishonest fork (but I think it&#39;s BTC becau=
se I&#39;m<br>
&gt; running a light client) that still seems to only to damage me. Where d=
oes<br>
&gt; the side effect onto others on the network come from?<br>
&gt; <br>
&gt; Cheers,<br>
&gt; <br>
&gt; LL<br>
&gt; <br>
<br>
Hello Lloyd,<br>
<br>
The problem comes when a large part of the ecosystem gets scammed at<br>
once, which is how such an attack would happen in practice.<br>
<br>
For example, consider if bitcoin had 10000 users. 10 of them use a full<br>
node wallet while the other 9990 use an SPV wallet. If a miner attacked<br>
the system by printing infinite bitcoins and spending coins without a<br>
valid signature, then the 9990 SPV wallets would accept those fake coins<br=
>
as payment, and trade the coins amongst themselves. After a time those<br>
coins would likely be the ancestors of most active coins in the<br>
9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:<br>
full-node-coin and SPV-coin.<br>
<br>
Now the fraud miners may become well known, perhaps being published on<br>
bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong<br>
incentive to be against any rollback. Their recent transactions would<br>
disappear and they&#39;d lose money. They would argue that they&#39;ve alre=
ady<br>
been using the coin for a while, and it works perfectly fine, and anyway<br=
>
a coin that can be spent in 9990 places is more useful than one that can<br=
>
be spent in just 10 places. The SPV-wallet community might even decide<br>
to use something like `invalidateblock` to make sure their SPV-coin<br>
doesn&#39;t get reorg&#39;d out of existence. There&#39;d also likely be a =
social<br>
attack, with every bitcoin community portal being flooded with bots and<br>
shills advocating the merits of SPV-coin. This is not a hypothetical<br>
because we already saw the same thing during the scalability conflict<br>
2015-2017.<br>
<br>
Before you know it, &quot;Bitcoin&quot; would become SPV-coin with inflatio=
n and<br>
arbitrary seizure. Any normal user could download software called<br>
&quot;Bitcoin wallet&quot; which they trust and have used before, but inste=
ad of<br>
using Bitcoin they&#39;d be using SPV-coin. You may be one of the 10 wallet=
s<br>
backed by a full node, but that won&#39;t do much good to you when 9990<br>
users happily use another coin as their medium of exchange.<br>
<br>
Regards<br>
CB<br>
_______________________________________________<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>

--000000000000b34ac705a58ce880--