Matt Morehouse [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-28 🗒️ Summary of this message: ZmnSCPxj ...
📅 Original date posted:2023-07-28
🗒️ Summary of this message: ZmnSCPxj proposes a scheme for a multipath payment protocol called "keysend" that allows for splitting payments into multiple parts.
📝 Original message:
Hi ZmnSCPxj,
This sounds very similar to AMP
(https://docs.lightning.engineering/lightning-network-tools/lnd/amp).
Does this scheme offer any improvements over AMP?
- Matt
On Fri, Jul 28, 2023 at 7:24 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> 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
🗒️ Summary of this message: ZmnSCPxj proposes a scheme for a multipath payment protocol called "keysend" that allows for splitting payments into multiple parts.
📝 Original message:
Hi ZmnSCPxj,
This sounds very similar to AMP
(https://docs.lightning.engineering/lightning-network-tools/lnd/amp).
Does this scheme offer any improvements over AMP?
- Matt
On Fri, Jul 28, 2023 at 7:24 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> 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