Date: Mon, 05 Jul 2021 23:26:23 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cLK-RFlIdmwOvuKag-cOImIVCltq97EWfT-mFpPFa5wJfbAgptlKFhmgt4WQNw2pYVt-sGCCCTtHi1s0Vdwwimun_fUdvrDeOOPnlFjYDdA=@protonmail.com>
In-Reply-To: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
References: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Proof of reserves - recording
Precedence: list

Good morning Billy,

> I wonder if there would be some way to include the ability to prove balan=
ces held on the lightning network, but I suspect that isn't generally possi=
ble.=C2=A0

Thinking about this in terms of economic logic:

Every channel is anchored onchain, and that anchor (the funding txout) is p=
roof of the existence, and size, of the channel.

The two participants in the channel can sign a plaintext containing their n=
ode 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 lie abo=
ut its money.
  * Especially if the counterparty is *another* custodian who wants proof-o=
f-reserves, it has every incentive to overreport, but then the first party =
will refuse to sign.
    It has a disincentive to underreport, and would itself refuse to sign a=
 dishonest report that assigns more funds to the first party.
    The only case that would be acceptable to both custodians would be to h=
onestly report their holdings in the Lightning channel.
* If the counterparty is a sockpuppet of the custodian, then the entire cha=
nnel is owned by the custodian and it would be fairly dumb of he custodian =
to claim to have less funds than the entire channel.

Perhaps a more practical problem is that Lightning channel states change fa=
irly quickly, and there are possible race conditions, due to network latenc=
y (remember, both nodes need to sign, meaning both of them need to communic=
ate with each other, thus hit by network latency and other race conditions)=
 where a custodian Lightning node is unable to "freeze" a snapshot of its c=
urrent state and make an atomic proof-of-reserves of *all* channels.

Regards,
ZmnSCPxj