-
Notifications
You must be signed in to change notification settings - Fork 307
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
Better tests for transaction conflict handling. #1063
Comments
@LagginTimes is currently still working on this. |
Why would you look at the input sequence? Are you trying to understand which tx got broadcasted first, and assuming that people are signing with fee sniping protections? |
Describe the enhancement
This continues on the work suggested in ticket #985 and implemented in #964.
However, I realized that it is tedious to construct
TxGraph
histories, making it difficult to test multiple scenarios without an overwhelming amount of code. I suggested aTxTemplate
structure in #964 (comment):Alongside this, we need a
Scenario
structure to describe the specific scenario we are testing, and the expected results of various calls tobdk_chain
structure methods (this is how we should that the final state is expected).Scenarios
last_seen
s conflict. The most recent tx should be the only tx that appears in the list methods.last_seen
s conflict. The most recent tx should be the only TX that appears in the list methods.U
conflicts with a tx anchored in orphaned blockO
.O
has higherlast_seen
.O
should be the only tx that appears in the list methods.U
conflicts with a tx anchored in orphaned blockO
.U
has higherlast_seen
.U
should be the only tx that appears in the list methods.B
andB'
conflict.C
spendsB
.B'
is anchored in best chain.B
andC
should not appear in the list methods.B
andB'
conflict.C
spendsB
.B
is anchored in best chain.B'
should not appear in the list methods.B
andB'
conflict.C
spends bothB
andB'
.C
is impossible. Try this with onlyB
confirmed vs onlyB'
confirmed vs none confirmed.Further work
Our current structures do not handle unconfirmed conflicts properly when the conflicting transactions have the same
last_seen
timestamp (thanks to @rajarshimaitra for pointing this out).bdk/crates/chain/tests/test_indexed_tx_graph.rs
Lines 692 to 695 in fe7bba1
I propose we deal with this as follows:
When two unconfirmed txs conflict, but have the same last_seen, we can check the input's sequences (using RBF rules). Otherwise, we sort by feerate (if possible). We fallback to lexicographical sorting of txids.
The text was updated successfully, but these errors were encountered: