fix(key-wallet): stop counting a contact's watch-only coins as the wallet's - #926
Merged
Merged
Conversation
…llet's
`all_funding_accounts` included `dashpay_external_accounts`. A DashPay
external account is watch-only by construction — its addresses derive
from a *contact's* xpub, so this wallet can observe those outputs but can
never sign for them. They are the contact's coins, and this wallet only
ever pays into them.
Counting them as funding had two visible consequences.
The wallet balance did not move after paying a contact: the amount left
the standard account and reappeared under the external one, because the
payment output landed there. Observed on device — after sending 0.01
DASH, `account_balances=[Standard{idx:0,BIP44}=>0.99587131 DASH,
DashpayExternal{idx:0}=>0.01 DASH]`, with the external account climbing
across successive payments (0.111 → 0.461 → 0.511). To a user this reads
as "my balance is wrong", or worse, "the send did not happen".
And `utxos()` fed `get_spendable_utxos()`, so coin selection could pick
an output the wallet cannot sign for, failing at signing time with funds
apparently available.
Receival accounts stay: those addresses derive from our own xpub and a
contact pays into them, so the funds are genuinely ours.
This does not stop the wallet seeing those transactions. Detection runs
through `transaction_checking`, whose `AccountTypeToCheck` list still
includes `DashpayExternalAccount`, and the monitored-address /
compact-filter set is built from `all_accounts`, which also still
includes it. Only balance and UTXO aggregation change.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe funding-account iterators now exclude DashPay external accounts. They continue to include standard and DashPay receival accounts. Tests verify both iterator variants and confirm that external accounts remain stored. ChangesFunding account scope
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #926 +/- ##
==========================================
+ Coverage 74.95% 75.04% +0.09%
==========================================
Files 328 328
Lines 76884 76933 +49
==========================================
+ Hits 57626 57738 +112
+ Misses 19258 19195 -63
|
QuantumExplorer
approved these changes
Aug 7, 2026
bfoss765
added a commit
to bfoss765/platform
that referenced
this pull request
Aug 9, 2026
… the persisted transaction row dashpay/rust-dashcore#926 established that a `DashpayExternalAccount` is watch-only by construction — its addresses derive from a contact's xpub, so they are the contact's coins and this wallet only ever pays into them — and removed those accounts from `all_funding_accounts` so they stop counting toward balance and UTXO aggregation. The persistence seam is the same rule's second home, and it was missed. Upstream `check_core_transaction` emits one `TransactionRecord` per matched account, so a payment to a contact produces two records sharing one txid: the funding account's (`Outgoing`, `net = change - spent`) and the external account's (`Incoming`, `net = +paid`). `build_core_changeset` projected both into `CoreChangeSet.records`, and `derive_new_utxos` turned the contact's output into a wallet UTXO. Because the persisted `transactions` row is keyed by txid alone — the `transaction_account_involvements` table is only written for provider-key accounts, so there is no per-account dimension to disambiguate — the watch-only record defined the stored row. Field capture on testnet: a 0.69998912 DASH payment away was persisted as `direction=incoming`, `netAmount=+69998912` instead of `-70000000`, and the paid output sat in `txos` with `isSpent=0` indefinitely, inflating any SQL-sum balance. Records owned by an external account are now excluded from the persist-time projection: no transaction row, no new TXO. The funding account's record — already correct — becomes the row that lands. Everything genuinely ours from the same event is preserved: address-used flips and highest-used watermarks (so contact address rotation keeps working), derived-address rows, and `derive_spent_utxos`, which stays unfiltered so a contact spending an output persisted by a pre-fix build still clears the stale row. Eight regression tests cover the record pair a real contact payment produces, the standalone first-sighting path, the confirmation re-emit, a genuine receive, a DashPay *receival* account receive (the boundary dashpay#926 drew, which must stay incoming/positive), and an internal transfer. The four fix-dependent ones were verified to fail without the change.
QuantumExplorer
added a commit
that referenced
this pull request
Aug 11, 2026
…es (#952) A DashpayExternalAccount derives its addresses from the contact's xpub, so its coins are the contact's, never this wallet's. That policy now has two enforcement sites — balance/UTXO aggregation dropped the accounts from all_funding_accounts (#926), and dashpay/platform#4363 filters the same records out of its persistence projection — but each site hardcodes its own account-type list, which can silently drift when a new contact-owned account type is added. Give the policy one canonical home: AccountType::is_contact_owned(), with an exhaustive match so a new account type cannot compile without deciding whether its coins are the wallet's or a contact's, plus a delegating ManagedAccountType::is_contact_owned(). The #926 funding- scope test now asserts all_funding_accounts agrees with the predicate. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
QuantumExplorer
pushed a commit
to dashpay/platform
that referenced
this pull request
Aug 11, 2026
… the persisted transaction row dashpay/rust-dashcore#926 established that a `DashpayExternalAccount` is watch-only by construction — its addresses derive from a contact's xpub, so they are the contact's coins and this wallet only ever pays into them — and removed those accounts from `all_funding_accounts` so they stop counting toward balance and UTXO aggregation. The persistence seam is the same rule's second home, and it was missed. Upstream `check_core_transaction` emits one `TransactionRecord` per matched account, so a payment to a contact produces two records sharing one txid: the funding account's (`Outgoing`, `net = change - spent`) and the external account's (`Incoming`, `net = +paid`). `build_core_changeset` projected both into `CoreChangeSet.records`, and `derive_new_utxos` turned the contact's output into a wallet UTXO. Because the persisted `transactions` row is keyed by txid alone — the `transaction_account_involvements` table is only written for provider-key accounts, so there is no per-account dimension to disambiguate — the watch-only record defined the stored row. Field capture on testnet: a 0.69998912 DASH payment away was persisted as `direction=incoming`, `netAmount=+69998912` instead of `-70000000`, and the paid output sat in `txos` with `isSpent=0` indefinitely, inflating any SQL-sum balance. Records owned by an external account are now excluded from the persist-time projection: no transaction row, no new TXO. The funding account's record — already correct — becomes the row that lands. Everything genuinely ours from the same event is preserved: address-used flips and highest-used watermarks (so contact address rotation keeps working), derived-address rows, and `derive_spent_utxos`, which stays unfiltered so a contact spending an output persisted by a pre-fix build still clears the stale row. Eight regression tests cover the record pair a real contact payment produces, the standalone first-sighting path, the confirmation re-emit, a genuine receive, a DashPay *receival* account receive (the boundary #926 drew, which must stay incoming/positive), and an internal transfer. The four fix-dependent ones were verified to fail without the change.
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.
Problem
ManagedAccountCollection::all_funding_accountsincludesdashpay_external_accounts.A DashPay external account is watch-only by construction — the crate's own doc comment on the variant says so (
managed_account_type.rs: "DashPay external (watch-only) account"). Its addresses derive from a contact's xpub, so this wallet can observe those outputs but can never sign for them. They are the contact's coins; this wallet only ever pays into them.Treating them as funding has two visible consequences.
The balance does not move after paying a contact. The amount leaves the standard account and reappears under the external one, because the payment output landed there. Observed on an iOS device after sending 0.01 DASH to a contact:
The external account climbs across successive payments (0.111 → 0.461 → 0.511 in one session). To a user this reads as "my balance is wrong", or worse, "the send did not happen".
Unspendable outputs reach coin selection.
utxos()feedsget_spendable_utxos(), so selection can pick an output the wallet has no key for and fail at signing time with funds apparently available.What changed
dashpay_external_accountsis dropped fromall_funding_accountsandall_funding_accounts_mut. That covers every consumer at once —account_balances,balance/update_balance,utxos,get_spendable_utxos,immature_transactions,matured_coinbase_records.dashpay_receival_accountsstays: those addresses derive from our xpub and a contact pays into them, so the funds are genuinely ours.The doc comment now states the exclusion and the reason, so the line does not get "fixed" back.
What deliberately did not change
The wallet still sees these transactions.
transaction_checking, whoseAccountTypeToChecklist still includesDashpayExternalAccount(transaction_router/mod.rs,account_checker.rs), so a send to a contact is still routed and recorded.all_accounts, notall_funding_accounts, and still includes the external account.all_accounts/all_accounts_mutare untouched, so chain-lock promotion, transaction history and instant-lock marking keep working per-account.Only balance and UTXO aggregation change.
Alternatives considered
update_balance/get_spendable_utxosonly — strictly worse:account_balances()and rawutxos()would keep reporting the contact's coins as the wallet's, i.e. the same bug on a different surface.is_watch_onlyexists on the immutableAccountbut not onManagedCoreFundsAccount; the fact is already encoded in the account type, which is what the aggregation matches on anyway.Testing
cargo test -p key-wallet— 604 passed, 0 failed. No existing test encoded the old behaviour.New regression test
external_dashpay_accounts_are_not_funding_accountsbuilds a collection with a standard, a receival and an external account and asserts the external one is absent from the funding view while the receival one is present, that the mutable view visits the same set, and that the account itself still exists in the collection. Verified to fail without the fix ("the contact's watch-only account must not count as this wallet's funds").cargo clippy -p key-wallet --all-features --all-targets -- -D warningsandcargo fmt --checkare clean.Summary by CodeRabbit