path: root/2c/749211b83196bb69f4331669bf7f84181cd1eb

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 47AF9C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 05:10:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2377C403EA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 05:10:03 +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 nWIJoSPq0dZD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 05:10:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [IPv6:2607:f8b0:4864:20::62c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0D521403AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 05:10:00 +0000 (UTC)
Received: by mail-pl1-x62c.google.com with SMTP id v13so11357167ple.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Jul 2021 22:10:00 -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=oukKylXdQ+hjdECGevfdLvFbpZv462oFQC5N0bZMHsw=;
 b=ssor0XhKyGiAE4X9qApyaH9oFiaosRoGIO/BEo09QW1rVcGdnR/LaU7pT4Pz6iw8e6
 3Gqa/I35klA7roChDCN6lH00FA7BPOC3L2bbdd8GZppZSQXbn33Exy3PCaNUIbJEN136
 x/Km5W4Df1tl75qD/75volyeSyAz6Xnkp7/5u51LWHcH+TUR0Wmgbg+etbtBsvqtu1NY
 xswseV4CUDWGJnpw7IdfgUAXdQPnXX3K79Z7+xqvudiBmUaorQYrL3CVlG+OJySTXVuD
 NsU4VMjuNq3XZSOlobps6rM+n/yiw28xSLxMQKm9TdEtcpjvZOUKB+42H46XA3qc6K8M
 khtQ==
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=oukKylXdQ+hjdECGevfdLvFbpZv462oFQC5N0bZMHsw=;
 b=Uqso9UaeuV+OZhuRts3UQSrW/049NdES9EcbVlDobdic3UdpCo746LK0M56UTkVFOP
 zVKzQb7mp7k9e6S3blUvfKK0b+3D/XGM4LwgTaHhKVRmPah7jQom5yE6xNsU2f8FlNtt
 EyMyoijS700eILIeUHk9yQm5gSTiHMGh+04La6VrLEc7wyXQa0G6S8qngjPjjz5om2t4
 +l2Ivi1A0ZKUFuFz7xiaow7F0Q2sA5xoRukSYOD3n+6rKmIVR00IOqNesutyYeIXQbrL
 ALJ22fA7ufbVZXPgQnfkObScXYTCSvJlga4LsI1uzPFNsMU4hHwm5B9If27rK05mfFgp
 1zNA==
X-Gm-Message-State: AOAM531f12owZhHwAI0Sdc+qj59JpU6F/cm6/N3XsDZqSy1cijKvll5E
 y7DUOWhPk51EVL6kkKkxsn8PNA==
X-Google-Smtp-Source: ABdhPJxcbrFkEIcHcpUI6fgDU5RbkPzrTVPeZmQf5Nu4choIEW4SpvdAuQPFmwh5u7V9hLvcs6B5/w==
X-Received: by 2002:a17:902:ce91:b029:129:6334:8c4c with SMTP id
 f17-20020a170902ce91b029012963348c4cmr13597604plg.79.1625548200386; 
 Mon, 05 Jul 2021 22:10:00 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::7844])
 by smtp.gmail.com with ESMTPSA id b19sm6818670pfv.139.2021.07.05.22.09.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 Jul 2021 22:09:59 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-C867E876-813F-406A-AEC3-331836204E02
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 5 Jul 2021 22:09:59 -0700
Message-Id: <EC55B6BD-2BDD-4074-A813-459D73D89DB2@voskuil.org>
References: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com>
In-Reply-To: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
X-Mailer: iPhone Mail (18F72)
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 05:10:03 -0000


--Apple-Mail-C867E876-813F-406A-AEC3-331836204E02
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy

> 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 th=
eir node pubkeys and how much each owns
>>=20
>> Sure, but even if both participants in the channel sign a correct stateme=
nt of truth, one of the participants can send funds out in the next second, i=
nvalidating that truth. While proof of ownership of on-chain UTXOs can be se=
en publicly in real time if they are spent, LN transactions aren't public li=
ke that. So any balance attestation is at best only valid the instant its ta=
ken, and can't be used as verification the money is still owned by the same c=
hannel partner in the next second.=20
>=20
> The same problem really also exists onchain --- a thief (or "thief") who h=
as gotten a copy of the key can sign a transaction that spends it, one secon=
d after the proof-of-reserves is made.
>=20
> Really, though, the issue is that ownership of funds is conditional on *kn=
owledge* of keys.
> And *knowledge* is easily copyable.
>=20
> Thus, it is possible that the funds that are "proven" to be the reserve of=
 a custodian is actually *also* owned by someone else who has gotten to the p=
rivkeys (e.g. somebody threw a copy of it from a boating accident and a fear=
less scuba diver rescued it), and thus can also move the funds outside of th=
e control of the custodian.
> This condition can remain for many months or years, as well, without knowl=
edge 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, h=
ence "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 require=
s 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 l=
ive 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 cur=
rent 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 poss=
ible.=20
>>=20
>>>   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
>>=20
>> True, but at least if funds do get lost, it would be come clear far quick=
er. Today, an insolvent company could go many months without the public find=
ing out.=20
>>=20
>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>=20
>>> Good morning e,
>>>=20
>>>> If only one could prove that he won=E2=80=99t get into a boating accide=
nt.
>>>=20
>>> At least in the context of Lightning channels, if one party in the chann=
el 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 necessarily w=
ho owns which).
>>> If the other party then uses its funds in a new proof-of-reserves, then o=
bviously the other output of the unilateral close was the one lost in the bo=
ating accident.
>>>=20
>>> On the other hand, yes, custodians losing custodied funds in boating acc=
idents is much too common.
>>> I believe it is one reason why custodian proof-of-reserves is not that p=
opular --- it only proves that the funds were owned under a particular key a=
t some snapshot of the past, it does not prove that the key will not get los=
t (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.l=
inuxfoundation.org wrote:
>>>>> Good morning Billy,
>>>>>=20
>>>>>> 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 po=
ssible.
>>>>>=20
>>>>> 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 th=
eir 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 to l=
ie about its money.
>>>>> -   Especially if the counterparty is another custodian who wants proo=
f-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 s=
ign a dishonest report that assigns more funds to the first party.
>>>>>      The only case that would be acceptable to both custodians would b=
e to honestly report their holdings in the Lightning channel.
>>>>>=20
>>>>> -   If the counterparty is a sockpuppet of the custodian, then the ent=
ire 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.
>>>>>=20
>>>>> Perhaps a more practical problem is that Lightning channel states chan=
ge 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 commu=
nicate with each other, thus hit by network latency and other race condition=
s) where 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.
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>=20
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20

--Apple-Mail-C867E876-813F-406A-AEC3-331836204E02
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"><a href=3D"https://github.=
com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy">https://github.c=
om/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;Z=
mnSCPxj@protonmail.com&gt; wrote:<br><br></blockquote></div><blockquote type=
=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>Good morning Billy,</span><br><spa=
n></span><br><span></span><br><blockquote type=3D"cite"><span></span><br></b=
lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>&nbsp; T=
he two participants in the channel can sign a plaintext containing their nod=
e pubkeys and how much each owns</span><br></blockquote></blockquote><blockq=
uote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><=
span>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.&nbsp;</span><br></blockquote><span></=
span><br><span>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 i=
t, one second after the proof-of-reserves is made.</span><br><span></span><b=
r><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 are=
 "proven" to be the reserve of a custodian is actually *also* owned by someo=
ne else who has gotten to the privkeys (e.g. somebody threw a copy of it fro=
m a boating accident and a fearless scuba diver rescued it), and thus can al=
so move the funds outside of the control of the custodian.</span><br><span>T=
his condition can remain for many months or years, as well, without knowledg=
e 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 t=
he privkeys, hence "if only one could prove that he won't get into a boating=
 accident".</span><br><span></span><br><span>On the other hand, one could ar=
gue 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 fro=
m any lakes, seas, or rivers".</span><br><span></span><br><span>Regards,</sp=
an><br><span>ZmnSCPxj</span><br><span></span><br><blockquote type=3D"cite"><=
span></span><br></blockquote><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><span>&nbsp; a custodian Lightning node is unable to "freeze" a snapsho=
t of its current state and make an atomic proof-of-reserves of *all* channel=
s</span><br></blockquote></blockquote><blockquote type=3D"cite"><span></span=
><br></blockquote><blockquote type=3D"cite"><span>That would be a neat trick=
. But yeah, I don't know how that would be possible.&nbsp;</span><br></block=
quote><blockquote type=3D"cite"><span></span><br></blockquote><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>&nbsp; I believe it is one reaso=
n why custodian proof-of-reserves is not that popular ... it does not prove t=
hat the key will not get lost</span><br></blockquote></blockquote><blockquot=
e type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><spa=
n>True, but at least if funds do get lost, it would be come clear far quicke=
r. Today, an insolvent company could go many months without the public findi=
ng out.&nbsp;</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;ZmnSCPxj@protonmail.com&gt; wrote:</span><br></blockquote><=
blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><span>Good morning e,</span><br></blockquote>=
</blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span></spa=
n><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=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></blockquote></b=
lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><=
br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><span>At least in the context of Lightning channels, if one party in th=
e channel loses its key in a boating accident, the other party (assuming it i=
s a true separate person and not a sockpuppet) has every incentive to unilat=
erally close the channel, which reveals the exact amounts (though not necess=
arily who owns which).</span><br></blockquote></blockquote><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>If the other party then uses its fund=
s in a new proof-of-reserves, then obviously the other output of the unilate=
ral close was the one lost in the boating accident.</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>On the other hand, yes, custodians losing custodied funds in bo=
ating accidents is much too common.</span><br></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><span>I believe it is one re=
ason why custodian proof-of-reserves is not that popular --- it only proves t=
hat 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 salvag=
ed by a scuba diver") later.</span><br></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blo=
ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Regards,</=
span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote typ=
e=3D"cite"><span>ZmnSCPxj</span><br></blockquote></blockquote><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><span></span><br></blockquote></blockquote></blockquote><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>e</sp=
an><br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><span></span><br></blockquot=
e></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"ci=
te"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On Jul 5, 2021=
, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org w=
rote:</span><br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><block=
quote type=3D"cite"><span>Good morning Billy,</span><br></blockquote></block=
quote></blockquote></blockquote><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"ci=
te"><blockquote type=3D"cite"><span>I wonder if there would be some way to i=
nclude the ability to prove balances held on the lightning network, but I su=
spect that isn't generally possible.</span><br></blockquote></blockquote></b=
lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty=
pe=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 this in terms of economic logic:</span><br></blo=
ckquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><=
span>Every channel is anchored onchain, and that anchor (the funding txout) i=
s proof of the existence, and size, of the channel.</span><br></blockquote><=
/blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>The t=
wo participants in the channel can sign a plaintext containing their node pu=
bkeys and how much each owns.</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>One of the participants sh=
ould provably be the custodian.</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></span><br></blockquote>=
</blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>-&n=
bsp; &nbsp;If the counterparty is a true third party, it has no incentive to=
 lie about its money.</span><br></blockquote></blockquote></blockquote></blo=
ckquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=
=3D"cite"><blockquote type=3D"cite"><span>-&nbsp; &nbsp;Especially if the co=
unterparty is another custodian who wants proof-of-reserves, it has every in=
centive to overreport, but then the first party will refuse to sign.</span><=
br></blockquote></blockquote></blockquote></blockquote><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D=
"cite"><span>&nbsp; &nbsp; &nbsp;It has a disincentive to underreport, and w=
ould itself refuse to sign a dishonest report that assigns more funds to the=
 first party.</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; &nbsp;The only case that wou=
ld be acceptable to both custodians would be to honestly report their holdin=
gs in the Lightning channel.</span><br></blockquote></blockquote></blockquot=
e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><span></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>-&nbsp=
; &nbsp;If the counterparty is a sockpuppet of the custodian, then the entir=
e channel is owned by the custodian and it would be fairly dumb of he custod=
ian to claim to have less funds than the entire channel.</span><br></blockqu=
ote></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq=
uote 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"><blockquote=
 type=3D"cite"><span>Perhaps a more practical problem is that Lightning chan=
nel states change fairly quickly, and there are possible race conditions, du=
e to network latency (remember, both nodes need to sign, meaning both of the=
m 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 s=
napshot of its current state and make an atomic proof-of-reserves of all cha=
nnels.</span><br></blockquote></blockquote></blockquote></blockquote><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><bloc=
kquote type=3D"cite"><span>Regards,</span><br></blockquote></blockquote></bl=
ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><span>ZmnSCPxj</span><br><=
/blockquote></blockquote></blockquote></blockquote><blockquote type=3D"cite"=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit=
e"><span></span><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><b=
lockquote type=3D"cite"><span>bitcoin-dev mailing list</span><br></blockquot=
e></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>b=
itcoin-dev@lists.linuxfoundation.org</span><br></blockquote></blockquote></b=
lockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><=
blockquote type=3D"cite"><blockquote type=3D"cite"><span>https://lists.linux=
foundation.org/mailman/listinfo/bitcoin-dev</span><br></blockquote></blockqu=
ote></blockquote></blockquote><span></span><br><span></span><br></div></bloc=
kquote></body></html>=

--Apple-Mail-C867E876-813F-406A-AEC3-331836204E02--