Implement and integrate new Incremental Merkle Tree
This supersedes #823.
----
This is an implementation of a new incremental merkle tree with
* no memory safety issues
* a more sensible internal design
* better space efficiency (tree representation, witnessing)
* simpler API
It is intended that this tracks the behavior of the previous tree, which it does, as verified by tests. I even wrote a little circuit for testing that all the paths work.
This PR also integrates the tree into the codebase and deprecates the old tree in almost all of our code. (I left it alone in `zerocashTest` but everything else has been changed.)
This change is compatible with the testnet but you will need to clear your *local* blockchain data out since the serialized representation of the merkle tree is now different.
Closes#517, Closes#519, Closes#591, Closes#460, Closes#473
Some specifics on consensus changes:
* Transactions must be anchored to a real anchor in the chain.
* Anchors are pushed and popped during ConnectBlock/DisconnectBlock as appropriate.
* DisconnectTip triggers evictions, under some circumstances, of transactions in the
mempool which are anchored to roots that are no longer valid.
* Commitments append to the tree at the current best root during ConnectBlock.
- rpcwallet: No need to lock twice here
- openssl: Clang doesn't understand selective lock/unlock here. Ignore it.
- CNode: Fix a legitimate (though very unlikely) locking bug.
Chance "getbalance *" not to use IsTrusted. The method and result
now match the "getbalance <specific-account>" behavior. In
particular, "getbalance * 0" now works.
Also fixed a comment -- GetGalance has required 1 confirmation
for many years, and the default "getbalance *" behavior matches
that.
Github-Pull: #6276
Rebased-From: 7d6a85ab5b1dc96e0f3f6f835f27bb81ba2af919
Previously due to an off-by-one error the wallet ignored
nLockTime-by-height transactions that would be valid in the next block
even though they are accepted into the mempool. The transactions
wouldn't show up until confirmed, nor would they be included in the
unconfirmed balance. Similar to the mempool behavior fix in 665bdd3b,
the wallet code was calling IsFinalTx() directly without taking into
account the fact that doing so tells you if the transaction could have
been mined in the *current* block, rather than the next block.
To fix this we strip IsFinalTx() of non-consensus-critical
functionality, removing the default arguments, and add CheckFinalTx() to
check if a transaction will be final in the next block.
Github-Pull: #6183
Rebased-From: 28bf06236d3b385e95fe26a7a742395b30efd6ee
It's reasonable that automatic coin selection will not pick a zero
value txout, but they're actually spendable; and you should know
if you have them. Listing also makes them available to tools like
dust-b-gone.
Adds a regression test for the wallet's ResendWalletTransactions function, which uses a new, hidden RPC command "resendwallettransactions."
I refactored main's Broadcast signal so it is passed the best-block time, which let me remove a global variable shared between main.cpp and the wallet (nTimeBestReceived).
I also manually tested the "rebroadcast unconfirmed every half hour or so" functionality by:
1. Running bitcoind -connect=0.0.0.0:8333
2. Creating a couple of send-to-self transactions
3. Connect to a peer using -addnode
4. Waited a while, monitoring debug.log, until I see:
```2015-03-23 18:48:10 ResendWalletTransactions: rebroadcast 2 unconfirmed transactions```
One last change: don't bother putting ResendWalletTransactions messages in debug.log unless unconfirmed transactions were actually rebroadcast.
