-
Notifications
You must be signed in to change notification settings - Fork 35.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When creating new blocks, sort 'paid' area by fee-per-kb #1590
Conversation
Does this include the improvements in #1240? |
@luke-jr : no, it doesn't include anything from #1240. The steps towards better fee handling, as I see them, are:
|
#1240 does both 1 and 3, and is well-tested... |
Reworked a little bit after getting some feedback from the big mining pools (added options -maxblocksize and -maxfreesize). @luke-jr : I spent most of today looking carefully at how your proposed priority mechanism (the age_weight1 + fee_weight2 formula) and this one actually behave with the transactions that are in the main network's memory pool right now (I implemented just the "change the priority calculation" part of #1240 and ran it). And I came to the conclusion that with your scheme it will be hard to get the weights right, and miners will have no idea what they're trading off if we give them the ability to fiddle with the weights. I wrote the code, and couldn't predict how many free transactions would be included in a block if I made weight1=1 and weight2=1000. I like this method better; it is clear what will happen if you set -maxblocksize=50000 and -maxfreesize=10000 (defaults are 250,000 and 27,000 which match the behavior of previous releases). |
How can I, with this version, prioritize by fee alone (only using age when fee is identical) and still include as many free transactions as possible? |
@luke-jr : you can't. Prioritizing by fee alone is too easy to game (spammer includes a 1-satoshi fee with all their transactions and crowds out all the zero-fee transactions). Sorting by significantly-greater-than-zero-fee first, and then filling up to -maxblocksize with free transactions would also be easy to game (just send lots of zero-priority zero-fee transactions to make the miner always create -maxblocksize blocks). Or all the SatoshiDice fee-paying transactions would crowd out old clients that expect that their high-priority free transactions will get into a block eventually. |
@luke-jr : I think we could safely get the behavior you want by introducing another parameter: lets call it -blockminsize. The rules would then be: You'd set -blockprioritysize=0, and set -blockmaxsize and -blockminsize to the size of blocks you want to create, and you'll get always-sorted-by-fee, include-free-if-there-is-extra-room. Depending on your block size, I believe these days your blocks would contain no free transactions, though, due to all the SatoshiDice fee-paying return transactions. My only concern is that three different sizes is a lot of knobs to explain. |
Better to have undocumented options, than not have them at all because they're too hard to document. IMO. |
Implemented -blockminsize, and cleaned up the implementation (use std::heap for the priority queue). Behavior with default values on the network right now looks reasonable; blocks have a dozen or so high-priority transactions, then are filled with fee-paying transactions. Blocks created are between 60 and 100K big |
ACK |
Modify CreateNewBlock so that instead of processing all transactions in priority order, process the first 27K of transactions in priority order and then process the rest in fee-per-kilobyte order. This is the first, minimal step towards better a better fee-handling system for both miners and end-users; this patch should be easy to backport to the old versions of Bitcoin, and accomplishes the most important goal-- allow users to "buy their way in" to blocks using transaction fees.
Modify CreateNewBlock so that instead of processing all transactions in priority order, process the first 27K of transactions in priority order and then process the rest in fee-per-kilobyte order. bitcoin#1590 Also added IsTOROnly().
036a7b1 [GUI] Update translations from Transifex for 4.1 (Fuzzbawls) Pull request description: Pulls all translations for languages at or above 80% completion. Since this is the first time we've used a minimum completion threshold, this also removes all languages with less than 80% completion. ACKs for top commit: furszy: utACK 036a7b1 random-zebra: utACK 036a7b1 Tree-SHA512: ca95b990e6a6b3ea2cb2767bcb19ff66f5080221bf2195d4bd48abb05f3bf72e945f50578a48ba39bd5eb90cbc00b22e5df6c2c0517efb132826ff891da204d4
Modify CreateNewBlock so that instead of processing all transactions
in priority order, process the first 27K of transactions in
priority order and then process the rest in fee-per-kilobyte
order.
This is the first, minimal step towards better a better fee-handling
system for both miners and end-users; this patch should be easy
to backport to the old versions of Bitcoin, and accomplishes the
most important goal-- allow users to "buy their way in" to blocks
using transaction fees.
Four params give miners control over the transaction selection process:
-blockmaxsize : maximum size of blocks created (default: 250000)
-blockprioritysize : how much of the block to set aside for high-priority-maybe-free transactions (default: 27000)
-blockminsize : minimum size of blocks created (default: 0)
-mintxfee : transactions that pay below this many bitcoins-per-kilobyte are considered "free" (default: 0.0005)
Discussion thread in the Mining forums: https://bitcointalk.org/index.php?topic=95837