Add RPC `reissuetransaction` #3681

Add a new wallet RPC call reissuetransaction. Implements #3677.

The is make it possible to re-issue transactions that got stuck because they built on unconfirmed change transactions that were malleated.

• For conflicted transactions:
  • Iterate over inputs, find variants of parent transactions that made it into the block chain, create a new transaction with updated prevouts
  • Re-sign transaction
  • Commit new transaction to wallet and broadcast it to network
• For normal unconfirmed transactions:
  • Rebroadcast transaction to network
• For confirmed transaction:
  • Do nothing

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/7bc8c2815147b6d205046ea4c437045c51626d79 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Just some thoughts on this: If the parent variant has already been spent the reissue fails. If we are in a chain of unconfirmed transactions (so the parent is not malleated, but the parent-parent) reissue also fails. Not sure if big merchants can set -spendzeroconfchange because they have to send a lot of transactions, the wallet could run out of funds too quickly, if set. I am just concerned that on busy wallets this version of reissue is useless because most reissues will fail. So if they still need to manually clean up the wallet (with zapwallettxes?) and do many reissue on their own, I doubt they are interested in using reissue in the first place. There is a different implementation of reissuetransaction https://github.com/cozz/bitcoin/commit/daffee917a511f281dd76c1ad98c0dcd7b269fbe It only allows reissue, if there is a confirmed parent conflict and all parent conflicts must be confirmed by 6 confirmations. It provides mainly the advantage that a reissue can never fail, unless we are waiting for confirmations. It returns an error on normal unconfirmed transactions. It is designed so businesses can just blindly hammer reissuetransaction on all transactions, without reissuing anything twice, or even anything that is not conflicted and does not need a reissue.

A further idea to this is to provide a rpc "needreissue". This would simply return an array of transaction ids, that need a reissue. So businesses just need to periodically call this and reissue the transactions. We could even provide a "autoreissue". This reissues all transactions where there is a parent conflict confirmed by 6 confirmations and that have not been reissued before of course.

Another further idea: in rpc we have introduced a new field "walletconflicts". I would like to rename this field to something like "replacedby". This is because if a transaction has been reissued, it would also appear there. So there is a general field "replacedby" showing the new transaction id. Now matter if it has been replaced because "malleated" or if it has been replaced because we manually reissued, replacing by our own.

(Havent tested, but is there a check if the parent variant has been spent in the meantime in the current code? Not sure, but if not the current implementation could add another double spend to the wallet.)

I'm afraid this is way too complicated. No way to test this or at least all corner cases.

Hadn't thought about it that it would be possible for the parent variant to already be spent. I thought this would be a relatively way to avoid having to mess with vfSpent and still make it possible to unstuck transactions.

But if it still amounts to thousands of lines of code, let's forget about it. -zapwallettxes and then manual re-issue is a much more thorough solution.