Automatic Iterative Rebalancing
If there are many open channels but none of them has enough balance to fulfill an invoice on its own then wallet may simply send a bunch of payments to itself in order to achieve a required capacity in one selected channel, and then pay through it.
This idea is not new but to the best of my knowledge it has not been implemented anywhere up until now. I abbreviate it as AIR and BLW will support it as of 0.03–112 update. Here’s how it works:
- When user scans an invoice wallet checks if it can be fulfilled using any of currently present channels, if such channel is found then it’s going to be an ordinary off-chain payment.
- If no single fitting channel is found but invoice can still be fulfilled by combining multiple balances then wallet initiates an AIR before ultimately fulfilling an invoice.
- Once AIR is started wallet selects one accumulator channel and sends a payment from other local channel into selected one. Wallet does this automatically and iteratively since reaching a required balance may need multiple payments from different channels.
How does AIR compare to AMP?
AIR solves a similar problem and does have some pros and cons when compared to proposed AMP methods. According to https://lightningwiki.net/index.php/AMP there are three AMP flavors of which two seem realistic: OG AMP and Base AMP.
How do they treat delivery failure
OG AMP is truly atomic: either recipient gets all payment parts and reconstructs a preimage or they don’t and the whole combined payment fails.
Base AMP is “economically atomic”, that is, recipient is incentivized to wait for all payment parts to arrive before fulfilling it but underpaid payments may happen if some parts fail along the way and sorting this out may be messy.
AIR is not atomic at all but this is fine because recipient and sender is the same person. If rebalancing iteration fails you simply get the funds back, and you are free to start another AIR attempt any time.
OG AMP removes an invoice and it’s not always good thing
Signed payment request and preimage as proof-of-payment simply do not exist here. This is often fine but when one purchases some kind of service I’d argue it’s not since one would want to have a proof that service has been paid for just in case if anything goes wrong.
Both Base AMP and AIR keep a signed invoice in place, it can be said they are equal in this regard.
AIR is limited by channel capacity, AMP has better delivery chances
Since AIR results in an single off-chain payment it can’t be used to send more than a single largest channel capacity allows to. Also it’s easier to deliver a few small payments rather than a big one.
For this reasons AIR can’t be treated as full AMP replacement but rather as a method which wallet should prefer when requested payment sum is relatively low, otherwise AMP should be used.
For those interested, here’s an in-depth link and discussion about how the same idea can be applied to routing nodes: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html
