After D4906/D4903, it turns out that all places using GetTxVirtualSize() and

GetVirtualSizeWithDescendants() are better if given the **incremental**

virtual sizes that would be calculated including ancestor information as

a baseline. The increment can be smaller than if we ignored that baseline,

because of the nonlinearity of the VirtualSize function. This is a

distinction that was not relevant before now. By taking advantage of the

distinction we can get more optimal package handling in cases where the

transactions have highly variable sigops density.

For example, consider a case of three transactions, where txC spends

txB output which in turn spends txA output.

txA size=100, sigops=10, fee=10000 txB size=100, sigops=0, fee=100 txC size=200, sigops=2, fee=700

We can mine either {txA}, {txA, txB}, or {txA, txB, txC}. The

virtualsizes (50 bytes/sigop) and fees for these packages are:

500, 500, 600 10000, 10100, 10800

Note that including txB is 'free', because it is riding on a sigop-heavy

ancestor so the virtualsize is sigop-dominated. Including txC is also

partially free -- only its sigops count matters. The total feerates for

these packages (sat/vbyte) are:

20, 20.2, 18

So {txA, txB} is definitely the first choice for mining. But prior

to this patch, that wouldn't be chosen. Here are the changes in

ancestor scoring with this patch:

txB: 20.2 sat/vbyte [was 1 sat/vbyte] txA: 20 sat/vbyte [was 20 sat/vbyte] txC: 7 sat/vbyte [was 3.5 sat/vbyte]

i.e. the mining will first choose txB (with txA), then later on will

choose txC.

Likewise, if the mempool is full then we can evict either {txC},

{txB, txC}, or {txA, txB, txC}. Again there is no reason to evict

txB before evicting txA, and the new descendant scoring will give:

txC: 7 sat/vbyte [was 3.5 sat/vbyte] txA: 20 sat/vbyte [was 20 sat/vbyte] txB: inf sat/vbyte [was 2.6 sat/vbyte]

i.e., the mempool will first evict txC, then later evict txA (with txB).