Live data from Hacker News

An analysis of Bitcoin's throughput bottlenecks

github.com

21–30 of 234 posts

Re: An analysis of Bitcoin's throughput bottlenecks

#21
post #13

Earlier quoted context omitted.

I don't know how Bitcoin transactions work, but can a company (like Paypal) buy bunch of bitcoins (10000), and then proceed to do all transaction internally with their own ledger mechanism without depending on other networks?, wouldn't this allow anybody within paypal network to send/receive super fast?

Yeah that's how all centralized crypto exchanges do it

What if there's a run on the exchange?

Re: An analysis of Bitcoin's throughput bottlenecks

#22
post #13

Earlier quoted context omitted.

If Bitcoin were used by everybody on the planet, the current max of 10 transactions/second means that each person could be part of a transaction once every 13 years (4 billion pairs of people / 10 Hz). Boosting the rate up to 100 transactions per second reduces that down to 15 months. Just think, receive you paycheck this week, and over a year later you can use it to buy groceries. Bitcoin's throughout is absolutely…

I don't know how Bitcoin transactions work, but can a company (like Paypal) buy bunch of bitcoins (10000), and then proceed to do all transaction internally with their own ledger mechanism without depending on other networks?, wouldn't this allow anybody within paypal network to send/receive super fast?

Correct. This adds a point of centralization, which defeats the entire purpose of cryptocurrency. As far as I can tell, cryptocurrency is based on wanting (1) a shared database that (2) can be updated by anyone within specific rules and (3) doesn't require anybody to trust anybody else. In the same way that low-trust societies have a much bigger overhead as a result of the lack of trust, I do not think cryptocurrencies are feasible while holding to (3) without massive, massive expenditure as a result.

Re: An analysis of Bitcoin's throughput bottlenecks

#23
its a pity bitcoin devs are so opposed to changing the protocol. So much research has been done showing the feasibility of increasing bitcoins throughput. Xthinner for instance is capable of compressing bitcoin blocks by up to 99% using bloom filters [1]. Much of this research was conducted on the bitcoin fork, bitcoin cash, by people ostracized from the bitcoin community for wanting to explore these ideas.

[1]https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...

Re: An analysis of Bitcoin's throughput bottlenecks

#24
post #6

Bitcoin could handle 100k+ tps with some more serious optimizations (but keeping the same protocol / data structures) it’s simply tragic what small blockers have done with Bitcoin instead. UTXO is massively parallel! The double spend critical path could do millions of double spend checks per second.

> UTXO is massively parallel I don't quite understand what you mean by UTXO being parallel. Can you explain more? My naive understanding is that the amount of unspent bitcoin you have at an address (UTXO) has to be accurate for the critical path of verifying a double spend doesn't happen, and updating multiple UTXOs in parallel seems like it would allow violating that.

[deleted]

Re: An analysis of Bitcoin's throughput bottlenecks

#25

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

How many transactions happen in the world?

Visa says they do 150 million transactions in a day, for an average of 1,700tps — and I’d have to imagine their spikes are much higher.

Re: An analysis of Bitcoin's throughput bottlenecks

#26
post #6

Bitcoin could handle 100k+ tps with some more serious optimizations (but keeping the same protocol / data structures) it’s simply tragic what small blockers have done with Bitcoin instead. UTXO is massively parallel! The double spend critical path could do millions of double spend checks per second.

> UTXO is massively parallel I don't quite understand what you mean by UTXO being parallel. Can you explain more? My naive understanding is that the amount of unspent bitcoin you have at an address (UTXO) has to be accurate for the critical path of verifying a double spend doesn't happen, and updating multiple UTXOs in parallel seems like it would allow violating that.

The reason UTXOs parallelize better is because when you look at a transaction on a UTXO-based blockchain like Bitcoin, you can deterministically and often immediately know from it exactly how the state of the system will change, and which states will change. A Bitcoin transaction for example completely describes which outputs will be spent, which new outputs will be created, and the new amounts in those outputs. This is a really nice property. It makes validating and analyzing transactions parallelizable by design. The system still has to protect against double-spends globally, but this part is light in comparison and can be very fast.

In contrast to Bitcoin, basically every other smart contract blockchain is account-based, not UTXO-based, and has shared global state. This does not parallelize naturally at all. I like to think its similar to using cash vs transferring money using Venmo. Giving someone cash parallelize naturally, like UTXOs, whereas Venmo requires a database lock.

In account-based systems, it’s impossible to tell how a transaction will change the system's state without executing it. The order that transactions are executed is crucial too, which is why people say Ethereum is single-threaded. Attempts to parallelize account-based systems fall into different categories. Ethereum 2.0's plan is to basically create separate VMs with separate state, called shards or rollups. This can work sometimes, but it makes interactivity between shards (think applications) much more difficult, and interactivity to me is a major reason for using blockchain. Another approach is to embed information into transactions to make them parallelize more like UTXO-based transactions, which is what Solana does. But they parallelize only at the smart contract level, not at the asset level as UTXOs can.

Whereas UTXO-based designs get parallelizability by design, creating a programming model for smart contracts and tokens has to-date been harder on these systems, and frankly there aren't even that many people trying. I've been working on this problem for a while and believe I've found a breakthrough. Check out https://run.network if it interests you.

Re: An analysis of Bitcoin's throughput bottlenecks

#27

Bitcoin doesn't need to increase its throughput. This is what layer 2 (3,4,...,n) solutions are for. This is like saying "Well, the dollar is useless because Fedwire TPS doesn't accommodate all transactions." If you compare apples to apples, Bitcoin is more than adequate to replace something like Fedwire with a zero trust decentralized system. Layer 2 solutions for Bitcoin can look something like The Lightning Networ…

If you want people to actually be able to pay for things with Bitcoin (often a stated goal), then yes, it does.

Re: An analysis of Bitcoin's throughput bottlenecks

#28

> I will also show that while Bitcoin currently may not be in a safe state, future software optimizations could allow Bitcoin safely process likely more than 100 transactions/second on today's hardware. 100 transactions/second still doesn’t sound like a lot, especially if you want Bitcoin to be an actual currency used for exchange of goods.

If Bitcoin were used by everybody on the planet, the current max of 10 transactions/second means that each person could be part of a transaction once every 13 years (4 billion pairs of people / 10 Hz). Boosting the rate up to 100 transactions per second reduces that down to 15 months. Just think, receive you paycheck this week, and over a year later you can use it to buy groceries. Bitcoin's throughout is absolutely…

This is not really true, for several reasons. One simple reason is that a bitcoin transaction can have multiple outputs, while your analysis assumes each transaction is between two people.

Re: An analysis of Bitcoin's throughput bottlenecks

#29

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

Seriously? Bitcoin that has intentionally low transaction throuput is only two orders of magnitude slower than largest online payment processor that was designed with highest possible throuput in mind?

Re: An analysis of Bitcoin's throughput bottlenecks

#30

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

has anyone ever done the modeling on the dynamic limits of decentralized network consensus? my intuition has always been that getting, say, 100,000 globally distributed voting nodes to agree on even a simple truth value will quickly run into exponential (or worse) latency bottlenecks by way of metcalfe's law.

  the speed of light, as a hard limit, starts to become insurmountable when your consensus pathway has to be traversed  the equivalent of tens of millions of  km of signal path in order for every node to have an equal influence on the validity of every other node's vote.  
these high tps coins all seem to get around this by weakening decentralization, whether by shortening this path, either because they have far fewer nodes, or are deciding to sum over some approximation of node consensus by sampling or creating privileged paths, or because geography already creates privileged paths (all the nodes are in the same general area, or even in the same datacenter).

I suspect the reason TX speed tends to stay mired in the tens per second region is that no amount of consensus accounting gimmickry will overcome the underlying physical limitations of true global scale decentralization of consensus.

Post reply on HN