{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-07\n📝 Original message:I think that one of the solutions here is to have light clients choose\ntheir full node tethers explicitly. Even if you think it is unrealistic to\nhave everyone run their own node (fwiw, I don’t), there is still a trust\nmodel where you can pick your trusted source.\n\nThis way you could have many light clients working off of a family node,\nand the peer services could be limited to some sort of “authenticated”\npeers. Perhaps this is better accomplished over the RPC interface in Core,\nbut the idea is to have some sort of peer service model between “full\npublic” and “owner only”. This limits the amount of costs that can be\nproperly externalized, without exposing risk of consensus capture by\neconomically weighty institutions.\n\nKeagan\n\nOn Wed, May 6, 2020 at 9:56 PM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e What I'm thinking more is if the costs of security are being too much\n\u003e externalized from the light clients onto full nodes, nodes operators are\n\u003e just going to stop servicing light clients `peercfilters=false`. The\n\u003e backbone p2p network is going to be fine. But the massive LN light clients\n\u003e network built on top is going to rely on centralized services for its chain\n\u003e access and now you may have consensus capture by those..\n\u003e\n\u003e Le mer. 6 mai 2020 à 12:00, Keagan McClelland \u003ckeagan.mcclelland at gmail.com\u003e\n\u003e a écrit :\n\u003e\n\u003e\u003e Hi Antoine,\n\u003e\u003e\n\u003e\u003e Consensus capture by miners isn't the only concern here. Consensus\n\u003e\u003e capture by any subset of users whose interests diverge from the overall\n\u003e\u003e consensus is equally damaging. The scenario I can imagine here is that the\n\u003e\u003e more light clients outpace full nodes, the more the costs of security are\n\u003e\u003e being externalized from the light clients onto the full nodes. In this\n\u003e\u003e situation, it can make full nodes harder to run. If they are harder to run\n\u003e\u003e it will price out some marginal set of full node operators, which causes a\n\u003e\u003e net new increase in light clients (as the disaffected full nodes convert),\n\u003e\u003e AND a redistribution of load onto a smaller surface area. This is a\n\u003e\u003e naturally unstable process. It is safe to say that as node counts drop, the\n\u003e\u003e set of node operators will increasingly represent economic actors with\n\u003e\u003e extreme weight. The more this process unfolds, the more likely their\n\u003e\u003e interests will diverge from the population at large, and also the more\n\u003e\u003e likely they can be coerced into behavior they otherwise wouldn't. After all\n\u003e\u003e it is easier to find agents who carry lots of economic weight. This is true\n\u003e\u003e independent of their mining status, we should be just as wary of consensus\n\u003e\u003e capture by exchanges or HNWI's as we are about miners.\n\u003e\u003e\n\u003e\u003e Keagan\n\u003e\u003e\n\u003e\u003e On Wed, May 6, 2020 at 3:06 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e I do see the consensus capture argument by miners but in reality isn't\n\u003e\u003e\u003e this attack scenario have a lot of assumptions on topology an deployment ?\n\u003e\u003e\u003e\n\u003e\u003e\u003e For such attack to succeed you need miners nodes to be connected to\n\u003e\u003e\u003e clients to feed directly the invalid headers and if these ones are\n\u003e\u003e\u003e connected to headers/filters gateways, themselves doing full-nodes\n\u003e\u003e\u003e validation invalid chain is going to be sanitized out ?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sure now you trust these gateways, but if you have multiple connections\n\u003e\u003e\u003e to them and can guarantee they aren't run by the same entity, that maybe an\n\u003e\u003e\u003e acceptable security model, depending of staked amount and your\n\u003e\u003e\u003e expectations. I more concerned of having a lot of them and being\n\u003e\u003e\u003e diversified enough to avoid collusion between gateways/chain access\n\u003e\u003e\u003e providers/miners.\n\u003e\u003e\u003e\n\u003e\u003e\u003e But even if you light clients is directly connected to the backbone\n\u003e\u003e\u003e network and may be reached by miners you can implement fork anomalies\n\u003e\u003e\u003e detection and from then you may have multiples options:\n\u003e\u003e\u003e * halt the wallet, wait for human intervention\n\u003e\u003e\u003e * fallback connection to a trusted server, authoritative on your chain\n\u003e\u003e\u003e view\n\u003e\u003e\u003e * invalidity proofs?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Now I agree you need a wide-enough, sane backbone network to build on\n\u003e\u003e\u003e top, and we should foster node adoption as much as we can.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Le mar. 5 mai 2020 à 09:01, Luke Dashjr \u003cluke at dashjr.org\u003e a écrit :\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e \u003e Trust-minimization of Bitcoin security model has always relied first\n\u003e\u003e\u003e\u003e and\n\u003e\u003e\u003e\u003e \u003e above on running a full-node. This current paradigm may be shifted by\n\u003e\u003e\u003e\u003e LN\n\u003e\u003e\u003e\u003e \u003e where fast, affordable, confidential, censorship-resistant payment\n\u003e\u003e\u003e\u003e services\n\u003e\u003e\u003e\u003e \u003e may attract a lot of adoption without users running a full-node.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e No, it cannot be shifted. This would compromise Bitcoin itself, which\n\u003e\u003e\u003e\u003e for\n\u003e\u003e\u003e\u003e security depends on the assumption that a supermajority of the economy\n\u003e\u003e\u003e\u003e is\n\u003e\u003e\u003e\u003e verifying their incoming transactions using their own full node.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e The past few years has seen severe regressions in this area, to the\n\u003e\u003e\u003e\u003e point\n\u003e\u003e\u003e\u003e where Bitcoin's future seems quite bleak. Without serious improvements\n\u003e\u003e\u003e\u003e to the\n\u003e\u003e\u003e\u003e full node ratio, Bitcoin is likely to fail.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Therefore, all efforts to improve the \"full node-less\" experience are\n\u003e\u003e\u003e\u003e harmful,\n\u003e\u003e\u003e\u003e and should be actively avoided. BIP 157 improves privacy of fn-less\n\u003e\u003e\u003e\u003e usage,\n\u003e\u003e\u003e\u003e while providing no real benefits to full node users (compared to more\n\u003e\u003e\u003e\u003e efficient protocols like Stratum/Electrum).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e For this reason, myself and a few others oppose merging support for BIP\n\u003e\u003e\u003e\u003e 157 in\n\u003e\u003e\u003e\u003e Core.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e Assuming a user adoption path where a full-node is required to\n\u003e\u003e\u003e\u003e benefit for\n\u003e\u003e\u003e\u003e \u003e LN may deprive a lot of users, especially those who are already\n\u003e\u003e\u003e\u003e denied a\n\u003e\u003e\u003e\u003e \u003e real financial infrastructure access.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e If Bitcoin can't do it, then Bitcoin can't do it.\n\u003e\u003e\u003e\u003e Bitcoin can't solve *any* problem if it becomes insecure itself.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Luke\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e P.S. See also\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200506/26bac9b9/attachment.html\u003e"}