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 silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7754DC0175;
Tue, 5 May 2020 13:50:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 6377A203BA;
Tue, 5 May 2020 13:50:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CV9KGF9ecPnc; Tue, 5 May 2020 13:50:07 +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-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by silver.osuosl.org (Postfix) with ESMTPS id 2DC632048D;
Tue, 5 May 2020 13:50:07 +0000 (UTC)
Date: Tue, 05 May 2020 13:49:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1588686604;
bh=MVeDSsT7KMoWbGXXCDB3O8Lpm9YTBRUTj5FMMGp8JX8=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=lYk57nmhvQuJnERNKvt5sODY9h4ZCEjmuS4+5NtQln8L/3uUnzmb2jvYJ9vip2KM2
ihgSI9xMDxDrOBDQFHYujO+7LO4wA+Kl/BeA/Cd4fwHpxoWDJdIONe9i7IZUgcS7+w
BwQkshQCdGgZhmv8p2NeH5mhVkgoNVUtwyDoiJjQ=
To: Luke Dashjr <luke@dashjr.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com>
In-Reply-To: <202005051300.38836.luke@dashjr.org>
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
<202005051300.38836.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<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: Tue, 05 May 2020 13:50:09 -0000
Good morning ariard and luke-jr
> > Trust-minimization of Bitcoin security model has always relied first an=
d
> > above on running a full-node. This current paradigm may be shifted by L=
N
> > where fast, affordable, confidential, censorship-resistant payment serv=
ices
> > 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.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to=
the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are har=
mful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage=
,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP 1=
57 in
> Core.
BIP 157 can be implemented as a separate daemon that processes the blocks d=
ownloaded by an attached `bitcoind`, i.e. what Wasabi does.
The intention, as I understood it, of putting BIP157 directly into bitcoind=
was to essentially force all `bitcoind` users to possibly service BIP157 c=
lients, in the hope that a BIP157 client can contact any arbitrary fullnode=
to get BIP157 service.
This is supposed to improve to the situation relative to e.g. Electrum, whe=
re there are far fewer Electrum servers than fullnodes.
Of course, as ariard computes, deploying BIP157 could lead to an effective =
DDoS on the fullnode network if a large number of BIP157 clients arise.
Though maybe this will not occur very fast? We hope?
It seems to me that the thing that *could* be done would be to have watchto=
wers provide light-client services, since that seems to be the major busine=
ss model of watchtowers, as suggested by ariard as well.
This is still less than ideal, but maybe is better than nothing.
Regards,
ZmnSCPxj
|
