17 ms·

An analysis of Bitcoin's throughput bottlenecks

100 points by billytetrud 5y ago

oogabooga123 5y ago
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.
- TheDong 5y ago
  > 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.
  - Taek 5y ago
    A design technique called utreexo allows you to validate essentially every single transaction in the entire history in full parallelism. With an infinite number of cores, you could in theory validate the entire bitcoin blockchain in under a second. That said, you need to do billions of cryptographic operations still, and you need to actually posses the full blockchain. 100k tps+ is not really reasonable on modern consumer hardware, and even getting to 100 requires a lot more engineering than has currently been completed.
  - deleted 5y ago
    [deleted]
  - nivexous 5y ago
    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 https://run.network if it interests you.
RcouF1uZ4gsC 5y ago
> 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.
- MereInterest 5y ago
  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 pathetic, by several orders of magnitude. I think the only reason that aspect hasn't gotten more attention is because the energy efficiency is even worse.
  - ezekg 5y ago
    Are there any cryptocurrencies that are attempting to solve this issue?
    - sambroner 5y ago
      Basically all (hardly even an exaggeration!) other cryptocurrencies are attempting to improve upon the throughput issue. Solana is a particularly prominent one with 50k/s https://solana.com/ https://solana.com/
      - uncoder0 5y ago
        I'm interested in how all these other chains deal with people writing tons of junk transactions per second to bloat up the chain.
        cgb223 5y ago
chromaton 5y ago
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-cryptocurrency-transactions-by-type/ https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/ https://www.businessofapps.com/data/paypal-statistics/
- bourgwaletariat 5y ago
  How many transactions happen in the world?
  - ketzo 5y ago
    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.
    - newsbinator 5y ago
      Stellar (XLM) claims to be able to handle 4000tps, if I remember correctly?
      - deleted 5y ago
        [deleted]
  - PeterisP 5y ago
    Looking solely at electronic direct payments, it would be more than a billion transactions per day, there are multiple major schemes that work on the 100m/day scale each (Visa, Mastercard, US ACH, EU SEPA, China Unionpay, etc) and a lot of smaller ones that add up. So that's in the ballpark of 10k sustained average txn/sec, more in peaks. On the other hand, there's room for a lot of growth, it's not even a single transaction per day for the almost 8 billion people that we have.
djschnei 5y ago
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 Network (trustless) or something like the Liquid side-chain (maybe for institution-to-institution settlement?).
- ketzo 5y ago
  If you want people to actually be able to pay for things with Bitcoin (often a stated goal), then yes, it does.
  - billytetrud 5y ago
    He mentioned the Lightning Network - that is exactly what its for.
- lottin 5y ago
  Sorry but bitcoin is peer-to-peer cash system. If it can't handle peer-to-peer transactions then it's an utter failure.
  - dalmo3 5y ago
    99% of the content on news.ycombinator.com is not about startups. An utter failure!
    - chris_wot 5y ago
      Nice try, but that's not the point of news.ycombinator.com
  - itsdsmurrell 5y ago
    Correct, BTC is not peer to peer cash, try the real Bitcoin, Bitcoin Cash.
