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

multi: rename "taproot" channel type to mean production variant

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
multi: rename "taproot" channel type to mean production variant

In this commit, we shuffle the CLI and RPC names so the bare "taproot"
identifier refers to the production taproot channel type (final
scripts, feature bits 80/81), i.e. the variant new integrations should
actually be using. Before this commit, "taproot" on the CLI mapped to
the staging bits, and anyone who wanted a real production taproot
channel had to spell out "taproot-final" on `lncli openchannel` or
`SIMPLE_TAPROOT_FINAL` over RPC. The recommended choice was hidden
behind the longer name.

On the CLI (`lncli openchannel --channel_type=...`):

- "taproot" now selects the production variant (it used to mean
staging).
- "taproot-staging" is added for the legacy development bits, for
peers that haven't moved over yet.
- "taproot-final" stays as a deprecated alias for "taproot" so
existing scripts don't break.

On the RPC (`CommitmentType`):

- `TAPROOT = 7` is added as the canonical name for the production
type. `SIMPLE_TAPROOT_FINAL = 7` is kept as a deprecated alias via
`option allow_alias = true`, so existing clients keep compiling
against the same Go constant and the wire value doesn't change.
- `SIMPLE_TAPROOT = 5` (staging) is unchanged.
- `SIMPLE_TAPROOT_OVERLAY = 6` is unchanged. The taproot-assets
daemon hard-codes this distinct enum value, so it's unaffected.

Wire compat is preserved end-to-end: only the comments, enum entry
order, and the CLI string-to-enum mapping change. The numeric values
and the existing generated Go identifiers stay stable.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change is a user-facing rename, not a security fix. The developers noticed that the short, obvious name 'taproot' was accidentally pointing to an older experimental ('staging') channel type, while the recommended production version required a longer, harder-to-find name. They swapped the labels so 'taproot' now means the production version, added 'taproot-staging' for the old experimental one, and kept 'taproot-final' as a compatibility alias. The underlying numeric codes on the network wire did not change, so existing software keeps working.

Recommended action

No security action required. Operators and integrators may review documentation to confirm they now use the intended taproot channel variant; the change is backward compatible.

Security signals we found

01

No memory-safety, cryptographic, or authorization changes

02

No bug fix or vulnerability remediation visible in diff

03

Backward-compatible alias added to avoid breaking existing clients

04

CLI mapping change could affect user expectations but is explicitly documented

Risk score

Why this scored 19/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 9/10
Evidence quality 5/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.