diff options
author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2021-07-06 00:09:25 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-07-06 00:09:36 +0000 |
commit | d9de36e7c1ae460577200def082d3b186b71354f (patch) | |
tree | a829e2fd8aea0ae18f274d002de87551dd07066b | |
parent | fb5c67018504021f9a5033fc001cd101585592fe (diff) | |
download | pi-bitcoindev-d9de36e7c1ae460577200def082d3b186b71354f.tar.gz pi-bitcoindev-d9de36e7c1ae460577200def082d3b186b71354f.zip |
Re: [bitcoin-dev] Proof of reserves - recording
-rw-r--r-- | e0/5075f67e7d97ac40eff662c48bb4f6437b9eb4 | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/e0/5075f67e7d97ac40eff662c48bb4f6437b9eb4 b/e0/5075f67e7d97ac40eff662c48bb4f6437b9eb4 new file mode 100644 index 000000000..1de50eb3f --- /dev/null +++ b/e0/5075f67e7d97ac40eff662c48bb4f6437b9eb4 @@ -0,0 +1,139 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 7501EC000E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <eric@voskuil.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com> +In-Reply-To: <F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org> +References: <cLK-RFlIdmwOvuKag-cOImIVCltq97EWfT-mFpPFa5wJfbAgptlKFhmgt4WQNw2pYVt-sGCCCTtHi1s0Vdwwimun_fUdvrDeOOPnlFjYDdA=@protonmail.com> + <F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +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 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 + + + |