Correction to my own comment above, and it turns into a genuine question for @tbast rather than just a fix.
I leaned on "the BOLT specification recommends 6 confirmations" as if it were a citation. I went looking for it in BOLT 1–11 and can't find it.
The only "6 confirmations" in the spec is BOLT #7, gating channel_announcement — a gossip rule about when a channel may be announced, not a statement about when funds are safe. BOLT #5's only finality number is 100 (irrevocably resolved), and its MUST-monitor obligation is scoped to that depth — which is precisely the obligation the bug violated. BOLT #2 leaves reorg depth as the abstract parameter R and makes minimum_depth the accepter's judgement, requiring 100 only for a coinbase funding tx.
If I've missed it, I'd genuinely like the pointer and I'll correct again. But if it isn't there, then "implementations should refuse anything below 6" reads as a proposal rather than a restatement of the spec — which I think is a stronger position for it to be in, not a weaker one, because right now the four implementations sit at 3, 6, 8 and 100 and nothing in the spec adjudicates between them.
Which raises the question worth asking on this thread: should it? BOLT #5 already says MUST monitor until 100 deep. Nobody except CLN does that, for entirely understandable cost reasons. So either the 100 is aspirational and the real number should be written down somewhere normative, or implementations are collectively running below a MUST and calling it engineering judgement. Both are defensible readings; they're just different, and the disclosure is the natural place to settle which.
Everything else in my comments stands — lnd's floor is 3, you reach 6 only at 16,777,215 sat, and the operator override is unreachable on a release build (lnd#11072). It was only my gloss on the spec that was wrong. Post and tool are corrected.
Correction to my own comment above, and it turns into a genuine question for @tbast rather than just a fix.
I leaned on "the BOLT specification recommends 6 confirmations" as if it were a citation. I went looking for it in BOLT 1–11 and can't find it.
The only "6 confirmations" in the spec is BOLT #7, gating
channel_announcement— a gossip rule about when a channel may be announced, not a statement about when funds are safe. BOLT #5's only finality number is 100 (irrevocably resolved), and its MUST-monitor obligation is scoped to that depth — which is precisely the obligation the bug violated. BOLT #2 leaves reorg depth as the abstract parameterRand makesminimum_depththe accepter's judgement, requiring 100 only for a coinbase funding tx.If I've missed it, I'd genuinely like the pointer and I'll correct again. But if it isn't there, then "implementations should refuse anything below 6" reads as a proposal rather than a restatement of the spec — which I think is a stronger position for it to be in, not a weaker one, because right now the four implementations sit at 3, 6, 8 and 100 and nothing in the spec adjudicates between them.
Which raises the question worth asking on this thread: should it? BOLT #5 already says MUST monitor until 100 deep. Nobody except CLN does that, for entirely understandable cost reasons. So either the 100 is aspirational and the real number should be written down somewhere normative, or implementations are collectively running below a MUST and calling it engineering judgement. Both are defensible readings; they're just different, and the disclosure is the natural place to settle which.
Everything else in my comments stands — lnd's floor is 3, you reach 6 only at 16,777,215 sat, and the operator override is unreachable on a release build (lnd#11072). It was only my gloss on the spec that was wrong. Post and tool are corrected.