Proposal for Implementing Message Signing for Multiple Use Cases

Current State

Message signing on SeedSigner today only works for conventional single sig paths (BIP44/49/84/86), and it's an Advanced setting that's disabled by default. Everything else is turned away, but not handled consistently. I won't dive into those detail here.

There are three open PRs, each expanding message signing in a different direction: #874 (BIP48 multisig) @AusDavo, #891 (BIP47) @MightyMercurian, and #925 (any derivation path, superseding #923) @berlinxray. #874 and #891 each add one more path to the allowlist. That works, but #874 gets there by mapping m/48h/.../2h/... onto NATIVE_SEGWIT so the existing screen can render something, which means the user is asked to confirm a single sig P2WPKH address derived from a multisig path. That address is not one their wallet will ever show them. #925 takes the more general route @kdmukai suggested here to allow any path rather than adding them one at a time. This PR avoids the bogus address by simply omitting it for custom paths completely. This means the the confirm screen has nothing on it to confirm. Both are working around the same constraint from opposite sides. I had another proposal I discussed with @AusDavo on PR #874.

Proposal

For any path that isn't a conventional single sig one, don't show an address. Show the key that's actually going to sign: the seed fingerprint, the derivation path, and the compressed pubkey derived at that exact path. This resolves #874, #891, and #925 with one screen, and it generalizes. BIP48, BIP47, Nostr, Unchained-style m/45h, account-level paths like m/84h/0h/0h, electrum m0h/ and anything else a coordinator invents in the future all work without further changes. Conventional single sig paths are untouched, since the receive address is genuinely what those users verify against their wallet, so they keep confirming an address.

On the risk of signing at arbitrary paths, I'm not aware of a fund-loss risk here, and I'd welcome correction. Worth restating that message signing is Advanced and off by default, so none of this is in a novice's default path.

I've used AI to locally implemented this (not a PR at least yet), and the flow is unchanged up to the confirmation step. I did this to test out the idea and to share screenshots here to help visualize what I'm proposing. First, review the message, paged for long messages, exactly as today:

From there the flow branches. A conventional single sig path like m/84h/0h/0h/0/0 still confirms the receive address exactly as it does today.

Any other path now routes to a new screen, SeedSignMessageConfirmPubkeyView, shown here for a BIP48 multisig path. Fingerprint on top so you know which seed, then the derivation path, then the compressed pubkey truncated first-7/last-7 across two lines in the same fixed-width style the address screen already uses:

One more screen came out of this, a bit incidentally but worth surfacing. The signmessage QR decoder does no validation of the derivation path, and today the clean_match check happens to catch garbage as a side effect. Once arbitrary paths are allowed, that accidental guard is gone, and a malformed path would go straight into key derivation and cause errors. A bad QR is bad input, not a SeedSigner failure, so it now gets a proper screen:

Happy to open this as a PR if the direction seems right. Happy to let someone else open the PR and complete the work. I mainly wanted to gather input from the different folks involved in the different PRs and confirm this approach would work for the different use cases.

Message signing from keys at custom derivation paths #519

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions