Transaction confirmation data

[Gavin Andresen]

I gathered data on transaction first-confirmation times this weekend:

 https://docs.google.com/open?id=0B74FtkFP4j73TXZUY05kSFVzN00

Each line in the file (except the first one) represents one transaction. Each column is:

Number of seconds the transaction spent in the memory pool.

Size, in bytes, of the transaction.

Fees attached to the transaction (in satoshis).

Priority (floating-point number) of the transaction when it first entered the memory pool.  Priority 0.0 transactions have inputs that aren't yet confirmed.

Last column is "1" if the transaction exited the memory pool normally, by being included in the a block, or "0" if the transaction was still in the memory pool when I shut down bitcoind.

--------------

I haven't really analyzed it yet (feel free to help if you're a data geek); I plan on testing some algorithms for suggesting a reasonable fee if you want your transaction to get confirmed quickly, and suggesting an estimate of how long you'll have to wait if you don't attach any fee at all.

But it look like 35% of transactions this past weekend got into a block within 10 minutes, and 87% got into a block within one hour.

[1713574140]

1713574140

[1713574140]

1713574140

[1713574140]

1713574140

[1713574140]

1713574140

[1713574140]

1713574140

[deepceleron]

Unfortunately, rather than "delta time", the data set might be better if the number of blocks until transaction inclusion, and perhaps block size/number of transactions/position ranking at transaction appearance was captured.

Since this is at least 3D data, probably the best way to analyze is to make a few charts separating the data into categories. The plot would be a x/y point chart - fee paid vs time to inclusion.

I would separate the transactions into types and contrast these charts to see if cheap bastards get what they deserve:

- priority < 57.6M; fee paid was less than satoshi client minimum for size
- priority < 57.6M; fee paid was sufficient or greater than minimum required
- priority > 57.6M; zero fee required and zero was paid
- priority > 57.6M; fee paid was sufficient or greater than minimum


As an aside, I am curious about this fee rule from the transaction fee wiki page, and how it affects things (we now have a >1MB transaction queue) - i.e. if it is really implemented and active in current Bitcoin, and if so, the level of transaction activity required to activate the "increasingly more expensive" part (are we there yet?).

"If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.

If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc."

[Atheros]

On that list, I calculated that there were 4302 TXs that paid an insufficient fee for their priority which was 3.7% of the total. If someone double checks that I would appreciate it.

If I look at all transactions on the list:
Fee-paying transaction average confirmation time: 30.3 minutes
Fee-less transaction average confirmation time: 30.73 minutes

If I exclude the transactions that didn't pay a sufficient fee:
Fee-paying transaction average confirmation time: 30.27 minutes
Fee-less transaction average confirmation time: 29.07 minutes

It wasn't this bad before the transaction volume rose. Back then, there was an advantage to paying the fee. But now the fee-payers have to wait just as long.

[wabber]

It wasn't this bad before the transaction volume rose. Back then, there was an advantage to paying the fee. But now the fee-payers have to wait just as long.

Yea but it looks like the ones without a transaction fee have a much higher priority. I think we should increase the importance of the fee compared to the priority for making it into the next block

[galambo]

On that list, I calculated that there were 4302 TXs that paid an insufficient fee for their priority which was 3.7% of the total. If someone double checks that I would appreciate it.

If I look at all transactions on the list:
Fee-paying transaction average confirmation time: 30.3 minutes
Fee-less transaction average confirmation time: 30.73 minutes

If I exclude the transactions that didn't pay a sufficient fee:
Fee-paying transaction average confirmation time: 30.27 minutes
Fee-less transaction average confirmation time: 29.07 minutes

It wasn't this bad before the transaction volume rose. Back then, there was an advantage to paying the fee. But now the fee-payers have to wait just as long.

Can we be sure about this unless we exclude 1dice from the experiment? Many of the mining pools are now ignoring them and I think this could distort the statistic.

[Atheros]

Can we be sure about this unless we exclude 1dice from the experiment? Many of the mining pools are now ignoring them and I think this could distort the statistic.

That's a good idea.
There isn't enough data in this spreadsheet to exclude 1dice.

[Realpra]

What determines the max size of a block?

Won't we need to increase that?

[Prattler]

Transaction confirmation speed is limited by block sizes and block sizes cannot grow due to very slow propagation through the network:

https://bitcointalk.org/index.php?topic=88302.msg975343#msg975343

[jgarzik]

I haven't really analyzed it yet (feel free to help if you're a data geek); I plan on testing some algorithms for suggesting a reasonable fee if you want your transaction to get confirmed quickly, and suggesting an estimate of how long you'll have to wait if you don't attach any fee at all.

But it look like 35% of transactions this past weekend got into a block within 10 minutes, and 87% got into a block within one hour.

The most interesting analysis will be on what types of transactions (big, small, SD, non-SD, fee, no fee, priority) got into a block within 10 minutes or so.  If that 65% [who didn't make it in one block] is spammy, that might be normal.