Bitcoin Forum
May 10, 2024, 03:23:42 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Analysis of Bitcoin transaction rates  (Read 1037 times)
davejh (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
November 03, 2014, 11:34:02 AM
 #1

I've not had much time to post any Bitcoin stats recently, but I finally got time to do a write-up on transaction rates:

http://hashingit.com/analysis/33-7-transactions-per-second

I've been looking at just how many typical transactions can be processed per second and at whether the frequently quoted 7 TPS number has any value (it doesn't appear to anymore). I've also been looking at the rate of growth in transaction rates, average block sizes and that Bitcoin transaction processing seems to like to take a rest on Sundays Cheesy
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715311422
Hero Member
*
Offline Offline

Posts: 1715311422

View Profile Personal Message (Offline)

Ignore
1715311422
Reply with quote  #2

1715311422
Report to moderator
1715311422
Hero Member
*
Offline Offline

Posts: 1715311422

View Profile Personal Message (Offline)

Ignore
1715311422
Reply with quote  #2

1715311422
Report to moderator
1715311422
Hero Member
*
Offline Offline

Posts: 1715311422

View Profile Personal Message (Offline)

Ignore
1715311422
Reply with quote  #2

1715311422
Report to moderator
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
November 03, 2014, 01:07:53 PM
 #2

Nice analysis.

Comments while reading: Size of a TX varies, thus the TX per Block and Blocksize comparison lacks information. The 7 TPS claim refers to a single input and a single output AFAIK. I am also pretty sure I remember a comment about the size of a TX -with one input and one output- beeing reduced a while ago.

After reading: Yes we are heading towards problems as the various discussions about max_blocksize suggests as well.

On the other hand I see the amount of unconfirmed TX going down:



Im not really here, its just your imagination.
davejh (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
November 03, 2014, 02:41:43 PM
 #3

Nice analysis.

Thanks!

Comments while reading: Size of a TX varies, thus the TX per Block and Blocksize comparison lacks information. The 7 TPS claim refers to a single input and a single output AFAIK. I am also pretty sure I remember a comment about the size of a TX -with one input and one output- beeing reduced a while ago.

Yes. I've already got a "to do" item which is to take a detailed look at the types of transactions, not just the overall volumes as I can imagine quite a number of scenarios that may follow. I had already got some prelim analysis on the sizes of blocks following large inter-block confirmation times but that's currently too qualitative for my liking right now.

After reading: Yes we are heading towards problems as the various discussions about max_blocksize suggests as well.

On the other hand I see the amount of unconfirmed TX going down:




I'd actually be pretty surprised if this wasn't happening right now. I think pretty-much all mining pools are draining the system of every transaction they can, and as the network efficiency improves then they're getting quite efficient at doing it. The thing I'd really like to look at is what happens near very large blocks (there was one almost 1 Mbyte recently) and see if anyone is actually expressing a significant preference for fees. There may not actually be enough data yet, but I suspect there will be soon.
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
November 03, 2014, 03:00:20 PM
 #4

-snip-

Yes. I've already got a "to do" item which is to take a detailed look at the types of transactions, not just the overall volumes as I can imagine quite a number of scenarios that may follow. I had already got some prelim analysis on the sizes of blocks following large inter-block confirmation times but that's currently too qualitative for my liking right now.

Not sure if thats possible afterwards, but I would be very interessted to see the priority for transactions and/or the fee paid per KByte. I am actually working on something like that currently, but my server is to weak to do it. Might be good to use historical data like you did.

-snip-
I'd actually be pretty surprised if this wasn't happening right now. I think pretty-much all mining pools are draining the system of every transaction they can, and as the network efficiency improves then they're getting quite efficient at doing it. The thing I'd really like to look at is what happens near very large blocks (there was one almost 1 Mbyte recently) and see if anyone is actually expressing a significant preference for fees. There may not actually be enough data yet, but I suspect there will be soon.

I suspect something similar, but was told that most miners use bitcoin core. Yet, if you look at the number of unconfirmed transactions and how small some of the blocks are this does not add up. Thats why Id like to see some more information about the priority of the transactions that get confirmed, because fees are not the only factor that matters.

Im not really here, its just your imagination.
davejh (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
November 03, 2014, 04:12:29 PM
 #5

-snip-

Yes. I've already got a "to do" item which is to take a detailed look at the types of transactions, not just the overall volumes as I can imagine quite a number of scenarios that may follow. I had already got some prelim analysis on the sizes of blocks following large inter-block confirmation times but that's currently too qualitative for my liking right now.

Not sure if thats possible afterwards, but I would be very interessted to see the priority for transactions and/or the fee paid per KByte. I am actually working on something like that currently, but my server is to weak to do it. Might be good to use historical data like you did.

If nothing else the historical data should indicate potential changes. Certainly my qualitative analysis a few weeks ago showed that more than 50% of the largest 20 blocks seen on the network at that point had followed inter-block gaps of 50+ minutes (and those sizes of gaps are pretty common of course). This makes sense of course but what I didn't get to look at was any fee distributions for the big block and any immediately subsequent block. As we get closer to filling more blocks though then this will really start to skew things.

I didn't really try to look at this yesterday (I was writing on a plane so didn't have any connectivity to look things up) but given hashing distributions any day where our mean block size is up around 40% of the maximum is highly likely to start seeing blocks where all of the available transactions won't fit in the "next" block and we'll see longer-term trends starting to appear.

-snip-
I'd actually be pretty surprised if this wasn't happening right now. I think pretty-much all mining pools are draining the system of every transaction they can, and as the network efficiency improves then they're getting quite efficient at doing it. The thing I'd really like to look at is what happens near very large blocks (there was one almost 1 Mbyte recently) and see if anyone is actually expressing a significant preference for fees. There may not actually be enough data yet, but I suspect there will be soon.

I suspect something similar, but was told that most miners use bitcoin core. Yet, if you look at the number of unconfirmed transactions and how small some of the blocks are this does not add up. Thats why Id like to see some more information about the priority of the transactions that get confirmed, because fees are not the only factor that matters.

Some of this may be down to network effects; not all nodes may have seen all transactions at some particular instant.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!