dylkil 5y ago
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_ctor_xthinner_is_now_working_with/ https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...
- billytetrud 5y ago
  The actual transactions must all still be transmitted, so this "compression" is actually a way to avoid transmitting transaction data that has already been received by the other side. Bitcoin already does this and while maybe xthinner is better (I don't know) its absolutely not a 99X improvement over standard bitcoin. The problem with the bch people was that they were reckless and dishonest, not that they didn't occasionally create interesting things and have good points. It was a community that was problematic, but still contained some people doing good work.
  - topranks 5y ago
    It’s core principal; that the 1MB blocks use cap was arbitrary and holding back the network, remains 100% true. The arguments against SPV wallet use in this text don’t ring true for me.
    - grlass 5y ago
      It may be arbitrary, but increasing blocksize to mitigate network congestion is not a good solution, since any cap you set it to will also be arbitrary, and harm decentralisation (block propagation time, node operation costs, etc). And given how valuable it is to have data in a semi-permanent near-immutable distributed ledger, that block space would be filled up pretty quickly, solving nothing. Keeping the limit however has inspired a number of novel innovations to use the space more efficiently, including segwit (effectively increasing blocks to 4MB), and taproot. In short, block size increases are an "easy solution" that don't really solve much.
homakov 5y ago
Bitcoin dominance is fading this year only because it has bet on LN with fundamental inbound capacity problem. LN rejected my proposal to solve it and extend channels with credit lines: XLN https://medium.com/fairlayer/xln-extended-lightning-network-80fa7acf80f3 https://medium.com/fairlayer/xln-extended-lightning-network-...
- Qworg 5y ago
  Payment channels ARE credit, generally - I'm sorry this proposal was rejected. Was there a reason for the rejection?
  - homakov 5y ago
    Payment channels, in traditional sense, are fully collateralized credit. I suggested to leave collateralization ratio up to users themselves. Some could have 100% collateral, some 0%, some 50% etc. Rejection reason: unclear, doesn't fit the narrative.
  - billytetrud 5y ago
    Payment channels are not at all credit. Credit means you're relying on someone to pay you back, and have a risk that they won't pay you back. Credit relies on trust. Payment channels do not rely on trust. You can always retrieve your money even if your channel partner doesn't want to give it back.
    - Qworg 5y ago
      Unless you value the time your money that is locked up at zero, they are definitely credit - as GP said, fully-collateralized loans.
- rawtxapp 5y ago
  Bitcoin dominance always goes down in altcoin season and then comes right back up.
  - 5y ago
ilaksh 5y ago
Bitcoin is the cryptocurrency you pick when you don't want to improve or change anything about cryptocurrency. It's the digital gold cryptocurrency. Many people have tried over the years to improve it such as reducing bottlenecks etc. At this point, I think they have proven that they are not going to make structural changes. And so I think the rational response is just to appreciate and use Bitcoin for what the devs or evil conspirators or whatever have decided that Bitcoin is going to be. Thankfully we have other cryptocurrencies.
itsdsmurrell 5y ago
Try Bitcoin Cash. The devs have full control over the BTC protocol.
- vkoskiv 5y ago
  Not this again. Hey! I just forked Bitcoin into my own fork. Nobody is using it, so the transaction fees are almost zero. Therefore, it is also 100% better than Bitcoin!
Havoc 5y ago
I’m still not quite following why people are looking at bitcoin for this. Surely one of the newer generation like eth is better suited? Or better yet a layer 2 on eth
- gruez 5y ago
  >Surely one of the newer generation like eth is better suited? What scaling technologies do they have? The ones I'm aware of are: "commit the global state every n blocks and trust that", and "have n parallel blockchains so it's not one big chain" >Or better yet a layer 2 on eth or layer 2 on BTC, aka lightning network?
  - CyberDildonics 5y ago
    Why? It has been in development for 7 years. Why use this complicated hack solution when anyone can just use a different cryptocurrency and not have these problems in the first place?
    - wyager 5y ago
      > It has been in development for 7 years. Good. They need to get it right. > Why use this complicated hack solution It’s complicated but not a hack at all. It makes perfect sense. > when anyone can just use a different cryptocurrency and not have these problems in the first place? There are 0 (zero) cryptocurrencies that scale better than Bitcoin that don’t also compromise on security or decentralization. Lightning is the best known option which keeps these properties which make Bitcoin desirable in the first place.
      - loveitmore 5y ago
        0 that scale better? XRP performs better at scale and I don’t believe for a second Bitcoin is anymore decentralized. That being said, I don’t know enough about the security aspect - so your claim may end up being correct!
        5y ago
CryptoPunk 5y ago
This analysis is complete nonsense because it starts with assumptions that are entirely arbitrary and biased toward the argument of not scaling Bitcoin: >>Bitcoin.org documents the minimum requirements for running a full node, however with the current state of technology, we must substantially lower these requirements so as to make running a full node as accessible as possible to even people in poorer countries No, people in poorer countries only need to be able to write transactions with their own private keys. You can easily find trusted sources of blockchain data, and even poll multiple sources to ensure you are not being fed false information by one source. If your government blocks access to all those sources with a national firewall, you can use a VPN, which is much easier than running a full node, to bypass it. What you don't want is people in poorer countries having to trust third parties with their private keys, which is exactly the result of limiting on-chain throughput so that the vast majority of people use trusted third parties to hold their digital currency and transact it on their behalf. If we take the assumption that only people who have enough bandwidth to stream Netflix 24 hours a day should be able to run a Bitcoin node, we get maximum allowable throughput at least 100X greater than today, and even that requirement is arbitrarily stringent, as Bitcoin could be distributed enough to be impossible to shut down with an even smaller percentage of the world population being capable of running a full node. The analysis also assumes that a user should be able to run a full node with 1. Computing resources they already own for their own personal computing needs. 2. By only utilizing 10% of those resources. Using a dedicated node, with computing resources that the user purchases and utilizes 100% for Bitcoin node operation, is ruled out, again arbitrarily for no reason that would be relevant to a global network attack scenario. Thus the analysis contains assumptions like this: >>But since most Bitcoin users are more affluent, for analysis of current Bitcoin I'll use a range of 250-500 GB for the 90th percentile users, and 500-2000 GB for the top 10%. Note that I'm using wide ranges because I'm less certain about these numbers. In reality, tens of millions of people could easily afford to purchase tens of TB of storage for running dedicated Bitcoin nodes, and tens of millions of people is easily enough to make shutting down or controlling the Bitcoin network impossible for any nation-state actor. So this assumption that Bitcoin nodes need to be able to run on machines with only 500 GB to 2 TB of storage, with only 10% of that, i.e. 50 GB to 200 GB, allocated to running a Bitcoin node, is absolutely absurd. And this is just storage, which the analysis assumes is okay to limit to the top 10% of the global population. For bandwidth, the analysis assumes that 90% of the world population, which includes some of the poorest people in the world, should have enough for running a full node. This idea that the lower classes in India should be running a Bitcoin full node, or else the Bitcoin network will somehow be jeopardized, would be comical if this weren't a serious attempt at swaying public opinion. Basically the analysis is implying that it's okay for it to cost $100 in fees to conduct a single Bitcoin transaction, which is out of reach for even the wealthy in rich countries, but that it is not okay that poor people in India not be able to run a Bitcoin full node on their own device - and let's not forget - while utilizing only 10% of their device's network resources. Just absurd.. To summarize, the analysis assumes that it should be possible to run a Bitcoin node using 10% of the typical personal computing resources of 90% of the world population, when in reality all Bitcoin needs to be shutdown and censorship proof is that it be possible to run a full node using something on order of 500% of the typical personal computing resources of the richest 1% of the world population, i.e. the richest 80 million people, who live in the developed world, given many of those people are willing to purchase dedicated hardware and bandwidth for running a Bitcoin full node, and many would do that if the network actually came under any threat of a coordinated global attack on the network. Considering all this, this analysis could easily be under-estimating how much Bitcoin could increase its throughput by a factor of 1,000X. It's a very disingenuous and biased analysis that obfuscates this fact by being loaded with analysis and data that 1. imply credibility and 2. hide and distract from these totally bogus starting assumptions. Finally, the analysis only considers a physical network attack. The political attack, of countries banning Bitcoin internally, and the best defenses against that, are not considered. In reality, the best defense against a political attack is allowing Bitcoin to scale by 100 or 1,000 times in throughput, to increase the proportion of the population that is economically dependent on the network, and would oppose attempts to politically attack it. And in reality, a political attack is much more likely, and dangerous, to the ability of cryptocurrency to fulfill its potential to financially empower the world's population, than a physical network attack.
billytetrud 5y ago
A little late, but I wanted to mention that I came to work on this because of the debate about block size and scaling ideas around the segwit update. Lots of opinions are generally thrown around without a whole lot of data to back it up, so I wanted to put in the work to make a systematic framework for estimating and comparing alternatives. I wanted to make it easier for other people to evalute what bitcoin's actual bottlenecks are and the way their preferred solution would affect those bottlenecks.
- CryptoPunk 5y ago
  For a rebuttal to your analysis, please see this: https://news.ycombinator.com/item?id=27136533 https://news.ycombinator.com/item?id=27136533
  - deleted 5y ago
    [deleted]
jlrubin 5y ago
Some of my congestion control research that helps large scale users make throughput/latency tradeoffs using simple "transaction templates": https://utxos.org/uses/scaling/ https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/batching_sim/ https://utxos.org/analysis/batching_sim/ https://github.com/bitcoin/bitcoin/pull/21702 https://github.com/bitcoin/bitcoin/pull/21702
- billytetrud 5y ago
  Thanks Jeremy! Are all those links related to congestion control? In short, that's basically allowing transactions to be shifted from high-congestion times to lower-congestion times without delaying the transfer (eg the transfer from the sender, even if the receive won't get the coins immediately). Is that right? Or are there more benefits of it?
  - jlrubin 5y ago
    Hi Billy, yes they all are. 1 -> high level idea, 2 -> basic simulation, 3 -> batching improvements, 4 -> the PR to bitcoin core. I have a lot more material scattered around too :) You understanding of the shifting from high congestion to low is spot on, but there are other benefits. The technique can also be used for more general smart contracts. I've been building a language, https://learn.sapio-lang.org https://learn.sapio-lang.org, for expressing smart contracts. You can do vaults, synthetic derivatives, sidechains, etc with it. One niche point I like to make too, btw, is that the delayed payouts can be into non-interactively initialized payment channels. So you could immediate begin spending/routing payments in the lightning network on open, and wait for low congestion to expand out your UTXO.
    - billytetrud 5y ago
      Ah very interesting. So Sapio is a library for constructing somewhat arbitrary programs using CTV as a mechanism for enabling more turing complete operations? Is Sapio turing complete (or, I guess equivalently would Bitcoin be turing complete with the addition of CTV)? So with non-interactively created channels, I don't quite understand how you would be able to immediately spend/route payments. Don't you always need to interact with your channel partner in order to do both of those things?
