Atomic Multi-Path Payments
Alice has two channels with Bob
channel 1: 1 BTC
channel 2: 1 BTC
Alice wants to send 2 BTC to Bob
Bob sends a 2 BTC invoice to Alice
Alice cannot pay the invoice because each channel only has 1 BTC
Alice wants to send 2 BTC to Bob
Step 1
Bob sends a 1 BTC invoice to Alice
Alice pays 1 BTC to Bob through channel 1
Step 2
Bob sends a 1 BTC invoice to Alice
Alice pays 1 BTC to Bob through channel 2
Alice opens a channel with Bob.
Bob sends 2 BTC invoice to Alice
Alice pays 2 BTC to Bob by splitting the payment
1 BTC goes through channel1
1 BTC goes through channel2
Bob receives and combines the two payments to claim his BTC
Atomicity: Bob cannot receive the full payment until he receives all of the partial payments
Avoid Payment Hash Reuse: Each partial payment has a distinct payment hash
Order Invariance: Partial payment order does not matter
Non-interactive Setup: Bob does not have to know the transaction is an AMP
Alice generates two partial shares since she'll pay through two channels. In this example, we'll use two random numbers 123456 and 654321.
Alice generates a base pre-image (BP) by adding the partial shares. 123456 + 654321 = 777777. If Bob knows BP, then he can claim the funds.
Alice computes the partial pre-images by concatenating the base pre-image to the sequence number i, then hashing the result.
Alice creates the payment payments by hashing the partial pre-image. This makes each pre-image distinct and indistinguishable from the others.
Alice sends the partial payments and partial shares to Bob.
When Bob receives all of the payments, he will then combine partial shares to generate the base pre-image.
Bob can now use the base pre-image to generate the partial pre-images to claim funds.
If Bob does not receive all of the partial payments, then he cannot generate the base pre-image thus making it atomic.
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
