<div dir="ltr">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:<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't be enough full nodes to serve them<br>- people might build products 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'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.</div><div><br></div><div>The arguments for why BIP 157 is better than the existing light client technologies are available elsewhere, but to summarize:</div><div><br></div><div>- 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.<br>- unique-for-block means clients can download from multiple sources</div><div>- 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<br>- less possibilities to DoS/waste resources on the serving node<br>- better for privacy<br></div><div><br></div><div>> The intention, as I understood it, of putting BIP157 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 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.</div><div><br></div><div>Regards,</div><div>John</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning ariard and luke-jr<br>
<br>
<br>
> > Trust-minimization of Bitcoin security model has always relied first and<br>
> > above on running a full-node. This current paradigm may be shifted by LN<br>
> > where fast, affordable, confidential, censorship-resistant payment services<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>
BIP 157 can be implemented as a separate daemon that processes the blocks downloaded 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 clients, 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, where 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?  We hope?<br>
<br>
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.<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="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>