public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof of reserves - recording
Date: Mon, 5 Jul 2021 18:34:53 -0700	[thread overview]
Message-ID: <CAGpPWDZpqhpgrO5BFyoB3w-+_xU6bU=sTA-r--vzY910K5c5aQ@mail.gmail.com> (raw)
In-Reply-To: <5EIOo5CwOeMAVo59ES88McUhlBpvJaRgsFKiyaASICQLHhfMC5Q-ALBKeeB77O3NVEQL11UE4WkNhfuTF23uFHYDv7iYzmiOU0RFjqSUUQA=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 4468 bytes --]

@ 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’t 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
> 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
> 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 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.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 generally
> 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 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 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 he
> 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 other
> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 5388 bytes --]

  reply	other threads:[~2021-07-06  1:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 18:24 [bitcoin-dev] Proof of reserves - recording Billy Tetrud
2021-07-05 23:26 ` ZmnSCPxj
2021-07-05 23:32   ` Eric Voskuil
2021-07-06  0:09     ` ZmnSCPxj
2021-07-06  1:34       ` Billy Tetrud [this message]
2021-07-06  4:54         ` ZmnSCPxj
2021-07-06  5:09           ` Eric Voskuil
2021-07-06  6:02             ` Billy Tetrud
2021-07-06  7:37               ` Eric Voskuil
2021-07-06 16:39 ` Erik Aronesty
2021-07-06 18:40   ` eric
2021-07-07  6:18   ` Billy Tetrud
2021-07-09 14:55     ` Eric Voskuil
2021-07-09 17:43       ` Billy Tetrud
2021-07-09 18:32         ` Eric Voskuil
2021-07-09 22:02           ` Billy Tetrud
2021-07-09 23:18             ` Eric Voskuil
2021-07-09 23:50               ` ZmnSCPxj
2021-07-10  0:49                 ` eric
2021-07-10  1:26                   ` ZmnSCPxj
2021-07-10  1:49                     ` eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGpPWDZpqhpgrO5BFyoB3w-+_xU6bU=sTA-r--vzY910K5c5aQ@mail.gmail.com' \
    --to=billy.tetrud@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox