RFC: eltoo-like channels for fiber network

[contrun]

Eltoo (the paper), or LN-Symmetry, is a penalty free solution with the broadcastability of latest state update guarantied. I think eltoo-like channels are a great match for fiber network because, they offers the following advantages.

Rational of adopting eltoo in fiber network

• No need to toxic information (term borrowed from the paper, which refers to revocation secrets that may result in asset loss if accidentally revealed), as the latest state update are guaranteed broadcast-able. This greatly simplifies the state management and watch tower implementation. We now need only to keep the latest state in the node.
• Orthogonal to the payment channel feature existing in lightning/fiber network. We can still use the payment channel network to transfer assets for two nodes that are not directly connected to each other.

Overview of eltoo

Refer to the paper for details. Below is a simplified overview of eltoo.

Eltoo makes it possible for later state update transaction (akin to commitment transaction in lightning/fiber network parlor) to consume any earlier state update transaction output. If an older state update transaction is broadcasted to the network, then we can always consume this transaction output with the newer state update transaction, which in turn can be settled to the desired outputs for both parties.

To be more concrete, a state update transaction is valid if the following two conditions are satisfied

• Valid signature for the state update
• Version number is newer

The trick here is to exclude the outpoint of input UTXO from hashing while obtaining the message of the signature (SIGHASH_NOINPUT in the paper). This way, we can consume any state update transaction output because we do not care about the inputs while verify the signature. As long as version number is newer, the transaction is valid. This implies that the latest state update is always broadcast-able. And since we can always broadcast the latest state, we don't even have to punish the peer for publishing old state updates.

What we need to do if we want to implement eltoo-like solution in fiber network

I think the basic mechanism of comparing state number is already presented in this PR. We still need to implement a few things.

SIGHASH_NOINPUT

Currently commitment lock uses transaction hash as the message to sign and verify. This will bind the signature to the transaction input. As mentioned above, in eltoo, we need to consume any older state update input and create the newest state update output. So we need to change the hashing process of commitment lock. In CKB, we can manually read necessary transaction fields and hash them. One thing to note is that, we need to be careful about which things to include while hashing. For example, the state number should always be hashed, as otherwise the adversary can just change state number in the transaction and create a valid "newer" transaction.

settlement transaction

State update transaction should always be time-locked to give the honest party a chance to discover old state update transaction is broadcasted. This means we need an additional phrase to settle the transaction (i.e. to send assets to each parties). This is called the settle transaction in eltoo.

To make this compatible to payment channel network, we need to create HTLC outputs in the settlement transaction. Then we may have to handle the minimal CKB amount for a cell. I think we need to create a separate settlement lock contract as current commitment lock.

P2P message protocol

Since we now need to sign two transactions while committing state updates, the peer message protocol definitely needs to adjust accordingly. Below are a few notable changes to the p2p message protocol.

• We don't need revocation secrets etc.
• We need to send the partial signatures to both state update transaction and settlement transaction.
• The version number is shared among both parties, which means we have to handle simultaneous state updates.

Alternatives

Status quo asymmetrical channels

Currently channel participants have different set of commitment transactions so as to guarantee the safety (the ability to punish adversary publishing old transactions) and liveliness (the ability to force close the channel under counter-party's unresponsiveness) properties. To make watch tower implementation simple, we introduced checking state updates freshness by using version number. Augmented with SIGHASH_NOINPUT, we can implement eltoo like channels. Current, implementing the thing as mentioned, we can enjoy eltoo' simplification to the state management and watch tower implementation.

Possible drawbacks

Although the concepts are straightforward for eltoo, it was a research project without any serious code implementation (such endeavour only appeared recently), many of the tradeoffs of eltoo remain unclear until we have some serious engineering efforts.

[contrun]

Closing. Daric is essentially eltoo with revocation. #10