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

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

[Christian Decker]

With the recently published proof-of-concept of eltoo on signet by
Richard, I thought it might a good time to share some thoughts on ho I
think we can build this system. I think there are a few properties of
eltoo that allow us to build a nicely layered protocol stack, which
improves flexibility and simplifies the reasoning about their relative
security.

Since I don't like huge e-mails myself and I'm about to write one,
here's a quick TL;DR:

> Using the clean separation of protocol layers provided by eltoo we can
> reconcile many on-chain and off-chain concepts, and simplify the
> reasoning to build more complex functionality beyond simple
> HTLCs. Bitcoin transactions are a natural fit to represent proposed
> off-chain state-changes while they are being negotiated.


### Clean separation of protocol layers

One of te big advantages of eltoo over other off-chain update mechanisms
is that it provides strong guarantees regarding the state that will
eventually end up confirmed on-chain. If parties in an eltoo off-chain
contract agree on an update, we can be certain (within eltoo's security
assumptions) that this is the state that will eventually confirm
on-chain, if no newer states are agreed.

In particular it means that we are guaranteed no earlier state can leak
onto the chain, keeping anything we build on top of the update layer
unencumbered since it doesn't have to deal with this case.

This is in stark contrast to the penalty update mechanism, where
old/revoked states can leak on-chain, resulting in anything built on top
of the penalty mechanism having to deal with that eventuality. For
example if we look at HTLCs as specified [1] we see that it needs an
additional revokation path for the case the commitment transaction that
created this HTLC output is confirmed:

```btcscript
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
```

The update mechanism bleeding into the other layers is rather cumbersome
if you ask me, and complicates the reasoning about security. Having to
thread the penalty through outputs created by the off-chain contract may
also not work if we deal with more than 2 parties, since penalties
always steal all the funds, regardless of whether the output belonged to
the cheater or not (see asymmetry vs symmetry argument from the paper
[2]).

With the clean separation we get from eltoo we can concentrate on
building the output scripts we'd like to have without having to thread
penalties through them. This reduces the complexity and our on-chain
footprint.

The update layer now exposes only two very simple operations:
`add_output` and `remove_output` (this should sound very familiar :-p).


### Ownership and atomic update model

Now that we have a solid update layer, which ensures that agreed upon
states will eventually be reflected on-chain, we can turn our attention
to the next layer up: the negotiation layer. Each output in our
agreed-upon state needs to be assigned one or more owners. The owners
are the participants that need to sign off on removal of an output and
the creation of new outputs which redistribute the funds contained in
the removed outputs to newly created outputs.

In addition we need to ensure that multiple `remove_output` and
`add_output` are guaranteed to be applied atomically. By creating a
datastructure that lists a number of operations that are to either be
applied to the current state or discarded, we can have arbitrary complex
changes of ownership, and the newly created outputs can have arbitrary
scripts.

If all of this sounds familiar that's because this is exactly the UTXO
model and the transaction structure we have in Bitcoin. We
collaboratively manage funds bound to some outputs (UTXO) and can change
their ownership and allocation over time (transactions).

This means that a subset of the participants in an off-chain contract
can negotiate among themselves how to redistribute funds, join and split
them in an arbitrary fashion, without the rest of the contract being
involved. The end result is a valid Bitcoin transaction that spends some
outputs of the current state, and is signed by the owners. The
transaction can then be presented to the entire group, and applied to
the state. Applying the transaction flattens multiple transactions built
on top of the current state into a new state (similar to transaction
cut-through in mimblewimble).

Using transactions as a means to represent off-chain negotiations, and
then applying them to the off-chain state via cut-through has a number
of advantages over similar schemes:

- Even if we failed to update the off-chain state, the transactions
  building on top of it are valid transactions, so once we tear down
  the channel, our negotiated new state can still be reached by
  broadcasting the transaction after settlement (this is basically
  what the channel factory paper [3] was using).
    
- We can reuse a lot of tools that we have already built for on-chain
  transactions, including things like miniscript and hardware wallets,
  without explicitly requiring them in our own specification. The
  Bitcoin object model is our interface here.

