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).