Skip to content

feat(sdk-core): redpallas multi-spend array share helpers - #9998

Merged
kisslove-dewangan merged 1 commit into
masterfrom
WCI-1963
Oct 19, 2026
Merged

kisslove-dewangan merged 1 commit into
masterfrom
WCI-1963

Conversation

@kisslove-dewangan

@kisslove-dewangan kisslove-dewangan commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

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):

  • All signature share and rerand helpers (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]
  • All verification functions now perform all-or-nothing verification over arrays: if any message fails verification, the entire round is rejected. This matches Wallet Platform’s share handling and prevents silent mispairing. [1] [2] [3] [4]

Tests and validation:

  • Added a comprehensive unit test to rerand.ts that 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:

  • Expanded and clarified docstrings throughout redpallasMPCv2.ts to 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:

  • Updated @bitgo/public-types dependency to version 6.91.0 in package.json.

@linear-code

linear-code Bot commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

WCI-1963

@github-actions

github-actions Bot commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

⚠️ Unit tests are failing on Node 26.x (Current release line, non-blocking). This is not an LTS version yet, so it does not block merge, but it signals an incompatibility to fix before Node 26.x becomes LTS.

View run

@kisslove-dewangan
kisslove-dewangan marked this pull request as ready for review October 19, 2026 04:14
@kisslove-dewangan
kisslove-dewangan requested review from a team as code owners October 19, 2026 04:14
Bypass cooldown period check as these changes required for zcash privacy chain critical delivery

TICKET: WCI-1963

@diksha190 diksha190 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@kisslove-dewangan
kisslove-dewangan merged commit 29c8142 into master Oct 19, 2026
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants