diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2020-05-06 05:06:11 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-05-06 09:06:24 +0000 |
| commit | aed43a647dfb0d5524a0adf6a8234ee0f2dee0ee (patch) | |
| tree | bc1e6c693b938b31e5ea783525b97472c4154b53 | |
| parent | 57163628c9a14e0b9bceac5fd341862ca9068371 (diff) | |
| download | pi-bitcoindev-aed43a647dfb0d5524a0adf6a8234ee0f2dee0ee.tar.gz pi-bitcoindev-aed43a647dfb0d5524a0adf6a8234ee0f2dee0ee.zip | |
Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
| -rw-r--r-- | e4/9285e90ad4114311260457497da31e2f0c7356 | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/e4/9285e90ad4114311260457497da31e2f0c7356 b/e4/9285e90ad4114311260457497da31e2f0c7356 new file mode 100644 index 000000000..8e03b4355 --- /dev/null +++ b/e4/9285e90ad4114311260457497da31e2f0c7356 @@ -0,0 +1,237 @@ +Return-Path: <antoine.riard@gmail.com> +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: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com> + <202005051300.38836.luke@dashjr.org> +In-Reply-To: <202005051300.38836.luke@dashjr.org> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Wed, 6 May 2020 05:06:11 -0400 +Message-ID: <CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com> +To: Luke Dashjr <luke@dashjr.org> +Content-Type: multipart/alternative; boundary="000000000000089d3605a4f71420" +X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + "lightning-dev\\\\@lists.linuxfoundation.org" + <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 <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 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 <luke@dashjr.org> 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 + +<div dir=3D"ltr"><div>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 ?<br><br></div><div>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 ?<br= +><br></div><div>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.<br><br></div><div>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:<br></d= +iv><div>* halt the wallet, wait for human intervention<br></div><div>* fall= +back connection to a trusted server, authoritative on 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 a= +doption as much as we can.<br></div></div><br><div class=3D"gmail_quote"><d= +iv dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A009:= +01, Luke Dashjr <<a href=3D"mailto:luke@dashjr.org">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-left:1px solid rgb(204,204,204);padding-le= +ft:1ex">On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote= +:<br> +> Trust-minimization of Bitcoin security model has always relied first a= +nd<br> +> above on running a full-node. This current paradigm may be shifted by = +LN<br> +> where fast, affordable, confidential, censorship-resistant payment ser= +vices<br> +> 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'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 "full node-less" 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> +> Assuming a user adoption path where a full-node is required to benefit= + for<br> +> LN may deprive a lot of users, especially those who are already denied= + a<br> +> real financial infrastructure access.<br> +<br> +If Bitcoin can't do it, then Bitcoin can't do it.<br> +Bitcoin can'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> + +--000000000000089d3605a4f71420-- + |