<p>First, even if you find the transaction with the lowest effective fee rate in a block, that will not necessarily mean that the mempool cleared to that level. In their recent paper <a href="https://people.mpi-sws.org/%7Ejohnme/pdf/messias-sdbd-20.pdf" rel="nofollow noreferrer">&quot;On Blockchain Commit Times: An analysis of how miners choose Bitcoin transactions</a>&quot;, Messias et al observe deviations in the block composition from the expected norm (<a href="https://btcinformation.org/en/developer-reference#getblocktemplate" rel="nofollow noreferrer">GetBlockTemplate</a>) of up to 22%. They surmise that this could be caused by out-of-band prioritization or use of other algorithms.</p>
<p>Fact is, we don't know what software miners are running to compose blocks, how often they update their templates, how often they get acceleration requests or have their own interests to include transactions, and which version of Bitcoin Core they may be running if they even they simply use GetBlockTemplate (GBT).</p>
<p>Assuming that blocks are generally produced by Bitcoin Core's <em>GetBlockTemplate</em> method, and applying general rules for block composition, we know the following:</p>
<ul>
<li>Transactions must be ordered topologically in a block<br />
If a transaction spends UTXOs created within the
same block, the child transaction must follow the parent in the block's transaction list</li>
<li>GBT selects in order of effective fee rate</li>
<li>GBT will select complete transaction ancestor groups<br />
This means either a single transaction if no child transaction is present, or the descendants have a lower effective feerate, or the complete group derived from the descendant that has the highest effective feerate.</li>
<li>Groups may be skipped when they don't fit in the block<br />
If a transaction group requires more blockspace than is left, a smaller transaction group with a lower effective feerate will get included instead. This means that larger transaction groups may miss a block even though transactions with lower feerates made it in.</li>
<li>Only the best sibling counts<br />
Sibling transactions <em>do not</em> form a shared ancestor group unless the
ancestor group is started from a shared descendant. I.e. if two siblings both have higher feerates than the parent, they each form a separate ancestor group in the candidate list and get prioritized on basis of the effective feerate of their individual group. When the ancestor group with the higher effective feerate gets selected, all remaining ancestor groups get recalculated and the sibling transactions would now likely have the highest effective feerate right afterwards (since it was higher than the parent alone). So, even if siblings and parents all appeared grouped in a block, they would be positioned at the highest effective feerate among the individual ancestor groups, the parent does not gain a special benefit from being CPFPed multiple times in parallel, and they were actually selected iteratively not together.</li>
</ul>
<p>Altogether, it would be expected that transactions should appear in descending order of their feerate in the block (when using GBT), except where topology interferes, or transactions have been imbued with a &quot;virtual high-feerate&quot; via <a href="https://btcinformation.org/en/developer-reference#prioritisetransaction" rel="nofollow noreferrer">PrioritiseTransaction</a>. <strong>I.e. you could look at the effective feerates of the last few transactions in the block and make a guess from there.</strong> Taking a low percentile instead may give you a more representative value.</p>

CC BY-SA 4.0
2020-10-08T21:49:28.530Z
@Prayank: Coin-age priority has been disabled since Bitcoin Core 0.12.0: https://bitcoin.stackexchange.com/q/49226/5406
Murch
CC BY-SA 4.0
2020-10-08T16:03:44.990Z
2020-10-08T22:32:15.057Z
2020-10-08T22:32:15.057Z
Murch
<p>Given a bitcoin block, what's the easiest way to determine the minimum net fee rate (including ancestors) for transactions in that block?</p>
<p>A naive approach would be to just find the minimum fee rate for a single transaction, but that does not take ancestor and descendant chains into account. I want to know the minimum clearing fee rate for the block considering the full ancestor/descendant chains</p>
<p>I've been looking through the <a href="https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L102" rel="nofollow noreferrer">transaction selection algorithm</a> to try and understand the logic, and figured I could try and reverse engineer it to decode an existing block... but I'm wondering if someone has already done the work and created a good tool/script/api that can parse an existing block and determine the minimum net fee rate of the block's transactions</p>

