Date: Tue, 05 May 2020 13:49:58 +0000
To: Luke Dashjr <luke@dashjr.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com>
In-Reply-To: <202005051300.38836.luke@dashjr.org>
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>,
 "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

Good morning ariard and luke-jr


> > 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 serv=
ices
> > 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 har=
mful,
> 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 1=
57 in
> Core.

BIP 157 can be implemented as a separate daemon that processes the blocks d=
ownloaded 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 c=
lients, 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, whe=
re 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 watchto=
wers provide light-client services, since that seems to be the major busine=
ss model of watchtowers, as suggested by ariard as well.
This is still less than ideal, but maybe is better than nothing.

Regards,
ZmnSCPxj