From lf-lists at mattcorallo.com Sat Jul 29 16:37:26 2023 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Sat, 29 Jul 2023 09:37:26 -0700 Subject: [Lightning-dev] Multipath Keysend In-Reply-To: References: Message-ID: <492172ad-a6dd-3657-e01e-2741cb5bc926@mattcorallo.com> IMO we should revisit this post-PTLCs, but in the mean time, folks should allow for classic keysend to be MPP. IIRC CLN already does, LDK added support for it not too long ago, and it'd be nice if others did too. Just like with normal lightning MPP payments - if the recipient decides to claim less than we tell them we want to send them, that's up to them, and if someone gets a donation and decides they don't want all of it but only a part, so be it. The sender has sent the payment as far as they're concerned - its been claimed! Matt On 7/27/23 10:13?AM, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > I would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments. > > In `keysend`, the preimage is embedded as TLV 5482373484 with length 32. > > In the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver. > > For example, suppose we want to split the `keysend` into 2 parts. > Let us select a true preimage `p` at random. > Then, we generate the payment hash `h = SHA256(p)`. > > Then, we generate a new 256-bit scalar, `a`. > For one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR. > All parts use the same payment hash `h`. > > The receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes. > Instead of failing, it holds the payment, using the usual basic multipath payment rules. > > When the receiver receives another part, it will XOR together the supposed preimages. > In the above case, it would get `a` and `a ^ p`, which when XORed together result in `a ^ a ^ p` or `p`, which is now the correct preimage, and the receiver can now claim the entire complete funds. > > The same technique would work with any number of parts --- if we split into `n` parts, we generate `n - 1` additional random scalars and use it for the first `n - 1` parts, then XOR all of them with the scalar-to-be-split for the `n`th part. > This scheme also works for dynamic splitting, i.e. if you are splitting a part that was already split off from a part that was already split off from a part etc. > > A sender can detect if the receiver does not support multipath `keysend` if a part reaches the receiver and it errors with `incorrect_or_unknown_payment_details`. > If the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`. > Thus, support for this on the receiver side does not need to be specially announced via a new feature bit --- an MPP-capable sender can simply try to split, and if it gets an `incorrect_or_unknown_payment_details`, knows that the receiver does not support multipath `keysend`. > The same feature bit 55 can be reused. > > Regards, > ZmnSCPxj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev