Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-28 🗒️ Summary of this message: The email ...
📅 Original date posted:2023-07-28
🗒️ Summary of this message: The email discusses a scheme for creating a multipath payment protocol using keysend, allowing the receiver to claim the payment once all parts have arrived.
📝 Original message:
Hi Z,
Or you can just use AMP and call it a day:
https://github.com/lightning/bolts/pull/658
-- Laolu
On Fri, Jul 28, 2023 at 12: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230728/540be4b8/attachment.html>;
🗒️ Summary of this message: The email discusses a scheme for creating a multipath payment protocol using keysend, allowing the receiver to claim the payment once all parts have arrived.
📝 Original message:
Hi Z,
Or you can just use AMP and call it a day:
https://github.com/lightning/bolts/pull/658
-- Laolu
On Fri, Jul 28, 2023 at 12: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230728/540be4b8/attachment.html>;