Repository navigation
chore(platform)!: update rust-dashcore past the FFI removal - #5729
Merged
Merged
Conversation
Contributor
|
Important Review skippedToo many files! This PR contains 198 files, which is 98 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry.
 |
5 of 6 tasks
Collaborator
|
✅ Final review complete — no blockers (commit 70abc13) · triage: normal |
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
from
November 3, 2026 05:35
8671039 to
46685b3
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
2 times, most recently
from
November 3, 2026 05:42
9176fc6 to
fda1e70
Compare
6 of 15 tasks
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
2 times, most recently
from
November 3, 2026 09:10
6a82cbb to
d3acb2c
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
2 times, most recently
from
November 3, 2026 09:15
444bb7e to
7377b8e
Compare
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
from
November 3, 2026 10:14
d3acb2c to
9a638e9
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 3, 2026 10:15
7377b8e to
70aa0a1
Compare
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
from
November 3, 2026 14:02
9a638e9 to
2887bfd
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 3, 2026 14:14
70aa0a1 to
d0345d5
Compare
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
from
November 3, 2026 14:46
2887bfd to
ac71375
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 3, 2026 14:47
d0345d5 to
a103d30
Compare
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
from
November 3, 2026 23:14
ac71375 to
6a737ac
Compare
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 3, 2026 23:14
a103d30 to
105aae2
Compare
xdustinface
force-pushed
the
refactor/drop-key-wallet-ffi-dependency
branch
2 times, most recently
from
November 4, 2026 10:22
d001e3e to
56e4ea2
Compare
Base automatically changed from
refactor/drop-key-wallet-ffi-dependency
to
v5.1-dev
November 4, 2026 12:58
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 5, 2026 02:23
105aae2 to
dbc10ad
Compare
xdustinface
marked this pull request as ready for review
November 5, 2026 02:24
Contributor
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
github-actions
Bot
added
the
waiting-bots
thepastaclaw
suggested changes
Nov 5, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Final validation — Phase 1 + Phase 2
Verified the findings against exact head dbc10ad and the pinned rust-dashcore source. Two blocking regressions remain: standalone DAPI loses X11 block hashing, and peer tracking can retain disconnected peers across internal SPV recovery, incorrectly reporting broadcast readiness. This was a static review; current CI reports successful code checks, including Rust, WASM, Docker, Swift, Kotlin, and end-to-end tests.
🔴 2 blocking
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: tenderdash-consensus-security); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — Despite its broad reach, the diff is primarily a dependency/API migration with equivalence-preserving hash and key adaptations and contained finality-error handling, rather than a clearly large or intricate change to critical behavior. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer,muse-spark-1.3-contributor— rust-quality (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— ffi-engineer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— platform-versioning (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— tenderdash-consensus-security (completed, effort high); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-dapi/Cargo.toml`:
- [BLOCKING] packages/rs-dapi/Cargo.toml:89-92: Preserve X11 block hashing when removing dash-spv
Removing dash-spv also removes the dependency that enabled dashcore's `core-block-hash-use-x11` feature. The remaining standalone rs-dapi dependency closure does not enable it: dashcore defaults to bincode, rpc-json enables rand-std/signer/serde, and neither DPP's selected features nor key-wallet enables X11. The production Dockerfile builds only `--package rs-dapi --locked`, so upstream `dash/src/hash_types.rs` now selects SHA256d for BlockHash instead of X11. Consequently, `block_hash_from_block_bytes` computes incorrect Dash block IDs. Historical streaming records the actual RPC block hash, while live streaming records this SHA256d hash, defeating historical/live duplicate suppression in both block-header and transaction-with-proofs streams. Explicitly enable X11 through a directly used dashcore dependency in rs-dapi. Add a test against an independently pinned Core block hash: the existing vector test compares two calls to the same feature-dependent hashing implementation and passes with either algorithm.
In `packages/rs-platform-wallet/src/spv/peers.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/spv/peers.rs:87-99: Resynchronize peer tracking across internal SPV restarts
The per-peer event stream is not continuous across dash-spv's internal fork recovery. At the pinned revision, sync_coordinator cancels and joins its network-event monitor before lifecycle::handle_fork stops the network, truncates storage, and starts another run. PeerNetworkManager::stop clears its connected set during that unmonitored interval, so departures can be lost before the new subscription starts. Platform clears this tracker only on its own stop or startup failure. Thus connect A → internal recovery → connect B → disconnect B can leave A in this set indefinitely; ignoring PeersUpdated, including a zero connected_count, cannot reconcile it. This affects operation recovery, not just display: SpvRuntime::is_broadcast_ready trusts this set, allowing pending sends to exhaust retries without waiting for actual peers. Asset-lock recovery also leaves its transport_missed flag false and skips the readiness-deferred retry. Use authoritative client peer counts for readiness and restore reset-aware peer synchronization. The lifecycle snapshot/reset capability belongs in rust-dashcore's dash-spv and should be consumed here. Add coverage for an internal restart with different replacement peers followed by loss of all peers.
Comment on lines
89
to
92
| # Dash Core RPC client | ||
| dashcore-rpc = { workspace = true } | ||
| dash-spv = { workspace = true } | ||
|
|
||
| rs-dash-event-bus = { path = "../rs-dash-event-bus" } |
Collaborator
There was a problem hiding this comment.
✅ Resolved at
70abc134; see the replies below.
🔴 Blocking: Preserve X11 block hashing when removing dash-spv
Removing dash-spv also removes the dependency that enabled dashcore's core-block-hash-use-x11 feature. The remaining standalone rs-dapi dependency closure does not enable it: dashcore defaults to bincode, rpc-json enables rand-std/signer/serde, and neither DPP's selected features nor key-wallet enables X11. The production Dockerfile builds only --package rs-dapi --locked, so upstream dash/src/hash_types.rs now selects SHA256d for BlockHash instead of X11. Consequently, block_hash_from_block_bytes computes incorrect Dash block IDs. Historical streaming records the actual RPC block hash, while live streaming records this SHA256d hash, defeating historical/live duplicate suppression in both block-header and transaction-with-proofs streams. Explicitly enable X11 through a directly used dashcore dependency in rs-dapi. Add a test against an independently pinned Core block hash: the existing vector test compares two calls to the same feature-dependent hashing implementation and passes with either algorithm.
source: gpt-6.1-sol (phase2-reviewer: general)
Collaborator
There was a problem hiding this comment.
Resolved (re-reviewed at 70abc134): Your direct rs-dapi dependency now explicitly enables dashcore/core-block-hash-use-x11, preserving X11 block hashing when rs-dapi builds independently of dash-spv. The updated regression test computes its expected X11 digest directly from the header bytes, and the standalone RS-DAPI image check passes.
Comment on lines
+87
to
+99
| match event { | ||
| NetworkEvent::PeerConnected(address) => { | ||
| let mut connected = self.connected(); | ||
| // dash-spv can reconnect an address before the old | ||
| // connection's departure, which it then leaves unannounced. | ||
| if !connected.contains(address) { | ||
| connected.push(*address); | ||
| } | ||
| } | ||
| NetworkEvent::PeerDisconnected(address) => { | ||
| self.connected().retain(|connected| connected != address); | ||
| } | ||
| NetworkEvent::PeersUpdated { .. } => return, |
Collaborator
There was a problem hiding this comment.
✅ Resolved at
70abc134; see the replies below.
🔴 Blocking: Resynchronize peer tracking across internal SPV restarts
The per-peer event stream is not continuous across dash-spv's internal fork recovery. At the pinned revision, sync_coordinator cancels and joins its network-event monitor before lifecycle::handle_fork stops the network, truncates storage, and starts another run. PeerNetworkManager::stop clears its connected set during that unmonitored interval, so departures can be lost before the new subscription starts. Platform clears this tracker only on its own stop or startup failure. Thus connect A → internal recovery → connect B → disconnect B can leave A in this set indefinitely; ignoring PeersUpdated, including a zero connected_count, cannot reconcile it. This affects operation recovery, not just display: SpvRuntime::is_broadcast_ready trusts this set, allowing pending sends to exhaust retries without waiting for actual peers. Asset-lock recovery also leaves its transport_missed flag false and skips the readiness-deferred retry. Use authoritative client peer counts for readiness and restore reset-aware peer synchronization. The lifecycle snapshot/reset capability belongs in rust-dashcore's dash-spv and should be consumed here. Add coverage for an internal restart with different replacement peers followed by loss of all peers.
source: gpt-6.1-sol (phase2-reviewer: general)
Collaborator
There was a problem hiding this comment.
Resolved (re-reviewed at 70abc134): Your c9aeac0d repin addresses the internal-restart sequence upstream: network shutdown cancels admissions, clears connected peers, and emits an empty PeersUpdated snapshot before cancelling and joining the event monitors, which drain queued events. Platform's PeerTracker replaces its cached addresses from those authoritative snapshots, so departed peers no longer remain cached through the fork restart.
Contributor
|
Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix; thepastaclaw left review threads unresolved; resolve them. |
github-actions
Bot
added
the
waiting-self-review
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 5, 2026 11:07
fa85397 to
1677942
Compare
xdustinface
marked this pull request as ready for review
November 5, 2026 11:14
Contributor
|
Your move: thepastaclaw left review threads unresolved; resolve them. |
github-actions
Bot
added
the
waiting-self-review
xdustinface
marked this pull request as draft
November 5, 2026 11:28
github-actions
Bot
removed
the
waiting-self-review
Moves every rust-dashcore pin from `7329126e` to `a319c0a3`, the current `dev` of dashpay/rust-dashcore. It includes dashpay/rust-dashcore#776 (FFI crates removed) and `TxIn::claimed_p2pkh_address`. Base SDK moves to 89828032. Adapted: - #1266: seeds and phrases come back as `Zeroizing` buffers and are borrowed, not copied - #1250: `AppEncryption` uses `application_encryption_path`, `AppEncryptionLegacy` the `_without_rotation` variant, so derived keys and paths are byte-identical - #902: `PeersUpdated` no longer lists addresses, so `PeerTracker` builds the connected set from `PeerConnected` / `PeerDisconnected` - #1223: devnet LLMQ size and threshold are `u16`, and larger values are now refused - #1189: `dash-spv`'s `sync` module is private, so imports use the public re-exports - #1223: the Base SDK's `LlmqParams` keeps the DKG fields flat as `u16`, so the verified context provider and the `refresh_checkpoints` example read `dkg_interval` and widen both counts to `u32`, giving the same fetch window and depth - #1320: hash newtypes no longer have `engine` or `from_engine`, so the ChainLock request id in `drive-abci` and the ProUpServTx payload hash in `platform-wallet` hash through `sha256d::Hash` and wrap the result, which gives the same bytes - #1320: upstream hash types no longer index into bytes or have `from_slice`, so callers read `as_byte_array` and use the newtypes' own `from_slice` and `all_zeros` - #1320: the newtypes' conversions are inherent functions, so the `Hash` trait imports that only served them go, and `rs-dapi` drops `dash-spv`, whose only use was that import dash-spv applies the `/name:version/` form and the 256-byte bound to the user agent again (#1311), so `platform_wallet_manager_spv_start` passes the configured user agent through. Behaviour that changes upstream: an existing SPV store resyncs its masternode lists once, because #1227 changed the snapshot format. The default user agent becomes `/dash-spv:<version>/`. #1273 (payload written only from version 3) and #1269 (`OP_CODESEPARATOR` in the legacy sighash) do not affect transactions Platform builds or verifies. #400 (SegWit and Taproot removed), #1288 (`bitcoin_units` re-exports), #1289 (dependency maintenance), #1318 (`bitcoinconsensus` removed), #1307 (partial merkle trees bounded by Dash's block size) and #1258 (masternode sync kept live on bad or missing diffs) need no change in Platform.
rust-dashcore now has the P2PKH sender check that `decode_transaction` carried a copy of, so it calls that instead. The script shape test goes with the copy, because rust-dashcore's `test_claimed_p2pkh_address` covers every case it had.
key-wallet now refuses an asset lock build with `BuilderError::FundsAwaitingFinality` when only coins that are not final yet would fund it. `map_builder_error` let that fall into the generic `AssetLockTransaction` string, so a caller could not tell "wait for confirmation" from a hard failure.
Map it to a new `PlatformWalletError::AssetLockFundsAwaitingFinality { waiting }`. The FFI maps the new variant to the existing `ErrorAssetLockInsufficientFunds` (29) code, so iOS and Android behave as before until hosts get a dedicated code.
`map_asset_lock_funding_result` passed only `AssetLockInsufficientFunds` to the typed conversion, so `AssetLockFundsAwaitingFinality` from the shielded fund-from-asset-lock path flattened to `ErrorWalletOperation` (6) while the non-shielded entry point returns 29.
dashpay/rust-dashcore#1320 moves `dashcore_hashes` onto `bitcoin_hashes` 1.x from the rust-bitcoin rev that `bitcoin-crypto` uses. The crates.io `bitcoin_hashes` 0.14 no longer gets its `io` feature, so the crates.io `bitcoin-io` and `bitcoin-consensus-encoding` 1.3.0 that took `bitcoin-internals` 0.7.0 from crates.io leave the graph. Since dashpay/rust-dashcore#1224 the same already held for `base58ck`, `bitcoin_hashes` and `bitcoin-units`. No crates.io dependency asks for a version the git rev provides, so the whole patch section goes. `Cargo.lock` is unchanged and `cargo vendor --locked` succeeds. Closes #5648.
Dropping `dash-spv` from `rs-dapi` also dropped the only thing in its dependency graph that enabled `dashcore`'s `core-block-hash-use-x11` feature. The Docker image builds `--package rs-dapi` alone, so `BlockHash` fell back to SHA256d and `block_hash_from_block_bytes` returned wrong Dash block hashes. `rs-dapi` now depends on `dashcore` with the feature enabled and decodes blocks through it. The Core v24 block test compares against an X11 hash computed directly from the header bytes, so it fails when the feature is missing.
Moves every rust-dashcore pin from `a319c0a3` to `c9aeac0d`, which adds dashpay/rust-dashcore#1325, #1327, #1308 and #1202. - #1325: dash-spv announces every peer it drops when it stops, including its internal restart after a fork, and keeps delivering events to handlers until the network has stopped. Before, `PeerTracker` kept departed peers after a fork restart, so `SpvRuntime::is_broadcast_ready` could report peers while none were connected. - #1327: `PeersUpdated` lists the connected peers again and drops `connected_count`. `PeerTracker` goes back to storing the latest list, so a missed event cannot leave its copy wrong. The tests build the event with `addresses` and a plain `best_height`. - #1308 and #1202 need no change: Platform converts quorum types only through `LLMQType::from(u8)`.
xdustinface
force-pushed
the
chore/update-rust-dashcore-past-ffi-removal
branch
from
November 5, 2026 12:39
703d703 to
70abc13
Compare
xdustinface
marked this pull request as ready for review
November 5, 2026 12:40
Contributor
|
Your move: thepastaclaw left review threads unresolved; resolve them. |
github-actions
Bot
added
the
waiting-self-review
3 of 4 tasks
thepastaclaw
approved these changes
Nov 5, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
Static verification of the complete diff at 70abc13 and relevant pinned upstream implementations found no actionable in-scope defects; both prior blocking findings are fixed. Current CI reports successful Rust workspace, wasm32, Swift, Kotlin, Evo SDK, Docker image, functional, and Dashmate E2E checks, with no failed code checks; two Test Suite checks and PR Hygiene remain pending. No builds or tests were run locally.
🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: tenderdash-consensus-security); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 11: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 12: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 13: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 14: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 15: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 16: gpt-6.1-sol (agent: phase2-reviewer, role: tenderdash-consensus-security); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — Despite its breadth, the diff primarily adapts dependency APIs while preserving hash bytes and derived keys, with contained finality-error handling rather than an intricate change to critical behavior. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer,muse-spark-1.3-contributor— rust-quality (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— ffi-engineer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— platform-versioning (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— tenderdash-consensus-security (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— ffi-engineer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— platform-versioning (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— tenderdash-consensus-security (completed, effort high); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify the current code and confirm that no unresolved issues remain.
No unresolved findings remain from the prior review on this head.
Contributor
|
Your move: thepastaclaw left review threads unresolved; resolve them. |
Contributor
Author
|
/self-reviewed |
shumkov
approved these changes
Nov 6, 2026
Open
8 of 12 tasks
7 of 16 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
dashpay/rust-dashcore#776 deletes
key-wallet-ffiand theffifeature ofdash-network. Platform could only move its rust-dashcore pin past that once nothing linked them, which #5727 and #5728 took care of. This PR is that bump.It also clears the workarounds that #5726 (merged) could not drop at
7329126e, as the review on #5717 pointed out: dashpay/rust-dashcore#1224, dashpay/rust-dashcore#1250 and dashpay/rust-dashcore#1226 all landed after that commit, and this pin contains all three.What was done?
chore(platform)!: update rust-dashcore past the FFI removal: moves every rust-dashcore pin from7329126etoa319c0a3, the currentdevofdashpay/rust-dashcore, and the Base SDK to89828032. Adapted:Zeroizingbuffers and are borrowed, not copied.ConnectKey::AppEncryptionusesapplication_encryption_path(.., rotation)andAppEncryptionLegacyusesapplication_encryption_path_without_rotation, replacing the rotation level feat(platform-wallet): derive application encryption keys with the DIP-13 rotation level #5649 appended by hand. Derived keys and paths are byte-identical, andconnect_keypairs_match_the_pinned_vectorsstill passes.PeersUpdateddropped its address list at this pin, soPeerTrackerbuilds the connected set fromPeerConnectedandPeerDisconnected. The repin below restores the list.dash-params, bump Base SDK crates to dashpay/base-sdk@89828032 rust-dashcore#1223: devnet LLMQ size and threshold areu16, and larger values are refused.dash-spv'ssyncmodule is private, so imports use the public re-exports.dash-params, bump Base SDK crates to dashpay/base-sdk@89828032 rust-dashcore#1223: the Base SDK'sLlmqParamskeeps the DKG fields flat asu16, so the verified context provider and therefresh_checkpointsexample readdkg_intervaland widen both counts tou32, giving the same fetch window and depth.bitcoin_hashes1.x rust-dashcore#1320 (bitcoin_hashes1.x): hash newtypes no longer haveengineorfrom_engine. The ChainLock request id indrive-abciand the ProUpServTx payload hash inplatform-wallethash throughsha256d::Hashand wrap the result, which gives the same bytes.verify_request_idstill matches its fixed vector.bitcoin_hashes1.x rust-dashcore#1320: upstream hash types no longer index into bytes or havefrom_slice, so callers readas_byte_arrayand use the newtypes' ownfrom_sliceandall_zeros.bitcoin_hashes1.x rust-dashcore#1320: the newtypes' conversions are inherent functions, so theHashtrait imports that only served them go.rs-dapidropsdash-spv, whose only use was that import./name:version/form and the 256-byte bound to the user agent again, soplatform_wallet_manager_spv_startpasses the configured user agent through and Platform's ownnormalize_user_agentgoes.refactor(platform-wallet): use TxIn::claimed_p2pkh_address:decode_transactioncalls the P2PKH sender check rust-dashcore now has, instead of its own copy. The copy's script shape test goes too, because rust-dashcore'stest_claimed_p2pkh_addresscovers every case it had.fix(platform-wallet): type asset-lock funds awaiting finality: key-wallet now refuses an asset lock that only coins awaiting finality would fund, withBuilderError::FundsAwaitingFinality. It maps to a newPlatformWalletError::AssetLockFundsAwaitingFinalityinstead of the genericAssetLockTransactionstring. The FFI reports it as the existingErrorAssetLockInsufficientFunds(29), so iOS and Android behave as before.fix(platform-wallet): keep shielded finality wait on code 29: the shielded fund-from-asset-lock path reports the new variant as 29 too, instead ofErrorWalletOperation(6).build: drop the rust-bitcoin [patch.crates-io]: with build(hashes)!: move tobitcoin_hashes1.x rust-dashcore#1320,dashcore_hashestakesbitcoin_hashes1.x from the rust-bitcoin revbitcoin-cryptouses. The crates.iobitcoin-ioandbitcoin-consensus-encoding1.3.0 that tookbitcoin-internals0.7.0 from crates.io leave the graph, so no crates.io dependency asks for a version the git rev provides and the whole patch section goes.Cargo.lockis unchanged andcargo vendor --lockedsucceeds. Closes build: shrink the vendoring[patch.crates-io]on the next rust-dashcore bump #5648.fix(dapi): keep X11 block hashing without dash-spv:dash-spvwas the only thing inrs-dapi's own graph that enableddashcore'score-block-hash-use-x11. The Docker image buildsrs-dapialone, so without itblock_hash_from_block_byteshashed blocks with SHA256d.rs-dapinow depends ondashcorewith the feature and decodes blocks through it, and the Core v24 block test compares against an X11 hash computed straight from the header bytes, so it fails without the feature.build: repin rust-dashcore for the peer list events: moves the pins froma319c0a3toc9aeac0d, which adds fix(dash-spv): keep peer events consistent across stop rust-dashcore#1325, feat: Versioning #1327, chore(release): update changelog and bump version to 0.24.21 #1308 and chore(drive): downgrade grovedb to supported version #1202.PeerTrackerkept departed peers after a fork restart, soSpvRuntime::is_broadcast_readycould report peers while none were connected.PeersUpdatedrust-dashcore#1327:PeersUpdatedlists the connected peers again and dropsconnected_count.PeerTrackergoes back to storing the latest list, as it did before fix(dashmate): dashmate logic doesn't recognize it's ran from helper #902, so a missed event cannot leave its copy wrong.LLMQType::from(u8).These upstream changes needed nothing in Platform: dashpay/rust-dashcore#400 (SegWit and Taproot removed), dashpay/rust-dashcore#1288 (
bitcoin_unitsre-exports), dashpay/rust-dashcore#1289 (dependency maintenance), dashpay/rust-dashcore#1318 (bitcoinconsensusremoved), dashpay/rust-dashcore#1307 (partial merkle trees bounded by Dash's block size) and dashpay/rust-dashcore#1258 (masternode sync kept live on bad or missing diffs).Not in this PR: #5629's port and duplicate checks can switch to
ExtNetInfo::validate_ports_and_duplicates(dashpay/rust-dashcore#1226) only after the nextv5.0-devforward merge brings them tov5.1-dev.How Has This Been Tested?
Locally, all green:
cargo fmt --all -- --checkcargo clippy --workspace --all-features --all-targets -- -D warningscargo check --target wasm32-unknown-unknownforwasm-sdk,wasm-dpp,wasm-dpp2andrs-sdk-trusted-context-provider(lib and tests), and the transport-free feature cuts CI checkscargo macheteandcargo vendor --lockedcargo test --libforplatform-wallet,platform-wallet-ffi,platform-wallet-storage,rs-sdk-trusted-context-provideranddpp,platform-wallet-storage's integration tests, and thedrive-abcichain lock testsThe Swift and Kotlin SDKs and the full workspace test suite are left to CI.
Breaking Changes
Breaking for Rust consumers of rust-dashcore types, and for apps that used the Swift
KeyWalletclasses #5728 deleted. Consensus and persisted formats are unchanged, apart from upstream behaviour: an existing SPV store resyncs its masternode lists once, because dashpay/rust-dashcore#1227 changed the snapshot format, and the default user agent becomes/dash-spv:<version>/.Checklist:
structure.rs, regeneratedgrovedb-structure.json, and checked the structure viewer link posted on this pull requestFor repository code-owners and collaborators only
PR Hygiene ·
70abc13Cargo.lock,Cargo.toml,packages/rs-drive-proof-verifier/src/proof.rsand 14 more) — QuantumExplorer or shumkovrust-dapi(packages/rs-dapi/Cargo.toml,packages/rs-dapi/src/services/core_service.rs,packages/rs-dapi/src/services/streaming_service/block_header_stream.rsand 5 more) — QuantumExplorer or lklimek or shumkovdpp(packages/rs-dpp/src/address_funds/platform_address.rs,packages/rs-dpp/src/core_types/validator/mod.rs,packages/rs-dpp/src/core_types/validator/v0/mod.rsand 11 more) — QuantumExplorer or shumkovrs-drive-abci(packages/rs-drive-abci/src/abci/handler/prepare_proposal.rs,packages/rs-drive-abci/src/execution/platform_events/block_end/validator_set_update/v0/mod.rs,packages/rs-drive-abci/src/execution/platform_events/block_end/validator_set_update/v1/mod.rsand 40 more) — QuantumExplorer or shumkovrs-platform-wallet-ffi(packages/rs-platform-wallet-ffi/src/asset_lock/built_callback.rs,packages/rs-platform-wallet-ffi/src/asset_lock/sync.rs,packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rsand 21 more) — HashEngineering or ZocoLini or llbartekll or romchornyiwallet-storage(packages/rs-platform-wallet-storage/src/sqlite/provider_accounts.rs,packages/rs-platform-wallet-storage/src/sqlite/rehydrate.rs,packages/rs-platform-wallet-storage/src/sqlite/schema/asset_locks.rsand 26 more) — lklimekrs-platform-wallet(packages/rs-platform-wallet/examples/dpns_marketplace_testnet.rs,packages/rs-platform-wallet/src/changeset/changeset.rs,packages/rs-platform-wallet/src/changeset/core_bridge.rsand 42 more) — HashEngineering or ZocoLini or llbartekll or romchornyirust-sdk-ffi(packages/rs-sdk-ffi/src/mnemonic_resolver_core_signer.rs,packages/rs-sdk-ffi/src/signer_simple.rs,packages/rs-sdk-ffi/src/voting/masternode_vote.rs) — lklimek or shumkovrust-sdk(packages/rs-sdk/src/core/dash_core_client.rs,packages/rs-sdk/src/core/transaction.rs,packages/rs-sdk/src/error.rsand 10 more) — lklimek or shumkovjs-wasm-sdk(packages/wasm-sdk/src/queries/epoch.rs,packages/wasm-sdk/src/wallet/dip14.rs,packages/wasm-sdk/src/wallet/key_generation.rs) — shumkovWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.