Hi Jozef, > I'm working on a project that uses LND with Atomic Multi-path Payments > (AMP) invoices. It seems there isn't any mobile lightning wallet that is > able to send sats to AMP invoices.
Any mobile wallet built on lnd v0.14 should be able to send to the reusable invoices (has the required feature bit set for AMP only). Wallets built on lnd v0.13 will be able to send to the invoices, but only once, unless they manually specify the `set_id` flag to a random value for any subsequent sends. We have some new-ish higher level API docs here: https://docs.lightning.engineering/lightning-network-tools/lnd/amp. > What is the future of AMP? Is it a dead-end or can it make it to standard? > Is there any other lightning implementation that supports it? Great questions! I view it as the successor to keysend (same thing but support payment splitting and a re-useable invoice format, though it isn't as widely propagated yet. The next step here is for us to finalize the current spec draft [1] and propose it as either a BOLT or a bLIP (the spec doc linked uses a more bLIP like format, but this OG PR adds things to BOLT 4: https://github.com/lightning/bolts/pull/658). It's been on my TODO list for sometime now, but I should be able to get to it over the next few weeks! When PTLCs are eventually rolled out across the network, AMP can be updated to use discrete-logs instead of payment hashes (Discrete Log Atomic Multi-Path, so DAMP? lol..), and also support receiver secret-reveal (which some consider to be a necessary component for "proof of payments") by combining each share with a receiver specified public key. [1]: https://github.com/cfromknecht/lightning-rfc/blob/bolt-amp/21-atomic-multi-path-payments.md -- Laolu On Fri, Feb 18, 2022 at 5:10 AM Jozef Hutko <jozef.hu...@gmail.com> wrote: > Hello, > > I'm working on a project that uses LND with Atomic Multi-path Payments > (AMP) invoices. It seems there isn't any mobile lightning wallet that is > able to send sats to AMP invoices. What is the future of AMP? Is it a > dead-end or can it make it to standard? Is there any other lightning > implementation that supports it? > > Thanks and Regards > Jozef > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
