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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Christian, and list,


> > > uncooperative membership change:
> > >
> > > -   a subset of channel parties might want to cooperatively sign a channel splicing transaction to 'splice out' uncooperative parties
> >
> > I believe this is currently considered unsafe.
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001975.html
> > Unless you refer to another mechanism...?
> > I believe this will end up requiring deep confirmation of the
> > uncooperative close followed by a new mechanism open.
>
> 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.

> > > mining, mining reward and difficulty adjustment
> > >
> > > -   no equivalent concept for multi-party channels
> >
> > Fees for each update. Consider how HTLC routing in Lightning
> > implicitly pays forwarding nodes to cooperate with the forwarding. I
> > imagine most nodes in a multiparticipant offchain system will want to
> > be paid for cooperation, even if just a nominal sub-satoshi amount.
>
> If we allow generic contracts on top of the base update mechanism it'll
> be rather difficult to identify the beneficiary of an update, so it's
> hard to know who should pay a fee. I'd rather argue that cooperating is
> in the interest of all participants since they'd eventually want to
> create an update of their own, and there is no upside to become
> unresponsive.
>
> Notice that the fees we leverage in LN are because we expose our funds
> to the risk of not being available by allocating them to an HTLC, not
> for the updates themselves. Since in the forwarding scenario we're only
> exposing the funds of the forwarding nodes to this risk it's only
> natural that they'd be the ones leveraging a fee, not the other
> participants that simply sign off on the change.

I suppose that could be argued.

However, I imagine it is possible for some of the updates to be implementable via HTLCs within sub-mechanisms of the higher mechanism.
If so, a participant may refuse to sign for the higher mechanism in order to force others to use HTLCs on the lower mechanisms, and thereby earn fees due to HTLC usage.
I believe I argue as much here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html

> ZmnSCPxj can request a factory channel reorganization to move some funds from the ZmnSCPxj<->Rene channel to the ZmnSCPxj<->YAijbOJA channel.
> This has the same effect, i.e. it allows a forwarding attempt to push through, that would not be possible without the factory-level channel reorganization.
>
> Further, assuming only ZmnSCPxj, YAijbOJA, and Rene are in the channel factory, then it is the same: all three need to be online in order for the JIT-routing to work.
>
> But I observed above that, in a channel rebalance using current channels (without factories) Rene cannot be convinced to waive the fee.

The counterargument above is that if rebalances can be made fee-free, then the above argument disappears.


>
> > > privacy:
> > >
> > > -   disassociate a particular update from signer(s)
> > > -   disassociate IP address of signers from signature
> > > -   using SIGHASH_ALL for cooperative closes
> >
> > I suppose Tor can be used to disassociate IP address from signers if
> > everyone is from a hidden service. However, we need to include some
> > kind of mix mechanism to allow individual signers to disassociate
> > their ownership of funds from their identity as signers. Though such
> > mechanisms already exist as theoretical constructs, so "just needs
> > implementing".
> > But then again: if you own funds in the mechanism, you should be a
> > signer (else you are trusting a federation). So a basic fact here is
> > that if you are a participant in some offchain mechanism, you are
> > likely (approaching 100% probability) to own money in it.
>
> 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.

>
> > > liveness:
> > >
> > > -   if signers know they will be offline, can they pre-sign updates that just commit their own outputs, rather then splice out?
> > > -   contingent tap-leafs to splice out non-responsive signers
> >
> > It might be possible to create a new mechanism-within-mechanism layer,
> > if a signer knows they will be offline.
> > For example, suppose entities A, B, and C have an offchain update
> > mechanism, which we shall call a "factory". Suppose this factory
> > contains an A-B channel, a B-C channel, a A-C channel, and some funds
> > owned by B only. Then suppose A knows he or she will be offline for
> > some time. Before A goes offline, they can move from this UTXO set:
> >
> > -   A-B channel
> > -   B-C channel
> > -   A-C channel
> > -   B funds
> >
> > To this UTXO set:
> >
> > -   A-B channel
> > -   A-C channel
> > -   B-C offchain update mechanism (sub-factory), which itself has its own UTXO set:
> >     -   B-C channel
> >     -   B funds
> >
> > This allows B and C to manage the B-C channels and B funds without
> > cooperation of A. Then, later, when A returns online, the B-C
> > offchain update mechanism is collapsed back to the parent A-B-C
> > offchain update mechanism.
> > This assumes A knows it will be offline (which it might do for
> > e.g. regular maintenance, or software updates).
>
> We could theoretically play this game, having each participant create
> two updates with the same state-number at each update:
>
> 1.  A normal one that just keeps them in the contract
> 2.  A fallback splice all outputs they own (direct ones, HTLCs, ...) and
>     putting the rest back into a channel without them.
>
>     In case of one user becoming inactive the others can sign the splice,
>     dropping the inactive participant and continue like nothing
>     happened. The worst case scenario is that the normal update gets
>     broadcast and confirmed instead, which means we are back to the
>     unilateral close that we'd have to do anyway without this mechanism.
>
>     Notice however that this only works if participants drop off one by one,
>     otherwise we get a combinatorial explosion for the fallback cases where
>     each combination of inactive participants needs to splice themselves
>     out. 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).

This might be a plausible way of implementing the "n-1 participants can kick out nth participant".

>
>     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?

Regards,
ZmnSCPxj