From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 47AF9C000E for ; 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 ; 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 ; 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 ; Tue, 6 Jul 2021 05:10:00 +0000 (UTC) Received: by mail-pl1-x62c.google.com with SMTP id v13so11357167ple.9 for ; 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 Mime-Version: 1.0 (1.0) Date: Mon, 5 Jul 2021 22:09:59 -0700 Message-Id: References: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com> In-Reply-To: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com> To: ZmnSCPxj X-Mailer: iPhone Mail (18F72) Cc: Bitcoin Protocol Discussion , Billy Tetrud 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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

On Jul 5, 2021, at 21:54, ZmnSCPxj <Z= mnSCPxj@protonmail.com> wrote:

=EF=BB=BFGood morning Billy,



  T= he two participants in the channel can sign a plaintext containing their nod= e pubkeys and how much each owns

<= 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. 

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.
Really, though, the issue is that ownership of funds is conditional o= n *knowledge* of keys.
And *knowledge* is easily copyable.

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.
T= his condition can remain for many months or years, as well, without knowledg= e of the custodian clients, *or* of the custodian itself.

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".

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".

Regards,
ZmnSCPxj

<= span>
  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

That would be a neat trick= . But yeah, I don't know how that would be possible. 

  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

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. 
=
On Mon, Jul 5, 2021 at 5:09= PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
<= blockquote type=3D"cite">
Good morning e,
=

If only one could prove that he won=E2= =80=99t get into a boating accident.
<= br>
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).
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.
<= /blockquote>

On the other hand, yes, custodians losing custodied funds in bo= ating accidents is much too common.
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.

Regards,
ZmnSCPxj


e

On Jul 5, 2021= , at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org w= rote:
Good morning Billy,

=
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.

Thinking about this in terms of economic logic:
<= span>Every channel is anchored onchain, and that anchor (the funding txout) i= s proof of the existence, and size, of the channel.
<= /blockquote>
The t= wo participants in the channel can sign a plaintext containing their node pu= bkeys and how much each owns.
One of the participants sh= ould provably be the custodian.

=
-&n= bsp;  If the counterparty is a true third party, it has no incentive to= lie about its money.
-   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.<= br>
     It has a disincentive to underreport, and w= ould itself refuse to sign a dishonest report that assigns more funds to the= first party.
=
     The only case that wou= ld be acceptable to both custodians would be to honestly report their holdin= gs in the Lightning channel.

- = ;  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.

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.
Regards,
ZmnSCPxj
<= /blockquote>

bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
<= blockquote type=3D"cite">
https://lists.linux= foundation.org/mailman/listinfo/bitcoin-dev


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