I'm trying to understand the algorithm Bitcoin Core uses to sort memory pool transactions by fee.
Gavin's fee rework proposal states:
Next, sort all remaining memory pool transactions by fee-paid-per-kilobyte, and include as many as will fit until the block is maximum block size bytes big, not including "free" transactions (transactions with fee-per-kb of less than the default spam threshold of 0.0001 BTC/kilobyte).
This makes sense, because a miner should want to load a block with transactions carrying the most "fee density", or fee per byte.
However, reviewing the CreateNewBlock function in miner.cpp, it's not clear how Bitcoin Core accounts for transaction length when prioritizing memory pool items:
// Prioritise by fee once past the priority size or we run out of high-priority
// transactions:
if (!fSortedByFee &&
((nBlockSize + nTxSize >= nBlockPrioritySize) || !AllowFree(dPriority)))
{
fSortedByFee = true;
comparer = TxPriorityCompare(fSortedByFee);
std::make_heap(vecPriority.begin(), vecPriority.end(), comparer);
}
TXPriorityCompare seems to just look at absolute fee:
public:
TxPriorityCompare(bool _byFee) : byFee(_byFee) { }
bool operator()(const TxPriority& a, const TxPriority& b)
{
if (byFee)
{
if (a.get<1>() == b.get<1>())
return a.get<0>() < b.get<0>();
return a.get<1>() < b.get<1>();
}
else
{
if (a.get<0>() == b.get<0>())
return a.get<1>() < b.get<1>();
return a.get<0>() < b.get<0>();
}
}
};
In other words, this looks like a sort on absolute transaction fee, not fee density. What am I missing?