Batched Splicing Considered Risky

[ajtowns]

@ZmnSCPxj

B can actually double-spend channel-with-B (pre-splice) using a revoked commitment transaction.

Why wouldn’t they just do a normal unilateral close, using the current non-splice commitment transaction?

In either case, you now have access to your funds with B’s channel, and can redo the splice/open with C/D, so what’s the problem?

@ZmnSCPxj

D, having seen me broadcast the batched transaction that includes the open of the channel-with-D, has now, naively, sent the preimage to the HTLC for the JIT channel payment.

The sensible thing to do would be for you to reject the HTLC when it reached you, refusing to forward it to D, because your channel isn’t suitable for zeroconf use, because you don’t control all the inputs. Maybe you could have a super-advanced version of zeroconf channels where the channel can survive being given an entirely new funding tx (in which case you just updated the funding tx for the channel when B closes that channel), but I don’t think we have that currently?

@ZmnSCPxj

I need to be able to tell C “forget about the splice, let us go back to our original channel funding output”, without having to close the channel-with-C, in order to try again with a different batched splice that no longer involves the peer B, or to splice in to C with my onchain funds instead of from the channel-with-B.

I think if you have a splice transaction that spends utxo X, but utxo X was already spent by transaction T that’s had 6 confirmations, dropping the splice transaction should be fine?