Bitcoin Forum
February 07, 2023, 05:37:36 PM *
News: Community Awards results
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Number of transaction each second  (Read 748 times)
Itcher (OP)
Full Member
***
Offline Offline

Activity: 364
Merit: 100



View Profile
July 11, 2013, 04:15:46 PM
 #1

Hi everyone,

if this has been discussed before please give me a link.

Someone said, the BTC-Network is unable to master more than seven transaction each second. Is this true? And why?

Thank you.
1675791456
Hero Member
*
Offline Offline

Posts: 1675791456

View Profile Personal Message (Offline)

Ignore
1675791456
Reply with quote  #2

1675791456
Report to moderator
1675791456
Hero Member
*
Offline Offline

Posts: 1675791456

View Profile Personal Message (Offline)

Ignore
1675791456
Reply with quote  #2

1675791456
Report to moderator
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675791456
Hero Member
*
Offline Offline

Posts: 1675791456

View Profile Personal Message (Offline)

Ignore
1675791456
Reply with quote  #2

1675791456
Report to moderator
1675791456
Hero Member
*
Offline Offline

Posts: 1675791456

View Profile Personal Message (Offline)

Ignore
1675791456
Reply with quote  #2

1675791456
Report to moderator
1675791456
Hero Member
*
Offline Offline

Posts: 1675791456

View Profile Personal Message (Offline)

Ignore
1675791456
Reply with quote  #2

1675791456
Report to moderator
hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1007


View Profile
July 12, 2013, 07:55:40 AM
 #2

Because block size is limited, and there is ~1 block per 10 minutes. 

10 minutes is 600s.  1000kb / 600s ~  2kb per second. 
arnuschky
Hero Member
*****
Offline Offline

Activity: 517
Merit: 501


View Profile
July 12, 2013, 09:21:46 AM
 #3

That limit is artificially placed in the code and can be lifted any time.

You should read: https://en.bitcoin.it/wiki/Scalability
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
July 12, 2013, 12:59:31 PM
 #4

http://blockchain.info/ru/charts/n-transactions-per-block

462 tx/block maximum ==> 462 tx per 600 sec ==> 0.77 tx/sec
Itcher (OP)
Full Member
***
Offline Offline

Activity: 364
Merit: 100



View Profile
July 12, 2013, 03:20:45 PM
 #5

Thank you ...

One block is a certain number of hash, and some of them are use for transaction? No? Do the Miner by making blocks connect the hashes in the blockchain?

I am confused about the way it works, am no coder, but be interested in the principles ...
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1053


Gerald Davis


View Profile
July 12, 2013, 03:26:12 PM
 #6

Thank you ...

One block is a certain number of hash, and some of them are use for transaction? No? Do the Miner by making blocks connect the hashes in the blockchain?

I am confused about the way it works, am no coder, but be interested in the principles ...

No none of that is correct.  Transactions take up space ina  block.  On average a tx is roughly 250 bytes.  The actual size of a single tx will vary depending on the # of inputs and outputs but looking at a large number of transaction is aggregate they average around 250 bytes.  Currently the Bitcoin protocol limits blocks to 1MB.   1024 * 1024 / 250 = ~ 4200 transactions.  4200 transactions every 600 seconds = ~ 7tps.  As pointed out above the 1MB limit is arbitrary and can be raised in the future.

None of this has anything to do with the number of hash attempts miners need to make before solving a block (failed hashes are simply discarded).

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
July 12, 2013, 04:31:08 PM
 #7

As pointed out above the 1MB limit is arbitrary and can be raised in the future.

What must be done to raise the limit?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1053


Gerald Davis


View Profile
July 12, 2013, 05:40:11 PM
 #8

As pointed out above the 1MB limit is arbitrary and can be raised in the future.

What must be done to raise the limit?

A hard fork will be necessary and one will want to proceed in a cautious manner to protect the integrity of the network and ensure users are not exposed to any unnecessary risk.

Here is an example of how the process could occur (version # for both clients and blocks in this example are arbitrary and just used for illustration purposes):
1) Test this process from start to finish on testnet.
2) In a future version of Bitcoin client (1.0.1) add support for new block version (version 2).  By default mining nodes will still create version 1 blocks at this time.  In 1.0.1, ver2 blocks >1MB height they are flagged as non-standard and will warn issue a warning to the node, store the block and NOT exclude these >1MB blocks when making the best/longest chain selection.
3) Have users upgrade to 1.0.1.  Monitor the usage of 1.0.1+ versions of clients and wait until a super majority has upgraded (no technical number but 80%+ has been used in the past).  
4) Once super majority of nodes have upgraded set a cutoff date and use alert messages to warn older clients to upgrade or risk being forked off the main network.
5) After date in step #4 have miners begin to create version 2 blocks (but still soft limited to 1MB). A config flag can be used in 1.0.1 version of node to force the node into version 2 block mode (still soft limited to 1MB).  This ensures all nodes have the ability to run the same codebase but still preserve their ability to support or not support the new block version.
6) Decide on a block height to implement >1MB blocks.  This should be 10,000 to 20,000 blocks beyond current block height.  It would make sense for it to be a memorable number, for example if we were ready for the transistion today (block height 246,242) the change could occur at block height 260,000
7) Release a new version of the client (1.1.1) which above the block height decided in step #6, allows creation of ver 2 blocks >1MB and considers them standard (selected for longest/best chain).  Version 1.1.1 would remove support for block version 1.
Cool Use alert messages to warn nodes on versions older than 1.1.1 that they risk being forked off after the block height in step #6.  As the block height approaches the messages should occur more frequently and with greater urgency.
9) The prior major version 1.0.1 can be coded with a failsafe node.  Since it "understands" ver2 blocks and just considers >1MB non-standard it can use this to protect the user.  The version 1.0.1 can be coded to look for double spends in the >1MB blocks.  The node can also count the # of blocks received on chains marked non-standard (because they have 1 or more >1MB block) and if that exceeds 50% of the total blocks in the prior day the user has likely been forked off (because it is after the cutoff date).  The node could then consider all transactions unconfirmed, prevent spending, and warn the user to immediately upgrade to avoid loss of funds.  Users older than 1.0.1 would have on knowledge of version 2 blocks and are at greater risk however similar safe mode could be built into clients now which looks for >50% of blocks being future blocks versions.

End state (once the block height picked in #6 passes):
Miners can (but aren't forced) to produce blocks greater than 1MB.
All nodes on current version will see these larger blocks as valid and use them for selecting the best chain.
Nodes which are on obsolete versions have some protection against malicious attack (alert messages & fail safe mode).

No it isn't a particularly simple process and it will take some time but using a staged process like the above (just an example nitpickers) provide a transition plan and ensure both non mining and mining nodes are ready for the change.
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!