bluepnume 5y ago
Take a look at "The Blocksize War" for a fantastic rundown of the events that led to Bitcoin not increasing its throughput. TLDR: Massively rushed changes, pushed by people with a lot of power on the network (miners and corporations), which ended up being largely antithetical to Bitcoin's decentralization thesis. Bitcoin's value is in its stability, its decentralization, and its lack of hurried change. It is in the control of everyone, not just the powerful actors in the system. Its value is not in its ability to pivot every few years like a startup to fulfill some new purpose.
- billytetrud 5y ago
  > led to Bitcoin not increasing its throughput Bitcoin did increase its blocksize and throughput. It about doubled it in fact. > Its value is not in its ability to pivot every few years like a startup to fulfill some new purpose. Yes, people don't realize that we don't want bitcoin to be agile, move fast and break things. We want it to be well considered, move slowly, and be safe and careful. Similarly, it aggrivates me that people complain about how "congress moves too slow, there's too much deadlock". We shouldn't want lawmaking to move fast. Like bitcoin, it should be slow, methodical, and careful. The problem with US congress is not that its slow, its that it is massively corrupt and opposing sides rush to put things together and then don't cooperate on improving proposals into a considered compromise. Slow compromise is what we want, not fast stubborn corrupt legislators.
  - bluepnume 5y ago
    Of course, apologies. Should have been clear I was talking about 2MB+ blocksize rather than segwit. Some great points!
