<p>The excerpt you're showing is for the priority area in blocks. The concept of "priority" in the source code corresponds modified bitcoin-days-destroyed per kilobyte. It is only used for a small portion of the block size (max 50kB by default in Bitcoin Core 0.11.x, and max 0kB by default in 0.12.x, it can be changed with a configuration setting).</p>

<p>Look at the rest of CreateNewBlock, which uses sorting by feerate, by iterating an index on the mempool that is pre-sorted by feerate (=satoshi per kB).</p>

CC BY-SA 3.0
2016-04-01T14:10:23.473Z
2016-04-01T14:10:23.473Z
Pieter Wuille
<p>I'm trying to understand the algorithm Bitcoin Core uses to sort memory pool transactions by fee.</p>

<p>Gavin's <a href="https://gist.github.com/gavinandresen/2961409" rel="nofollow">fee rework proposal</a> states:</p>

<blockquote>
  <p>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).</p>
</blockquote>

<p>This makes sense, because a miner should want to load a block with transactions carrying the most "fee density", or fee per byte.</p>

<p>However, reviewing the <a href="https://github.com/bitcoin/bitcoin/blob/v0.10.2/src/miner.cpp#L258" rel="nofollow">CreateNewBlock function in miner.cpp</a>, it's not clear how Bitcoin Core accounts for transaction length when prioritizing memory pool items:</p>

<pre><code>// Prioritise by fee once past the priority size or we run out of high-priority
// transactions:
if (!fSortedByFee &amp;&amp;
    ((nBlockSize + nTxSize &gt;= nBlockPrioritySize) || !AllowFree(dPriority)))
{
    fSortedByFee = true;
    comparer = TxPriorityCompare(fSortedByFee);
    std::make_heap(vecPriority.begin(), vecPriority.end(), comparer);
}
</code></pre>

<p>TXPriorityCompare seems to just look at absolute fee:</p>

<pre><code>public:
    TxPriorityCompare(bool _byFee) : byFee(_byFee) { }

    bool operator()(const TxPriority&amp; a, const TxPriority&amp; b)
    {
        if (byFee)
        {
            if (a.get&lt;1&gt;() == b.get&lt;1&gt;())
                return a.get&lt;0&gt;() &lt; b.get&lt;0&gt;();
            return a.get&lt;1&gt;() &lt; b.get&lt;1&gt;();
        }
        else
        {
            if (a.get&lt;0&gt;() == b.get&lt;0&gt;())
                return a.get&lt;1&gt;() &lt; b.get&lt;1&gt;();
            return a.get&lt;0&gt;() &lt; b.get&lt;0&gt;();
        }
    }
};
</code></pre>

<p>In other words, this looks like a sort on absolute transaction fee, not fee density. What am I missing?</p>

<bitcoin-core><transaction-fees><mempool><transaction-selection>
How does Bitcoin Core sort memory pool transactions by fee?
Rich Apodaca
# How does Bitcoin Core sort memory pool transactions by fee?

(Asked by: username_0 on 2015-07-08)

I'm trying to understand the algorithm Bitcoin Core uses to sort memory pool transactions by fee.

Gavin's [fee rework proposal](https://gist.github.com/gavinandresen/2961409) 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](https://github.com/bitcoin/bitcoin/blob/v0.10.2/src/miner.cpp#L258), 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?

**Tags:** bitcoin-core, transaction-fees, mempool, transaction-selection


---

## 1 answers

### Answer by username_1 on 2016-04-01. Score: 1

The excerpt you're showing is for the priority area in blocks. The concept of "priority" in the source code corresponds modified bitcoin-days-destroyed per kilobyte. It is only used for a small portion of the block size (max 50kB by default in Bitcoin Core 0.11.x, and max 0kB by default in 0.12.x, it can be changed with a configuration setting).

Look at the rest of CreateNewBlock, which uses sorting by feerate, by iterating an index on the mempool that is pre-sorted by feerate (=satoshi per kB).


---

