From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Date: Thu, 14 May 2020 04:02:07 +0000 [thread overview]
Message-ID: <uOUyhfZ-Ti4E4sQn_Cap6Em_pqVc-p2INXoBLIEKsiOWpWKT-WNeqUge902E-HU0wWWWo4onr8UQTNKg5YmVkUWfrlNVJkkMSWYCnoj2WVY=@protonmail.com> (raw)
In-Reply-To: <CALZpt+G8SzeX4U-VBhEZqQ0ApwAs_jKkKe7aeZEQZ5KcJaMjCg@mail.gmail.com>
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
next prev parent reply other threads:[~2020-05-14 4:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 10:17 [bitcoin-dev] " Antoine Riard
2020-05-05 13:00 ` Luke Dashjr
2020-05-05 13:49 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-05-05 17:09 ` John Newbery
2020-05-06 9:21 ` Antoine Riard
2020-05-05 15:16 ` [bitcoin-dev] " Lloyd Fournier
2020-05-12 21:05 ` Chris Belcher
2020-05-13 19:51 ` [bitcoin-dev] [Lightning-dev] " Antoine Riard
2020-05-14 4:02 ` ZmnSCPxj [this message]
[not found] ` <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>
2020-05-14 15:25 ` Keagan McClelland
2020-05-17 9:11 ` Christopher Allen
2020-05-14 15:27 ` William Casarin
2020-05-17 3:37 ` Antoine Riard
2020-05-06 9:06 ` [bitcoin-dev] " Antoine Riard
2020-05-06 16:00 ` [bitcoin-dev] [Lightning-dev] " Keagan McClelland
2020-05-07 3:56 ` Antoine Riard
2020-05-07 4:07 ` Keagan McClelland
2020-05-08 19:51 ` Braydon Fuller
2020-05-08 20:01 ` Keagan McClelland
2020-05-08 20:22 ` Braydon Fuller
2020-05-08 21:29 ` Christopher Allen
2020-05-09 7:48 ` Antoine Riard
2020-05-06 0:31 ` Olaoluwa Osuntokun
2020-05-06 9:40 ` Antoine Riard
[not found] ` <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@mail.gmail.com>
2020-05-11 5:44 ` ZmnSCPxj
2020-05-12 10:09 ` Richard Myers
2020-05-12 15:48 ` ZmnSCPxj
2020-05-08 19:33 ` Braydon Fuller
[not found] ` <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>
2020-05-06 8:27 ` Antoine Riard
2020-05-07 16:40 ` Igor Cota
2020-05-09 7:22 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='uOUyhfZ-Ti4E4sQn_Cap6Em_pqVc-p2INXoBLIEKsiOWpWKT-WNeqUge902E-HU0wWWWo4onr8UQTNKg5YmVkUWfrlNVJkkMSWYCnoj2WVY=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox