Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo

[Christian Decker <decker.christian@gmail.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