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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
