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
An analysis of Bitcoin's throughput bottlenecks
21–30 of 234 posts
Re: An analysis of Bitcoin's throughput bottlenecks
#22Earlier 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?
Re: An analysis of Bitcoin's throughput bottlenecks
#23[1]https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...
Re: An analysis of Bitcoin's throughput bottlenecks
#24Bitcoin 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.
Re: An analysis of Bitcoin's throughput bottlenecks
#25Here 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?
Re: An analysis of Bitcoin's throughput bottlenecks
#26Bitcoin 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.
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
#27Bitcoin 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…
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…
Re: An analysis of Bitcoin's throughput bottlenecks
#29Here 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/
Re: An analysis of Bitcoin's throughput bottlenecks
#30Here 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/
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.