From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id EC84CC0859; Wed, 6 May 2020 09:06:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id D3D9086914; Wed, 6 May 2020 09:06:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE1UvNe7JeG8; Wed, 6 May 2020 09:06:24 +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-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 1F2218690E; Wed, 6 May 2020 09:06:24 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id t16so227666plo.7; Wed, 06 May 2020 02:06:24 -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=KYLwFIMTdZKUf2InUbVu4YrNjy/wNM4ifD/Z2h65KaM=; b=MVB6D3Qr8IyhzhdFHWnwI7EiAPG4cKQzXqcp3S3RYWDTMTf6renuSis9vjaNFCzncZ pi4bJ+9UjWV1BulZfQH4GlUFswmJpFgDXSrK+dUI9ioama1QoaM8F9TwZJev420qx9Iv UwvVmvK1r3h7t3arbjuv333m9YdHqzOSqXIahLQ9GySQaYZstE4+3nnuqGfTUFrKlxb+ qI/Zfq5qXrG6HtHwAjI8lh7paQ+BtXEfW0hxugROcU1ZFktHrvknCTswk/IrNJjp2wiY PQO0Av2aSAf/zPauq2S7zaX5pqTbnFUkl4Q+keg/A/9Fzz2gr7ZssmtnKzfWQ2ii7H+G zoBQ== 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=KYLwFIMTdZKUf2InUbVu4YrNjy/wNM4ifD/Z2h65KaM=; b=BQn1fWZe4n+1aPP6YPLrB6PJC0Q92IdjfMFpaohvDD2EdEfHo3sOnSRy+tqhK/w9JG 53Of/Ti7c0hLZ+7Z/RHMOoBONgBSCxcStO2Aul+GOE7EHxfbIr7ZI5lp+XZkuzfBdVxw l4a9yxg9fjyhwjXjhCjWgZHIlnrdK3ggE7Tyte6QzmMhHVfvt9TLqO2gxPzMDBDc4uCR 4xtF53QmPUmdryQjWCx05G1WqWKu2m+McBwBU/SneCCuYRzAIYjNF2d0hkdiocoWcGHO V+pBn6Cf7l+2ojiQvryxTxRV0AQeThMaQ0LOsXkP7oolf2/H3djlKVtNJirbwKfWjVBp XrWQ== X-Gm-Message-State: AGi0PubJmwZ1sKUlCwZbMVRpvWSdVba2nX/y5shlVVBrvLDZ/qQIoJ3F ZC4r09sKp/myp+hipBdsh4KZ/K9XHa2Qas/VlYM= X-Google-Smtp-Source: APiQypKg4KG3tu9+Vas0e25EU1VEUswrR+OVC4MK99v7X9NbP/QS12D5Da0J8XPT4/dkrsWCZkPo4985H6YO08s9QFs= X-Received: by 2002:a17:90a:266c:: with SMTP id l99mr8199225pje.186.1588755983538; Wed, 06 May 2020 02:06:23 -0700 (PDT) MIME-Version: 1.0 References: <202005051300.38836.luke@dashjr.org> In-Reply-To: <202005051300.38836.luke@dashjr.org> From: Antoine Riard Date: Wed, 6 May 2020 05:06:11 -0400 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="000000000000089d3605a4f71420" X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-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, 06 May 2020 09:06:25 -0000 --000000000000089d3605a4f71420 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 a =C3=A9crit= : > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > Trust-minimization of Bitcoin security model has always relied first an= d > > above on running a full-node. This current paradigm may be shifted by L= N > > 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 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-206bafa5f= da0 > > https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sover= eignty-18fac5bcdc25 > --000000000000089d3605a4f71420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do see the consensus capture argument by miners but= in reality isn't this attack scenario have a lot of assumptions on top= ology an deployment ?

For such attack to succeed you need= miners nodes to be connected to clients to feed directly the invalid heade= rs 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 enti= ty, that maybe an acceptable security model, depending of staked amount and= your expectations. I more concerned of having a lot of them and being dive= rsified enough to avoid collusion between gateways/chain access providers/m= iners.

But even if you light clients is directly connecte= d to the backbone network and may be reached by miners you can implement fo= rk anomalies detection and from then you may have multiples options:
* halt the wallet, wait for human intervention
* fall= back 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 a= doption as much as we can.

Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A009:= 01, Luke Dashjr <luke@dashjr.org&= gt; a =C3=A9crit=C2=A0:
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 ser= vices
> may attract a lot of adoption without users running a full-node.

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.

The past few years has seen severe regressions in this area, to the point <= br> 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 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/@nico= lasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://= medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18f= ac5bcdc25
--000000000000089d3605a4f71420--