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@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@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
