1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <ZmnSCPxj@protonmail.com>
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 <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <uOUyhfZ-Ti4E4sQn_Cap6Em_pqVc-p2INXoBLIEKsiOWpWKT-WNeqUge902E-HU0wWWWo4onr8UQTNKg5YmVkUWfrlNVJkkMSWYCnoj2WVY=@protonmail.com>
In-Reply-To: <CALZpt+G8SzeX4U-VBhEZqQ0ApwAs_jKkKe7aeZEQZ5KcJaMjCg@mail.gmail.com>
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
<202005051300.38836.luke@dashjr.org>
<CAH5Bsr27rN1SE166ON_q49=MNti0v7Vyn6s6T5R3=LC69K2QdQ@mail.gmail.com>
<6883e35a-e584-523f-d6f9-cf9ce2cca66d@riseup.net>
<CALZpt+G8SzeX4U-VBhEZqQ0ApwAs_jKkKe7aeZEQZ5KcJaMjCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
