> 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 à 13:36, John Newbery via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > 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 >> > _______________________________________________ > 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
