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