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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
