> I will also show that while Bitcoin currently may not be in a safe state, future software optimizations could allow Bitcoin safely process likely more than 100 transactions/second on today's hardware.
100 transactions/second still doesn’t sound like a lot, especially if you want Bitcoin to be an actual currency used for exchange of goods.
If Bitcoin were used by everybody on the planet, the current max of 10 transactions/second means that each person could be part of a transaction once every 13 years (4 billion pairs of people / 10 Hz). Boosting the rate up to 100 transactions per second reduces that down to 15 months. Just think, receive you paycheck this week, and over a year later you can use it to buy groceries.
Bitcoin's throughout is absolutely 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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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.
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".
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.
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.
> 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.
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.
> 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."
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.
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.
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.
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?
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.
> 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.
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.
> 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.
> 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.
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.
When you're talking international, there is little trust and little legal recourse. It is absolutely a problem that bitcoin can solve exceptionally well.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
has anyone ever done the modeling on the dynamic limits of decentralized network consensus? my intuition has always been that getting, say, 100,000 globally distributed voting nodes to agree on even a simple truth value will quickly run into exponential (or worse) latency bottlenecks by way of metcalfe's law.
the speed of light, as a hard limit, starts to become insurmountable when your consensus pathway has to be traversed the equivalent of tens of millions of km of signal path in order for every node to have an equal influence on the validity of every other node's vote.
these high tps coins all seem to get around this by weakening decentralization, whether by shortening this path, either because they have far fewer nodes, or are deciding to sum over some approximation of node consensus by sampling or creating privileged paths, or because geography already creates privileged paths (all the nodes are in the same general area, or even in the same datacenter).
I suspect the reason TX speed tends to stay mired in the tens per second region is that no amount of consensus accounting gimmickry will overcome the underlying physical limitations of true global scale decentralization of consensus.
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
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.
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?
> 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.
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.
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.
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.
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.
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?).
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.
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.
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.
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.
>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.
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.
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.
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.
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)
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-...
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.
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.
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.
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)
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.
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.
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.
> 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?
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.
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.
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!
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"
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.
> 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.
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”.
Except that I can easily run a full bitcoin node on my desktop but not an ethereum node. What is the point of having a cryptocurrency if I have to trust someone else to run the software for me?
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.
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.
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.
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.
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.
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.
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
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.
>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:
> 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?".
>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.
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?
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.
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 persona...
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.
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...
>>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 i...
> 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 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: billytetrud↗
> 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.
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.
> 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?
> 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.
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.
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?
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?
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.
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.
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.
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.
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.
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?
233 comments
[ 2.8 ms ] story [ 272 ms ] thread100 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.
https://solana.com/
Every junk transaction costs them money
https://www.algorand.com/
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.
https://en.wikipedia.org/wiki/Mt._Gox
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.
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.
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/
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.
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.
[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.
https://news.ycombinator.com/item?id=25688004
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.
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
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.
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.
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.
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.
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.
>>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 persona...
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...
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 i...
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 ...
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: billytetrud ↗ > 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..? CryptoPunk ↗ Your arguments and analysis together contain grave contradictions that discredit them. billytetrud ↗ > you argue that your position/paper does not rely on potential future innovations billytetrud ↗ 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 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'r...
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.
https://news.ycombinator.com/item?id=27136533
https://utxos.org/uses/scaling/
https://utxos.org/analysis/bip_simulation/
https://utxos.org/analysis/batching_sim/
https://github.com/bitcoin/bitcoin/pull/21702
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.
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.
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?