We have seen this 'longest chain' verbiage where 'valid' is notably excluded for some time. I take it as a backup or auxiliary attack strategy. Every opportunity is taken to lay the foundation participant misunderstanding however. That misinformation effort seems to have picked up again over this last month here on bitcointalk.org.
Basically, if a bloatblock (for instance) can be inserted just one time, it would fork the chain and obsolete Bitcoin core software.
So what if a given version of bitcoin software is obsoleted by evolution of the network? The "core" developers have done this themselves several times. Arguments along the line of "longest valid chain" do not resolve the issue under debate. They just move the debate to the meaning of the word "valid".
Despite some advertising claims, the security of bitcoin does not depend on mathematics alone, it depends upon running software, which intern depends on running hardware which is supported by the economic majority. Any other way of defining "valid" necessarily requires the argument from authority, which ultimately results in a debate over who is the authority. With this, any hope of a decentralized system goes out the door.
Valid is subjective of course, and the changes to that are decided by the dev team. Very perceptive! That's how it's always been, seeing as even now Bitcoin is still a work in progress.
The system is already decentralised in the ways that Satoshi imagined. Yours and the "Bitcoin Unlimited" crowd's mentality involves letting the user loose with deciding every aspect of the system. It's lunacy, it's the opposite of what's been going on up to now, and it would end with all the different "Bitcoins" disintegrating, apart from the overbloated centralised one perhaps
Valid being a subjective term is indeed a good observation. The question still stands of who decides? Obviously you think that the Core developers should decide for us, I think that the decision making process for Bitcoin should become more distributed instead, the future of Bitcoin should be decided by the economic majority which as far as I understand it is also how Bitcoin ultimately still functions today.
Satoshi decided for us. Should we tear apart the whole thing and have it rewritten by "the economic majority"?
The will of the economic majority is more important then Satoshi's vision. Invoking Satoshi's vision surely must be a mistake on your behalf however since he did support increasing the blocksize:
While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section Cool to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. 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.
The eventual solution will be to not care how big it gets.
But for now, while its still small, its nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that wont matter much anymore.
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.
He even specified how we should phase it in:
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.