fix(key-wallet): stop pruning spent CoinJoin addresses from the filter scan

[ZocoLini]

#949 dropped a CoinJoin address from the forward compact-filter query once it was used and held no unspent output, on the grounds that CoinJoin addresses are single-use by protocol, so nothing would ever pay one again.

Mainnet does not honour that. On a restore of a mixing-heavy wallet, 287 CoinJoin addresses were paid by more than one transaction — verified on the scriptPubKey, not on a derivation label — some of them nearly 100 000 blocks after being emptied. Eight of those fell in a window where the wallet had already stopped watching them, and the scan never saw the payments:

9 transactions missed between heights 2 170 285 and 2 170 440
5 outputs never recorded (80 000 sat)
9 spends never recorded (176 780 sat)
4 already-spent outputs left on the books as spendable
balance overstated by 96 780 sat

Reproduced identically across four full syncs and by two independent methods (an A/B diff of per-address dumps, and an end-of-sync re-match of the whole chain against still-unspent scripts, which named the same heights and the same addresses without being told what to look for).

The saving did not pay for that. Pruning shrinks the query sixfold at the tip (13 378 to 2 200 scripts), but over a full mainnet restore it moves the sync by 7.7% in blocks and 2.3% in time — inside the run-to-run spread, with the fastest of the four runs being an unpruned one.

ManagedWalletInfo therefore no longer overrides scan_script_pubkeys, so the scan query is the monitored set again. The plumbing stays: a narrower query is still worth having if someone can show which scripts are genuinely unpayable. ManagedCoreFundsAccount::unspent_or_unused_script_pubkeys also stays, now documented as a description of the single-use discipline rather than as something safe to scan from, and the benchmark keeps measuring the two query shapes against each other so the prize stays visible.

The regression test walks the whole shape: pay a CoinJoin address, spend the output, then build a real BIP158 filter over the block carrying a second payment to it and require the scan query to match. It fails on the pruned query.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.19%. Comparing base (237f79a) to head (ec214ba).

Additional details and impacted files

@@ Coverage Diff @@## dev #985 +/- ##
==========================================
+ Coverage 77.14% 77.19% +0.05% 
==========================================
Files 329 329 Lines 82998 83056 +58 ==========================================
+ Hits 64026 64117 +91 + Misses 18972 18939 -33 

Flag	Coverage Δ
core	78.25% <ø> (ø)
ffi	52.40% <ø> (ø)
rpc	20.00% <ø> (ø)
spv	92.14% <ø> (+0.14%)	⬆️
wallet	79.28% <100.00%> (+0.06%)	⬆️

Files with missing lines	Coverage Δ
dash-spv/src/sync/filters/manager.rs	97.91% <ø> (ø)
key-wallet-manager/src/process_block.rs	93.33% <100.00%> (+1.02%)	⬆️
key-wallet-manager/src/wallet_interface.rs	9.37% <ø> (ø)
.../src/managed_account/managed_core_funds_account.rs	87.77% <ø> (ø)
...allet/managed_wallet_info/wallet_info_interface.rs	80.70% <ø> (+0.23%)	⬆️

... and 4 files with indirect coverage changes