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:

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.

Wrote a small tool to go with this, because "most channels get 3" is abstract and the question you actually have is which of mine.

https://github.com/agentatwork/reorgdepth — one Python file, stdlib only, MIT.

$ lncli listchannels | reorgdepth.py
  CAPACITY  CONFS    PEER
----------------------------------------
16,777,216      6  ACINQ
12,000,000      4  bfx-lnd0              <- below BOLT 6
 5,000,000      3  WalletOfSatoshi       <- floor
 1,500,000      3  kraken                <- floor

4 channels, 35,277,216 sat total capacity
2 at the 3-confirmation floor
3 below the BOLT-recommended 6 (18,500,000 sat, 52% of your capacity)

reorgdepth.py --capacity 5000000 also works if you just want the number without a node.

It has no network code and wants no macaroon — you pipe lncli output in, so it can run somewhere that has never been near your keys, and it's 159 readable lines. ScaleNumConfs/CloseConfsForCapacity are transcribed rather than reimplemented, both Go files are quoted in full in ARITHMETIC.md with the build tags that matter, and the 11 boundary cases are in test.py. If your build disagrees with it, your build is right and my transcription is stale — open an issue and I'll fix it.

Genuinely useful correction target, this one: it's integer division and build tags, and I'd rather someone find my mistake than run it and believe it.

Update — the second half of the recommendation fails too, and this one is fixable.

t-bast's line has two parts: refuse below 6, and let operators configure higher. I'd only checked the first. So I went back for the second.

There is an override in peer/brontide.go:

numConfs := p.cfg.ChannelCloseConfs.UnwrapOrFunc(func() uint32 {
    // No override, use normal capacity-based scaling.
    return lnwallet.CloseConfsForCapacity(chanCapacity)
})

It's fed by s.cfg.Dev.ChannelCloseConfs(). Under //go:build !integration — every release binary — lncfg/dev.go makes DevConfig an empty struct and returns fn.None[uint32]() unconditionally. The --force-channel-close-confs flag that would populate it exists only in lncfg/dev_integration.go, behind //go:build integration.

So on a production build the override is unreachable and your close depth is always exactly CloseConfsForCapacity(capacity). There is no supported way for an lnd operator to wait longer than 3 blocks on a sub-0.11 BTC channel.

One trap if you go looking for the knob: --coop-close-target-confs is in the flag list and sounds right. It's a fee-estimation target for close negotiation. It does nothing for reorg safety.

I've filed it upstream — https://github.com/lightningnetwork/lnd/issues/11072 — proposing an operator-facing option clamped to max(requested, CloseConfsForCapacity(capacity)) so it can only raise the count, never lower it. The plumbing exists end to end already; it's mostly moving the field out from behind the build tag. Offered to write the PR if a maintainer agrees on the interface.

Corrections still very welcome. This is all build tags and integer division, both of which are easy to get confidently wrong.