Quote from: gmaxwell on October 23, 2012, 06:46:28 AM

Quote from: kaerf on October 23, 2012, 03:53:18 AM

I think that's a whopper of an assumption. It can take years/decades to find weaknesses in crypto systems....meaning someone might find a vulnerability tomorrow or someone might find a vulnerability in several years. Given the narrow adoption of bitcoin, I'd say there hasn't been enough significant research to dismiss bitcoin's protocol as fundamentally sound. In fact, there never will be. We're always questioning and finding vulnerabilities in (existing) crypto systems.
Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

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.

I will not questions things any further. I submit. I am gone.