![]() ![]() If you're not mining, I personally would say it can only be good if you just follow the protocol spec and try to implement Bitcoin from there. There has been a lot of behind-the-scenes work on cross-implementation testing (the “testnet3″ blockchain contains hundreds of transaction validation test cases, for example), and new features are being added to the protocol to support alternative implementations > part of the solution is to encourage alternative implementations that make different trust/convenience tradeoffs than the reference implementation. It’s one of the few things that could instantly kill Bitcoin beyond legal harassment of its users. This can fork the chain and split the economy. Bitcoin is very complex and if you aren’t skilled and very thorough you are likely to diverge from its behavior in small, hard to detect ways. > What some people, especially Satoshi, have said is that there’s an unusual amount of risk involved with reimplementing the full system and using that reimplementation to mine. Nobody is against alternative implementations. Satoshi expressed very similar sentiments. > Gavin wrote to me only days after the BitCoinJ release to tell me how happy he was to see an alternative implementation. Many Bitcoin developers are actually quite positive to the idea of alternative implementations all they're saying is "be careful". ![]() Hi there, original author of the article here. Many of the most interesting cases are the great many things which must be rejected as no amount of exposure to the live network will trigger those cases (until an attacker exploits them to partition the network). This requires a unusual level of care and system level tests. The Internet would sort of suck if HTML5 were a purely advisory document and failing to match IE6's actual behavior 100% of the time was a fatal flaw in a browser." But, to quote a fairly representative post from their forums:Īny implementation needs to specifically test for uniformity with the network: Bitcoin is a distributed consensus algorithm and differences in what nodes accept or reject in the blockchain- things which would be minor harmless behavioral differences in most software- can often result in fatal security flaws where an attacker can move the nodes in question onto a separate fork and double-spend their funds away or partition the network. This might come as something of a surprise to many HNers, who would think "But wait. ![]() This remains true even if you improve upon the satoshi client with regards to, for example, hewing closer to the published spec. Interestingly, the main bitcoin developers generally treat other implementations of the protocol as being suspect and more-than-possibly threatening, since if you're not bug-for-bug compatible with the satoshi client that is a security risk. ![]()
0 Comments
Leave a Reply. |