<p>As Andrew Chow pointed out, my feerate calculations were wrong. I used the totalSize of the transaction. Correct would have been to use the virtualSize.</p>

<p>With correct calculations the visualization looks far more as I expected.</p>

<p><a href="https://i.sstatic.net/sJ6P1.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sJ6P1.png" alt="Block 517361"></a>
Block #517361 (compare above)</p>

CC BY-SA 3.0
2018-04-11T11:05:57.157Z
2018-04-11T11:05:57.157Z
0xb10c
<blockquote>
  <p>1) Is this known behavior of an algorithm that creates block templates? </p>
</blockquote>

<p>Yes. This is behavior that is present in Bitcoin Core.</p>

<p>Bitcoin Core bundles transactions into "packages" of one or more transactions. Each package consists of an unconfirmed transaction and its children (if any) to cover the case of Child-Pays-For-Parent. The transaction fee rate is calculated for the entire package (total fees paid by the transactions in the package divided by size of the package).</p>

<p>When transactions are selected, it's really the packages that are selected. Because the packages are put inside the block in the order of package fee rate, you will sometimes get a few low fee rate transactions followed by a really high fee rate transaction because they were all part of the same transaction and the high fee rate transaction was a child that paid for it's parent(s).</p>

<p>This is called "ancestor fee rate ordering".</p>

<blockquote>
  <p>2) What motivation is there behind this feature. Is it a bug?</p>
</blockquote>

<p>It is neither a feature nor a bug, it is just a quirk of how the transaction selection works.</p>

<hr>

<p>See also: <a href="https://bitcointalk.org/index.php?topic=2058831.0" rel="nofollow noreferrer">https://bitcointalk.org/index.php?topic=2058831.0</a></p>

CC BY-SA 3.0
2018-04-10T16:06:26.307Z
Thanks Andrew, but this does not really answer my question. I mentioned CPFP transactions in my question with the typical lower fee tx followed by a high/higher fee tx which are easy to see in the visualisation. But that's not what I mean. E.g. in block #517363 are ~30 5 sat/B tx which are followed by a single 9 sat/B tx and then again by multiple 5 sat/B tx (around position 1200). This (I believe at least, will check later) does not seem like CPFP, or at least is not the correct position in the block for a big package of these 31 tx's. (30*5sat/B + 1*9sat/B)/31tx would be later in the block.
0xb10c
CC BY-SA 3.0
2018-04-10T18:06:08.533Z
I think you are actually calculating the feerate incorrectly. I double checked and I am not getting the same feerates as you are for those transactions at the given block indexes. The numbers that you have match up to sat/byte, not sat/vbyte. I think you aren't calculating the feerates for transactions spending segwit inputs correctly.
Ava Chow
CC BY-SA 3.0
2018-04-10T18:08:08.133Z
yes, you are correct. I discovered it like 5 minutes ago while looking at the transactions mentioned above. Thanks!
0xb10c
CC BY-SA 3.0
2018-04-10T18:09:37.960Z
As an aside, I wrote a quick python script to calculate what transactions are packaged together in a given block: https://gist.github.com/achow101/dfb1016f78e653656ec40cd019f8116b. I think it works.
Ava Chow
CC BY-SA 3.0
2018-04-10T15:34:00.050Z
2018-04-10T15:34:00.050Z
Ava Chow
<p>While building a tool/visualization that displays the feerate of a transaction according to it's position in a given block I came across a patter in some blocks.</p>

<p>I expect a typical block to start with the highest fee per byte ratio (feerate) transactions and then continue with transactions where the feerate slowly decreases. Often there are some CPFP transactions where a lower feerate is followed by a higher feerate.</p>

<p>However, what I'm seeing is, that in some blocks (from different miners) are mixed 9 sat/B transactions with 5 sat/B transactions in between. At a later position in the block there are 5 sat/B transactions again. This happens over multiple blocks and different miners. I guess it originates from getblocktemplate or something similar.</p>

<p>I've forked a version of my tool an highlight 5 sat/B transactions in blue (Can be found <a href="https://5sat-byte-showcase.b10c.me/#517363" rel="nofollow noreferrer">here</a>, feel free to explore). Since this is still under active development, I'll include screenshots of some blocks in case the links stop working. I deliberately selected a set of blocks where I think it's clear what I mean. </p>

<hr>

<p><strong>Sample Blocks:</strong></p>

<p><a href="https://i.sstatic.net/5jgc6.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/5jgc6.png" alt="Block 517361"></a>
Block <a href="https://5sat-byte-showcase.b10c.me/#517361" rel="nofollow noreferrer">#517361</a> mined by ViaBTC (?)</p>

<p><a href="https://i.sstatic.net/E3iDa.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/E3iDa.png" alt="Block 517363"></a>
Block <a href="https://5sat-byte-showcase.b10c.me/#517363" rel="nofollow noreferrer">#517363</a> mined by BTC.TOP (?)</p>

<p><a href="https://i.sstatic.net/DjtVU.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/DjtVU.png" alt="Block 517357"></a>
Block <a href="https://5sat-byte-showcase.b10c.me/#517357" rel="nofollow noreferrer">#517357</a> mined by BTC.com (?)</p>

