Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
Good morning Antoine, > While approaching this question, I think you should consider economic weight > of nodes in evaluating miner consensus-hijack success. Even if you expect a > disproportionate ratio of full-nodes-vs-SPV, they may not have the same > economic weight at all, therefore even if miners are able to lure a majority > of SPV clients they may not be able to stir economic nodes. SPV clients users > will now have an incentive to cancel their hijacked history to stay on the > most economic meaningful chain. And it's already assumed, that if you run a > bitcoin business or LN routing node, you do want to run your own full-node. One hope I have for Lightning is that it will replace centralized custodial services, because: * Lightning gains some of the scalability advantage of centralized custodial services, because you can now transfer to any Lightning client without touching the blockchain, for much reduced transfer fees. * At the same time, it retains your-keys-your-coins noncustodiality, because every update of a Lightning channel requires your keys to sign off on it. If most Lightning clients are SPV, then if we compare these two worlds: * There are a few highly-important centralized custodial services with significant economic weight running fullnodes (i.e. now). * There are no highly-important centralized custodial services, and most everyone uses Lightning, but with SPV (i.e. a Lightning future). Then the distribution of economic weight would be different between these two worlds. It may even be possible, that the Lightning future with massive SPV might end up with more economic weight in SPV nodes, than in the world without Lightning and dependent on centralized custodial services to scale. It is also entirely possible that custodial services for Lightning will arise anyway and my hope is already dashed, come on universe, work harder will you, would you really disappoint some randomly-generated Internet person like that. > > I agree it may be hard to evaluate economic-weight-to-chain-backend segments, > specially with offchain you disentangle an onchain output value from its real > payment traffic. To strengthen SPV, you may implement forks detection and > fallback to some backup node(s) which would serve as an authoritative source > to arbiter between branches. Such backup node(s) must be picked up manually > at client initialization, before any risk of conflict to avoid Reddit-style > of hijack during contentious period or other massive social engineering. You > don't want autopilot-style of recommendations for picking up a backup nodes > and avoid cenralization of backups, but somehow a uniform distribution. A > backup node may be a private one, it won't serve you any data beyond headers, > and therefore you preserve public nodes bandwidth, which IMO is the real > bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for > 1-full-node and people are not effectively able to pickup a backup among > their social environment. > What do you think about this model ? Money makes the world go round, so such backup servers that are publicly-facing rather than privately-owned should be somehow incentivized to do so, or else they would not exist in the first place. Of course, a free market tends towards monopoly, because any entity that happens to have even a slight advantage at the business will have more money to use towards business reinvestment and increase its advantage further, until they beat the competition to dust, anyone who has won a 4X game knows to search for and stack those little advantages until you snowball and conquer the world/galaxy/petri dish which is why the endgame of 4X games is so boring compared to the start, we have seen this happen in mining and exchanges and so on, and this works against your desire to have a uniform distribution. If everyone runs such a privately-owned server, on the other hand, this is not so different from having a Lightning node you run at your home that has a fullnode as well and which you access via a remote control mobile device, and it is the inconvenience of having such a server at your home that prevents this in the first place. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
Hi Chris, While approaching this question, I think you should consider economic weight of nodes in evaluating miner consensus-hijack success. Even if you expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the same economic weight at all, therefore even if miners are able to lure a majority of SPV clients they may not be able to stir economic nodes. SPV clients users will now have an incentive to cancel their hijacked history to stay on the most economic meaningful chain. And it's already assumed, that if you run a bitcoin business or LN routing node, you do want to run your own full-node. I agree it may be hard to evaluate economic-weight-to-chain-backend segments, specially with offchain you disentangle an onchain output value from its real payment traffic. To strengthen SPV, you may implement forks detection and fallback to some backup node(s) which would serve as an authoritative source to arbiter between branches. Such backup node(s) must be picked up manually at client initialization, before any risk of conflict to avoid Reddit-style of hijack during contentious period or other massive social engineering. You don't want autopilot-style of recommendations for picking up a backup nodes and avoid cenralization of backups, but somehow a uniform distribution. A backup node may be a private one, it won't serve you any data beyond headers, and therefore you preserve public nodes bandwidth, which IMO is the real bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for 1-full-node and people are not effectively able to pickup a backup among their social environment. What do you think about this model ? Cheers, Antoine Le mar. 12 mai 2020 à 17:06, Chris Belcher a écrit : > 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-...@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
