Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet missing TXs #872

Closed
4 tasks done
nodech opened this issue Nov 7, 2023 · 0 comments · Fixed by #883
Closed
4 tasks done

Wallet missing TXs #872

nodech opened this issue Nov 7, 2023 · 0 comments · Fixed by #883
Assignees
Milestone

Comments

@nodech
Copy link
Contributor

nodech commented Nov 7, 2023

A wallet, while syncing or rescanning, may miss transactions if it involves an address that is only discovered within the block. Upon discovering an output in the transaction, the wallet will derive additional receive/change addresses, which assists in determining whether the transaction belongs to it. This can occur within a single transaction when one output is derived at point X and another output in the same transaction is at X + lookahead. The lookahead is recalculated after the transaction has been added, which results in the wallet not recognizing outputs that it owns. Another scenario involves a different transaction with an X + lookahead derivation. In this case, there is an issue where the FullNode/SPVNode will not include those transactions in the list initially because the provided filter did not track them. In such instances, we need to request the block again with an updated filter.

This issue can also pertain to inputs, but it is not as critical. If we were unaware of the credit that the transaction was spending, it indicates we were not tracking it to begin with, so we are not losing sight of the money; we simply miss the credit that was already spent.

This situation would not normally occur, but it is possible if a user operates two different devices with the same master/account key. One wallet might fail to derive lookahead addresses without receiving funds on them, while another wallet remains unaware that the lookahead addresses have been generated.

Both scenarios have distinct requirements and solutions. For the first scenario, it is sufficient to remove the transaction from the database and reinsert it. This ensures that no outputs were previously overlooked. The second scenario requires cooperation from the blockchain when rescanning or adding a block (if the block connect event is also filtered). The node sends the block to the wallet; the wallet checks the list of transactions, and if the filter was updated, it updates the filter and requests the node to resend the same block.

Both scenarios require the block to be disconnected and reconnected until the filter remains unchanged. This could lead to extensive loops if a transaction were crafted specifically to exploit this behavior. However, the limit is set by deriving addresses to the necessary depth and the transaction limits within the block. In theory, 1,000 transactions with 100 outputs exploiting this behavior could lead to 100,000 disconnects and reconnects. This issue can be avoided by setting a limit for the wallet on how many times to rescan the same block.

Alternatively if the wallet knows that this issue has happened in the past, on import of the wallet user can derive addresses before running the rescan, but this needs a lot of caution not to cause the further gaps in the derivation.

There are still some cases that can't be recovered if the gap is big enough and only solution is to increase the lookahead.

On track PR/Issues

Related

@nodech nodech self-assigned this Nov 7, 2023
@nodech nodech added this to the hsd 7.0.0 milestone Nov 7, 2023
nodech added a commit to nodech/hsd that referenced this issue Feb 14, 2024
nodech added a commit to nodech/hsd that referenced this issue Feb 14, 2024
nodech added a commit to nodech/hsd that referenced this issue Feb 15, 2024
nodech added a commit to nodech/hsd that referenced this issue Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant