An analysis of Bitcoin's throughput bottlenecks
github.com
github.com
https://utxos.org/uses/scaling/
https://utxos.org/analysis/bip_simulation/
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.
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?
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.
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.
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.
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.
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.
Every junk transaction costs them money
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.
Or if the exchange isn't fully collateralized, it's a scam and goes under.
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.
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?
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.
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."
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.
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.
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'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.
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.
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.
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.
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.
[1]https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto...
They probably don't want to mess with that dynamic too harshly.
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...
How are they profiting?
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.
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.
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.
DOGE and PRV (WSBCoin anyone?) don't require these layers.
The arguments against SPV wallet use in this text don’t ring true for me.
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.
Unless you done quantitative analysis into the most appropriate blocksize. But that will never happen at this stage.
Anything relevant you would like to share to back up this claim?
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.
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?
Why use this complicated hack solution when anyone can just use a different cryptocurrency and not have these problems 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.
That being said, I don’t know enough about the security aspect - so your claim may end up being correct!
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.
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.
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 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.
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.
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.
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.
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.
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.
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
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.
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?".
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.
> Surely one of the newer generation like eth is better suited?
Why surely?
Which is „pretty much the same“ in crypto terms.
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
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.
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.
Rejection reason: unclear, doesn't fit the narrative.
1: https://preview.redd.it/c21qium7jyr61.png?width=1113&format=...
2: https://www.reddit.com/r/CryptoCurrency/comments/mmstrt/i_bo...
Why not? If such evidence exists why aren't you presenting it?
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)
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...
The ethereum ecosystem is just so rich that there's no reason to leave it, well, maybe bsc and solana, but that's it.
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.
> 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?
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.
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?
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.
Sorry but they're still incredibly common
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...
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.
Just barely creeping across the line with crypto means its already inadequate.
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.
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.
Why does that sounded like its already being solved by Matic? From my understanding, Polygon Matic do exactly that.
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.
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.
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.
But it seems like decentralization and gas fees/tps are going to be inversely correlated no?
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
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.
Sure those aren't purely decentralized but a decentralized settlement layer is probably where most of the value is anyway.
Why?
The internet itself is a good example. It strikes a balance between decentralization and efficiency through the use of ISPs as supernodes.
Yes, I suppose there's no room for improvement there.
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.
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?
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.
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.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.
Kids can grasp it and yet heavily invested fanatical professionals in the field cannot.
It's sad.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.