test: fix block generation in `test_close_72_block_delay` to reflect correct depth
What the developer wrote
Authored by Níckolas Goline
test: fix block generation in `test_close_72_block_delay` to reflect correct depth
What changed, and why it matters
This is a one-line correction in a test file. The test was generating one too many blocks for the scenario it intended to exercise, so the developer reduced the count from 71 to 70. It does not change any production code, network protocol, or wallet behavior.
No security action needed. Treat as a normal test-maintenance commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In tests/test_gossip.py::test_close_72_block_delay, the comment explains that the assertion checks a channel is still visible at 72 blocks deep after a spend that itself requires 1 confirmation (i.e., 73 confirmations total). The previous bitcoind.generate_block(71) actually produced 72 post-spend confirmations (1 + 71), overshooting the intended 72-deep boundary. The patch changes it to bitcoind.generate_block(70) so the total depth is exactly 72. This is purely a test-fix with no runtime security implications.
Changed components
tests/test_gossip.pyInspect captured patch +1 / −1
diff --git a/tests/test_gossip.py b/tests/test_gossip.py
index 13724b9f..326a4391 100644
--- a/tests/test_gossip.py
+++ b/tests/test_gossip.py
@@ -2059,7 +2059,7 @@ def test_close_72_block_delay(node_factory, bitcoind):
# That implies 72 blocks *after* spending, i.e. 73 blocks deep!
# 72 blocks deep, l4 still sees it
- bitcoind.generate_block(71)
+ bitcoind.generate_block(70)
sync_blockheight(bitcoind, [l4])
assert len(l4.rpc.listchannels(source=l1.info['id'])['channels']) == 1
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.