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

Support musig in multi_a key expressions

Public commit record

What the developer wrote

Authored by Salvatore Ingala

78/100 · Adequate
Support musig in multi_a key expressions

musig() is deliberately rejected in sortedmulti_a, where sorting the
keys would require recomputing each aggregate key once per position;
doc/musig.md now documents that.

Also update some imprecisions in the documentation about
MAX_PUBKEYS_PER_MUSIG.

Add positive tests for musig in multi_a, and rejection test for musig
in sortedmulti_a (where sorting makes things more complicated).

The cleartext module makes sure that $keys only matches plain keys,
and not musig-aggregate keys.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds support for using MuSig multi-signature key groups inside taproot multi_a wallet policies on Ledger devices, while deliberately blocking them in sortedmulti_a. It also fixes a subtle parsing bug: previously, key expressions inside multi_a/sortedmulti_a were allocated one-by-one in a memory buffer, which would interleave badly with MuSig's own allocations and corrupt the in-memory layout. The new code parses all the keys into a temporary stack array first, then copies them into one contiguous allocation. Separately, the 'cleartext' human-readable display module now refuses to classify multisig patterns that contain musig keys, so the device falls back to showing the raw descriptor instead of potentially misleading text (for example, showing 'any 1 of two keys' for a musig that actually requires both).

Recommended action

Treat as a hardening/feature patch rather than an active vulnerability. Reviewers should verify that parse_multisig_keys() correctly bounds MAX_PUBKEYS_PER_MULTISIG, that the stack-local keys[] array size is safe on the target device's limited stack, and that all_keyexprs_plain() is applied consistently across every generated and hand-written multisig pattern so no musig-containing multisig is misclassified in the UI.

Security signals we found

01

Memory-layout correctness fix in policy parser (interleaved allocations could corrupt parsed policy nodes)

02

New guard prevents cleartext UI from misrepresenting musig-in-multisig policies as simpler plain-key multisigs

03

Feature gate: musig deliberately rejected in sortedmulti_a to avoid expensive/unsafe key re-sorting

04

Static assertion removed because contiguous allocation is no longer assumed

05

Test coverage added for both valid and invalid musig-in-multi_a cases

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/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.