path: root/21/761b2b64d75fb8c21cf511f8914a80e004e428

Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AD07BC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 07:37:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7BF45403AD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 07:37:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7Brk2N5HGmTG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 07:37:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com
 [IPv6:2607:f8b0:4864:20::433])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 10879403A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 07:37:09 +0000 (UTC)
Received: by mail-pf1-x433.google.com with SMTP id f17so7165564pfj.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 06 Jul 2021 00:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=mig2722bYDx+1U/REoiV6mf7xoRuMguxEv5XAphbJeM=;
 b=zlOIxOxJAag8bR7QmfPzgmx7KFCHcsh7JQUxzrxuxHpyCoOGq/5YWrNcImogd2161k
 xoULA99lxzN9CNhgskqc/FOZAfI+y5SHgFQjiHKB3J0s9o0Wjmu/fleN2NQATfbpae9D
 5hjnUvV2OfMKHbsMbeLeO1Mzt3ToTGrlr43l0Yag4acILKEAQp4qIISLBF/qFVc4wU92
 vf56T/GaN2yoyyokjEnJZU4quKG8Z5SzeBGnqhpHK6BB1eKrKvL6M4R0mwPhJSCK4YQ6
 cIkGa/FH5qZwTCzZl2YEEFa5eStd1W1zpuL/O6jDIx/fBSIDJPE5zMHSb5OBnfU2TlOr
 6Szg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=mig2722bYDx+1U/REoiV6mf7xoRuMguxEv5XAphbJeM=;
 b=T8l2i+9jOnhhuioqnbVOSrq0N153VrH/lJoIKWXlc0n+r/AJFlN0p7PCBCTdRz6tnN
 B5AzPnvYWN4n+h88WnjFc+2LmkTX775uZBUooySx6A1wSaPsQq7hdIjwDRloF+30kjZE
 TEcnL69Q83NaR9b3y8hC/DYMNZhqrO4eeQ2nqoUpL70ta9gK2Go2Q2b7kUP0F2gUUKEF
 zB9T/bw9RY/e8sKp4EWbZvm8PjR9E/lXk9wHE/E19DJv21PpQDg0LE181DJcusxUY7Aq
 fYhD935YNkNH4kNgvhBiDUsMTJR9WzB/XNLbkrl0LyJgmodeXb6JlfDoh9rfZu+pVBzf
 dCfQ==
X-Gm-Message-State: AOAM531Nb5cZ/yx38v2wVNbvIdTYCa0B5NfiASeDhpC2Pa/H/Wi/U1e8
 piv2Uf6umlNT/pOYOLfpOWT2uQ==
X-Google-Smtp-Source: ABdhPJxTvZg8c8KP9Z9awzrZOo+jBXgZpHjaOcIUwmzXizSiuSCtKCQWMyQd+7Q3p5zgmZmXgeXC3w==
X-Received: by 2002:a63:1a45:: with SMTP id a5mr19850267pgm.418.1625557029144; 
 Tue, 06 Jul 2021 00:37:09 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::7844])
 by smtp.gmail.com with ESMTPSA id e18sm10708590pfc.85.2021.07.06.00.37.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 Jul 2021 00:37:08 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-E1A554DE-66B3-4372-8779-401FCF03B481
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 6 Jul 2021 00:37:07 -0700
Message-Id: <F66EEF92-AAA3-4BBB-B6E2-30D3A2939D17@voskuil.org>
References: <CAGpPWDaSVFAqvmfCugLCE2X2fSz0dRos76FejFutA1=dF+R2zw@mail.gmail.com>
In-Reply-To: <CAGpPWDaSVFAqvmfCugLCE2X2fSz0dRos76FejFutA1=dF+R2zw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
X-Mailer: iPhone Mail (18F72)
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 07:37:12 -0000


--Apple-Mail-E1A554DE-66B3-4372-8779-401FCF03B481
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> @Eric
> Auditability Fallacy
>=20
> > A solvency audit requires simultaneous (atomic) proof of both the full a=
mount of the asset held by a custodian and the securities issued against it.=

>=20
> > in the case where the security is issued on a distinct public chain the a=
tomicity requirement is not satisfied.
>=20
> I think what its saying is that you can't get atomicity of both the securi=
ty 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 k=
now that between reserve-snapshot A and B, the balances add up to X. Each us=
er can validate that their balance was indeed that value between A and B. Wi=
th reserve snapshots and balance snapshots frequent enough, this can allow r=
easonably high accuracy of estimated solvency. However, it does seem clear t=
hat perfect accuracy is not possible.

If perfect is not possible, it=E2=80=99s not possible. It reduces to trust, w=
hich is the status quo.

All =E2=80=9Cusers=E2=80=9D need to simultaneously share their individual an=
d temporary audits with each other (ie publicly).

> > Historically it has not been difficult to detect such deviations. The di=
fficulty arises in stopping them.
>=20
> I disagree here that it has not been difficult to detect deviations (insol=
vency).

It is not hard to spot price inflation. Stopping or avoiding it is the actua=
l issue. No =E2=80=9Cproof=E2=80=9D of reserve can do this. The federal rese=
rve was clearly insolvent from its early days, as that was its purpose.

> I mean, "difficulty" isn't the right word. These things always become clea=
r eventually. But I think its important to detect insolvency quickly. Histor=
ically insolvency has certainly not been detected quickly. Insolvency is ins=
tead practically perpetual, and the question is only how insolvent and when w=
ill it explode?

There is no =E2=80=9Cproof=E2=80=9D that answers this question.

> I'm of the opinion that you can't prevent insolvency.

It=E2=80=99s not a matter of opinion. Lending implies risk. When you invest y=
ou are in fact the owner of the insolvency, not someone else.

> 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 failu=
re to conceal insolvency has the same result - so why not try to conceal it a=
nd hope you can shore it up). However, its important that people know the in=
stitutions they have their money in are insolvent, or to what degree they ar=
e. If that information were well tracked, it could become clear over time th=
at a 10% insolvent company rarely goes out of business, but a 20% insolvent c=
ompany usually does.

Nonsense, any business can fail, regardless of temporal cash reserves.

> 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 r=
eckless. Currently the amount of recklessness any given company engages in i=
s basically a company secret that their clients don't have insight into. PoR=
 would greatly help this I think. You don't think so?=20

Reckless is a subjective term. Proofs will not insure any investment.

e

>> On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric@voskuil.org> wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy=

>>=20
>>>> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>>=20
>>> =EF=BB=BFGood morning Billy,
>>>=20
>>>=20
>>>>=20
>>>>>   The two participants in the channel can sign a plaintext containing t=
heir node pubkeys and how much each owns
>>>>=20
>>>> Sure, but even if both participants in the channel sign a correct state=
ment of truth, one of the participants can send funds out in the next second=
, invalidating that truth. While proof of ownership of on-chain UTXOs 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 sa=
me channel partner in the next second.=20
>>>=20
>>> 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 sec=
ond after the proof-of-reserves is made.
>>>=20
>>> Really, though, the issue is that ownership of funds is conditional on *=
knowledge* of keys.
>>> And *knowledge* is easily copyable.
>>>=20
>>> 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 the=
 privkeys (e.g. somebody threw a copy of it from a boating accident and a fe=
arless scuba diver rescued it), and thus can also move the funds outside of t=
he control of the custodian.
>>> This condition can remain for many months or years, as well, without kno=
wledge of the custodian clients, *or* of the custodian itself.
>>>=20
>>> 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".=

>>>=20
>>> On the other hand, one could argue that at least the onchain proof requi=
res more conditions to occur, so we might plausibly live with "we cannot pro=
ve we will never get into a boating accident but we can show evidence that w=
e live in a landlocked city far from any lakes, seas, or rivers".
>>>=20
>>> Regards,
>>> ZmnSCPxj
>>>=20
>>>>=20
>>>>>   a custodian Lightning node is unable to "freeze" a snapshot of its c=
urrent state and make an atomic proof-of-reserves of *all* channels
>>>>=20
>>>> That would be a neat trick. But yeah, I don't know how that would be po=
ssible.=20
>>>>=20
>>>>>   I believe it is one reason why custodian proof-of-reserves is not th=
at popular ... it does not prove that the key will not get lost
>>>>=20
>>>> True, but at least if funds do get lost, it would be come clear far qui=
cker. Today, an insolvent company could go many months without the public fi=
nding out.=20
>>>>=20
>>>>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrot=
e:
>>>>>=20
>>>>> Good morning e,
>>>>>=20
>>>>>> If only one could prove that he won=E2=80=99t get into a boating acci=
dent.
>>>>>=20
>>>>> At least in the context of Lightning channels, if one party in the cha=
nnel loses its key in a boating accident, the other party (assuming it is a t=
rue separate person and not a sockpuppet) has every incentive to unilaterall=
y 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, the=
n obviously the other output of the unilateral close was the one lost in the=
 boating accident.
>>>>>=20
>>>>> On the other hand, yes, custodians losing custodied funds in boating a=
ccidents 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 key=
 at some snapshot of the past, it does not prove that the key will not get l=
ost (or "lost and then salvaged by a scuba diver") later.
>>>>>=20
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>=20
>>>>>>=20
>>>>>> e
>>>>>>=20
>>>>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists=
.linuxfoundation.org wrote:
>>>>>>> Good morning Billy,
>>>>>>>=20
>>>>>>>> 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 generally p=
ossible.
>>>>>>>=20
>>>>>>> Thinking about this in terms of economic logic:
>>>>>>> Every channel is anchored onchain, and that anchor (the funding txou=
t) is proof of the existence, and size, of the channel.
>>>>>>> The two participants in the channel can sign a plaintext containing t=
heir node pubkeys and how much each owns.
>>>>>>> One of the participants should provably be the custodian.
>>>>>>>=20
>>>>>>> -   If the counterparty is a true third party, it has no incentive t=
o lie about its money.
>>>>>>> -   Especially if the counterparty is another custodian who wants pr=
oof-of-reserves, it has every incentive to overreport, but then the first pa=
rty will refuse to sign.
>>>>>>>      It has a disincentive to underreport, and would itself refuse t=
o sign 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.
>>>>>>>=20
>>>>>>> -   If the counterparty is a sockpuppet of the custodian, then the e=
ntire channel is owned by the custodian and it would be fairly dumb of he cu=
stodian to claim to have less funds than the entire channel.
>>>>>>>=20
>>>>>>> Perhaps a more practical problem is that Lightning channel states ch=
ange fairly quickly, and there are possible race conditions, due to network l=
atency (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 conditio=
ns) 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
>>>>>>>=20
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>>>=20

--Apple-Mail-E1A554DE-66B3-4372-8779-401FCF03B481
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
><br><blockquote type=3D"cite">@Eric</blockquote></div><blockquote type=3D"c=
ite"><div dir=3D"ltr"><div dir=3D"ltr"><a href=3D"https://github.com/libbitc=
oin/libbitcoin-system/wiki/Auditability-Fallacy">Auditability Fallacy</a><di=
v><br></div><div>&gt;&nbsp;A solvency audit requires simultaneous (atomic) p=
roof of both the full amount of the asset held by a custodian and the securi=
ties issued against it.</div><div><br></div>&gt; in the case where the secur=
ity is issued on a distinct public chain the atomicity requirement is not sa=
tisfied.<br><div><br></div><div>I think what its saying is that you can't ge=
t atomicity of both the security and the reserve. While this is true, what y=
ou can get is a system where the order of events can be established to a deg=
ree of precision. Ie, you can know that between reserve-snapshot A and B, th=
e 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 fr=
equent enough, this can allow reasonably high accuracy of estimated solvency=
. However, it does seem clear that perfect accuracy is not possible.</div></=
div></div></blockquote><div><br></div><div>If perfect is not possible, it=E2=
=80=99s not possible. It reduces to trust, which is the status quo.</div><di=
v><br></div><div>All =E2=80=9Cusers=E2=80=9D need to simultaneously share th=
eir individual and temporary audits with each other (ie publicly).</div><div=
><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div>=
&gt;&nbsp;Historically it has not been difficult to detect such deviations. T=
he difficulty arises in stopping them.<br></div><div><br></div><div>I disagr=
ee here that it has not been difficult to detect deviations (insolvency).</d=
iv></div></div></blockquote><div><br></div><div>It is not hard to spot price=
 inflation. Stopping or avoiding it is the actual issue. No =E2=80=9Cproof=E2=
=80=9D of reserve can do this. The federal reserve was clearly insolvent fro=
m its early days, as that was its purpose.</div><br><blockquote type=3D"cite=
"><div dir=3D"ltr"><div dir=3D"ltr"><div>I mean, "difficulty" isn't the righ=
t word. These things always become clear eventually. But I think its importa=
nt to detect insolvency quickly. Historically insolvency has certainly not b=
een detected quickly. Insolvency is instead practically perpetual, and the q=
uestion is only how insolvent and when will it explode?</div></div></div></b=
lockquote><div><br></div><div>There is no =E2=80=9Cproof=E2=80=9D that answe=
rs this question.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div>I'm of the opinion that you can't prevent insolvency.</div><=
/div></div></blockquote><div><br></div><div>It=E2=80=99s not a matter of opi=
nion. Lending implies risk. When you invest you are in fact the owner of the=
 insolvency, not someone else.</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div dir=3D"ltr"><div>Places will have money troubles and will try to c=
