Encode BIP137 SegWit message signature headers

[j0ntz]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Description

Asana task

Edge's BTC message signing (used for CEX/ramp withdrawal ownership proofs, e.g. Bringin / NiceHash Travel Rule) produced a signature whose header byte always encoded a legacy P2PKH type (27-34), regardless of the signing address. BIP137 verifiers reject a legacy-header signature that comes from a SegWit address: nested SegWit (P2SH-P2WPKH) requires header 35-38 and native SegWit (P2WPKH / bech32) requires 39-42. Because Edge BTC wallets default to SegWit, the signatures Edge emitted were rejected by Bringin; a user had to run a script to rewrite the header to BIP137 before it was accepted, or fall back to selfie/ID verification.

signMessageBase64 in keymanager.ts called bitcoinMessage.sign(message, privKey, compressed) with no segwitType, so the header byte only reflected the compressed flag. This threads the address's derivation format through and selects the matching segwitType:

• bip84 (native SegWit / P2WPKH) -> header 39-42
• bip49 (nested SegWit / P2SH-P2WPKH) -> header 35-38
• bip44 / bip32 (legacy P2PKH) -> header 31-34 (unchanged)

The header selection routes through the canonical BIP43PurposeTypeEnum rather than raw format string literals, so a newly-added SegWit format fails loudly in the purpose mapping instead of silently falling through to a legacy header.

The ECDSA signature is unchanged for legacy P2PKH signing on Bitcoin; only the header byte differs there. The fix is general across all UTXO coins that support SegWit, since path.format reflects the actual address derivation.

BIP137 is opt-in

asUtxoSignMessageOtherParams carries signatureFormat: 'electrum' | 'bip137', defaulting to electrum. segwitType is applied only when bip137 is requested, so existing callers (bityProvider, EdgeProviderServer) keep the header byte they produce today. Emitting BIP137 unconditionally would have been a silent behavior change for them, and it would have broken EdgeApp/edge-react-gui#6065 depending on merge order: that PR's "Standard (Electrum)" option would have started emitting BIP137 headers. Making it opt-in removes the ordering hazard, and the GUI now sends the option instead of rewriting the header itself.

Scoped purpose lookup

bip43PurposeNumberToTypeEnum throws on a purpose it does not map, so resolving it unconditionally would let a future CurrencyFormat (bip86 Taproot being the obvious candidate) break message signing on the default Electrum path, which never needs it. The lookup lives in a getBip137SegwitType helper that returns before touching it unless BIP137 is requested, so an unmapped format can only affect BIP137 signing.

AddressNotOwnedError

signMessage throws a named AddressNotOwnedError when the wallet cannot sign for the requested address, whether it fails to parse or simply is not ours. Callers branch on error.name rather than matching parser prose, following the existing asMaybeInsufficientFundsErrorPlus pattern.

Coin message prefixes

The header byte alone is not enough for non-Bitcoin coins. signMessageBase64 previously magic-hashed with bitcoinjs-message's default "Bitcoin Signed Message:\n" for every coin, so an altcoin signature carried the right header but the wrong prefix and would not verify against that coin's own addresses. It now hashes with the coin's own prefixes.messagePrefix[0].

That made the prefix data load-bearing for the first time, and an audit by @peachbits (commit absorbed here, authored by them and ordered first) found 14 coins wrong. bitcoinjs-message copies the prefix into the hash verbatim and only varint-encodes the message length, so the prefix must carry its own leading CompactSize byte, mirroring ss << strMessageMagic in each coin's C++. Two failure classes: a wrong length byte (litecoin, dogecoin, feathercoin, zcoin, bitcoingold and its testnet) and a wrong string, usually Bitcoin's default left in place (dash, pivx, ecash, qtum, ravencoin, smartcash, ufo, digibyte). Dash's DarkCoin, PIVX's DarkNet, and Vertcoin's genuine use of Bitcoin's magic are pre-rebrand or intentional and are commented so they do not get "fixed" back.

Testing

• Unit tests pin both encodings on bitcoin and litecoin: the default produces the same H… header for bip44, bip49 and bip84, and only an explicit bip137 request shifts bip49 to I… and bip84 to J…. 12 cases, so swapping the two formats fails the suite. tsc, eslint, and the full mocha suite pass (1251 tests); npm run verify passes.
• messagePrefix.spec.ts asserts every registered coin's prefix leading byte matches its string length, covering 24 coins. This is the guard that makes a silently-unverifiable prefix a build failure.
• Litecoin sign-message vectors verify via bitcoinjs-message.verify against the derived legacy, P2SH-P2WPKH, and bech32 LTC addresses, and are confirmed NOT to verify under Bitcoin's prefix, so a regression back to the default would fail the suite.
• Offline round-trip: each Bitcoin format's signature verifies via bitcoinjs-message.verify against its real P2PKH / P2SH-P2WPKH / bech32 address.
• In-app (iOS sim, edge-funds BTC wallet): drove the real EdgeCurrencyWallet.signMessage path with this build linked, on the wallet's own receive addresses. The nested-SegWit 3... address produced header 35 and the native-SegWit bc1q... address produced header 40, both verifying against their respective addresses (screenshot attached). Before the fix both emitted header 31, which fails BIP137 verification for a SegWit address.
• In-app, opt-in round (iOS sim, this build linked into edge-react-gui#6065 via updot): signing the same message with bip84 address bc1q7f5wkp5k0847utsec7p8v59cqj7et6wrzz7dv4 produced header 32 under the default and header 40 under signatureFormat: 'bip137', identical r/s, both verifying against that address via bitcoinMessage.verify(..., checkSegwitAlways: true). That confirms the default no longer emits a SegWit header.

Asana: https://app.asana.com/1/9976422036640/project/1215088146871429/task/1216403654258303

---

Note

Medium Risk
Changes message-signing output for altcoins (prefix fixes) and opt-in BIP137 headers; default Electrum behavior is preserved but wrong-prefix fixes alter signatures that may have been used in production for non-BTC chains.

Overview
UTXO message signing is extended so ramp/CEX ownership proofs (e.g. BIP137 verifiers) can succeed without clients rewriting signatures.

signMessage accepts optional signatureFormat: 'electrum' | 'bip137' (default electrum). With bip137, signMessageBase64 sets bitcoinjs-message segwitType from the address derivation path (bip49 → nested SegWit, bip84 → native SegWit). Signing now uses each coin’s messagePrefix instead of Bitcoin’s default, and 14 altcoins had wrong prefix strings/length bytes corrected.

signMessage throws AddressNotOwnedError when the address is invalid for the chain or not owned by the wallet (replacing generic errors).

Tests add Bitcoin/Litecoin vectors for both encodings and messagePrefix.spec guards prefix CompactSize bytes across all registered coins.

^{Reviewed by Cursor Bugbot for commit 10d018f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[j0ntz]

📸 Test evidence: in-app BIP137 signatures (iOS sim, edge-funds BTC wallet)

agent proof 1216403654258303 01 bip137 signatures

Captured by the agent's in-app test run (build-and-test).

[j0ntz]

Automated code review (workflow-backed, high effort). All findings are advisory; the core BIP137 header fix is correct and matches the task requirement. Three notes below.

[j0ntz]

Updated in 4cb6e2b to resolve the cross-PR conflict raised on EdgeApp/edge-react-gui#6065.

BIP-137 is now opt-in rather than unconditional. asUtxoSignMessageOtherParams carries signatureFormat: 'electrum' | 'bip137', defaulting to electrum, threaded through UtxoEngine.signMessage → UtxoWalletTools.signMessageBase64 → keymanager.signMessageBase64, which applies segwitType only when BIP-137 is requested. Existing callers (bityProvider, EdgeProviderServer) keep the header byte they produce today, so this stops being a silent behavior change for them and merge order with #6065 no longer matters.

Also here:

• signMessage throws a named AddressNotOwnedError for an address the wallet cannot sign for, whether it fails to parse or simply is not ours. Callers branch on error.name instead of matching parser prose (same pattern as asMaybeInsufficientFundsErrorPlus).
• The keymanager spec covers both directions on bitcoin and litecoin: the default encoding yields the same H… header for bip44/bip49/bip84, and only an explicit bip137 request shifts bip49 to I… and bip84 to J…. 12 cases, so swapping the two formats fails the suite.

npm run verify passes locally (1251 tests). Driven end to end on the iOS sim with this build linked into the GUI: signing with a bip84 bc1q… address produced header 32 under the default and header 40 under BIP-137, identical r/s, both verifying against that address via bitcoinMessage.verify(..., checkSegwitAlways: true).

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d8f9bbc. Configure here.}