path: root/c2/d906370581ab71b39e391e4ede175ffda6cb70

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 4C193C0859;
 Wed,  6 May 2020 09:21:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 396C1204D8;
 Wed,  6 May 2020 09:21:32 +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 59M97BxhUr9K; Wed,  6 May 2020 09:21:30 +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-f177.google.com (mail-pl1-f177.google.com
 [209.85.214.177])
 by silver.osuosl.org (Postfix) with ESMTPS id 658AA24C8F;
 Wed,  6 May 2020 09:21:30 +0000 (UTC)
Received: by mail-pl1-f177.google.com with SMTP id k19so237322pll.9;
 Wed, 06 May 2020 02:21:30 -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=hTA+czHivxCTsILSakeUB6zzAZtLhdK3663QqqfVsGQ=;
 b=C9izuxUxA+9DGdNtECXP8qA+osopVG8dgd2zl1zdHcnETOJa3EfAAKLMizkHqO4yoL
 1IY4LExGtY/Mu9/KfjVfu//H3CTlbBL1jlJJDgKcRUGVfX68YFc6QB1yOObxox9C2ne6
 AYpx57o6DirMDpiRMWem+3feBcifE3WweYN9TChdmVpN1/boGDswaqG8n3BDJ/QzIZBq
 tbjHLnVxYT9L3PxgHSVo4xkauwW59M0zjhZzTQ5saYwPxhlozpXQ0me1vOWPo1cFDOz9
 Y49KI8VjKGXFbjvOsUKYDTrwogsSqUYflxivHQycyUhwCELdk/CMJB5WgtYWPpSiy9Ej
 F/Aw==
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=hTA+czHivxCTsILSakeUB6zzAZtLhdK3663QqqfVsGQ=;
 b=hM+vSWYElkn8VJzDB0SWUsQ0dkyBSnzLsV74LuOjRf2w6nSv7LVsUrg60uy8uTqUlx
 tN1bcj0aFwX08lYvWXxVETPazr4jF0iKkrcrVT2PxUTrInHeV6HMRhzN3BdzwkHksqOU
 HjKq0lfvrABA8aXzd1yWjePMrveaYG6/8ekyJAi57qnBPFmDtoxngEzPcmO+Np8ZNQWr
 YV0Ho8T7O8H39WuPvaeiqQMZFbbtrv7ijLxfWn1gubPzvJV0gB0YWcl7nua5abJ+MTGj
 AfQYZH5X11zVXQv9yps1zZnpaqEyRMclHHnuGqTV10UzNUjFtt+UEUP4RMz9oHPOKSAR
 mfCg==
X-Gm-Message-State: AGi0PubBK1Eoc5O0kybJfsGz4vPk/siofYyLnA0G6l1tD5eiWWcgGirG
 3VtO64SSZa5RQ214RyMpO7mS1N+wq07l1iZ/1KU=
X-Google-Smtp-Source: APiQypIZIZJkDezavtME//o630LYwEZzdkWdPPeZfrDzK9F+9xVE4jHcSNkO9t4YLl4mBc1Px4p2j2AHDrniAetFrQQ=
X-Received: by 2002:a17:90a:2365:: with SMTP id
 f92mr7877650pje.117.1588756889882; 
 Wed, 06 May 2020 02:21:29 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
 <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com>
 <CAOV-6Td2M-zSCrPvUKVOD39C2dMf5ORFR-+YiSjUddULKkHpxA@mail.gmail.com>
In-Reply-To: <CAOV-6Td2M-zSCrPvUKVOD39C2dMf5ORFR-+YiSjUddULKkHpxA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 6 May 2020 05:21:17 -0400
Message-ID: <CALZpt+E9A6uNJrcjz7GGz_dh6BosJybu4YRyJ4PvCB++c2Ocfg@mail.gmail.com>
To: John Newbery <john@johnnewbery.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000e534c05a4f74a11"
X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000
Cc: "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 09:21:32 -0000

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

> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.

And offer them a solution which would scale in the long-term.

Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how implementing BIP157 in Core will address
this issue ?

