Date: Tue, 06 Jul 2021 00:09:25 +0000
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
Precedence: list

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