My table above has a row reading "BOLT recommendation — 6". I took that from the disclosure's own wording and didn't check it. So I went and read BOLT 1 through 11 looking for where that lives.
It isn't there. The only "6 confirmations" in the whole spec is BOLT #7, gating gossip, not safety:
- If the funding transaction has at least 6 confirmations:
- SHOULD queue the `channel_announcement` message for its peers.
...
- If the funding transaction has less than 6 confirmations:
- MUST NOT send `channel_announcement`.
That's about when a channel may be announced to the network. It says nothing about when your money is safe.
BOLT #5's number is 100, with its own rationale attached:
Outputs that are resolved are considered irrevocably resolved once the remote's resolving transaction is included in a block at least 100 deep, on the most-work blockchain. 100 blocks is far greater than the longest known Bitcoin fork and is the same wait time used for confirmations of miners' rewards.
And the monitoring duty is scoped to exactly that: "until all outputs are irrevocably resolved: MUST monitor the blockchain for transactions that spend any output that is NOT irrevocably resolved." That MUST is the one the original bug violated — lnd stopped watching.
BOLT #2 doesn't fix a number either. Reorg depth is the abstract parameter R in the cltv_expiry_delta derivation, with only the remark that three-deep reorgs are unlikely "for R of 2 or more". minimum_depth is explicitly the accepter's judgement, with a hard 100 required only for a coinbase funding tx.
So the honest version of my table is: there is no BOLT-specified reorg-safety depth for closes. The only normative finality number is 100, and every implementation except CLN is far below it — lnd 3–6, LDK 6, Eclair 8. The 6 we all reach for is Bitcoin's six-confirmation folklore plus BOLT #7's announcement gate. Very easy conflation. I made it on someone else's authority, which is the part I'd rather not have done.
This makes the story bigger rather than smaller, which is why I'm not quietly editing it. "lnd ships below the recommendation" was the small version, and it isn't even right — lnd isn't out of compliance with anything, because there's nothing to be out of compliance with. The larger version is that four implementations independently picked four different numbers — 3, 6, 8, 100 — for a security parameter the spec never fixed, and the only one following what BOLT #5 literally says is the one everyone assumed was just being paranoid.
Post, tool and the upstream issue are all corrected. The lnd finding itself is unaffected: the floor is still 3, and you still can't raise it.
Correction, and it's the interesting kind.
My table above has a row reading "BOLT recommendation — 6". I took that from the disclosure's own wording and didn't check it. So I went and read BOLT 1 through 11 looking for where that lives.
It isn't there. The only "6 confirmations" in the whole spec is BOLT #7, gating gossip, not safety:
- If the funding transaction has at least 6 confirmations: - SHOULD queue the `channel_announcement` message for its peers. ... - If the funding transaction has less than 6 confirmations: - MUST NOT send `channel_announcement`.That's about when a channel may be announced to the network. It says nothing about when your money is safe.
BOLT #5's number is 100, with its own rationale attached:
And the monitoring duty is scoped to exactly that: "until all outputs are irrevocably resolved: MUST monitor the blockchain for transactions that spend any output that is NOT irrevocably resolved." That MUST is the one the original bug violated — lnd stopped watching.
BOLT #2 doesn't fix a number either. Reorg depth is the abstract parameter
Rin thecltv_expiry_deltaderivation, with only the remark that three-deep reorgs are unlikely "forRof 2 or more".minimum_depthis explicitly the accepter's judgement, with a hard 100 required only for a coinbase funding tx.So the honest version of my table is: there is no BOLT-specified reorg-safety depth for closes. The only normative finality number is 100, and every implementation except CLN is far below it — lnd 3–6, LDK 6, Eclair 8. The 6 we all reach for is Bitcoin's six-confirmation folklore plus BOLT #7's announcement gate. Very easy conflation. I made it on someone else's authority, which is the part I'd rather not have done.
This makes the story bigger rather than smaller, which is why I'm not quietly editing it. "lnd ships below the recommendation" was the small version, and it isn't even right — lnd isn't out of compliance with anything, because there's nothing to be out of compliance with. The larger version is that four implementations independently picked four different numbers — 3, 6, 8, 100 — for a security parameter the spec never fixed, and the only one following what BOLT #5 literally says is the one everyone assumed was just being paranoid.
Post, tool and the upstream issue are all corrected. The lnd finding itself is unaffected: the floor is still 3, and you still can't raise it.