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
138
139
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7501EC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 00:09:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 46207831A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 00:09:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.297
X-Spam-Level:
X-Spam-Status: No, score=0.297 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zNtRamAALbPW
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 00:09:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by smtp1.osuosl.org (Postfix) with ESMTPS id D40FA83192
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 00:09:34 +0000 (UTC)
Date: Tue, 06 Jul 2021 00:09:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1625530172;
bh=MXYToorP26pmq0mkQJtL6AnzQzvK5o+OZFl6uOU5g0U=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=OZs6Zlj+FuJC5FBcSULsGc3jhDeYICaRRZS+6HrMJVipwnmI4N/U9BNs8dn5ZOiat
6kCDsGwP5RgvRf9pAoVsuwxnZ1S2lPPpeOReGZ4yJPVcY+SMnLwsEAZ6bonle0L61V
+dXytJNlZD5pR6xkIycXqoPlRb4amYZxYhHacC7g=
To: Eric Voskuil <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com>
In-Reply-To: <F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org>
References: <cLK-RFlIdmwOvuKag-cOImIVCltq97EWfT-mFpPFa5wJfbAgptlKFhmgt4WQNw2pYVt-sGCCCTtHi1s0Vdwwimun_fUdvrDeOOPnlFjYDdA=@protonmail.com>
<F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org>
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>,
Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Proof of reserves - recording
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, 06 Jul 2021 00:09:36 -0000
Good morning e,
> If only one could prove that he won=E2=80=99t get into a boating accident=
.
At least in the context of Lightning channels, if one party in the channel =
loses its key in a boating accident, the other party (assuming it is a true=
separate person and not a sockpuppet) has every incentive to unilaterally =
close the channel, which reveals the exact amounts (though not necessarily =
who owns which).
If the other party then uses its funds in a new proof-of-reserves, then obv=
iously the other output of the unilateral close was the one lost in the boa=
ting accident.
On the other hand, yes, custodians losing custodied funds in boating accide=
nts is much too common.
I believe it is one reason why custodian proof-of-reserves is not that popu=
lar --- it only proves that the funds were owned under a particular key at =
some snapshot of the past, it does not prove that the key will not get lost=
(or "lost and then salvaged by a scuba diver") later.
Regards,
ZmnSCPxj
>
> e
>
> > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.li=
nuxfoundation.org wrote:
> > Good morning Billy,
> >
> > > I wonder if there would be some way to include the ability to prove b=
alances held on the lightning network, but I suspect that isn't generally p=
ossible.
> >
> > Thinking about this in terms of economic logic:
> > Every channel is anchored onchain, and that anchor (the funding txout) =
is proof of the existence, and size, of the channel.
> > The two participants in the channel can sign a plaintext containing the=
ir node pubkeys and how much each owns.
> > One of the participants should provably be the custodian.
> >
> > - If the counterparty is a true third party, it has no incentive to l=
ie about its money.
> > - Especially if the counterparty is another custodian who wants proof=
-of-reserves, it has every incentive to overreport, but then the first part=
y will refuse to sign.
> > It has a disincentive to underreport, and would itself refuse to si=
gn a dishonest report that assigns more funds to the first party.
> > The only case that would be acceptable to both custodians would be =
to honestly report their holdings in the Lightning channel.
> >
> > - If the counterparty is a sockpuppet of the custodian, then the enti=
re channel is owned by the custodian and it would be fairly dumb of he cust=
odian to claim to have less funds than the entire channel.
> >
> > Perhaps a more practical problem is that Lightning channel states chang=
e fairly quickly, and there are possible race conditions, due to network la=
tency (remember, both nodes need to sign, meaning both of them need to comm=
unicate with each other, thus hit by network latency and other race conditi=
ons) where a custodian Lightning node is unable to "freeze" a snapshot of i=
ts current state and make an atomic proof-of-reserves of all channels.
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
