mirror of
https://github.com/luxfi/mpc.git
synced 2026-09-24 00:26:24 +00:00
zeekayandHanzo Dev
72a2ae1371
api.KeygenResult carried only wallet_id, pubkeys and addresses — no threshold, no participants. Keygen accepts no per-request threshold (the ring's own --threshold governs), so a client had no way to learn what it actually got. That is not theoretical. luxfi/kms pkg/keys/manager.go validates req.Threshold (>=2, parties >= threshold), never sends it, then stores `Threshold: blsResult.Threshold, Parties: len(blsResult.Participants)`. Its client struct already declares both json fields, so with mpcd never emitting them every validator key set on record reads Threshold:0 Parties:0 while the caller had asked for 3-of-5 and passed validation. Ask for 3-of-5, silently get the ring's config, and record zero. Populate both from what the node is actually configured for: b.threshold, and a new ConfiguredParticipants() (peers + self, sorted). Configured — not GetReadyPeersIncludeSelf — because readiness answers "who is up right now", while a key's party set is a property of the key and must not change because a pod restarted; sorted so every node reports an identical list for the same key. Additive and backward compatible: both fields are omitempty, and the KMS client already decodes them. Clients can now compare against what they requested and fail closed. Tests: ConfiguredParticipants covers ring sizes, order normalization, cross-node determinism, and a peerIDs aliasing guard. Co-authored-by: Hanzo Dev <[email protected]>