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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 87672C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 05:44:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 76CBB875BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 05:44:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Iq2IP5TrJuoz
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 05:44:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by whitealder.osuosl.org (Postfix) with ESMTPS id B4C7F8745D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 05:44:13 +0000 (UTC)
Date: Mon, 11 May 2020 05:44:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1589175851;
bh=aObPBlXHr6WLB1yPmijDlW1WnNV/wdPoNqf9zTXC7e4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=RM168AGFc/Hqz4T0NGUHfy4pSXN+G9xfpJqijVGP+zVe37f/gGur47iTmHhfWK5FP
N6NxKr3chLCivVzzmWptfajdLI3KSqjVXWDDr4N7Tp2FFHSYufuvVxSJIwRXBT7PSU
tXNQ3SuWl5ES2cOxtW9Mucz6j8i61ohXEmJRRBxw=
To: Richard Myers <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dcn-zTdD8PQxsZoDJtOP90GBPqRXKuCwYkvkOWeoJmArexkFapaA1M_xLONcoM6qTVh7nJCbmBCOvUQYobI_WPbC5deMOgfytSRi1zIgJ_o=@protonmail.com>
In-Reply-To: <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@mail.gmail.com>
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
<CAO3Pvs8rkouxQY912VW04pmn-hdAhMNL_6E_nXDmkeibBegwkA@mail.gmail.com>
<CALZpt+H1OOhrOXUMO7Fn_9Vgx8_sNPAshdd8+euAT_NWgd7uqA@mail.gmail.com>
<CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@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: Mon, 11 May 2020 05:44:16 -0000
Good morning Richard, and all,
> 2) a=C2=A0light client can query an ISP connected full node on the same u=
nmetered local WiFi network and exchange differences in block headers oppor=
tunistically or pay for large missing ranges of headers, filters or full bl=
ocks using a payment channel. Cost is reduced and privacy=C2=A0is enhanced =
for the light client by not using a centralized ISP. Bandwidth for running =
the full node can be amortized=C2=A0and subsidized by payments from light c=
lients who they resell data to.
A relatively pointless observation, but it seems to me that:
* The light client is requesting for validation information, because...
* ...its direct peers might be defrauding it, leading to...
* ...the money it *thinks* it has in its channels being valueless.
Thus, if the light client opportunistically pays for validation information=
(whether full blocks, headers, or filters), the direct peers it has could =
just as easily not forward any payments, thus preventing the light client f=
rom paying for the validation information.
Indeed, if the direct peer *is* defrauding the light client, the direct pee=
r has no real incentive to actually forward *any* payments --- to do so wou=
ld be to reduce the possible earnings it gets from defrauding the light cli=
ent.
("Simulating" the payments so that the light client will not suspect anythi=
ng runs the risk that the light client will be able to forward all its mone=
y out of the channel, and the cheating peer is still potentially liable for=
any funds it originally had in the channel if it gets caught.)
What would work would be to use a system similar to watchtowers, wherein th=
e validation-information-provider is prepaid and issues tokens that can be =
redeemed later.
But this is not suitable for opportunistic on-same-WiFi where, say, a lapto=
p is running a validation-information-provider-for-payment program on the s=
ame WiFi as a light-client mobile phone, if we consider that the laptop and=
mobile may have never met before and may never meet again.
It would work if the laptop altruistically serves the blocks, but not if it=
were for (on-Lightning) payment.
So it seems to me that this kind of service is best ridden on top of watcht=
ower service providers.
Regards,
ZmnSCPxj
|
