public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>,
	Richard Myers <rich@gotenna.com>
Subject: Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo
Date: Thu, 19 Sep 2019 12:26:13 +0200	[thread overview]
Message-ID: <87sgos8tve.fsf@gmail.com> (raw)
In-Reply-To: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>

ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
>> Not necessarily. If we have an escape hatch in the scripts that allows
>> to spend any output attached to the settlement transaction by n-1
>> participants we could reclaim these into a new open right away.
>
> This would have to be very very carefully designed.
> The entire point of requiring an n-of-n signature is:
>
> * By using an n-of-n signatory where *you* are a signer, you are completely immune to Sybil attacks: even if everybody other than *you* in the signatory set is secretly just one entity, this is no different from doing a 2-of-2 bog-standard boring sleepy Zzzzzz Poon-Dryja Lightning Network channel.
>   * Any m-of-n signatory where strictly m < n allows anybody with the ability to run m nodes to outright steal money from you.
>     * As processing power is cheap nowadays, there is no m that can be considered safe.
>       Your alternative is to fall back on proof-of-work, but that just means going onchain, so you might as well just do things onchain.
>   * This is why 2-of-2 channels work so well, it's the minimum useable construction and any multiparty construction, when Sybilled, devolves to a 2-of-2 channel.
>
> So the n-1 participants would have to be very very very carefully limited in what they can do.
> And if the only "right" the n-1 participants can do is to force the nth participant to claim its funds onchain, then that is implementable with a transaction doing just that, which is pre-signed by the nth participant and given to participants 1..n-1.

Just to be clear, I do *not* want to support uncooperative splice-outs.
This is due to their need to either pre-sign a splice-out of the party
like I explained further down, or it requires encumbering whatever we
build on top in order to do a fast-reopen.

But I do think there is value in exploring what the options are :-)

>> Notice that we are negotiating whether or not to apply generic
>> transactions to a shared state. This also means that there is no direct
>> relationship between the ownership of an output and the ID signing off
>> on a change.
>>
>> The privacy guarantees are identical to Bitcoin on-chain, with the one
>> caveat that we may identify the proposing participant, but we can defend
>> against this by mixing as you propose.
>
> Yes, but if we later combine this with allowing multiilateral kick-out
> of a member that is unresponsive (i.e. we splice out the outputs it
> has at least partial ownership of, and keep only those that are owned
> only by the remaining members), then each member would have to
> honestly claim which UTXOs it is interested in keeping after it is
> kicked out of the membership set, defeating this point entirely.  I
> believe this is roughly what you propose in the next point, and
> roughly what you would want with the "n-1 participants" earlier.

That is indeed the issue I explained further down:

> It also adds the complexity of having to identify which participant is
> the co-owner of an output, otherwise I can claim ownership of an
> unrelated output and force that to move on-chain by including it in my
> fallback and then becoming unresponsive (added rounds of communication
> can help here, but are cumbersome).

Claiming ownership would then involve providing a valid input script
(disregarding any timelocks) that could spend the output under some
condition. Others would have to verify this proof-of-ownership before
accepting the node's self-splice-out before accepting it.

>>     It may be a bit much added complexity for a small complexity to be
>>     honest, hopefully this won't be needed too often :-)
>
> Statement makes no sense, unless you meant to say "It may be a bit
> much complexity for a small benefit" or similar?

Indeed, that was a weird sentence :-) I did mean that it is a lot of
complexity for very little benefit :-)

Cheers,
Christian


      reply	other threads:[~2019-09-19 10:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06 13:18 [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo Christian Decker
2019-09-06 14:32 ` ZmnSCPxj
     [not found]   ` <CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
2019-09-10  1:28     ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
     [not found]       ` <CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
2019-09-18  5:28         ` ZmnSCPxj
2019-09-18 13:44           ` Christian Decker
2019-09-19  2:01             ` ZmnSCPxj
2019-09-19 10:26               ` Christian Decker [this message]

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=87sgos8tve.fsf@gmail.com \
    --to=decker.christian@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=rich@gotenna.com \
    /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