{"type":"rich","version":"1.0","title":"John Newbery [ARCHIVE] wrote","author_name":"John Newbery [ARCHIVE] (npub1ap…608ff)","author_url":"https://njump.me/npub1aprq807up25mkugnhlr9nc2jkqqxd3wyrct3uj0kzhsdunaj7q8s7608ff","provider_name":"njump","provider_url":"https://njump.me","html":"📅 Original date posted:2020-05-05\n📝 Original message:There doesn't seem to be anything in the original email that's specific to\nBIP 157. It's a restatement of the arguments against light clients:\n\n- light clients are a burden on the full nodes that serve them\n- if light clients become more popular, there won't be enough full nodes to\nserve them\n- people might build products that depend on altruistic nodes serving data,\nwhich is unsustainable\n- maybe at some point in the future, light clients will need to pay for\nservices\n\nThe choice isn't between people using light clients or not. People already\nuse light clients. The choice between whether we offer them a light client\ntechnology that is better or worse for privacy and scalability.\n\nThe arguments for why BIP 157 is better than the existing light client\ntechnologies are available elsewhere, but to summarize:\n\n- they're unique for a block, which means they can easily be cached.\nServing a filter requires no computation, just i/o (or memory access for\ncached filter/header data) and bandwidth. There are plenty of other\nservices that a full node offers that use i/o and bandwidth, such as\nserving blocks.\n- unique-for-block means clients can download from multiple sources\n- the linked-headers/filters model allows hybrid approaches, where headers\ncheckpoints can be fetched from trusted/signed nodes, with intermediate\nheaders and filters fetched from untrusted sources\n- less possibilities to DoS/waste resources on the serving node\n- better for privacy\n\n\u003e The intention, as I understood it, of putting BIP157 directly into\nbitcoind was to essentially force all `bitcoind` users to possibly service\nBIP157 clients\n\nPlease. No-one is forcing anyone to do anything. To serve filters, a node\nuser needs to download the latest version, set `-blockfilterindex=basic` to\nbuild the compact filters index, and set `-peercfilters` to serve them over\nP2P. This is an optional, off-by-default feature.\n\nRegards,\nJohn\n\n\nOn Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning ariard and luke-jr\n\u003e\n\u003e\n\u003e \u003e \u003e Trust-minimization of Bitcoin security model has always relied first\n\u003e and\n\u003e \u003e \u003e above on running a full-node. This current paradigm may be shifted by\n\u003e LN\n\u003e \u003e \u003e where fast, affordable, confidential, censorship-resistant payment\n\u003e services\n\u003e \u003e \u003e may attract a lot of adoption without users running a full-node.\n\u003e \u003e\n\u003e \u003e No, it cannot be shifted. This would compromise Bitcoin itself, which for\n\u003e \u003e security depends on the assumption that a supermajority of the economy is\n\u003e \u003e verifying their incoming transactions using their own full node.\n\u003e \u003e\n\u003e \u003e The past few years has seen severe regressions in this area, to the point\n\u003e \u003e where Bitcoin's future seems quite bleak. Without serious improvements\n\u003e to the\n\u003e \u003e full node ratio, Bitcoin is likely to fail.\n\u003e \u003e\n\u003e \u003e Therefore, all efforts to improve the \"full node-less\" experience are\n\u003e harmful,\n\u003e \u003e and should be actively avoided. BIP 157 improves privacy of fn-less\n\u003e usage,\n\u003e \u003e while providing no real benefits to full node users (compared to more\n\u003e \u003e efficient protocols like Stratum/Electrum).\n\u003e \u003e\n\u003e \u003e For this reason, myself and a few others oppose merging support for BIP\n\u003e 157 in\n\u003e \u003e Core.\n\u003e\n\u003e BIP 157 can be implemented as a separate daemon that processes the blocks\n\u003e downloaded by an attached `bitcoind`, i.e. what Wasabi does.\n\u003e\n\u003e The intention, as I understood it, of putting BIP157 directly into\n\u003e bitcoind was to essentially force all `bitcoind` users to possibly service\n\u003e BIP157 clients, in the hope that a BIP157 client can contact any arbitrary\n\u003e fullnode to get BIP157 service.\n\u003e This is supposed to improve to the situation relative to e.g. Electrum,\n\u003e where there are far fewer Electrum servers than fullnodes.\n\u003e\n\u003e Of course, as ariard computes, deploying BIP157 could lead to an effective\n\u003e DDoS on the fullnode network if a large number of BIP157 clients arise.\n\u003e Though maybe this will not occur very fast?  We hope?\n\u003e\n\u003e It seems to me that the thing that *could* be done would be to have\n\u003e watchtowers provide light-client services, since that seems to be the major\n\u003e business model of watchtowers, as suggested by ariard as well.\n\u003e This is still less than ideal, but maybe is better than nothing.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200505/be23bd38/attachment-0001.html\u003e"}