Batched Splicing Considered Risky

The assumption of splicing design has always been that the splicing transaction is offchain and therefore technically 0-conf.

A key difference between offchain and 0-conf is: an offchain mechanism generally has a transaction with a single input that happens to be signed by a n-of-n consensus. While on the other hand, something is generally considered “0-conf” if its input(s) is/are potentially signed by just one signatory. The reason why “offchain” is safe compared to “0-conf” (by the above definitions) is that an “offchain” double-spend requires cooperation of the entire group of signatories which means that a possible receiver can always just refuse to sign a double-spend that would lose them funds, while a “0-conf” receiver is at the whim of the signer since the transaction can be re-signed to not include their funds.

The problem is that existing splice-in designs involve one input that is n-of-n consensus (the pre-splce funding tx out) and a number of other txins that are potentially single-signed by one participant, thus potentially allowing that single participant to double-spend the splice tx. What I am pointing out is that splice is an unholy mix of 0-conf and offchain.