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"
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
Precedence: list

--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--