Atomic Multi-Path Payments

Overview

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.