Note why we don't use `update_for_new_tip` in offers flow block upd
What changed, and why it matters
This commit only adds a two-line comment explaining why a particular helper function is not used in the offers flow code. It does not change any code behavior, fix a bug, or alter security logic.
No action needed; this is a documentation-only change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff adds a comment in lightning/src/offers/flow.rs clarifying that update_for_new_tip is intentionally not called because the component does not depend on disconnection information and instead directly jumps to the new best block tip. No functional code was modified.
Changed components
lightning/src/offers/flow.rsInspect captured patch +2 / −0
diff --git a/lightning/src/offers/flow.rs b/lightning/src/offers/flow.rs
index 901866f..2edcbc8 100644
--- a/lightning/src/offers/flow.rs
+++ b/lightning/src/offers/flow.rs
@@ -187,6 +187,8 @@ impl<MR: MessageRouter, L: Logger> OffersMessageFlow<MR, L> {
let timestamp = &self.highest_seen_timestamp;
let block_time = header.time as usize;
+ // Note that we deliberately don't use `update_for_new_tip` as we dont rely on receiving
+ // disconnection information instead expecting to simply "jump" to the new tip.
*self.best_block.write().unwrap() = BestBlock::new(header.block_hash(), height);
loop {
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.