Hacker News Reader

Comment by fweespeech | Hacker News Reader

> Using a bitcoin-based system offers several potential benefits. First off, it is faster. A bitcoin transaction clears in about 10 minutes, compared to three days for a traditional debt instrument to clear. The costs are lower.

Speed and cost is really where the advantage is. T+1 to T+3 is the usual range. 10 minutes is ridiculously fast and the cost savings appears to be notable.

Counterparty risk is reduced but the 51% attack exists + various security issues so its non-0 and really represents risk shifting rather than a lack of risk.

View on HN

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

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#Lightning_Network

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?

7 tps is the working theory. Whether its possible for an extended period of time is unknown.

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.

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.

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 another https://bitcoinj.github.io/working-with-micropayments.

> 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?

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.

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

Reply on news.ycombinator.com