Le mar. 5 mai 2020 =C3=A0 13:36, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> There doesn't seem to be anything in the original email that's specific t=
o
> BIP 157. It's a restatement of the arguments against light clients:
>
> - light clients are a burden on the full nodes that serve them
> - if light clients become more popular, there won't be enough full nodes
> to serve them
> - people might build products that depend on altruistic nodes serving
> data, which is unsustainable
> - maybe at some point in the future, light clients will need to pay for
> services
>
> The choice isn't between people using light clients or not. People alread=
y
> use light clients. The choice between whether we offer them a light clien=
t
> technology that is better or worse for privacy and scalability.
>
> The arguments for why BIP 157 is better than the existing light client
> technologies are available elsewhere, but to summarize:
>
> - they're unique for a block, which means they can easily be cached.
> Serving a filter requires no computation, just i/o (or memory access for
> cached filter/header data) and bandwidth. There are plenty of other
> services that a full node offers that use i/o and bandwidth, such as
> serving blocks.
> - unique-for-block means clients can download from multiple sources
> - the linked-headers/filters model allows hybrid approaches, where header=
s
> checkpoints can be fetched from trusted/signed nodes, with intermediate
> headers and filters fetched from untrusted sources
> - less possibilities to DoS/waste resources on the serving node
> - better for privacy
>
> > The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly servic=
e
> BIP157 clients
>
> Please. No-one is forcing anyone to do anything. To serve filters, a node
> user needs to download the latest version, set `-blockfilterindex=3Dbasic=
` to
> build the compact filters index, and set `-peercfilters` to serve them ov=
er
> P2P. This is an optional, off-by-default feature.
>
> Regards,
> John
>
>
> On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard and luke-jr
>>
>>
>> > > Trust-minimization of Bitcoin security model has always relied first
>> and
>> > > above on running a full-node. This current paradigm may be shifted b=
y
>> 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.
>> >
>> > 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 BI=
P
>> 157 in
>> > Core.
>>
>> BIP 157 can be implemented as a separate daemon that processes the block=
s
>> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>>
>> The intention, as I understood it, of putting BIP157 directly into
>> bitcoind was to essentially force all `bitcoind` users to possibly servi=
ce
>> BIP157 clients, in the hope that a BIP157 client can contact any arbitra=
ry
>> fullnode to get BIP157 service.
>> This is supposed to improve to the situation relative to e.g. Electrum,
>> where there are far fewer Electrum servers than fullnodes.
>>
>> Of course, as ariard computes, deploying BIP157 could lead to an
>> effective DDoS on the fullnode network if a large number of BIP157 clien=
ts
>> arise.
>> Though maybe this will not occur very fast?  We hope?
>>
>> It seems to me that the thing that *could* be done would be to have
>> watchtowers provide light-client services, since that seems to be the ma=
jor
>> business model of watchtowers, as suggested by ariard as well.
>> This is still less than ideal, but maybe is better than nothing.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><div>&gt; The choice between whether we offer them a =
light client technology that is better or worse for privacy and scalability=
.<br><br></div>And offer them a solution which would scale in the long-term=
.<br><br></div>Again it&#39;s not an argumentation against BIP 157 protocol=
 in itself, the problem I&#39;m interested in is how implementing BIP157 in=
 Core will address this issue ?<br></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A013:3=
6, John Newbery via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9cri=
t=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"><div di=
r=3D"ltr">There doesn&#39;t seem to be anything in the original email that&=
#39;s specific to BIP 157. It&#39;s a restatement of the arguments against =
light clients:<div><br></div><div>- light clients are a burden on the full =
nodes that serve them<br>- if light clients become more popular, there won&=
#39;t be enough full nodes to serve them<br>- people might build products t=
hat depend on altruistic nodes serving data, which is unsustainable<br>- ma=
ybe at some point in the future, light clients will need to pay for service=
s<br></div><div><br></div><div>The choice isn&#39;t between=C2=A0people usi=
ng light clients or not. People already use light clients. The choice betwe=
en whether we offer them a light client technology that is better or worse =
for privacy and scalability.</div><div><br></div><div>The arguments for why=
 BIP 157 is better than the existing light client technologies are availabl=
