path: root/ac/1fb79c626a1a52417818f05a635236b1c7b7df

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EF5D0C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 04:54:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id BEE07832C7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 04:54:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, 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_H4=0.001,
 RCVD_IN_MSPIKE_WL=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 Un9kH8Q39HBD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 04:54:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 7E99E8322E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 04:54:22 +0000 (UTC)
Date: Tue, 06 Jul 2021 04:54:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1625547259;
 bh=XWXt+cEILzz4kg6PSjW+sz645x9TDZpfW26EGG8undc=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=qsRTKPpxVoxNKkMGv1ljSmqq4GkfIpnkl5Zt+OnWqNi9d4k2OjdRDegMhkVJlETXY
 StmBNXaXpdMN/yA8IYAmklkn+ELXzfhtTlJsP1KercB3B4fy7X1WINova+dQg1ntnB
 O8kP8/qvLSRApFpo8b/x6mSSpw7MA4t/3LCzhEKs=
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
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 04:54:25 -0000

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