Track serialized transactions in the mempool

Some transactions are malleable – meaning that an unprivileged actor can change them into different, valid transactions with different serialization, which may change the txid.

This is easily avoided using our segwit scheme, by signing over the entire transaction. However, there are some use-cases for which malleability is a desirable property. The client should be able to handle these types of transactions correctly.

For transactions in a block, no change is necessary. For transactions in the mempool:

• The node should not malleate transactions it receives over the network
• The node should not malleate transactions it receives via the internal API
• The node should respect the "first seen" rule for transactions and their malleations: nodes should not accept a malleated transaction if it double-spends a transaction already in the mempool.

This can be accomplished by tracking mempool transactions along with their serialization and their hash. When transmitting transactions in the mempool, the serialization should be used directly, instead of reserializing.

Serialization should occur only when a new transaction is created from scratch inside the node.