# Atomic Multi-Path Payments Links: [[Lightning]], [[Spontaneous payments]] ## ["Makes keysend obsolete"](https://github.com/lightningnetwork/lnd/issues/5044#issuecomment-783775382) Responses to GitHub issue on [[2022-02-24]] Links: [[Keysend]] [[Olaoluwa Osuntokun|roasbeef]]: Our main focus right now is deploying AMP, which is a better version of keysend as it supports payment splitting, recurring push payments, a static invoice, and more. We wouldn't be opposed to a PR that adds in their experimental feature bit (though it's odd it's a lower feature bit). [[Conner Fromknecht|cfromknecht]]: The feature bit has _not_ been standardized yet, and as [@Roasbeef](https://github.com/Roasbeef) mentions keysend will be made obsolete in the near term by work on AMP. ### More comments in a [[c-lightning]] [thread](https://github.com/ElementsProject/lightning/issues/4299#issuecomment-781606865) There hasn't been much effort on our part to standardize because keysend will be made obsolete by [lightning/bolts#658](https://github.com/lightning/bolts/pull/658) (or the rewrite coming soon-tm 😉), which generalizes the technique to more than one HTLC. ## [BOLT04: Atomic Multi-path Payments #658](https://github.com/lightning/bolts/pull/658) PR for inclusion into [[BOLT]] 04 penned by [[Conner Fromknecht|cfromknecht]] on [[2019-08-15]] (not yet merged) ### Summary One of the biggest distinctions (some would argue drawback) from [Base AMP](https://github.com/lightning/bolts/pull/658#643) is that the sender does not receive a preimage as a result of a successful payment. However, the lack of a "proof" of payment unlocks a range of novel features: - Partial Payment Decorrelation: each subpayment uses a different payment hash, offering stronger privacy from intermediaries - Concurrent-Safe Reusable Invoices: As a by-product of the sender generating the preimages and payment hashes, an invoice is no longer single use. The payer conveys to the payee which invoice is being settled by including the invoice's payment hash. All payments made to the invoice can be tracked as a single subscription or account, and each payment receives it's own unique `set_id`. Multiple, concurrent payments can be made to the same invoice and properly reconstructed using the enclosed `set_id`. - A subscription invoice might be generated as an invoice with the desired subscription amount, which will be verified each time the user pays. - An account invoice, e.g. a recurring invoice for funding an exchange, would use a zero-value invoice, allowing deposits (or withdrawals) of arbitrary amounts. - [[Spontaneous payments|Spontaneous]] AMPs: More often discussed in the single-shot case, this describes users making payments to other nodes using just their public key (handwaves hop hints). However, AMP is really a generalization of the single-shot case, so we propose to merge these two concepts under a single, unified proposal. All of the tangential benefits of AMP are carried over to spontaneous single-shot payments (SSSP?), without introducing any additional code complexity. ## [AMP: Atomic Multi-Path Payments over Lightning](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) Original proposal by [[Olaoluwa Osuntokun|Laolu]] on [[2018-02-06]] ## [Page](https://bitcoinops.org/en/topics/atomic-multipath/) on [[Bitcoin Optech]] **Atomic Multipath Payments (AMPs)**, sometimes called **Original AMP** or **OG AMP**, allow a spender to pay multiple hashes all derived from the same preimage—a preimage the receiver can only reconstruct if they receive a sufficient number of shares. Unlike Simplified Multipath Payments ([SMP](https://bitcoinops.org/en/topics/multipath-payments/)), this only allows the receiver to accept a payment if they receive all of the individual parts. Each share using a different hash adds privacy by preventing the separate payments from being automatically correlated with each other by a third party. The proposal’s downside is that the spender selects all the preimages, so knowledge of the preimage doesn’t provide cryptographic proof that they actually paid the receiver. Both AMP and SMP allow splitting higher value HTLCs into multiple lower value HTLCs that are more likely to individually succeed, so a spender with sufficient liquidity can use almost all of their funds at once no matter how many channels those funds are split across. ## [Announcing lnd 0.13-beta: Get Amped on Lightning!](https://lightning.engineering/posts/2021-06-17-lnd-v0.13/) [[Lightning Labs]] blog on [[2021-06-17]] In this release, we’ve added initial support for Atomic Multi-Path Payments (AMP). AMP is the successor to the widely used “keysend” protocol as it enables payments to be sent in multiple shards similar to Multi-Path Payments (MPP). Unlike MPP, the receiver cannot pull the payment until all the payment shards arrive. This trait makes the new payment type more useful for payment-splitting aware probing. In addition to providing a new first-class method for spontaneous payments, AMP also allows invoices to be effectively re-used. AMP invoices look just like normal invoices, however they signal that the invoice must be paid using the AMP protocol. ### Receiving/Sending Spontaneous Payments **Receiving:** To automatically accept incoming spontaneous AMP payments, users simply need to set a configuration option (`accept-amp=1`). Users can also accept one-time payments to an AMP Invoice without the configuration option. **Sending:** Sending a spontaneous AMP payment requires specifying the amount and pubkey of the destination in addition to the `--amp` flag on the command line. Users of the RPC interface will need to set the corresponding field within the SendPaymentV2 request. Note that without specifying any routing/hop hints, this will only work for nodes in the public channel graph. ### AMP Invoices An AMP invoice for a spontaneous payment seems counterintuitive at first, however this will unlock recurring payments (eg. subscriptions, deposits/withdrawals, etc)! Recurring invoices are not implemented in this release, but will be available at a later point. For now an AMP invoice can only be settled by one payment. That said, this release does include support for simulating recurring payments, making the existing AMP invoices "pseudo-reusable" by allowing users to specify a new random payment address. The default expiry for AMP invoices is 30 days. ## [[lnd]] Release 0.14.0: [Re-Usable Static AMP Invoices](https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.14.0.md#re-usable-static-amp-invoices) - Associated pull request: [LND#5803](https://github.com/lightningnetwork/lnd/pull/5803) [AMP invoices are now fully re-usable, meaning it's possible for an `lnd` node to use a static AMP invoice multiple times](https://github.com/lightningnetwork/lnd/pull/5803). An AMP invoice can be created by adding the `--amp` flag to `lncli addinvoice`. From there repeated payments can be made to the invoice using `lncli payinvoice`. On the receiver side, notifications will still come in as normal, but notifying only the _new_ "sub-invoice" paid each time. A new field has been added to the main `Invoice` proto that allows callers to easily scan to see the current state of all repeated payments to a given `payment_addr`. A new `LookupInvoiceV2` RPC has been added to the `invoicerpcserver` which allows callers to look up an AMP invoice by set_id, opting to only return relevant HTLCs, or to look up an AMP invoice by its `payment_addr`, but omit all HTLC information. The first option is useful when a caller wants to get information specific to a repeated payment, omitting the thousands of possible _other_ payment attempts. The second option is useful when a caller wants to obtain the _base_ invoice information, and then use the first option to extract the custom records (or other details) of the prior payment attempts.