> Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
https://bitcointalk.org/index.php?topic=1790.msg28917#msg289...
There has always been a challenging trade-off here, which is presumably why he limited the size in the first place.
This trade-off was widely acknowledged in the community going back essentially as far as records do.
And as time has gone on we've only learned more about how some ideas don't work. For example, Satoshi believed businesses would run nodes to verify their own transactions-- but we've found in practice few do, instead outsourcing it to centralized third parties often with dubious security practices.
You're singling out one expression of mildly small-block sentiment and overlooking multiple expressions of strongly large-block sentiment by Satoshi.
He _implemented_ the block size limit, nothing forced him to. Had he wanted it to change automatically he could have coded it that way. Instead, he tended to describe the design as being mostly set in stone. When someone tried to remove the limit he urgently yelled at them to stop (and stated if it were ever needed it could be phased in). I'm sure that his, like everyone elses, understanding of the requirements evolved over time too.
Meanwhile, scaling Bitcoin via layers was endorsed explicitly by essentially every technical voice in the space for years until some got wrapped up with scammers. Satoshi even built specific affordances for payment channels directly into the transaction format, and was the first person to describe their use.
"At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node."
- November, 2008
Here:
"The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users."
-July, 2010
Here:
"It would be nice to keep the [block chain] files small as long as we can.
The eventual solution will be to not care how big it gets.
But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore. (note to readers, "client-only mode" refers to SPV mode)"
- August, 2010
Here:
"The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling."
- in an email to Mike Hearn
Are you really unfamiliar with these, or think they're not worthy of your reader's attention?
The second is saying not literally every user, similar to the third. (and in fact said it would be best to keep things as small as possible for as long as possible!)
The last was in a message thread that discussed using payment channels.
So I do not agree with your claim that they unambiguously supported your position, moreover they were made much earlier-- before there was much practical experience. I already pointed out his last comment on the subject...
There's no evidence to suggest it's discussing mining. It's directly in response to a criticism of the Bitcoin design, where a correspondent argues that everyone validating everything to ensure the transactions they receive are valid will get too costly in computing resources. This is the email that the quoted statement was responding to:
http://www.metzdowd.com/pipermail/cryptography/2008-November...
>To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.
So it's unambiguously about validation. Why would you claim otherwise?
And the last known statements Satoshi made on it were in emails to Mike Hearn, like this one, from December 29 2010:
>>A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
>>Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
>>With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
>>Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.
That is much more clearly his preference/vision than the brief reference to the community turning tyrannical about block sizes, and it was more recent.
There is no technological bottleneck preventing a 100X raising of the throughput limit: not Initial Blockchain Download, which is already being expedited with trusted third party set checkpoints, not computation, not storage and not bandwidth.
The vast majority of Bitcoin agreed with my sentiment, and that was the sentiment expressed by Satoshi any time he commented on it.
It was just irresponsible, overly timid leadership allowing a loud minority to sabotage Bitcoin's widely supported roadmap.
Responding to the comment below:
1. You can prune spent transactions. Only the UTXO set needs to be stored, so you don't need to store 5 TB more each year. But even that wouldn't be prohibitively costly for thousands of hobbyists worldwide. So even if pruning wasn't an option - and it is - Bitcoin's censorship resistance would remain totally secure.
2. You can use checkpointing in initial sync up, instead of downloading the entire transaction history. The hash of the true chain is widely disseminated and Bitcoin nodes already use a form of checkpointing, where they skip validation for transactions before the checkpoint flag, to expedite Initial Blockchain Download.
The average web page these days is over 1 MB. The idea that you need to limit every once-in-every-10-minute block to 1 or 1.6 MB is not, from everything I can see, close to approaching a sound balancing of competing priorities.
There never was a scaling issue.
Bitcoin core has had since the Big Forks a larger number of transactions than Bitcoin Cash, which was forked to allegedly fix the transaction rate.
If the rest of you had actually tried /running a node/ instead of just copying and pasting the fifty cent army's argument of the day maybe you'd realize that.
Layer 2 is where the scaling happens. END OF STORY.
Checkpointing is also currently being utilized in Bitcoin Core, so relying on it further is not a major departure on how things are currently done.
And at 100X current block sizes, validating the entire history with no checkpoints will still be possible for thousands of hobbyists with beefed up but still modest hardware/bandwidth.
The empowerment from 100X more people being able to write transactions to the main chain, with their own private keys, will be well worth the relatively tolerable compromises on full node validation.
Not fully verifying history is a complete departure from how things are done in bitcoin full nodes.
And Bitcoin Core removed even those checkpoints [1].
[1] https://bitcoin.stackexchange.com/questions/75733/why-does-b...
Currently it has checkpointing in the form of assumevalid, which by default causes a full node to skip validation of transaction older than the checkpoint when synchronizing. [1]
[1] https://bitcoin.stackexchange.com/questions/88652/does-assum...
As it is, tens of millions of people can easily stream 700 KB/s HD video 24/7, yet Bitcoin is being kept to a throughput of 2 KB/s based on the claim that increasing it to satisfy market demand would lead to Bitcoin becoming centralized, with only large corporate entities left being able to fully validate.
It's pure FUD.
The security of the system comes from decenteralization, so its goals can't be reached if its only workable for the best funded 10% of the participants. Moreover, the operating cost of a node are only compensated fairly indirectly and are a public good (if everyone else runs an honest node, you don't gain from running your own). As a result, it's not sufficient to just be not-astronomical, it has to be fairly close to painless.
Node's ability to keep up is also only one part of the equation. Bitcoin's long term security is absolutely dependant on transaction fees paying for proof of work. With functionally limitless capacity the natural price of transactions is essentially zero-- as has been demonstrated by competing systems which have found that they can only fund security with inflation.
Most critically-- while you can make a fine argument that some moderate increases (more like 2x or 5x than 100x) are viable without too much increase in security risks-- those kinds of changes (heck, even 100x) don't categorically change the situation.
But we do have technology to categorically change the situation, tech that was thought of and made accordance for before Bitcoin was ever released and has always been part of the long term plans-- regardless of whatever lies motivated parties might want to tell you-- tech like lighthing adds essentially unlimited transaction throughput to Bitcoin because it doesn't require public broadcast for each and every transaction. I was talking to someone this morning who is doing a test sustaining 400 transactions per second.
> and that was the sentiment expressed by Satoshi any time he commented on it.
Sorry, that is just a flat out lie-- at I pointed out in a prior comment literally the last public statement Satoshi made on the matter of scalablity/resource usage was: "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."
https://bitcointalk.org/index.php?topic=1790.msg28917#msg289...
There is a long history of the position I'm presenting, going back to many of Bitcoin's earliest participants.
As for initial synchronization:
There is no basis for claiming users cannot keep up with it at 100X current throughput levels, and like I said, relying on trusted third party set checkpoints to completely do away with validating the entire blockchain history is always an option, and already one being utilized to some extent with the flag in Bitcoin Core to skip validation on transactions older than a TTP-set checkpoint.
Saying every one should validate, but then limiting the world to 300,000 on-chain writes a day, meaning limiting who can use Bitcoin without third-party intermediaries to 0.1% of the world population, is a bad trade-off. Better 10% of Bitcoiners be able to run their own fully validating node, and all 7 billion people be able to generate transactions *with their own private keys*, than let every one with a PC run a fully validating node, while only 0.1% make writes to Bitcoin with their own private keys.
In a scenario where a party cannot write a transaction to Bitcoin, due to limited on-chain capacity, there is little point in running a fully validating node. Emphasizing full node validation accessibility over main chain write accessibility to this extent is not a sensible prioritization.
Regarding this off-chain payment channel networks Red Herring, there is no reason to be confident that PCNs like the lightning network can provide a mix of trade-offs that will make them compelling to a wide set of users, and indeed the LN has still failed to get traction nearly 6 years after first being proposed.
The capital lock-up requirements, especially in a setting where on-chain transaction fees are high, the need for being online to trustlessly receive funds, and the routing challenges, are all potentially fundamental showstoppers for the LN being a viable technology for widespread utilization/adoption.
Finally, even if payment channel networks work - which is a very speculative 'if' and not one that the entire empowerment of humanity with access to electronic cash should be made dependent on - blocks would still need to be on the order of 100X larger to enable global mass-adoption, as payment channel networks do not completely do away with the need to have on-chain throughput.