e elsewhere, but to summarize:</div><div><br></div><div>- they&#39;re uniqu=
e for a block, which means they can easily be cached. Serving a filter requ=
ires no computation, just i/o (or memory access for cached filter/header da=
ta) and bandwidth. There are plenty of other services that a full node offe=
rs that=C2=A0use i/o and bandwidth, such as serving blocks.<br>- unique-for=
-block means clients can download from multiple sources</div><div>- the lin=
ked-headers/filters model allows hybrid approaches, where headers checkpoin=
ts can be fetched from trusted/signed nodes, with intermediate headers and =
filters fetched from untrusted sources<br>- less possibilities to DoS/waste=
 resources on the serving node<br>- better for privacy<br></div><div><br></=
div><div>&gt;=C2=A0The intention, as I understood it, of putting BIP157 dir=
ectly into bitcoind was to essentially force all `bitcoind` users to possib=
ly service BIP157 clients</div><div><br></div><div>Please. No-one is forcin=
g anyone to do anything. To serve filters, a node user=C2=A0needs to downlo=
ad the latest version, set `-blockfilterindex=3Dbasic` to build the compact=
 filters index, and set `-peercfilters` to serve them over P2P. This is an =
optional, off-by-default feature.</div><div><br></div><div>Regards,</div><d=
iv>John</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning ariard and=
 luke-jr<br>
<br>
<br>
&gt; &gt; Trust-minimization of Bitcoin security model has always relied fi=
rst and<br>
&gt; &gt; above on running a full-node. This current paradigm may be shifte=
d by LN<br>
&gt; &gt; where fast, affordable, confidential, censorship-resistant paymen=
t services<br>
&gt; &gt; may attract a lot of adoption without users running a full-node.<=
br>
&gt;<br>
&gt; No, it cannot be shifted. This would compromise Bitcoin itself, which =
for<br>
&gt; security depends on the assumption that a supermajority of the economy=
 is<br>
&gt; verifying their incoming transactions using their own full node.<br>
&gt;<br>
&gt; The past few years has seen severe regressions in this area, to the po=
int<br>
&gt; where Bitcoin&#39;s future seems quite bleak. Without serious improvem=
ents to the<br>
&gt; full node ratio, Bitcoin is likely to fail.<br>
&gt;<br>
&gt; Therefore, all efforts to improve the &quot;full node-less&quot; exper=
ience are harmful,<br>
&gt; and should be actively avoided. BIP 157 improves privacy of fn-less us=
age,<br>
&gt; while providing no real benefits to full node users (compared to more<=
br>
&gt; efficient protocols like Stratum/Electrum).<br>
&gt;<br>
&gt; For this reason, myself and a few others oppose merging support for BI=
P 157 in<br>
&gt; Core.<br>
<br>
BIP 157 can be implemented as a separate daemon that processes the blocks d=
ownloaded by an attached `bitcoind`, i.e. what Wasabi does.<br>
<br>
The intention, as I understood it, of putting BIP157 directly into bitcoind=
 was to essentially force all `bitcoind` users to possibly service BIP157 c=
lients, in the hope that a BIP157 client can contact any arbitrary fullnode=
 to get BIP157 service.<br>
This is supposed to improve to the situation relative to e.g. Electrum, whe=
re there are far fewer Electrum servers than fullnodes.<br>
<br>
Of course, as ariard computes, deploying BIP157 could lead to an effective =
DDoS on the fullnode network if a large number of BIP157 clients arise.<br>
Though maybe this will not occur very fast?=C2=A0 We hope?<br>
<br>
It seems to me that the thing that *could* be done would be to have watchto=
wers provide light-client services, since that seems to be the major busine=
ss model of watchtowers, as suggested by ariard as well.<br>
This is still less than ideal, but maybe is better than nothing.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000e534c05a4f74a11--