AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 54 Bitcoin

watchtower: add production taproot channel support to justice kit

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
watchtower: add production taproot channel support to justice kit

Wire channel type through BreachRetribution and the watchtower blob
system to support production taproot channels with final scripts.

The key changes are:

1. Add ChanType field to BreachRetribution so downstream consumers
(including the watchtower) can determine the script variant.

2. Add FlagTaprootFinalChannel blob type flag and
TypeAltruistTaprootFinalCommit blob type to distinguish production
from staging taproot channels in watchtower backups.

3. Add TaprootFinalCommitment to the watchtower's CommitmentType enum
with appropriate witness type and size mappings.

4. Update taprootJusticeKit to use WithProdScripts() when constructing
script trees for production taproot channels. The isFinal flag is
set during construction from BreachRetribution.ChanType and during
deserialization from the blob's commitment type.

Without this change, the watchtower would construct justice transactions
using staging scripts for production taproot channels, resulting in
invalid witnesses that fail to sweep breached outputs.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in LND's watchtower (a service that helps recover funds if a channel partner tries to cheat) so it correctly handles production taproot channels. Before this fix, the watchtower would use the wrong script variant when building recovery transactions, producing invalid transactions that could not actually sweep the breached funds. The change wires the channel type through several internal data structures and adds a new blob type for final/production taproot channels. A small related change also makes the RBF cooperative close protocol use the current block height instead of a fixed height at startup, and forces RBF cooperative close to be enabled whenever taproot channels are enabled.

Recommended action

Treat this as a functional correctness fix with security implications for watchtower-backed taproot channels. Users running watchtowers and production taproot channels should upgrade so that justice transactions will be valid. Review whether any already-created watchtower state for production taproot channels used the wrong blob type and may need re-backup or migration. No immediate active-exploitation vector is evident from the diff.

Security signals we found

01

Incorrect script variant used for production taproot channels could prevent watchtower from sweeping breached outputs

02

New blob flag and commitment type added to differentiate staging vs production taproot scripts

03

BreachRetribution now carries ChanType to drive script-variant selection

04

taprootJusticeKit now applies WithProdScripts() based on channel type

05

RBF cooperative close height check now uses current best block height instead of FSM creation height

06

RBF cooperative close automatically enabled when taproot channels are enabled

Risk score

Why this scored 54/100

Our methodology →
Potential impact 18/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.