- It allows for experimentation even inside a running eltoo instance. If
  you can find another participant that supports a fancy new protocol,
  you can use that protocol even though some of the other participants
  may not know anything about it. As long as you can understand the
  Bitcoin transaction model you can participate in a multi-party
  channel.

I think this reconciliation between the off-chain model and the on-chain
model, with many concepts cleanly mapping from one context to another
(state outputs = UTXO, off-chain update = on-chain transactions,
cut-through = confirmation, operation batching = block creation) is
rather nice :-)

That should be enough rambling on my side. I'm interested in what others
think about this. Is it completely off, does it make no sense at all, or
is this something we should be looking into going forward?

Cheers,
Christian

[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#received-htlc-outputs
[2] https://blockstream.com/eltoo.pdf
[3] https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable%5FFunding%5FOf%5FBlockchain%5FMicropayment%5FNetworks.pdf

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

[ZmnSCPxj]

Good morning Christian,

This is effectively transaction cut-through.
I mention this in passing here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html

> I observe that one may consider any offchain system a specialization of an offchain transaction cut-through system.
> Thus, one may model changes to the offchain system state as the creation of some transactions, followed by a cut-through of those transactions into the new state.

Basically, we can send a transaction that spends a subset of the current state txos to the participants in the update mechanism.
Then the participants can agree that it is a valid spend of the specified state txos, and agree to sign a new state with the spent txos deleted and the new txos of the transaction inserted.
Disagreement at this point is essentially a "if your tx is so valid why do you not try it on the base blockchain layer huh?" challenge and is basically an invitation to close it unilaterally and enforce the contract on the blockchain.

The "difficulty" in Poon-Dryja is not very onerous in my opinion; see the sketch here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html

Of note is that any contract with a relative locktime requirement would not make sense to maintain offchain.
If one wishes to select a relative locktime relative to the current moment, one can quite easily compute an absolute timelock.

Another note, is that contracts with timelocks need to be enforced onchain on or before the timelock.
Under Decker-Russell-Osuntokun the onchain enforcement needs to be triggered early according to the CSV security parameter; this is not an issue under Poon-Dryja (as the CSV is in a later transaction).
Under Decker-Russell-Osuntokun due to the use of `SIGHASH_NOINPUT` and the non-stable txids involved, any transaction you wish to transport in the offchain update mechanism needs to also be signed under `SIGHASH_NOINPUT`, but again this is not onerous.
In any case it is "only" a matter of tradeoffs one is willing to work under anyway, and Decker-Russell-Osuntokun is very cool and uses `nLockTime` and `OP_CHECKLOCKTIMEVERIFY` in a very clever way.

Regards,
ZmnSCPxj

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

[ZmnSCPxj]

Good morning Richard,

> I believe using the eltoo update scheme as a way to consolidate blocks of off-chain transactions is an interesting idea worth exploring.  
>
> ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo. Although using CSV is more complicated and outputs must also use SIGHASH_NOINPUT [1], the ability to have multiple party channels and the most used types of scripts makes eltoo compelling compared to LN-Penalty for this kind of application.

I broadly agree.

I imagine a future where most people do not typically have single-signer ownership of coins onchain, but are instead share-owners of coins, with single-signer ownership occurring onchain only in the case of dispute or for long-term cold storage.

>
> The multiple party aspect in particular introduces an interesting way to unify concepts from different second layer protocols like federated sidechains and statechains (ht. aakselrod [2]).
>
> Though the Statechains proposal relies on eltoo [3], I think what Christian suggested does not try to solve the dynamic membership problem. That's why I think of this as more an evolution of the channel factory paper towards something like a federated sidechain.
>
> > I think this reconciliation between the off-chain model and the on-chain
> > model, with many concepts cleanly mapping from one context to another
> > (state outputs = UTXO, off-chain update = on-chain transactions,
> > cut-through = confirmation, operation batching = block creation) is
> > rather nice :-)
>
> One additional concept that could be new to this off-chain blockchain model would be something like batched multi-party loop-in/out. In a Schnorr/Taproot world you could add signers/inputs and remove signers/outputs with a single multi-signature negotiated off-chain. You'd still like to limit these onchain txs, even if they are small, but updating channels periodically seems like a straight forward way to address the dynamic membership problem.

Indeed.
Such a change-in-membership transaction would be a 1-input 1-output transaction, and with use of n-of-n MuSig would be as small (and as private, modulo the fact that you are coordinating this with a bunch of other participants) as a single-sig user making a 1-input 1-output transaction (which generally is not very private because such transactions are usually "send-to-self" and changing membership generally means ownership does not actually change much).
The cost of this transaction would be small (certainly smaller than the update+state transactions needed in Decker-Russell-Osuntokun)

For setting this up, it might be useful to have the below ritual.
This assumes only a change in the membership set is desired, without a simultaneous change in the UTXO set.

1.  Create a new update+state transaction for the current Decker-Russell-Osuntokun mechanism.
    The state transaction pays out to a single output paying to the new membership set rather than the current UTXO set of the mechanism.
    Do *not* sign this yet.
    Call this the "final" update+state transaction.
2.  Create a new Decker-Russell-Osuntokun mechanism initial update+state transaction.
    This pays out to the current UTXO set of the previous mechanism.
    This will spend from the new membership set.
    Completely sign these transactions.
    * The update transaction can spend the above "final" transaction, as it is `SIGHASH_NOINPUT`.
3.  Sign the final update+state transaction of the previous Decker-Russell-Osuntokun mechanism.
    Do *not* broadcast the update+state transaction yet.
4.  Create and sign the membership-change onchain transaction.
    This spends the current onchain funding transaction output and outputs to the same new membership set.
    Broadcast this onchain.

The above ritual ensures that, after step 3 completes, the mechanism can continue operating without waiting for onchain activity to complete.
It ensures that, even if the membership-change onchain transaction becomes invalid later (by somebody bribing a miner to publish a previous update transaction from the older membership set), we will still enter an update that will eventually put the new membership set onchain.
This reduces the critical path to only steps 1 to 3, and we can continue operating with the new membership set as soon as step 3 completes and we do not need to wait for the membership-change transaction to be deeply-confirmed in order to use the new membership set mechanism.

However, it has the drawback that, until the membership-change onchain transaction is deeply-confirmed onchain, the CSV parameter is temporarily doubled (as there is the possibility that the previous mechanism is closed).
Also, the mechanism cannot be mutually closed until the membership-change onchain transaction is deeply-confirmed, as there is no stable txid we can spend from (we would strongly prefer to use `SIGHASH_ALL` for cooperative closes to improve our privacy).

>
> I guess this all gets back to how to design an off-chain protocol for managing these negotiations. Ultimately I can imagine a sort of multi-party eltoo based 'signet' with the same RPC interface, but different transaction validation and block creation logic.  Perhaps there would be a new message where the channel parties would add their signature before forwarding a valid block, and the block wouldn't be built on until all parties had signed.

The "block" that would need to be signed by the participants would actually be a Decker-Russell-Osuntokun update+state transaction, and would commit to the UTXO set rather than the transaction set.
Unless I misunderstand your meaning here.

Regards,
ZmnSCPxj

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

[ZmnSCPxj]

Good morning Richards, and list,

> Thanks for the feedback ZmnSCPxj.
>
> > I imagine a future where most people do not typically have single-signer ownership of coins onchain, but are instead share-owners of coins, with single-signer ownership occurring onchain only in the case of dispute or for long-term cold storage.
>
> The change-in-membership ritual you describe seems like a good start for elaborating on this idea. 
>
> Some aspects of multi-party Decker-Russell-Osuntokun channels have analogs to a signet blockchain that use a n-of-n federation of signers. But other places, like change-in-membership, do not have direct analogs.
>
> For example, some signet concepts with multi-party channel analogs:
>
> block script:
> * the first 'update' and 'settle' transactions, aka 'setup' and 'refund' transactions, define the set of signers that must sign subsequent channel updates
>
> genesis block:
> * the initial 'funding' transaction, aka outpoint of the commitment transaction, which establishes the funded channel
>
> utxo set:
> * the specific set of on-chain outputs from the 'settlement' transaction that spends the balance of the latest 'update' transaction signed by the complete set of channel parties.
>
> mempool:
> * the set of proposals for specific changes to the set of outputs from the latest 'settlement' transaction (similar to update_add_htlc, update_fail_htlc, etc)
>
> Concepts where layer two channels do not have an obvious analog to a layer one signet blockchain:
>
> cooperative close:
> * when all parties mutually agree to close the channel
> * close the channel with a layer one transaction which finalizes the outputs from the most recent channel output state
> * should be optimized for privacy and low on-chain fees

Of note is that a close of an update mechanism does not require the close of any hosted update mechanisms, or more prosaically, "close of channel factory does not require close of hosted channels".
This is true for both unilateral and cooperative closes.

Of course, the most likely reason you want to unilaterally close an outer mechanism is if you have some contract in some deeply-nested mechanism that will absolute-locktime expire "soon", in which case you have to close everything that hosts it.
But for example if a channel factory has channels A B C and only A has an HTLC that will expire soon, while the factory and A have to close, B and C can continue operation, even almost as if nothing happened to A.

>
> membership change (ZmnSCPxj ritual):
> * when channel parties want to leave or add new members to the channel
> * close and reopen a new channel via something like a channel splicing transaction to the layer one blockchain
> * should be optimized for privacy and low on-chain fees paid for by parties entering and leaving the channel

Assuming you mean that any owned funds will eventually have to be claimed onchain, I suppose this is doable as splice-out.

But note that currently we have some issues with splice-in.

As far as I can tell (perhaps Lisa Neigut can correct me, I believe she is working on this), splice-in has the below tradeoffs:

1.  Option 1: splice-in is async (other updates can continue after all participants have sent the needed signatures for the splice-in).
    Drawback is that spliced-in funds need to be placed in a temporary n-of-n, meaning at least one additional tx.
2.  Option 2: splice-in is efficient (only the splice-in tx appears onchain).
    Drawback is that subsequent updates can only occur after the splice-in tx is deeply confirmed.
    * This can be mitigated somewhat by maintaining a pre-splice-in and post-splice-in mechanism, until the splice-in tx is deeply confirmed, after which the pre-splice-in version is discarded.
      Updates need to be done on *both* mechanisms until then, and any introduced money is "unuseable" anyway until the splice-in tx confirms deeply since it would not exist in the pre-splice-in mechanism yet.

But perhaps a more interesting thing (and more in keeping with my sentiment "a future where most people do not typically have single-signer ownership of coins onchain") would be to transfer funds from one multiparticipant offchain mechanism to another multiparticipant offchain, by publishing a single transaction onchain.
It may be doable via some extension of my proposed ritual for changing membership set.

>
> balance change (similar to membership change):
> * when channel parties want to add or remove some of the finalized value in the channel
> * close and reopen a new channel via something like a channel splicing transaction to the layer one blockchain
> * should be optimized for privacy and low on-chain fees paid for by parties adding and removing value from the channel
>
> uncooperative close:
> * when one or more nodes fails to sign the next channel state update
> * use a layer one transaction to commit both finalized and un-finalized outputs from the most recent channel output state
> * script timeouts determine when channel parties should uncooperatively close the channel if not all parties have signed the next 'update' and 'settlement' transaction
>
> 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.

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

>
> transaction fees:
> * updates to layer two channels do not incur transactions fees
> * invalid updates dropped to layer one should be paid by cheating node
> * splice in/out transactions should be paid by requesting signers only
> * do transaction fees prevent 'griefing' attacks?
>
> 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.

>
> 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).

Regards,
ZmnSCPxj

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

[Christian Decker]

ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
>> cooperative close:
>> * when all parties mutually agree to close the channel
>> * close the channel with a layer one transaction which finalizes the outputs from the most recent channel output state
>> * should be optimized for privacy and low on-chain fees
>
> Of note is that a close of an update mechanism does not require the
> close of any hosted update mechanisms, or more prosaically, "close of
> channel factory does not require close of hosted channels".  This is
> true for both unilateral and cooperative closes.
>
> Of course, the most likely reason you want to unilaterally close an
> outer mechanism is if you have some contract in some deeply-nested
> mechanism that will absolute-locktime expire "soon", in which case you
> have to close everything that hosts it.  But for example if a channel
> factory has channels A B C and only A has an HTLC that will expire
> soon, while the factory and A have to close, B and C can continue
> operation, even almost as if nothing happened to A.

