path: root/0f/db2d35efed3643bc40fdddd658c8496f0eb033

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CCDBDC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 01:35:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A53074038B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 01:35:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pxfkGSlZRWY5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 01:35:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [IPv6:2a00:1450:4864:20::632])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 07CB740389
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 01:35:12 +0000 (UTC)
Received: by mail-ej1-x632.google.com with SMTP id hc16so31486970ejc.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Jul 2021 18:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=TdIXFsa2QMYJw/tQ9cZqSIQ+WJbcWKPpSug8c3FWBNI=;
 b=bATHBiZUeL1KfPjz0VRzmoV3VahCGfq+bp/WBHPLfZtZkMmOygnd/b9WNBv75eodYI
 wUJJ4jIJ5Ql6dfE1kML6kEzzUw/KzDHqrhDp2flDP3BbuUUw0LNLhVqk2Y6zI7gOgBnE
 tboZ0eSe63HmkBTnFhxxK/84H01LIDMgvf3fZ+YCpehBQoFS6NoYDKLXHul3rCJlKkIp
 2dCmcCfchvIsX7Y1Dp6JHCj2NtZvpJy4Ul2qnqnkDNeZZGj/+0sNVrA+7QNwvNGgSzqm
 RW5fVIZCuTZMGEyxQwcLD9jkDQZN/BuK6VVJ+QYdHYqwWkoNMBYkDa9HUWLs+yQhn01E
 XTtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=TdIXFsa2QMYJw/tQ9cZqSIQ+WJbcWKPpSug8c3FWBNI=;
 b=UI2P0czEgBGpCwg9GUd515pcJ/Rp7+ic3k9fICqVd3C493fSP++bzYyDvwB1HO7z3i
 ywW4w82UaVZN1PCMvQHERY5i6qjw6SOf7oULEPUSEwbshqmYr0DmNtCyNt78TSkERao8
 f/tojvIxMKrXE84tFuuO8YuYOQw/T1FM+wv0g8NgyFmc/Ia9joxAB5naBsFnIaDLgPNH
 CUL35Go5kxqe1aioGGKqOEAiIMEVqfmmUZwMEnqjKJxkaaxxMuMd9rrIkJODm7U3epq+
 nL5lsc4QkUxRCbZr6oApIVVELKSNR4PYf9b536IRtpRLdpkTtAbKd0M4Wk3tW/POgDnW
 JeZg==
X-Gm-Message-State: AOAM530z6MDFBGPdYXub+iy6KdNFfCHsS1MOi6q0iqPW5nFc5AnCsD5t
 WrBRpZscc3NOb0RKHxecgknRo/N+X25th2TVbTA=
X-Google-Smtp-Source: ABdhPJxObuWyIup0G30W0jxBt2EpJ0l9e4rpx3i5WqyFEYPdNMMiWbRXEmu+yanRMj19nnOTqmo671sLPm0d27Cd2zw=
X-Received: by 2002:a17:907:9622:: with SMTP id
 gb34mr16011700ejc.401.1625535310928; 
 Mon, 05 Jul 2021 18:35:10 -0700 (PDT)
MIME-Version: 1.0
References: <cLK-RFlIdmwOvuKag-cOImIVCltq97EWfT-mFpPFa5wJfbAgptlKFhmgt4WQNw2pYVt-sGCCCTtHi1s0Vdwwimun_fUdvrDeOOPnlFjYDdA=@protonmail.com>
 <F79C4763-619D-42B9-92C8-555AC128832E@voskuil.org>
 <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com>
In-Reply-To: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 5 Jul 2021 18:34:53 -0700
Message-ID: <CAGpPWDZpqhpgrO5BFyoB3w-+_xU6bU=sTA-r--vzY910K5c5aQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000c71ed605c66a6eb9"
X-Mailman-Approved-At: Tue, 06 Jul 2021 08:35:55 +0000
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 01:35:14 -0000

--000000000000c71ed605c66a6eb9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@ ZmnSCPxj, Good Evening

>  The two participants in the channel can sign a plaintext containing
their node pubkeys and how much each owns

Sure, but even if both participants in the channel sign a correct statement
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 public
like that. So any balance attestation is at best only valid the instant its
taken, and can't be used as verification the money is still owned by the
same channel partner in the next second.

>  a custodian Lightning node is unable to "freeze" a snapshot of its
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
possible.

>  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
quicker. Today, an insolvent company could go many months without the
public finding out.

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 accide=
nt.
>
> At least in the context of Lightning channels, if one party in the channe=
l
> loses its key in a boating accident, the other party (assuming it is a tr=
ue
> separate person and not a sockpuppet) has every incentive to unilaterally
> close the channel, which reveals the exact amounts (though not necessaril=
y
> 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 th=
e
> boating accident.
>
> On the other hand, yes, custodians losing custodied funds in boating
> accidents 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 k=
ey
> 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.linuxfoundation.org wrote:
> > > Good morning Billy,
> > >
> > > > I wonder if there would be some way to include the ability to prove
> balances held on the lightning network, but I suspect that isn't generall=
y
> possible.
> > >
> > > 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
> their 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
> lie about its money.
> > > -   Especially if the counterparty is another custodian who wants
> proof-of-reserves, it has every incentive to overreport, but then the fir=
st
> 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 b=
e
> to honestly report their holdings in the Lightning channel.
> > >
> > > -   If the counterparty is a sockpuppet of the custodian, then the
> entire channel is owned by the custodian and it would be fairly dumb of h=
e
> custodian to claim to have less funds than the entire channel.
> > >
> > > Perhaps a more practical problem is that Lightning channel states
> change fairly quickly, and there are possible race conditions, due to
> network latency (remember, both nodes need to sign, meaning both of them
> need to communicate with each other, thus hit by network latency and othe=
r
> race conditions) 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
>
>
>

--000000000000c71ed605c66a6eb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@

ZmnSCPxj, Good Evening<div><br></div><div>&gt;=C2=A0

The two participants in the channel can sign a plaintext containing their n=
ode pubkeys and how much each owns</div><div><br></div><div>Sure, but even =
if both participants in the channel sign a correct statement of truth, one =
of the participants can send funds out in the next second, invalidating tha=
t truth. While proof of ownership of on-chain UTXOs can be seen publicly in=
 real time if they are spent, LN transactions aren&#39;t public like that. =
So any balance attestation is at best only valid the instant its taken, and=
 can&#39;t be used as verification the money is still owned by the same cha=
nnel partner in the next second.=C2=A0</div><div><br></div><div>&gt;=C2=A0

a custodian Lightning node is unable to &quot;freeze&quot; a snapshot of it=
s current state and make an atomic proof-of-reserves of *all* channels</div=
><div><br></div><div>That would be a neat trick. But yeah, I don&#39;t know=
 how that would be possible.=C2=A0</div><div><br></div><div>&gt;=C2=A0

I believe it is one reason why custodian proof-of-reserves is not that popu=
lar ... it does not prove that the key will not get lost<br><div><br></div>=
</div><div>True, but at least if funds do get lost, it would be come clear =
far quicker. Today, an insolvent company could go many months without the p=
ublic finding out.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj &lt;<=
a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morni=
ng e,<br>
<br>
<br>
&gt; If only one could prove that he won=E2=80=99t get into a boating accid=
ent.<br>
<br>
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).<br>
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.<br>
<br>
On the other hand, yes, custodians losing custodied funds in boating accide=
nts is much too common.<br>
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 &quot;lost and then salvaged by a scuba diver&quot;) later.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; e<br>
&gt;<br>
&gt; &gt; On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev <a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a> wrote:<br>
&gt; &gt; Good morning Billy,<br>
&gt; &gt;<br>
&gt; &gt; &gt; I wonder if there would be some way to include the ability t=
o prove balances held on the lightning network, but I suspect that isn&#39;=
t generally possible.<br>
&gt; &gt;<br>
&gt; &gt; Thinking about this in terms of economic logic:<br>
&gt; &gt; Every channel is anchored onchain, and that anchor (the funding t=
xout) is proof of the existence, and size, of the channel.<br>
&gt; &gt; The two participants in the channel can sign a plaintext containi=
ng their node pubkeys and how much each owns.<br>
&gt; &gt; One of the participants should provably be the custodian.<br>
&gt; &gt;<br>
&gt; &gt; -=C2=A0 =C2=A0If the counterparty is a true third party, it has n=
o incentive to lie about its money.<br>
&gt; &gt; -=C2=A0 =C2=A0Especially if the counterparty is another custodian=
 who wants proof-of-reserves, it has every incentive to overreport, but the=
n the first party will refuse to sign.<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0It has a disincentive to underreport, and woul=
d itself refuse to sign a dishonest report that assigns more funds to the f=
irst party.<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0The only case that would be acceptable to both=
 custodians would be to honestly report their holdings in the Lightning cha=
nnel.<br>
&gt; &gt;<br>
&gt; &gt; -=C2=A0 =C2=A0If the counterparty is a sockpuppet of the custodia=
n, then the entire channel is owned by the custodian and it would be fairly=
 dumb of he custodian to claim to have less funds than the entire channel.<=
br>
&gt; &gt;<br>
&gt; &gt; Perhaps a more practical problem is that Lightning channel states=
 change fairly quickly, and there are possible race conditions, due to netw=
ork latency (remember, both nodes need to sign, meaning both of them need t=
o communicate with each other, thus hit by network latency and other race c=
onditions) where a custodian Lightning node is unable to &quot;freeze&quot;=
 a snapshot of its current state and make an atomic proof-of-reserves of al=
l channels.<br>
&gt; &gt; Regards,<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt;<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
</blockquote></div>

--000000000000c71ed605c66a6eb9--