Not sure if this sheds any light on the block size effects of various pools, but here is
a recent snapshot of blocks. What I do not understand is how the Eligius miner created such a small block when there were over 1200 unconfirmed transactions in the mem pool. Direct link: http://i.imgur.com/S29IMDg.png
http://i.imgur.com/S29IMDg.png
Topic: I know this has been brought up before, but confirmation times are getting weird - page 4. (Read 10064 times)
November 16, 2013, 09:51:51 AM
November 16, 2013, 05:36:57 AM
That is a flawed understanding of the fee rules. High priority txs have no required fee, none. As in 0 satsohis. This applies regardless if a block is 1MB in size.
The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
I don't think this is correct. Under the Satoshi client's fee rules (which as I understand are enforced by most, but certainly not all, miners), high priority transactions with no fees will only be included in the first 27 kB of a block (this limit can be changed with the blockprioritysize option). Once the block hits this limit, only fee-paying transactions will be included, regardless of priority.The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
FWIW all my transactions are high priority ones and I've observed a steep increase in confirmation times, going up to nine hours in some cases, when their priority reaches several thousand million.
November 16, 2013, 04:10:44 AM
That is a flawed understanding of the fee rules. High priority txs have no required fee, none. As in 0 satsohis. This applies regardless if a block is 1MB in size.
The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
I don't think this is correct. Under the Satoshi client's fee rules (which as I understand are enforced by most, but certainly not all, miners), high priority transactions with no fees will only be included in the first 27 kB of a block (this limit can be changed with the blockprioritysize option). Once the block hits this limit, only fee-paying transactions will be included, regardless of priority.The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
Blocks are not getting full, average block size is 100 - 150kb at the moment from what I see in the last couple of blocks. This means there probably are more zero fee TXs than what can fit into the 27kb area of blocks.
edit: it's the weekend, so maybe blocks really are becoming large. Average block size comes somewhat close to 250k:
http://blockchain.info/de/charts/avg-block-size?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
November 16, 2013, 12:12:32 AM
That is a flawed understanding of the fee rules. High priority txs have no required fee, none. As in 0 satsohis. This applies regardless if a block is 1MB in size.
The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
I don't think this is correct. Under the Satoshi client's fee rules (which as I understand are enforced by most, but certainly not all, miners), high priority transactions with no fees will only be included in the first 27 kB of a block (this limit can be changed with the blockprioritysize option). Once the block hits this limit, only fee-paying transactions will be included, regardless of priority.The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
Lastly the rules aren't enforced at the protocol level. Miners an build any valid block they want by using custom bitcoind. This is hardly beyond the capabilities of a major pool (all are using custom nodes already). It is possible to have a block contain NOTHING but no fee txs (as in ~2,400 of them) and the block is still valid.
True, but hardly relevant unless a significant fraction of miners are using non-standard fee rules. A few do (which is the only reason transactions paying insufficient fees are ever confirmed at all), but I'm pretty sure most do not. November 15, 2013, 11:19:37 PM
The way I see it their are three possible sources for the recent change.
1) One or more of the large mining pools has changed how it mines recently
2) The transactions mix has radically, changed such as a very high volume of 0 fee transactions being attempted recently
3) The network communications have been disrupted in some way such that transactions are taking longer to reach miners
My naive guess is that the Chinese have 'discovered' that the transaction fee is optional and one of their trading sites/forums etc has caused a massive increase in 0 fee transactions being attempted. If this is the case then they will probably only take a few more days of slowness for them to realize that the fee isn't so optional and they will cut it out. If it's something else then it may be the new normal.
1) One or more of the large mining pools has changed how it mines recently
2) The transactions mix has radically, changed such as a very high volume of 0 fee transactions being attempted recently
3) The network communications have been disrupted in some way such that transactions are taking longer to reach miners
My naive guess is that the Chinese have 'discovered' that the transaction fee is optional and one of their trading sites/forums etc has caused a massive increase in 0 fee transactions being attempted. If this is the case then they will probably only take a few more days of slowness for them to realize that the fee isn't so optional and they will cut it out. If it's something else then it may be the new normal.
+3
Well, in any case, now that people are starting to feel the pain of slower transaction confirmations it will be interesting to see how both miners and users respond (who will give first... the miners by creating larger blocks, as D&T pointed out, or the users [who care about tx confirmation times in the first place] by paying higher fees).
November 15, 2013, 11:09:11 PM
The way I see it their are three possible sources for the recent change.
1) One or more of the large mining pools has changed how it mines recently
2) The transactions mix has radically, changed such as a very high volume of 0 fee transactions being attempted recently
3) The network communications have been disrupted in some way such that transactions are taking longer to reach miners
My naive guess is that the Chinese have 'discovered' that the transaction fee is optional and one of their trading sites/forums etc has caused a massive increase in 0 fee transactions being attempted. If this is the case then they will probably only take a few more days of slowness for them to realize that the fee isn't so optional and they will cut it out. If it's something else then it may be the new normal.
1) One or more of the large mining pools has changed how it mines recently
2) The transactions mix has radically, changed such as a very high volume of 0 fee transactions being attempted recently
3) The network communications have been disrupted in some way such that transactions are taking longer to reach miners
My naive guess is that the Chinese have 'discovered' that the transaction fee is optional and one of their trading sites/forums etc has caused a massive increase in 0 fee transactions being attempted. If this is the case then they will probably only take a few more days of slowness for them to realize that the fee isn't so optional and they will cut it out. If it's something else then it may be the new normal.
November 15, 2013, 10:48:38 PM
Maybe I should change the title of this thread... you are addressing something that I feel is quite off-topic. I just wanted to have a discussion over what dynamics changed after Nov. 3, 2013 -- not a general discussion about transaction fees and confirmation times.
So far the hypotheses are that Elgius changed how they prioritize transactions based on address reuse and that we hit recently hit a threshold of transactions broadcast per day (due to the growing adoption of Bitcoin).
This is what I'm talking about. I didn't bother mentioning it because it's already been explained several times in this thread. I was merely elaborating on why, with a sufficiently large number of transactions, many of those transactions will not get into a block, even though the block size is nowhere near the limit and the transactions pay the minimum required fee. The minimum fee is not sufficient if a block is more than a quarter full. If nobody ever pays more than the minimum fee, blocks will never be more than a quarter full, leading people to ask "why is there a huge backlog of fee-paying transactions when the blocks are nowhere near full?" And now you know. And knowing is half the battle.So far the hypotheses are that Elgius changed how they prioritize transactions based on address reuse and that we hit recently hit a threshold of transactions broadcast per day (due to the growing adoption of Bitcoin).
That is a flawed understanding of the fee rules. High priority txs have no required fee, none. As in 0 satsohis. This applies regardless if a block is 1MB in size.
The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
Lastly the rules aren't enforced at the protocol level. Miners an build any valid block they want by using custom bitcoind. This is hardly beyond the capabilities of a major pool (all are using custom nodes already). It is possible to have a block contain NOTHING but no fee txs (as in ~2,400 of them) and the block is still valid.
November 15, 2013, 10:01:35 PM
Maybe I should change the title of this thread... you are addressing something that I feel is quite off-topic. I just wanted to have a discussion over what dynamics changed after Nov. 3, 2013 -- not a general discussion about transaction fees and confirmation times.
So far the hypotheses are that Elgius changed how they prioritize transactions based on address reuse and that we hit recently hit a threshold of transactions broadcast per day (due to the growing adoption of Bitcoin).
This is what I'm talking about. I didn't bother mentioning it because it's already been explained several times in this thread. I was merely elaborating on why, with a sufficiently large number of transactions, many of those transactions will not get into a block, even though the block size is nowhere near the limit and the transactions pay the minimum required fee. The minimum fee is not sufficient if a block is more than a quarter full. If nobody ever pays more than the minimum fee, blocks will never be more than a quarter full, leading people to ask "why is there a huge backlog of fee-paying transactions when the blocks are nowhere near full?" And now you know. And knowing is half the battle. So far the hypotheses are that Elgius changed how they prioritize transactions based on address reuse and that we hit recently hit a threshold of transactions broadcast per day (due to the growing adoption of Bitcoin).
November 15, 2013, 09:45:21 PM
Code:
// Free transaction area
if (nNewBlockSize < 27000)
nMinFee = 0;
By default the client reserves 27kb for free high priority transactions. if (nNewBlockSize < 27000)
nMinFee = 0;
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
Code:
// Raise the price as the block approaches full
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Also it will raise the minFee once blocksize becomes larger than 250kb.if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Of course miners can change this.
People, pay the fucking transaction fees. If your transaction is taking a long time to confirm and you paid no fee, or only the minimum required fee, it's your own damn fault.
Maybe I should change the title of this thread... you are addressing something that I feel is quite off-topic. I just wanted to have a discussion over what dynamics changed after Nov. 3, 2013 -- not a general discussion about transaction fees and confirmation times.
So far the hypotheses are that Elgius changed how they prioritize transactions based on address reuse and that we hit recently hit a threshold of transactions broadcast per day (due to the growing adoption of Bitcoin).
November 15, 2013, 09:24:53 PM
Code:
// Free transaction area
if (nNewBlockSize < 27000)
nMinFee = 0;
By default the client reserves 27kb for free high priority transactions. if (nNewBlockSize < 27000)
nMinFee = 0;
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
Code:
// Raise the price as the block approaches full
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Also it will raise the minFee once blocksize becomes larger than 250kb.if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Of course miners can change this.
People, pay the fucking transaction fees. If your transaction is taking a long time to confirm and you paid no fee, or only the minimum required fee, it's your own damn fault.
November 15, 2013, 08:20:03 PM
I also have noticed a problem when I was using the bitcoin atm machine i went there and my confirmation came instantly but the next day it took my 10 minutes to get my 1 confirmation from block chain
Block chain usually takes 10 minutes at most to confirm a good transaction.
You were just lucky on the first day (making your transaction just before a block) and unlucky on the second (making your transaction just AFTER a block)
November 15, 2013, 08:14:43 PM
I also have noticed a problem when I was using the bitcoin atm machine i went there and my confirmation came instantly but the next day it took my 10 minutes to get my 1 confirmation from block chain
November 15, 2013, 05:21:54 PM
Anyone knows if Eligius is still doing zero-fee transactions?
As far as I know, they have always required a fee of 4096 Satohies.
November 15, 2013, 05:00:13 PM
That's it, right here. The block only permits a limited amount of zero fee transactions to be included, and any additional transactions must meet the criteria for the fee schedule to be included into a block.
That is not correct. A miner could make every block 1MB ~2,400 tx only include the free ones and exclude every paying tx if they wanted. Not saying they would (it would be stupid) or they should but they could. Saying the "block" prevents them is a cop out.
Miners decide what tx to include in a block. The only thing which can't be included in a block is an invalid tx, or a sum of tx greater than 1MB in size.
I was generallizing. I know that miners can choose their own rules, but the default set of rules say that there is a limit to the free transactions. Changing those rules requires programming skill and the desire to do so.
November 15, 2013, 04:38:59 AM
Code:
// Free transaction area
if (nNewBlockSize < 27000)
nMinFee = 0;
By default the client reserves 27kb for free high priority transactions. if (nNewBlockSize < 27000)
nMinFee = 0;
Code:
/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIZE = 1000000;
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
Code:
// Raise the price as the block approaches full
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Also it will raise the minFee once blocksize becomes larger than 250kb.if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY;
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
Of course miners can change this.
November 15, 2013, 02:13:53 AM
I believe in that graph you are looking at transactions processed per day, which, of course, will show a constant number given the saturation condition we are talking about.
Assume the number of "transactions to the popular addresses" is constant then a jump in transactions to the other "not popular" addresses shows that now we have more transactions being requested than are being processed by the system.
This will cause a backlog - at about the time the confirmation time increased.
Assume the number of "transactions to the popular addresses" is constant then a jump in transactions to the other "not popular" addresses shows that now we have more transactions being requested than are being processed by the system.
This will cause a backlog - at about the time the confirmation time increased.
November 15, 2013, 01:57:40 AM
I don't understand why our communication is breaking down so much. I can tell that we're both trying to tell each other something, but it isn't working.
I completely understand the general mechanics of transaction backlogs and I very much appreciate your explaining them in detail. The point of my starting this thread was to wonder what event/dynamic/new-mining-pool/whatever occurred on Nov. 3, 2013 such that, since that date, the confirmation times have gone up significantly.
My apologies in advance if I am somehow misunderstanding you.
I completely understand the general mechanics of transaction backlogs and I very much appreciate your explaining them in detail. The point of my starting this thread was to wonder what event/dynamic/new-mining-pool/whatever occurred on Nov. 3, 2013 such that, since that date, the confirmation times have gone up significantly.
My apologies in advance if I am somehow misunderstanding you.
Could it be as simple as the total number of transactions per day crossing a threshold where the backlog starts to happen, given a flat number of transactions per block.
Notice that about that time the "Number of transactions excluding popular addresses" jumped up and crossed over the 50,000 transactions per day line.
6 * 24 * 350 is about 50K transactions per day.
Yeah, that's a fine hypothesis, but why would popular/non-popular matter? If you look at the total number of transactions over the past year, it has been pretty constant (well, constant is relative, but the important point is that it has been higher in the past).
https://blockchain.info/charts/n-transactions?timespan=1year&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
November 15, 2013, 01:48:23 AM
I don't understand why our communication is breaking down so much. I can tell that we're both trying to tell each other something, but it isn't working.
I completely understand the general mechanics of transaction backlogs and I very much appreciate your explaining them in detail. The point of my starting this thread was to wonder what event/dynamic/new-mining-pool/whatever occurred on Nov. 3, 2013 such that, since that date, the confirmation times have gone up significantly.
My apologies in advance if I am somehow misunderstanding you.
I completely understand the general mechanics of transaction backlogs and I very much appreciate your explaining them in detail. The point of my starting this thread was to wonder what event/dynamic/new-mining-pool/whatever occurred on Nov. 3, 2013 such that, since that date, the confirmation times have gone up significantly.
My apologies in advance if I am somehow misunderstanding you.
Could it be as simple as the total number of transactions per day crossing a threshold where the backlog starts to happen, given a flat number of transactions per block?
Notice that about that time the "Number of transactions excluding popular addresses" jumped up and crossed over the 50,000 transactions per day line.
6 * 24 * 350 is about 50K transactions per day.
November 15, 2013, 01:39:51 AM
(I noticed for example, that Elgius is de-prioritizing transactions that reuse addresses, this is new, and perhaps that is a cause for this)
This will cause the transactions that reuse addresses to be delayed. Is there a way to get a statistic on how many transactions fall into this category (reused therefore being delayed by some of the pools)?
That would be great to find out! Apparently BTC Guild is thinking about doing this too.
November 15, 2013, 01:34:13 AM
Well threshold would imply some sort of cental block planning agency. Various miners have various different block parameters. Tx volume is higher than the block size being created by the various parameters currently used by various miners. Some miners target larger blocks, some target smaller ones, a couple seem to include nothing but the coinbase tx. Collectively all miners have a certain tx throughput which is less than the tx volume and the limit imposed by the 1MB cap.
Miners can either expand the # of tx they include in blocks
OR
Users can collectively reduce tx volume
OR
The backlog will grow
For the time being a way to put yourself at the front of the line is to pay a tx fee but that won't reduce/eliminate the backlog it will just ensure your tx has a higher chance of going first.
Miners can either expand the # of tx they include in blocks
OR
Users can collectively reduce tx volume
OR
The backlog will grow
For the time being a way to put yourself at the front of the line is to pay a tx fee but that won't reduce/eliminate the backlog it will just ensure your tx has a higher chance of going first.
I don't understand why our communication is breaking down so much. I can tell that we're both trying to tell each other something, but it isn't working.
I completely understand the general mechanics of transaction backlogs and I very much appreciate your explaining them in detail. The point of my starting this thread was to wonder what event/dynamic/new-mining-pool/whatever occurred on Nov. 3, 2013 such that, since that date, the confirmation times have gone up significantly.
My apologies in advance if I am somehow misunderstanding you.
Jump to: