{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-07-27\n🗒️ 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.\n📝 Original message:\nGood morning list,\n\nI would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments.\n\nIn `keysend`, the preimage is embedded as TLV 5482373484 with length 32.\n\nIn the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver.\n\nFor example, suppose we want to split the `keysend` into 2 parts.\nLet us select a true preimage `p` at random.\nThen, we generate the payment hash `h = SHA256(p)`.\n\nThen, we generate a new 256-bit scalar, `a`.\nFor one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR.\nAll parts use the same payment hash `h`.\n\nThe receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes.\nInstead of failing, it holds the payment, using the usual basic multipath payment rules.\n\nWhen the receiver receives another part, it will XOR together the supposed preimages.\nIn 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.\n\nThe 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.\nThis 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.\n\nA 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`.\nIf the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.\nThus, 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`.\nThe same feature bit 55 can be reused.\n\nRegards,\nZmnSCPxj"}