Codecov Report

Merging #1093 into master will increase coverage by 0.18%.
The diff coverage is 97.47%.

@@            Coverage Diff             @@
##           master    #1093      +/-   ##
==========================================
+ Coverage   82.67%   82.85%   +0.18%     
==========================================
  Files         101      102       +1     
  Lines        7653     7707      +54     
  Branches      312      316       +4     
==========================================
+ Hits         6327     6386      +59     
+ Misses       1326     1321       -5

User funds can now be recovered from their seed, without using backups (we could say that "we use the bitcoin blockchain to backup channels").
If a user loses their channel backup but still has their BIP32 seed, they can use DLP to request peers they have active channels with to publish their current commitment transaction, extract their funding pubkey from its witness, re-compute their to-remote key and spend their output.

To be clear, you assume that the user performing disaster-recovery

• has their BIP32 seed
• knows which peer (e.g. 33 byte node id) they had what channel (e.g. 8 byte short channel id) with
• the node (peer) is online and reachable
• the channel had DLP enabled

right?

Not necessarily, just knowing your seed helps a lot: If commitment transactions have already been published, all you need to to is scan the blockchain for txs that spend a 2-of-2 p2wsh multisig, extract pubkeys, and check if you can spend its to-remote output. This may be enough in many cases, as your peers will eventually close channels that are never used anymore and where they have funds locked in, even if they don't support DLP.

Also, if you've funded channels it's very easy to re-compute their channel ids, just look at transactions coming out of your bitcoin wallet. If channels are public you can then find which node you were connected to

And in most cases users open channels to very few nodes and should be able to guess which ones