Open
Conversation
- Move insufficient funds check from create_and_send_cpfp_tx to can_speedup - Centralize all speedup validation logic in can_speedup function - Add warnings and notifications for insufficient funds and missing funding - Replace all self.store.can_speedup() calls with self.can_speedup() - Remove duplicate validation logic from dispatch_transactions and process_active_speedups - Simplify perform_speedup to use can_speedup directly - Remove notify_funding_not_found helper method (inline in can_speedup)
This commit implements a major refactoring of the speedup transaction dispatch
mechanism, changing from immediate dispatch to a deferred queuing system that
preserves ordering and improves error handling.
Key changes:
1. Deferred Speedup Dispatch:
- Speedups are now created and marked as ToDispatch instead of being sent
immediately
- Dispatch happens in the next tick, preserving ordering guarantees
- This ensures speedups are dispatched sequentially, maintaining funding chain
dependencies
2. Transaction Storage in Speedup:
- Added tx: Option<Transaction> field to CoordinatedSpeedUpTransaction
- Speedup transactions are now stored with their speedup data
- Funding transactions use None (no transaction needed)
3. Method Refactoring:
- Renamed create_and_send_cpfp_tx -> create_cpfp_tx (creates and queues)
- Split dispatch_speedup into:
* dispatch_speedup: Marks speedup for dispatch (monitor + save)
* dispatch_speedup_tx: Actually sends transaction to network
- Renamed should_boost_speedup -> should_boost_last_speedup
4. Enhanced Error Handling:
- dispatch_speedup_tx validates transaction exists and tx_id matches
- Retryable errors (MempoolRejection/NetworkError) keep ToDispatch state
- Fatal errors mark speedup as Failed
- Proper state updates after successful dispatch (InMempool)
5. Improved Tick Flow:
- Process speedups first, then transactions, then boost operations
- This ensures speedups created in a tick are dispatched in the next tick
- Prevents same-tick dispatch and maintains ordering
6. Validation Improvements:
- can_speedup now checks unconfirmed transactions first
- Better separation of concerns in validation logic
- should_boost_last_speedup checks ToDispatch state before attempting boost
7. Context Handling:
- Speedup transactions now use their own context (CPFP/RBF/FUNDING)
- News filtering updated to exclude speedup-related contexts
This refactoring improves reliability by ensuring speedups are dispatched in
the correct order, handles errors more gracefully, and provides better
separation between creation and dispatch phases.
Adjust test timing to accommodate the new deferred speedup dispatch system where speedups are queued and dispatched in subsequent ticks. Changes: - reorg_test: Increase mine/tick iterations from 4 to 8 to allow sufficient time for speedup transactions to be dispatched and confirmed - speedup_chain_recompute_fee_test: Replace single mine/tick with loop of 4 iterations to ensure proper sequencing of speedup dispatch - utils/mod: Remove unused import (SubscriberInitExt)
- Export TransactionBlockchainStatus from bitvmx-transaction-monitor - Add From<TransactionBlockchainStatus> for TransactionState implementation - Remove TransactionStatusExt trait in favor of direct From impl - Update coordinator to use direct status mapping via .into() - Map NotFound status to ToDispatch instead of Failed - Simplify AlreadyKnown error handling in dispatch_txs
…status to seach in mempool.
…broadcast state. If a transaction was not broadcast, there is no need to search for it in the mempool.
Introduce allow_search_in_mempool to register a transaction with the monitor with mempool search enabled, and replace the five inline monitor.monitor(..., true) call sites with this helper.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
This PR makes speedup transaction handling in BitcoinCoordinator crash-safe and consistent. Previously, dispatch_speedup could broadcast a CPFP/RBF transaction before persisting its metadata, so a crash in between would leave the coordinator unaware of already-sent speedups and risk reusing the same funding UTXO.
Changes
Centralize can_speedup validation and notifications to ensure consistent checks before any speedup.
Refactor speedup dispatch to a deferred queuing system, persisting intent and state before broadcasting to the Bitcoin network so the coordinator can safely recover after crashes.
Simplify transaction state management by mapping TransactionBlockchainStatus directly to TransactionState and adding transaction filtering/batching with improved mempool status querying.
Update and extend tests to cover dispatch flow, new state mapping, and recovery behavior.