<p>and <a href="https://5sat-byte-showcase.b10c.me/#517362" rel="nofollow noreferrer">here</a> is one from Slush too.</p>

<hr>

<p><strong>Questions:</strong> </p>

<p>1) Is this known behavior of an algorithm that creates block templates? </p>

<p>2) What motivation is there behind this feature. Is it a bug?</p>

<p>3) Are there commonly used <code>getblocktemplate</code> alternatives?</p>

<transaction-fees><mining-theory><getblocktemplate>
Where does this pattern in the feerate distribution per block originate from?
0xb10c
# Where does this pattern in the feerate distribution per block originate from?

(Asked by: username_0 on 2018-04-10)

While building a tool/visualization that displays the feerate of a transaction according to it's position in a given block I came across a patter in some blocks.

I expect a typical block to start with the highest fee per byte ratio (feerate) transactions and then continue with transactions where the feerate slowly decreases. Often there are some CPFP transactions where a lower feerate is followed by a higher feerate.

However, what I'm seeing is, that in some blocks (from different miners) are mixed 9 sat/B transactions with 5 sat/B transactions in between. At a later position in the block there are 5 sat/B transactions again. This happens over multiple blocks and different miners. I guess it originates from getblocktemplate or something similar.

I've forked a version of my tool an highlight 5 sat/B transactions in blue (Can be found [here](https://5sat-byte-showcase.b10c.me/#517363), feel free to explore). Since this is still under active development, I'll include screenshots of some blocks in case the links stop working. I deliberately selected a set of blocks where I think it's clear what I mean.

---

**Sample Blocks:**

[![Block 517361](https://i.sstatic.net/5jgc6.png)](https://i.sstatic.net/5jgc6.png)
Block [#517361](https://5sat-byte-showcase.b10c.me/#517361) mined by ViaBTC (?)

[![Block 517363](https://i.sstatic.net/E3iDa.png)](https://i.sstatic.net/E3iDa.png)
Block [#517363](https://5sat-byte-showcase.b10c.me/#517363) mined by BTC.TOP (?)

[![Block 517357](https://i.sstatic.net/DjtVU.png)](https://i.sstatic.net/DjtVU.png)
Block [#517357](https://5sat-byte-showcase.b10c.me/#517357) mined by BTC.com (?)

and [here](https://5sat-byte-showcase.b10c.me/#517362) is one from Slush too.

---

**Questions:**

1) Is this known behavior of an algorithm that creates block templates?

2) What motivation is there behind this feature. Is it a bug?

3) Are there commonly used `getblocktemplate` alternatives?

**Tags:** transaction-fees, mining-theory, getblocktemplate


---

## 2 answers

### Answer by username_1 on 2018-04-10. Score: 3 | Accepted answer

> 1) Is this known behavior of an algorithm that creates block templates?

Yes. This is behavior that is present in Bitcoin Core.

Bitcoin Core bundles transactions into "packages" of one or more transactions. Each package consists of an unconfirmed transaction and its children (if any) to cover the case of Child-Pays-For-Parent. The transaction fee rate is calculated for the entire package (total fees paid by the transactions in the package divided by size of the package).

When transactions are selected, it's really the packages that are selected. Because the packages are put inside the block in the order of package fee rate, you will sometimes get a few low fee rate transactions followed by a really high fee rate transaction because they were all part of the same transaction and the high fee rate transaction was a child that paid for it's parent(s).

This is called "ancestor fee rate ordering".

> 2) What motivation is there behind this feature. Is it a bug?

It is neither a feature nor a bug, it is just a quirk of how the transaction selection works.

---

See also: <https://bitcointalk.org/index.php?topic=2058831.0>

> **Comments:**
> **username_0**: Thanks Andrew, but this does not really answer my question. I mentioned CPFP transactions in my question with the typical lower fee tx followed by a high/higher fee tx which are easy to see in the visualisation. But that's not what I mean. E.g. in block #517363 are ~30 5 sat/B tx which are followed by a single 9 sat/B tx and then again by multiple 5 sat/B tx (around position 1200). This (I believe at least, will check later) does not seem like CPFP, or at least is not the correct position in the block for a big package of these 31 tx's. (30*5sat/B + 1*9sat/B)/31tx would be later in the block.  
> **username_1**: I think you are actually calculating the feerate incorrectly. I double checked and I am not getting the same feerates as you are for those transactions at the given block indexes. The numbers that you have match up to sat/byte, not sat/vbyte. I think you aren't calculating the feerates for transactions spending segwit inputs correctly.  
> **username_0**: yes, you are correct. I discovered it like 5 minutes ago while looking at the transactions mentioned above. Thanks!  
> **username_1**: As an aside, I wrote a quick python script to calculate what transactions are packaged together in a given block: https://gist.github.com/achow101/dfb1016f78e653656ec40cd019f8116b. I think it works.  

---

### Answer by username_0 on 2018-04-11. Score: 2

As Andrew Chow pointed out, my feerate calculations were wrong. I used the totalSize of the transaction. Correct would have been to use the virtualSize.

With correct calculations the visualization looks far more as I expected.

[![Block 517361](https://i.sstatic.net/sJ6P1.png)](https://i.sstatic.net/sJ6P1.png)
Block #517361 (compare above)


---

