Sweeper Behavior Today

Today anytime we have an output on chain, we immediately want to sweep it into an address protected by our main seed. We don't technically have to do this though, as in many cases, the output is uncontested, so it can just sit in the chain. The advantage of sweeping as we today is that we attempt to maximize the amount of funds that are stored in an addr derived by our main seed. My maximizing this value, we also increase the amount of funds that can be reliably recovered if a node randomly blows up and loses all its data.

Today's SCB Recovery Shortcomings

However, there's still the case of a large force close going on chain, with many HTLCs wherein the sweeping node blows up as soon as the commitment transaction is confirmed. In this case, we can only reliably recover our settled balance, even with the existing SCB flow. The reason for that is that the SCBs are meant to be static in that they're updated just once, then a user can stash them later to use to attempt to recover funds. The size of an HTLC you can send across the network has dramatically gone up, to the point that many nodes routine send 1 BTC+ HTLCs across the network. The current SCB flow unfortunately doesn't help these larger nodes.

Extending SCB w/ Encrypted P2P Storage Blobs

A new spec proposal can help us achieve the best of both worlds: #8154. Once the encrypted p2p storage feature is implemented, we can use it to periodically checkpoint the sweeper state. In this case, the state would include all the active tendered sweeps. These sweeps may be pending, being broadcast, undergoing fee bumps, etc. As is, the proposal only allows for ~65KB, but as we're just storing small information like witness scripts and partial signatures, 65KB would be enough to store information for the max amount of outputs that can exist in a fully loaded force close.

Enhanced SCB Recovery via RAID-0 Sweeper Checkpoints

With the p2p storage feature implemented, and periodic sweeper checkpoints fanned out to our channel peers, we can augment the SCB flow to attempt to re-download the blobs stored by the peers to allow resuming any active sweeps that may have been ongoing. This would be done on a best effort basis, and we'd likley want to implement some basic RAID 0 (disk striping) approach s.t even if we can only connect to one of those past peers, we're able to sweep a large portion of the pending funds.