From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: <202005051300.38836.luke@dashjr.org> <6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net> In-Reply-To: <6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net> From: Antoine Riard Date: Wed, 13 May 2020 15:51:29 -0400 Message-ID: To: Chris Belcher Content-Type: multipart/alternative; boundary="000000000000b34ac705a58ce880" X-Mailman-Approved-At: Wed, 13 May 2020 20:13:39 +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: 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 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
Hi Chris,

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's already assumed, that if you run a bitcoin bu= siness 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 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'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'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'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 t= hink about this model ?

Cheers,

Antoine
=
Le=C2= =A0mar. 12 mai 2020 =C3=A0=C2=A017:06, Chris Belcher <belcher@riseup.net> a =C3=A9crit=C2=A0:
On 05/05/2020 16:16, Llo= yd 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 wrot= e:
>>> Trust-minimization of Bitcoin security model has always relied= first and
>>> above on running a full-node. This current paradigm may be shi= fted by LN
>>> where fast, affordable, confidential, censorship-resistant pay= ment
>> services
>>> may attract a lot of adoption without users running a full-nod= e.
>>
>> No, it cannot be shifted. This would compromise Bitcoin itself, wh= ich for
>> security depends on the assumption that a supermajority of the eco= nomy is
>> verifying their incoming transactions using their own full node. >>
>
> Hi Luke,
>
> I have heard this claim made several times but have never understood t= he
> 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.=C2=A0 I've been scammed several t= imes in my life in
> fiat currency transactions but as far as I could tell it never negativ= ely
> affected the currency overall!
>
> The links you point and from what I've seen you say before refer t= o "miner
> control" as the culprit. My only thought is that this is because = a light
> 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 becau= se I'm
> running a light client) that still seems to only to damage me. Where d= oes
> 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 alre= ady
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 inflatio= n and
arbitrary seizure. Any normal user could download software called
"Bitcoin wallet" which they trust and have used before, but inste= ad of
using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallet= s
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/ma= ilman/listinfo/lightning-dev
--000000000000b34ac705a58ce880--