Repository navigation
fix: same block core chain lock height - #979
Merged
Merged
Conversation
lklimek
reviewed
Apr 26, 2023
| // propose one | ||
| // This is done before all else | ||
|
|
||
| let core_chain_lock_update = match self.platform.core_rpc.get_best_chain_lock() { |
Contributor
There was a problem hiding this comment.
we should also check in ProcessProposal if received core chain lock height is valid
Member
Author
There was a problem hiding this comment.
Yeah there's a todo there already.
lklimek
approved these changes
Apr 26, 2023
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Aug 21, 2026
…68e652) Carries the wallet-scope born-spent attribution, the rescan reseed fix, and the repair-span bound into this branch's engine. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Aug 25, 2026
…th dev (a5d7ea0b) The dashpay#979 engine fixes and dashpay#974's coalesced committed-range sweeps now live on one rev: fix/key-wallet-rescan-changeset merged with dev, with the durable pending-sweep re-keyed to the coalesced model (manager-level swept-awaiting-commit receipt, resume-only seeding). Replaces the two superseded pins this branch carried (6768f983, 9a68e652). The rev also carries rust-dashcore dashpay#981 (Mnemonic::from_phrase is now the auto-detecting parse), so the three parse_mnemonic_any_language wordlist walks (wallet_lifecycle, rs-platform-wallet-ffi derivation + identity_keys_from_mnemonic, rs-sdk-ffi signer_simple) collapse to thin delegates and the language-tagged test call sites drop the argument. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Sep 4, 2026
…ile accessors over JNI The two reconcile-diagnostic reads Android lacked. coreWalletState wraps platform_wallet_core_wallet_state (syncedHeight / lastProcessedHeight / monitorRevision) — confirms a spvRescanFilters rewind actually took. accountSpentOutpoints wraps platform_wallet_account_spent_outpoints — the engine's spent-coin set per account, the dashpay#979 reconcile complement to the unspent UTXO page and the instrument for the rust-dashcore#992 burn race. Decoders pinned by CoreWalletStateTest.
4 of 6 tasks
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Sep 18, 2026
… + dashpay#1001) Same integration/979-on-v42pin-93260bf branch as before, now with dashpay/rust-dashcore#1001 (keep a spend-first coin recognisable so its spend stays in history) cherry-picked on top; the dashpay#649-skip conflict with dashpay#979's born-spent staging is resolved by keeping both.
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Sep 18, 2026
… + dashpay#1001 + rust-dashcore#1008) rust-dashcore#1008: dash-spv collects the scripts derived by every application of a block, not only the tracked delivery, so gap-widened addresses found by a re-applied block still reach the batch rescan and the committed-range sweep (dashpay/rust-dashcore#1006). Cherry-picked onto the fork pin branch with the one-line dashpay#979 conflict resolved by keeping the durable pending-sweep note for every delivery.
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Sep 18, 2026
… + dashpay#1001 + rust-dashcore#989) Swaps rust-dashcore#1008 for dashpay#989, which supersedes it (dashpay#1008 was closed as a subset). dashpay#989 fixes the same loss of scripts derived by a re-applied block (dashpay/rust-dashcore#1006) but routes them by height to the batch covering the block, falls back to the backward sweep when that range has committed, re-tests everything the wallet watches that a batch never matched before each commit, and withholds FiltersSyncComplete until the blocks it finds are applied. dashpay#979's durable pending-sweep note is kept, now taken on every delivery rather than only the tracked one.
HashEngineering
added a commit
to HashEngineering/platform
that referenced
this pull request
Sep 18, 2026
A persisted address pool has been observed arriving sparse (a 2026-08-19 field wallet was missing BIP44 change rows 875..=890 between surviving ones). Ingesting the sparse list as-is makes every output paying a missing address permanently unrecognizable — no rescan repairs it, because the row-derived `highest_generated` suppresses the gap-limit re-derivation that otherwise would. Derivation is pure key arithmetic, so re-derive every missing index up to the persisted watermark at load. The key source comes from the pool's own account (`accounts.account_of_type`), not from `key_source_for_account_type`. That helper routes through `extended_public_key_for_account_type`, which has no arm for either DashPay variant and so answers `NoKeySource` for both — skipping the repair on exactly the account type that needs it most. `DashpayReceivingFunds` is wallet-owned and funds-bearing, and its account already carries the xpub the missing addresses derive from; an unrepaired hole there makes a contact's payments to us invisible. The helper stays as the fallback for the types `account_of_type` deliberately does not return: the BLS provider operator account and the Ed25519 platform-node account. Never fatal: a failed repair restores exactly what the rows carried. Requires `AddressPool::ensure_contiguous_to` (rust-dashcore dashpay#979). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7 of 13 tasks
5 of 8 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
3 participants
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
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only