I guess it should check if any combination of transactions starting from A or B is the next highest fee rate it would include it.
I guess the possible groups could be:
A
B
A-C
B-D
or A-C B-D E
I am assuming whichever of those groups have the highest fees will be included first?
Topic: Why transactions inside blocks are not quite sorted by the fee? (Read 796 times)
August 02, 2017, 04:09:03 AM
oh darn, yes in that case you can't tell if you should group without knowing if it used the txns natural feerate or the package feerate. So much for my simple approximation. 
August 02, 2017, 03:16:12 AM
If I were making graphs like yours, I think I'd logically merge all transactions that have unconfirmed parents into their parents, and show the combined rate. I believe that graph will be monotone.
OK. That would be interesting.
But I don't quite understand how to group them.
For instance I have "parent" transactions A and B - both spend only confirmed inputs.
Then I have:
C - spends input from A
D - spends input from B
E - spends input from both, A and B
Do all five (A, b, C, D, E) end up in one group then?
FWIW, if you think core is doing something-- you can check the getblocktemplate output yourself and remove all doubt!
Achow101 is right about the cause, if you look in the graph you will see a dip to low feerate right before the high feerate spike: thats the parent then its high rate descendant transaction.
You can think of it as logically working like this: if grouping a transaction with its descendants gives a higher feerate for the group than the transaction had, consider including the group. They go in that order... the whole group in its group-feerate order.
If I were making graphs like yours, I think I'd logically merge all transactions that have unconfirmed parents into their parents, and show the combined rate. I believe that graph will be monotone.
Achow101 is right about the cause, if you look in the graph you will see a dip to low feerate right before the high feerate spike: thats the parent then its high rate descendant transaction.
You can think of it as logically working like this: if grouping a transaction with its descendants gives a higher feerate for the group than the transaction had, consider including the group. They go in that order... the whole group in its group-feerate order.
If I were making graphs like yours, I think I'd logically merge all transactions that have unconfirmed parents into their parents, and show the combined rate. I believe that graph will be monotone.
great
thanks
thanks
Thank you, I didn't know about that.
Where is it in the code? Who made it?
I believe this is the PR that made it: https://github.com/bitcoin/bitcoin/pull/7600Where is it in the code? Who made it?
The code should all be in src/miner.cpp.
Thank you, I didn't know about that.
Where is it in the code? Who made it?
Where is it in the code? Who made it?
Bitcoin Core 0.13.0+ (and its derivatives) use a thing called ancestor fee rate ordering. What this does is it takes transactions and their dependencies and groups them together. Then the groups are sorted by their combined fee rate. This results in a generally decreasing fee rate as you go through the transactions in the block, with occasional spikes due to CPFP where a child has a large fee rate, but combined with its parent, is a smaller fee rate so placed further down in the block.
Here you see it even better:
It's a fresh one, mined 5 minutes ago.
And it took ~30 minutes to mine it.
It's a fresh one, mined 5 minutes ago.
And it took ~30 minutes to mine it.
This pattern is very common, across different pools.
I think it's something that bitcoin core must be doing.
Unless some mining software that assembles the blocks is so common as well.
I think it's something that bitcoin core must be doing.
Unless some mining software that assembles the blocks is so common as well.
Many mining pools run their own private code.
There is no requirement for the transactions in the block to be in any particular order (as an exception, I think I recall that if a transaction spends the outputs of another transaction in the same block then it must be later in the block than the transaction whose outputs are being spent).
Miners/pools are allowed by the protocol to use any criteria they want for choosing which transactions to include (so they don't have to include the highest fee per byte transactions if they don't want to), and (other than the exception I listed above) they can order the transaction however they like within the block.
CPFP is a likely reason that you are seeing those spikes. It is possible that paired up transactions (where one spends the outputs of another) are placed next to each other when building the block. It is also possible (though probably unlikely) that the pools are randomly moving some transactions around a bit in the block as an additional method of modifying the merkle root (in addition to simply incrementing the extraNonce).
There is no requirement for the transactions in the block to be in any particular order (as an exception, I think I recall that if a transaction spends the outputs of another transaction in the same block then it must be later in the block than the transaction whose outputs are being spent).
Miners/pools are allowed by the protocol to use any criteria they want for choosing which transactions to include (so they don't have to include the highest fee per byte transactions if they don't want to), and (other than the exception I listed above) they can order the transaction however they like within the block.
CPFP is a likely reason that you are seeing those spikes. It is possible that paired up transactions (where one spends the outputs of another) are placed next to each other when building the block. It is also possible (though probably unlikely) that the pools are randomly moving some transactions around a bit in the block as an additional method of modifying the merkle root (in addition to simply incrementing the extraNonce).
It's not an issue, but I find in intriguing and would like to understand the reason.
When I draw a chart for each block that presents a fee (in SPB), in relation to how far the tx was placed inside the block, it almost always looks somehow like this:
What I mean is that the chart in general goes form the highest SPB to the lowest one. - which is understandable.
But what is strange for me is that it isn't smooth.
There are spikes - in some places inside the block you have a tx whose fee is "too high" for that place, but that is sort of compensated by a tx placed next to it whose fee is to low to end up there.
So what is the reason for placing the txs like this?
Is it because of the Child Pays for Parent feature, or is it something else?
Sorry, I know I can figure it out by reading the code, but hope that someone can just help me here.
I mean, by referring me to the specific code that is responsible for this behaviour.
When I draw a chart for each block that presents a fee (in SPB), in relation to how far the tx was placed inside the block, it almost always looks somehow like this:
What I mean is that the chart in general goes form the highest SPB to the lowest one. - which is understandable.
But what is strange for me is that it isn't smooth.
There are spikes - in some places inside the block you have a tx whose fee is "too high" for that place, but that is sort of compensated by a tx placed next to it whose fee is to low to end up there.
So what is the reason for placing the txs like this?
Is it because of the Child Pays for Parent feature, or is it something else?
Sorry, I know I can figure it out by reading the code, but hope that someone can just help me here.
I mean, by referring me to the specific code that is responsible for this behaviour.
Jump to: