BTC - Transaction Volume in the Network

[CWestermark]

VISA handles 150 000 000 transactions a day. http://corporate.visa.com/about-visa/technology/transaction-processing.shtml with 86 400 seconds per day, that is 1 739 transactions per second. But we also have to count for other credit cards, bank transfers and a new kinds of transactions that we do not have today, such as micro payments for bloggers, filmmakers etc.

Let us assume roughly 10 000 transaction a second is needed for a viable world crypto currency. Of course not, one single coin will dominate all payments, but let us say that the biggest have 10% stake and hence BTC has to be able to handle 1 000 transactions a seconds. The closer BTC or an Altcoin is to be able to handle this transaction volume, the bigger potential it has to grow to one of the most dominant ones.

With a block generation of 10min, 1MB harcoded blocksize and 400byte transaction size, BTC will never be close to handle the requiered transaction volume. Is there any "fixes" down the road for this, or will an altcoin have to adjust for a satisfying transaction volume?

[1714773454]

1714773454

[1714773454]

1714773454

[nmersulypnem]

VISA handles 150 000 000 transactions a day. http://corporate.visa.com/about-visa/technology/transaction-processing.shtml with 86 400 seconds per day, that is 1 739 transactions per second. But we also have to count for other credit cards, bank transfers and a new kinds of transactions that we do not have today, such as micro payments for bloggers, filmmakers etc.

Let us assume roughly 10 000 transaction a second is needed for a viable world crypto currency. Of course not, one single coin will dominate all payments, but let us say that the biggest have 10% stake and hence BTC has to be able to handle 1 000 transactions a seconds. The closer BTC or an Altcoin is to be able to handle this transaction volume, the bigger potential it has to grow to one of the most dominant ones.

With a block generation of 10min, 1MB harcoded blocksize and 400byte transaction size, BTC will never be close to handle the requiered transaction volume. Is there any "fixes" down the road for this, or will an altcoin have to adjust for a satisfying transaction volume?

The block size limit will probably increase a little - maybe 10x. ...but yes, your analysis is essentially correct.  There are also methods for block chain merging (like what Ethereum plans on using) which might bring block times in to 1-2 minutes, but essentially we'll never be able to process the number of transactions that the existing finance world does. ...unless we take a different approach and *really* fragment the block chain.

This is only one of several fundamental flaws in some of the "to the moon" rhetoric.

[MoonShadow]

There are several parrallel projects that I know of, none of which addresses transaction volume rates per se, but both of which contribute to the capacity.

The first one of note is the "naked block" change to the protocol that is forthcoming.  The point of it is that, because of the p2p style of propagation of bitcoin network objects, the actual transactions don't need to be part of a published block for miners to confirm that they are correct; because miner's almost certainly already have those transactions.  So broadcasting blocks complete represents a double broadcasting of those transactions.  The "naked block" change will permit miners to publish their blocks using only the block headers and the myrkle tree, which will reduce the actual data size of the published blocks.  This will help thoughput because the block size limit doesn't need to be increased in order to fit many more actual transactions.

Another is the development of 'overlay' processing networks, which are expected to take most of the burden of small value transactions using a reduced trust model.  The big one pursuing this line of inquriy is the Electrum client via their Stratum network.  What will happen is variations on the trust model of bitcoin will be employed to permit users within a particular overlay network to send arbitrary values to one another without using the blockchain at all, or only using the blockchain to settle up values periodicly or if a value limit has been crossed.  Online wallet services use a similar trick to permit users to send another member bitcoins without creating a transaction that must be processed immediately or individually.  The wallet services function similar to Paypal in this context, keeping the accounting in house; while the overlay networks can be expected to function similar to Ripple.  The end result is the same, many transactions between users cancel one another out, reducing (but not eliminating) the necessity to create bitcoin transactions.  Another reduction that overlay networks could employ is to use send-to-many transactions to gather up the individual transactions that users produce over a time period into one huge transaction with numerous inputs and outputs, expecting that the portions of those transactions related to various senders will be properly signed by their overlay network connected nodes in a timely fashion.  The economic force that can be expected to drive the development of such overlay networks are rising transaction fees.

Still another reduction in transaction volumes, also related to the send-to-many transaction, would be large institutions that gather up numerous payments to themselves to pay out to numerous creditors at once.  Think along the lines of Wal-Mart paying all of their employees their weekly payroll in a single transaction, or an individual paying all of their monthly bills at once.  While those actual send-to-many transactions would be quite large, the 'naked block' protocol results in Wal-Mart's weekly payroll transaction having no more of a footprint inside a broadcast block than another's simple Satoshi Dice payout.

So, while the main bitcoin network isn't really designed to handle huge transaction volumes (thinkof it more like the banks' ATM network, they don't handle all transactions, but they do handle those that require great security over distances) it doesn't really need to, and it can handle more volume than is commonly expected.