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.

Okay working through it:

• B adds zero sats
• A adds 1M sats
• C adds 1M sats

Now we have
amount_a: 1M
amount_b: 0
amount_c: 1M

And assume existing channels ab and ac are the same, say 10M

amount_ab: 10M
amount_bc: 10M

So for the signing order on splice_ab we see

1. B has 11M in incoming inputs
2. A has 10M in incoming inputs

Since (2) is less, A must sign first

And for the signing order on splice_bc we see

1. B has 11M in incoming inputs
2. C has 10M in incoming inputs

Since (2) is less, C must sign first

Which, I believe I see now, makes a tie actually impossible. Nice! 👍

I think there are still a few mistakes, because B adds both current channel funding outputs in every signing session.
With the amounts that you've chosen, the correct statements are:

So for the signing order on splice_ab we see

1. B has 21M in incoming inputs (the two current channel outputs + C's input)
2. A has 1M in incoming inputs

Since (2) is less, A must sign first

And for the signing order on splice_bc we see

1. B has 21M in incoming inputs (the two current channel outputs + A's input)
2. C has 1M in incoming inputs

Since (2) is less, C must 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".

I think there are still a few mistakes, because B adds both current channel funding outputs in every signing session. With the amounts that you've chosen, the correct statements are:

...

Oh this is an interesting point. The current spec is vague on which side gets to count the channel input itself for signing order calculations.

Making it explicitly the initiator makes sense to me.

I don't think the spec is vague, it says:

The initiator:
  - MUST `tx_add_input` an input which spends the current funding transaction output.

Since the signing order is then based on the tx_add_input each side sent, this is correctly specified already? The wording is weird though, it should probably be:

• MUST send tx_add_input for the current funding transaction output.

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.