21 ms·

how does the bitcoin system handles 10k+ transactions an hour?

fweespeech 11y ago
If you replaced "bitcoin" with "exchange-N-coin" and had N exchanges with fixed miner pools controlled by Y institutions roughly equally, you could scale horizontally. Whether that is cost effective with a bitcoin architecture, idk. It'd be relatively easy to do this and you only need 5 institutions with 20% of the pool each and SEC oversight to prevent them from colluding. Alternatively: https://en.bitcoin.it/wiki/Scalability#Increasing_Block_Size https://en.bitcoin.it/wiki/Scalability#Increasing_Block_Size https://en.bitcoin.it/wiki/Scalability#Lightning_Network https://en.bitcoin.it/wiki/Scalability#Lightning_Network
- x0x0 11y ago
  You offer suggestions on ways to handle such transaction volumes. Does that mean it is currently an unsolved problem? What volume can the current bitcoin blockchain implementation absorb?
  - fweespeech 11y ago
    7 tps is the working theory. Whether its possible for an extended period of time is unknown. https://blockchain.info/charts/n-transactions https://blockchain.info/charts/n-transactions It hasn't hit that limit [as of yet] for a full 24 hour period so there is no way to know if that is true. But really, its only "unsolved" in the sense there hasn't been a need to solve it and so an arbitrary limiter [1 megabyte] has not been increased.
    - sharpneli 11y ago
      7tps only with transactions that have a single input and a single output. In practice transactions have multiple inputs and multiple outputs. Based on average size of recent transactions it comes out to ~2.3tps.
  - wslh 11y ago
    The way to solve the blockchain limitations (confirmation speed, small amounts) is using micropayment channels. One of the implementations is https://github.com/bitpay/bitcore-channel https://github.com/bitpay/bitcore-channel another https://bitcoinj.github.io/working-with-micropayments https://bitcoinj.github.io/working-with-micropayments.
- notahacker 11y ago
  > It'd be relatively easy to do this and you only need 5 institutions with 20% of the pool each and SEC oversight to prevent them from colluding. If I understand correctly, you're saying that this architecture might not only [possibly] not be cost-effective, but also effectively reintroduces centralisation and counterparty risk with the fixed miner pools as the SEC is needed to prevent AltExchanges from being manipulated or failing? So it might not even be a solution to a problem the financial services industry (which throws millions at low latency connections for monitoring and executing trades but cares little about T+3 settlement) doesn't think it has?
  - fweespeech 11y ago
    Its the flaw in the horizontal scaling suggestion I made. Scaling Bitcoin requires everyone to agree on bigger machines/faster pipes and/or use the lightning option [which may or may not work]. Both of those options don't have the problem I stated.
brighton36 11y ago
It doesn't now. But Lightning Network will probably be your answer

If you replaced "bitcoin" with "exchange-N-coin" and had N exchanges with fixed miner pools controlled by Y institutions roughly equally, you could scale horizontally. Whether that is cost effective with a bitcoin architecture, idk. It'd be relatively easy to do this and you only need 5 institutions with 20% of the pool each and SEC oversight to prevent them from colluding. Alternatively: https://en.bitcoin.it/wiki/Scalability#Increasing_Block_Size https://en.bitcoin.it/wiki/Scalability#Increasing_Block_Size https://en.bitcoin.it/wiki/Scalability#Lightning_Network https://en.bitcoin.it/wiki/Scalability#Lightning_Network

x0x0 11y ago
You offer suggestions on ways to handle such transaction volumes. Does that mean it is currently an unsolved problem? What volume can the current bitcoin blockchain implementation absorb?
- fweespeech 11y ago
  7 tps is the working theory. Whether its possible for an extended period of time is unknown. https://blockchain.info/charts/n-transactions https://blockchain.info/charts/n-transactions It hasn't hit that limit [as of yet] for a full 24 hour period so there is no way to know if that is true. But really, its only "unsolved" in the sense there hasn't been a need to solve it and so an arbitrary limiter [1 megabyte] has not been increased.
  - sharpneli 11y ago
    7tps only with transactions that have a single input and a single output. In practice transactions have multiple inputs and multiple outputs. Based on average size of recent transactions it comes out to ~2.3tps.
- wslh 11y ago
  The way to solve the blockchain limitations (confirmation speed, small amounts) is using micropayment channels. One of the implementations is https://github.com/bitpay/bitcore-channel https://github.com/bitpay/bitcore-channel another https://bitcoinj.github.io/working-with-micropayments https://bitcoinj.github.io/working-with-micropayments.
notahacker 11y ago
> It'd be relatively easy to do this and you only need 5 institutions with 20% of the pool each and SEC oversight to prevent them from colluding. If I understand correctly, you're saying that this architecture might not only [possibly] not be cost-effective, but also effectively reintroduces centralisation and counterparty risk with the fixed miner pools as the SEC is needed to prevent AltExchanges from being manipulated or failing? So it might not even be a solution to a problem the financial services industry (which throws millions at low latency connections for monitoring and executing trades but cares little about T+3 settlement) doesn't think it has?
- fweespeech 11y ago
  Its the flaw in the horizontal scaling suggestion I made. Scaling Bitcoin requires everyone to agree on bigger machines/faster pipes and/or use the lightning option [which may or may not work]. Both of those options don't have the problem I stated.

brighton36 11y ago

It doesn't now. But Lightning Network will probably be your answer