Author: ZmnSCPxj 2023-07-27 17:13:59+00:00
Published on: 2023-07-27T17:13:59+00:00
A scheme for creating a `keysend` protocol that allows for multipath payments is being shared. In this scheme, the preimage is embedded as TLV 5482373484 with a length of 32. For multipath payments, the receiver can only claim the payment once all parts have arrived. To split the `keysend` into two parts, a true preimage `p` is randomly selected. The payment hash `h` is generated using `SHA256(p)`. A new 256-bit scalar `a` is generated. For one part, `a` is sent for TLV 5482373484, and for the second part, `a ^ p` (XOR operation) is sent. Both parts use the same payment hash `h`. When the receiver receives either part, it realizes that the supposed preimage does not match the actual HTLC payment hashes. Instead of failing, the receiver holds the payment and follows the basic multipath payment rules. Upon receiving another part, the receiver XORs together the supposed preimages. In the given example, it would result in `a ^ a ^ p` or `p`, which is now the correct preimage, allowing the receiver to claim the entire funds. This technique works with any number of parts by generating additional random scalars and XORing them with the scalar-to-be-split for the last part. The scheme also works for dynamic splitting. A sender can detect if the receiver doesn't support multipath `keysend` if a part reaches the receiver and errors with `incorrect_or_unknown_payment_details`. If the receiver supports multipath `keysend`, it will hold onto incoming HTLCs until MPP timeout and error with `mpp_timeout`. Support for this on the receiver side doesn't need to be specially announced via a new feature bit; an MPP-capable sender can try to split, and if it receives `incorrect_or_unknown_payment_details`, it knows the receiver doesn't support multipath `keysend`. The same feature bit 55 can be reused.
Updated on: 2023-08-11T15:56:58.163251+00:00