feat: persist hardware wallet activities

[jvsena42]

Description

This PR ports bitkit-android #1044 to iOS, making watch-only hardware wallet activity a full participant in bitkit-core's wallet-scoped storage. iOS already stored hardware activity under a derived wallet id, so this fills the gaps that were left behind:

1. Persists the Electrum transaction details the hardware watcher emits, so Explore shows inputs and outputs for a hardware transaction instead of an empty section.
2. Reconciles each watcher snapshot against what is already stored rather than only adding to it, so a reorged or replaced transaction stops showing. Transfer information the app wrote itself survives the reconcile, including a pending transfer the watcher has not seen yet.
3. Records a transfer to spending funded from a hardware wallet against that wallet, so it reads as a single hardware transfer rather than a main-wallet row shadowed by a hardware duplicate. The wallet is resolved before the device is asked to sign, so a transfer is never recorded against the wrong wallet.
4. Scopes the remaining activity operations to the wallet that owns the activity: seen state, deletion, contacts, and boost relationships. Marking everything as seen and clearing all activity previously skipped hardware wallets entirely.
5. Enables tags and contacts on hardware activities, which were hidden behind an interim gate while those operations were unscoped. Boost stays unavailable, since a watch-only wallet has no signing keys.
6. Tells the user when transaction details are unavailable instead of quietly hiding the section.

Scoping point 4's boost relationships per wallet turned ActivityService's boostTxIds cache from a single Set<String> into a [String: Set<String>], which introduced a data race that crashed the app during manual testing (EXC_BAD_ACCESS in Dictionary._Variant.lookup, reached from ActivityListViewModel.filterOutReplacedSentTransactions). Readers run on whichever executor calls getTxIdsInBoostTxIds, while writers run on MainActor and the core queue, so an in-place keyed write could resize the storage mid-lookup — where the previous whole-value Set assignment was a single store and never tore. The cache is now behind an OSAllocatedUnfairLock. A lock rather than an actor because updateBoostTxIdsCache is called from inside the synchronous ServiceQueue.background(.core) blocks, which must stay non-async for the reason documented on replaceHwSnapshot; making it async would either lose that serialization or decouple the cache update from the write it belongs to. Dropping the two await MainActor.run hops also takes a main-thread round trip off the watcher poll path.

The PR also moves bitkit-core from 0.4.2 to 0.5.3. Version 0.4.2 was cut from a branch that never merged upstream, and its only unique symbol was the extended-public-key serializer used when claiming a watch-only account. That single dependency pinned the repo to a dead-end tag and blocked every upgrade, so this decodes the key locally instead, matching the approach in #632. Everything the hardware wallet integration relies on is unchanged between the two versions.

Linked Issues/Tasks

• Android counterpart: feat: persist hardware activities bitkit-android#1044
• Overlaps with feat: add boltz savings swap #632, which makes the same bitkit-core bump and the same extended-public-key workaround. Whichever lands second should rebase rather than resolve by hand.
• Follow-up ActivityService: concurrent cold reads of the boostTxIds cache each run their own full rebuild #650 — concurrent cold reads of the boostTxIds cache each run their own full rebuild. Pre-existing pattern, made cheaper by this PR (the nil check now caches an empty set, where master's .isEmpty check re-scanned on every call); left out of scope because after the lock it is wasted work rather than a correctness problem.
• Follow-up ServiceQueue: the async overload silently defeats the serialization its callers assume #649 — ServiceQueue's async overload silently defeats the serialization its callers assume. Surfaced while reviewing this PR and worked around here in replaceHwSnapshot; the general fix touches ~40 call sites and was kept out.

Screenshot / Video

receive-two-transactions.mov

tag-filter.mov

transfer-from-savings.mov

tags.mov

transfer-details.mov

recover-hw-transfer.mov

server-accounts.mov

QA Notes

Manual Tests

