feat(sdk-core): add EdDSA MPCv2 full 3-round signing orchestration

[Marzooqa]

• Add signTxRequest, signTxRequestForMessage, and signRequestBase to EddsaMPCv2Utils implementing WASM round 0 + API rounds 1 and 2
• Verify PGP signatures on BitGo round1Output and round2Output
• Return latestTxRequest after round 2 (round 3 + send deferred to next PR)
• Add signTxRequest unit tests using nock with real BitGo DSG sessions

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

TICKET: WCI-154

[linear-code]

WCI-154 [BitgoJS] Implement signRequestBase on EddsaMPCv2Utils - round 1 & round 2

[zahin-mohammad]

Reviewed against base #8687. Built locally — tsc --noEmit clean in sdk-core, signTxRequest.ts test passes (5/5).

The orchestration faithfully mirrors ECDSA's EcdsaMPCv2Utils.signRequestBase and the protocol structure looks right: WASM rounds 0/1/2 interleaved with API rounds 1/2/3, no client-side verification on round 3 (WP finalises). Nothing here freezes public API surface — the two new public methods (signTxRequest, signTxRequestForMessage) match the existing ITSSUtils/ECDSA shape, and signRequestBase is private. So everything below is follow-up safe.

Most significant finding is the missing mpcv2PartyId plumbing — backup signing is implicitly unsupported here even though the helpers from #8687 already accept the party id. ECDSA supports it; this is a behavioral gap vs the parallel path.

See inline comments.

[zahin-mohammad]

Backup-signer support gap. params.mpcv2PartyId (declared on TSSParamsWithPrv for exactly this purpose) is silently dropped. ECDSA's signRequestBase plumbs it through to both DSG init and the share helpers (see ecdsaMPCv2.ts:784, 792, 827, 845, 876, 893); here the user is hardcoded to MPCv2PartiesEnum.USER.

The helpers from #8687 already accept partyId: 0 | 1, so plumbing is mechanical:

const partyId = params.mpcv2PartyId ?? 0;
const userParty = partyId === 0 ? MPCv2PartiesEnum.USER : MPCv2PartiesEnum.BACKUP;
const userDsg = new EddsaMPSDsg.DSG(userParty);
userDsg.initDsg(userKeyShare, bufferContent, derivationPath, MPCv2PartiesEnum.BITGO);
// pass partyId through each getEddsaSignatureShareRoundN call

Follow-up safe — but worth filing as a Linear ticket so it doesn't get lost. Without it, EdDSA MPCv2 backup-signer flow can't go through this path.

[zahin-mohammad]

Typo: handleIncomingMessagexs → handleIncomingMessages.

[zahin-mohammad]

Assert ordering — the assert runs after Buffer.from(txOrMessageToSign, 'hex'). If signableHex is undefined, Buffer.from(undefined, 'hex') throws a TypeError first and the helpful assertion message never surfaces. Same pattern at L388-389 for the message branch. Suggest moving the assert above the Buffer.from call:

txOrMessageToSign = unsignedTx.signableHex;
assert(txOrMessageToSign, 'Missing signableHex in unsignedTx');
bufferContent = Buffer.from(txOrMessageToSign, 'hex');

[zahin-mohammad]

Defensive: handleIncomingMessages returns DeserializedMessages (an array). If WASM ever returns [] or an unexpected length, userMsg2 becomes undefined and the next getEddsaSignatureShareRound2(undefined, ...) crashes with a confusing PGP error. A targeted assert(userMsg2, 'WASM round 1 produced no message') after the destructure would surface the real failure. Same applies to userMsg3 at L478.

[zahin-mohammad]

Fragile share lookup: txRequestSignatureShares[length - 1] assumes BitGo's response share is always last. ECDSA does the same thing so it's not a regression, but it would be more robust to filter explicitly:

const bitgoShare = txRequestSignatureShares.find(
  (s) => s.from === SignatureShareType.BITGO && s.to === SignatureShareType.USER
);
assert(bitgoShare, 'Missing BitGo round-2 share');

Follow-up safe; flagging here so the pattern doesn't propagate further.

[zahin-mohammad]

Note (not blocking, pre-existing pattern): signTxRequestForMessage accepts a TSSParamsForMessageWithPrv which includes messageRaw: string and bufferToSign: Buffer, but signRequestBase ignores both — it derives bufferContent from txRequest.messages[0].messageEncoded. ECDSA does the same thing so this PR isn't introducing the issue, but it's a quiet footgun: a caller who passes bufferToSign thinking that's what gets signed will be confused when actual signing uses the txRequest's messageEncoded. Worth filing as a separate cleanup ticket against the shared TSSParamsForMessageWithPrv contract.

[Marzooqa]

I'll look into this as a follow-up https://linear.app/bitgo/issue/WCI-362/fix-tssparamsformessage-buffertosign-footgun-validate-against

[zahin-mohammad]

Coverage gap: rate-limit retries are tested for round 2 only. Rounds 1 and 3 use the same sendSignatureShareV2 retry path but aren't exercised. A parameterised helper that injects 429s on each round in turn would be cheap to add.

[zahin-mohammad]

Coverage gaps that pair with the mpcv2PartyId finding on the impl side:

• Tests only cover party 0 (USER); BACKUP path is untested.
• No round-2 tampered-signature negative test (round 1 negative is at L198, but round 2's verifyBitGoEddsaMessageRound2 could swallow tampering with no test catching it).
• No test for malformed/missing round-3 server response — currently any failure there surfaces as a confusing sendTxRequest error rather than something localised to round 3.

[zahin-mohammad]

LGTM — gated on #8687 landing first (per the DO NOT MERGE label).

All 8 prior comments are resolved in this revision:

• ✅ Backup-signer plumbing: params.mpcv2PartyId now flows through DSG init + all three getSignatureShareRound{One,Two,Three} calls; signerShareType derived from partyId
• ✅ Typo handleIncomingMessagexs → handleIncomingMessages
• ✅ Assert ordering moved before Buffer.from(...) in both tx and message branches
• ✅ Defensive assert(userMsg2, ...) / assert(userMsg3, ...) after each handleIncomingMessages destructure
• ✅ Fragile [length - 1] share lookup replaced with new getBitgoSignatureShare(shares, signerShareType) helper in tss/common.ts that filters by from === BITGO && to === signerShareType
• ✅ messageRaw/bufferToSign footgun tracked as follow-up WCI-362
• ✅ Rate-limit retry tests added for rounds 1 and 3 (round 2 was already covered)
• ✅ Test coverage: BACKUP path ("signs a txRequest with backup key") + malformed round-3 response added. Round-2 tampered-signature is covered at the helper level in #8687 (verifyBitGoMessageRoundTwo should throw on a tampered message), so the orchestration-level gap is acceptable

Residual nits — non-blocking, address in a follow-up

1. Inconsistent error style in signRequestBase. The GPG-key check uses if (!bitgoGpgPubKey) throw new Error(...) while every other invariant in this method uses assert(...). Unifying on assert(bitgoGpgPubKey, 'Missing BitGo GPG key for MPCv2') would keep the failure-mode style consistent.
2. Unnamed boolean args to pickBitgoPubGpgKeyForSigning(true, params.reqId, txRequest.enterpriseId, true). This is a pre-existing pattern carried over from ECDSA, not introduced here, but the call site reads as flag soup. Worth a separate cleanup ticket against the helper signature (named-options object or named consts) so the pattern doesn't propagate further.
3. Round-2 orchestration-level negative test for a wrong-type response would mirror the existing should throw if round 1 response has wrong type and round the symmetry out. Not strictly needed since verifyBitGoMessageRoundTwo is unit-tested at the helper layer, but cheap to add.

None of these block — happy to approve as-is.