On a traditional Bitcoin wallet, backup is as simple as writing down a list of words, once and for all. It is not as simple with Lightning because backups need to be updated after each transaction. It’s also very tricky because from a protocol point of view, restoring an out-of-date backup is the same as a cheating attempt, and will result in your peer taking all your funds.
For Eclair Mobile, we came up with the idea to use Google Drive as a remote backup system, by uploading an encrypted version of the channel data every time they were updated. It worked well enough and the feature was later replicated by a few other Lightning wallets, but it also required a dependency (and an account) to a external service provider (Google). We wanted to do better.
The idea of static backups has been floating around for some time now, but they are not a silver bullet and suffer from two main drawbacks:
- You need to remember what peers you have a channel with, meaning that you need to make a backup every time you create a channel. It’s an improvement, but it’s still not as good as doing a backup once and for all.
- Restoring a channel will close it. It costs you money and takes time.
Our idea with Phoenix is, on top of static backups, to make our peer store a backup of our channels for us. This immediately raises two questions: (1) how would I know who my former peers were when I need to restore my wallet and (2) why would my former peer cooperate and help me restore my funds.
Phoenix’s answer for (1) is easy enough: the peer is always ACINQ. That kind of simplification is one of the advantages behind the choice to always connect to the same nodes.
Now regarding (2), ACINQ needs an incentive to cooperate. In the case of Phoenix:
- ACINQ is always the funder, with a non-zero reserve, which means that ACINQ always has something at stake. From there, in order to recover its funds, ACINQ has two choices: either force-close(*), which means paying high fees (funder pays the commitment fees in unilateral close scenarii as per the LN protocol), or help users recover their channels, which could lead to earning future routing fees.
- Just like the
data_loss_protectfeature of the LN protocol, ACINQ doesn’t have a way to tell the difference between a recovery scenario and a normal reconnection. When reconnecting and exchanging commitment number about existing channels, ACINQ will always return the last encrypted channel data. We actually plan to go one step further and make ACINQ always send its data first, preventing it from gaining any information — true or false — from Phoenix beforehand. This is an example of shifting the trust balance in favour of Phoenix.
(*) Note that if ACINQ chooses to force-close, Phoenix would still recover its money thanks to static backups.
To summarise, if you (a Phoenix user) lose your data (uninstall app, lose phone, …), just reinstall the app with the same seed, and you will instantly recover your channels and be ready to make payments. We have demonstrated this use case in our preview video.
This article is part 3 of a series of articles introducing Phoenix. Other articles in this series:
