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

feat: unconfirmed balance. #184

Open
dan-da opened this issue Sep 13, 2024 · 0 comments
Open

feat: unconfirmed balance. #184

dan-da opened this issue Sep 13, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@dan-da
Copy link
Collaborator

dan-da commented Sep 13, 2024

Presently if one calls RPCs: synced_balance(), send() and then synced_balance() again, one might expect the balance to change but it doesn't.

The reason is that the send RPC only inserts the Tx in the mempool. It does not modify any MonitoredUtxo. MonitoredUtxo only reflect changes in confirmed blocks. As such, user would not see any change in their wallet balance after send(). neither synced balance nor unsynced balance.

I think what should be happening is that once a Tx is inserted into the mempool the wallet should be notified to keep track of any Utxos that came from it or go back to it.

I think the logical way to do this is for the wallet to keep a list of mempool_utxos which always contains the set of utxo presently in the mempool which came from or are destined for our wallet. Calculating unconfirmed balance then becomes:

self.monitored_utxos
 .iter()
 .filter_map(|u| if u.is_not_spent() { Some(u.native_coins()) else {None}  ))
 .chain(self.mempool_utxos)
 .filter_map(|u| if u.is_not_spent() { Some(u.native_coins()) else {None}  ))

the wallet would likely need to listen to mempool events in order to keep these lists fully in sync with mempool as utxos get expired, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant