Repository navigation
feat(sdk-core): redpallas multi-spend array share helpers - #9998
Conversation
|
|
Bypass cooldown period check as these changes required for zcash privacy chain critical delivery TICKET: WCI-1963
749225e to
e2052ea
Compare
diksha190
left a comment
There was a problem hiding this comment.
SafeChain passed
Socket: Vulnerability 100, Supply Chain 99, Maintenance 79, Quality 79. T
he Overall 0 comes only from the package’s UNLICENSED license, which is expected for a BitGo-owned package.
Package: @bitgo/public-types@6.91.0.
Exception type: Other (zcash privacy chain onboarding delivery timeline). The diff vs 6.90.0 only changes the RedPallas rerand and signing schemas (msgN becomes an array per spend), with no new dependencies or scripts, and the PR needs it to type-check. No conditions.
Approved the PR.
TICKET: WCI-1963
Exception Type: Other
Justification: Needed for zcash privacy chain onboarding having critical delivery timeline
Current Dependency: @bitgo/public-types@6.90.0
Upgrade To: @bitgo/public-types@6.91.0
This pull request updates the RedPallas MPCv2 implementation to support multi-spend (fan-out) signing for shielded Zcash (ZEC) transactions, in line with WCI-1949. The changes generalize signature and rerandomization helpers to handle multiple concurrent per-spend sessions, ensuring that all protocol rounds (rerand and DSG) operate on arrays of messages (one per spend) and that all verification and signing logic is array-aware and order-preserving. This enables correct handling of transactions with multiple Orchard spends, as required by Wallet Platform and OVC.
Multi-spend support for RedPallas MPCv2 (WCI-1949):
getSignatureShareRoundOne/Two/Three,getRerandShareRoundOne/Two, and their verifiers) now accept and return arrays of messages, one per spend, and assert non-empty input arrays. This ensures correct fan-out for multi-spend ZEC transactions. [1] [2] [3] [4] [5] [6]Tests and validation:
rerand.tsthat runs three concurrent rerand sessions over the same DKG keyshare, verifying that each spend gets its own distinct rerandomized result and that sessions are fully independent and persistable.Documentation and code clarity:
redpallasMPCv2.tsto describe the multi-spend design, the importance of message order, and the all-or-nothing verification model. [1] [2] [3] [4] [5] [6]Dependency update:
@bitgo/public-typesdependency to version6.91.0inpackage.json.