An analysis of Bitcoin's throughput bottlenecks(github.com)
github.com
An analysis of Bitcoin's throughput bottlenecks
https://github.com/fresheneesz/bitcoinThroughputAnalysis
233 comments
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?
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, 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.
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, 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.
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?
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?
Yep! It's an e-dsl essentially, since you write a program and it compiles to bitcoin transactions.
Sapio is turing complete (trivially, you can call any program you can write in regular rust from a Sapio contract). However, the output is a static set of transactions, which is not turing complete. However, if you have an updatable "finish!" clause, then Sapio can generate the logic for a "next step if N parties agree" or something similar, which lets you express the continuation logic in Sapio.
For your last question, I think it is semantics. An "interaction" is (by my perhaps non-standard and definitely inconsistent terms) a back and forth communication between two parties. A non-interactively created channel is set up by either party (or a third party) and then the funds cannot move without the signoff of either party. However there's no guarantee that the funds can move, unless the parties receive a transmission from the creator informing them of the setup (think of this kind of like a memory leak in rust?). This isn't really an interaction as it can happen fully asynchronously, but it's sort of weird because if you don't get it you don't get paid... but assuming the person paying you wanted to pay you, they can try to let you know later!
Then, payments (in one direction, i.e. A->B but not B->A) can be done in the same async half-interactive way. You just get the broadcast and save it to get more money.
This might seem really niche (it is) but carving out these little pockets of what constitutes an interaction opens the door for some really interesting types of devices. E.g., imagine a "low power smart meter" that you can open a channel to and pay multiple times, but the smart meter only has a public key on it, no private key. All state (incl block headers) can be SPV checked and stored locally. Requiring a full interaction means that these devices have to have a private key accessible. This is sort of a contrived example, because there are better ways to make the smart meter, but it shows you the edge that exists at least.
Sapio is turing complete (trivially, you can call any program you can write in regular rust from a Sapio contract). However, the output is a static set of transactions, which is not turing complete. However, if you have an updatable "finish!" clause, then Sapio can generate the logic for a "next step if N parties agree" or something similar, which lets you express the continuation logic in Sapio.
For your last question, I think it is semantics. An "interaction" is (by my perhaps non-standard and definitely inconsistent terms) a back and forth communication between two parties. A non-interactively created channel is set up by either party (or a third party) and then the funds cannot move without the signoff of either party. However there's no guarantee that the funds can move, unless the parties receive a transmission from the creator informing them of the setup (think of this kind of like a memory leak in rust?). This isn't really an interaction as it can happen fully asynchronously, but it's sort of weird because if you don't get it you don't get paid... but assuming the person paying you wanted to pay you, they can try to let you know later!
Then, payments (in one direction, i.e. A->B but not B->A) can be done in the same async half-interactive way. You just get the broadcast and save it to get more money.
This might seem really niche (it is) but carving out these little pockets of what constitutes an interaction opens the door for some really interesting types of devices. E.g., imagine a "low power smart meter" that you can open a channel to and pay multiple times, but the smart meter only has a public key on it, no private key. All state (incl block headers) can be SPV checked and stored locally. Requiring a full interaction means that these devices have to have a private key accessible. This is sort of a contrived example, because there are better ways to make the smart meter, but it shows you the edge that exists at least.
Well, Sapio seems pretty cool. Composable scripts is definitely something we need in Bitcoin.
So basically, the idea of non-interactive channel creation sounds basically like a way for someone to lock in their payment to someone without interacting with them. I suppose I can see the usefulness in that in certain situations. Especially situations where someone that you can interact with does care that you've paid the person who can't interact at the moment.
So basically, the idea of non-interactive channel creation sounds basically like a way for someone to lock in their payment to someone without interacting with them. I suppose I can see the usefulness in that in certain situations. Especially situations where someone that you can interact with does care that you've paid the person who can't interact at the moment.
Yeah, it's also just simpler in general.
E.g., Alice and Bob request that coinbase pay them into a channel. Coinbase can just do it according to the instructions from Alice and Bob, and Alice and Bob can be offline thereafter.
E.g., Alice and Bob request that coinbase pay them into a channel. Coinbase can just do it according to the instructions from Alice and Bob, and Alice and Bob can be offline thereafter.
> 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.
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 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.
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.
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.
> This adds a point of centralization, which defeats the entire purpose of cryptocurrency.
I don't think you get to declare what "the entire purpose of cryptocurrency" is! People tend to get confused about what "trustlessness" actually means. It certainly doesn't mean that every single aspect of every transaction involving cryptocurrency must not require any party to place any trust in another party. If you're using cryptocurrency to buy bread you still need to trust that the baker hasn't poisoned your bread, and that need for trust must be addressed by some mechanism unrelated to cryptocurrency (like the baker's reputation, or laws against poisoning people). That doesn't illustrate some absurdity in the idea of cryptocurrency or "defeat the entire purpose of cryptocurrency."
I don't think you get to declare what "the entire purpose of cryptocurrency" is! People tend to get confused about what "trustlessness" actually means. It certainly doesn't mean that every single aspect of every transaction involving cryptocurrency must not require any party to place any trust in another party. If you're using cryptocurrency to buy bread you still need to trust that the baker hasn't poisoned your bread, and that need for trust must be addressed by some mechanism unrelated to cryptocurrency (like the baker's reputation, or laws against poisoning people). That doesn't illustrate some absurdity in the idea of cryptocurrency or "defeat the entire purpose of cryptocurrency."
We're in agreement that trust is needed at some point in the system. Cryptocurrencies can be completely internally consistent, but have no relationship to the real world. The only way for that relationship to be formed is by trust.
But, there is not a single thing in cryptocurrencies that make sense if you are willing to allow for centralization. If you have a centralized system, then you have a limited number of actors allowed to make changes to the ledger. You can establish trust out-of-band, whether that means by passing around gpg keys, by investigating previous banking practices, or by establishing common rules for auditing. After that, there's no need for Proof of Work/Stake/Space/etc, because you can trust the updates coming from the rest of the network.
The reason I say that the point of cryptocurrency is trustlessness and decentralization is because the only other alternative is that all the implementers of cryptocurrencies are utter fools not to see the simpler solution. I don't think that is the case. I think they have seen the simpler solution of trusted validators, and have dismissed it out of a fundamental difference in priorities from mine, but I don't think they are fools.
But, there is not a single thing in cryptocurrencies that make sense if you are willing to allow for centralization. If you have a centralized system, then you have a limited number of actors allowed to make changes to the ledger. You can establish trust out-of-band, whether that means by passing around gpg keys, by investigating previous banking practices, or by establishing common rules for auditing. After that, there's no need for Proof of Work/Stake/Space/etc, because you can trust the updates coming from the rest of the network.
The reason I say that the point of cryptocurrency is trustlessness and decentralization is because the only other alternative is that all the implementers of cryptocurrencies are utter fools not to see the simpler solution. I don't think that is the case. I think they have seen the simpler solution of trusted validators, and have dismissed it out of a fundamental difference in priorities from mine, but I don't think they are fools.
I’m not sure what you mean. The centralization being discussed here is out of band and thus the trust is also out of band. It’s no different than your local bar opening a tab for you, or using an escrow service for a construction contract.
Because once that centralization occurs, the remaining trustlessness doesn't serve a purpose. All that's happened is switching from one centralized system to another, but with a much, much greater overhead.
Mind you, I don't mind centralized systems, but the entire marketing of cryptocurrencies for the past decade has been how it is decentralized and outside of the the reach of any entity. We knew this wasn't the case in 2014, when Mt Gox folded and all signs pointed to fraud. We knew this wasn't the case in 2016, when the Dao smart contract was reversed by general appeal. We know it now as mining pools continue to rise. The decentralization is the main selling point of cryptocurrencies, and yet at every turn it is proven false.
Mind you, I don't mind centralized systems, but the entire marketing of cryptocurrencies for the past decade has been how it is decentralized and outside of the the reach of any entity. We knew this wasn't the case in 2014, when Mt Gox folded and all signs pointed to fraud. We knew this wasn't the case in 2016, when the Dao smart contract was reversed by general appeal. We know it now as mining pools continue to rise. The decentralization is the main selling point of cryptocurrencies, and yet at every turn it is proven false.
> without massive, massive expenditure as a result.
Could you elaborate on this?
The problem I foresee is that having someone you have to trust is not a bad thing because at least you're able to identify that entity's traits and act accordingly. If that entity is, for example, the world's largest military power, I might feel like I have a lot less to worry about than if they're, as another example, a publicly traded company about half the size of the average major U.S. bank.
Is this what you're alluding to?
Could you elaborate on this?
The problem I foresee is that having someone you have to trust is not a bad thing because at least you're able to identify that entity's traits and act accordingly. If that entity is, for example, the world's largest military power, I might feel like I have a lot less to worry about than if they're, as another example, a publicly traded company about half the size of the average major U.S. bank.
Is this what you're alluding to?
In general, the more people cooperate, the better the results are overall. The downside is that the more people cooperate, the more they can be taken advantage of by defectors, by bad actors who decide to harm the public good in exchange for personal benefit. I absolutely agree that being able to trust particular actors is a huge benefit.
Part of the problem is language. "Trust" isn't just trust in a particular actor's intent, but also in their capabilities to carry through on a promise. In order to trust somebody to carry out a promise, you need to indirectly trust on others not to interfere with that promise. In this case, if you don't trust the US government to handle currency, then you certainly can't trust a publicly traded company that is beholding to work within and has assets that can be seized by the US government. If you assume ill-intent on the part of the government, then there's no reason to assume that a smaller actor wouldn't be influenced by the government.
In this case, I trust the US government to manage currency well, because it is in its best interest to do so.
Part of the problem is language. "Trust" isn't just trust in a particular actor's intent, but also in their capabilities to carry through on a promise. In order to trust somebody to carry out a promise, you need to indirectly trust on others not to interfere with that promise. In this case, if you don't trust the US government to handle currency, then you certainly can't trust a publicly traded company that is beholding to work within and has assets that can be seized by the US government. If you assume ill-intent on the part of the government, then there's no reason to assume that a smaller actor wouldn't be influenced by the government.
In this case, I trust the US government to manage currency well, because it is in its best interest to do so.
This is basically the principle behind a tech on top of bitcoin called lighning network: https://lightning.network
The whole selling point of bitcoin is that it's a decentralised ledger that isn't owned by anybody. If the transactions are managed by a central entity, then that's no longer true. For example, what's to stop such an entity from creating bitcoins out of nothing and thus debasing the bitcoin currency?
Absolutely nothing is preventing it. Depending on your viewpoint, it happened back in 2014, and somehow the cryptocurrency community just sort of shrugged and got back to wildly speculating.
https://en.wikipedia.org/wiki/Mt._Gox
https://en.wikipedia.org/wiki/Mt._Gox
Yeah that's how all centralized crypto exchanges do it
What if there's a run on the exchange?
they suddenly have a 'technical issue' and suspend trading until it is 'fixed.' sometimes its never fixed and the exchange founder mysteriously disappears to Thailand or dies, or claims to start an orphanage in india. sometimes all three.
Just in case you aren't catching on here, cryptocurrencies are not the future. They are just digital tulips - beautiful to look at and comprehend, but separate from any meaningful contribution to the economic system. You can still get rich from them by hyping and selling them before people catch on more broadly.
Civilization works because of laws that are interpreted by courts and norms which are broadly accepted but not often checked/enforced. Crypto is trying to create a "trustless" future where you do not need society to coordinate and regulate. Our modern financial system needs that squishiness/trust which you get from the legal system to operate at full capacity.
Picture the suspension of a car. In our modern financial world, the legal system and regulatory institutions serve as the shocks and struts of your car. It allows you to drive fast while not having to worry about every imperfection on the road. Cryptocurency is like driving a car where your wheels are attached directly to the axel - yes it's perfectly efficient and there's nothing between you and the road, but that also means you have to be exceptionally careful where you are driving, and you can't do it fast.
There's a reason all cars come with suspensions.
Civilization works because of laws that are interpreted by courts and norms which are broadly accepted but not often checked/enforced. Crypto is trying to create a "trustless" future where you do not need society to coordinate and regulate. Our modern financial system needs that squishiness/trust which you get from the legal system to operate at full capacity.
Picture the suspension of a car. In our modern financial world, the legal system and regulatory institutions serve as the shocks and struts of your car. It allows you to drive fast while not having to worry about every imperfection on the road. Cryptocurency is like driving a car where your wheels are attached directly to the axel - yes it's perfectly efficient and there's nothing between you and the road, but that also means you have to be exceptionally careful where you are driving, and you can't do it fast.
There's a reason all cars come with suspensions.
They pause withdrawals while they get their coins out of cold storage.
Or if the exchange isn't fully collateralized, it's a scam and goes under.
Or if the exchange isn't fully collateralized, it's a scam and goes under.
If the blockchain gets backed up it would take a few days to get money in/out of exchanges.
I don't think there can theoretically be a run on the exchange because in theory all the deposits are there, in the exchange, in theory, unlike a bank which only had a fraction of the deposited money in reserve. A run on a crypto exchange would be great for them considering they usually charge a withdrawal fee.
Those aren't withdrawal fees, those are transaction fees for the network. Most cryptocurrencies cost next to nothing for each transaction, while bitcoin and ethereum cost from $20 - $60 USD for the average transaction.
No I'm not confusing it. My exchange and all other exchanges charge a fee to withdrawal money. Its usually quite large.
Again, that fee is not something the exchange is charging you. The fee doesn't go to them.
If it is bitcoin or ethereum there are very high fees for each transaction. The exchange is showing you those fees in your native currency. They aren't getting that money, it is going to the miners.
If it is bitcoin or ethereum there are very high fees for each transaction. The exchange is showing you those fees in your native currency. They aren't getting that money, it is going to the miners.
No you still are misunderstanding what I'm saying. The text on the exchange for me is like "We charge 0.05% fee on all withdrawals NOT INCLUDING the transaction fee to send to your wallet".
If you are not talking about the spread between exchanging two currencies, that should be a GIANT red flag to not use that exchange.
That’s how traditional financial systems work.
Paypal already does this with bitcoin.
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.
It hasn't gotten attention because they just re-centralized using exchanges and off-chain transactions. Just the latest episode of the fugazicoin clown show.
If the transactions are off the chain and to centralized and networked banks I wonder if the 21M coins will hold true for very long... And what happens when bank-run is attempted... As I don't see people staying away from all the fun things they can do with fiat currencies... As at that point the currency on exchanges and between them is fiat.
This is what the lightning network is for. It would be somewhat reasonable to withdraw or deposit to/from your lightning channel a couple times a year. Some other solutions would be needed to get the rest of the way, but improvement is improvement right? Why be so negative about it?
Are there any cryptocurrencies that are attempting to solve this issue?
It is only an issue in the first place because of bitcoin's purposely meniscule throughput. Monero's throughput adapts while bitcoin cash has 32x the max blocksize.
Algorand looks like a promising proof of stake altcoin in my opinion.
https://www.algorand.com/
https://www.algorand.com/
I agree, and I can't believe more people haven't mentioned it here. I am not going to rehash what anyone can read at the linked site, but it seems like an absolutely great project, and seems to be flying under everyone's radar.
Except that it's fairly centralized
That's going to change this fall:
https://algorand.foundation/the-algo/algo-governance
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/
I looked into it and Solana requires "Validator" nodes to be specially blessed by them to get rewards for running their software, so this isn't particularly de-centralized.
[deleted]
I'm interested in how all these other chains deal with people writing tons of junk transactions per second to bloat up the chain.
Having a transaction fee de-incentivizes most people who want to do this
Every junk transaction costs them money
Every junk transaction costs them money
I don't know about other chains, but for ethereum you get money for destroying/freeing up block space. This is how the Chi gas tokens work: they write 0s to the chain when gas is cheap and destroy the blocks when gas is expensive.
From what I’ve seen they don’t
NANO actually just went through a pretty big spam attack and it crippled the network for awhile, but they supposedly came up with a pretty novel solution in the latest version. I haven't dug into it yet though. But NANO is fee-less, so it is (was?) more prone to these types of attacks. Having a fee increases the cost of a spam attack.
In some senses it's not a lot, in other senses it is a lot. Large systems (like the US banking system) only do a few intra-bank settlements per day, 100 tps is well beyond what you need for nation states to do business with eachother.
And then down at the consumer level it's nothing at all. During peak hours of the peak season (Christmas), Visa does something like 50,000 tps.
What makes Bitcoin interesting is the trustlessness of the transfers, and that tends to be more interesting higher up the stack (at the inter-bank and inter-national levels) than at the consumer level. But you can also combine this with layer two technologies like payment channels, ILP (interledger protocol), and the lightning network to get rapid transfers where most of the transactions never hit the chain.
The Sia network for example does something like 30 million transactions per day (that's about 300 tps), but only about 500 of those are actually on-chain at the settlement layer. The rest are ultra efficient off-chain payments that only require a packet or two to be sent between two machines (as opposed to broadcast).
---------
From the perspective of "everyone can own and use bitcoin", 100 tps is not quite enough. To support 1 billion people on Bitcoin even with the best layer 2 systems we have in theory, you need about 400 tps. So 7 billion would need like 3,000 tps.
And then down at the consumer level it's nothing at all. During peak hours of the peak season (Christmas), Visa does something like 50,000 tps.
What makes Bitcoin interesting is the trustlessness of the transfers, and that tends to be more interesting higher up the stack (at the inter-bank and inter-national levels) than at the consumer level. But you can also combine this with layer two technologies like payment channels, ILP (interledger protocol), and the lightning network to get rapid transfers where most of the transactions never hit the chain.
The Sia network for example does something like 30 million transactions per day (that's about 300 tps), but only about 500 of those are actually on-chain at the settlement layer. The rest are ultra efficient off-chain payments that only require a packet or two to be sent between two machines (as opposed to broadcast).
---------
From the perspective of "everyone can own and use bitcoin", 100 tps is not quite enough. To support 1 billion people on Bitcoin even with the best layer 2 systems we have in theory, you need about 400 tps. So 7 billion would need like 3,000 tps.
> What makes Bitcoin interesting is the trustlessness of the transfers, and that tends to be more interesting higher up the stack (at the inter-bank and inter-national levels) than at the consumer level
What's interesting about that? Higher up the stack, trustlessness is not compelling at all - if I'm transacting with you on the scale of six-plus figures, I absolutely won't transact with someone I don't trust, and anonymity is a defect - I want to know who you are so I can sue you if our deal goes sideways.
What's interesting about that? Higher up the stack, trustlessness is not compelling at all - if I'm transacting with you on the scale of six-plus figures, I absolutely won't transact with someone I don't trust, and anonymity is a defect - I want to know who you are so I can sue you if our deal goes sideways.
The whole point of a trustless transaction is that you don't need to worry about who the counterparty is. You don't need the leverage to sue somebody because fraud is not possible. For digital transactions, the lack of trust can be two-way - two mutually distrusting people can confidently exchange Bitcoin for Ethereum in a transaction, because the software and math behind the blockchain prevents fraud from happening at all.
For meatspace the best you can do is one-way. If I'm buying a car with Bitcoin, I still need to trust the car manufacturer to deliver, but the car manufacturer does not need to trust me. They don't need to know who I am or how deep my credit line is, as soon as the bitcoin hits their wallets they have extreme confidence that the transaction won't be reverted. No bounced checks, no chargebacks, etc. It's a zero fraud system, and there's also no intermediate party (like PayPal or a bank) that can decide the transaction shouldn't happen. Whether or not the payment is accepted is at the sole discretion of the recipient.
For meatspace the best you can do is one-way. If I'm buying a car with Bitcoin, I still need to trust the car manufacturer to deliver, but the car manufacturer does not need to trust me. They don't need to know who I am or how deep my credit line is, as soon as the bitcoin hits their wallets they have extreme confidence that the transaction won't be reverted. No bounced checks, no chargebacks, etc. It's a zero fraud system, and there's also no intermediate party (like PayPal or a bank) that can decide the transaction shouldn't happen. Whether or not the payment is accepted is at the sole discretion of the recipient.
> The whole point of a trustless transaction is that you don't need to worry about who the counterparty is. You don't need the leverage to sue somebody because fraud is not possible.
Payment reversal is not possible, fraud is still just as possible as it is with a traditional transaction. If I were selling a fake van Gogh, I'd prefer BTC for the transaction, but if I were selling a legit van Gogh I'm not worried about being sued over, a wire would suffice. I would think more than twice about transacting with anyone in large amounts who insists on transacting in BTC.
Payment reversal is not possible, fraud is still just as possible as it is with a traditional transaction. If I were selling a fake van Gogh, I'd prefer BTC for the transaction, but if I were selling a legit van Gogh I'm not worried about being sued over, a wire would suffice. I would think more than twice about transacting with anyone in large amounts who insists on transacting in BTC.
> Whether or not the payment is accepted is at the sole discretion of the recipient.
Forgot to mention - no? This isn't how the protocol works, you have zero discretion about whether to accept payment or not in BTC. If ISIL sends your wallet a million dollars then that's that, you've just received money from a terrorist group, the whole world knows it, and now the feds want to talk to you.
Forgot to mention - no? This isn't how the protocol works, you have zero discretion about whether to accept payment or not in BTC. If ISIL sends your wallet a million dollars then that's that, you've just received money from a terrorist group, the whole world knows it, and now the feds want to talk to you.
I'm sure the banks will love when they their lowly paid employee/contractor accidentally moves the money to wrong address or some bit flip happens... Or targeted attack...
With current system money is still somewhere and you can drag them to court as final step. With crypto, no luck it is just lost.
With current system money is still somewhere and you can drag them to court as final step. With crypto, no luck it is just lost.
And yet, people do huge deals involving millions of crypto everyday.
When you're talking international, there is little trust and little legal recourse. It is absolutely a problem that bitcoin can solve exceptionally well.
This is a great way to put it. If you look at settlement times 3tps is great. If you’re actively transacting as a consumer then that won’t cut it.
It can be enough when combined with layer 2 solutions as well. But you can't get around the nature of reality.
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...
[1]https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...
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.
>problem with the bch people was that they were reckless and dishonest
Anything relevant you would like to share to back up this claim?
Anything relevant you would like to share to back up this claim?
There were opportunists on both sides but the blockstream people argued that purely observational non-mining nodes somehow 'secure' the network despite having no effect and need to be possible to run with a non-broadband connection and less than 100GB of free disk space. Satoshi himself in the Bitcoin whitepaper estimated higher bandwidth and storage requirements for nodes than what the blockstream employed devs said were too high. The point of Wall Street getting involved was to kill Bitcoin as a currency and turn it into a pure speculator's playground. (aka bitcoin as gold)
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.
The arguments against SPV wallet use in this text don’t ring true for me.
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.
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.
>since any cap you set it to will also be arbitrary
Unless you done quantitative analysis into the most appropriate blocksize. But that will never happen at this stage.
Unless you done quantitative analysis into the most appropriate blocksize. But that will never happen at this stage.
There are some very important changes happening in bitcoin (taproot, eltoo, lightning). Devs aren't opposed to protocol changes, they are opposed to ill-thought changes that make it less decentralized and weaker.
Since when does Lightning Network not make it less decentralized? That's news to me
[deleted]
Wrong, they are opposed to changes that will stop them from profiteering off higher layer solutions they provide.
Bitcoin incorporated Compact Blocks which similar improves average case behavior.
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...
Things like thinblocks or compact blocks only help on average. Bitcoin must be robust for worst case.
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...
Things like thinblocks or compact blocks only help on average. Bitcoin must be robust for worst case.
For anyone who joined late: https://www.reddit.com/r/btc/comments/61mxuj/block_size_limi...
The lower transaction throuput,the higher the fees, the higher the incentive for the miners to process transactions.
They probably don't want to mess with that dynamic too harshly.
They probably don't want to mess with that dynamic too harshly.
this was the debate circa 2014/2015. Should the bitcoin network consist of many low fee transactions or few high fee transactions. Right now the incentive for miners to secure the network is produced with the block reward, but when the block reward runs out this incentive will be from fees alone. In order to provide miners with the same revenue as today when the block reward runs out, the average fee per tx will need to be close to $200. If you increase the block size to 100mb and use block compression tech like xthinner to make blocks essentially 1mb (like today), then the average fee needed is only $2.
>use block compression tech like xthinner to make blocks essentially 1mb (like today), then the average fee needed is only $2.
Claiming that xthinner can reduce 100mb blocks down to 1mb is dishonest. It might reduce the network transfer down to 1mb (assuming you already the txes), but on-disk storage would stay the same.
https://news.ycombinator.com/item?id=25688004
Claiming that xthinner can reduce 100mb blocks down to 1mb is dishonest. It might reduce the network transfer down to 1mb (assuming you already the txes), but on-disk storage would stay the same.
https://news.ycombinator.com/item?id=25688004
A single transaction costs more than the space to store the entire chain many times over.
block propagation was the main reason for being opposed to a block size increase, storage costs were debunked time and time again as being irrelevant.
Why many low fee transactions were not chosen?
You'll get many different responses to this question depending on who you ask. If you want to read into further i recommend you read the great scaling debate[1]. Its pretty long but does a fantastic job of summarizing the history.
In short the most popular reason for not having a block size increase (to allow many low fee transactions) was that it would increase the cost of running a full node, in turn centralising the network. More transactions would mean nodes would need a bigger hard drive and a better cpu to process the transactions. The small block camp wanted people to be able to run nodes on a raspberry pi. This theory is misguided in my opinion though, they chose to sacrifice cheap transactions to keep node running costs cheap.
[1]https://medium.com/hackernoon/the-great-bitcoin-scaling-deba...
In short the most popular reason for not having a block size increase (to allow many low fee transactions) was that it would increase the cost of running a full node, in turn centralising the network. More transactions would mean nodes would need a bigger hard drive and a better cpu to process the transactions. The small block camp wanted people to be able to run nodes on a raspberry pi. This theory is misguided in my opinion though, they chose to sacrifice cheap transactions to keep node running costs cheap.
[1]https://medium.com/hackernoon/the-great-bitcoin-scaling-deba...
They (the devs that control the repo that almost all miners run code from) chose to stifle the base layer to profit from higher layers using 'goat herders should be able to run a full node' as the excuse.
Because Bitcoin works in a way that means miners, collectively, control the network.
They voted with their hash power against Bitcoin Cash when it forked, which was the “increase the limit” fork aiming at low fees and high number of transactions.
Those miners can now enjoy high fees as a result.
They voted with their hash power against Bitcoin Cash when it forked, which was the “increase the limit” fork aiming at low fees and high number of transactions.
Those miners can now enjoy high fees as a result.
In my experience, I have seen literally 0 devs that are trying to increase miner profits. No one is worried that miners aren't getting paid enough.
The miners control the network, longest chain and all that.
They also have lots of money to pay for devs.
Foolish to think a bunch of open source devs are controlling the protocol in defiance of miners who would rather they do something else.
They also have lots of money to pay for devs.
Foolish to think a bunch of open source devs are controlling the protocol in defiance of miners who would rather they do something else.
This is the real reason for the block size cap.
Why not fork? Sure, it may no longer be Bitcoin Core... but legitimate non-backwards compatible forks seem like a good reason to start a new chain
this is exactly what bitcoin cash is
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.
For a rebuttal to your analysis, please see this:
https://news.ycombinator.com/item?id=27136533
https://news.ycombinator.com/item?id=27136533
[deleted]
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
>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?
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?
Ethereum has 8 distinct active layer 2 technologies including things analogous to lightning network, as they are permissionless to build and deploy there.
Turns out nobody likes watchtowers which lightning style solutions require, the market is not choosing that
Bitcoin does not represent choice, it represents throwing all eggs in one basket and defending that with no competition (lightning). More like a state capital system.
Turns out nobody likes watchtowers which lightning style solutions require, the market is not choosing that
Bitcoin does not represent choice, it represents throwing all eggs in one basket and defending that with no competition (lightning). More like a state capital system.
> Bitcoin does not represent choice
Why not? Anyone can use bitcoin for anything they want. And any other cryptocurrency can compete with bitcoin if they want (and clearly many try). Seems we have plenty of choice in the market at the cryptocurrency moment.
The difference is that in Bitcoin land, people cooperate to build standards. In Ethereum, far fewer standards are created, and instead people just build whatever Ethereum based project they want and try to sell that. So yes, there are more choice, but the quality of those choices is a lot lower. For example, in Bitcoin there's one lightning network standard, and many wallets that implement that stanrdard. By contrast there's a ton of layer 2 networks on Ethereum and none of them interoperate and each one has a single implementation (generally).
> nobody likes watchtowers
The number of bitcoin lightning nodes has been constantly growing since its inception, and pretty much every metric is at an all time high: https://bitcoinvisuals.com/lightning . So .. I think you're not correct there.
Why not? Anyone can use bitcoin for anything they want. And any other cryptocurrency can compete with bitcoin if they want (and clearly many try). Seems we have plenty of choice in the market at the cryptocurrency moment.
The difference is that in Bitcoin land, people cooperate to build standards. In Ethereum, far fewer standards are created, and instead people just build whatever Ethereum based project they want and try to sell that. So yes, there are more choice, but the quality of those choices is a lot lower. For example, in Bitcoin there's one lightning network standard, and many wallets that implement that stanrdard. By contrast there's a ton of layer 2 networks on Ethereum and none of them interoperate and each one has a single implementation (generally).
> nobody likes watchtowers
The number of bitcoin lightning nodes has been constantly growing since its inception, and pretty much every metric is at an all time high: https://bitcoinvisuals.com/lightning . So .. I think you're not correct there.
There are many standards on Ethereum. There are also many people building their own things to try and extract value for themselves.
Bitcoin has some obscure things besides lightning due to the permissionless nature as well, but the limitations come from the block space and the smaller set of operations allowed
The comparison about what the market chose comes from TVL and volume metrics. see www.defipulse.com which also includes lightning
Bitcoin has some obscure things besides lightning due to the permissionless nature as well, but the limitations come from the block space and the smaller set of operations allowed
The comparison about what the market chose comes from TVL and volume metrics. see www.defipulse.com which also includes lightning
Decentralized cryptocurrency tech is in its infancy. Just like you wouldn't standardize on programming languages in the 50s, it makes no sense to already talk about standardizing things that are under active research.
Ethereum shards share security, so you can't just do a 51% attack on one shard.
Zkrollups on Ethereum have the same security properties as on-chain transactions, with no need for monitoring and no withdrawal delays. That can't be said for the LN.
Zkrollups on Ethereum have the same security properties as on-chain transactions, with no need for monitoring and no withdrawal delays. That can't be said for the LN.
Sharding is fraught with issues. One fundamental issue is that by the very nature of sharding, you have fewer nodes on each shard, which makes it easier to perform sybil attacks on a particular shard. Shards aren't a pancia. Also, if you have, say, 10 shards - that isn't giving you 10x throughput. Its gonna give you maybe 2x throughput because what shards are doing is allowing lower-power machines help run the network, and those lower-power machines are not as effective as the rest, so they aren't contributing as much. I mean, its not cut and dry because there may be a lot of extra machines depending on the state of the network and resource requirements, but its generally not a linear relationship there.
All nodes validate the root hash of every shard, so no, a Sybil attack on one shard is no easier than on the entire blockchain.
It may even be harder, as there would be more nodes in total when the hardware/network resources a person needs to run a node decline from what's needed to validate the whole blockchain, to what's needed validate the fraction of the blockchain contained in one shard, or conversely, when 64X more economic activity, and thus more people, are utilizing the blockchain, as a result of the scalability boost provided by dividing the blockchain into 64 shards.
>>Also, if you have, say, 10 shards - that isn't giving you 10x throughput. Its gonna give you maybe 2x throughput because what shards are doing is allowing lower-power machines help run the network, and those lower-power machines are not as effective as the rest, so they aren't contributing as much.
They don't have to be lower power machines. If the blockchain is divided into 64 shards, then the total network throughput can increase by 64X with the power requirements of validating machines not changing.
It may even be harder, as there would be more nodes in total when the hardware/network resources a person needs to run a node decline from what's needed to validate the whole blockchain, to what's needed validate the fraction of the blockchain contained in one shard, or conversely, when 64X more economic activity, and thus more people, are utilizing the blockchain, as a result of the scalability boost provided by dividing the blockchain into 64 shards.
>>Also, if you have, say, 10 shards - that isn't giving you 10x throughput. Its gonna give you maybe 2x throughput because what shards are doing is allowing lower-power machines help run the network, and those lower-power machines are not as effective as the rest, so they aren't contributing as much.
They don't have to be lower power machines. If the blockchain is divided into 64 shards, then the total network throughput can increase by 64X with the power requirements of validating machines not changing.
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?
Why use this complicated hack solution when anyone can just use a different cryptocurrency and not have these problems in the first place?
> 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.
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.
There is at least monero, bitcoin cash and ethereum. Bitcoin Cash and Ethereum both have more transactions than bitcoin already. Ethereum has four times the transaction throughput. Bitcoin Cash has 32x the max block size. There is no technical reason bitcoin could not increase their max block size, but then there would be no reason for their hacky second layer to exist.
The only way what you are saying makes sense is if you decide to for some reason define security as "bitcoin's hashing and has rate".
No one is doing any sort of mining attacks on bitcoin cash, monero or ethereum.
Like the "lightning network" the only way to pretend it is necessary is to pretend it solves a made up problem.
The only way what you are saying makes sense is if you decide to for some reason define security as "bitcoin's hashing and has rate".
No one is doing any sort of mining attacks on bitcoin cash, monero or ethereum.
Like the "lightning network" the only way to pretend it is necessary is to pretend it solves a made up problem.
> There is no technical reason bitcoin could not increase their max block size
You should read the paper this thread is about. It tells you tons of technical reasons that it would be a bad idea to increase the max block size very much if at all.
You should read the paper this thread is about. It tells you tons of technical reasons that it would be a bad idea to increase the max block size very much if at all.
It doesn’t really though.
It makes laughable claims like miners have only 94KB of bandwidth.
It’s the same old fud that says SPV is unsafe for the average user, Moore’s law is nonexistent, and even then makes crazy lowball assumptions about what hardware and network connectivity people have.
It’s basic fallacy is the same old one that says every user needs to download and validate the entire chain and all transactions to use Bitcoin.
If that’s true it’s going nowhere anyway.
It makes laughable claims like miners have only 94KB of bandwidth.
It’s the same old fud that says SPV is unsafe for the average user, Moore’s law is nonexistent, and even then makes crazy lowball assumptions about what hardware and network connectivity people have.
It’s basic fallacy is the same old one that says every user needs to download and validate the entire chain and all transactions to use Bitcoin.
If that’s true it’s going nowhere anyway.
Ethereum has increased its max block size 7+ times in the last 5 years and has had zero issues doing so. “Papers” from technically illiterate authors that ignore very real, tangible evidence contradicting them are about as useful as flat earth “math”.
Yeah no shit you can just increase the block size. That doesn’t result in better asymptotic scaling.
Spinning up an ethereum full node (“archive node”) is way harder than spinning up a Bitcoin full node, partially because the eth blockchain is over 7TB vs about 300GB for BTC.
Spinning up an ethereum full node (“archive node”) is way harder than spinning up a Bitcoin full node, partially because the eth blockchain is over 7TB vs about 300GB for BTC.
Mimblewimble improves on Bitcoin's scalability by allowing all spent outputs to be removed from the Initial Block Download.
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!
That being said, I don’t know enough about the security aspect - so your claim may end up being correct!
XRP isn't decentralized at all... Bitcoin is absolutely far far far more decentralized than a currency that is wholely controlled by a single company.
Define decentralized.
Ripple owns a lot of XRP(in escrow). That is the only claim of centralization that is true. The network has equal or greater decentralization than BTC.
Ripple owns a lot of XRP(in escrow). That is the only claim of centralization that is true. The network has equal or greater decentralization than BTC.
>What scaling technologies do they have? The ones I'm aware of are
Not Eth, but you're missing one option - tree graph based. They've pushed 3000+ TPS through it already in testnets...and that's on layer 1. High level description:
https://confluxnetwork.medium.com/tree-graph-structure-of-co...
>or layer 2 on BTC, aka lightning network?
Indeed - that could work. I do think Eth has the edge though. Throughput only matters if you have an eco-system that needs it ultimately.
Not Eth, but you're missing one option - tree graph based. They've pushed 3000+ TPS through it already in testnets...and that's on layer 1. High level description:
https://confluxnetwork.medium.com/tree-graph-structure-of-co...
>or layer 2 on BTC, aka lightning network?
Indeed - that could work. I do think Eth has the edge though. Throughput only matters if you have an eco-system that needs it ultimately.
> They've pushed 3000+ TPS through it already in testnets
Whenever someone says something like "they've tested it with X throughput", it usually means that they're not considering security properties. Sure, you can push throughput through on test machines in a test setting and it will happen. But in an adversarial environment, systems pushed to those limits can often be attacked. Its not sufficient to test throughput in normal conditions. You have to go through every attack vector and test the throughput during attacks and ensure the throughput you're pushing through isn't making those attacks easier to pull off.
Centralized systems can push plenty of throughput. The question is not: "How fast can we make this system run?", the question is "how fast can we make this system run WHILE keeping its properties of decentralization and resilience against attacks?".
Whenever someone says something like "they've tested it with X throughput", it usually means that they're not considering security properties. Sure, you can push throughput through on test machines in a test setting and it will happen. But in an adversarial environment, systems pushed to those limits can often be attacked. Its not sufficient to test throughput in normal conditions. You have to go through every attack vector and test the throughput during attacks and ensure the throughput you're pushing through isn't making those attacks easier to pull off.
Centralized systems can push plenty of throughput. The question is not: "How fast can we make this system run?", the question is "how fast can we make this system run WHILE keeping its properties of decentralization and resilience against attacks?".
>usually means that they're not considering security properties.
They claim they have managed security, scalability and decentralization. I'm in no position to evaluate this. However they've got Sequoia onboard, plus a Turing award winner, plus Shanghai gov and team is full of PhDs...so I figured good enough for me.
They claim they have managed security, scalability and decentralization. I'm in no position to evaluate this. However they've got Sequoia onboard, plus a Turing award winner, plus Shanghai gov and team is full of PhDs...so I figured good enough for me.
You would think so, but there have not actually been any meaningful scaling improvements that don’t boil down to “trust a centralized authority”. Taking all factors into account, Lightning is currently the best known option (although it is fairly complicated).
What's better about Ethereum in this regard? People are still looking to Bitcoin because its substantially larger than Ethereum in pretty much every way (development, market cap, awareness, etc), its got a way better track record than Ethereum, its far more decentralized (Vitalik is still the god of Ethereum). There's lots of reasons people still look to Bitcoin.
> Surely one of the newer generation like eth is better suited?
Why surely?
> Surely one of the newer generation like eth is better suited?
Why surely?
Bitcoin is essentially dead development wise, virtually all exciting development is happening on ETH.
I hear much more talk about ethereum than I do about BTC.
He'll, I don't even have a personal BTC wallet and no one I know does either. Everything is ERC20: if you want BTC exposure, you hold WBTC not BTC.
He'll, I don't even have a personal BTC wallet and no one I know does either. Everything is ERC20: if you want BTC exposure, you hold WBTC not BTC.
Isn‘t ETH in the vicinity of an order of magnitude to Bitcoin's market cap etc?
Which is „pretty much the same“ in crypto terms.
Which is „pretty much the same“ in crypto terms.
There is substantially more development on Ethereum:
https://medium.com/electric-capital/electric-capital-develop...
There is also substantially more economic activity on Ethereum, with users paying 10X more fees to utilize it over the last 7 days:
https://twitter.com/iamDCinvestor/status/1392468184482164741
https://medium.com/electric-capital/electric-capital-develop...
There is also substantially more economic activity on Ethereum, with users paying 10X more fees to utilize it over the last 7 days:
https://twitter.com/iamDCinvestor/status/1392468184482164741
I'm skeptical of a few things in the medium post, for instance if you compare the etherium's ERC20 defi ecosystem to bitcoin, you will get more git repositories because there are simply more coins.
Secondly, more is not always better, and measuring developer activity by git repositories is like measuring lines of code as a metric for the amount of work being done.
Because right now Bitcoin can only do currency, whereas Ethereum (and some other crypto's) can do anything a computer can do, since they are turing complete.
Granted there are projects on Bitcoin, like rootstock, that have the goal of adding the capability, but my personal take (and I think a lot of others) from being in the space many years, is that its unlikely these will ever get released and/or adpoted.
Granted there are projects on Bitcoin, like rootstock, that have the goal of adding the capability, but my personal take (and I think a lot of others) from being in the space many years, is that its unlikely these will ever get released and/or adpoted.
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-...
It looks like you are explaining some good stuff in that blog post, but the overall arrangement and writing style of the post reduces it's impact.
Your post could be more influential if you refined it through a technical writing type process - perfecting the ordering of presenting information for the audience you hope to persuade.
Your post could be more influential if you refined it through a technical writing type process - perfecting the ordering of presenting information for the audience you hope to persuade.
This is true, but that's not the only post I had on the subject, just the earliest one. Anyway, I gave up on btc and now implementing xln on eth https://github.com/homakov/xlncontracts/blob/main/contracts/...
Bitcoin dominance always goes down in altcoin season and then comes right back up.
I was a 100% bitcoiner 2014 to 2020, but after exploring defi and L2 projects in pipeline, i decided this time is different and converted to eth. That's just my opinion.
To me, it's like gold=Bitcoin, I can fully trust it and know that it will be here in 100 years from now, functioning just the same and that my wallet from today will be perfectly functional, and oil=Ethereum, it's an awesome platform that allows me to run a variety of different financial operations with different assets (including Bitcoin), but it's much more nimble, things are a lot less set in stone and I frankly have no idea what it'll look like in 100 years from now or even if it will still be the dominant defi platform.
A parallel is like, today we only have 1 thing that's gold and many banks/financial institutions that provide variety of services. All these institutions combined are worth a lot of money (the largest banks combined have roughly ~2T$ in market cap[1]), but gold market cap is like 11T$.
Just my 2 cents, I own both and hope both succeed.
1: https://www.statista.com/statistics/431751/leading-banks-usa...
A parallel is like, today we only have 1 thing that's gold and many banks/financial institutions that provide variety of services. All these institutions combined are worth a lot of money (the largest banks combined have roughly ~2T$ in market cap[1]), but gold market cap is like 11T$.
Just my 2 cents, I own both and hope both succeed.
1: https://www.statista.com/statistics/431751/leading-banks-usa...
But do you hold BTC or WBTC? Among people I know, actually havinf a BTC wallet is pretty rare.
The ethereum ecosystem is just so rich that there's no reason to leave it, well, maybe bsc and solana, but that's it.
The ethereum ecosystem is just so rich that there's no reason to leave it, well, maybe bsc and solana, but that's it.
Meanwhile, crypto indexers beat Bitcoin maximalists. But, the evidence for indexing performance will never see the light of day . :)
Not sure what you mean by crypto indexer, you mean people who buy a basket of crypto? Sure, in the short term, they might outperform BTC, over long term 70% will die, 90+% won't recover to their ATHs. If you indexed back in 2017 into top 10 coins, only like 3 of them crossed their old prices from 2017, rest are as good as dead.
Usually you'd rebalance periodically.
Seems like stuff folks say in a bubble. 90% of it will disappear once ethereum fixes this/that.
Where did you get these numbers? I assume this is a post-hoc rationalization?
I mean you can pull up the numbers for yourself if you don't believe me, people have also done the math themselves [1][2].
1: https://preview.redd.it/c21qium7jyr61.png?width=1113&format=...
2: https://www.reddit.com/r/CryptoCurrency/comments/mmstrt/i_bo...
1: https://preview.redd.it/c21qium7jyr61.png?width=1113&format=...
2: https://www.reddit.com/r/CryptoCurrency/comments/mmstrt/i_bo...
This is useful. Good numbers. Thank-you.
>But, the evidence for indexing performance will never see the light of day . :)
Why not? If such evidence exists why aren't you presenting it?
Why not? If such evidence exists why aren't you presenting it?
You'll note that my comment was downvoted. This evidence is immoral. Thus, it won't be aired.
You can go to pandaanalytics.com if you'd like, and play with their index options. See what strategies have worked well. (I weight by market cap, top-10, no stablecoins)
You can go to pandaanalytics.com if you'd like, and play with their index options. See what strategies have worked well. (I weight by market cap, top-10, no stablecoins)
Your comment was downvoted, likely due to claims with no evidence but instead a story about how you're about to be silenced. You could've just posted something to support your position instead and we'd skip all the drama in this exchange.
Is this really drama? I don't actually care if I'm downvoted. People will always upvote iced cream, and downvote brocolli. It's not hard to see that, or understand why that would be the case. Mostly I find it funny.
Your proposal isn't trustless anymore. At that point, why not just have normal centralized bank accounts?
You wrote that article in 2018 too, what do you think about the state of the LN now, where its no longer common to get payment failures?
You wrote that article in 2018 too, what do you think about the state of the LN now, where its no longer common to get payment failures?
> Your proposal isn't trustless anymore
not black and white. I didn't say to drop collateral channels to have credit, but to use credit in addition to collateral on receiving side. Also, on ETH those credits are enforceable (as i answered below) so it is far better than a custodial balance.
> where its no longer common to get payment failures?
nothing changed, the inbound capacity flaw is fundamental. Download a wallet - you can't receive a payment - full stop. Until this is solved say goodbye to adoption. With credits on both sides the total capacity of the network skyrockets. And somebody is taking the risks anyway, either liquidity providers as in delusional LN model, or users themselves as in XLN.
not black and white. I didn't say to drop collateral channels to have credit, but to use credit in addition to collateral on receiving side. Also, on ETH those credits are enforceable (as i answered below) so it is far better than a custodial balance.
> where its no longer common to get payment failures?
nothing changed, the inbound capacity flaw is fundamental. Download a wallet - you can't receive a payment - full stop. Until this is solved say goodbye to adoption. With credits on both sides the total capacity of the network skyrockets. And somebody is taking the risks anyway, either liquidity providers as in delusional LN model, or users themselves as in XLN.
> where its no longer common to get payment failures
Sorry but they're still incredibly common
Sorry but they're still incredibly common
Payment channels ARE credit, generally - I'm sorry this proposal was rejected. Was there a reason for the rejection?
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.
Rejection reason: unclear, doesn't fit the narrative.
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.
Unless you value the time your money that is locked up at zero, they are definitely credit - as GP said, fully-collateralized loans.
Interesting.
> Also, uninsured balances are enforceable onchain, which is very different from a trusted balance.
Does this mean XLN is implemented with a smart contract that withdraws the money from an address if you fail to pay? Or automatically cancels the channel if you withdraw more than what you have in the channel?
> Also, uninsured balances are enforceable onchain, which is very different from a trusted balance.
Does this mean XLN is implemented with a smart contract that withdraws the money from an address if you fail to pay? Or automatically cancels the channel if you withdraw more than what you have in the channel?
It's better explained in solidity:
https://github.com/homakov/xlncontracts/blob/main/contracts/...
it is withdrawn from a special intermediary "reserve" balance OR a Debt is created on this identity.
https://github.com/homakov/xlncontracts/blob/main/contracts/...
it is withdrawn from a special intermediary "reserve" balance OR a Debt is created on this identity.
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/
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.
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.
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.
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.
Bitcoin's Proof of Work algorithm has linear scaling. Basically 100,000 nodes all trying to build consensus using Nakamoto PoW can do it in O(100,000) messages. The scaling factor on the number of miners is not what is a bottleneck here.
The main bottleneck for cryptocurrencies is that every single node has to validate every single transaction. So your global throughput is effectively limited to what a single node can process.
Technologies like STARKs can improve these bottlenecks without introducing new trust layers or trust assumptions but still carry data availability requirements which once again require every node to have all the data, even if they don't have to actually process all the data.
There are additional techniques you can use to minimize the data availability impact but then you start introducing trust assumptions again.
It's a tricky problem and there's a good reason none of the major chains have adopted a solution, but it's not as dire as your post suggests, nor does your post highlight any of the fundamental issues at play.
The main bottleneck for cryptocurrencies is that every single node has to validate every single transaction. So your global throughput is effectively limited to what a single node can process.
Technologies like STARKs can improve these bottlenecks without introducing new trust layers or trust assumptions but still carry data availability requirements which once again require every node to have all the data, even if they don't have to actually process all the data.
There are additional techniques you can use to minimize the data availability impact but then you start introducing trust assumptions again.
It's a tricky problem and there's a good reason none of the major chains have adopted a solution, but it's not as dire as your post suggests, nor does your post highlight any of the fundamental issues at play.
> The main bottleneck for cryptocurrencies is that every single node has to validate every single transaction. So your global throughput is effectively limited to what a single node can process
literally what I said in my post. the mining aspect was your addition, not mine. I am describing an idealized model which doesn't even consider the added complication of mining to incentivise playing by the rules(let's assume coins are issued based on signs from, say, zeus). just simple consensus on a single 0/1 truth value.
this is the hard scalability problem, and people claiming to fix it are ultimately bound to create hierarchies of truth authority, undermining decentralization and recreating the existing concentric power structure (with themselves in the center) they claim to obsolete.
literally what I said in my post. the mining aspect was your addition, not mine. I am describing an idealized model which doesn't even consider the added complication of mining to incentivise playing by the rules(let's assume coins are issued based on signs from, say, zeus). just simple consensus on a single 0/1 truth value.
this is the hard scalability problem, and people claiming to fix it are ultimately bound to create hierarchies of truth authority, undermining decentralization and recreating the existing concentric power structure (with themselves in the center) they claim to obsolete.
Yeah I was thinking the same thing. I know nothing compared to many of the posters on this thread.
But it seems like decentralization and gas fees/tps are going to be inversely correlated no?
But it seems like decentralization and gas fees/tps are going to be inversely correlated no?
There is an example of directly scaling PoW that's been in prod for 1.5 years now: https://explorer.chainweb.com/mainnet
Instead of having X PH of PoW difficulty for a single blockchain, you have N parallel blockchains with ~X/N PH difficulty. Same energy needs, N*single chain performance. The coolest bit being that N can increase in an upgrade w/o needing to increase energy consumption, should the network gain traction and need more throughput. It upgraded from 10 to 20 chains last summer.
Other cool bit is that each chain runs a formally verifiable LISP (Pact)... I jokingly refer to Kadena as "a multithreaded LISP machine in the sky".
Disclaimer: I designed the Chainweb consensus algorithm
Instead of having X PH of PoW difficulty for a single blockchain, you have N parallel blockchains with ~X/N PH difficulty. Same energy needs, N*single chain performance. The coolest bit being that N can increase in an upgrade w/o needing to increase energy consumption, should the network gain traction and need more throughput. It upgraded from 10 to 20 chains last summer.
Other cool bit is that each chain runs a formally verifiable LISP (Pact)... I jokingly refer to Kadena as "a multithreaded LISP machine in the sky".
Disclaimer: I designed the Chainweb consensus algorithm
What are the data availability requirements in a chain whose header commits to UTXO set Merkle Mountain Range peaks, where tx inputs come with Merkle proofs up to an MMR peak, and the miner adds a STARK proof of existence of a valid history?
> has anyone ever done the modeling on the dynamic limits of decentralized network consensus?
I did in the paper this post is about (in the context of bitcoin). Look at the section on Miner Centralization Pressure: https://github.com/fresheneesz/bitcoinThroughputAnalysis#min...
> these high tps coins all seem to get around this by weakening decentralization
Yes, that's true.
> in order for every node to have an equal influence on the validity of every other node's vote
The trick is to ensure that distance does not play a substantial role in a node's "vote". That's one reason that blocks must take so much time to be mined in bitcoin (10 minutes). Proof of work systems that have less-than-a-minute block times are just not very safe. It takes time for lots of entities to come to a consensus across the whole world.
> 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.
Yeah, there are physical limits. The speed of light is the ultimate limit here. You can't come to a consensus with someone faster than you can send and receive a response from them. And the minimum requirements for consensus probably require a lot more than one message and one response.
I did in the paper this post is about (in the context of bitcoin). Look at the section on Miner Centralization Pressure: https://github.com/fresheneesz/bitcoinThroughputAnalysis#min...
> these high tps coins all seem to get around this by weakening decentralization
Yes, that's true.
> in order for every node to have an equal influence on the validity of every other node's vote
The trick is to ensure that distance does not play a substantial role in a node's "vote". That's one reason that blocks must take so much time to be mined in bitcoin (10 minutes). Proof of work systems that have less-than-a-minute block times are just not very safe. It takes time for lots of entities to come to a consensus across the whole world.
> 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.
Yeah, there are physical limits. The speed of light is the ultimate limit here. You can't come to a consensus with someone faster than you can send and receive a response from them. And the minimum requirements for consensus probably require a lot more than one message and one response.
Ethereum layer 1 is processing closer to 20 per second. In particular, it did 1716000 in the last 24 h.
Ethereum's layer 2 can handle tens of thousands transactions per second. These are then settled on chain as a single transaction. There are multiple layer 2 solutions already working and more are coming. It's not a pipedream anymore they are live.
Ethereum's layer 2 can handle tens of thousands transactions per second. These are then settled on chain as a single transaction. There are multiple layer 2 solutions already working and more are coming. It's not a pipedream anymore they are live.
How many transactions per day are currently being run on Ethereum layer 2? I can't find this info.
Because layer 2 is nebulous.
You’ll have to look up the transactions for each ERC20 token with volume. Volume is much higher than the base chain, but we are still waiting on rollups and sharding to supercharge TPS.
You’ll have to look up the transactions for each ERC20 token with volume. Volume is much higher than the base chain, but we are still waiting on rollups and sharding to supercharge TPS.
"already working" hmm.
Yes, they're called rollups and several are already in production on the public chain.
they're not lying. Loopring is one example among half a dozen. The issue is that current L2's are purpose-built by individual dapps. What doesn't currently exist (should be released in next few months) is the code that lets you copy/paste your current L1 code into an L2 code with almost no effort. At that point all the current dapps running on L1 can just port over to L2 very quickly and without the huge risk of a bug in a ton of new code lines.
> What doesn't currently exist (should be released in next few months) is the code that lets you copy/paste your current L1 code into an L2 code with almost no effort
Why does that sounded like its already being solved by Matic? From my understanding, Polygon Matic do exactly that.
Why does that sounded like its already being solved by Matic? From my understanding, Polygon Matic do exactly that.
Those are on-chain transactions. Coinbase and many other wallets now support offline, or 'Instant Sends' which is more akin to the simple database update that PayPal/Visa performs.
Sure those aren't purely decentralized but a decentralized settlement layer is probably where most of the value is anyway.
Sure those aren't purely decentralized but a decentralized settlement layer is probably where most of the value is anyway.
Why is that more novel than, say, intra-bank transactions?
You can't make a huge return holding USD. We just need to pretend this is real adoption to recruit more to the ponzi.
Those intra-bank transactions that are still done via FTP, take 2-3 days to settle, and require owning a bank in order to participate?
Yes, I suppose there's no room for improvement there.
Yes, I suppose there's no room for improvement there.
If I wanted that, I would be using something like Venmo, instead of Bitcoin.
>a decentralized settlement layer is probably where most of the value is anyway.
Why?
Why?
Graph theory. A purely centralized topology has significant problems with fault tolerance, trust, and control. However you do not need a hyperconnected graph to achieve strong fault tolerance and protect against a single node with full control.
The internet itself is a good example. It strikes a balance between decentralization and efficiency through the use of ISPs as supernodes.
The internet itself is a good example. It strikes a balance between decentralization and efficiency through the use of ISPs as supernodes.
How many settlement layers exist between a PayPal transaction and the underlying money transfer protocol (SEPA, SWIFT etc)?
Paypal isn't meaningfully decentralized. And Ethereum isn't sufficiently decentralized. Their throughput is part of what prevents Ethereum from being actually decentralized - pretty much no normal person can run a full ethereum node.
How many transactions happen in the world?
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.
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.
Which is the core point: the major processors aren't being limited by their technology, they're being limited by the size of the economy. There's no real meaningful limit on how they can scale that.
Just barely creeping across the line with crypto means its already inadequate.
Just barely creeping across the line with crypto means its already inadequate.
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.
Approximately 100,000 a second including cash transactions.
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?
VisaNet will do 76,000 tps - 4 orders of magnitude.
It is based on usage statistics not a technical benchmark. That number is not their peak throughput capacity it's how many transactions they actually do, which I'd wager is bottle-necked by user adoption not by tech.
Yes, let's wager on that.
check IOTA if you want to learn (if you have not) about DAG structure that potentially solves decentralized scalability. GOSSIP protocol
I looked into this and IOTA requires special blessed "Coordinator" nodes, so it's not really decentralized.
i want to elucidate my downvoters that I was not shilling the project. I was just pointing towards a network structure that you guys might find interesting given the problems we were discussing. I was not expecting to get some kind of reddit r/cryptocurrency style backlash.
what you said is indeed true chromaton, but is also already solved and on its way to removing it this year. the theoretical solution to that was found in 2019 in one of their researchers conventions
Fair enough. But I don't really buy anyone saying it's "on its way", as I've heard that one before. You can see a lot of "on its way" in this thread as well.
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.
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.
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.
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?
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?
Try Bitcoin Cash. The devs have full control over the BTC protocol.
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!
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.
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.
> 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.
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.
Of course, apologies. Should have been clear I was talking about 2MB+ blocksize rather than segwit. Some great points!
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.
>>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.
> This analysis is complete nonsense
First of all, thank you for being pretty much the only person who actually wants to talk about the paper, and not something tangential : )
> assumptions that are entirely arbitrary and biased toward the argument of not scaling Bitcoin
I do mention in the paper that the assumptions are up for debate, but I did try pretty hard to justify those assumptions so they are certainly not arbitrary. If by "biased" you mean that my conclusions are a factual result of my assumptions, then thank you. If by "biased" you mean that I decided what results I wanted to get, and then chose the assumptions based on that, I really would love a bit more benefit of the doubt. You don't know me, so its a bit strange for you to start accusing me of cooking the books on something I spend literally dozens if not hundreds of hours on.
In any case, I agree that there are other assumptions that may make sense. There are other bottlenecks to growth than blockchain space, and so it should be considered how much blockchain space will allow bitcoin to grow as fast as we need it to grow (for whatever reason we'd want that). This will change over time. The more people adopt it, the more likely blockchain space will become a bottleneck that substantially slows adoption.
But certainly it could be argued that right now we don't need 90% of the earth to be able to run a bitcoin node. I can absolutely see the argument for increasing the minimimum requirements in the assumptions to be much higher in the next 5 years, maybe even 10 years. But in 10 years, I think we'll want to make using bitcoin to its fullest capacity a lot more accessible.
> What you don't want is people in poorer countries having to trust third parties with their private keys
You absolutely have a point! Most people using custodial solutions that do batch things under the hood to get around scaling issues is certainly not a state we want to be in. It may happen anyway, even if we magically found infinite scalability, but we don't want it regardless.
However at the same time, we don't want the rugged pulled out from under us: we don't want bitcoin's rules to be changed out from under us. Enough full nodes need to be out there to ensure that various attacks aren't possible on the network and that blocks that propagate are valid blocks. I think there is some sweet spot on both of those amounts. And I do think more discussion is needed around the assumptions we're making. I wrote this paper in part to start exactly such a discussion about the assumptions and what concrete targets we have for bitcoin in terms of these network demographics.
What would you say is an acceptable percentage of the population using custodial systems like you're talking about? 10%? Less? What about: what's the percentage of the population that would be acceptable to run a full node? 10%? 50%? More? Maybe at some point I'll write another paper just on the different reasonable assumptions.
> 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.
Again, not arbitrary. The reason I did that is to include normal people. Normal people aren't going to buy and set up a dedicated server for bitcoin. And what about a remove bitocin service? Well, that's just the service running bitcoin, its not the individual - so its no better than SPV. So yes, if we're ok with just say 5% or less of the population running bitcoin, we can remove the 10% capacity limit, but if its normal people - people don't like their machine running slowly all the time because bitcoin is chugging through the world's transactions. Most people just would switch to an SPV node.
> 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.
Well, yes, they could afford to. That isn't the question I'm concerned with. Its not about cost. Its about convenience. Will 10s of millions of people buy extra hardware just to run bitcoin? I would argue no, they won't.
But yes, you're probably right that 10s of millions of people running PUBLIC full nodes is probably enough. My understanding is that we're at less than 1/1000th of that goal at the moment. Were we to make it easier for people to run public nodes (either via IPv6 or Tor or NAT hole punching), it would make it a lot easier to reach that goal.
And I'm not saying we couldn't bring these requirements up eventually. Once we blast past 10 million public nodes, maybe we can re-evaluate. But as of right now, Bitcoin has a serious vulnerability to sybil attacks on public nodes.
> 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 certainly don't agree with that statement. It means 99% of people would need to run SPV nodes - which is currently not good. First of all, the World's 1% owns less than 50% of the wealth, so it would be a minority of the economic activity. Putting the majority of economic activity in SPV nodes would leave the system quite vulnerable in situations where a majority of hashpower hardforks to something dangerous or malicious. This isn't necessarily a 51% attack scenario. It could be a situation where miners misread the sentiment of users and choose badly, or where mistakes were made, or it could be a situation where it favors miners but not users, or a number of things like that that aren't a single colluding group. So I would say at very least, the majoritiy of economic activity should be using their own full nodes, and a vast majority is far safer. Perhaps this is 5% of the world.
> The political attack, of countries banning Bitcoin internally, and the best defenses against that, are not considered.
I'm curious what your analysis would be of that.
> increase the proportion of the population that is economically dependent on the network
I agree this would be a very helpful mitigation of political attacks in general.
> much more likely
This I'm not sure about. Yes political attacks are likely (and of course we've seen many of them already). However, political attacks that could succeed seem already quite unlikely. I would love to see your analysis of how likely one might be to succeed and what the network requirements would be to sufficiently mitigate that. And then the tradeoffs vs these other kinds of attacks could be compared.
First of all, thank you for being pretty much the only person who actually wants to talk about the paper, and not something tangential : )
> assumptions that are entirely arbitrary and biased toward the argument of not scaling Bitcoin
I do mention in the paper that the assumptions are up for debate, but I did try pretty hard to justify those assumptions so they are certainly not arbitrary. If by "biased" you mean that my conclusions are a factual result of my assumptions, then thank you. If by "biased" you mean that I decided what results I wanted to get, and then chose the assumptions based on that, I really would love a bit more benefit of the doubt. You don't know me, so its a bit strange for you to start accusing me of cooking the books on something I spend literally dozens if not hundreds of hours on.
In any case, I agree that there are other assumptions that may make sense. There are other bottlenecks to growth than blockchain space, and so it should be considered how much blockchain space will allow bitcoin to grow as fast as we need it to grow (for whatever reason we'd want that). This will change over time. The more people adopt it, the more likely blockchain space will become a bottleneck that substantially slows adoption.
But certainly it could be argued that right now we don't need 90% of the earth to be able to run a bitcoin node. I can absolutely see the argument for increasing the minimimum requirements in the assumptions to be much higher in the next 5 years, maybe even 10 years. But in 10 years, I think we'll want to make using bitcoin to its fullest capacity a lot more accessible.
> What you don't want is people in poorer countries having to trust third parties with their private keys
You absolutely have a point! Most people using custodial solutions that do batch things under the hood to get around scaling issues is certainly not a state we want to be in. It may happen anyway, even if we magically found infinite scalability, but we don't want it regardless.
However at the same time, we don't want the rugged pulled out from under us: we don't want bitcoin's rules to be changed out from under us. Enough full nodes need to be out there to ensure that various attacks aren't possible on the network and that blocks that propagate are valid blocks. I think there is some sweet spot on both of those amounts. And I do think more discussion is needed around the assumptions we're making. I wrote this paper in part to start exactly such a discussion about the assumptions and what concrete targets we have for bitcoin in terms of these network demographics.
What would you say is an acceptable percentage of the population using custodial systems like you're talking about? 10%? Less? What about: what's the percentage of the population that would be acceptable to run a full node? 10%? 50%? More? Maybe at some point I'll write another paper just on the different reasonable assumptions.
> 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.
Again, not arbitrary. The reason I did that is to include normal people. Normal people aren't going to buy and set up a dedicated server for bitcoin. And what about a remove bitocin service? Well, that's just the service running bitcoin, its not the individual - so its no better than SPV. So yes, if we're ok with just say 5% or less of the population running bitcoin, we can remove the 10% capacity limit, but if its normal people - people don't like their machine running slowly all the time because bitcoin is chugging through the world's transactions. Most people just would switch to an SPV node.
> 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.
Well, yes, they could afford to. That isn't the question I'm concerned with. Its not about cost. Its about convenience. Will 10s of millions of people buy extra hardware just to run bitcoin? I would argue no, they won't.
But yes, you're probably right that 10s of millions of people running PUBLIC full nodes is probably enough. My understanding is that we're at less than 1/1000th of that goal at the moment. Were we to make it easier for people to run public nodes (either via IPv6 or Tor or NAT hole punching), it would make it a lot easier to reach that goal.
And I'm not saying we couldn't bring these requirements up eventually. Once we blast past 10 million public nodes, maybe we can re-evaluate. But as of right now, Bitcoin has a serious vulnerability to sybil attacks on public nodes.
> 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 certainly don't agree with that statement. It means 99% of people would need to run SPV nodes - which is currently not good. First of all, the World's 1% owns less than 50% of the wealth, so it would be a minority of the economic activity. Putting the majority of economic activity in SPV nodes would leave the system quite vulnerable in situations where a majority of hashpower hardforks to something dangerous or malicious. This isn't necessarily a 51% attack scenario. It could be a situation where miners misread the sentiment of users and choose badly, or where mistakes were made, or it could be a situation where it favors miners but not users, or a number of things like that that aren't a single colluding group. So I would say at very least, the majoritiy of economic activity should be using their own full nodes, and a vast majority is far safer. Perhaps this is 5% of the world.
> The political attack, of countries banning Bitcoin internally, and the best defenses against that, are not considered.
I'm curious what your analysis would be of that.
> increase the proportion of the population that is economically dependent on the network
I agree this would be a very helpful mitigation of political attacks in general.
> much more likely
This I'm not sure about. Yes political attacks are likely (and of course we've seen many of them already). However, political attacks that could succeed seem already quite unlikely. I would love to see your analysis of how likely one might be to succeed and what the network requirements would be to sufficiently mitigate that. And then the tradeoffs vs these other kinds of attacks could be compared.
>>I do mention in the paper that the assumptions are up for debate, but I did try pretty hard to justify those assumptions so they are certainly not arbitrary.
Where in the paper did you justify those assumptions? I see them as not only totally arbitrary, but wrong according to any common sense analysis of threats or weighing of priorities.
>>If by "biased" you mean that I decided what results I wanted to get, and then chose the assumptions based on that, I really would love a bit more benefit of the doubt.
I will be happy to give you a benefit of the doubt if you can convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency.
>>You don't know me, so its a bit strange for you to start accusing me of cooking the books on something I spend literally dozens if not hundreds of hours on.
I don't think it's strange when you rest a behometh of an analysis on assumptions as unjustified as Bitcoin needing to limit scalability so that 90% of the world population, the vast majority of whom live in the developing world and can't afford to use Bitcoin today due to lack of scalability, can run a full node.
If one thinks adversarially, then one has to assume potential malicious intentions behind writings intended to justify limiting the scalability of the most well-known and highest market cap cryptocurrency.
>>However at the same time, we don't want the rugged pulled out from under us: we don't want bitcoin's rules to be changed out from under us. Enough full nodes need to be out there to ensure that various attacks aren't possible on the network and that blocks that propagate are valid blocks. I think there is some sweet spot on both of those amounts. And I do think more discussion is needed around the assumptions we're making. I wrote this paper in part to start exactly such a discussion about the assumptions and what concrete targets we have for bitcoin in terms of these network demographics.
Again: a trivial analysis shows that your logic is totally unsound. The population for whom you want to keep Bitcoin's node operation costs limited is also the population that cannot afford to use Bitcoin directly and thus has no incentive to run a full node.
It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin.
In a scenario where 80 million people, or the richest 1% of the world population, is both using Bitcoin regularly, and can afford to run a Bitcoin full node on dedicated hardware, is both possible, and entirely sufficient to prevent the rules of the network from being changed.
I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now, the Bitcoin economy is 200X larger than it is now, there are tens, possibly hundreds of thousands of people worldwide running full nodes, and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user. It's totally implausible, and I cannot imagine any reasonable basis for you holding this assumption.
>>Again, not arbitrary. The reason I did that is to include normal people. Normal people aren't going to buy and set up a dedicated server for bitcoin.
Almost any one who runs a full node is a committed individual, not a normal one. And a committed individual could very plausibly buy dedicated hardware, and allocate 100% of it to running a full node. The assumption that normal people need to be able to run a full node without buying hardware is not justified, as such people are very unlikely to run a full node anyway.
To summarize: normal non-committed people running Bitcoin nodes is in no way needed to maintain Bitcoin's resistance to attacks state-level actors, or prevent the rules from being changed without resistance from the userbase. This cohort is already a non-factor, and the more committed cohort running full nodes is entirely sufficient to maintain the network's decentralization and censorship resistance.
>>Well, yes, they could afford to. That isn't the question I'm concerned with. Its not about cost. Its about convenience. Will 10s of millions of people buy extra hardware just to run bitcoin? I would argue no, they won't.
It's not very inconvenient to buy and plug in a dedicated machine for running a full node. And if there are 80 million people worldwide who can afford to that, and practically everyone in the world is using Bitcoin every day, then yes, a significant minority of those 80 million people will go through the trouble of doing that.
If even 0.5% of that 80 million do, that's 400,000 nodes. And if some state, or collection of states, begins to organize to try to attack the network, more amongst those 80 million will be motivated to run a node if they live in a jurisdiction that allows it.
>>But yes, you're probably right that 10s of millions of people running PUBLIC full nodes is probably enough. My understanding is that we're at less than 1/1000th of that goal at the moment.
I didn't say 10s of millions of people running public full nodes is enough. I said 10s of millions of people BEING ABLE TO run one is enough.
Driving for 10s of millions of full nodes, by limiting network throughput to the point where only 0.1% of the world population can transact on it daily, makes absolutely no sense. That would never work.
Furthermore, it makes no sense why Bitcoin would need 10s of millions of full nodes. It's an arbitrary assumption, that is not supported by any detailed threat analysis or any evidence of real-world attacks that necessitate that size of a network for that matter.
>>Putting the majority of economic activity in SPV nodes would leave the system quite vulnerable in situations where a majority of hashpower hardforks to something dangerous or malicious.
SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain. Such an attack would be extremely conspicious, and there would be a strong social reaction to it resulting in any SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data.
Right now, the vast majority of the world population cannot use Bitcoin, and you're trying to justify the extreme restrictions on throughput that cause this, on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers, in which case the majority of the world population would be no worse off than they are now, where they rely on an entirely centralized financial system, because they cannot use Bitcoin.
>>I'm curious what your analysis would be of that.
Only what I already stated: 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.
Where in the paper did you justify those assumptions? I see them as not only totally arbitrary, but wrong according to any common sense analysis of threats or weighing of priorities.
>>If by "biased" you mean that I decided what results I wanted to get, and then chose the assumptions based on that, I really would love a bit more benefit of the doubt.
I will be happy to give you a benefit of the doubt if you can convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency.
>>You don't know me, so its a bit strange for you to start accusing me of cooking the books on something I spend literally dozens if not hundreds of hours on.
I don't think it's strange when you rest a behometh of an analysis on assumptions as unjustified as Bitcoin needing to limit scalability so that 90% of the world population, the vast majority of whom live in the developing world and can't afford to use Bitcoin today due to lack of scalability, can run a full node.
If one thinks adversarially, then one has to assume potential malicious intentions behind writings intended to justify limiting the scalability of the most well-known and highest market cap cryptocurrency.
>>However at the same time, we don't want the rugged pulled out from under us: we don't want bitcoin's rules to be changed out from under us. Enough full nodes need to be out there to ensure that various attacks aren't possible on the network and that blocks that propagate are valid blocks. I think there is some sweet spot on both of those amounts. And I do think more discussion is needed around the assumptions we're making. I wrote this paper in part to start exactly such a discussion about the assumptions and what concrete targets we have for bitcoin in terms of these network demographics.
Again: a trivial analysis shows that your logic is totally unsound. The population for whom you want to keep Bitcoin's node operation costs limited is also the population that cannot afford to use Bitcoin directly and thus has no incentive to run a full node.
It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin.
In a scenario where 80 million people, or the richest 1% of the world population, is both using Bitcoin regularly, and can afford to run a Bitcoin full node on dedicated hardware, is both possible, and entirely sufficient to prevent the rules of the network from being changed.
I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now, the Bitcoin economy is 200X larger than it is now, there are tens, possibly hundreds of thousands of people worldwide running full nodes, and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user. It's totally implausible, and I cannot imagine any reasonable basis for you holding this assumption.
>>Again, not arbitrary. The reason I did that is to include normal people. Normal people aren't going to buy and set up a dedicated server for bitcoin.
Almost any one who runs a full node is a committed individual, not a normal one. And a committed individual could very plausibly buy dedicated hardware, and allocate 100% of it to running a full node. The assumption that normal people need to be able to run a full node without buying hardware is not justified, as such people are very unlikely to run a full node anyway.
To summarize: normal non-committed people running Bitcoin nodes is in no way needed to maintain Bitcoin's resistance to attacks state-level actors, or prevent the rules from being changed without resistance from the userbase. This cohort is already a non-factor, and the more committed cohort running full nodes is entirely sufficient to maintain the network's decentralization and censorship resistance.
>>Well, yes, they could afford to. That isn't the question I'm concerned with. Its not about cost. Its about convenience. Will 10s of millions of people buy extra hardware just to run bitcoin? I would argue no, they won't.
It's not very inconvenient to buy and plug in a dedicated machine for running a full node. And if there are 80 million people worldwide who can afford to that, and practically everyone in the world is using Bitcoin every day, then yes, a significant minority of those 80 million people will go through the trouble of doing that.
If even 0.5% of that 80 million do, that's 400,000 nodes. And if some state, or collection of states, begins to organize to try to attack the network, more amongst those 80 million will be motivated to run a node if they live in a jurisdiction that allows it.
>>But yes, you're probably right that 10s of millions of people running PUBLIC full nodes is probably enough. My understanding is that we're at less than 1/1000th of that goal at the moment.
I didn't say 10s of millions of people running public full nodes is enough. I said 10s of millions of people BEING ABLE TO run one is enough.
Driving for 10s of millions of full nodes, by limiting network throughput to the point where only 0.1% of the world population can transact on it daily, makes absolutely no sense. That would never work.
Furthermore, it makes no sense why Bitcoin would need 10s of millions of full nodes. It's an arbitrary assumption, that is not supported by any detailed threat analysis or any evidence of real-world attacks that necessitate that size of a network for that matter.
>>Putting the majority of economic activity in SPV nodes would leave the system quite vulnerable in situations where a majority of hashpower hardforks to something dangerous or malicious.
SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain. Such an attack would be extremely conspicious, and there would be a strong social reaction to it resulting in any SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data.
Right now, the vast majority of the world population cannot use Bitcoin, and you're trying to justify the extreme restrictions on throughput that cause this, on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers, in which case the majority of the world population would be no worse off than they are now, where they rely on an entirely centralized financial system, because they cannot use Bitcoin.
>>I'm curious what your analysis would be of that.
Only what I already stated: 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.
> the best defense against a political attack is allowing Bitcoin to scale by 100 or 1,000 times in throughput
Ok, but are there different kinds of political attacks? What's the general description of a political attack? How specifically would bitcoin throughput solve the issue?
My brief thoughts:
One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed.
Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change. Adoption wouldn't really solve this problem, in fact, it might make this problem worse since the more people that adopt bitcoin, the more unsophisticated users (that aren't familiar with computer security, especially bitcoin security issues) there are that might support dangerous changes.
> convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency
It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial. My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks.
> one has to assume potential malicious intentions behind writings
No one is forcing you to assume anything. I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you.
Ok, but are there different kinds of political attacks? What's the general description of a political attack? How specifically would bitcoin throughput solve the issue?
My brief thoughts:
One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed.
Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change. Adoption wouldn't really solve this problem, in fact, it might make this problem worse since the more people that adopt bitcoin, the more unsophisticated users (that aren't familiar with computer security, especially bitcoin security issues) there are that might support dangerous changes.
> convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency
It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial. My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks.
> one has to assume potential malicious intentions behind writings
No one is forcing you to assume anything. I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you.
> Where in the paper did you justify those assumptions?
I have a whole section on available machine resources which cites a ton of sources. I also wrote down specific goals and an exhaustive list of "Failure-Mode Considerations". The assumptions and requirements are based on matching available resources with the stated goals and preventing the listed failure modes. If they don't match up, I'd love to debate that. If they do match up, but you think the goals are off base, I'd love to debate that too. I'm curious what specifically we disagree on that leads to our disagreement on the acceptability of the assumptions.
> It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin.
Ok. So I hear you saying that my assumptions lead to a primary bottleneck that can be loosened by reducing the requirements. You're saying that assuming that 90% of Bitcoin users should be able to run a full node alongside the goal of everyone on earth using bitcoin leads to a situation where there is not enough on-chain space to support that number of users. I think that's a valid line of thinking.
However, I don't think analysis of that is in any way "trivial". How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there? Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain? Or do you think the lightning network will scale? If you think the lightning network will be able to scale to a world-wide payment network, how much on-chain traffic is needed to support it? Will people batch their transactions? How well will schnorr signature aggrigation work to reduce traffic in practice? Etc etc.
This paper don't really use any of that kind of thinking in its assumptions. Instead it chooses goals and finds what requirements satisfy those goals. Do you think my analysis likely finds the right requirements to satisfy the given goals and assumptions?
> any one who runs a full node is a committed individual
That is true today becauase its a pain in the ass to run a full node. You need to keep it on all the time, it sucks up resources on your computer, it takes some research to configure it correctly or buy the right hardware (so that it isn't a potato). It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run. More wallets could integrate a full bitcoin node, however they aren't doing that because it is so resource intense. If every desktop wallet ran a full node, then I'm sure you would agree that a lot more people would run a full node.
> The assumption that normal people need to be able to run a full node without buying hardware is not justified
Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... . We can't rely on just "committed individuals" to run public full nodes. There just aren't enough of them.
> It's not very inconvenient to buy and plug in a dedicated machine for running a full node.
I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen.
> If even 0.5% of that 80 million do, that's 400,000 nodes
I calculated that we need 5 million honest public full nodes to have enough security to resist state-level sybil attacks. Again, see the Sybil and Eclipse Attacks section.
> In a scenario where .. the richest 1% of the world .. is .. using .. a Bitcoin full node .. sufficient to prevent the rules of the network from being changed.
I disagree, as I said in my previous comment. And in the next paragraph.
> I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now .. and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user.
Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously. Outcry doesn't happen instantaneously. An attack (or mistake) like that could cause massive massive damage in a very short period of time.
Lets say 45% of world's economic activity (the 1%) is done using full nodes. The rest is on SPV nodes. A 51% group of miners could create a hard fork and release it. Let's further say the group also has a large sybil network they use to propagate their blocks more quickly (which may be useful in honest mining) and these nodes also serve SPV nodes. Up to 55% of the network (all the SPV nodes) could follow that hard fork as soon as its release, more if the fork has support among others running those full nodes. This would in turn give the rest of the miners who weren't party to this an economic incentive to follow that fork, since it has the majority of both hashpower and economic activity. Even if outcry then happened, it would be impossible to undo the damage done. Another hardfork could be done to reverse the change, but the forks could never re-merge. This would split bitcoin into two currencies and cause massive economic chaos and friction that would probably be numbered in the billions of dollars in disruptive damage.
You could say that its unlikely that 51% of the miners could put together such a hard fork without people knowing about it, and I agree (although its certainly in the realm of realistic possibility). However, I think its not clear that enough outcry would happen such that miners wouldn't end up doing it anyway. People in the world generally don't pay much attention to large-scale things like this, especially things like monetary policy and technical security related things. Its quite likely I think that >95% of people simply wouldn't pay much attention to it until it happened.
Regardless, even a 1% probability of that happening per century is far too high I think.
Even if 55% of the world's economic activity ran on full nodes, miners wouldn't necessarily know that. Its very hard to measure those kinds of things precisely, and wishful thinking could bias them to thinking more people are on SPV than in reality. A hard fork would still have massive negative consequences.
The way SPV is currently designed, a hard fork like this could be harmful to anyone running an SPV node. However, if the fraction of SPV nodes is low enough, the incentive to attempt such an attack would be subtantially lower.
So that's one situation and one aspect of it. There would also be bad consequences for the vulnerability of mining to attack if the blocksize limit was 2GB.
> SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain
How long would this take? How many SPV users (ie 99% of the population in your ideal scenario) would actually put in the effort to make any change whatsoever?
> Such an attack would be extremely conspicious, and there would be a strong social reaction to it
I agree with both of those things. But conspicuousness of an attack doesn't prevent it from happening and causing massive damage in the time while the attack is able to operate.
> SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data.
Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes. While yes, SPV servers could be blacklisted, this would hardly be a painless or easy process. And it would be too late to stop the hard fork in my scenario above from happening. The economy would have already switched onto the hardfork, and the transactions on that fork would be irreversible without even more massive disruption and damage.
> on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers
A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork. That's exactly the scenario where something like this could happen. Rash decisions, lots of contention, emotions flaring. No centralized authority was needed for that scenario to cause problems. And if SPV nodes could simply be coopted to whoever had majority hashpower (or even minority hashpower in the cases where SPV nodes are mostly tied to specific SPV services rather than a distributed network of SPV server nodes), that would be no bueno.
I have a whole section on available machine resources which cites a ton of sources. I also wrote down specific goals and an exhaustive list of "Failure-Mode Considerations". The assumptions and requirements are based on matching available resources with the stated goals and preventing the listed failure modes. If they don't match up, I'd love to debate that. If they do match up, but you think the goals are off base, I'd love to debate that too. I'm curious what specifically we disagree on that leads to our disagreement on the acceptability of the assumptions.
> It makes absolutely no sense to massively inhibit Bitcoin's utility, in order to make running a Bitcoin node possible for a population who this inhibiting action prevents from using Bitcoin.
Ok. So I hear you saying that my assumptions lead to a primary bottleneck that can be loosened by reducing the requirements. You're saying that assuming that 90% of Bitcoin users should be able to run a full node alongside the goal of everyone on earth using bitcoin leads to a situation where there is not enough on-chain space to support that number of users. I think that's a valid line of thinking.
However, I don't think analysis of that is in any way "trivial". How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there? Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain? Or do you think the lightning network will scale? If you think the lightning network will be able to scale to a world-wide payment network, how much on-chain traffic is needed to support it? Will people batch their transactions? How well will schnorr signature aggrigation work to reduce traffic in practice? Etc etc.
This paper don't really use any of that kind of thinking in its assumptions. Instead it chooses goals and finds what requirements satisfy those goals. Do you think my analysis likely finds the right requirements to satisfy the given goals and assumptions?
> any one who runs a full node is a committed individual
That is true today becauase its a pain in the ass to run a full node. You need to keep it on all the time, it sucks up resources on your computer, it takes some research to configure it correctly or buy the right hardware (so that it isn't a potato). It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run. More wallets could integrate a full bitcoin node, however they aren't doing that because it is so resource intense. If every desktop wallet ran a full node, then I'm sure you would agree that a lot more people would run a full node.
> The assumption that normal people need to be able to run a full node without buying hardware is not justified
Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... . We can't rely on just "committed individuals" to run public full nodes. There just aren't enough of them.
> It's not very inconvenient to buy and plug in a dedicated machine for running a full node.
I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen.
> If even 0.5% of that 80 million do, that's 400,000 nodes
I calculated that we need 5 million honest public full nodes to have enough security to resist state-level sybil attacks. Again, see the Sybil and Eclipse Attacks section.
> In a scenario where .. the richest 1% of the world .. is .. using .. a Bitcoin full node .. sufficient to prevent the rules of the network from being changed.
I disagree, as I said in my previous comment. And in the next paragraph.
> I challenge you to describe a situation where Bitcoin throughput is 1000X greater than is now .. and yet the rules of the network can be changed without a massive outcry / pushback from the ordinary Bitcoin user.
Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously. Outcry doesn't happen instantaneously. An attack (or mistake) like that could cause massive massive damage in a very short period of time.
Lets say 45% of world's economic activity (the 1%) is done using full nodes. The rest is on SPV nodes. A 51% group of miners could create a hard fork and release it. Let's further say the group also has a large sybil network they use to propagate their blocks more quickly (which may be useful in honest mining) and these nodes also serve SPV nodes. Up to 55% of the network (all the SPV nodes) could follow that hard fork as soon as its release, more if the fork has support among others running those full nodes. This would in turn give the rest of the miners who weren't party to this an economic incentive to follow that fork, since it has the majority of both hashpower and economic activity. Even if outcry then happened, it would be impossible to undo the damage done. Another hardfork could be done to reverse the change, but the forks could never re-merge. This would split bitcoin into two currencies and cause massive economic chaos and friction that would probably be numbered in the billions of dollars in disruptive damage.
You could say that its unlikely that 51% of the miners could put together such a hard fork without people knowing about it, and I agree (although its certainly in the realm of realistic possibility). However, I think its not clear that enough outcry would happen such that miners wouldn't end up doing it anyway. People in the world generally don't pay much attention to large-scale things like this, especially things like monetary policy and technical security related things. Its quite likely I think that >95% of people simply wouldn't pay much attention to it until it happened.
Regardless, even a 1% probability of that happening per century is far too high I think.
Even if 55% of the world's economic activity ran on full nodes, miners wouldn't necessarily know that. Its very hard to measure those kinds of things precisely, and wishful thinking could bias them to thinking more people are on SPV than in reality. A hard fork would still have massive negative consequences.
The way SPV is currently designed, a hard fork like this could be harmful to anyone running an SPV node. However, if the fraction of SPV nodes is low enough, the incentive to attempt such an attack would be subtantially lower.
So that's one situation and one aspect of it. There would also be bad consequences for the vulnerability of mining to attack if the blocksize limit was 2GB.
> SPV node operators would be made aware of this attack, and not rely on SPV data servers that recognize the invalid chain
How long would this take? How many SPV users (ie 99% of the population in your ideal scenario) would actually put in the effort to make any change whatsoever?
> Such an attack would be extremely conspicious, and there would be a strong social reaction to it
I agree with both of those things. But conspicuousness of an attack doesn't prevent it from happening and causing massive damage in the time while the attack is able to operate.
> SPV data servers that are cooperating in the attack being completely discredited in favor of ones that serve accurate data.
Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes. While yes, SPV servers could be blacklisted, this would hardly be a painless or easy process. And it would be too late to stop the hard fork in my scenario above from happening. The economy would have already switched onto the hardfork, and the transactions on that fork would be irreversible without even more massive disruption and damage.
> on the basis of a highly unlikely threat where a majority of the world population have their Bitcoin activity coopted by a centralized authority through a coordinated attack by the majority of hashpower and SPV data servers
A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork. That's exactly the scenario where something like this could happen. Rash decisions, lots of contention, emotions flaring. No centralized authority was needed for that scenario to cause problems. And if SPV nodes could simply be coopted to whoever had majority hashpower (or even minority hashpower in the cases where SPV nodes are mostly tied to specific SPV services rather than a distributed network of SPV server nodes), that would be no bueno.
>>I have a whole section on available machine resources which cites a ton of sources.
Maybe I'm just terrible at reading comprehension, but I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for the network to remain safe from an attack. Can you actually copy-paste an excerpt from the analysis that explains this assumption?
>>How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there?
I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population. I can't get mired down in over-analysis of every point we can already grant from a common sense deduction, as that will result in me not being allowed to even criticize your central assumptions due to be over-burdened by the analysis requirement.
>>Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain?
The assumption that the lightning network will even work is extremely speculative, and the burden is on those making this assumption to support it, not on me to support the idea that it won't. There is no compelling reason to believe that an experimental network with extremely low adoption levels will ever prove highly useful, and gain widespread usage.
>>Instead it chooses goals and finds what requirements satisfy those goals.
Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack, and not merely that it can't scale and satisfy the goal of 90% of the world population being able to run a full node using only 10% of hardware and network resources they already own. It doesn't justify its starting assumption.
>>That is true today becauase its a pain in the ass to run a full node.
I disagree. All it takes is to install the Bitcoin full node software on any computer with sufficient hardware resources, and start running it, with next to no configuration. You can even buy plug-and-play Bitcoin nodes where the full node software comes already installed on the device, to skip that trivial step of downloading and installing the software.
>>It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run.
I don't see how you're justifying your argument that running a full node is not for the minority of people that are "committed individuals". You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it.
Moreover, I clearly acknowledged that the resources a full node takes to run affects the number of people likely to run it, as I specifically restricted the percentage of the world population able to run a full node under high-scalability assumptions to 1%, or 80 million, on the basis that only they could afford to purchase those resources, My claim implies 99% of the world population would not be likely to run a full node in a high-scalability scenario, due to the unaffordability of acquiring the hardware and bandwidth resources for this cohort.
>>Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... .
Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility, and far more likely to actually work, than imposing extreme restrictions on Bitcoin's throughput, which would only work if the extremely inconsistent assumption that tens of millions of people who currently cannot transact on Bitcoin will run a full node.
For example, there's trust-based network-peering: http://www.cs.columbia.edu/~danr/courses/6772/Fall06/papers/...
>>I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen.
Strawman. I never said that 10s of millions of people would be willing to do that, or this would be needed to maintain resistance to cooption.
>>Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously.
The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years.
>>Regardless, even a 1% probability of that happening per century is far too high I think.
This conclusions on an extremely inconsistent set of assumptions. On what basis is 99.9% of the world population not being able to use Bitcoin due to the current extreme restrictions on throughput, a better scenario than there being a 1% probability of a scalable and mass-adopted Bitcoin suffering a failure of the type you describe once per century?
>>Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes.
There are relatively low-cost ways to prevent that from being the case in the future.
>>A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork.
It would require more than just miners that want it. It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition, or else those SPV data servers who want the change would face social backlash and a mass migration away from reliance on them.
>>One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed.
Yes, and I think of all the ways to mitigate the risks to Bitcoin, this is the most effective one, that results in the greatest reduction of risk to Bitcoin.
>>Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change.
If they can convince real people to support the change, they can also support real people running full nodes to support the change, so this risk is not alleviated by restricting transaction throughput to lower the cost of running a full node.
> convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency
It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial.
>>My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks.
Pursuing the goal of "seeing people financially empowered by cryptocurrency" would also involve pursuing the goal of "mak[ing] the Bitcoin system be secure against adversarial attacks", but it does not hold it as the only goal. It's a broader and more sensible goal to pursue, since a highly secure Bitcoin network is only useful to the extent that people can use it.
>>I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you.
If I see evidence of bias in your writings, I will express my opinion on it.
Maybe I'm just terrible at reading comprehension, but I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for the network to remain safe from an attack. Can you actually copy-paste an excerpt from the analysis that explains this assumption?
>>How do you know how much on-chain space is needed by a full world of users? What assumptions do you make there?
I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population. I can't get mired down in over-analysis of every point we can already grant from a common sense deduction, as that will result in me not being allowed to even criticize your central assumptions due to be over-burdened by the analysis requirement.
>>Are you someone that thinks the lightning network won't scale and so all transctions must be on-chain?
The assumption that the lightning network will even work is extremely speculative, and the burden is on those making this assumption to support it, not on me to support the idea that it won't. There is no compelling reason to believe that an experimental network with extremely low adoption levels will ever prove highly useful, and gain widespread usage.
>>Instead it chooses goals and finds what requirements satisfy those goals.
Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack, and not merely that it can't scale and satisfy the goal of 90% of the world population being able to run a full node using only 10% of hardware and network resources they already own. It doesn't justify its starting assumption.
>>That is true today becauase its a pain in the ass to run a full node.
I disagree. All it takes is to install the Bitcoin full node software on any computer with sufficient hardware resources, and start running it, with next to no configuration. You can even buy plug-and-play Bitcoin nodes where the full node software comes already installed on the device, to skip that trivial step of downloading and installing the software.
>>It is not neccessarily the case that running bitcoin is only for the minority that are "committed individuals", but instead its, in part, a function of how much resources running a full node takes. In other words, the number of people likely to run a full node is not independent of the resources a full node takes to run.
I don't see how you're justifying your argument that running a full node is not for the minority of people that are "committed individuals". You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it.
Moreover, I clearly acknowledged that the resources a full node takes to run affects the number of people likely to run it, as I specifically restricted the percentage of the world population able to run a full node under high-scalability assumptions to 1%, or 80 million, on the basis that only they could afford to purchase those resources, My claim implies 99% of the world population would not be likely to run a full node in a high-scalability scenario, due to the unaffordability of acquiring the hardware and bandwidth resources for this cohort.
>>Part of what underlies that goal is that we need to maximize the number of people running public full nodes. The Bitcoin network is massively underserved by public full nodes, see the section on Sybil and Eclipse attacks: https://github.com/fresheneesz/bitcoinThroughputAnalysis#syb... .
Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility, and far more likely to actually work, than imposing extreme restrictions on Bitcoin's throughput, which would only work if the extremely inconsistent assumption that tens of millions of people who currently cannot transact on Bitcoin will run a full node.
For example, there's trust-based network-peering: http://www.cs.columbia.edu/~danr/courses/6772/Fall06/papers/...
>>I disagree. Do you think 10s of millions of people are willing to do that? I very much doubt it. I certainly don't think we can rely on that to happen.
Strawman. I never said that 10s of millions of people would be willing to do that, or this would be needed to maintain resistance to cooption.
>>Lack of outcry is not what I'm claiming. I'm claiming that if >50% of the economic activity on the network is done via SPV nodes, rules can be changed in a way that will instantaneously affect those SPV nodes. People do not react instantaneously.
The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years.
>>Regardless, even a 1% probability of that happening per century is far too high I think.
This conclusions on an extremely inconsistent set of assumptions. On what basis is 99.9% of the world population not being able to use Bitcoin due to the current extreme restrictions on throughput, a better scenario than there being a 1% probability of a scalable and mass-adopted Bitcoin suffering a failure of the type you describe once per century?
>>Wallets are likely to connect to random SPV servers on the network in the future, just like full nodes connect to random nodes.
There are relatively low-cost ways to prevent that from being the case in the future.
>>A centralized authority is not strictly necessary. This may simply be a contentious change that miners want. Maybe there's a loud minority of users on board too. Think about the bch fork.
It would require more than just miners that want it. It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition, or else those SPV data servers who want the change would face social backlash and a mass migration away from reliance on them.
>>One kind of political attack I can think of is one where some group decides they don't like bitcoin, and want to kill it. So they try to make laws that make bitcoin harder to use, or perhaps outright ban it. Increasing bitcoin's adoption would help reduce the number of people who don't have a stake in bitcoin, and thus reduce the number of people who would support such an attack. Increasing on-chain throughput may increase adoption (at what rate, I don't know), which would increase the rate at which we achieve some minimum level of adoption (perhaps 20%-30%?) to where an attack is unlikely to succeed.
Yes, and I think of all the ways to mitigate the risks to Bitcoin, this is the most effective one, that results in the greatest reduction of risk to Bitcoin.
>>Another kind of political attack I can think of is one where some group decides to advocate for some dangerous change to bitcoin. They convince a lot of people to want this change, and thus have the backing to attempt to get people to use that change.
If they can convince real people to support the change, they can also support real people running full nodes to support the change, so this risk is not alleviated by restricting transaction throughput to lower the cost of running a full node.
> convince me that the assumptions make any sense at all from the perspective of someone who wants to see people financially empowered by cryptocurrency
It sounds like you're asking me to bias my assumptions, or to explain to you how my assumptions are biased in a way you like. That honestly sounds a bit hypocrticial.
>>My goal is to find the ideal tradeoffs that make the Bitcoin system be secure against adversarial attacks, not to find tradeoffs that maximize the adoption rate of bitcoin but as a result leave the system vulnerable to significant attacks.
Pursuing the goal of "seeing people financially empowered by cryptocurrency" would also involve pursuing the goal of "mak[ing] the Bitcoin system be secure against adversarial attacks", but it does not hold it as the only goal. It's a broader and more sensible goal to pursue, since a highly secure Bitcoin network is only useful to the extent that people can use it.
>>I'm just going to ignore your accusations for now but if you continue to insult me I might just stop talking to you.
If I see evidence of bias in your writings, I will express my opinion on it.
Oh I did want to also mention that I think you probably missed reading this section, which goes over the line of thinking you've brought up about increased adoption: https://github.com/fresheneesz/bitcoinThroughputAnalysis#use...
> I don't see anything at all in the places you mention explaining why your assumption is that Bitcoin needs 90% of the world being able to run a full node for the network to remain safe from an attack. Can you actually copy-paste..?
I don't have any good clips of text that would connect them better. A lot of the connection between them is left vauge and implied. I agree this can be improved. I've created an issue for this: https://github.com/fresheneesz/bitcoinThroughputAnalysis/iss... Feel free to comment there.
> I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population.
I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways people transact, some better than others. If your analysis were to make that a critical piece of the discussion, it would have to be justified in more depth. But I'm not trying to ask you to do hours of analysis here.
> Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack
You may read what you want, but the intention of the paper was primarily to create a reusable way to evaluate the safe/secure throughput limits of bitcoin. The intention was explicitly not to come up with the "correct" or "best" assumptions or requirements of the network. It simply chose conservative limits and rolled with those. I was very clear about this in the paper. I'm happy to discuss the assumptions, but if your problem with the paper is that the assumptions aren't where you think they should be, you're asking of the paper something outside of its scope.
> You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it.
I don't think you're understanding me. You are explaining the current state of things. I'm thinking about a future where bitcoin doesn't take research to configure, and is a no brainer to run. You don't have to worry about reaching bandwidth caps or slowing down your apartment's internet or making your machine slow when you're playing a game. We agree that it currently takes committed people to run bitcoin. I think that needs to change.
> Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility
While I would love to hear about new strategies my paper doesn't incorporate, the first half of the paper explicitly doesn't incorporate new technology. It analyses the network as created by current bitcoin software.
> For example, there's trust-based network-peering
That's interesting. I worry that relying on trust might introduce issues, but its interesting nonetheless. I'll read through that. Thanks!
> Strawman. I never said that 10s of millions of people would be willing to do that
When I wrote that sentence, I still misunderstood what you meant. I forgot to revise after realizing you just meant that 10s of millions of people would need to be able to run full nodes, but it seems you think that far fewer would actually have to run full nodes.
> The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years.
Perhaps you're right. But this paper neither refutes nor confirms that, and analysizing the optimal tradeoffs there is, again, out of scope for the paper.
> There are relatively low-cost ways to prevent that from being the case in the future.
Yes and many of those ways are even less secure. If you're referring to the trust-based network-peering you mentioned, perhaps there's something there, but trust-based is by definition not trustless, which is generally what bitcoin is built to be. I agree some kinds of small but less-than-minimal trust could definitely be useful. But the fact is that bitcoin doesn't currently have those mechanisms.
> It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition
It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing?
> It's a broader and more sensible goal to pursue
Perhaps. But the scope of the paper is broad enough. I hope you can appreciate that ideas an techniques in the paper can be useful even if the goal is not something you agree with.
I don't have any good clips of text that would connect them better. A lot of the connection between them is left vauge and implied. I agree this can be improved. I've created an issue for this: https://github.com/fresheneesz/bitcoinThroughputAnalysis/iss... Feel free to comment there.
> I don't think I even have to provide a detailed analysis to make a high confidence claim that Bitcoin limited to 3 transactions per second cannot be used by the vast majority of the world population.
I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways people transact, some better than others. If your analysis were to make that a critical piece of the discussion, it would have to be justified in more depth. But I'm not trying to ask you to do hours of analysis here.
> Your paper suggests that Bitcoin can't scale to the point where less than 90% of the world population can run a full node using only 10% of hardware and network resources they already own, and remain safe from network attack
You may read what you want, but the intention of the paper was primarily to create a reusable way to evaluate the safe/secure throughput limits of bitcoin. The intention was explicitly not to come up with the "correct" or "best" assumptions or requirements of the network. It simply chose conservative limits and rolled with those. I was very clear about this in the paper. I'm happy to discuss the assumptions, but if your problem with the paper is that the assumptions aren't where you think they should be, you're asking of the paper something outside of its scope.
> You even argued that "it takes some research to configure" a Bitcoin full node, which supports my claim that under any plausible hardware requirements, it would be predominantly committed individuals who would go through the trouble of doing it.
I don't think you're understanding me. You are explaining the current state of things. I'm thinking about a future where bitcoin doesn't take research to configure, and is a no brainer to run. You don't have to worry about reaching bandwidth caps or slowing down your apartment's internet or making your machine slow when you're playing a game. We agree that it currently takes committed people to run bitcoin. I think that needs to change.
> Your analysis negates the existence of strategies for countering Sybil and Eclipse that would be far less costly to Bitcoin's utility
While I would love to hear about new strategies my paper doesn't incorporate, the first half of the paper explicitly doesn't incorporate new technology. It analyses the network as created by current bitcoin software.
> For example, there's trust-based network-peering
That's interesting. I worry that relying on trust might introduce issues, but its interesting nonetheless. I'll read through that. Thanks!
> Strawman. I never said that 10s of millions of people would be willing to do that
When I wrote that sentence, I still misunderstood what you meant. I forgot to revise after realizing you just meant that 10s of millions of people would need to be able to run full nodes, but it seems you think that far fewer would actually have to run full nodes.
> The attack does not need to be instantaneously neutralized for Bitcoin to survive it. It can incur significant short-term losses, and still not come close to erasing the social gains from allowing Bitcoin to be operational for billions of people for many years.
Perhaps you're right. But this paper neither refutes nor confirms that, and analysizing the optimal tradeoffs there is, again, out of scope for the paper.
> There are relatively low-cost ways to prevent that from being the case in the future.
Yes and many of those ways are even less secure. If you're referring to the trust-based network-peering you mentioned, perhaps there's something there, but trust-based is by definition not trustless, which is generally what bitcoin is built to be. I agree some kinds of small but less-than-minimal trust could definitely be useful. But the fact is that bitcoin doesn't currently have those mechanisms.
> It would require the majority of major stakeholders, including those running SPV data servers, to want it, and for that change not to face significant public opposition
It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing?
> It's a broader and more sensible goal to pursue
Perhaps. But the scope of the paper is broad enough. I hope you can appreciate that ideas an techniques in the paper can be useful even if the goal is not something you agree with.
Your arguments and analysis together contain grave contradictions that discredit them.
For instance, you argue that your position/paper does not rely on potential future innovations, like here:
>>While I would love to hear about new strategies my paper doesn't incorporate, the first half of the paper explicitly doesn't incorporate new technology. It analyses the network as created by current bitcoin software.
But then you rely on your assumption that Bitcoin could indeed gain significant adoption, while limited to an on-chain throughput limit of three transactions per second, based on a secondary assumption: that off-chain transaction solutions, that despite years of development, have failed to gain any appreciable market adoption, and which many argue are fundamentally limited in their utility, especially in scenarios where on-chain transaction fees are high, will in fact undergo development and innovation that will make them widely useful:
>>I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways people transact, some better than others. If your analysis were to make that a critical piece of the discussion, it would have to be justified in more depth. But I'm not trying to ask you to do hours of analysis here.
My assumption, that one of many low-cost approaches to defending against Sybil attacks, could be successfully developed and implemented into Bitcoin, is much safer than your assumption that off-chain based payment systems, like Lightning Network, will overcome their many technical limitations and become market successes, and massively increase Bitcoin's adoption.
So to summarize, you are in fact resting your 'Bitcoin node costs required to keep the network safe' assumption on assumptions about future development/adoption of highly experimental and unproven off-chain technologies.
Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software that will be developed:
>>You are explaining the current state of things. I'm thinking about a future where bitcoin doesn't take research to configure, and is a no brainer to run. You don't have to worry about reaching bandwidth caps or slowing down your apartment's internet or making your machine slow when you're playing a game. We agree that it currently takes committed people to run bitcoin. I think that needs to change.
This is just one of several ways in which your stance and arguments appear disingenuous due to their inconsistencies.
For instance, you argue that your position/paper does not rely on potential future innovations, like here:
>>While I would love to hear about new strategies my paper doesn't incorporate, the first half of the paper explicitly doesn't incorporate new technology. It analyses the network as created by current bitcoin software.
But then you rely on your assumption that Bitcoin could indeed gain significant adoption, while limited to an on-chain throughput limit of three transactions per second, based on a secondary assumption: that off-chain transaction solutions, that despite years of development, have failed to gain any appreciable market adoption, and which many argue are fundamentally limited in their utility, especially in scenarios where on-chain transaction fees are high, will in fact undergo development and innovation that will make them widely useful:
>>I certainly agree that 3 tps on chain is not enough for everyone to only transact on chain. However, there are many off chain ways people transact, some better than others. If your analysis were to make that a critical piece of the discussion, it would have to be justified in more depth. But I'm not trying to ask you to do hours of analysis here.
My assumption, that one of many low-cost approaches to defending against Sybil attacks, could be successfully developed and implemented into Bitcoin, is much safer than your assumption that off-chain based payment systems, like Lightning Network, will overcome their many technical limitations and become market successes, and massively increase Bitcoin's adoption.
So to summarize, you are in fact resting your 'Bitcoin node costs required to keep the network safe' assumption on assumptions about future development/adoption of highly experimental and unproven off-chain technologies.
Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software that will be developed:
>>You are explaining the current state of things. I'm thinking about a future where bitcoin doesn't take research to configure, and is a no brainer to run. You don't have to worry about reaching bandwidth caps or slowing down your apartment's internet or making your machine slow when you're playing a game. We agree that it currently takes committed people to run bitcoin. I think that needs to change.
This is just one of several ways in which your stance and arguments appear disingenuous due to their inconsistencies.
> you argue that your position/paper does not rely on potential future innovations
Let me ask you something: how much of my paper did you actually read? Again, the first half discusses current bitcion (actually 2019 bitcoin, when I wrote the paper). The second half discusses a prediction of future bitcoin. And did you read the section on User Growth and Growth of Public Nodes? Its very relevant to your line of thinking. https://github.com/fresheneesz/bitcoinThroughputAnalysis#use...
> a secondary assumption: that off-chain transaction solutions... will .. undergo development and innovation that will make them widely useful
Nothing in the core of my paper relies on any assumptions about the lightning network. The paper is about on-chain throughput not 2nd layers. The only mention of the lightning network is in discussion around how much on-chain throughput the lightning network would need if it indeed scales up to a large fraction of the world's tranasctions.
> Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software
I believe I made my assumptions very clear. The easiest attack against bitcoin today is a Sybil attack that drains the resources of public nodes. Because that is the weakest link of bitcoin, that should be the highest priority to improve. It is rather indisputable that making a full node take more resources will reduce the fraction of people willing to run a public full node, and that making a full node take less resources to run will conversely increase the fraction of people willing to run a public full node. Do you disagree with that last sentence?
The next important question would be how elastic is that relationship? Would reducing the resources by half double the number of public full nodes? Would it do more? Less? Another question would be: how many more public nodes would we get from further adoption of bitcoin? And again, the third piece would be: how much adoption would we get from increasing on-chain throughput? This 3 variable set of relationships would be quite interesting to add the the discussion of this in order to contrast the goals I chose vs the ones you have. Are you willing to do that math or make estimates? Or are you just demanding that I put in the effort to evaluate your claims (that increasing throughput via larger block size is the fastest way to improving bitcoin's worst-case / weakest-link security) for you?
Of course, your assumption seems to be that bitcoin is most suceptible to a political attack, whereas the easiest attack I've analyzed is a Sybil attack on public node resources. Are you willing to quantify the risks and costs of attack there and do the analysis? If so, I think that would be very valuable. But as it stands, it sounds like you're simply claiming that you have discredited my work without actually showing any of your own work that might give rigorous evidence that my paper has flaws that can be improved on.
I also asked you a question that you ignored. I'd appreciate an answer:
>> It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing?
Let me ask you something: how much of my paper did you actually read? Again, the first half discusses current bitcion (actually 2019 bitcoin, when I wrote the paper). The second half discusses a prediction of future bitcoin. And did you read the section on User Growth and Growth of Public Nodes? Its very relevant to your line of thinking. https://github.com/fresheneesz/bitcoinThroughputAnalysis#use...
> a secondary assumption: that off-chain transaction solutions... will .. undergo development and innovation that will make them widely useful
Nothing in the core of my paper relies on any assumptions about the lightning network. The paper is about on-chain throughput not 2nd layers. The only mention of the lightning network is in discussion around how much on-chain throughput the lightning network would need if it indeed scales up to a large fraction of the world's tranasctions.
> Here is another instance where you rest your starting assumption on further assumptions about new Bitcoin node software
I believe I made my assumptions very clear. The easiest attack against bitcoin today is a Sybil attack that drains the resources of public nodes. Because that is the weakest link of bitcoin, that should be the highest priority to improve. It is rather indisputable that making a full node take more resources will reduce the fraction of people willing to run a public full node, and that making a full node take less resources to run will conversely increase the fraction of people willing to run a public full node. Do you disagree with that last sentence?
The next important question would be how elastic is that relationship? Would reducing the resources by half double the number of public full nodes? Would it do more? Less? Another question would be: how many more public nodes would we get from further adoption of bitcoin? And again, the third piece would be: how much adoption would we get from increasing on-chain throughput? This 3 variable set of relationships would be quite interesting to add the the discussion of this in order to contrast the goals I chose vs the ones you have. Are you willing to do that math or make estimates? Or are you just demanding that I put in the effort to evaluate your claims (that increasing throughput via larger block size is the fastest way to improving bitcoin's worst-case / weakest-link security) for you?
Of course, your assumption seems to be that bitcoin is most suceptible to a political attack, whereas the easiest attack I've analyzed is a Sybil attack on public node resources. Are you willing to quantify the risks and costs of attack there and do the analysis? If so, I think that would be very valuable. But as it stands, it sounds like you're simply claiming that you have discredited my work without actually showing any of your own work that might give rigorous evidence that my paper has flaws that can be improved on.
I also asked you a question that you ignored. I'd appreciate an answer:
>> It would be quite easy for an attacker to Sybil the network of SPV servers, so those wouldn't help in an attack. I think our disagreement here is that I'm talking about whether a damaging attack would be feasible, and you're talking about whether the attack would destroy bitcoin. Those are very different statements. Do you agree that a damaging attack could happen in the scenario you're describing?
In a just world this would be the top comment. Instead we have Bitcoin boomers asking if you’ve heard about their lord and savior lightning, which like Jesus is coming any day now!
It's impossible to make people understand a truth they've already heavily invested in rejecting, no matter how obvious and unquestionable that truth is. More than any other thing in the world the BTC saga taught me that. Stupidity alone although a big part of it is simply inadequate to explain it wholly given just how stupid the BTC position actually is.
Kids can grasp it and yet heavily invested fanatical professionals in the field cannot.
It's sad.
Kids can grasp it and yet heavily invested fanatical professionals in the field cannot.
It's sad.
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.
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.
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.
[deleted]
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.
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.
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?).
If you want people to actually be able to pay for things with Bitcoin (often a stated goal), then yes, it does.
He mentioned the Lightning Network - that is exactly what its for.
Sorry but bitcoin is peer-to-peer cash system. If it can't handle peer-to-peer transactions then it's an utter failure.
It can. The lightning network is part of bitcoin as peer to peer cash.
Correct, BTC is not peer to peer cash, try the real Bitcoin, Bitcoin Cash.
https://utxos.org/uses/scaling/
https://utxos.org/analysis/bip_simulation/
https://utxos.org/analysis/batching_sim/
https://github.com/bitcoin/bitcoin/pull/21702