harwoodleon 5y ago
This paper is very considered. But it does not consider that these questions have all been addressed in other cryptocurrencies like Nano (nano.org), which is a far more usable system than Bitcoin. Especially now that “Time as a currency” spam mitigation measures are being rolled out.
- billytetrud 5y ago
  True, the paper is just about bitcoin specifically. I've read through Nano and the spam problem was #1 in my mind. It seemed to me that there was no possible way to prevent spam in Nano without turning it into a strictly-worse form of cryptocurrency than other proof of work systems. So my determination about Nano was that if it maintained its current course, it would flame out (transactions would increase without bound until no one could run Nano nodes) OR that they would have to change course to something like increasing the transaction PoW, which would increase the work done on end-user machines to the point where its very cumbersome (slow and expensive) to create a transaction. I'm curious to know what "time as a currency" is and how it solves the spam problem. Do you have a good link that explains?

100 points by billytetrud 5y ago

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.

TheDong 5y ago
> 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.
- Taek 5y ago
  A design technique called utreexo allows you to validate essentially every single transaction in the entire history in full parallelism. With an infinite number of cores, you could in theory validate the entire bitcoin blockchain in under a second. That said, you need to do billions of cryptographic operations still, and you need to actually posses the full blockchain. 100k tps+ is not really reasonable on modern consumer hardware, and even getting to 100 requires a lot more engineering than has currently been completed.
- deleted 5y ago
  [deleted]
- nivexous 5y ago
  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 https://run.network if it interests you.

RcouF1uZ4gsC 5y ago

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

MereInterest 5y ago
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 pathetic, by several orders of magnitude. I think the only reason that aspect hasn't gotten more attention is because the energy efficiency is even worse.
- ezekg 5y ago
  Are there any cryptocurrencies that are attempting to solve this issue?
  - sambroner 5y ago
    Basically all (hardly even an exaggeration!) other cryptocurrencies are attempting to improve upon the throughput issue. Solana is a particularly prominent one with 50k/s https://solana.com/ https://solana.com/
    - uncoder0 5y ago
      I'm interested in how all these other chains deal with people writing tons of junk transactions per second to bloat up the chain.
      - cgb223 5y ago

chromaton 5y ago

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-cryptocurrency-transactions-by-type/ https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/ https://www.businessofapps.com/data/paypal-statistics/

bourgwaletariat 5y ago
How many transactions happen in the world?
- ketzo 5y ago
  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.
  - newsbinator 5y ago
    Stellar (XLM) claims to be able to handle 4000tps, if I remember correctly?
    - deleted 5y ago
      [deleted]
- PeterisP 5y ago
  Looking solely at electronic direct payments, it would be more than a billion transactions per day, there are multiple major schemes that work on the 100m/day scale each (Visa, Mastercard, US ACH, EU SEPA, China Unionpay, etc) and a lot of smaller ones that add up. So that's in the ballpark of 10k sustained average txn/sec, more in peaks. On the other hand, there's room for a lot of growth, it's not even a single transaction per day for the almost 8 billion people that we have.

djschnei 5y ago

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 Network (trustless) or something like the Liquid side-chain (maybe for institution-to-institution settlement?).

ketzo 5y ago
If you want people to actually be able to pay for things with Bitcoin (often a stated goal), then yes, it does.
- billytetrud 5y ago
  He mentioned the Lightning Network - that is exactly what its for.
lottin 5y ago
Sorry but bitcoin is peer-to-peer cash system. If it can't handle peer-to-peer transactions then it's an utter failure.
- dalmo3 5y ago
  99% of the content on news.ycombinator.com is not about startups. An utter failure!
  - chris_wot 5y ago
    Nice try, but that's not the point of news.ycombinator.com
- itsdsmurrell 5y ago
  Correct, BTC is not peer to peer cash, try the real Bitcoin, Bitcoin Cash.

dylkil 5y ago

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_ctor_xthinner_is_now_working_with/ https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...

