LND #2933 adds a document describing LND’s current backup and recovery options.
LND #2313 implements code and RPCs that allow LND nodes to use static channel backups. This is based on the Data Loss Protection (DLP) protocol implemented in LND #2370 to allow backing up a single file containing all of your current channel state at any point and then enabling restoring from that file at any later point to get your remote peer to help you to close any of those channels in their latest state (excluding unfinalized routed payments (HTLCs)). Note: despite the “static” in this feature’s name, this is not like an HD wallet one-time backup. It’s a backup that needs to be done at least as often as each time you open a new channel—but that’s much better than the current state where you may not be able to recover any funds from any of your channels if you lose data. Further improvements to backup robustness are mentioned in the PR’s description. See the description of LND #2370 in Newsletter #31 for more details on how DLP-based backup and recovery works. Getting this major improvement to backups merged was one of the major goals for upcoming LND version 0.6-beta.
LND #2740 implements a new gossiper subsystem which puts its peers into two buckets, active gossiper or passive gossiper. Active gossipers are peers communicating in the currently normal way of sharing all of their state with your node; passive gossipers are peers from which you will only request specific updates. Because most active gossipers will be sending you the same updates as all other gossipers, having more than a few of them is a waste of your bandwidth, so this code will ensure that you get a default of 3 active gossipers and then put any other gossipers into the passive category. Furthermore, the new code will try to only request updates from one active gossiper at a time in round-robin fashion to avoid syncing the same updates from different nodes. In one test described on the PR, this change reduced the amount of gossip data requested by 97.5%.
LND #2885 changes how LND attempts to reconnect to all of its peers when coming back online. Previously it attempted to open connections to all its persistent peers at once. Now it spreads the connections over a 30 second window to reduce peak memory usage by about 20%. This also means that messages that are sent on a regular interval, such as pings, do not happen at the same time for all peers.
LND #2759 lowers the default CLTV delta for all channels from 144 blocks (about 24.0 hours) to 40 blocks (about 6.7 hours). When Alice wants to pay Zed through a series of routing nodes, she starts by giving money to Bob under the terms that either Alice can take it back after (say) 400 blocks or Bob can claim the money before then if he can provide the preimage for a particular hash (the key that opens a hashlock). The 400 block delay is enforced onchain if necessary using
OP_CHECKLOCKTIMEVERIFY (CLTV). Bob then sends the money (minus his routing fee) to Charlie with similar terms except that the CLTV value is reduced from Alice’s original 400 blocks by the CLTV delta of his channel with Charlie, reducing the value to 360 blocks. This ensures that if Charlie waits the maximum time to fulfil his HTLC to Bob and claim his payment (360 blocks), Bob still has 40 blocks to claim his payment from Alice by fulfilling the original HTLC. If Bob’s HTLC expiry time with Charlie wasn’t reduced at all and used a 400 block delay, Bob would be at risk of losing money. Charlie could delay fulfilling his HTLC until 400 blocks, and Alice could then cancel her HTLC with Bob before Bob had time to fulfil the HTLC.
Subsequent routers each successively subtract their delta from the value of the terms they give to the next node in the route. Using a high CLTV delta therefore reduces the possible number of hops that can be used in a route, and makes a channel less attractive for use when routing payments.
LND #2691 increases the default address look-ahead value during recovery from 250 to 2,500. This is the number of keys derived from an HD seed that the wallet uses when rescanning the block chain for your funds. Previously, if your node gave out more than 250 addresses or pubkeys without any of them being used, your node would not find your complete balance on its first rescan, requiring you to initiate additional attempts. Now, you’d need to give out more than 2,500 addresses before reiteration might become necessary. An earlier version of this PR wanted to set this value to 25,000, but there were concerns that this would significantly slow down rescanning with the BIP158 Neutrino implementation, so the value was decreased until it could be shown that people needed a value that high. (Note: checking addresses against a BIP158 filter is very fast by itself; the problem is that any match requires downloading and scanning the associated block—even if it’s a false-positive match. The more addresses you check, the greater the number of expected false positives, so scanning becomes slower and requires more bandwidth.)
LND #2765 changes how the LN node responds to channel breaches (attempted theft). Previously, if an attempted breach was detected, the node created a breach remedy transaction to collect all funds associated with that channel. However, when users start using watchtowers, the watchtower may create a breach remedy transaction but not include all the possible funds. (This doesn’t mean the watchtower is malicious: your node may simply not have had a chance to tell the watchtower about the latest commitments it accepted.) This PR updates the logic used to generate the breach remedy transaction so that it only collects the funds that haven’t been collected by prior breach remedy transactions, allowing recovery of any funds the watchtower didn’t collect.