d11fc16 [Wallet] Call notification signal when a transaction is abandoned (Jonas Schnelli)
df0e222 Add RPC test for abandoned and conflicted transactions. (Alex Morcos)
01e06d1 Add new rpc call: abandontransaction (Alex Morcos)
9e69717 Make wallet descendant searching more efficient (Alex Morcos)
Unconfirmed transactions that are not in your mempool either due to eviction or other means may be unlikely to be mined. abandontransaction gives the wallet a way to no longer consider as spent the coins that are inputs to such a transaction. All dependent transactions in the wallet will also be marked as abandoned.
Due to include ordering, defining in one place was not enough to ensure correct
usage. Use global defines so that we don't have to worry abou this ordering.
Also add a comment in configure about the test.
8a7f000 [RPC] remove the option of having multiple timer interfaces (Jonas Schnelli)
db198d5 Fix RPCTimerInterface ordering issue Dispatching a QThread from a non Qt thread is not allowed. Always use the HTTPRPCTimerInterface (non QT) to dispatch RPCRunLater threads. (Jonas Schnelli)
fa33d97 [walletdb] Add missing LOCK() in Recover() for dummyWallet (MarcoFalke)
fa14d99 [qa] check if wallet or blochchain maintenance changes the balance (MarcoFalke)
fa0765d [qa] Cleanup wallet.py test (MarcoFalke)
3968922 c++11: fix libbdb build against libc++ in c++11 mode (Cory Fields)
57d2f62 c++11: CAccountingEntry must be defined before use in a list (Cory Fields)
89f71c6 c++11: don't throw from the reverselock destructor (Cory Fields)
76ac35f c++11: detect and correct for boost builds with an incompatible abi (Cory Fields)
noexcept is default for destructors as of c++11. By throwing in reverselock's
destructor if it's lock has been tampered with, the likely result is
std::terminate being called. Indeed that happened before this change.
Once reverselock has taken another lock (its ctor didn't throw), it makes no
sense to try to grab or lock the parent lock. That is be broken/undefined
behavior depending on the parent lock's implementation, but it shouldn't cause
the reverselock to fail to re-lock when destroyed.
To avoid those problems, simply swap the parent lock's contents with a dummy
for the duration of the lock. That will ensure that any undefined behavior is
caught at the call-site rather than the reverse lock's destruction.
Barring a failed mutex unlock which would be indicative of a larger problem,
the destructor should now never throw.
