search

synonymdev / bitkit

Self-custodial Bitcoin and Lightning Wallet for Android and iOS.
https://bitkit.to
MIT License
109 stars 22 forks source link

[Bug]: Restored wallet splits Boosted CPFP transactions into separate activities #1844

Open catch-21 opened 1 month ago

catch-21 commented 1 month ago

Describe the bug

When boosting a transaction, the existing activity is updated to reflect the change and combines the subtracted amounts. If the wallet is restored the transactions are displayed as separate activities. We should aim to keep the activity list constant after wallet restore.

Reproduce

  1. Send onchain funds using a fee rate that needs a boost
  2. Boost the transaction
  3. Observe the two transactions are combined in one activity
  4. Restore the wallet
  5. Observe the two transactions each now have their own activity

Screenshots / Recording

In the following example, the final transaction in the CPFP chain is d69eeb99e9a562e7b9a6a34abce3c77808e4e0f8a077058ee1558881ae209a2b

Before restore, two activities are shown for a chain of three transactions. The top one had a boost and so combines two CPFP transactions and the bottom is a single transaction:

Screenshot 2024-05-17 at 15 59 17

After restore there are three activities, one for each transaction in the CPFP chain:

Screenshot 2024-05-17 at 15 59 17

Operating system

Android 13 TKQ1.221114.001

Bitkit version

4980b42f4382c93137996ed30d7b68658a000786

Log output

No response

JeanlChristophe commented 1 month ago

@catch-21 It's what's on the current version of Figma, right?

catch-21 commented 1 month ago

I assume Figma is correct, in that multiple transactions are to always be grouped into a single activity.

coreyphillips commented 1 month ago

It's about intention. Bitkit loses that intent when we restore because it doesn't back up which transactions were boosted vs transactions that were sent-to-self. They are effectively the same thing, we just bundle boosted transactions together.

Potential solution. If we wanted to retain that intent and have boosted transactions bundled together on restore we would have to add boosted transactions to our backup flow and adjust the activity list UI accordingly during restore.

Personally, I'm against using backups for anything that is non-critical or UI-related as it adds a lot of complexity and increases the calls we need to make when reading/writing from backups. Therefore, I would argue that keeping the way it currently restores is an acceptable fallback instead of additional complexity.