path: root/ed/06384a4fc59fc9df00ebed25035cc1f4c8cecb

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 648EFC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:03:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 43F2083104
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:03:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 Y76fQAoGm2KK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:03:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [IPv6:2a00:1450:4864:20::532])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3B2D7830E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:03:04 +0000 (UTC)
Received: by mail-ed1-x532.google.com with SMTP id x2so7936963edr.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Jul 2021 23:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=cMjn7BQu0dHigZYtbkhA2fawnz6xNo8Yb6ORJETQ6tE=;
 b=l0zoGjP8KBTBQjzVL8Pe3adr4eFh2JgC3HKTxbMURQyQe6x4MlfV7M4QsXmz7J8+wj
 KRODu6EUoLsC5ngNNm6VVkhH7nkgcrOg8bJ8xdnLr1LrBHzeZRFxal6Znx9KgvYsABDX
 tn+urBNi3HLykLL7IiZu6LATOc1hyZ9/JpS9JUuv1CTIumRqXL+QnxgPQ+gGyz6qV2Vj
 VUCM3w2rNdTQoavtyi38XhC1NE2nKjNK16/qU+Ib3K2XCwti/saw43os+u0/oBNLetyR
 e3waVtnpyxfNVKikgXaCE5wGFYJz//B9xcUsonM42S2XoYVBt9VScVNvoe0aQfdYSIKY
 e7gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=cMjn7BQu0dHigZYtbkhA2fawnz6xNo8Yb6ORJETQ6tE=;
 b=ev1drEx8+UFWPqIq3Oi59fJC2GOIoXP4n86r6X/paW2JBeA73iPK8GnONMbOVlMMyo
 NodNySjeI7Ni1UwI1lIYytnLCgRmoOOptMIQX1PA/2ixbTz99tjfEyGmUUT9QMzKrT/K
 n+8FijC9Va2icjlHMg1edXpl+4xe41jW9mIt8UOSAYviPMowiqLiS1Swt0azfXmWao4q
 9LHTQ4gdy0jlpkNDO7OgI/CyUoUpVJdXvGKryNi5fi7lx4DhSeE4ieWD74Z5qaFJJiXL
 4aRSmiyNsar6ZrSyjPYgdLgOvM4ApP/k5aAAgi7oRux2URFUdhR2nl63Z5iUUVcrOP0i
 hIEA==
X-Gm-Message-State: AOAM532EbaEgl0fW0OYMOUy/1gJhV7yZJX3xzHPUm9+xJ1GAFtk6IMmK
 pRKwwnQjOB8zENNDY3MwSutRwVNoAgntVrBf02aLgDm18bZ0OA==
X-Google-Smtp-Source: ABdhPJxC7o1nGs3uubwoY48S68KT6/5dETns1FlW+rWKfo60ZB+YLIwY4RfRGgPRPcEnlEDMvwptaABOW/yhuA5+gNs=
X-Received: by 2002:a05:6402:4388:: with SMTP id
 o8mr3245447edc.338.1625551382226; 
 Mon, 05 Jul 2021 23:03:02 -0700 (PDT)
MIME-Version: 1.0
References: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com>
 <EC55B6BD-2BDD-4074-A813-459D73D89DB2@voskuil.org>
In-Reply-To: <EC55B6BD-2BDD-4074-A813-459D73D89DB2@voskuil.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 5 Jul 2021 23:02:45 -0700
Message-ID: <CAGpPWDaSVFAqvmfCugLCE2X2fSz0dRos76FejFutA1=dF+R2zw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="000000000000b3ac1e05c66e2c16"
X-Mailman-Approved-At: Tue, 06 Jul 2021 08:35:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 06:03:06 -0000

--000000000000b3ac1e05c66e2c16
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@ZmnSCPxj
>  a thief (or "thief") who has gotten a copy of the key can sign a
transaction that spends it, one second after the proof-of-reserves is made.

Sure, but anyone can easily see that transaction happen and can discount
that part of the attestation. The same isn't true on lightning.

> *knowledge* is easily copyable.

Knowledge isn't even really needed. Custodians could collude to sign each
other's balance attestations. However, if the network of proof of reserves
is cohesive, people could validate that addresses (and their balances)
aren't shared by anyone that's part of that PoR network.