over it up, since usually there is no downside (admitting insolvency can lea=
d to bankrupcy, and failure to conceal insolvency has the same result - so w=
hy not try to conceal it and hope you can shore it up). However, its importa=
nt 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 busi=
ness, but a 20% insolvent company usually does.</div></div></div></blockquot=
e><div><br></div><div>Nonsense, any business can fail, regardless of tempora=
l cash reserves.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div di=
r=3D"ltr"><div> Then people can have parameters where they're ok with a cert=
ain measurable degree of insolvency, but react swiftly and strongly when a c=
ompany is too reckless. Currently the amount of recklessness any given compa=
ny engages in is basically a company secret that their clients don't have in=
sight into. PoR would greatly help this I think. You don't think so?&nbsp;</=
div></div></div></blockquote><div><br></div><div>Reckless is a subjective te=
rm. Proofs will not insure any investment.</div><div><br></div><div>e</div><=
br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 5, 2021 at 10:10 PM Eric Vosk=
uil &lt;<a href=3D"mailto: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 solid 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/l=
ibbitcoin-system/wiki/Auditability-Fallacy</a></div><div dir=3D"ltr"><br><bl=
ockquote type=3D"cite">On Jul 5, 2021, at 21:54, ZmnSCPxj &lt;<a href=3D"mai=
lto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&g=
t; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"lt=
r">=EF=BB=BF<span>Good morning Billy,</span><br><span></span><br><span></spa=
n><br><blockquote type=3D"cite"><span></span><br></blockquote><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>&nbsp; The two participants in t=
he channel can sign a plaintext containing their node pubkeys and how much e=
ach owns</span><br></blockquote></blockquote><blockquote type=3D"cite"><span=
></span><br></blockquote><blockquote type=3D"cite"><span>Sure, but even if b=
oth participants in the channel sign a correct statement of truth, one of th=
e participants can send funds out in the next second, invalidating that trut=
h. While proof of ownership of on-chain UTXOs can be seen publicly in real t=
ime if they are spent, LN transactions aren't public like that. So any balan=
ce attestation is at best only valid the instant its taken, and can't be use=
d as verification the money is still owned by the same channel partner in th=
e next second.&nbsp;</span><br></blockquote><span></span><br><span>The same p=
roblem really also exists onchain --- a thief (or "thief") who has gotten a c=
opy of the key can sign a transaction that spends it, one second after the p=
roof-of-reserves is made.</span><br><span></span><br><span>Really, though, t=
he issue is that ownership of funds is conditional on *knowledge* of keys.</=
span><br><span>And *knowledge* is easily copyable.</span><br><span></span><b=
r><span>Thus, it is possible that the funds that are "proven" to be the rese=
rve of a custodian is actually *also* owned by someone else who has gotten t=
o 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 outsid=
e 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 clien=
ts, *or* of the custodian itself.</span><br><span></span><br><span>There is n=
o way to prove that there is no alternate copy of the privkeys, hence "if on=
ly one could prove that he won't get into a boating accident".</span><br><sp=
an></span><br><span>On the other hand, one could argue that at least the onc=
hain proof requires more conditions to occur, so we might plausibly live wit=
h "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 riv=
ers".</span><br><span></span><br><span>Regards,</span><br><span>ZmnSCPxj</sp=
an><br><span></span><br><blockquote type=3D"cite"><span></span><br></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>&nbsp; a custo=
dian Lightning node is unable to "freeze" a snapshot of its current state an=
d make an atomic proof-of-reserves of *all* channels</span><br></blockquote>=
</blockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockq=
uote type=3D"cite"><span>That would be a neat trick. But yeah, I don't know h=
ow that would be possible.&nbsp;</span><br></blockquote><blockquote type=3D"=
cite"><span></span><br></blockquote><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><span>&nbsp; I believe it is one reason why custodian proof-of-r=
eserves is not that popular ... it does not prove that the key will not get l=
ost</span><br></blockquote></blockquote><blockquote type=3D"cite"><span></sp=
an><br></blockquote><blockquote type=3D"cite"><span>True, but at least if fu=
nds do get lost, it would be come clear far quicker. Today, an insolvent com=
pany could go many months without the public finding out.&nbsp;</span><br></=
blockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockquo=
te 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>G=
ood morning e,</span><br></blockquote></blockquote><blockquote type=3D"cite"=
><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><block=
quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa=
n>If only one could prove that he won=E2=80=99t get into a boating accident.=
</span><br></blockquote></blockquote></blockquote><blockquote type=3D"cite">=
<blockquote type=3D"cite"><span></span><br></blockquote></blockquote><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><span>At least in the context o=
f 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 s=
ockpuppet) has every incentive to unilaterally close the channel, which reve=
als the exact amounts (though not necessarily who owns which).</span><br></b=
lockquote></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 output of the unilateral close was the one lost in the b=
oating accident.</span><br></blockquote></blockquote><blockquote type=3D"cit=
e"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><span>On the other hand, yes=
, custodians losing custodied funds in boating accidents is much too common.=
</span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><span>I believe it is one reason why custodian proof-of-reserve=
s is not that popular --- it only proves that the funds were owned under a p=
articular key at some snapshot of the past, it does not prove that the key w=
ill not get lost (or "lost and then salvaged by a scuba diver") 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></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><span>ZmnSCPxj</span><b=
r></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci=
te"><span></span><br></blockquote></blockquote><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquo=
te></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><span>e</span><br></blockquote></blockquote><=
/blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc=
kquote type=3D"cite"><span>On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-de=
v <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a> wrote:</span><br></blockquote></b=
lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Good m=
orning Billy,</span><br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite=
"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote></blo=
ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><=
span>I wonder if there would be some way to include the ability to prove bal=
ances held on the lightning network, but I suspect that isn't generally poss=
ible.</span><br></blockquote></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote>=
</blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite=
"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Thinking about t=
his in terms of economic logic:</span><br></blockquote></blockquote></blockq=
uote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><block=
quote type=3D"cite"><blockquote type=3D"cite"><span>Every channel is anchore=
d onchain, and that anchor (the funding txout) is proof of the existence, an=
d size, of the channel.</span><br></blockquote></blockquote></blockquote></b=
lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>The two participants in the chan=
nel can sign a plaintext containing their node pubkeys and how much each own=
s.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><span>One of the participants should provably be the custod=
ian.</span><br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockq=
uote type=3D"cite"><span></span><br></blockquote></blockquote></blockquote><=
/blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><span>-&nbsp; &nbsp;If the counterpar=
ty is a true third party, it has no incentive to lie about its money.</span>=
<br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"=
cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><span>-&nbsp; &nbsp;Especially if the counterparty is another custodi=
an who wants proof-of-reserves, it has every incentive to overreport, but th=
en the first party will refuse to sign.</span><br></blockquote></blockquote>=
</blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite=
"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>&nbsp; &nbsp; &n=
bsp;It has a disincentive to underreport, and would itself refuse to sign a d=
ishonest report that assigns more funds to the first party.</span><br></bloc=
kquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><s=
pan>&nbsp; &nbsp; &nbsp;The only case that would be acceptable to both custo=
dians would be to honestly report their holdings in the Lightning channel.</=
span><br></blockquote></blockquote></blockquote></blockquote><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><span></span><br></blockquote></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>-&nbsp; &nbsp;If the counterparty is a=
 sockpuppet of the custodian, then the entire channel is owned by the custod=
ian and it would be fairly dumb of he custodian to claim to have less funds t=
han the entire channel.</span><br></blockquote></blockquote></blockquote></b=
lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockq=
uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Perhaps a m=
ore practical problem is that Lightning channel states change fairly quickly=
, and there are possible race conditions, due to network latency (remember, b=
oth nodes need to sign, meaning both of them need to communicate with each o=
ther, thus hit by network latency and other race conditions) where a custodi=
an Lightning node is unable to "freeze" a snapshot of its current state and m=
ake an atomic proof-of-reserves of all channels.</span><br></blockquote></bl=
ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Regards=
,</span><br></blockquote></blockquote></blockquote></blockquote><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><span>ZmnSCPxj</span><br></blockquote></blockquote></blockquo=
te></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></=
blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>bitco=
in-dev mailing list</span><br></blockquote></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span><a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a></span><br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockqu=
ote type=3D"cite"><span><a href=3D"https://lists.linuxfoundation.org/mailman=
/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a></span><br></blockquote></blockquote></blockq=
uote></blockquote><span></span><br><span></span><br></div></blockquote></div=
></blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-E1A554DE-66B3-4372-8779-401FCF03B481--