1

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 Block #517361 mined by ViaBTC (?)

Block 517363 Block #517363 mined by BTC.TOP (?)

Block 517357 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?

Improve this question
2

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

Improve this answer
4
  • 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 Apr 10 '18 at 16:06
  • 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. – Andrew Chow♦ Apr 10 '18 at 18:06
  • yes, you are correct. I discovered it like 5 minutes ago while looking at the transactions mentioned above. Thanks! – 0xb10c Apr 10 '18 at 18:08
  • 1
    As an aside, I wrote a quick python script to calculate what transactions are packaged together in a given block: gist.github.com/achow101/dfb1016f78e653656ec40cd019f8116b. I think it works. – Andrew Chow♦ Apr 10 '18 at 18:09
1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.