CC BY-SA 4.0
2020-10-07T22:33:33.047Z
Have you read [help/on-topic] and are you just looking for a software recommendation or did you want to know the method by which you can calculate the fee paid and fee-rate paid for transactions in a block?
RedGrittyBrick
CC BY-SA 4.0
2020-10-07T23:05:45.633Z
I'd like to know a good way to calculate the minimum net fee rate of all the ancestor chains in a block, if one exists
deezy
<transaction-fees><block><fee-estimation>
Given a bitcoin block, what's the easiest way to determine the minimum net fee rate (including ancestors) for transactions in that block?
deezy
# Given a bitcoin block, what's the easiest way to determine the minimum net fee rate (including ancestors) for transactions in that block?

(Asked by: username_0 on 2020-10-06)

Given a bitcoin block, what's the easiest way to determine the minimum net fee rate (including ancestors) for transactions in that block?

A naive approach would be to just find the minimum fee rate for a single transaction, but that does not take ancestor and descendant chains into account. I want to know the minimum clearing fee rate for the block considering the full ancestor/descendant chains

I've been looking through the [transaction selection algorithm](https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L102) to try and understand the logic, and figured I could try and reverse engineer it to decode an existing block... but I'm wondering if someone has already done the work and created a good tool/script/api that can parse an existing block and determine the minimum net fee rate of the block's transactions

**Tags:** transaction-fees, block, fee-estimation

> **Comments:**
> **username_1**: Have you read [help/on-topic] and are you just looking for a software recommendation or did you want to know the method by which you can calculate the fee paid and fee-rate paid for transactions in a block?  
> **username_0**: I'd like to know a good way to calculate the minimum net fee rate of all the ancestor chains in a block, if one exists  

---

## 1 answers

### Answer by username_2 on 2020-10-08. Score: 3 | Accepted answer

First, even if you find the transaction with the lowest effective fee rate in a block, that will not necessarily mean that the mempool cleared to that level. In their recent paper ["On Blockchain Commit Times: An analysis of how miners choose Bitcoin transactions](https://people.mpi-sws.org/%7Ejohnme/pdf/messias-sdbd-20.pdf)", Messias et al observe deviations in the block composition from the expected norm ([GetBlockTemplate](https://btcinformation.org/en/developer-reference#getblocktemplate)) of up to 22%. They surmise that this could be caused by out-of-band prioritization or use of other algorithms.

Fact is, we don't know what software miners are running to compose blocks, how often they update their templates, how often they get acceleration requests or have their own interests to include transactions, and which version of Bitcoin Core they may be running if they even they simply use GetBlockTemplate (GBT).

Assuming that blocks are generally produced by Bitcoin Core's *GetBlockTemplate* method, and applying general rules for block composition, we know the following:

* Transactions must be ordered topologically in a block  
  If a transaction spends UTXOs created within the
  same block, the child transaction must follow the parent in the block's transaction list
* GBT selects in order of effective fee rate
* GBT will select complete transaction ancestor groups  
  This means either a single transaction if no child transaction is present, or the descendants have a lower effective feerate, or the complete group derived from the descendant that has the highest effective feerate.
* Groups may be skipped when they don't fit in the block  
  If a transaction group requires more blockspace than is left, a smaller transaction group with a lower effective feerate will get included instead. This means that larger transaction groups may miss a block even though transactions with lower feerates made it in.
* Only the best sibling counts  
  Sibling transactions *do not* form a shared ancestor group unless the
  ancestor group is started from a shared descendant. I.e. if two siblings both have higher feerates than the parent, they each form a separate ancestor group in the candidate list and get prioritized on basis of the effective feerate of their individual group. When the ancestor group with the higher effective feerate gets selected, all remaining ancestor groups get recalculated and the sibling transactions would now likely have the highest effective feerate right afterwards (since it was higher than the parent alone). So, even if siblings and parents all appeared grouped in a block, they would be positioned at the highest effective feerate among the individual ancestor groups, the parent does not gain a special benefit from being CPFPed multiple times in parallel, and they were actually selected iteratively not together.

Altogether, it would be expected that transactions should appear in descending order of their feerate in the block (when using GBT), except where topology interferes, or transactions have been imbued with a "virtual high-feerate" via [PrioritiseTransaction](https://btcinformation.org/en/developer-reference#prioritisetransaction). **I.e. you could look at the effective feerates of the last few transactions in the block and make a guess from there.** Taking a low percentile instead may give you a more representative value.

> **Comments:**
> **username_2**: @Prayank: Coin-age priority has been disabled since Bitcoin Core 0.12.0: https://bitcoin.stackexchange.com/q/49226/5406  

---

