Splice Signing Order Woes

SpliceSignOrder.md

Imagine a three node network with two channels

A <-> B <-> C

Let's say B would like to perform two splices:

splice-out 10M sats from A <-> B
splice-out 10M sats from B <-> C

B would then like to merge these two splices into a single transaction. This is done in the standard way, namely:

1. Initiate splice-out with A, continue process until A finalizes. Do not finalize ourself and pause here.
2. Initiate splice-out with C, add inputs & outputs from splice attempt (1). Finalize up to the point of signature exchange.
3. Pass inputs & outputs from splice attempt (2) to A. Finalize up the point of signature exchange.

At this point all nodes have a single matching transation that performs a splice for A <-> B and B <-> C.

By existing tie break rules current de-facto rule, the initiator (B) must sign first.

A is waiting to receive signatures for all inputs, which include input(s) controlled by C

• It will not send signatures until it receives all of these

C is waiting to receive signatures for all inputs, which include input(s) controlled by A

• It will not send signatures until it receives all of these

B has it's own signatures but not those for A or C. It cannot send the complete package for either splice, even though it is required to for both.

To break this race condition, the tie break rule must be updated for the accepter to sign first.

The only case where there can be a deadlock is when B's node_id is less than A and C's node_ids and:

• funding_amount_ab + funding_amount_bc + amount_c = amount_a
• funding_amount_ab + funding_amount_bc + amount_a = amount_c

The only case where those two inequations hold is if amount_a = amount_c and funding_amount_ab = funding_amount_bc = 0 (dual-funding without contributing where both peers use the exact same amount). It should be easy to work around that specific case when it happens or simply abort, as it shouldn't happen "by chance".

Yeah dual having 0 initial channel balances creates this problem but seems easy to work around. I imagine it happening if a user does a double lease with dual for the same amount.

Say a single dual open that is two lease requests that result in this:

B <- A (10M)
B <- C (10M)

We could pop out an error saying lease amounts cannot be exactly equal, and / or automatically jiggle the amount by a sat.