the `zapwallettxes.py` qa test is currently broken due to a syntax error:

```python
     assert_raises(JSONRPCException, self.nodes[0].gettransaction, [txid3])
     #there must be a expection because the unconfirmed wallettx0 must be gone by now
```

This doesn't actually test that the transaction is not in the wallet, because `gettransaction()` is being called incorrectly (with an array instead of a string).

Changing the test to `assert_raises(JSONRPCException, self.nodes[0].gettransaction, txid3)` causes the rpc to succeed and the test script to fail because `txid3` is still in the wallet.

This is because the mempool is now persistent and is saved to disk when bitcoind shuts down. zapwallettxes removes the unconfirmed transaction from the wallet but bitcoind will rescan the mempool.dat file on startup and add the unconfirmed transaction back into the wallet.

I've 'fixed' zapwallettxes.py in https://github.com/jnewbery/bitcoin/tree/zapwallettxes , but the question remains: how *should* -zapwallettxes interact with persistent mempool? The use case for zapwallettxes is explained here: https://github.com/bitcoin/bitcoin/pull/3659#issuecomment-34878999 . My view is that even with zapwallettxes, bitcoind should rescan the mempool, but there should be better documentation or a warning that unconfirmed transaction in your mempool will be re-added to the wallet even if zapwallettxes is used. If you really want to remove all unconfirmed transactions from your wallet, you can delete your mempool.dat file and then restart with zapwallettxes.
bool ActivateBestChain(CValidationState& state, const CChainParams& chainparams, std::shared_ptr<const CBlock> pblock = std::shared_ptr<const CBlock>());
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams);
double GuessVerificationProgress(const ChainTxData& data, CBlockIndex* pindex);
/**
 * Prune block and undo files (blk???.dat and undo???.dat) so that the disk space used is less than a user-defined target.
 * The user sets the target (in MB) on the command line or in config file.  This will be run on startup and whenever new
 * space is allocated in a block or undo file, staying below the target. Changing back to unpruned requires a reindex
 * (which in this case means the blockchain must be re-downloaded.)
 *
 * Pruning functions are called from FlushStateToDisk when the global fCheckForPruning flag has been set.
 * Block and undo files are deleted in lock-step (when blk00003.dat is deleted, so is rev00003.dat.)
 * Pruning cannot take place until the longest chain is at least a certain length (100000 on mainnet, 1000 on testnet, 1000 on regtest).
 * Pruning will never delete a block within a defined distance (currently 288) from the active chain's tip.
 * The block index is updated by unsetting HAVE_DATA and HAVE_UNDO for any blocks that were stored in the deleted files.
 * A db flag records the fact that at least some block files have been pruned.
 *
 * @param[out]   setFilesToPrune   The set of file indices that can be unlinked will be returned
 */
void FindFilesToPrune(std::set<int>& setFilesToPrune, uint64_t nPruneAfterHeight);
/**
 *  Mark one block file as pruned.
 */
void PruneOneBlockFile(const int fileNumber);
/**
 *  Actually unlink the specified files
 */
void UnlinkPrunedFiles(const std::set<int>& setFilesToPrune);
CBlockIndex * InsertBlockIndex(uint256 hash);
void FlushStateToDisk();
void PruneAndFlush();