Where does this pattern in the feerate distribution per block originate from?

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, 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 mined by ViaBTC (?)

Block #517363 mined by BTC.TOP (?)

Block #517357 mined by BTC.com (?)

and here 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?

0xb10c

Posted 2018-04-10T14:49:07.690

Reputation: 953

Answers

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.

Andrew Chow

Posted 2018-04-10T14:49:07.690

Reputation: 40 910

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. (305sat/B + 19sat/B)/31tx would be later in the block. – 0xb10c – 2018-04-10T16:06:26.307

1I 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. – Andrew Chow – 2018-04-10T18:06:08.533

yes, you are correct. I discovered it like 5 minutes ago while looking at the transactions mentioned above. Thanks! – 0xb10c – 2018-04-10T18:08:08.133

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.

– Andrew Chow – 2018-04-10T18:09:37.960

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 (compare above)

0xb10c

Posted 2018-04-10T14:49:07.690

Reputation: 953