Write structs to serialise-deserialise Channels inside Peer-storage
What changed, and why it matters
This commit adds new data structures for serializing and deserializing Lightning channel backup information stored with peers. It is purely foundational code that defines how channel data should be formatted for storage and transmission. There is no indication this commit introduces a security vulnerability or fixes one—it appears to be a building block for a future peer-storage backup feature.
No immediate security action required. Monitor follow-up commits that implement actual peer storage backup/recovery logic for proper authentication, encryption, and deserialization validation.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit introduces two related additions: (1) a PeerStorageMonitorHolder struct in our_peer_storage.rs containing channel_id, counterparty_node_id, min_seen_secret, and monitor_bytes, with TLV-based serialization; and (2) a vector serialization implementation for that struct in ser.rs. The code is marked pub(crate) and is intended to support future peer-storage-based channel state recovery. No logic for actual backup, encryption, network transmission, or recovery is added in this commit.
Changed components
lightning/src/ln/our_peer_storage.rslightning/src/util/ser.rsInspect captured patch +31 / −0
diff --git a/lightning/src/ln/our_peer_storage.rs b/lightning/src/ln/our_peer_storage.rs
index 430c9f5..1786374 100644
--- a/lightning/src/ln/our_peer_storage.rs
+++ b/lightning/src/ln/our_peer_storage.rs
@@ -13,7 +13,9 @@
use bitcoin::hashes::sha256::Hash as Sha256;
use bitcoin::hashes::{Hash, HashEngine, Hmac, HmacEngine};
+use bitcoin::secp256k1::PublicKey;
+use crate::ln::types::ChannelId;
use crate::sign::PeerStorageKey;
use crate::crypto::chacha20poly1305rfc::ChaCha20Poly1305RFC;
@@ -146,6 +148,34 @@ fn derive_nonce(key: &PeerStorageKey, random_bytes: &[u8]) -> [u8; 12] {
nonce
}
+/// [`PeerStorageMonitorHolder`] represents a single channel sent over the wire.
+/// This would be used inside [`ChannelManager`] to determine
+/// if the user has lost channel states so that we can do something about it.
+///
+/// The main idea here is to just enable node to figure out that it has lost some data
+/// using peer storage backups.
+///
+/// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
+///
+/// TODO(aditya): Write FundRecoverer to use `monitor_bytes` to drop onchain.
+pub(crate) struct PeerStorageMonitorHolder {
+ /// Channel Id of the channel.
+ pub(crate) channel_id: ChannelId,
+ /// Node Id of the channel partner.
+ pub(crate) counterparty_node_id: PublicKey,
+ /// Minimum seen secret to determine if we have lost state.
+ pub(crate) min_seen_secret: u64,
+ /// Whole serialised ChannelMonitor to recover funds.
+ pub(crate) monitor_bytes: Vec<u8>,
+}
+
+impl_writeable_tlv_based!(PeerStorageMonitorHolder, {
+ (0, channel_id, required),
+ (2, counterparty_node_id, required),
+ (4, min_seen_secret, required),
+ (6, monitor_bytes, required_vec),
+});
+
#[cfg(test)]
mod tests {
use crate::ln::our_peer_storage::{derive_nonce, DecryptedOurPeerStorage};
diff --git a/lightning/src/util/ser.rs b/lightning/src/util/ser.rs
index ac2b529..95554b1 100644
--- a/lightning/src/util/ser.rs
+++ b/lightning/src/util/ser.rs
@@ -1084,6 +1084,7 @@ impl_for_vec!((A, B), A, B);
impl_for_vec!(SerialId);
impl_for_vec!(NegotiatedTxInput);
impl_for_vec!(InteractiveTxOutput);
+impl_for_vec!(crate::ln::our_peer_storage::PeerStorageMonitorHolder);
impl_writeable_for_vec!(&crate::routing::router::BlindedTail);
impl_readable_for_vec!(crate::routing::router::BlindedTail);
impl_for_vec!(crate::routing::router::TrampolineHop);
Why this scored 11/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.