Thomas HUET [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-28 🗒️ Summary of this message: The motivation ...
📅 Original date posted:2023-07-28
🗒️ 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.
📝 Original message:
What is the motivation for multipath keysend? Why not just make
several independent keysend payments with different payment hashes?
We should make sure that there is a user need before adding complexity
to keysend, especially since we're already working on BOLT 12 which
supports multipath and even provides a proof of payment.
Le ven. 28 juil. 2023 à 09:24, ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> a écrit :
>
> 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
🗒️ 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.
📝 Original message:
What is the motivation for multipath keysend? Why not just make
several independent keysend payments with different payment hashes?
We should make sure that there is a user need before adding complexity
to keysend, especially since we're already working on BOLT 12 which
supports multipath and even provides a proof of payment.
Le ven. 28 juil. 2023 à 09:24, ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> a écrit :
>
> 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