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

feat(core): allow signing messages with multisig keys

Public commit record

What the developer wrote

Authored by Petr Susil

85/100 · Strong
feat(core): allow signing messages with multisig keys

Signing a message with a BIP-45, BIP-48, Casa or Unchained key failed with a
forbidden key path error. Any path whose public key or address can already be
shown is now accepted.

Fixes issue 7717.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug where Trezor hardware wallets refused to sign text messages with keys used for multisig wallets (BIP-45, BIP-48, Casa, Unchained). The change makes the device allow message signing on any key path where it can already display a public key or address. It also updates the companion trezorctl tool so that when it auto-detects a multisig-style path, it requests a single-key signature instead. This is a feature/bugfix rather than a vulnerability patch: it widens the set of allowed paths for the SignMessage operation, but only to paths the device already considers safe for public-key/address display.

Recommended action

Review as a normal feature/bugfix. Verify that the extra schemas added for SignMessage cannot be reused by other message types (the SignMessage.is_type_of guard appears to ensure this). Confirm that the fork-coin alias exclusion and taproot exclusion are correctly enforced in production builds. No emergency security response is indicated by the diff alone.

Security signals we found

01

Path validation relaxation scoped to SignMessage only

02

Multisig account/leaf paths now derivable for message signing

03

SPENDTAPROOT explicitly excluded from extra schemas

04

Fork-coin Bitcoin-namespace aliases deliberately not granted

05

CLI maps SPENDMULTISIG to SPENDADDRESS for single-key message signatures

06

New unit and device tests assert allowed/forbidden path matrix

Risk score

Why this scored 35/100

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