Atomic multi-path payments is one of the next generation technologies coming to Lightning, we look at two possible implementation proposals as discussed by ZmnSCPxj on Lightning-dev.
Feed for tag: atomic-multi-path-payments
Dmytro Piatkivskyi started the following discussion on lightning-dev regarding the topic of channel rebalancing.
There has been a lot of discussion on sending cycle transactions to oneself to ’re-balance’ the network. On LN mailing list [1] or numerous places elsewhere. There has been even a paper suggesting a smart mechanism to do the re-balancing (see Revive or Liquidity network [2]). My question is what do we actually get from it? [3] states that the distribution of funds in channels does not really affect the network liquidity. I can see cheaper fees or shorter paths if the network is kept balanced. But don’t you think that a smart fee strategy will do the job?
To save your time, [4] explains the gist from [3].
- [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
- [2] https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
- [3] https://arxiv.org/abs/1007.0515
- [4] https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
Olauluwa Osuntokun posted to the lighting network developer’s mailing list a proposal for extending the complexity and utility of payment paths. The scheme is called “Atomic Multi-path Payments” (AMP) and Osuntokun claims “the beauty of the scheme is that is requires no fundamental changes to the [current] protocol”. The purpose of the scheme is to provide a way for a sender to break payments up into “chunks”. There is unusued space in data trasmitted between lighting nodes as a byproduct of tor compliance. This unusued space has been isolated as a 65 bytes that can be used as processing instructions for nodes along the payment path.
When considering payments that are broken into chunks, it is an excellent idea both technically and economically. Relay and processing becomes subdivided further than presently among nodes. More nodes increases security by reducing probability of select certain paths redundantly. Economically, single payments dispursed over a wider set of nodes provides a more fair (probabilisitically speaking) distrobution of work.