billytetrud 5y ago
The actual transactions must all still be transmitted, so this "compression" is actually a way to avoid transmitting transaction data that has already been received by the other side. Bitcoin already does this and while maybe xthinner is better (I don't know) its absolutely not a 99X improvement over standard bitcoin. The problem with the bch people was that they were reckless and dishonest, not that they didn't occasionally create interesting things and have good points. It was a community that was problematic, but still contained some people doing good work.
- topranks 5y ago
  It’s core principal; that the 1MB blocks use cap was arbitrary and holding back the network, remains 100% true. The arguments against SPV wallet use in this text don’t ring true for me.
  - grlass 5y ago
    It may be arbitrary, but increasing blocksize to mitigate network congestion is not a good solution, since any cap you set it to will also be arbitrary, and harm decentralisation (block propagation time, node operation costs, etc). And given how valuable it is to have data in a semi-permanent near-immutable distributed ledger, that block space would be filled up pretty quickly, solving nothing. Keeping the limit however has inspired a number of novel innovations to use the space more efficiently, including segwit (effectively increasing blocks to 4MB), and taproot. In short, block size increases are an "easy solution" that don't really solve much.

homakov 5y ago

Bitcoin dominance is fading this year only because it has bet on LN with fundamental inbound capacity problem. LN rejected my proposal to solve it and extend channels with credit lines: XLN https://medium.com/fairlayer/xln-extended-lightning-network-80fa7acf80f3 https://medium.com/fairlayer/xln-extended-lightning-network-...

Qworg 5y ago
Payment channels ARE credit, generally - I'm sorry this proposal was rejected. Was there a reason for the rejection?
- homakov 5y ago
  Payment channels, in traditional sense, are fully collateralized credit. I suggested to leave collateralization ratio up to users themselves. Some could have 100% collateral, some 0%, some 50% etc. Rejection reason: unclear, doesn't fit the narrative.
- billytetrud 5y ago
  Payment channels are not at all credit. Credit means you're relying on someone to pay you back, and have a risk that they won't pay you back. Credit relies on trust. Payment channels do not rely on trust. You can always retrieve your money even if your channel partner doesn't want to give it back.
  - Qworg 5y ago
    Unless you value the time your money that is locked up at zero, they are definitely credit - as GP said, fully-collateralized loans.
rawtxapp 5y ago
Bitcoin dominance always goes down in altcoin season and then comes right back up.
- 5y ago

ilaksh 5y ago

Bitcoin is the cryptocurrency you pick when you don't want to improve or change anything about cryptocurrency. It's the digital gold cryptocurrency. Many people have tried over the years to improve it such as reducing bottlenecks etc. At this point, I think they have proven that they are not going to make structural changes. And so I think the rational response is just to appreciate and use Bitcoin for what the devs or evil conspirators or whatever have decided that Bitcoin is going to be. Thankfully we have other cryptocurrencies.

itsdsmurrell 5y ago

Try Bitcoin Cash. The devs have full control over the BTC protocol.

vkoskiv 5y ago
Not this again. Hey! I just forked Bitcoin into my own fork. Nobody is using it, so the transaction fees are almost zero. Therefore, it is also 100% better than Bitcoin!

Havoc 5y ago

I’m still not quite following why people are looking at bitcoin for this. Surely one of the newer generation like eth is better suited? Or better yet a layer 2 on eth

gruez 5y ago
>Surely one of the newer generation like eth is better suited? What scaling technologies do they have? The ones I'm aware of are: "commit the global state every n blocks and trust that", and "have n parallel blockchains so it's not one big chain" >Or better yet a layer 2 on eth or layer 2 on BTC, aka lightning network?
- CyberDildonics 5y ago
  Why? It has been in development for 7 years. Why use this complicated hack solution when anyone can just use a different cryptocurrency and not have these problems in the first place?
  - wyager 5y ago
    > It has been in development for 7 years. Good. They need to get it right. > Why use this complicated hack solution It’s complicated but not a hack at all. It makes perfect sense. > when anyone can just use a different cryptocurrency and not have these problems in the first place? There are 0 (zero) cryptocurrencies that scale better than Bitcoin that don’t also compromise on security or decentralization. Lightning is the best known option which keeps these properties which make Bitcoin desirable in the first place.
    - loveitmore 5y ago
      0 that scale better? XRP performs better at scale and I don’t believe for a second Bitcoin is anymore decentralized. That being said, I don’t know enough about the security aspect - so your claim may end up being correct!
      - 5y ago

CryptoPunk 5y ago

This analysis is complete nonsense because it starts with assumptions that are entirely arbitrary and biased toward the argument of not scaling Bitcoin: >>Bitcoin.org documents the minimum requirements for running a full node, however with the current state of technology, we must substantially lower these requirements so as to make running a full node as accessible as possible to even people in poorer countries No, people in poorer countries only need to be able to write transactions with their own private keys. You can easily find trusted sources of blockchain data, and even poll multiple sources to ensure you are not being fed false information by one source. If your government blocks access to all those sources with a national firewall, you can use a VPN, which is much easier than running a full node, to bypass it. What you don't want is people in poorer countries having to trust third parties with their private keys, which is exactly the result of limiting on-chain throughput so that the vast majority of people use trusted third parties to hold their digital currency and transact it on their behalf. If we take the assumption that only people who have enough bandwidth to stream Netflix 24 hours a day should be able to run a Bitcoin node, we get maximum allowable throughput at least 100X greater than today, and even that requirement is arbitrarily stringent, as Bitcoin could be distributed enough to be impossible to shut down with an even smaller percentage of the world population being capable of running a full node. The analysis also assumes that a user should be able to run a full node with 1. Computing resources they already own for their own personal computing needs. 2. By only utilizing 10% of those resources. Using a dedicated node, with computing resources that the user purchases and utilizes 100% for Bitcoin node operation, is ruled out, again arbitrarily for no reason that would be relevant to a global network attack scenario. Thus the analysis contains assumptions like this: >>But since most Bitcoin users are more affluent, for analysis of current Bitcoin I'll use a range of 250-500 GB for the 90th percentile users, and 500-2000 GB for the top 10%. Note that I'm using wide ranges because I'm less certain about these numbers. In reality, tens of millions of people could easily afford to purchase tens of TB of storage for running dedicated Bitcoin nodes, and tens of millions of people is easily enough to make shutting down or controlling the Bitcoin network impossible for any nation-state actor. So this assumption that Bitcoin nodes need to be able to run on machines with only 500 GB to 2 TB of storage, with only 10% of that, i.e. 50 GB to 200 GB, allocated to running a Bitcoin node, is absolutely absurd. And this is just storage, which the analysis assumes is okay to limit to the top 10% of the global population. For bandwidth, the analysis assumes that 90% of the world population, which includes some of the poorest people in the world, should have enough for running a full node. This idea that the lower classes in India should be running a Bitcoin full node, or else the Bitcoin network will somehow be jeopardized, would be comical if this weren't a serious attempt at swaying public opinion. Basically the analysis is implying that it's okay for it to cost $100 in fees to conduct a single Bitcoin transaction, which is out of reach for even the wealthy in rich countries, but that it is not okay that poor people in India not be able to run a Bitcoin full node on their own device - and let's not forget - while utilizing only 10% of their device's network resources. Just absurd.. To summarize, the analysis assumes that it should be possible to run a Bitcoin node using 10% of the typical personal computing resources of 90% of the world population, when in reality all Bitcoin needs to be shutdown and censorship proof is that it be possible to run a full node using something on order of 500% of the typical personal computing resources of the richest 1% of the world population, i.e. the richest 80 million people, who live in the developed world, given many of those people are willing to purchase dedicated hardware and bandwidth for running a Bitcoin full node, and many would do that if the network actually came under any threat of a coordinated global attack on the network. Considering all this, this analysis could easily be under-estimating how much Bitcoin could increase its throughput by a factor of 1,000X. It's a very disingenuous and biased analysis that obfuscates this fact by being loaded with analysis and data that 1. imply credibility and 2. hide and distract from these totally bogus starting assumptions. Finally, the analysis only considers a physical network attack. The political attack, of countries banning Bitcoin internally, and the best defenses against that, are not considered. In reality, the best defense against a political attack is allowing Bitcoin to scale by 100 or 1,000 times in throughput, to increase the proportion of the population that is economically dependent on the network, and would oppose attempts to politically attack it. And in reality, a political attack is much more likely, and dangerous, to the ability of cryptocurrency to fulfill its potential to financially empower the world's population, than a physical network attack.

billytetrud 5y ago

A little late, but I wanted to mention that I came to work on this because of the debate about block size and scaling ideas around the segwit update. Lots of opinions are generally thrown around without a whole lot of data to back it up, so I wanted to put in the work to make a systematic framework for estimating and comparing alternatives. I wanted to make it easier for other people to evalute what bitcoin's actual bottlenecks are and the way their preferred solution would affect those bottlenecks.

CryptoPunk 5y ago
For a rebuttal to your analysis, please see this: https://news.ycombinator.com/item?id=27136533 https://news.ycombinator.com/item?id=27136533
- deleted 5y ago
  [deleted]

jlrubin 5y ago

Some of my congestion control research that helps large scale users make throughput/latency tradeoffs using simple "transaction templates": https://utxos.org/uses/scaling/ https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/batching_sim/ https://utxos.org/analysis/batching_sim/ https://github.com/bitcoin/bitcoin/pull/21702 https://github.com/bitcoin/bitcoin/pull/21702

billytetrud 5y ago
Thanks Jeremy! Are all those links related to congestion control? In short, that's basically allowing transactions to be shifted from high-congestion times to lower-congestion times without delaying the transfer (eg the transfer from the sender, even if the receive won't get the coins immediately). Is that right? Or are there more benefits of it?
- jlrubin 5y ago
  Hi Billy, yes they all are. 1 -> high level idea, 2 -> basic simulation, 3 -> batching improvements, 4 -> the PR to bitcoin core. I have a lot more material scattered around too :) You understanding of the shifting from high congestion to low is spot on, but there are other benefits. The technique can also be used for more general smart contracts. I've been building a language, https://learn.sapio-lang.org https://learn.sapio-lang.org, for expressing smart contracts. You can do vaults, synthetic derivatives, sidechains, etc with it. One niche point I like to make too, btw, is that the delayed payouts can be into non-interactively initialized payment channels. So you could immediate begin spending/routing payments in the lightning network on open, and wait for low congestion to expand out your UTXO.
  - billytetrud 5y ago
    Ah very interesting. So Sapio is a library for constructing somewhat arbitrary programs using CTV as a mechanism for enabling more turing complete operations? Is Sapio turing complete (or, I guess equivalently would Bitcoin be turing complete with the addition of CTV)? So with non-interactively created channels, I don't quite understand how you would be able to immediately spend/route payments. Don't you always need to interact with your channel partner in order to do both of those things?

bluepnume 5y ago

Take a look at "The Blocksize War" for a fantastic rundown of the events that led to Bitcoin not increasing its throughput. TLDR: Massively rushed changes, pushed by people with a lot of power on the network (miners and corporations), which ended up being largely antithetical to Bitcoin's decentralization thesis. Bitcoin's value is in its stability, its decentralization, and its lack of hurried change. It is in the control of everyone, not just the powerful actors in the system. Its value is not in its ability to pivot every few years like a startup to fulfill some new purpose.

billytetrud 5y ago
> led to Bitcoin not increasing its throughput Bitcoin did increase its blocksize and throughput. It about doubled it in fact. > Its value is not in its ability to pivot every few years like a startup to fulfill some new purpose. Yes, people don't realize that we don't want bitcoin to be agile, move fast and break things. We want it to be well considered, move slowly, and be safe and careful. Similarly, it aggrivates me that people complain about how "congress moves too slow, there's too much deadlock". We shouldn't want lawmaking to move fast. Like bitcoin, it should be slow, methodical, and careful. The problem with US congress is not that its slow, its that it is massively corrupt and opposing sides rush to put things together and then don't cooperate on improving proposals into a considered compromise. Slow compromise is what we want, not fast stubborn corrupt legislators.
- bluepnume 5y ago
  Of course, apologies. Should have been clear I was talking about 2MB+ blocksize rather than segwit. Some great points!

harwoodleon 5y ago

This paper is very considered. But it does not consider that these questions have all been addressed in other cryptocurrencies like Nano (nano.org), which is a far more usable system than Bitcoin. Especially now that “Time as a currency” spam mitigation measures are being rolled out.

billytetrud 5y ago
True, the paper is just about bitcoin specifically. I've read through Nano and the spam problem was #1 in my mind. It seemed to me that there was no possible way to prevent spam in Nano without turning it into a strictly-worse form of cryptocurrency than other proof of work systems. So my determination about Nano was that if it maintained its current course, it would flame out (transactions would increase without bound until no one could run Nano nodes) OR that they would have to change course to something like increasing the transaction PoW, which would increase the work done on end-user machines to the point where its very cumbersome (slow and expensive) to create a transaction. I'm curious to know what "time as a currency" is and how it solves the spam problem. Do you have a good link that explains?