Bitcoin Forum
December 04, 2016, 04:37:08 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transaction confirmation data  (Read 1012 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
June 18, 2012, 01:41:34 PM
 #1

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.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480869428
Hero Member
*
Offline Offline

Posts: 1480869428

View Profile Personal Message (Offline)

Ignore
1480869428
Reply with quote  #2

1480869428
Report to moderator
1480869428
Hero Member
*
Offline Offline

Posts: 1480869428

View Profile Personal Message (Offline)

Ignore
1480869428
Reply with quote  #2

1480869428
Report to moderator
1480869428
Hero Member
*
Offline Offline

Posts: 1480869428

View Profile Personal Message (Offline)

Ignore
1480869428
Reply with quote  #2

1480869428
Report to moderator
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
June 18, 2012, 04:00:41 PM
 #2

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
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
June 18, 2012, 05:09:33 PM
 #3

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.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
wabber
Member
**
Offline Offline

Activity: 85


View Profile
June 19, 2012, 01:52:58 AM
 #4

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
Sr. Member
****
Offline Offline

Activity: 390



View Profile
June 19, 2012, 01:56:46 AM
 #5

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
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
June 19, 2012, 06:17:36 AM
 #6

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.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
Realpra
Hero Member
*****
Offline Offline

Activity: 819


View Profile
June 19, 2012, 08:07:57 AM
 #7

What determines the max size of a block?

Won't we need to increase that?

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
Prattler
Full Member
***
Offline Offline

Activity: 192


View Profile
June 19, 2012, 07:47:16 PM
 #8

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
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
June 20, 2012, 12:20:51 AM
 #9

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!