From 36e9725d9a9e9f71b31f8193daccfc96bb94090a Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 15 Aug 2022 19:30:32 +0000 Subject: [PATCH] Provide guidance on ChannelMonitorUpdate serialized size Users need to make decisions about storage sizing and we need to have advice on the maximum size of various things users need to store. ChannelMonitorUpdates are likely the worst case of this, they're usually at max a few KB, but can get up to a few hundred KB for commitment transactions that have 400+ HTLCs pending. We had one user report an update (likely) going over 400 KiB, which isn't immediately obvious to me is practical, but its within a few multiples of trivially-reachable sizes, so its likely that did occur. To be on the safe side, we simply recommend users ensure they can support "upwards of 1 MiB" here. --- lightning/src/chain/channelmonitor.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs index 855263fe5..4225bdee6 100644 --- a/lightning/src/chain/channelmonitor.rs +++ b/lightning/src/chain/channelmonitor.rs @@ -57,8 +57,13 @@ use io::{self, Error}; use core::ops::Deref; use sync::Mutex; -/// An update generated by the underlying Channel itself which contains some new information the -/// ChannelMonitor should be made aware of. +/// An update generated by the underlying channel itself which contains some new information the +/// [`ChannelMonitor`] should be made aware of. +/// +/// Because this represents only a small number of updates to the underlying state, it is generally +/// much smaller than a full [`ChannelMonitor`]. However, for large single commitment transaction +/// updates (e.g. ones during which there are hundreds of HTLCs pending on the commitment +/// transaction), a single update may reach upwards of 1 MiB in serialized size. #[cfg_attr(any(test, fuzzing, feature = "_test_utils"), derive(PartialEq))] #[derive(Clone)] #[must_use] -- 2.39.5