• 1. Settings → Advanced → Dev Settings → Trezor → pair the Bridge emulator: Home shows the hardware wallet tile with its balance and blue activity rows.
• 2. Fund two hardware addresses with different amounts → mine a block → Home → Show All: both blue received rows appear exactly once.
• 3a. Blue hardware receive → Activity Item → Tag: the tag button is available and adding a tag succeeds.
  • 3b. back → reopen the same activity: the tag is still there.
  • 3c. Activity Item → Explore: Inputs and Outputs are populated instead of empty.
• 4. All Activity → tag filter → select the hardware tag: the tagged blue row remains and untagged rows are gone.
• 5a. Hardware Wallet → Transfer To Spending → 25% → Continue → approve on device → Continue Using Bitkit: Home shows exactly one new blue Transfer / From Savings row, not a main-wallet row plus a hardware duplicate.
  • 5b. Tap that row → Activity Item: shows "From savings".
  • 5c. Wait for the next watcher poll: the row keeps its transfer styling and does not revert to a plain send.
• 6. All Activity → switch Sent, Received, Other, All: hardware receives appear under Received, the hardware transfer under Other, and All shows the combined list with no duplicate.
• 7a. Settings → Hardware Wallets Settings → remove the paired device: its activity disappears from Home and All Activity.
  • 7b. Re-pair the same wallet: its activity rebuilds without duplicate rows.
  • 7c. Do a hardware transfer to spending, wait for the channel to become usable, remove the device, re-pair it → the rediscovered funding tx reads as a transfer, not a plain send.
• 8. regression: App on-chain and LN activity → Activity Item, tags, contacts, Explore, Savings and Spending lists, boost: behaviour matches master.
• 9. regression: Settings → Advanced → Server accounts → set up an account against Pubky Ring: the claim is still accepted after the local key decoding change.

Automated Checks

• Unit tests added: BitkitTests/HwSnapshotMergeTests.swift covers the snapshot reconciliation rules — a stored row missing from a snapshot is dropped, a transfer is not, and transfer metadata is carried forward and matched by transaction id rather than activity id.
• Unit tests added: BitkitTests/WatchOnlyAccountServiceTests.swift pins the local extended-public-key decoding against bitkit-core's own test vectors, plus invalid character, bad checksum, off-curve key, and wrong-length rejection.
• Unit tests added: BitkitTests/HwWalletManagerTests.swift covers transaction details reaching persistence scoped to the derived wallet id, details deduped across two address-type watchers, an unconfirmed transaction whose timestamp drifts between polls not re-writing to core, and wallet id resolution for a device.
• Unit tests added: BitkitTests/TransferViewModelHwTests.swift covers an unresolvable wallet id aborting before the device signs or anything is broadcast.
• Unit tests added: BitkitTests/ActivityListTest.swift gains testConcurrentBoostCacheAccessIsSafe, hammering the boostTxIds cache with concurrent reads across 8 seeded and 64 cold wallet ids against upserting writers. Cold reads are what insert new keys and force the dictionary to resize, which is the window that crashed. It only catches the bug under Thread Sanitizer — on the unfixed code it passed 3/3 plain runs, and TSan names the exact site (Swift access race … in ActivityService.refreshBoostTxIdsCache). Verified in both directions: unfixed + TSan fails, fixed + TSan passes. Worth deciding whether CI should gain a TSan job, since without one this is a deadlock smoke test rather than a race guard.
• Unit tests modified: BitkitTests/HwWalletManagerTests.swift and BitkitTests/HwWalletManagerFundingTests.swift record wallet-scoped snapshots instead of bare activity lists; BitkitTests/HwTransferMocks.swift gains wallet id resolution.
• Test coverage removed: the hardware-duplicate collapsing test in BitkitTests/ActivityHardwareTests.swift is gone because the funding transaction is now stored only under the hardware wallet, so there is no duplicate to collapse. It is replaced by a case proving the same transaction id in two wallet scopes stays two distinct activities.
• Local run: 654 tests across the 60 offline unit suites passed on the iPhone 16 simulator. UtxoSelectionTests and DustChangeHelperTests pass on their own but hit the live Blocktank regtest deposit endpoint and flaked once with a 404 during a long run.
• Not run locally: AddressTypeIntegrationTests, BlocktankTests, LdkMigration, ChannelPurchaseFlow, and BroadcastConnectivityTests need a live node and hang without the regtest stack. The manual tests above were also not run — they need a Trezor Bridge emulator, so the hardware journeys rest on review and QA.
• Local run: SwiftFormat lint passed for all changed Swift files, and node scripts/validate-translations.js reported no errors.
• Local product QA (2026-08-03/04, iPhone 17 sim + Bridge emulator): manual checklist items 1–8 verified. Item 9 (Pubky Ring watch-only claim) not run. Offline unit suite: 698 BitkitTests passed (skipped live/hang-prone suites matching CI + DustChangeHelperTests).
• After the boostTxIds lock fix (2026-08-04): build succeeded for the app plus the notification and widget extension targets, which share CoreService.swift; 99 tests passed across the six affected suites (ActivityTests, ActivityHardwareTests, HwSnapshotMergeTests, HwWalletManagerTests, HwWalletManagerFundingTests, TransferViewModelHwTests); SwiftFormat lint clean. The full offline suite has not been re-run since that change, so the 654/698 figures above still describe the earlier runs.
• CI: standard build and test checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR promotes hardware-wallet activity to wallet-scoped persisted storage and preserves transaction details and transfer metadata during watcher reconciliation.