Indeed this is something that I think we already mentioned back in the
duplex micropayment channel days, though it was a bit hidden and only
mentioned HTLCs (though the principle carries over for other structures
built on the raw update mechanism):

> The process simply involves one party creating the teardown
> transaction, both parties signing it and committing it to the
> blockchain. HTLC outputs which have not been removed by agreement can
> be copied over to the summary transaction such that the same timelocks
> and resolution rules apply.

Notice that in the case of eltoo the settlement transaction is already
the same as the teardown transaction in DMC.

>> membership change (ZmnSCPxj ritual):
>> * when channel parties want to leave or add new members to the channel
>> * close and reopen a new channel via something like a channel splicing transaction to the layer one blockchain
>> * should be optimized for privacy and low on-chain fees paid for by parties entering and leaving the channel
>
> Assuming you mean that any owned funds will eventually have to be
> claimed onchain, I suppose this is doable as splice-out.
>
> But note that currently we have some issues with splice-in.
>
> As far as I can tell (perhaps Lisa Neigut can correct me, I believe
> she is working on this), splice-in has the below tradeoffs:
>
> 1.  Option 1: splice-in is async (other updates can continue after all participants have sent the needed signatures for the splice-in).
>     Drawback is that spliced-in funds need to be placed in a temporary
>     n-of-n, meaning at least one additional tx.

Indeed this is the first proposal I had back at the Milan spec meeting,
and you are right that it requires stashing the funds in a temporary
co-owned output to make sure the transition once we splice in is
atomic. Batching could help here, if we have 3 participants joining they
can coordinate to set the funds aside together and then splice-in at the
same time. The downside is the added on-chain transaction, and the fact
that the funds are not operational until they reach the required depth
(I don't think we can avoid this with the current security guarantees
provided by Bitcoin). Notice that there is still some uncertainty
regarding the confirmation of the splice-in even though the funds were
stashed ahead of time, and we may end up in a state where we assumed
that the splice-in will succeed, but the fees we attached turn out to be
too low. In this case we built a sandcastle that collapses due to our
foundation being washed away, and we'd have to go back and agree on
re-splicing with corrected fees (which a malicious participant might
sabotage) or hope the splice eventually confirms.

> 2.  Option 2: splice-in is efficient (only the splice-in tx appears onchain).
>     Drawback is that subsequent updates can only occur after the splice-in tx is deeply confirmed.
>     * This can be mitigated somewhat by maintaining a pre-splice-in
>     and post-splice-in mechanism, until the splice-in tx is deeply
>     confirmed, after which the pre-splice-in version is discarded.
>       Updates need to be done on *both* mechanisms until then, and any
>     introduced money is "unuseable" anyway until the splice-in tx
>     confirms deeply since it would not exist in the pre-splice-in
>     mechanism yet.

This is the more complex variant we discussed during the last
face-to-face in Australia, and it seemed to me that people were mostly
in favor of doing it this way. It adds complexity since we maintain
multiple variants (making it almost un-implementable in LN-penalty),
however the reduced footprint, and the uncertainty regarding
confirmations in the first solution are strong arguments in favor of
this option.

> But perhaps a more interesting thing (and more in keeping with my
> sentiment "a future where most people do not typically have
> single-signer ownership of coins onchain") would be to transfer funds
> from one multiparticipant offchain mechanism to another
> multiparticipant offchain, by publishing a single transaction onchain.
> It may be doable via some extension of my proposed ritual for changing
> membership set.

Aside from a bit more coordination I don't see any roadblocks to do
this, and it'd be an awesome improvement. It even allows sub-dust
transfers between channels, as long as the total funds in the channel
remain above dust :-)

>> 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. The
footprint would be 1 unilateral close, n outputs for participants, m
outputs for contracts built on top, and 1 open transaction that
recollects all outputs in which the non-responding participant is not a
co-signer. The main advantage is that we can avoid downtime.

Just spit-balling here, since it'd leak some of the update logic back
into the contracts built on top of the update mechanism, which for me is
enough to discard this idea again.

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

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

>> 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).

It may be a bit much added complexity for a small complexity to be
honest, hopefully this won't be needed too often :-)

Cheers,
Christian

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

[ZmnSCPxj]

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

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

[Christian Decker]

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