8 ms·

Interestingly, the main bitcoin developers generally treat other implementations of the protocol as being suspect and more-than-possibly threatening, since if y

by patio11 14y ago

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. This remains true even if you improve upon the satoshi client with regards to, for example, hewing closer to the published spec. This might come as something of a surprise to many HNers, who would think "But wait. 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: Any 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 requires a unusual level of care and system level tests. 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). (cite: https://bitcointalk.org/index.php?topic=192880.0 https://bitcointalk.org/index.php?topic=192880.0)

mseebach 14y ago
How can a bug in the implementation be a security risk? Aren't the artefacts of bitcoin (I don't know the correct terminology) cryptographically unambiguous, completely independent of the implementation used to create them? The "problem" with HTML incompatibilities is that there is room for plenty of ambiguity in both standard and implementation, without compromising the fundamental mission of the users of the protocol (rendering web content).
- betterunix 14y ago
  "How can a bug in the implementation be a security risk?" It could fork the block chain: http://bitcoin.org/chainfork.html http://bitcoin.org/chainfork.html
- Strilanc 14y ago
  If one type of client accepts a particular block and another doesn't, the block chain splits and things go badly. This literally happened one month ago, because of a bug being fixed: https://bitcointalk.org/index.php?topic=152030.0 https://bitcointalk.org/index.php?topic=152030.0
  - mseebach 14y ago
    Ugh, that is very bad. I had much higher thoughts of the cryptographic purity of BTC.
    - betterunix 14y ago
      The cryptographic purity of a system without a formal security definition and for which there is a known polynomial time attack? I think you were bound to be disappointed...
    - fianchetto 14y ago
      Bitcoin is cryptographically pure but programmers aren't quite as perfect.
      - betterunix 14y ago
        What is the security definition?
        nullc 14y ago
        https://socrates1024.s3.amazonaws.com/consensus.pdf https://socrates1024.s3.amazonaws.com/consensus.pdf
        betterunix 14y ago
        I think this paper presents a poor security definition for Bitcoin, at the very least because it assumes a non-adaptive adversary (i.e. the adversary cannot change which nodes it controls over time). That is not how things work in the real world; in the real world, the adversary will keep increasing his computational power (the number of "pawns") until his attack is successful. I am also skeptical of a computational model that assumes the adversary's computation is somehow synchronized with the honest parties'; that is not even remotely realistic, and it is very weak. In other words, that paper does not tell us anything we did not already know: Bitcoin is secure only if nobody does as much computational work as the rest of the network combined (though there may be other attacks on the protocol that have not yet been discovered). If anything, this paper is a step towards formalizing a security definition for a protocol that is similar to Bitcoin, or a step towards proving that there will always be a polynomial time attack against such protocols (as was the case with Merkle's puzzles).
- zoul 14y ago
  A bug in the implementation could affect the consensus about the largest chain, just as happened with the official client recently. That’s a security risk.
- patio11 14y ago
  How can a bug in the implementation be a security risk? This gets a little complicated. "Bitcoin" is a commodity, a protocol (series of promises), a protocol (computer code to implement that series of promises), a particular distributed ledger, a network (of computers implementing the computer code implementing the series of promises with regards to one consensus distributed ledger), etc etc. Consider bitcoin the series of promises. One such promise is under what circumstances opcode 32 causes a transaction to be marked as invalid. (Don't bother looking it up -- you'll have to go down a rabbit hole for a while.) It is critically important that all code implementing opcode 32 comes to the same conclusion regarding every transaction in history and every transaction in the future. Consider an edge case for opcode 32, occurring in a transaction that I'll call T, two years ago. T is, as of right now, accepted as valid in the history that bitcoin (as you understand that term) accepts as correct. If a malfunctioning bitcoin client were to reject T, they would reject large portions of history after T, because they'd be predicated on an invalid series of transactions. Following me so far? So the more interesting case isn't when there is a difference of opinions in the past, it is when there is a predictable difference of opinions in the future. In this case, one set of clients starts building a transaction ledger B, and one starts building a transaction ledger B'. They are different transaction ledgers. People subscribing to either ledger, which they think of as The One True Bitcoin Ledger, will be mighty pissed when other people in The One True Bitcoin Economy tell them that their unforgeable, unloseable, ungovernable units of crypocurrency are actually worthless bits. This is called a blockchain fork. Bitcoiners are terrified of it happening again. (Yes, it has already happened at least once. Long story. "No harm, no foul, he wasn't trying to crash our entire economy so we dodged a bullet." is pretty much the consensus among Bitcoiners who actually understand what happened there.)
  - mechanical_fish 14y ago
    So, when this happens again, and then is discovered, who decides which partition of the tree is the "fork" and which is the main branch? I presume it happens by consensus? But... where does consensus come from, in the general case? Does it operate like much open-source governance, via a mix of public and private meetings on IRC between the maintainers of the biggest clients? When that "community" decides to invalidate the mobster's Bitcoins, is there an appeals process, and do the judges have bodyguards? How does one get a seat at the Bitcoin developer summit in the first place? Do the contributors of the most code have the most influence? Which in practice usually translates to "friends and allies of the project founder" and "rich individuals and companies who pay developers to contribute to the project in order to influence its direction?"
- wcoenen 14y ago
  A bitcoin node tries to determine what the consensus is about the bitcoin ledger by looking for the longest block chain. However, in order to do that it must first collect blocks from other nodes and reject any invalid ones. If a certain implementation disagrees with the rest of the network about the validity of a block, then it will disagree with the rest of the network about the state of the ledger. This can then be exploited by an attacker, e.g. by paying a merchant with a transaction that seems to OK to him but is not accepted by the rest of the network. I don't think that this is a big problem though. A node knows that it is no longer in agreement with the majority of the network when it sees an "invalid" block chain that has the most proof of work done on it. In this case it should shut itself down.
evv 14y ago
More importantly, I believe, is the fact that nobody can stop alternative implementations from existing on the network. Attackers are probably already tinkering with custom BTC clients, attempting to abuse the system. If this were really a concern, it is far too late. The smart bitcoin users will choose the best client available, not just the default one.
- betterunix 14y ago
  "The smart bitcoin users will choose the best client available, not just the default one." What you are saying is that the security of Bitcoin depends on everyone other than the smart users. If the block chain is forked because of an incompatibility between two Bitcoin clients, the fact that smart users choose the "best" client is irrelevant; you need most users to choose that client. You should not rely on most of the users of a cryptosystem to be "smart" about using it: http://www.securius.com/newsletters/Security_Through_Usability.html http://www.securius.com/newsletters/Security_Through_Usabili...
  - nullc 14y ago
    Not simply "most": "Virtually all". A split that was near 50/50 (e.g. 'most') would be an utterly pessimal outcome, while a 99.9/0.01 split is probably pretty harmless, at least if you talk in terms weighed by some kind of amorphous economic significance.
vbuterin 14y ago
Hi there, original author of the article here. Many Bitcoin developers are actually quite positive to the idea of alternative implementations; all they're saying is "be careful". > Gavin wrote to me only days after the BitCoinJ release to tell me how happy he was to see an alternative implementation. Satoshi expressed very similar sentiments. Nobody is against alternative implementations. > 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. 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. This can fork the chain and split the economy. It’s one of the few things that could instantly kill Bitcoin beyond legal harassment of its users. - Mike Hearn 2011 > part of the solution is to encourage alternative implementations that make different trust/convenience tradeoffs than the reference implementation. 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 -Gavin Andresen, late 2012 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. If you fall off the main chain and it's not obviously your fault, then either the protocol spec was unclear and can get improved or the original client has a bug, in which case there are ways to carefully phase the bug out of existence with a patch.
shazow 14y ago
I probably haven't been keeping up with the bitcointalk forums as much as yourself, but I haven't gotten the impression that the main bitcoin developers treat alternative implementations as threatening. There are already several moderately-popular alternative implementations in the wild. Bitcoinj is used by pretty much every Android-based Bitcoin app. Electrum (a popular thin-client) is using a custom implementation on their backends, too. Every time I ask or see a question from people who are working on alternative clients, the developers have always been supportive and informative. The biggest problem, and possibly the underlying spirit of the warning you quoted, is that the current version of the protocol is not super-well documented. Some data structures are undefined and need to be reverse-engineered from other implementations (such as net_time), others are ambiguously defined. My takeaway from the thread you linked is closer to this quote: "Yes, please, feedback from re-implementors is very helpful." — Gavin Andresen, lead Bitcoin developer.
- nwh 14y ago
  > Electrum (a popular thin-client) is using a custom implementation on their backends, too. The Electrum server doesn't do any network communication of it's own, it's a bunch of external databases that does it's communication though a standard bitcoind.
GigabyteCoin 14y ago
I think you are misinformed. There are links to multiple Bitcoin clients on bitcoin.org which is controlled by "the main Bitcoin developers": http://bitcoin.org/en/choose-your-wallet http://bitcoin.org/en/choose-your-wallet Where did you get the impression that the Bitcoin devs treat other clients as "suspect and more-than-possibly threatening"?
gojomo 14y ago
The early days of the web were similar; that's how you get rapid evolution in a decentralized system. The whole Bitcoin ecosystem is learning by doing, with lots of precocious amateur participation, under intense pressure. Ultimately that may make it stronger. Those who prefer spec stability should stick to systems built by government/defense contracting.
dennisgorelik 14y ago
Why do you even discuss technical side of bitcoin if you find the whole bitcoin business concept flawed?

by patio11 14y ago

mseebach 14y ago

How can a bug in the implementation be a security risk? Aren't the artefacts of bitcoin (I don't know the correct terminology) cryptographically unambiguous, completely independent of the implementation used to create them? The "problem" with HTML incompatibilities is that there is room for plenty of ambiguity in both standard and implementation, without compromising the fundamental mission of the users of the protocol (rendering web content).

