unconfirmed tx chaining. spend unconfirmed utxos. #197
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wallet subscribes to mempool via tokio broadcast to track owned utxos. Changes: * add spent_utxos, unspent_utxos lists to WalletState struct * add WalletState::handle_mempool_event() * add test confirmed_and_unconfirmed_balance() * add Mempool::event_channel (tokio broadcast channel) * Mempool faillible mutation methods return Result() * Mempool mutable methods broadcast MempoolEvent * add tests::shared::mine_block_to_wallet() * lib.rs: spawn wallet task for listening to mempool events and dispatch to WalletState for handling. * add locks::tokio::AtomicRw::try_lock_guard_mut()
removes the mempool broadcast channel and wallet listener task.
Instead all mempool mutations go through GlobalState methods
which inform wallet of the changes. This makes changes atomic
over mempool+wallet so they are always in sync.
Changes:
* remove Mempool::event_channel
* Mempool &mut methods only callable by super
* Mempool &mut methods return MempoolEvent(s)
* add MempoolEvent::UpdateTxMutatorSet. (unused)
* add GlobalState methods: mempool_clear, mempool_insert,
mempool_prune_stale_transactions
* remove spawn_wallet_task from lib.rs
* add/improve doc-comments
This was referenced Oct 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #189
Extends #184. ( diff )
This PR implements chaining of unconfirmed transactions.
Or at least it appears to. I've been told this is not feasible without triton-vm programs.
So maybe it only appears to work, but is not fully correct. That's for reviewers to decide, and tell me how the approach is wrong. Or maybe it is only cut-through that requires tricky triton-vm stuff, and this PR doesn't attempt cut-through.
Primarily for this reason, I am making this a draft PR. Another reason is that this PR does not (yet?) attempt to handle (or test) the case where unconfirmed tx B depends on A, and B has a higher fee, so it gets confirmed in a block and A does not. I'm not certain what the code will do... undefined behavior.
The approach taken here is a natural extension of the changes in #184. Namely the wallet-state keeps track of all wallet-affecting utxos in the mempool. It considers them for balance calculations, for selecting inputs, when scanning for spent-inputs, and when updating wallet state with a new block.
The PR includes a test case, spend_unconfirmed_tx() in wallet_state.rs. The test case starts with a single input utxo then sends Tx A worth 5, then tx B worth 10 in the same block (B depends on A) and verifies balances, then mines another block and verifies balances. In detail:
steps 5 and 6 were the trickiest as it required some changes to WalletState::update_wallet_state_with_new_block() which is a complex method.
There may be better way(s) to represent the unconfirmed utxos in WalletStatus for more efficient balance calcs.
But for now, I don't want to put further effort into improving unless/until the concept/direction is approved by reviewers.
My thought is that this approach may not be the best/ideal way to achieve this functionality, but if not fatally incorrect then it may be worth having as a stop-gap for now, until a better approach can be implemented.