TL; DR: We have enabled receive on Eclair Mobile Testnet 0.4.0, with a background watcher mechanism and a basic liquidity service.
In our last blog post we explained the reasons which led us to limit Eclair Mobile to only sending money until now. There were three of them:
- For mobile users, the #1 use case for Lightning is to send payments;
- It is far safer, because it saves us from monitoring the blockchain;
- Inbound liquidity is necessary to receive funds and we don’t have the tools to address this yet.
In other words, if we want to enable receive on Eclair Mobile, the two main problems are security and liquidity. Let’s see how we addressed them.
But before going into details, here is a quick demo of the receive experience:
Monitoring the blockchain
A note about watch towers
The go-to answer to monitoring the blockchain has often been watch towers. When we first released our app in 2017, we hinted that “trustless third-party watchers” would be how we would do it too. But there are a few catch 22s.
While it is already technically possible and even fairly easy to develop and run such a watcher, operating one is challenging because the data needed to watch a single channel isn’t constant size: watch towers need to store an ever increasing amount of opaque data that needs to be indexed and is impossible to compress…
It gets worse: because we don’t want to trust watch towers, we give them so little information about channels, that they have no way to know when a channel has been closed (so they can’t clean up data), or even if there is a real channel in the first place. The latter opens the way to abuse and make it even more difficult to operate a watch tower in a sustainable way.
It should be noted that the upcoming SIGHASH_NOINPUT opcode will make it possible to have constant-size storage; there is no ETA though. There may also be a way to offer this as a paying service, but it is easier said than done and we haven’t found a model that was both acceptable for users and economically viable.
For those reasons, we decided to not rely on watch towers for now. Here is how we did it instead:
Step 1: Having enough time to react
The first thing to do is to make sure that we have enough time to react if our counterparty tries to cheat. As long as the wallet was send-only, we didn’t really care, because publishing a revoked commitment would actually give us money, which is why the refund timeout was set to 144 blocks (~1 day) by default.
For maximum safety, Eclair Mobile will now require a refund delay (a.k.a. retaliation window) of 2016 blocks (~2 weeks) from its counterparties, which is the highest value allowed by LN spec. This means that whatever happens, your funds will be safe if you start Eclair Mobile at least once every two weeks.
Note that as a consequence, when enabling the receive feature, Eclair Mobile will ask you to close any channel that has a refund timeout smaller than that. Any new channel you open will have the correct setting by default.
With that in place, we still need to have users start the app every two weeks, which is not very satisfying. We could remind them to do so using periodic notifications, but that’s not very satisfying either, and they would probably quickly get annoyed.
This is why we added what we call a background watcher.
Step 2: Adding a background watcher
Every now and then, Eclair Mobile will start a very lightweight background task, that will connect to Electrum servers (or your own Electrum server if you configured it), check if the funding transaction of any of your channel has been spent, and raise an alarm if something fishy has been detected.
If all your funding transactions are still unspent, then everything is fine: we are good for another two weeks, and there is no need to bother the user at all.
Even if one of your funding transaction has been spent, but the spending transactions is an expected one, such as a mutual or unilateral close, then there is no need to do anything either for another two weeks.
In fact, the only time when the user will have to actually start the app is if the spending tx is an actual cheating attempt (which hopefully will never happen). Only in this case will the watcher send a notification to the user, requesting them to start the app as soon as possible.
Note that depending on the brand and battery settings, some devices may prevent the background watcher to operate reliably. If that is the case, Eclair Mobile’s self-diagnostic feature will detect it and warn the user.
Summary and tradeoffs
Our mechanism protects your funds without forcing you to trust a third party, and with few requirements on your part. One of them is that your device must be reasonably well connected to the internet. If you go off the grid for more than two weeks, you should close your channels.
Even then, you could still rely on game theory: after all, your counterparties have no way to know if you are online or not. Critically, our background watcher doesn’t connect to them when checking the blockchain; just because your channels stay inactive for weeks or months doesn’t mean that you are not watching them.
If you lose your phone, then this is similar as going offline: you have two weeks to restore your app on another phone, or your funds will be at risk. But again, even if you take longer than two weeks, your counterparties cannot know that they have an opportunity to defraud you.
Now that we have a way to secure our channels, the other main pain point was liquidity.
Getting Inbound liquidity
Some context
When you want to send money over Lightning, you need to have a channel open with money on your side of it. If you don’t have a channel, opening one is pretty straightforward: you just need to connect to a peer on the network and fund a new channel. Pretty much anybody will accept this incoming channel request, as it doesn’t cost them anything.
When receiving money, that’s another story: this time your counterparty needs to have funds on their side. Not everyone will want to put funds in a channel to you, because it costs them money in locked capital, therefore there is an incentive issue.
The end goal
As we stated in our previous blog post, we believe that the combination of advertising your willingness to provide liquidity to other nodes (for a fee) with the ability to dual fund channels is the proper way to address this issue.
But we don’t have it yet, so in the meantime we have tried to approach it with what’s currently possible.
In the mean time
The idea is to use the push_msat(*) feature to pay in advance for incoming liquidity. Starting from today, when you open a channel to our testnet node (the venerable endurance), if you push funds, we will automatically open a channel back to your node. This is a trusted dual funding, which is not ideal, even if you only trust us with the push amount.
(*) This feature allows you to unconditionally send funds to your counterparty when you open a channel with her.
The results looks a bit like a Decker-Wattenhofer setup with two channels, one with all the funds on your side, an the other with all the funds on our side. An alternative to end up with a single balanced channel would have been to require an upfront payment of the total amount you wanted on your side, and then open a single balanced channel, but (1) you would have had to trust us for far more money and (2) we would still have to make two on-chain transactions, so it wouldn’t have been less costly in terms of blockchain space.
Pricing for testnet has been set to 1% as an example, meaning that if you open a channel with us and push 0.1mBTC worth of bitcoins, we will open a channel to you and fund it with 10 mBTC. Here is what the UX looks like currently in Eclair Mobile:
A call to testers
Receiving Ligthning payments is now possible with our testnet application (version 0.4.0), and your feedback is welcome! We plan to add this option to our mainnet application within a few weeks. In the meantime, happy testing!
