Description
Currently, if we are restored from an old backup or otherwise lose some persistent state, our peer may tell us about it via the data_loss_protect message. This means that we are holding a revoked holder state.
However, in this case we may end up broadcasting the revoked transaction at a future time. For example, we may decide to broadcast it if the peer goes a way for a long time.
If we detect a data_loss_protect from a peer, we should put the channel into a special mode where we don't try to do anything in the regular channel lifecycle (such as state change or broadcast). Also, there should be an API to allow broadcasting of the toxic transaction, reserved for the case where we can't get our peer to close the channel from their side.
After data_loss_protect is detected on a channel:
- prevent advancing of channel state (creation of new local or remote commitment txns)
- prevent "normal" force-close, e.g. if the peer is down for a while
- new API to allow signing and broadcasting of revoked transaction (to be triggered manually by operator)
- special signer mode allowing signing of revoked transaction, in case signer state has not been lost / rolled back and it's disallowing signing via the new API
An additional issue exists when we detect that chanmon is out of sync with chanmgr. It will normally auto force-close. But it may be that the chanmon has a revoked holder transaction, and publishing it will get us penalized. Accordingly:
- try to connect to peer to detect if
data_loss_protectmode should be turned on before auto force-closing