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

contractcourt: add channel type support to HTLC resolvers

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
contractcourt: add channel type support to HTLC resolvers

This commit extends all HTLC contract resolvers to accept and store channel
type information, which is essential for determining whether to use staging
or production taproot witness types during contract resolution. Each resolver
constructor now accepts a channeldb.ChannelType parameter and stores it as
a field within the resolver struct.

The channel arbitrator has been updated to extract channel type information
from the channel state and pass it to all resolver constructors. This ensures
that each resolver has the necessary context to make appropriate decisions
about script generation and witness type selection based on the specific
channel type being resolved.

Helper methods isTaprootFinal() have been added to each resolver to provide
a clean interface for determining when production taproot witness types
should be used. This lays the groundwork for the resolvers to properly
handle both staging and production taproot channels with the correct
script optimizations.

The changes maintain backward compatibility with existing channel types
while providing the infrastructure needed for production taproot channel
support throughout the contract resolution system.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit prepares LND's on-chain contract-resolution code to distinguish between experimental 'staging' taproot channels and the new 'final' production taproot channels. It passes the channel type into HTLC resolvers and adds helper checks so the correct Bitcoin witness script is chosen when a channel is force-closed. The change itself is infrastructure: it does not fix an active bug, but it prevents a class of future failures where a production taproot channel could be resolved using the wrong script type.

Recommended action

Review the corresponding witness-generation functions (MakeTaprootHtlcSucceedInputFinal, etc.) and ensure the new *Final witness types are covered by unit and integration tests for production taproot channel force-closes. Verify that chanType is non-zero for all persisted channels that may be resolved after restart.

Security signals we found

01

Witness-type selection now branches on final vs staging taproot channel type

02

Channel type is persisted/restored via SupplementState to survive restarts

03

Incorrect witness type for a production taproot channel could make on-chain HTLC claims fail or be non-standard

04

Change is defensive/infrastructure rather than a direct vulnerability fix

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/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.