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

Lowers MAX_N_IN_THRESH to 24

Public commit record

What the developer wrote

Authored by Salvatore Ingala

70/100 · Adequate
Lowers MAX_N_IN_THRESH to 24

It is extremely unlikely to be hit in practice, and has a large memory
impact because of the dynamic programming tables of compute_thresh_ops()
and compute_thresh_stacksize()

The dynamic programming tables of compute_thresh_ops() and
compute_thresh_stacksize() are sized for MAX_N_IN_THRESH, causing them
to contribute a substantial stack usage, especially with nested
thresh fragments.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit reduces a hard-coded limit in Ledger's Bitcoin app on how many branches a 'thresh' miniscript operator can have, from 128 down to 24. The change is framed as a memory-usage improvement, not a security fix. It also adds a test to make sure policies exceeding the new limit are rejected rather than analyzed with an undersized table. There is no direct evidence in the commit or supplied references that this was a disclosed vulnerability or that an exploit exists.

Recommended action

Treat as a defensive hardening change. Review whether the lowered limit is acceptable for all supported wallet policies and user-visible error messages. Consider adding an explicit runtime check on the thresh branch count before table allocation, so future increases to MAX_N_IN_THRESH do not reintroduce stack overflow risk. No urgent patch cycle is indicated absent evidence of active exploitation.

Security signals we found

01

Stack-memory pressure reduction in recursive miniscript analysis

02

Hard-coded threshold lowered to prevent large dynamic-programming tables

03

New unit test checks rejection of oversized thresh fragments

04

No explicit bounds check added independent of the constant

05

No vendor statement of security relevance or CVE in commit

Risk score

Why this scored 43/100

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