A trasnaction is considered "conflicted" when one or more of its inputs are being spent by another transaction. A Conflicted transaction is marked with negative confirmation height in the gettransaction rpc call.
7315 described the situation when a conflicted transaction was previously in a block, which has later been reorged out. A reorg is a situation where a new longer chain has replaced a specific portion of the existing blockchain. So transactions in the reorged blocks are rejected.
When a conflict with an existing wallet transaction and a transaction in reorged block is identified, previously the conflicted transaction's state wasn't updated. This would cause irregular calculation in balance, as the inputs of the conflicting transaction, which were marked unspendable, becomes spendable again.
#27145 updates this behavior, and in case of block reorgs, the conflicted wallet transactions are marked as "inactive".
What is the purpose of try_updating_state lambda here? Why do we wanna mark transactions recursively?
What is the new block disconnection logic achieving here?
What is mapTxSpends and what is it used for?
What does it mean by EXCLUSIVE_LOCKS_REQUIRED(cs_wallet)?
Can you describe in brief the approach taken in wallet_conflicts.py functional tests? Are there any other test scenarios with conflicts you can think of?
Have you tried running the wallet_conflicts.py on master branch? How does it fail?
Learning
Orphaned Blocks.
Transaction conflicts.
Functional Testing.
Wallet behavior.
Note: Drop your PR and review related questions below
Session Details
[Wallet][python][c++]Notes
A trasnaction is considered "conflicted" when one or more of its inputs are being spent by another transaction. A Conflicted transaction is marked with negative confirmation height in the
gettransactionrpc call.7315 described the situation when a conflicted transaction was previously in a block, which has later been reorged out. A reorg is a situation where a new longer chain has replaced a specific portion of the existing blockchain. So transactions in the reorged blocks are rejected.
When a conflict with an existing wallet transaction and a transaction in reorged block is identified, previously the conflicted transaction's state wasn't updated. This would cause irregular calculation in balance, as the inputs of the conflicting transaction, which were marked unspendable, becomes spendable again.
#27145 updates this behavior, and in case of block reorgs, the conflicted wallet transactions are marked as "inactive".
Questions?
Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
What is the purpose of
try_updating_statelambda here? Why do we wanna mark transactions recursively?What is the new block disconnection logic achieving here?
What is
mapTxSpendsand what is it used for?What does it mean by
EXCLUSIVE_LOCKS_REQUIRED(cs_wallet)?Can you describe in brief the approach taken in
wallet_conflicts.pyfunctional tests? Are there any other test scenarios with conflicts you can think of?Have you tried running the
wallet_conflicts.pyon master branch? How does it fail?Learning