path: root/c2/4519ef02d86c2d5b874f51b3b60c1974543a8a

Return-Path: <john@johnnewbery.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF1FCC0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  5 May 2020 17:35:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 964D68784E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  5 May 2020 17:35:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NQRI44D2EKPx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  5 May 2020 17:35:44 +0000 (UTC)
X-Greylist: delayed 00:18:26 by SQLgrey-1.7.6
Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com
 [209.85.208.67])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 2441D8780E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  5 May 2020 17:35:44 +0000 (UTC)
Received: by mail-ed1-f67.google.com with SMTP id t12so2540618edw.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 05 May 2020 10:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=johnnewbery-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=+zL81hLdidoPUe6GQR8d0iaI9OFzUlFsommFmbCSsk4=;
 b=ST8mkZ+QCm07tmvpUwT8HfCUmvi97sdd2xzr1oAkxyOvUvgV1HUw85e0ul9tC60d5z
 PjRriz3A/346ObC3x1fI2ZWQdz5VU+Wd+Rh00rB6420NF0ftCEbfOJhcLEE1xBg/UcSq
 Yd94Afdpk5hPNBSbVG5KkfDQ0MPj2h4+nn5ZcUvb7OM6DGS/cJU304+h/u9EUWz9LFjE
 iv7DRJKntlKX/Rvej4P4geruYjEO2c1+IqBCAIGi9zjXxBWe5pNEyJ8bh0SzWqJzvrAo
 jE7txevEYNWL8G9TEygLR247tzX+x5AOM0K+wfJBlEerjPqUvLOxPQV4QrLwmL+hs3nt
 CfyA==
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=+zL81hLdidoPUe6GQR8d0iaI9OFzUlFsommFmbCSsk4=;
 b=gkp668iIuoVHDRW6oIAeazsSRHDApArjlOC4810JB/cTtvLoICJrKm0IxX4GpSuKhV
 L4esysM9Xw8+16cnLl7XqPjEjvlFmr4A+kVcU14j41+jBsbrbT5I0y+j9XlcICL9uPZT
 LKdYBYNxH5SSQYeXyNgbpMxcSRlwxS//EHm8Wi2aVE/kAATjNj3H9PiO3xWc6Cy4EcN5
 5x4M2Njwtp3zeBeaniTMgwZYFulAuK8fYY6q4d3ury53KEohwLNr85UeFd/YhK2TtrpG
 sP6sIm8LaHHGWEYV4GbRQ17oegMPG104jtt/r4PmNT9HGtz5Pd7K/BEdUl0LXyWJ3EO3
 EaCg==
X-Gm-Message-State: AGi0PuaogPZcV1LpXS5KTMhKFvPoes7mzE7MNRawfjDWwwCk5MXaTMf3
 PLSKw2bGMVHPKvWnUp1AOQfqL64JrrTvGdVmVSk7h+A0Gak=
X-Google-Smtp-Source: APiQypK4sSuJjdcYNkETlmDy5pgPOTbjoyaqev+uUngHHUVVC8qDNflMf9wj60jOg03lipWtO4WJIIhpt5rITAyb4Hw=
X-Received: by 2002:a19:7909:: with SMTP id u9mr2328841lfc.130.1588698584563; 
 Tue, 05 May 2020 10:09:44 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
 <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com>
In-Reply-To: <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com>
From: John Newbery <john@johnnewbery.com>
Date: Tue, 5 May 2020 13:09:33 -0400
Message-ID: <CAOV-6Td2M-zSCrPvUKVOD39C2dMf5ORFR-+YiSjUddULKkHpxA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c9d85c05a4e9b65d"
X-Mailman-Approved-At: Tue, 05 May 2020 17:36:37 +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: Tue, 05 May 2020 17:35:45 -0000

--000000000000c9d85c05a4e9b65d
Content-Type: text/plain; charset="UTF-8"

There doesn't seem to be anything in the original email that's specific to
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 already
use light clients. The choice between whether we offer them a light client
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 headers
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 service
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=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
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 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.
> >
> > 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.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> 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 service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> 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 clients 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 major
> 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
>

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

<div dir=3D"ltr">There doesn&#39;t seem to be anything in the original emai=
l that&#39;s specific to BIP 157. It&#39;s a restatement of the arguments a=
gainst light clients:<div><br></div><div>- light clients are a burden on th=
e full nodes that serve them<br>- if light clients become more popular, the=
re won&#39;t be enough full nodes to serve them<br>- people might build pro=
ducts that depend on altruistic nodes serving data, which is unsustainable<=
br>- maybe at some point in the future, light clients will need to pay for =
services<br></div><div><br></div><div>The choice isn&#39;t between=C2=A0peo=
ple using light clients or not. People already use light clients. The choic=
e between 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 a=
vailable elsewhere, but to summarize:</div><div><br></div><div>- they&#39;r=
e unique for a block, which means they can easily be cached. Serving a filt=
er requires no computation, just i/o (or memory access for cached filter/he=
ader data) and bandwidth. There are plenty of other services that a full no=
de offers that=C2=A0use i/o and bandwidth, such as serving blocks.<br>- uni=
que-for-block means clients can download from multiple sources</div><div>- =
the linked-headers/filters model allows hybrid approaches, where headers ch=
eckpoints can be fetched from trusted/signed nodes, with intermediate heade=
rs and filters fetched from untrusted sources<br>- less possibilities to Do=
S/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 BIP=
157 directly into bitcoind was to essentially force all `bitcoind` users to=
 possibly service BIP157 clients</div><div><br></div><div>Please. No-one is=
 forcing anyone to do anything. To serve filters, a node user=C2=A0needs to=
 download 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><div>John</div><div><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid 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>

--000000000000c9d85c05a4e9b65d--