Author: Bryan Bishop 2018-02-08 17:49:23
Published on: 2018-02-08T17:49:23+00:00
Olaoluwa Osuntokun and Conner Fromknecht have designed a scheme called Atomic Multi-Path Payments (AMP) to enable atomic payments over Lightning that can be made through multiple payment flows without reusing the payment hash. The protocol goals include atomicity, avoiding payment hash reuse, order invariance, and non-interactive setup. The receiver must wait until all HTLCs arrive before pulling them, ensuring that the logical transaction succeeds or fails in its entirety. The sender uses additive secret sharing to ensure that the receiver cannot pull the payment until they have enough shares to reconstruct the original pre-image. The protocol is end-to-end between sender and receiver, requires no fundamental changes to the protocol, and can be experimented with on Lightning today with the addition of a new feature bit to gate this new feature.Sending pay payments predominantly over an AMP-like protocol has several clear benefits such as eliminating the constraint that a single path from sender to receiver with sufficient directional capacity, reducing strain from larger payments on individual paths, potential fee savings for larger payments, allowing for logical payments larger than the current maximum value of an individual payment, improving privacy of LN intermediaries, and increasing the set of possible paths a partial payment could have taken.The design can be seen as a generalization of the single, non-interactive payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode extra data for the receiver. In that design, only the sender and receiver need to implement this feature in order for it to function, which can be announced using a feature bit.The Lightning Network currently uses a 65-byte payload to instruct each node on how to forward a payment, including the realm, next node, amount, outgoing CLTV, and an HMAC over the entire thing. 12 bytes per hop are currently unused and can be repurposed for application protocols to signal new interpretation of bytes and deliver additional encrypted+authenticated data to each hop. The protocol has a hard limit of 20-hops, but with AMPs (Atomic Multi-path Payments), there is a solution that leverages EOBs to deliver additive shares of a base preimage, from which partial payments can be derived. The protocol allows for up to 2^64-1 satoshis to be sent in a single payment.The sender initiates the payment by building the base preimage and sampling n additive shares, taking the sum to compute BP. The sender then constructs n partial payments, determining the partial preimage and payment hash for each one. The sender initiates the i'th payment by constructing a route to the destination with value v_i and payment hash h_i. The tuple (ID, n, s_i) is included in the EOB to be opened by the receiver. The first byte of the unused padding bytes in the payload is repurposed to signal version 0x01 of the AMP protocol to include the three-tuple within the per-hop payload for the final destination. The sender can retry partial payments just as they would normal payments since they are order invariant and indistinguishable from regular payments to intermediaries in the network.Upon the arrival of each partial payment, the receiver will iteratively reconstruct BP and do some bookkeeping to figure out when to settle the partial payments. Each EOB is decoded to retrieve (ID, n, s_i), where i is the unique but unknown index of the incoming partial payment. The receiver has access to a persistent key-value store DB that maps ID to (n, c*, BP*). In the basic protocol, the receiver caches the first n it sees and verifies that all incoming partial payments have the same n. The receiver should reject all partial payments if any EOB deviates. Next, the persistent store is updated with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing the reconstruction by one step.
Updated on: 2023-05-20T05:11:49.306709+00:00