Here I have 3 channels, the largest of them has a capacity of 2 000 000 SAT. Then I get a 3 000 000 SAT multipart invoice which gets split into 5 smaller payments. When attempting to make a final partial payment there is a need for rebalancing so AIR is carried out automatically before proceeding further.

Place to try it out: http://b.lightning-wallet.com/multipart/.

Wallet which supports this on TestNet: BLW v0.3–116 at Google Play or direct APK download.

Technical description: LNURL.

Besides atomicity AMP idea has a useful property of single payment being split into a bunch of smaller transactions, because once divided a large payment has way better delivery chances.

Furthermore, atomicity itself is often not required and partially fulfilled payments are sometimes more preferable to atomic ones. For example, consider a case when someone refills a balance on a lightning-enabled site using non-atomic 5-part payment: even if only 1 part is successful that is still better than nothing at all.

Therefore, it makes sense to enable payments which can be broken into smaller parts but are not atomic. As of update 0.3–116 BLW supports such a scheme on TestNet and it works as follows:

1. When generating an LN invoice payee software embeds a special multipart LNURL tag which contains a callback URI. An effect of this is multipart-enabled wallets now recognize this possibility while other wallets just see a usual LN payment request.
2. Wallet asks user permission to split a payment in case if sending it in one piece has failed or if no single channel has enough balance to handle it.
3. Once accepted wallet calls an embedded URI and gets a JSON response which contains additional invoices, it then proceeds with spreading total payment amount across these invoices and fulfilling them one at a time.

My hope is that multipart/AIR/AMP combined with unbounded channels have a potential to solve current liquidity issues for good.

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

Try it on TestNet right now: https://lightning-wallet.com/instant/

What is going on?

When channel is funded in a special way an amount present in it can be spent immediately, without waiting for a funding transaction to become confirmed. This introduces no additional risks to either channel side, can be standardized with minor Lightning protocol changes and works on TestNet today.

This idea was brought to me by Kixunil and the gist is: if Bob the funder decides to push a certain amount to Alice the fundee on channel opening then pushed amount can be spent by Alice right away.

Pushing is essentially giving money away for free as far as LN protocol is concerned, an example: if total channel capacity is 1 BTC and Bob decides to push 0.5 BTC to Alice then initial channel funds distribution would be (0.5 Alice / 0.5 Bob).

Why would Bob do this?

Pushing may sound obscure but it’s in fact surprisingly applicable to a wide range of real-life scenarios, a few examples:

• Alice gives fiat to Bob in person and thus purchases an incoming channel with converted amount in BTC pushed to her.
• Alice redeems a voucher online and orders an incoming channel with voucher value pushed to her.
• Alice the trader withdraws her exchange balance in a form of new Alice / Exchange channel with balance once again pushed to her.

This “special” case is so ubiquitous it may eventually become the way to use Lightning Network for end users.

Why is immediate spending from such a channel safe?

From Alice perspective, the pushed off-chain funds she has in an unconfirmed channel are not really her funds until a funding transaction gets included in a block. So, if anything, Alice has an incentive to spend these funds off-chain while they are unconfirmed on-chain.

From Bob perspective, he owes a pushed amount to Alice until a channel gets confirmed on-chain so he should not mind Alice spending these funds off-chain before that happens and thus clearing Bob’s debt.

Now, the central issue: what if a funding transaction gets thrown out of mempool eventually, would not Bob incur a financial loss if Alice manages to spend pushed amount off-chain before that? The answer is no, he would not, let’s analyze this edge case step by step:

1. Alice pays 0.5 BTC to Bob with fiat, Bob opens a 1 BTC channel to Alice and pushes 0.5 BTC to her, so initial distribution is (0.5 Alice / 0.5 Bob).
2. Bob already has a (0.6 Bob / 0.4 Carol) channel and Alice pays 0.1 BTC to Carol through Bob, so both channel states are updated and new distribution is (0.4 Alice / 0.6 Bob), (0.5 Bob / 0.5 Carol).
3. Alice / Bob channel funding hangs in a mempool for weeks and eventually gets thrown out so there is no more an on-chain basis for their channel, so it gets removed from their wallets. Bob has lost 0.1 BTC in Bob / Carol channel while gained nothing in a by-now non-existing Alice / Bob channel, but Bob still has fiat which Alice gave him so effectively he now owes 0.4 BTC to Alice which he can refund or utilize while opening a new channel to Alice.

