Implement Atomic Multi-path Payments using Simple Taproot Channels #8568
Description
I was surprised to find no issue (not even a closed one) tracking these missing features in CLN, so here we are.
Simple Taproot Channels
Rather than using P2WSH multisignature outputs for channel funding, we can use MuSig2 to produce scriptless P2TR multisignature outputs. This greatly reduces the on-chain size of mutual-close, unilateral-close, and splicing transactions, as a scriptless P2TR channel funding output can be spent by means of a single signature and without an explicit public key in the input witness data since the key was already embedded in the funding output.
Note that Simple Taproot Channels are a half measure on the way to Point Time-Lock Contract (PTLC) channels.
Atomic Multi-path Payments
The dirty little open secret of the Lightning Network is that its officially spec'd Multi-Path Payments (MPP) are not atomic: a payment recipient is free to reveal the payment pre-image even without having received the expected sum of payment parts. Although in many cases there is an economic incentive for it not to do this, there is no cryptographic guarantee against it, and worse, it is unclear whether the user would be alerted if this were to occur. (Would the payment attempt appear to have failed entirely even though some funds would have been irrecoverably transferred anyway?)
Before this milquetoast MPP entered the chat, there was the concept of true AMP, which is cryptographically atomic but requires adaptor signatures. Fortunately, we now have Schnorr signatures in Taproot, so we can get adaptor signatures for free. Given that we're implementing Simple Taproot Channels, which use Taproot for the funding output, we can go ahead and use Taproot for the HTLC outputs too, and thus we can use Schnorr adaptor signatures to implement AMP.
Note that this “O.G. AMP” is a half measure on the way to so-called “High AMP,” which uses adaptors for the purposes of both onion layering and payment splitting concurrently. Gijs van Dam wrote a pretty good overview of it all.
Notably, LND has supported both Simple Taproot Channels and Atomic Multi-path Payments for some time now. Of course, the LND developers never seem to care about collaboratively drafting and vetting protocol specifications before rushing ahead into implementation, so it is possible that a properly spec'd implementation of these features would turn out to be incompatible with LND's ad-hoc implementation, and the LND developers likely would never expend the resources to implement the finalized spec ex post facto. (Flashbacks of the X2 vs. K56flex war.)