Orphan transactions were stored as a CDataStream pointer; this changes the mapOrphanTransactions data structures to store orphans as a CTransaction.
This also fixes CVE-2013-4627 by always re-serializing transactions before relaying them.
And I cleaned up the "tx" message-handling code a little (it was re-using 'inv' and 'tx' variables, which is error-prone and confusing).
Tested by running against the main network with max orphans set to eleven, to exercise the add/remove/map overflow code.
This reverts commit c40a5aaaf484855a4350fd702e8e72fd21a68155.
Orphan transactions were stored as a CDataStream pointer;
this changes the mapOrphanTransactions data structures to
store orphans as a CTransaction.
This also fixes CVE-2013-4627 by always re-serializing
transactions before relaying them.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/159bc4819304c4394a92230c9e7b9f3416abe877 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.
Seems ok to me.
mapOrphanTransactions[hash] cannot be null; it will be initialized to an empty (default constructor) CTransaction when referenced. That should be impossible, because addOrphan/EraseOrphan keeps mapOrphanTransactions and mapOrphanTransactionsByPrev in sync. But even if some bug caused it to happen, if that default CTransaction made it out of the orphan list it would be rejected by the memory pool. If it got stuck in the orphan list... no big deal, it will eventually be evicted.
Haven't tested, but looks good to me.