Fix docs on ChannelMonitor::payment_preimages
What the developer wrote
Authored by Valentine Wallace
Fix docs on ChannelMonitor::payment_preimages
What changed, and why it matters
This commit only updates a code comment to clarify that the payment_preimages field also covers forwarded payments, not just inbound payments. No actual code behavior was changed, so there is no security issue or vulnerability.
No action needed; this is a non-functional documentation fix.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is a documentation-only change in lightning/src/chain/channelmonitor.rs. It rewords the doc comment on the payment_preimages field to note that it includes forwards and that forwarded payments have an empty PaymentClaimDetails list. No logic, data structures, or security properties were modified.
Changed components
lightning/src/chain/channelmonitor.rs documentationInspect captured patch +10 / −9
diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index a537ff5..3c94b91 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -1256,18 +1256,19 @@ pub(crate) struct ChannelMonitorImpl<Signer: EcdsaChannelSigner> {
// deserialization
current_holder_commitment_number: u64,
- /// The set of payment hashes from inbound payments for which we know the preimage. Payment
- /// preimages that are not included in any unrevoked local commitment transaction or unrevoked
- /// remote commitment transactions are automatically removed when commitment transactions are
- /// revoked. Note that this happens one revocation after it theoretically could, leaving
- /// preimages present here for the previous state even when the channel is "at rest". This is a
- /// good safety buffer, but also is important as it ensures we retain payment preimages for the
- /// previous local commitment transaction, which may have been broadcast already when we see
- /// the revocation (in setups with redundant monitors).
+ /// The set of payment hashes from inbound payments and forwards for which we know the preimage.
+ /// Payment preimages that are not included in any unrevoked local commitment transaction or
+ /// unrevoked remote commitment transactions are automatically removed when commitment
+ /// transactions are revoked. Note that this happens one revocation after it theoretically could,
+ /// leaving preimages present here for the previous state even when the channel is "at rest".
+ /// This is a good safety buffer, but also is important as it ensures we retain payment preimages
+ /// for the previous local commitment transaction, which may have been broadcast already when we
+ /// see the revocation (in setups with redundant monitors).
///
/// We also store [`PaymentClaimDetails`] here, tracking the payment information(s) for this
/// preimage for inbound payments. This allows us to rebuild the inbound payment information on
- /// startup even if we lost our `ChannelManager`.
+ /// startup even if we lost our `ChannelManager`. For forwardeds, the list of
+ /// [`PaymentClaimDetails`] is empty.
payment_preimages: HashMap<PaymentHash, (PaymentPreimage, Vec<PaymentClaimDetails>)>,
// Note that `MonitorEvent`s MUST NOT be generated during update processing, only generated
Why this scored 15/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.