{"type":"rich","version":"1.0","author_name":"npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xp","author_url":"https://nostr.ae/npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-07-28\n🗒️ Summary of this message: The motivation for multipath keysend is to allow for splitting payments into multiple parts, ensuring the receiver can only claim the payment once all parts have arrived. This adds complexity to keysend, but may be useful for certain use cases.\n📝 Original message:\nWhat is the motivation for multipath keysend? Why not just make\nseveral independent keysend payments with different payment hashes?\nWe should make sure that there is a user need before adding complexity\nto keysend, especially since we're already working on BOLT 12 which\nsupports multipath and even provides a proof of payment.\n\nLe ven. 28 juil. 2023 à 09:24, ZmnSCPxj via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e\n\u003e Good morning list,\n\u003e\n\u003e I would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments.\n\u003e\n\u003e In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.\n\u003e\n\u003e In the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver.\n\u003e\n\u003e For example, suppose we want to split the `keysend` into 2 parts.\n\u003e Let us select a true preimage `p` at random.\n\u003e Then, we generate the payment hash `h = SHA256(p)`.\n\u003e\n\u003e Then, we generate a new 256-bit scalar, `a`.\n\u003e For one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR.\n\u003e All parts use the same payment hash `h`.\n\u003e\n\u003e The receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes.\n\u003e Instead of failing, it holds the payment, using the usual basic multipath payment rules.\n\u003e\n\u003e When the receiver receives another part, it will XOR together the supposed preimages.\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e 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.\n\u003e\n\u003e 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`.\n\u003e If the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.\n\u003e 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`.\n\u003e The same feature bit 55 can be reused.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}