Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id AD07BC000E for ; 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 ; 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 ; 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 ; Tue, 6 Jul 2021 07:37:09 +0000 (UTC) Received: by mail-pf1-x433.google.com with SMTP id f17so7165564pfj.8 for ; 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 Mime-Version: 1.0 (1.0) Date: Tue, 6 Jul 2021 00:37:07 -0700 Message-Id: References: In-Reply-To: To: Billy Tetrud X-Mailer: iPhone Mail (18F72) Cc: Bitcoin Protocol Discussion 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 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 wrote: >> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy= >>=20 >>>> 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 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 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


@Eric
> 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.

> in the case where the secur= ity is issued on a distinct public chain the atomicity requirement is not sa= tisfied.

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.

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

All =E2=80=9Cusers=E2=80=9D need to simultaneously share th= eir individual and temporary audits with each other (ie publicly).

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

I disagr= ee here that it has not been difficult to detect deviations (insolvency).

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.

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?

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

I'm of the opinion that you can't prevent insolvency.
<= /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.

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.

Nonsense, any business can fail, regardless of tempora= l cash reserves.

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? 

Reckless is a subjective te= rm. Proofs will not insure any investment.

e
<= br>
On Mon, Jul 5, 2021 at 10:10 PM Eric Vosk= uil <eric@voskuil.org> wrote:<= br>
=EF=BB=BFGood morning Billy,



  The two participants in t= he channel can sign a plaintext containing their node pubkeys and how much e= ach owns

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. 

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.

Really, though, t= he 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 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.
This condition can remain= for many months or years, as well, without knowledge of the custodian clien= ts, *or* of the custodian itself.

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

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

Regards,
ZmnSCPxj


  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
=

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

  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

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. 

On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
=
G= ood morning e,

If only one could prove that he won=E2=80=99t get into a boating accident.=
=

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

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

=
Regards,
ZmnSCPxj


e
<= /blockquote>

On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-de= v bitcoin-dev@lists.linuxfoundation.org wrote:
Good m= orning Billy,
=

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

=
Thinking about t= his in terms of economic logic:
Every channel is anchore= d onchain, and that anchor (the funding txout) is proof of the existence, an= d size, of the channel.
The two participants in the chan= nel can sign a plaintext containing their node pubkeys and how much each own= s.
One of the participants should provably be the custod= ian.

<= /blockquote>
-   If the counterpar= ty is a true third party, it has no incentive to lie about its money.=
-   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.
=
    &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.
     The only case that would be acceptable to both custo= dians would be to 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 custod= ian and it would be fairly dumb of he custodian to claim to have less funds t= han the entire channel.

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

bitco= in-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<= /a>
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


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