From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7501EC000E for ; Tue, 6 Jul 2021 00:09:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 46207831A9 for ; Tue, 6 Jul 2021 00:09:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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_H2=-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 zNtRamAALbPW for ; Tue, 6 Jul 2021 00:09:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.osuosl.org (Postfix) with ESMTPS id D40FA83192 for ; Tue, 6 Jul 2021 00:09:34 +0000 (UTC) Date: Tue, 06 Jul 2021 00:09:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1625530172; bh=MXYToorP26pmq0mkQJtL6AnzQzvK5o+OZFl6uOU5g0U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=OZs6Zlj+FuJC5FBcSULsGc3jhDeYICaRRZS+6HrMJVipwnmI4N/U9BNs8dn5ZOiat 6kCDsGwP5RgvRf9pAoVsuwxnZ1S2lPPpeOReGZ4yJPVcY+SMnLwsEAZ6bonle0L61V +dXytJNlZD5pR6xkIycXqoPlRb4amYZxYhHacC7g= To: Eric Voskuil From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 00:09:36 -0000 Good morning e, > If only one could prove that he won=E2=80=99t get into a boating accident= . At least in the context of 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 sockpuppet) has every incentive to unilaterally = 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, then obv= iously the other output of the unilateral close was the one lost in the boa= ting accident. On the other hand, yes, custodians losing custodied funds in boating accide= nts is much too common. I believe it is one reason why custodian proof-of-reserves is not that popu= lar --- 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@lists.li= nuxfoundation.org wrote: > > Good morning Billy, > > > > > 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 p= ossible. > > > > 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 the= ir node pubkeys and how much each owns. > > One of the participants should provably be the custodian. > > > > - 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 proof= -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 si= gn 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. > > > > - If the counterparty is a sockpuppet of the custodian, then the enti= re 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. > > > > Perhaps a more practical problem is that Lightning channel states chang= e 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 comm= unicate with each other, thus hit by network latency and other race conditi= ons) where a custodian Lightning node is unable to "freeze" a snapshot of i= ts 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