From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0E54BC016F; Thu, 14 May 2020 04:02:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id E95138963A; Thu, 14 May 2020 04:02:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-KGZoORmVvR; Thu, 14 May 2020 04:02:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by hemlock.osuosl.org (Postfix) with ESMTPS id 2702F88D57; Thu, 14 May 2020 04:02:16 +0000 (UTC) Date: Thu, 14 May 2020 04:02:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589428933; bh=bLrXjKi2BEPIXQQqDniuOknL8ui03cRdg5YvPlrjXV4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=YikgIJPysr+TnPAKfYXWi9qYcPcV4JIhk3ugl7w43SregdHhoNkLLigLNoSxcLWfe gWgbnbs1bwAwvs0Dwcalt8WXtQDeAbdlin7zsiUQLEFv35tP8DkxRlbg7QO7yFHccG 7e0RhyhcRcDyESi7DC2cDAFP4Bl6zN5+fhTh6N+8= To: Antoine Riard From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <202005051300.38836.luke@dashjr.org> <6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 04:02:18 -0000 Good morning Antoine, > While approaching this question, I think you should consider economic wei= ght of nodes in evaluating miner consensus-hijack success. Even if you expe= ct a disproportionate ratio of full-nodes-vs-SPV, they may not have the sam= e =C2=A0economic 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 c= lients 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 custodia= l services, because you can now transfer to any Lightning client without to= uching the blockchain, for much reduced transfer fees. * At the same time, it retains your-keys-your-coins noncustodiality, becaus= e 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 sign= ificant economic weight running fullnodes (i.e. now). * There are no highly-important centralized custodial services, and most ev= eryone uses Lightning, but with SPV (i.e. a Lightning future). Then the distribution of economic weight would be different between these t= wo worlds. It may even be possible, that the Lightning future with massive SPV might e= nd up with more economic weight in SPV nodes, than in the world without Lig= htning and dependent on centralized custodial services to scale. It is also entirely possible that custodial services for Lightning will ari= se anyway and my hope is already dashed, come on universe, work harder will= you, would you really disappoint some randomly-generated Internet person l= ike that. > > I agree it may be hard to evaluate economic-weight-to-chain-backend segme= nts, specially with offchain you disentangle an onchain output value from i= ts real payment traffic. To strengthen SPV, you may implement forks detecti= on and fallback to some backup node(s) which would serve as an authoritativ= e source to arbiter between branches. Such backup node(s) must be picked up= manually at client initialization, before any risk of conflict to avoid Re= ddit-style of hijack during contentious period or other massive social engi= neering. You don't want autopilot-style of recommendations for picking up a= backup nodes and avoid cenralization of backups, but somehow a uniform dis= tribution. 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 IM= O 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-fa= cing rather than privately-owned should be somehow incentivized to do so, o= r else they would not exist in the first place. Of course, a free market tends towards monopoly, because any entity that ha= ppens to have even a slight advantage at the business will have more money = to use towards business reinvestment and increase its advantage further, un= til they beat the competition to dust, anyone who has won a 4X game knows t= o search for and stack those little advantages until you snowball and conqu= er the world/galaxy/petri dish which is why the endgame of 4X games is so b= oring compared to the start, we have seen this happen in mining and exchang= es and so on, and this works against your desire to have a uniform distribu= tion. 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 pre= vents this in the first place. Regards, ZmnSCPxj