This data is also distorted by huge floods of 'free' pool payment transactions which have fast/instant confirmation because they're minded by the paying pool, and by huge floods of other kinds of transactions that have fees which see higher delays because they are specifically blocked by some pools because they use the blockchain inefficiently.
If these things were filtered out the results may be somewhat different.
Topic: No Fee-transactions take longer - Myth?? (Read 1214 times)
Transactions either require a fee (because they are small or the coins aren't aged long enough) or they don't require a fee.
Any analysis of fees should take into consideration (and discount) satoshidice transactions, as they are generally a house-of-cards, where one transaction relies on previously relayed coins that have no confirmations, these will languish until the original transactions are confirmed regardless of fee included. For example there is a transaction that has paid double the required fee but has not been included because it is funded by several other transactions which are also not confirmed.
The inclusion of "free" transactions in blocks is up to miners (pools). Here is some of the parameters a pool can alter without needing to alter the Bitcoin client:
We should first look at how Bitcoin handles transactions that require a fee but don't include it (which can only be sent with an altered Bitcoin). The parameter "minimum block size" is a default value of zero, meaning no transactions not including the minimum per-kb fee will be included. If this is raised to a much higher value by a pool, this means that even spammy free transactions can be included anytime the block is smaller than this minimum after including all normal transactions. No pool I know of alters this (without some further code changes) because it just provides a free way to spam the blockchain with no benefit to anyone but the sender. Only pools like Eligius allow for some free small transactions, using their own rules, transactions that other Bitcoin peers generally won't even relay.
Then lets examine how transactions that qualify to be free are handled: there is a "free transaction" window of 27KB (of a maximum block size of 500K). This is what makes high-priority transactions free. However, they must still compete for just a small part of a block with other high-priority transactions, ranked in order of priority, but this space reserved for high-priority transactions is rarely full, meaning that high-priority non-fee transactions are almost always included in the next block. The Bitcoin client doesn't even prompt for a fee when sending a high-priority transaction.
Finally there are normal transactions, these are ones that pay at least the minimum fee as required. As of 0.7.0 (when run by a pool), they are sorted by fee, so that ones that pay more than the required fee are ranked more highly than minimum-fee-payers. This "paid" area also can include high-priority transactions that have volunteered a fee.
In conclusion, one must properly analyze all available information about a transaction (priority, size, time relayed, funding source) before evaluating the effectiveness of paying more fees. However, one can simply examine the default rules of Bitcoin to determine if volunteering more fee is of benefit.
Any analysis of fees should take into consideration (and discount) satoshidice transactions, as they are generally a house-of-cards, where one transaction relies on previously relayed coins that have no confirmations, these will languish until the original transactions are confirmed regardless of fee included. For example there is a transaction that has paid double the required fee but has not been included because it is funded by several other transactions which are also not confirmed.
The inclusion of "free" transactions in blocks is up to miners (pools). Here is some of the parameters a pool can alter without needing to alter the Bitcoin client:
Code:
-blockminsize=Set minimum block size in bytes (default: 0)
-blockprioritysize=Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)
We should first look at how Bitcoin handles transactions that require a fee but don't include it (which can only be sent with an altered Bitcoin). The parameter "minimum block size" is a default value of zero, meaning no transactions not including the minimum per-kb fee will be included. If this is raised to a much higher value by a pool, this means that even spammy free transactions can be included anytime the block is smaller than this minimum after including all normal transactions. No pool I know of alters this (without some further code changes) because it just provides a free way to spam the blockchain with no benefit to anyone but the sender. Only pools like Eligius allow for some free small transactions, using their own rules, transactions that other Bitcoin peers generally won't even relay.
Then lets examine how transactions that qualify to be free are handled: there is a "free transaction" window of 27KB (of a maximum block size of 500K). This is what makes high-priority transactions free. However, they must still compete for just a small part of a block with other high-priority transactions, ranked in order of priority, but this space reserved for high-priority transactions is rarely full, meaning that high-priority non-fee transactions are almost always included in the next block. The Bitcoin client doesn't even prompt for a fee when sending a high-priority transaction.
Finally there are normal transactions, these are ones that pay at least the minimum fee as required. As of 0.7.0 (when run by a pool), they are sorted by fee, so that ones that pay more than the required fee are ranked more highly than minimum-fee-payers. This "paid" area also can include high-priority transactions that have volunteered a fee.
In conclusion, one must properly analyze all available information about a transaction (priority, size, time relayed, funding source) before evaluating the effectiveness of paying more fees. However, one can simply examine the default rules of Bitcoin to determine if volunteering more fee is of benefit.
It seems that it doesnt matter and quite to the contrary even impede your chances of quick confirmations if you include a fee into your transaction.
Thoughts?
Before trying to conclude anything from this graph, you need to remember why fees were or were not paid. A strong majority of the transactions were likely made by clients that either require or highly suggest that you pay a fee only when the transaction would otherwise take a long time.Thoughts?
A proper analysis would show time in terms of blocks and would use only their own pairs of transactions that have the same/similar priority when their isn't a fee where one of the pair is submitted with a fee and the other isn't.
It is unclear what y-axis refers to. It shows values up to several thousands of BTC, surely these are not transaction fees.
A histogram would be a more useful view.
"Drag a box to zoom."
Given the resolution of the chart, I can't make a determination. Too much overlap in the blue "fee paid" area to tell what percentage of transactions were comfirmed within any given time frame under 50 minutes.
Perhaps a simpler bar chart with less noise would make the point better.
Perhaps a simpler bar chart with less noise would make the point better.
http://bitcoinstats.org/
It seems that it doesnt matter and quite to the contrary even impede your chances of quick confirmations if you include a fee into your transaction.
Thoughts?
Jump to: