[anhthii]

Summary

Builds on #174. It keeps node-signed results and client-side verification, and narrows t+1 aggregation to keygen, the only result a client can't check on its own.

Result	A lying node could send	How the client catches it
Signing	A bad signature	Verify it against the wallet public key (client.VerifySigningResult)
Reshare	A different public key	Check the wallet public key is unchanged
Keygen	A fake public key	Can't be checked locally, so t+1 nodes must agree

Changes

Signing and reshare results are checked one message at a time (off / log / enforce) and delivered as soon as one valid copy arrives. No aggregator, timers or remembered outcomes.

New client.VerifySigningResult(keyType, pubKey, tx, result) verifies secp256k1 and ed25519 signing results against the wallet (or derived child) public key. It turns tx into the signed message the same way the nodes do.

Keygen keeps t+1. RequiredNodeSignatures is renamed to KeygenRequiredNodeSignatures, and a value above 1 requires enforce. RequiredNodeSignaturesForWallet and the reshare-committee threshold tracking are removed.

Per-node copies are requested by the client, not configured on nodes. result_signing.per_node_results is removed. When KeygenRequiredNodeSignatures > 1, CreateWallet sends Mpc-Keygen-Result-Copies: per-node. The keygen consumer forwards it, and the event consumer adds the node ID to the keygen result's idempotency key for that request only.

Why

• No node config to coordinate. Under per_node_results, the setting had to match on every node and be turned on in a fixed order. Turning it on too early gave every client N callbacks per result, and turning it on too late made every operation time out. Now old clients don't send the header and keep getting one copy.

• Fewer edge cases in the library. The shared aggregator for signing and reshare caused two problems:

  • a retry answered by a different node was dropped as a late copy;
  • a second OnSignResult replaced the first callback.

  Its remembered outcomes were also in-memory only, so they were lost on restart or failover.

• Duplicate handling belongs in the application. JetStream delivers at least once, so apps need durable handling by TxID, wallet or session anyway.

• Easier to port to mpcium-client-ts: the signing and reshare check is a stateless per-message function.

Compatibility and rollout

• No node config change, and the result body is unchanged.
• Deploy nodes before any client sets KeygenRequiredNodeSignatures > 1. Older nodes ignore the header and send one copy, so keygen would time out.
• Keygen errors reported by a single node (for example cluster not ready) reach a t+1 client only after the 15s aggregation timeout, the same as before.

Testing

• go test -race ./... passes.
• New and updated unit tests:
  • per-message verification: valid copy, unsigned, tampered body, wrong subject, unknown node, impostor key;
  • keygen quorum: waits for t+1, acks only after delivery, drops late copies, a forged pubkey loses to two honest nodes, copies split across subscriptions are counted together;
  • CreateWallet sends the header only when t+1 is required;
  • VerifySigningResult for secp256k1 and ed25519, including a tx with a leading zero byte.
• E2E suite not run yet.

[vietddude]

E2E with fystack/apex#828, 3 local nodes from this branch, keygen t+1 = 3, enforce:

• each node sent its own keygen copy and each wallet was created once;
• Stellar withdrawals succeeded from one signed copy;
• replayed, unsigned and forged results were dropped.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud