The devs didn't stop anything over the overflow bug. All that they did was contact a majority share of miners, let them know that there was a problem, and asked them to cooperate. They did. If they had not, the devs couldn't had done much of anything to stop the overflow bug. In hindsight, it wouldn't have amounted to much anyway. Once those same miners had upgraded to the patched client, those same clients just started to reject blocks with an overflow transaction and backed up the blockchain as far as was required automaticly. There were still old clients trying to submit tainted blocks for weeks because there were miners who had not been paying attention and had not upgraded. I was here when that all went down, and wasn't mining; and I can honestly say the network didn't really skip a beat from the perspective of a casual user.
Well, I can see quite plainly that BTC is still around. However, that was what? 2-3 years from its beginnings? Every year more BTC users and miners are added to the overall pool. How long until the people not paying attention outnumber the people who do? What happens if some change requires a major update to clients as well as miners?
Moreover, if I'm not mistaken when the overflow bug was discovered, the devs issued an "emergency alert" similar to the "check for new updates" function present in basically all other modern software. This feature, while only a half-implementation of automatically detecting new updates, has since been disabled. I don't know that there's even a "correct" answer to that problem, with the complexities of alt clients added into the mix.
When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.
If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).
Again, you display your ignorance in such matters. There are sound reasons for everything that ou sight, and foreseeable solutions to the potential problems that you noted. These topics have been debated to no end long before you ever arrived. The search function is your friend.
I have read most of the arguments, as well as a lot about the protocol itself on the wiki. That is how I know that many of the design choices were either economically or programatically unsound.
There definitely needs to be a connection between accounting and the security of that accounting, but there is no need for them to be inseparable, and ultimately the accounting is more important than documenting the security forever, not to mention potentially orders of magnitude more efficient spacewise.
There does not need to be any direct connection between standard tx and contracts with complicated scripts. Standard tx have no need for scripts, and of the few (like 2 at most) scripts that have an actual use, they could be simplified a great deal. Currently you can't even use the scripts that
are useful, ie the minimal trust escrow feature.
Finally, the "solution" of pruning the merkle trees of previous tx doesn't help miners any, and furthermore excludes clients (ie anyone who doesn't own a giant server cluster) from verifying tx for themselves. Not only does that kill decentralization, but it also stops merchants from verifying tx, which means either they can't use BTC or else the customer has to stand around for an hour or so waiting for the first confirmation. I don't call that a solution at all.
A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.
Again, there are sound reasons for the choices. Do some research, please.
Sound economically? Sound in terms of programatic and storage efficiency? Sound in terms of flexibility?
That's too vague to agree or disagree with. I still have yet to read the whitepaper, but I'll get around to it soon enough. ATM I couldn't tell you specifically what in terms of satoshi's theory I may agree or disagree with, only what I've seen in the actual implementation thereof.
More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.
Not yet, but someone is going to add such funtions before they are really neeed.
Perhaps. That depends on what hooks are left in the original client for this and whether or not they are flexible enough to allow what needs to be done. It also depends on how standardized said hooks are, and whether there will be disagreements on how to extend the implementation. In terms of shifting decimals fluidly and the storage of the values and the standardization thereof there's a whole lot of room for compatibility to break. The longer implementing it in a standard way is put off, the worse the potential disconnect becomes.
I'll have to read the whitepaper to see if it says anything specific on the matter.