[WIP] Erase orphans only when banned #8618

This pull refines the excellent insightful contributions of @gavinandresen in c74332c67806ed92e6e18de174671a7c30608780

Denial of service logic might possibly have been a little harsh and was written before compact/thin block technology was incorporated into the code.

Only remove orphans from mempool from nodes that were misbehaving. This will allow for more efficient compact/thin block downloads.

Thank you for your consideration of this code.

WIP is it requires further testing - e.g. what happens if a node dumps a bunch of invalid orphans and then disconnects - the code still needs to keep track of the disconnected node's misbehaviour...! (EraseOrphan code perhaps moving from FinalizeNode to the point where it is banned...?)

Orphans are not even used for compact block reconstruction.

And keeping the orphans a disconnected peer gave us opens up an avenue for attack: you can repeatedly send a bunch of nonsense orphans, and disconnect. This will cause the orphan pool to overflow and its effectiveness will decrease.

@sipa Now that you mention that, it makes sense - I mean, of course orphans aren't used.... which confuses me as Unlimited's code removes the line entirely (doesn't even make it dependent on misbehaviour). Any idea why they do this? Perhaps it helps with future blocks, i.e. not the very next one - or perhaps they found that orphans often find their parents when the block arrives, so it did significantly help reduce the amount of refetches needed. This makes sense to me also... which now makes your sentence make less sense to me - what do you mean when orphans are not used for compact block reconstruction? What if the block mined includes some of those orphans? It wouldn't use the ones already cached in memory?

The changes in 0.13 should make orphans much less common, if a large part of the network adopts them. The earlier "trickle" based tx announcement logic systematically relayed transactions and their dependencies out of order. Between 0.13 there are hardly any orphans anymore.

@rebroad If you have any question with other projects please ask please ask in the respective issue tracker. People here can't be responsible for their actions.

I currently have no reason to believe this is useful at this time-- really we should be looking at what orphan behavior is like once 0.13 is widely deployed (or at least, checked on nodes which only have 0.13 peers).

@sipa @gmaxwell Thanks for the explanations. Ok, so I have only one question remaining regarding orphans, which is child pays for parent - how are these txs currently relayed? e.g. a parent has a fee below minrelayfee so doesn't get relayed, and child has a healthy fee above minrelayfee but is to most nodes an orphan - how are child pays for parent txs being reliably relayed currently?

Hopefully what happens is that the child is relayed closely followed by the parent - this way nodes can identify the parent as the parent of the child and relay it even if the fee is below minrelayfee.

Anyway, I intend to close this pull for now as it does appear to be unnecessary but would enjoy hearing that the above functionality mentioned is already in the code.

CPFP won't work if the parent is below the minrelaytxfee.