feat(dash-spv): floor mainnet sync at HD/BIP39 activation height#877
Conversation
Floor mainnet sync at block 227121, the height from which HD/BIP39 wallets could first exist on chain. No address any HD wallet derives can appear before it, so syncing the pre-HD-wallet chain is wasted work. This matches the entry in DashSync's `mainnet_checkpoint_array` commented "first sync time (aka BIP39 creation time)", the value the official Dash mobile SPV client uses. Add `MAINNET_HD_ACTIVATION_HEIGHT` and a `NetworkExt::hd_wallet_sync_floor()` method to the `dash` crate, alongside `known_genesis_block_hash` where the other per-network chain constants live (mainnet returns the floor, other networks return `0`, meaning sync from genesis). When the caller sets no explicit `start_from_height`, `DashSpvClient::new` floors the wallet-derived birth height via `birth_height.max(config.network.hd_wallet_sync_floor())`, so a low or zero birth height can no longer drag mainnet sync back to genesis. Anchoring reuses the existing checkpoint machinery and snaps to the nearest checkpoint at or before the floor (the 200000 checkpoint), a safe undershoot that never skips a block that could hold an HD wallet transaction. An explicit `start_from_height` is still honored downward, and testnet/regtest/devnet are unaffected.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe network API now exposes an HD wallet synchronization floor, with a mainnet-specific activation height. ChangesWallet sync floor
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant DashSpvClient
participant Wallet
participant NetworkExt
DashSpvClient->>Wallet: earliest_required_height()
DashSpvClient->>NetworkExt: hd_wallet_sync_floor()
DashSpvClient->>DashSpvClient: Clamp start height and select checkpoint
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #877 +/- ##
==========================================
- Coverage 74.29% 74.28% -0.02%
==========================================
Files 325 325
Lines 73910 73923 +13
==========================================
+ Hits 54911 54913 +2
- Misses 18999 19010 +11
|
Floor mainnet sync at block 227121, the height from which HD/BIP39 wallets could first exist on chain. No address any HD wallet derives can appear before it, so syncing the pre-HD-wallet chain is wasted work. This matches the entry in DashSync's
mainnet_checkpoint_arraycommented "first sync time (aka BIP39 creation time)", the value the official Dash mobile SPV client uses.Add
MAINNET_HD_ACTIVATION_HEIGHTand aNetworkExt::hd_wallet_sync_floor()method to thedashcrate, alongsideknown_genesis_block_hashwhere the other per-network chain constants live (mainnet returns the floor, other networks return0, meaning sync from genesis). When the caller sets no explicitstart_from_height,DashSpvClient::newfloors the wallet-derived birth height viabirth_height.max(config.network.hd_wallet_sync_floor()), so a low or zero birth height can no longer drag mainnet sync back to genesis. Anchoring reuses the existing checkpoint machinery and snaps to the nearest checkpoint at or before the floor (the 200000 checkpoint), a safe undershoot that never skips a block that could hold an HD wallet transaction. An explicitstart_from_heightis still honored downward, and testnet/regtest/devnet are unaffected.Summary by CodeRabbit