TODO: Add RPC and UI feature to re-issue transaction #3677

For daemon this would be a RPC call (reissuetransaction?), for UI could be context menu feature on transaction list.

The goal would be to 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, update prevouts
  • Fail if the resulting transaction would cause a double-spend with a transaction in the mempool or another active transaction in the wallet
  • Re-sign transaction (ask for unlock wallet if needed)
  • Broadcast transaction to network
• For normal unconfirmed transactions:
  • Rebroadcast transaction to network
• For confirmed transaction:
  • Do nothing / keep option disabled

A more advanced variant could allow for adding inputs and/or extra fee, but this base functionality would already be useful IMO.

By "update prevouts" do you mean to update the inputs and so change the txhash to a transaction already added to mapWallet? Would it be possible to mark the transaction as invalid, make the inputs spendable again, and always send a new transaction instead?

With updating prevouts I mean that you update the inputs txhash if needed, you leave it alone for inputs that are still valid. The point is that you can send the transaction that got stuck. It avoids the complication of having to re-mark anything as spendable.

But you mean creating a new transaction, not updating the old one? Because by updating mapWallet<uint256..> would be a different hash than wtx.GetHash(). This would cause all kinds of confusion.

I would always create a new transaction that tries to use the same inputs than the old one. If parent is conflicted try to use the parent variants. There could be a chain of unconfirmed transactions. So the parent is not always conflicted. Maybe some grand-grand-parent. If not enough Inputs randomly choose other inputs. Then the old transaction is marked as "reissued", this field contains the hash of the new one. The GUI could hide the old invalid transaction. So the user wouldnt notice. We could also hide them in RPC Listtransaction. The rpc call reissue returns the hash of the new transaction.

Also I think we should check "How many confirmations has the parent variant?". Or the parent-parent-variant if a chain of transactions. Only if >= 6 confirmations we create a new similar transaction. Otherwise we return some errorcode.

Sure, it will create a new transaction variant that can confirm, I of course didn't mean it will literally change the transaction in the wallet.

And indeed this will only work if the direct parent is confirmed but as another variant. This process could be done recursively if there are more transactions in between. Or the user could manually reissue them in the right order.

It should never be needed to choose different inputs. That could be dangerous as it makes reissueing multiple times possible (as happened to mtgox).