Peer Storage (Part 3): Identifying Lost Channel States #3897
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
adi2011
force-pushed
the
peer-storage/serialise-deserialise
branch
from
101f31c to
a35566a
Compare
'PeerStorageMonitorHolder' is used to wrap a single ChannelMonitor, here we are adding some fields separetly so that we do not need to read the whole ChannelMonitor to identify if we have lost some states. `PeerStorageMonitorHolderList` is used to keep the list of all the channels which would be sent over the wire inside Peer Storage.
Create a utililty function to prevent code duplication while writing ChannelMonitors. Serialise them inside ChainMonitor::send_peer_storage and send them over. TODO: Peer storage should not cross 64k limit.
Deserialise the ChannelMonitors and compare the data to determine if we have lost some states.
Node should now determine lost states using retrieved peer storage.
adi2011
force-pushed
the
peer-storage/serialise-deserialise
branch
from
a35566a to
4c9f3c3
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3897 +/- ##
==========================================
- Coverage 88.86% 88.86% -0.01%
==========================================
Files 165 165
Lines 118886 118962 +76
Branches 118886 118962 +76
==========================================
+ Hits 105650 105710 +60
- Misses 10911 10923 +12
- Partials 2325 2329 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| /// | ||
| /// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor | ||
| #[rustfmt::skip] | ||
| pub(crate) fn write_util<Signer: EcdsaChannelSigner, W: Writer>(channel_monitor: &ChannelMonitorImpl<Signer>, is_stub: bool, writer: &mut W) -> Result<(), Error> { |
There was a problem hiding this comment.
@wpaulino what do you think we should reasonably cut here to reduce the size of a ChannelMonitor without making the emergency-case ChannelMonitors all that different from the regular ones to induce more code changes across channelmonitor.rs? Obviously we should avoid counterparty_claimable_outpoints, but how much code is gonna break in doing so?
| } | ||
| }, | ||
| None => { | ||
| // TODO: Figure out if this channel is so old that we have forgotten about it. |
There was a problem hiding this comment.
There's no need to worry here, I think. If the channel is gone we either haven't fallen behind (probably) or we already broadcasted a stale state (because we broadcast on startup if the channel is gone and we have a ChannelMonitor) at which point were screwed. So nothing to do here.
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
| }, | ||
|
|
||
| Err(e) => { | ||
| panic!("Wrong serialisation of PeerStorageMonitorHolderList: {}", e); |
There was a problem hiding this comment.
I don't think we should ever panic in any of this code. Yes, something might be wrong if we have peer storage data we can't read anymore, but really no reason to refuse to at least keep other potential channels operational.
In this PR, we begin serializing the ChannelMonitors and sending them over to determine whether any states were lost upon retrieval.
The next PR will be the final one, where we use FundRecoverer to initiate a force close and potentially go on-chain using a penalty transaction.
Sorry for the delay!