• Reconciles complete hardware-wallet snapshots while deferring destructive pruning for partial snapshots.
• Scopes activity mutations, contacts, tags, seen state, and boost relationships by wallet.
• Records hardware-funded transfers against the originating hardware wallet.
• Adds synchronization around the wallet-scoped boost transaction cache.
• Replaces the bitkit-core extended-public-key serializer with local validated decoding and upgrades bitkit-core.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported failed-snapshot deduplication issue is addressed by conditionally invalidating the cached snapshot after a write failure, allowing the next identical watcher snapshot to retry.

Important Files Changed

Filename	Overview
Bitkit/Managers/HwWalletManager.swift	Aggregates watcher snapshots, serializes wallet-scoped persistence and deletion, and now invalidates snapshot deduplication state after failed writes.
Bitkit/Services/HwSnapshotMerge.swift	Reconciles watcher snapshots with stored activity while preserving transfer metadata and deferring deletion for incomplete snapshots.
Bitkit/Services/CoreService.swift	Adds wallet-scoped activity operations and synchronized wallet-specific boost transaction caches.
Bitkit/ViewModels/TransferViewModel.swift	Resolves the hardware wallet scope before signing and records the resulting transfer in that scope.
Bitkit/Services/WatchOnlyAccountService.swift	Replaces the removed core serializer dependency with locally validated extended-public-key decoding.
BitkitTests/HwWalletManagerTests.swift	Covers wallet-scoped snapshot persistence, transaction-detail deduplication, and retrying an identical snapshot after a transient persistence failure.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    W[Hardware wallet watchers] --> M[Merge address-type snapshots]
    M --> C{Snapshot complete?}
    C -->|No| U[Upsert without pruning]
    C -->|Yes| R[Reconcile and prune missing rows]
    U --> S[Wallet-scoped core storage]
    R --> S
    S --> A[Combined activity views]
    T[Transfer to spending] --> I[Resolve hardware wallet ID before signing]
    I --> S

Loading

_{Reviews (4): Last reviewed commit: "feat: enable asign HW transactions to a ..." | Re-trigger Greptile}

Replacing approve with utAck comment — PR was not fully device-tested.

[jvsena42]

Description updated with test videos and some findings, specially test case 7c. I also opened issues for findings out of the scope of this PR. Waiting for AI review before re-requesting human review

[jvsena42]

draft for solve conflicts

Dismissing approval — PR has merge conflicts and is still draft.

[ovitrif]

Assigning a contact to a hardware activity still leaves that transaction out of the contact Activity screen, because get(contact:) only queries the default wallet scope.

[ovitrif]

Thanks for addressing the contact Activity gap. Hardware assignments now reach contact history across wallet scopes, and this looks good to merge.