Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote: > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: >>> 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. >> > > Hi Luke, > > I have heard this claim made several times but have never understood the > argument behind it. The question I always have is: If I get scammed by not > verifying my incoming transactions properly how can this affect anyone > else? It's very unintuative. I've been scammed several times in my life in > fiat currency transactions but as far as I could tell it never negatively > affected the currency overall! > > The links you point and from what I've seen you say before refer to "miner > control" as the culprit. My only thought is that this is because a light > client could follow a dishonest majority of hash power chain. But this just > brings me back to the question. If, instead of BTC, I get a payment in some > miner scamcoin on their dishonest fork (but I think it's BTC because I'm > running a light client) that still seems to only to damage me. Where does > the side effect onto others on the network come from? > > Cheers, > > LL > Hello Lloyd, The problem comes when a large part of the ecosystem gets scammed at once, which is how such an attack would happen in practice. For example, consider if bitcoin had 1 users. 10 of them use a full node wallet while the other 9990 use an SPV wallet. If a miner attacked the system by printing infinite bitcoins and spending coins without a valid signature, then the 9990 SPV wallets would accept those fake coins as payment, and trade the coins amongst themselves. After a time those coins would likely be the ancestors of most active coins in the 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies: full-node-coin and SPV-coin. Now the fraud miners may become well known, perhaps being published on bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong incentive to be against any rollback. Their recent transactions would disappear and they'd lose money. They would argue that they've already been using the coin for a while, and it works perfectly fine, and anyway a coin that can be spent in 9990 places is more useful than one that can be spent in just 10 places. The SPV-wallet community might even decide to use something like `invalidateblock` to make sure their SPV-coin doesn't get reorg'd out of existence. There'd also likely be a social attack, with every bitcoin community portal being flooded with bots and shills advocating the merits of SPV-coin. This is not a hypothetical because we already saw the same thing during the scalability conflict 2015-2017. Before you know it, "Bitcoin" would become SPV-coin with inflation and arbitrary seizure. Any normal user could download software called "Bitcoin wallet" which they trust and have used before, but instead of using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets backed by a full node, but that won't do much good to you when 9990 users happily use another coin as their medium of exchange. Regards CB ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
I do see the consensus capture argument by miners but in reality isn't this attack scenario have a lot of assumptions on topology an deployment ? For such attack to succeed you need miners nodes to be connected to clients to feed directly the invalid headers and if these ones are connected to headers/filters gateways, themselves doing full-nodes validation invalid chain is going to be sanitized out ? Sure now you trust these gateways, but if you have multiple connections to them and can guarantee they aren't run by the same entity, that maybe an acceptable security model, depending of staked amount and your expectations. I more concerned of having a lot of them and being diversified enough to avoid collusion between gateways/chain access providers/miners. But even if you light clients is directly connected to the backbone network and may be reached by miners you can implement fork anomalies detection and from then you may have multiples options: * halt the wallet, wait for human intervention * fallback connection to a trusted server, authoritative on your chain view * invalidity proofs? Now I agree you need a wide-enough, sane backbone network to build on top, and we should foster node adoption as much as we can. Le mar. 5 mai 2020 à 09:01, Luke Dashjr a écrit : > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > 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. > > > Assuming a user adoption path where a full-node is required to benefit > for > > LN may deprive a lot of users, especially those who are already denied a > > real financial infrastructure access. > > If Bitcoin can't do it, then Bitcoin can't do it. > Bitcoin can't solve *any* problem if it becomes insecure itself. > > Luke > > P.S. See also > > https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0 > > https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > 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. > Hi Luke, I have heard this claim made several times but have never understood the argument behind it. The question I always have is: If I get scammed by not verifying my incoming transactions properly how can this affect anyone else? It's very unintuative. I've been scammed several times in my life in fiat currency transactions but as far as I could tell it never negatively affected the currency overall! The links you point and from what I've seen you say before refer to "miner control" as the culprit. My only thought is that this is because a light client could follow a dishonest majority of hash power chain. But this just brings me back to the question. If, instead of BTC, I get a payment in some miner scamcoin on their dishonest fork (but I think it's BTC because I'm running a light client) that still seems to only to damage me. Where does the side effect onto others on the network come from? Cheers, LL ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > 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. > Assuming a user adoption path where a full-node is required to benefit for > LN may deprive a lot of users, especially those who are already denied a > real financial infrastructure access. If Bitcoin can't do it, then Bitcoin can't do it. Bitcoin can't solve *any* problem if it becomes insecure itself. Luke P.S. See also https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0 https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