> There is no way to prove that there is no alternate copy of the privkeys

Well there are only really 2 cases:

1. Only one entity has the keys
2. Two entities have the keys and trust each other

In case 1, the attestation is accurate. In case 2, its really another way
of saying case 1: you can view the two trusting entities as a single
entity. In the case there are 2 non-trusting entities, its very likely that
one would steal from the other, or that they would be very uncomfortable
with the situation such that it wouldn't last long.

But you can't prove that someone won't steal the reserves. You can't prove
cryptographically that the reserves aren't promised to someone else in a
legal contract (unless of course you make the proof of reserves system
legally binding). But this is why anyone that recommends PoR also
recommends independent audits to attest that the PoR actually matches
reality.

So yes, there are limitations, but I don't think that means that PoR isn't
worth doing. Is that what you're implying?

> we can show evidence that we live in a landlocked city far from any
lakes, seas, or rivers

I think that's the idea, if I understand you correctly.

@Eric
Auditability Fallacy
<https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy>

> A solvency audit requires simultaneous (atomic) proof of both the full
amount of the asset held by a custodian and the securities issued against
it.

> in the case where the security is issued on a distinct public chain the
atomicity requirement is not satisfied.

I think what its saying is that you can't get atomicity of both the
security and the reserve. While this is true, what you can get is a system
where the order of events can be established to a degree of precision. Ie,
you can know that between reserve-snapshot A and B, the balances add up to
X. Each user can validate that their balance was indeed that value between
A and B. With reserve snapshots and balance snapshots frequent enough, this
can allow reasonably high accuracy of estimated solvency. However, it does
seem clear that perfect accuracy is not possible.

> Historically it has not been difficult to detect such deviations. The
difficulty arises in stopping them.

I disagree here that it has not been difficult to detect deviations
(insolvency). I mean, "difficulty" isn't the right word. These things
always become clear eventually. But I think its important to detect
insolvency quickly. Historically insolvency has certainly not been detected
quickly. Insolvency is instead practically perpetual, and the question is
only how insolvent and when will it explode?

I'm of the opinion that you can't prevent insolvency. Places will have
money troubles and will try to cover it up, since usually there is no
downside (admitting insolvency can lead to bankrupcy, and failure to
conceal insolvency has the same result - so why not try to conceal it and
hope you can shore it up). However, its important that people know the
institutions they have their money in are insolvent, or to what degree they
are. If that information were well tracked, it could become clear over time
that a 10% insolvent company rarely goes out of business, but a 20%
insolvent company usually does. Then people can have parameters where
they're ok with a certain measurable degree of insolvency, but react
swiftly and strongly when a company is too reckless. Currently the amount
of recklessness any given company engages in is basically a company secret
that their clients don't have insight into. PoR would greatly help this I
think. You don't think so?

On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric@voskuil.org> wrote:

> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>
> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> =EF=BB=BFGood morning Billy,
>
>
>
>   The two participants in the channel can sign a plaintext containing
> their node pubkeys and how much each owns
>
>
> Sure, but even if both participants in the channel sign a correct
> statement of truth, one of the participants can send funds out in the nex=
t
> second, invalidating that truth. While proof of ownership of on-chain UTX=
Os
> can be seen publicly in real time if they are spent, LN transactions aren=
't
> public like that. So any balance attestation is at best only valid the
> instant its taken, and can't be used as verification the money is still
> owned by the same channel partner in the next second.
>
>
> The same problem really also exists onchain --- a thief (or "thief") who
> has gotten a copy of the key can sign a transaction that spends it, one
> second after the proof-of-reserves is made.
>
> Really, though, the issue is that ownership of funds is conditional on
> *knowledge* of keys.
> And *knowledge* is easily copyable.
>
> Thus, it is possible that the funds that are "proven" to be the reserve o=
f
> a custodian is actually *also* owned by someone else who has gotten to th=
e
> privkeys (e.g. somebody threw a copy of it from a boating accident and a
> fearless scuba diver rescued it), and thus can also move the funds outsid=
e
> of the control of the custodian.
> This condition can remain for many months or years, as well, without
> knowledge of the custodian clients, *or* of the custodian itself.
>
> There is no way to prove that there is no alternate copy of the privkeys,
> hence "if only one could prove that he won't get into a boating accident"=
.
>
> On the other hand, one could argue that at least the onchain proof
> requires more conditions to occur, so we might plausibly live with "we
> cannot prove we will never get into a boating accident but we can show
> evidence that we live in a landlocked city far from any lakes, seas, or
> rivers".
>
> Regards,
> ZmnSCPxj
>
>
>   a custodian Lightning node is unable to "freeze" a snapshot of its
> current state and make an atomic proof-of-reserves of *all* channels
>
>
> That would be a neat trick. But yeah, I don't know how that would be
> possible.
>
>
>   I believe it is one reason why custodian proof-of-reserves is not that
> popular ... it does not prove that the key will not get lost
>
>
> True, but at least if funds do get lost, it would be come clear far
> quicker. Today, an insolvent company could go many months without the
> public finding out.
>
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>
> 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 channe=
l
> loses its key in a boating accident, the other party (assuming it is a tr=
ue
> separate person and not a sockpuppet) has every incentive to unilaterally
> close the channel, which reveals the exact amounts (though not necessaril=
y
> who owns which).
>
> If the other party then uses its funds in a new proof-of-reserves, then
> obviously the other output of the unilateral close was the one lost in th=
e
> boating accident.
>
>
> On the other hand, yes, custodians losing custodied funds in boating
> accidents is much too common.
>
> I believe it is one reason why custodian proof-of-reserves is not that
> popular --- it only proves that the funds were owned under a particular k=
ey
> 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.linuxfoundation.org wrote:
>
> Good morning Billy,
>
>
> I wonder if there would be some way to include the ability to prove
> balances held on the lightning network, but I suspect that isn't generall=
y
> possible.
>
>
> 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 their
> 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 lie
> about its money.
>
> -   Especially if the counterparty is another custodian who wants
> proof-of-reserves, it has every incentive to overreport, but then the fir=
st
> party will refuse to sign.
>
>      It has a disincentive to underreport, and would itself refuse to sig=
n
> a dishonest report that assigns more funds to the first party.
>
>      The only case that would be acceptable to both custodians would be t=
o
> honestly report their holdings in the Lightning channel.
>
>
> -   If the counterparty is a sockpuppet of the custodian, then the entire
> channel is owned by the custodian and it would be fairly dumb of he
> custodian to claim to have less funds than the entire channel.
>
>
> Perhaps a more practical problem is that Lightning channel states change
> fairly quickly, and there are possible race conditions, due to network
> latency (remember, both nodes need to sign, meaning both of them need to
> communicate with each other, thus hit by network latency and other race
> conditions) where a custodian Lightning node is unable to "freeze" a
> snapshot of its 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
>
>
>
>

--000000000000b3ac1e05c66e2c16
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>@ZmnSCPxj<br></div>&gt;=C2=A0

a thief (or &quot;thief&quot;) who has gotten a copy of the key can sign a =
transaction that spends it, one second after the proof-of-reserves is made.=
<div><br></div><div>Sure, but anyone can easily see that transaction happen=
 and can discount that part of the attestation. The same isn&#39;t true on =
lightning.</div><div><br></div><div>&gt; *knowledge* is easily copyable.</d=
iv><div><br></div><div>Knowledge isn&#39;t even really needed. Custodians c=
ould collude to sign each other&#39;s balance attestations. However, if the=
 network of proof of reserves is cohesive, people could validate that addre=
sses (and their balances) aren&#39;t shared by anyone that&#39;s part of th=
at PoR network.=C2=A0</div><div><br></div><div>&gt; There is no way to prov=
e that there is no alternate copy of the privkeys</div><div><br></div><div>=
Well there are only really 2 cases:</div><div><br></div><div>1. Only one en=
tity has the keys</div><div>2. Two entities have the keys and trust each ot=
her</div><div><br></div><div>In case 1, the attestation is accurate. In cas=
e 2, its really another way of saying case 1: you can view the two trusting=
 entities as a single entity. In the case there are 2 non-trusting entities=
