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

miniscript: Using Func and Expr when parsing keys, hashes, and locktimes

Public commit record

What the developer wrote

Authored by Ava Chow

73/100 · Adequate
miniscript: Using Func and Expr when parsing keys, hashes, and locktimes

Since pk(), pk_k(), pkh(), pk_h(), sha256(), ripemd160(), hash256(),
hash160(), after(), and older() all are single argument expressions that
are parsed immediately, we can use the Expr and Func parsing functions
to determine what the arguments of these expressions are, rather than
searching for the next closing parentheses.

This fixes an issue when pk(), pk_k(), pkh(), and pk_h() include a
musig() expression as Expr properly handles nested expressions.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes how Bitcoin Core reads certain pieces of text inside Miniscript and descriptor expressions. Previously, the parser looked for the next closing parenthesis to decide where an argument ended. That simple scan broke when the argument itself contained nested parentheses, such as a musig(...) key expression inside pk(...). The new code uses proper expression-parsing helpers that understand matching parentheses, so nested structures are handled correctly. The commit message explicitly calls this a fix for parsing musig() inside pk(), pkh(), pk_k(), and pk_h().

Recommended action

Treat as a bug-fix patch that should be applied to maintained branches using Miniscript/descriptor parsing. Review whether the old parser could be induced to accept malformed descriptors or produce incorrect script structures when nested parentheses appear, and consider adding regression tests for valid nested musig() expressions inside pk()/pkh().

Security signals we found

01

Parser previously used naive 'next )' delimiter scan, which mishandles nested parentheses

02

Commit message states this fixes parsing of musig() nested inside pk()/pkh()/pk_k()/pk_h()

03

Fuzzer crash test case retained and its expected error message updated

04

Change is localized to Miniscript/descriptor parsing, not consensus or P2P

05

No explicit CVE, security advisory, or researcher attribution in commit or references

Risk score

Why this scored 59/100

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