AMP: Atomic Multi-Path Payments over Lightning

Summary:

The Lightning Network has introduced a new protocol called AMP (Atomic Multi-path Payments), which allows for multiple payment flows without reusing any payment hashes. This protocol has several benefits such as supporting larger payment flows, reducing strain on individual paths, allowing for logical payments larger than the current maximum value of an individual payment, and improving privacy with sufficient path diversity.To ensure atomicity, the receiver should not be able to settle any of the partial payments until all of them have arrived. Payment preimages validated by the consensus layer should be distinct for each partial payment to avoid correlation of the partial payments and ensure that malicious intermediaries straddling partial payments cannot steal funds.The protocol repurposes unused space in the onion per-hop payload of the onion blob to signal the protocol and deliver some protocol-specific data, then uses additive secret sharing to ensure that the receiver can't pull the payment until they have enough shares to reconstruct the original pre-image. 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.The Lightning Network currently uses a 65-byte payload to give each node instructions on how to forward a payment, including the realm or chain to forward on, the next node to forward to, the amount to forward, the outgoing CLTV, and an HMAC over the entire thing. The protocol currently has a hard limit of 20 hops, but with 12 bytes for each hop that are currently unpurposed, application protocols can signal new interpretation of bytes and deliver additional encrypted and authenticated data to each hop.The proposed solution is Atomic Multi-path Payments (AMPs) which leverages EOBs to deliver additive shares of a base preimage from which partial payments' preimages can be derived. The receiver can only construct this value after having received all of the partial payments, satisfying the atomicity constraint. The sender's parameters to the sending procedure are a random identifier ID, the number of partial payments n, and the total payment value V where V = v_1 + … + v_n.For each i in [1,n], the sender deterministically computes the partial preimage r_i = H(BP || i) by concatenating the sequence number i to the base preimage and hashing the result. The sender initiates the i’th payment by constructing a route to the destination with value v_i and payment hash h_i, and includes the tuple (ID, n, s_i) in the EOB to be opened by the receiver. Upon the arrival of each partial payment, the receiver iteratively reconstructs BP and does some bookkeeping to figure out when to settle the partial payments. 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, we update our persistent store with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing the reconstruction by one step. The sender can retry partial payments just as they would normal payments, since they are order invariant and would be indistinguishable from regular payments to intermediaries in the network.

Updated on: 2023-05-20T07:58:13.227958+00:00