Two weeks ago, PR #410 was merged into eclair’s master branch. This pull request added support for “Data loss protection”, one of the features we absolutely wanted to implement in eclair before going on mainnet.
Why is it such a big deal? One of the tricky thing with Lightning is that you cannot easily backup a channel. Suppose you simply copy your node data, and later restart from this now outdated state; then you may broadcast what you think is the current commitment, which is actually a revoked commitment and you will be punished by your counterparty.
Data loss protection is an optional feature that was added to the Lightning Network specifications a few months ago. In a nutshell, it allows parties to provide additional data at reconnection, in order to give provable information on their counterparty’s current commitment number.
For example, if Alice and Bob have a channel open together and support this feature, Bob will tell Alice: “you are at least at commitment number N, and here is the proof”. If Alice’s commitment number is M with M< N, then (1) she knows that her data is stale and (2) she can ask Bob to broadcast his current commitment, which is really the only thing left to do when one of the parties loses its data anyway.
Can Bob lie? Partly: he cannot invent a future commitment number, but he can, for example, say “you are at commitment number N” when in fact Alice is at commitment number P with P > N. However, Bob can never be sure that Alice has lost her data or if she is just pretending, and attempting to cheat on LN is a very risky bet…
Another way to look at it: in order to lose money, you would have to lose your data and have a dishonest counterparty and they are willing to bet all their money that you are telling the truth when you say you lost your data.
A third way to look at it: with only one old backup of your data, you’ll be able to retrieve most of your funds, provided that your counterparty is honest (or is not willing to bet that you are honest).
What’s next?
The next important feature we are working on at the spec level is a better synchronization mechanism. As the Lightning Network grows on testnet, the need appeared for a more efficient way to exchange initial routing information, particularly for mobile devices.