Can this be extended to a full blown trustless case?

Sort of yes, here’s how: Alice and Bob create a special non-RBF funding transaction which has two outputs:

• First output is a 0.5 BTC P2WPKH transfer from Alice to Bob, this is her paying to Bob for opening of channel with a pushed amount.
• Second output is 1 BTC channel funding from Bob with 0.5 BTC pushed to Alice off-chain.

Unlike previous case, here Bob does take risks if Alice spends her pushed amount off-chan and funding gets thrown out of mempool eventually, but Bob can always CPFP a first output if transaction starts hanging in mempool for a long time or if double spend is detected.

Is it hard to implement this?

Not at all, the currently proposed way is just a matter of introducing a new turbo bit in channel flags which would allow funder to signal an operational channel state once funding is broadcasted and fundee to accept it once it sees a funding in a mempool.

Eclair implementation (please don’t use it on MainNet yet).

BLW implementation for TestNet.

For those interested in details I’d like to explain here what exact problem is being addressed and how my implementation tries to do it in a technologically sound and economically sustainable way.

What is the problem?

Every Lightning payment attempt creates a valid Bitcoin commitment transaction which fixates current channel balance distribution. This transaction can be broadcasted by either party at any time, even if a state it captures gets invalidated later by subsequent Lightning payments.

To understand why this can be dangerous let’s consider the following picture which illustrates a channel opening and a number of following payments which create a trail of valid commitment transactions.

States b) through d) depict outgoing payments. After each outgoing payment you only have less money and your peer only has more so if they want to break a channel at some point the only rational choice is to spend the last commitment transaction, otherwise it would be a gift to you. This is the idea behind send-only wallets such as Eclair for Android: they don’t allow receiving Lightning funds but also don’t require you to become online periodically and there is no need for a watchtower.

Now let’s look at the last e) payment. This is an incoming one which shifts part of channel balance back to you. The issue here is that commitment transactions for payments c) and d) don’t go anywhere and your peer may be tempted to broadcast those since they are more beneficial to peer than current channel state.

What protects you from funds loss here is that each commitment transaction sends funds to a limbo address which is designed in such a way that your peer needs to wait a number of blocks in order to finally transfer those coins into their wallet, but you can sweep the whole channel balance right away once your wallet sees a broadcasted commitment transaction.

Obviously, for this to work someone capable of punishing a misbehaving peer needs to be online periodically. In BLW the wait period is set to 2016 Bitcoin blocks and up until now this long delay was the only thing protecting users from channel breaches.

This approach was far from perfect as it’s absolutely reasonable to assume someone could just forget to launch an app at least once per 2016 blocks and thus get into risk of funds getting stolen.

How watchtower improves a situation

The idea is simple: watchtower is a service which is always online and watching for channel breaches even at times when your wallet is offline. Implementation is also pretty straightforward, here is a complete high-level overview of an algorithm:

1. On every incoming or outgoing Lightning payment BLW creates a blob of signatures and public keys required to punish a peer in case if corresponding commitment transaction gets broadcasted. This blob is then saved into local BLW database.

2. After every incoming payment BLW futher looks into local database and searches for past payments which your peer might be now tempted to broadcast (those would be c) and d) in a picture above).

3. For every found payment BLW encrypts a punishment blob with it’s corresponding commitment transaction ID used as decryption key, then cuts TXID in half so we obtain an (encrypted blob, halfTXID) pair.

4. Once all the pairs are ready BLW sends them to watchtower in a series of packs each containing of up to 20 pairs (the reason for such batching is explained below).

5. Watchtower saves every pair in a database and continuously listens to new blocks looking if any new halfTXID matches the one it has in a database. If it does, this means your peer has broadcasted an old channel state. Watchtower now has a fullTXID which it uses to decrypt a corresponding blob and broadcast punishment transactions.

Watchtower service has economical challenges

Running it requires a reasonable infrastructure: at a minimum watching server needs to have enough resources to store potentially billions of blobs and run a Bitcoin node. As such, it can not be expected for watchower to provide a service for free, there should be a reward of some kind or else an owner might be tempted to just stop an operation at some point and leave wallet users insecure*.

* Even if watchtower is not there all of a sudden you still can punish a peer all by yourself if they breach a channel and you manage to get your wallet online during the next 2016 blocks.

One popular proposal for making it incentive compatible is to include a watchtower reward in every punishment blob so when a breach happens watchtower gets a part of channel balance by just publishing a punishment transaction. In my opinion this approach is flawed for two reasons:

1. Channel breaches are not expected to happen often so it does not seem to me that service will be able to sustain itself by earning on rewards alone.

2. This gives some weird incentives: watchtower now wants all peers to breach their channels as often as possible. This may result in hacks and other attempts to influence LN node owners.

Storage tokens as a solution

Those who use BLW already know it has an accompanying maintenance server called Olympus which takes Chaumian-style ecash tokens for storing various user data.

Until now these tokens were only used to store encrypted channel backups but now Olympus also provides a watchtower service which requires one storage token for watching of up to 20 encrypted blobs. This is the reason BLW batches pairs of (encrypted blob, halfTXID) into packs of up to 20 items before sending them to Olympus: every pack has a storage token attached so watching service gets paid every time it accepts a blob.

Currently Olympus charges 1000 SAT per 50 tokens so each token costs 20 SAT. Thus, storing each commitment transaction costs about 1 SAT.

BLW acquires tokens automatically when there is a need for them by fulfilling an LN payment issued by Olympus server, the whole process is mostly transparent to users, the only noticeable thing would be 1000 SAT Lightning payments occasionally popping up in a wallet payment list.

All that said, user is free to opt out of this scheme at any time and rely solely on getting online per 2016 block periods, as shown on a screenshots below.

Bitcoin Atom info:
https://bitcointalk.org/index.php?topic=2515675.0

Atom Lightning Wallet on Google Play:
https://play.google.com/store/apps/details?id=com.lightning.walletapp.bca

Atom Lightning Wallet sources:
https://github.com/btcontract/lnwallet-atom

Eclair Atom binaries and sources:
https://github.com/btcontract/eclair-atom/releases

A tipping widget to spend your BCA:
http://bcatip.lightning-wallet.com/

Why doing this?

First and foremost, I want LN to be readily available in places where miners have less censorship power by design because LN critically relies on refunding on-chain transactions to be confirmed in a reasonable time-frame or else a race condition becomes possible where an attacker may steal a part of channel balance and get away with it.

Current LN refunding transactions are easily discernible and we have just a handful of large miner pools who technically can stop processing some or all of them. While it may seem like pulling off this type of attack is not in pools’ best interest we should never forget that powerful miner supported forks do exist. Large mining companies such as Bitmain openly despise Bitcoin so given the right market conditions they may attempt to play games with LN in order to lure investors into BCH where they have total control.

BCA uses PoW/PoS consensus which may have issues of it’s own but it does give businesses and investors a direct means to keep LN going even if miners don’t want it to, by an option of pushing refunding transactions via PoS blocks. Functional Lightning Network based on a hybrid consensus should remind miner monopolists that there are many places where investors could go in case of what, including those where miners have less power, not more.

Second, I want to try various approaches which currently seem nonviable on BTC based LN and see how they play out:

- toSelfDelay of up to 8640 blocks is accepted thus turning “online at least once a day” rule into “online at least once per two months”. The upside is this effectively eliminates the need for watchtowers, the downside is up to 2 months of waiting if peer becomes unresponsive and you close a channel uncooperatively.

- Maximum channel capacity of ~0.16 BTC is removed in BCA which hopefully will increase liquidity and remove unnecessary load from blockchain and LN routing graph.

- BCA nodes are very tolerant to fee-rate disparity and accept a difference of up to 150 times. Low fee-rate tolerance is currently one of the main reasons for broken channels on BTC mainnet.

Of course, LN does not have a global consensus and I won’t be able to enforce these rules once new nodes start joining but judging from BTC experience node operators tend to adhere to default settings so these rules stand a good chance of taking off.

I may be wrong about everything but there seem to be no downside in doing this. LN success on BCA will reward every Bitcoin investor and strengthen it’s success on BTC while failure of any kind will supply us with knowledge about what should not be done.