betterunix 14y ago
"How can a bug in the implementation be a security risk?" It could fork the block chain: http://bitcoin.org/chainfork.html http://bitcoin.org/chainfork.html
Strilanc 14y ago
If one type of client accepts a particular block and another doesn't, the block chain splits and things go badly. This literally happened one month ago, because of a bug being fixed: https://bitcointalk.org/index.php?topic=152030.0 https://bitcointalk.org/index.php?topic=152030.0
- mseebach 14y ago
  Ugh, that is very bad. I had much higher thoughts of the cryptographic purity of BTC.
  - betterunix 14y ago
    The cryptographic purity of a system without a formal security definition and for which there is a known polynomial time attack? I think you were bound to be disappointed...
  - fianchetto 14y ago
    Bitcoin is cryptographically pure but programmers aren't quite as perfect.
    - betterunix 14y ago
      What is the security definition?
      - nullc 14y ago
        https://socrates1024.s3.amazonaws.com/consensus.pdf https://socrates1024.s3.amazonaws.com/consensus.pdf
        betterunix 14y ago
        I think this paper presents a poor security definition for Bitcoin, at the very least because it assumes a non-adaptive adversary (i.e. the adversary cannot change which nodes it controls over time). That is not how things work in the real world; in the real world, the adversary will keep increasing his computational power (the number of "pawns") until his attack is successful. I am also skeptical of a computational model that assumes the adversary's computation is somehow synchronized with the honest parties'; that is not even remotely realistic, and it is very weak. In other words, that paper does not tell us anything we did not already know: Bitcoin is secure only if nobody does as much computational work as the rest of the network combined (though there may be other attacks on the protocol that have not yet been discovered). If anything, this paper is a step towards formalizing a security definition for a protocol that is similar to Bitcoin, or a step towards proving that there will always be a polynomial time attack against such protocols (as was the case with Merkle's puzzles).
zoul 14y ago
A bug in the implementation could affect the consensus about the largest chain, just as happened with the official client recently. That’s a security risk.
patio11 14y ago
How can a bug in the implementation be a security risk? This gets a little complicated. "Bitcoin" is a commodity, a protocol (series of promises), a protocol (computer code to implement that series of promises), a particular distributed ledger, a network (of computers implementing the computer code implementing the series of promises with regards to one consensus distributed ledger), etc etc. Consider bitcoin the series of promises. One such promise is under what circumstances opcode 32 causes a transaction to be marked as invalid. (Don't bother looking it up -- you'll have to go down a rabbit hole for a while.) It is critically important that all code implementing opcode 32 comes to the same conclusion regarding every transaction in history and every transaction in the future. Consider an edge case for opcode 32, occurring in a transaction that I'll call T, two years ago. T is, as of right now, accepted as valid in the history that bitcoin (as you understand that term) accepts as correct. If a malfunctioning bitcoin client were to reject T, they would reject large portions of history after T, because they'd be predicated on an invalid series of transactions. Following me so far? So the more interesting case isn't when there is a difference of opinions in the past, it is when there is a predictable difference of opinions in the future. In this case, one set of clients starts building a transaction ledger B, and one starts building a transaction ledger B'. They are different transaction ledgers. People subscribing to either ledger, which they think of as The One True Bitcoin Ledger, will be mighty pissed when other people in The One True Bitcoin Economy tell them that their unforgeable, unloseable, ungovernable units of crypocurrency are actually worthless bits. This is called a blockchain fork. Bitcoiners are terrified of it happening again. (Yes, it has already happened at least once. Long story. "No harm, no foul, he wasn't trying to crash our entire economy so we dodged a bullet." is pretty much the consensus among Bitcoiners who actually understand what happened there.)
- mechanical_fish 14y ago
  So, when this happens again, and then is discovered, who decides which partition of the tree is the "fork" and which is the main branch? I presume it happens by consensus? But... where does consensus come from, in the general case? Does it operate like much open-source governance, via a mix of public and private meetings on IRC between the maintainers of the biggest clients? When that "community" decides to invalidate the mobster's Bitcoins, is there an appeals process, and do the judges have bodyguards? How does one get a seat at the Bitcoin developer summit in the first place? Do the contributors of the most code have the most influence? Which in practice usually translates to "friends and allies of the project founder" and "rich individuals and companies who pay developers to contribute to the project in order to influence its direction?"
wcoenen 14y ago
A bitcoin node tries to determine what the consensus is about the bitcoin ledger by looking for the longest block chain. However, in order to do that it must first collect blocks from other nodes and reject any invalid ones. If a certain implementation disagrees with the rest of the network about the validity of a block, then it will disagree with the rest of the network about the state of the ledger. This can then be exploited by an attacker, e.g. by paying a merchant with a transaction that seems to OK to him but is not accepted by the rest of the network. I don't think that this is a big problem though. A node knows that it is no longer in agreement with the majority of the network when it sees an "invalid" block chain that has the most proof of work done on it. In this case it should shut itself down.

evv 14y ago

More importantly, I believe, is the fact that nobody can stop alternative implementations from existing on the network. Attackers are probably already tinkering with custom BTC clients, attempting to abuse the system. If this were really a concern, it is far too late. The smart bitcoin users will choose the best client available, not just the default one.

betterunix 14y ago
"The smart bitcoin users will choose the best client available, not just the default one." What you are saying is that the security of Bitcoin depends on everyone other than the smart users. If the block chain is forked because of an incompatibility between two Bitcoin clients, the fact that smart users choose the "best" client is irrelevant; you need most users to choose that client. You should not rely on most of the users of a cryptosystem to be "smart" about using it: http://www.securius.com/newsletters/Security_Through_Usability.html http://www.securius.com/newsletters/Security_Through_Usabili...
- nullc 14y ago
  Not simply "most": "Virtually all". A split that was near 50/50 (e.g. 'most') would be an utterly pessimal outcome, while a 99.9/0.01 split is probably pretty harmless, at least if you talk in terms weighed by some kind of amorphous economic significance.

vbuterin 14y ago

Hi there, original author of the article here. Many Bitcoin developers are actually quite positive to the idea of alternative implementations; all they're saying is "be careful". > Gavin wrote to me only days after the BitCoinJ release to tell me how happy he was to see an alternative implementation. Satoshi expressed very similar sentiments. Nobody is against alternative implementations. > 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. 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. This can fork the chain and split the economy. It’s one of the few things that could instantly kill Bitcoin beyond legal harassment of its users. - Mike Hearn 2011 > part of the solution is to encourage alternative implementations that make different trust/convenience tradeoffs than the reference implementation. 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 -Gavin Andresen, late 2012 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. If you fall off the main chain and it's not obviously your fault, then either the protocol spec was unclear and can get improved or the original client has a bug, in which case there are ways to carefully phase the bug out of existence with a patch.

shazow 14y ago

I probably haven't been keeping up with the bitcointalk forums as much as yourself, but I haven't gotten the impression that the main bitcoin developers treat alternative implementations as threatening. There are already several moderately-popular alternative implementations in the wild. Bitcoinj is used by pretty much every Android-based Bitcoin app. Electrum (a popular thin-client) is using a custom implementation on their backends, too. Every time I ask or see a question from people who are working on alternative clients, the developers have always been supportive and informative. The biggest problem, and possibly the underlying spirit of the warning you quoted, is that the current version of the protocol is not super-well documented. Some data structures are undefined and need to be reverse-engineered from other implementations (such as net_time), others are ambiguously defined. My takeaway from the thread you linked is closer to this quote: "Yes, please, feedback from re-implementors is very helpful." — Gavin Andresen, lead Bitcoin developer.

nwh 14y ago
> Electrum (a popular thin-client) is using a custom implementation on their backends, too. The Electrum server doesn't do any network communication of it's own, it's a bunch of external databases that does it's communication though a standard bitcoind.

GigabyteCoin 14y ago

I think you are misinformed. There are links to multiple Bitcoin clients on bitcoin.org which is controlled by "the main Bitcoin developers": http://bitcoin.org/en/choose-your-wallet http://bitcoin.org/en/choose-your-wallet Where did you get the impression that the Bitcoin devs treat other clients as "suspect and more-than-possibly threatening"?

gojomo 14y ago

The early days of the web were similar; that's how you get rapid evolution in a decentralized system. The whole Bitcoin ecosystem is learning by doing, with lots of precocious amateur participation, under intense pressure. Ultimately that may make it stronger. Those who prefer spec stability should stick to systems built by government/defense contracting.

dennisgorelik 14y ago

Why do you even discuss technical side of bitcoin if you find the whole bitcoin business concept flawed?