As a block fills it may not be possible to include both a transaction and its successor. In these cases the successor will be skipped for a lower ranked transaction which may have a lower feerate. Because of this it is preferable to choose the larger package first.
In feerate ties, prefer larger packages first. #9886
pull gmaxwell wants to merge 1 commits into bitcoin:master from gmaxwell:prefer_bigger_packages changing 1 files +16 −4-
gmaxwell commented at 5:31 AM on February 28, 2017: contributor
-
10f42bab4f
In feerate ties, prefer larger packages first.
As a block fills it may not be possible to include both a transaction and its successor. In these cases the successor will be skipped for a lower ranked transaction which may have a lower feerate. Because of this it is preferable to choose the larger package first.
-
gmaxwell commented at 5:32 AM on February 28, 2017: contributor
At least I believe this is true, I haven't tested it. (Edit: Darn, checked the rpc tests for tests I needed to update, but not test-bitcoin)
- MarcoFalke added the label TX fees and policy on Feb 28, 2017
- MarcoFalke added the label Mempool on Feb 28, 2017
-
sdaftuar commented at 2:24 PM on February 28, 2017: member
I'll take a look. My recollection from when I was working on this before is that this won't make much difference (because at the end of the block heuristics like this are basically random), but I could be mistaken.
There is another change to the sort that I intended to propose/test, which is to set the ancestor feerate score for a tx to be the min(feerate, feerate with ancestors) -- this would be analogous to what we do for descendant feerate sorting (where we use max(feerate, feerate with descendants). My hypothesis is that we'd get a small performance boost by not having to re-sort low-fee children of high-fee parents when the parent was selected for inclusion. (Also it might make the ancestor feerate score more useful for other heuristics, too...)
-
sdaftuar commented at 8:24 PM on March 2, 2017: member
I ran a couple of simulations on the first week of December (2016). I tested this similarly to what I've done before: call CNB every 100 transactions and log the results, and then look at the last invocation to CNB before each actual block on the network.
I compared the fees generated by the existing strategy versus this one, and over the 1061 blocks in my sample period, the grand total of additional fee generated by this PR is 57261 satoshis, and this algorithm isn't strictly better. (914 of the blocks had identical fees; of the remainder, 93 were better in this PR, and 54 were better using the existing algorithm.)
So while it is possible that on average this algorithm may be ever-so-slightly better than what we have, I don't know that this is a change worth making given how tiny the measured effect is...
-
gmaxwell commented at 5:35 PM on May 30, 2017: contributor
closing due to sdaftuar's measurements. Thanks!
- gmaxwell closed this on May 30, 2017
- DrahtBot locked this on Sep 8, 2021
