Date: Tue, 06 Jul 2021 04:54:11 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0C9QijB2q6YADZLIDMFtTksQon92ixWlHg5tECfETla5is1GGAX6AktIS-DNthydwtxG0l6Ao99hYlikx-sKSpWxxAMGGmUoUyrn6zDkBrE=@protonmail.com>
In-Reply-To: <CAGpPWDZpqhpgrO5BFyoB3w-+_xU6bU=sTA-r--vzY910K5c5aQ@mail.gmail.com>
References: <cLK-RFlIdmwOvuKag-cOImIVCltq97EWfT-mFpPFa5wJfbAgptlKFhmgt4WQNw2pYVt-sGCCCTtHi1s0Vdwwimun_fUdvrDeOOPnlFjYDdA=@protonmail.com>
 <F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org>
 <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com>
 <CAGpPWDZpqhpgrO5BFyoB3w-+_xU6bU=sTA-r--vzY910K5c5aQ@mail.gmail.com>
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>
Subject: Re: [bitcoin-dev] Proof of reserves - recording
Precedence: list

Good morning Billy,


>
> >=C2=A0 The two participants in the channel can sign a plaintext containi=
ng their node pubkeys and how much each owns
>
> Sure, but even if both participants in the channel sign a correct stateme=
nt of truth, one of the participants can send funds out in the next second,=
 invalidating that truth. While proof of ownership of on-chain UTXOs can be=
 seen publicly in real time if they are spent, LN transactions aren't publi=
c like that. So any balance attestation is at best only valid the instant i=
ts taken, and can't be used as verification the money is still owned by the=
 same channel partner in the next second.=C2=A0

The same problem really also exists onchain --- a thief (or "thief") who ha=
s gotten a copy of the key can sign a transaction that spends it, one secon=
d after the proof-of-reserves is made.

Really, though, the issue is that ownership of funds is conditional on *kno=
wledge* of keys.
And *knowledge* is easily copyable.

Thus, it is possible that the funds that are "proven" to be the reserve of =
a custodian is actually *also* owned by someone else who has gotten to the =
privkeys (e.g. somebody threw a copy of it from a boating accident and a fe=
arless scuba diver rescued it), and thus can also move the funds outside of=
 the control of the custodian.
This condition can remain for many months or years, as well, without knowle=
dge of the custodian clients, *or* of the custodian itself.

There is no way to prove that there is no alternate copy of the privkeys, h=
ence "if only one could prove that he won't get into a boating accident".

On the other hand, one could argue that at least the onchain proof requires=
 more conditions to occur, so we might plausibly live with "we cannot prove=
 we will never get into a boating accident but we can show evidence that we=
 live in a landlocked city far from any lakes, seas, or rivers".

Regards,
ZmnSCPxj

>
> >=C2=A0 a custodian Lightning node is unable to "freeze" a snapshot of it=
s current state and make an atomic proof-of-reserves of *all* channels
>
> That would be a neat trick. But yeah, I don't know how that would be poss=
ible.=C2=A0
>
> >=C2=A0 I believe it is one reason why custodian proof-of-reserves is not=
 that popular ... it does not prove that the key will not get lost
>
> True, but at least if funds do get lost, it would be come clear far quick=
er. Today, an insolvent company could go many months without the public fin=
ding out.=C2=A0
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > Good morning e,
> >
> > > If only one could prove that he won=E2=80=99t get into a boating acci=
dent.
> >
> > At least in the context of Lightning channels, if one party in the chan=
nel 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 unilatera=
lly close the channel, which reveals the exact amounts (though not necessar=
ily who owns which).
> > If the other party then uses its funds in a new proof-of-reserves, then=
 obviously the other output of the unilateral close was the one lost in the=
 boating accident.
> >
> > On the other hand, yes, custodians losing custodied funds in boating ac=
cidents is much too common.
> > I believe it is one reason why custodian proof-of-reserves is not that =
popular --- 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@list=
s.linuxfoundation.org wrote:
> > > > Good morning Billy,
> > > >
> > > > > I wonder if there would be some way to include the ability to pro=
ve balances held on the lightning network, but I suspect that isn't general=
ly possible.
> > > >
> > > > Thinking about this in terms of economic logic:
> > > > Every channel is anchored onchain, and that anchor (the funding txo=
ut) is proof of the existence, and size, of the channel.
> > > > The two participants in the channel can sign a plaintext containing=
 their node pubkeys and how much each owns.
> > > > One of the participants should provably be the custodian.
> > > >
> > > > -=C2=A0 =C2=A0If the counterparty is a true third party, it has no =
incentive to lie about its money.
> > > > -=C2=A0 =C2=A0Especially if the counterparty is another custodian w=
ho wants proof-of-reserves, it has every incentive to overreport, but then =
the first party will refuse to sign.
> > > >=C2=A0 =C2=A0 =C2=A0It has a disincentive to underreport, and would =
itself refuse to sign a dishonest report that assigns more funds to the fir=
st party.
> > > >=C2=A0 =C2=A0 =C2=A0The only case that would be acceptable to both c=
ustodians would be to honestly report their holdings in the Lightning chann=
el.
> > > >
> > > > -=C2=A0 =C2=A0If the counterparty is a sockpuppet of the custodian,=
 then the entire channel is owned by the custodian and it would be fairly d=
umb of he custodian to claim to have less funds than the entire channel.
> > > >
> > > > Perhaps a more practical problem is that Lightning channel states c=
hange fairly quickly, and there are possible race conditions, due to networ=
k latency (remember, both nodes need to sign, meaning both of them need to =
communicate with each other, thus hit by network latency and other race con=
ditions) where a custodian Lightning node is unable to "freeze" a snapshot =
of its 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