summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZmnSCPxj <ZmnSCPxj@protonmail.com>2021-07-06 00:09:25 +0000
committerbitcoindev <bitcoindev@gnusha.org>2021-07-06 00:09:36 +0000
commitd9de36e7c1ae460577200def082d3b186b71354f (patch)
treea829e2fd8aea0ae18f274d002de87551dd07066b
parentfb5c67018504021f9a5033fc001cd101585592fe (diff)
downloadpi-bitcoindev-d9de36e7c1ae460577200def082d3b186b71354f.tar.gz
pi-bitcoindev-d9de36e7c1ae460577200def082d3b186b71354f.zip
Re: [bitcoin-dev] Proof of reserves - recording
-rw-r--r--e0/5075f67e7d97ac40eff662c48bb4f6437b9eb4139
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
+
+
+