We have fixed serious currency-ending flaws in the protocol design in the last year (and in every year before, for that matter), e.g. in this one from March a tricky interaction between the surprising possibility of creating _valid_ duplicated transactions and the way the protocol undoes blocks during reorganization made it possible for someone to mine a pair of blocks which when shown to a node cause it to forever separate from the main network.  Another example is this one from May, where bitcoin's transaction hash tree is calculated in a flawed manner where a different set of transactions can be created for a block that have the same hash (a second-preimage attack on the function). An attacker could use this to create a bizarro version of a valid block that was invalid— carrying duplicated transactions— but had the same hash/ID, and after giving it to a node that node would never reorganize onto the chain containing it or its valid clone, leaving that node on a fork or preventing particular miners from successfully mining. (This attack doesn't even require the attacker to mine, he only has to relay maliciously). It turned out that the attack blocks had to a special form which can be rejected very early on before saving the block then the node can blacklist the peer and not allow that to prevent it from fetching the same block ID from another peer and, eventually, get a non-corrupted copy.  These were both day-one protocol design flaws that could be used for either massive scale denial of service attacks, or targeting single nodes to rob them (by mining some blocks slowly on the fork they're on).

Protocol level flaws are not unique to any particular implementation but implementation specific bugs are dangerous for all Bitcoin users, not just for people who are on the broken implementation: Because Bitcoin is a distributed consensus algorithm consistency is more important than correctness— a serious implementation specific flaw in _any_ widely deployed implementation, especially one widely deployed in merchants and miners— may result in a complete failure of the system (e.g. allowing half of all transactions for a day or two to be reversed and respent to new destinations, bankrupting a significant chunk of users and rightfully scaring everyone sane away from the system), because regardless of which implementation is right if nodes don't agree they will split into two currencies where all the coins can be spent in each. Once healed one side must lose, so it's more important to be consistent than correct. The attacks I listed above are so dangerous in  particular because an attacker could use them to create inconsistency in the network.

By taking extra care and doing extra design work we've kept the protocol fully compatible while fixing these things— as far back as 0.2.10 (compatibility prior to that was broken by _Satoshi_ on a several year time delay, and absent that protocol version change I believe we're compatible to the first version). Although old nodes could be subjected to targeted attacks absent an attack they continue to work like normal. If you don't want software that changes you can just continue to run old software… and get robbed when someone finally gets around to attacking you. (Although I strongly encourage you to not keep substantial funds in known vulnerable nodes, or even online, if there is anything I've learned from Bitcoin is that there is no amount of potential loss which is great enough to make many people become careful and informed about security— no amount of explanation of risk that will prevent someone from saying "well I haven't been robbed yet!"— witness the popularity of untrustworthy centralized services, scams, etc.)

Of course, many non-protocol changes are constantly being worked on by the small crew of active developers and by smaller contributions from the broader community— fixing bugs that crash the software, adding infrastructural features that make it possible for people to run fancy services like web wallets, explorers, escrows, and distributed bond markets (e.g. raw transactions), closing day one denial of service vulnerabilities that malicious parties could use to shut down all copies of the software, and improving performance so that Bitcoin doesn't become centralized to a few big websites that could afford to keep running inefficient node software (or write their own private non-released high performance software)— itself an essential aspect of security. If Bitcoin was just a couple major exchanges and webwallets— well, we'd be better off with paypal.  

There remain serious performance and DOS issues which are not yet resolved, many kinds of Bitcoin service that can't be provided without modifying the software,  etc— lots of work remains before we even start talking about all the squishy-feely user-centric improvements which are also urgently needed.   These sorts of challenging and unsexy infrastructural tasks are the things the core developers are working on and I find it depressing that this work is not only not highly appreciated by some in the community but the that community tolerates persistent misplaced attacks which violate even the broadest definitions of acceptable conduct.

It'd have nearly the same amount of influence if all of the main developers transferred to it.

Might as well just explicitly declare the end of the bitcoind development project.

bitcoind is currently the only stable implementation of a full Bitcoin node AFAIK, so if the bitcoin.org project was closed everyone would move to some fork of bitcoind. Probably a fork maintained by the current developers of the bitcoin.org client. There wouldn't be much increase in "decentralization".

Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

(or maybe just bitcoind) would be quickly out-competed if that rule was adopted.

You do realise that Bitcoin is an experimental currency as the warning states on bitcoin.org 'Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world.'

The word experimental to me brings up things like expect change until its been gotten right. As is there has been a lot of faith in the terms of money from punters such as myself and time from the devs etc. that it will succeed eventually but it is still a risk, one that I willingly take. I have not found any guarantees for Bitcoin yet.

I put faith in the devs that they are doing the right thing, if they had nefarious intentions it would of been far more easily to implement in the past than now as each day passes. I dont have a coding background so I also have to have faith in those that do and keep an eye on the code.

Educate yourself on how to actually fix your perceived problems, learn coding, make your own fork etc.

Get some life experience as well.

Yet another baseless accusation leveled at Rarity.  Let me guess, you have posted with the troll planners on this "Something Awful" too?

Rarity was the definition of a reasonable skeptic on these forums.  Her skepticism of libertarian arguments and her pro-government and regulation views were labeled as trolling specifically because they were a minority viewpoint strongly argued.  Some of those with less faith in their views could not handle the challenge of not not existing in an echo chamber and chose the easy way out of attacking the messenger rather than defending their views.

Yea but if nobody agree with his protocol change, no one will follow his fork anyway and instead will continue to use the old fork.

You understand that the source code for the "official" software is open source, and that you and anybody else is welcome to take a copy of that source code and modify it right?  That as long as your modified software adheres to the rules of the protocol, it will work with the bitcoin system?

Nice agressive confrontational very first post.  Good luck!

It sounds more and more that the definition of "trolling" on this forums is simply "stuff Theymos doesn't like"

Well, the problem is really that we haven't finished (or even started) deploying bloom filters. It means the RAM requirements are going up over time as Bitcoin usage scales.

There's no theoretical reason Bitcoin can't run well on your phone. But as Andreas said, we haven't finished all the programming for that yet.

Right, sort of how companies like Cisco, Intel, Apple, Microsoft, and Google, and guys like Linus Torvalds, have little to do with people's ability to read their e-mail, and they owe 98% of the credit to the guys who invented the binary code and the transistor.

Satoshi also made 98% of SolidCoin, NameCoin, I0coin, IXCoin, and every other coin out there that is presently deep in the toilet.

Bitcoin trades at over $12 a coin because of the collective actions and frequent releases of the Bitcoin devs, entities like MtGox/BitInstant/BitPay, utilities like BlockChain.info, the many businesses who accept Bitcoin as payment, promoters like Bitcoin Magazine and WeUseCoins.com (not to mention my own coins), and like it or not, things like the Silk Road.  When you say "Hey Gregory, you didn't build that!", that's being a douche and has nothing to do with how much money you have in Bitcoin - it's just plain and simple being a douche.

Which is it?  How many fingers can you chop off your hand before it ceases to be a hand?

The way I see it, by downloading the software, they are paying, just not with money, the same way they "pay" Google by seeing ads.  These people are offering Bitcoin (the idea) a share of their mind and their time.  They are incrementally adding to the entire Bitcoin-based economy by considering accepting Bitcoins in exchange for their goods and services.  They are paying with their willingness to change how they see a BTC as something worth 0.00 to them, to something worth over $10.  Of course, I am also respectfully keeping in mind that you have contributed substantially to bitcoind, and I have not.

Here's another example of central planning: http://www.bitcoin.org/bitcoin.pdf

In other words, not persuasive.