rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2023-07-27 🗒️ Summary of this message: A scheme for creating a `keysend` protocol that allows for multipath payments is proposed, where the receiver can claim the payment once all parts have arrived. 📝 Original message: 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