Keep track of explicit wallet conflicts instead of using mempool

This commit is contained in:
Pieter Wuille
2015-11-26 18:42:07 +01:00
parent 5d5ef3a4cf
commit 9ac63d6d30
6 changed files with 124 additions and 26 deletions

View File

@@ -215,6 +215,24 @@ of just announcing the hash. In a reorganization, all new headers are sent,
instead of just the new tip. This can often prevent an extra roundtrip before
the actual block is downloaded.
Negative confirmations and conflict detection
---------------------------------------------
The wallet will now report a negative number for confirmations that indicates
how deep in the block chain the conflict is found. For example, if a transaction
A has 5 confirmations and spends the same input as a wallet transaction B, B
will be reported as having -5 confirmations. If another wallet transaction C
spends an output from B, it will also be reported as having -5 confirmations.
To detect conflicts with historical transactions in the chain a one-time
`-rescan` may be needed.
Unlike earlier versions, unconfirmed but non-conflicting transactions will never
get a negative confirmation count. They are not treated as spendable unless
they're coming from ourself (change) and accepted into our local mempool,
however. The new "trusted" field in the `listtransactions` RPC output
indicates whether outputs of an unconfirmed transaction are considered
spendable.
0.12.0 Change log
=================