, its very likely that one would steal from the other, or that they would b=
e very uncomfortable with the situation such that it wouldn&#39;t last long=
.=C2=A0</div><div><br></div><div>But you can&#39;t prove that someone won&#=
39;t steal the reserves. You can&#39;t prove cryptographically that the res=
erves aren&#39;t promised to someone else in a legal contract (unless of co=
urse you make the proof of reserves system legally binding). But this is wh=
y anyone that recommends PoR also recommends independent audits to attest t=
hat the PoR actually matches reality.=C2=A0</div><div><br></div><div>So yes=
, there are limitations, but I don&#39;t think that means that PoR isn&#39;=
t worth doing. Is that what you&#39;re implying?</div><div><br></div><div>&=
gt; we can show evidence that we live in a landlocked city far from any lak=
es, seas, or rivers</div><div><br></div><div>I think that&#39;s the idea, i=
f I understand you correctly.=C2=A0</div><div><br></div><div>@Eric</div><a =
href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-F=
allacy">Auditability Fallacy</a><div><br></div><div>&gt;=C2=A0A solvency au=
dit requires simultaneous (atomic) proof of both the full amount of the ass=
et held by a custodian and the securities issued against it.</div><div><br>=
</div>&gt; in the case where the security is issued on a distinct public ch=
ain the atomicity requirement is not satisfied.<br><div><br></div><div>I th=
ink what its saying is that you can&#39;t get atomicity of both the securit=
y and the reserve. While this is true, what you can get is a system where t=
he order of events can be established to a degree of precision. Ie, you can=
 know that between reserve-snapshot A and B, the balances add up to X. Each=
 user can validate that their balance was indeed that value between A and B=
. With reserve snapshots and balance snapshots frequent enough, this can al=
low reasonably high accuracy of estimated solvency. However, it does seem c=
lear that perfect accuracy is not possible.=C2=A0</div><div><br></div><div>=
&gt;=C2=A0Historically it has not been difficult to detect such deviations.=
 The difficulty arises in stopping them.<br></div><div><br></div><div>I dis=
agree here that it has not been difficult to detect deviations (insolvency)=
. I mean, &quot;difficulty&quot; isn&#39;t the right word. These things alw=
ays become clear eventually. But I think its important to detect insolvency=
 quickly. Historically insolvency has certainly not been detected quickly. =
Insolvency is instead practically perpetual, and the question is only how i=
nsolvent and when will it explode?=C2=A0</div><div><br></div><div>I&#39;m o=
f the opinion that you can&#39;t prevent insolvency. Places will have money=
 troubles and will try to cover it up, since usually there is no downside (=
admitting insolvency can lead to bankrupcy, and failure to conceal insolven=
cy has the same result - so why not try to conceal it and hope you can shor=
e it up). However, its important that people know the institutions they hav=
e their money in are insolvent, or to what degree they are. If that informa=
tion were well tracked, it could become clear over time that a 10% insolven=
t company rarely goes out of business, but a 20% insolvent company usually =
does. Then people can have parameters where they&#39;re ok with a certain m=
easurable degree of insolvency, but react swiftly and strongly when a compa=
ny is too reckless. Currently the amount of recklessness any given company =
engages in is basically a company secret that their clients don&#39;t have =
insight into. PoR would greatly help this I think. You don&#39;t think so?=
=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil &lt;<a href=3D"mai=
lto:eric@voskuil.org">eric@voskuil.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"><a=
 href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-=
Fallacy" target=3D"_blank">https://github.com/libbitcoin/libbitcoin-system/=
wiki/Auditability-Fallacy</a></div><div dir=3D"ltr"><br><blockquote type=3D=
"cite">On Jul 5, 2021, at 21:54, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@pr=
otonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br><=
br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<=
span>Good morning Billy,</span><br><span></span><br><span></span><br><block=
quote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"=
><blockquote type=3D"cite"><span>=C2=A0 The two participants in the channel=
 can sign a plaintext containing their node pubkeys and how much each owns<=
/span><br></blockquote></blockquote><blockquote type=3D"cite"><span></span>=
<br></blockquote><blockquote type=3D"cite"><span>Sure, but even if both par=
ticipants in the channel sign a correct statement of truth, one of the part=
icipants can send funds out in the next second, invalidating that truth. Wh=
ile proof of ownership of on-chain UTXOs can be seen publicly in real time =
if they are spent, LN transactions aren&#39;t public like that. So any bala=
nce attestation is at best only valid the instant its taken, and can&#39;t =
be used as verification the money is still owned by the same channel partne=
r in the next second.=C2=A0</span><br></blockquote><span></span><br><span>T=
he same problem really also exists onchain --- a thief (or &quot;thief&quot=
;) who has gotten a copy of the key can sign a transaction that spends it, =
one second after the proof-of-reserves is made.</span><br><span></span><br>=
<span>Really, though, the issue is that ownership of funds is conditional o=
n *knowledge* of keys.</span><br><span>And *knowledge* is easily copyable.<=
/span><br><span></span><br><span>Thus, it is possible that the funds that a=
re &quot;proven&quot; to be the reserve of a custodian is actually *also* o=
wned by someone else who has gotten to the privkeys (e.g. somebody threw a =
copy of it from a boating accident and a fearless scuba diver rescued it), =
and thus can also move the funds outside of the control of the custodian.</=
span><br><span>This condition can remain for many months or years, as well,=
 without knowledge of the custodian clients, *or* of the custodian itself.<=
/span><br><span></span><br><span>There is no way to prove that there is no =
alternate copy of the privkeys, hence &quot;if only one could prove that he=
 won&#39;t get into a boating accident&quot;.</span><br><span></span><br><s=
pan>On the other hand, one could argue that at least the onchain proof requ=
ires more conditions to occur, so we might plausibly live with &quot;we can=
not prove we will never get into a boating accident but we can show evidenc=
e that we live in a landlocked city far from any lakes, seas, or rivers&quo=
t;.</span><br><span></span><br><span>Regards,</span><br><span>ZmnSCPxj</spa=
n><br><span></span><br><blockquote type=3D"cite"><span></span><br></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>=C2=A0 a cust=
odian Lightning node is unable to &quot;freeze&quot; a snapshot of its curr=
ent state and make an atomic proof-of-reserves of *all* channels</span><br>=
</blockquote></blockquote><blockquote type=3D"cite"><span></span><br></bloc=
kquote><blockquote type=3D"cite"><span>That would be a neat trick. But yeah=
, I don&#39;t know how that would be possible.=C2=A0</span><br></blockquote=
><blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=
=3D"cite"><blockquote type=3D"cite"><span>=C2=A0 I believe it is one reason=
 why custodian proof-of-reserves is not that popular ... it does not prove =
that the key will not get lost</span><br></blockquote></blockquote><blockqu=
ote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><=
span>True, but at least if funds do get lost, it would be come clear far qu=
icker. Today, an insolvent company could go many months without the public =
finding out.=C2=A0</span><br></blockquote><blockquote type=3D"cite"><span><=
/span><br></blockquote><blockquote type=3D"cite"><span>On Mon, Jul 5, 2021 =
at 5:09 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=
=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:</span><br></blockquote><=
blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"=
cite"><blockquote type=3D"cite"><span>Good morning e,</span><br></blockquot=
e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span></=
span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>If only one could prove that he=
 won=E2=80=99t get into a boating accident.</span><br></blockquote></blockq=
uote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span=
></span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><span>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 incen=
tive to unilaterally close the channel, which reveals the exact amounts (th=
ough not necessarily who owns which).</span><br></blockquote></blockquote><=
blockquote type=3D"cite"><blockquote type=3D"cite"><span>If the other party=
 then uses its funds in a new proof-of-reserves, then obviously the other o=
utput of the unilateral close was the one lost in the boating accident.</sp=
an><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=
=3D"cite"><span></span><br></blockquote></blockquote><blockquote type=3D"ci=
te"><blockquote type=3D"cite"><span>On the other hand, yes, custodians losi=
ng custodied funds in boating accidents is much too common.</span><br></blo=
ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><s=
pan>I believe it is one reason why custodian proof-of-reserves is not that =
popular --- 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 &quot;lost and then salvaged by a scuba diver&quot;) later.</span>=
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D=
"cite"><span></span><br></blockquote></blockquote><blockquote type=3D"cite"=
><blockquote type=3D"cite"><span>Regards,</span><br></blockquote></blockquo=
te><blockquote type=3D"cite"><blockquote type=3D"cite"><span>ZmnSCPxj</span=
><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=
=3D"cite"><span></span><br></blockquote></blockquote><blockquote type=3D"ci=
te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></=
blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>e</span><br></blockquote></bl=
ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><=
blockquote type=3D"cite"><span></span><br></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=
=3D"cite"><blockquote type=3D"cite"><span>On Jul 5, 2021, at 16:26, ZmnSCPx=
j via bitcoin-dev <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a> wrote:</span><b=
r></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=
=3D"cite"><span>Good morning Billy,</span><br></blockquote></blockquote></b=
lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">=
<blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></bloc=
kquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">=
<blockquote type=3D"cite"><span>I wonder if there would be some way to incl=
ude the ability to prove balances held on the lightning network, but I susp=
ect that isn&#39;t generally possible.</span><br></blockquote></blockquote>=
</blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span><=
/span><br></blockquote></blockquote></blockquote></blockquote><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquot=
e type=3D"cite"><span>Thinking about this in terms of economic logic:</span=
><br></blockquote></blockquote></blockquote></blockquote><blockquote type=
=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><span>Every channel is anchored onchain, and that anchor (the =
funding txout) is proof of the existence, and size, of the channel.</span><=
br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"=
cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=
=3D"cite"><span>The two participants in the channel can sign a plaintext co=
ntaining their node pubkeys and how much each owns.</span><br></blockquote>=
</blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>O=
ne of the participants should provably be the custodian.</span><br></blockq=
uote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bloc=
kquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s=
pan></span><br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc=
kquote type=3D"cite"><span>-=C2=A0 =C2=A0If the counterparty is a true thir=
d party, it has no incentive to lie about its money.</span><br></blockquote=
></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>=
-=C2=A0 =C2=A0Especially if the counterparty is another custodian who wants=
 proof-of-reserves, it has every incentive to overreport, but then the firs=
t party will refuse to sign.</span><br></blockquote></blockquote></blockquo=
te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><span>=C2=A0 =C2=A0 =C2=A0It h=
as a disincentive to underreport, and would itself refuse to sign a dishone=
st report that assigns more funds to the first party.</span><br></blockquot=
e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span=
>=C2=A0 =C2=A0 =C2=A0The only case that would be acceptable to both custodi=
ans would be to honestly report their holdings in the Lightning channel.</s=
pan><br></blockquote></blockquote></blockquote></blockquote><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blo=
ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><span>-=C2=A0 =C2=A0If the counterpart=
y is a sockpuppet of the custodian, then the entire channel is owned by the=
 custodian and it would be fairly dumb of he custodian to claim to have les=
s funds than the entire channel.</span><br></blockquote></blockquote></bloc=
kquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockqu=
ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><block=
quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><sp=
an>Perhaps a more practical problem is that Lightning channel states change=
 fairly quickly, and there are possible race conditions, due to network lat=
ency (remember, both nodes need to sign, meaning both of them need to commu=
nicate with each other, thus hit by network latency and other race conditio=
ns) where a custodian Lightning node is unable to &quot;freeze&quot; a snap=
shot of its current state and make an atomic proof-of-reserves of all chann=
els.</span><br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc=
kquote type=3D"cite"><span>Regards,</span><br></blockquote></blockquote></b=
lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite">=
<blockquote type=3D"cite"><blockquote type=3D"cite"><span>ZmnSCPxj</span><b=
r></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=
=3D"cite"><span></span><br></blockquote></blockquote></blockquote></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>bitcoin-dev mailing list</span><br><=
/blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite=
"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a></span><br></blockquot=
e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span=
><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev</a></span><br></blockquote></blockquote></blockquote></blockquote><s=
pan></span><br><span></span><br></div></blockquote></div></blockquote></div=
>

--000000000000b3ac1e05c66e2c16--