[Lightning-dev] Witness asymmetric payment channels

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Aug 27 01:48:13 UTC 2020

Good morning LL, and other LNers...

Since we want to upgrade to Decker-Russell-Osuntokun in the future anyway, we still need to solve this "simultaneous HTLC" problem.

So here is another cut at this, without the token-passing:

* Perform a coin toss whenever simultaneous HTLC offers occur.
* Typically, a multiparty coin-toss involves two rounds: first commitments to random numbers are sent, then the actual random numbers are sent, and then after validating that they match commitments, their lowest bits are XORed and the resulting bit is heads/tails.
  * However, we should recognize that HTLCs hashes are not under full control of anyone other than the payee, and if somebody is *offering* an HTLC, it is either the payer, or a forwarding node.
  * Even *if* it is under control of the offerer of the HTLC, once an HTLC is instantiated, it consumes capacity on the channel (`max_accepted_htlcs`).
    Thus, even if one counterparty keeps winning the coin toss, it will eventually run out of capacity to add a new HTLC.
  * So we could just use the HTLC hashes to seed the random numbers of the coin toss.
    For example, it could be salted with the node IDs of the channel parties, then the resulting hash of the hash is used in the deterministic coin toss.

So let us consider two messages:

* `add_htlc` containing 1 or more HTLCs the sender wants to add.
* `ack_htlc` containing nothing.

Whenever a node wants to add one or more HTLCs, it sends `add_htlc`, then waits for *either* `add_htlc` *or* `ack_htlc`.
If it receives an `ack_htlc`, then it is the only one with HTLCs to add, so they add the HTLCs and send partial signatures of the new state to each other.

If we receive an `add_htlc` without having sent an `add_htlc` of our own, we just send out an `ack_htlc` and proceed to partial signature sharing.

However, if both peers sent `add_htlc` to each other, they perform a coin toss ritual.
They concatenate their node IDs (lexicographic order), then concatenate those with the set of HTLCs being added by each side.
They hash the concatenation, and then take the lowest bit of that hash.
If it is 0, then the node that owns the `/0` direction won and the HTLCs it added are what goes in the next update (and the loser has to buffer up its changes until after the update ritual completes).
If it is 1, then the node that owns the `/1` direction won.


More information about the Lightning-dev mailing list