From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EF5D0C000E for ; Tue, 6 Jul 2021 04:54:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id BEE07832C7 for ; Tue, 6 Jul 2021 04:54:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un9kH8Q39HBD for ; Tue, 6 Jul 2021 04:54:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7E99E8322E for ; Tue, 6 Jul 2021 04:54:22 +0000 (UTC) Date: Tue, 06 Jul 2021 04:54:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1625547259; bh=XWXt+cEILzz4kg6PSjW+sz645x9TDZpfW26EGG8undc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=qsRTKPpxVoxNKkMGv1ljSmqq4GkfIpnkl5Zt+OnWqNi9d4k2OjdRDegMhkVJlETXY StmBNXaXpdMN/yA8IYAmklkn+ELXzfhtTlJsP1KercB3B4fy7X1WINova+dQg1ntnB O8kP8/qvLSRApFpo8b/x6mSSpw7MA4t/3LCzhEKs= To: Billy Tetrud From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com> In-Reply-To: References: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 04:54:25 -0000 Good morning Billy, > > >=C2=A0 The two participants in the channel can sign a plaintext containi= ng their node pubkeys and how much each owns > > 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,= 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 publi= c like that. So any balance attestation is at best only valid the instant i= ts taken, and can't be used as verification the money is still owned by the= same channel partner in the next second.=C2=A0 The same problem really also exists onchain --- a thief (or "thief") who ha= s gotten a copy of the key can sign a transaction that spends it, one secon= d after the proof-of-reserves is made. Really, though, the issue is that ownership of funds is conditional on *kno= wledge* 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 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= the control of the custodian. This condition can remain for many months or years, as well, without knowle= dge of the custodian clients, *or* of the custodian itself. 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". On the other hand, one could argue that at least the onchain proof requires= more conditions to occur, so we might plausibly live with "we cannot prove= we will never get into a boating accident but we can show evidence that we= live in a landlocked city far from any lakes, seas, or rivers". Regards, ZmnSCPxj > > >=C2=A0 a custodian Lightning node is unable to "freeze" a snapshot of it= s current state and make an atomic proof-of-reserves of *all* channels > > That would be a neat trick. But yeah, I don't know how that would be poss= ible.=C2=A0 > > >=C2=A0 I believe it is one reason why custodian proof-of-reserves is not= that popular ... it does not prove that the key will not get lost > > 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 fin= ding out.=C2=A0 > > On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj wrote: > > > Good morning e, > > > > > If only one could prove that he won=E2=80=99t get into a boating acci= dent. > > > > At least in the context of Lightning channels, if one party in the chan= nel loses its key in a boating accident, the other party (assuming it is a = true separate person and not a sockpuppet) has every incentive to unilatera= lly close the channel, which reveals the exact amounts (though not necessar= ily who owns which). > > If the other party then uses its funds in a new proof-of-reserves, then= obviously the other output of the unilateral close was the one lost in the= boating accident. > > > > On the other hand, yes, custodians losing custodied funds in boating ac= cidents 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 = lost (or "lost and then salvaged by a scuba diver") later. > > > > Regards, > > ZmnSCPxj > > > > > > > > e > > > > > > > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev@list= s.linuxfoundation.org wrote: > > > > Good morning Billy, > > > > > > > > > I wonder if there would be some way to include the ability to pro= ve balances held on the lightning network, but I suspect that isn't general= ly possible. > > > > > > > > Thinking about this in terms of economic logic: > > > > Every channel is anchored onchain, and that anchor (the funding txo= ut) is proof of the existence, and size, of the channel. > > > > The two participants in the channel can sign a plaintext containing= their node pubkeys and how much each owns. > > > > One of the participants should provably be the custodian. > > > > > > > > -=C2=A0 =C2=A0If the counterparty is a true third party, it has no = incentive to lie about its money. > > > > -=C2=A0 =C2=A0Especially if the counterparty is another custodian w= ho wants proof-of-reserves, it has every incentive to overreport, but then = the first party will refuse to sign. > > > >=C2=A0 =C2=A0 =C2=A0It has a disincentive to underreport, and would = itself refuse to sign a dishonest report that assigns more funds to the fir= st party. > > > >=C2=A0 =C2=A0 =C2=A0The only case that would be acceptable to both c= ustodians would be to honestly report their holdings in the Lightning chann= el. > > > > > > > > -=C2=A0 =C2=A0If the counterparty is a sockpuppet of the custodian,= then the entire channel is owned by the custodian and it would be fairly d= umb of he custodian to claim to have less funds than the entire channel. > > > > > > > > Perhaps a more practical problem is that Lightning channel states c= hange fairly quickly, and there are possible race conditions, due to networ= k latency (remember, both nodes need to sign, meaning both of them need to = communicate with each other, thus hit by network latency and other race con= ditions) where a custodian Lightning node is unable to "freeze" a snapshot = of its current state and make an atomic proof-of-reserves of all channels. > > > > Regards, > > > > ZmnSCPxj > > > > > > > > bitcoin-dev mailing list > > > > bitcoin-dev@lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev