Since #7946 we don’t hold cs_main while syncing transactions connected in a block with our wallet. There have been several previously identified open issues such as #9148 and proposed fixes before 0.14.
There are at least two more potential unsolved problems:
- There is a race condition where if two blocks are connected in different threads the wallet could receive the transactions in the connected blocks out of order. In particular if there was a reorg, and a wallet transaction appeared on both chains of the reorg, and the wallet received notification of the transaction in the stale block after receiving notification of the transaction in the current tip block, then this could lead to the wallet believing a confirmed transaction is currently conflicted because it will have the wrong
hashBlock. One potential scenario that could cause this race is a miner issuing a preciousblock rpc call (for a block tied with the current tip) simultaneously with receiving a new block building off the current tip. CreateTransactioncalls take cs_main, which used to mean that the wallet, mempool and chainstate were necessarily synced. However it is unknown whether problems could be caused by trying to create a new transaction while the mempool and chain state might be ahead of where the wallet is synced. This is probably not an actual problem, but needs further review.- Certainly it is possible that transactions might be created which are no longer valid and won’t be accepted to the mempool.
- Additionally it needs to be carefully thought about whether it is ok for the wallet transaction to be created based on chain state information from the current tip but then possibly updated afterwards with stale information.
