Keep track of explicit wallet conflicts instead of using mempool

1 files changed, 18 insertions, 0 deletions

diff --git a/doc/release-notes.md b/doc/release-notes.md
index f7958381b6..96c830d177 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -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
 =================