From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>
References: <87mufhva0k.fsf@gmail.com>
	<G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com>
	<CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
	<RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com>
	<CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
	<ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com>
	<87ef0doh0w.fsf@gmail.com>
	<4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>
Date: Thu, 19 Sep 2019 12:26:13 +0200
Message-ID: <87sgos8tve.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
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
Precedence: list

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