5 ms·

Being uncomfortable about alternate implementations makes me uncomfortable.

nwh 13y ago
It's a system completely designed around gaining a consensus. Any slightly differentiation in behaviour means a fork in the chain with catastrophic network-wide consequences. Both the original creator and the current developers are typically against re-implementations, with good reason.
- makomk 13y ago
  The trouble is, because the exact behaviour isn't documented and depends on subtle implementation quirks, the original implementation already has enough differences in behaviour between different versions to fork the chain with catastrophic network-wide consequences.
  - nwh 13y ago
    Exactly. In the case of the most recent fork, it was a completely unexpected implementation bug that meant that the underlying database ran out of locks, different to the more recent builds that didn't. That was caused just by differences in underlying databases, let alone a whole new verification system as we see here.
    - ErsatzVerkehr 13y ago
      Obviously this is not a desirable property of the system. If it's going to be robust against malicious attacks, it must be robust against well-meaning reimplementations.
      - betterunix 13y ago
        What does it even mean for Bitcoin to be robust against malicious attacks? Bitcoin has no security definition, just a vague notion of what its users should not be able to do.
      - nullc 13y ago
        Malicious attacks are not the same as consensus failure. Consensus requires agreement, malicious attacks are orthogonal, unless you're hypothesizing a malicious party introducing an intentionally incompatible node and a significant fraction of users switching to it.
- VMG 13y ago
  Both implementations should run in parallel, differences in behavior will show bugs in either implementation.
  - gcb1 13y ago
    you can detect bugs with one running alone as well. but so what. if i run one without the bug and accept a payment, you and millions with the bug will just say "meh. this one does not match. will just drop it" and my transaction goes out of the main block.
    - VMG 13y ago
      Some poorly-defined edge cases can only be found with alternative implementations. These are the edge cases that will cause trouble in a network with only one implementation.
- javert 13y ago
  > Both the original creator and the current developers are typically against re-implementations, with good reason. That is not true. Gavin Andressen supports alternate implementations. Take the following quote [1]: "Diversity is a good thing. Diverse, inter-operating implementations of the Bitcoin protocol make the network more robust against software bugs, denial-of-service attacks, and vulnerabilities. There are several projects re-implementing Bitcoin; if you are a Java or Go or Python or C programmer who wants to see Bitcoin succeed, you should consider helping them out by reviewing, testing, or contributing patches." He then goes on to list several alternatives, including btcd. [1] https://bitcoinfoundation.org/blog/?p=204 https://bitcoinfoundation.org/blog/?p=204
  - nwh 13y ago
    Alright, it's at odds with the developers I've spoken to about it. GMaxwell cautions most developers when they attempt it, for example.
- jedunnigan 13y ago
  Yea, this is one of those things where that argument gets tricky. On the flip side one could argue that diversification of implementations is key to the long-term success of Bitcoin. If, let's say, there is a serious issue with bitcoind that shows up somewhere down the road that causes a fork and it is the only implementation everyone is using, there will be a network-wide problem. If there are a number of implementations in the wild, the fork would be contained to a smaller subset of users, and managed accordingly. Getting to this point of diversification safely is difficult, however, which is why I imagine some of the core devs might be against it. I remember Amir Taaki got a lot of flack when he came out with libbitcoin.

nwh 13y ago

It's a system completely designed around gaining a consensus. Any slightly differentiation in behaviour means a fork in the chain with catastrophic network-wide consequences. Both the original creator and the current developers are typically against re-implementations, with good reason.

makomk 13y ago
The trouble is, because the exact behaviour isn't documented and depends on subtle implementation quirks, the original implementation already has enough differences in behaviour between different versions to fork the chain with catastrophic network-wide consequences.
- nwh 13y ago
  Exactly. In the case of the most recent fork, it was a completely unexpected implementation bug that meant that the underlying database ran out of locks, different to the more recent builds that didn't. That was caused just by differences in underlying databases, let alone a whole new verification system as we see here.
  - ErsatzVerkehr 13y ago
    Obviously this is not a desirable property of the system. If it's going to be robust against malicious attacks, it must be robust against well-meaning reimplementations.
    - betterunix 13y ago
      What does it even mean for Bitcoin to be robust against malicious attacks? Bitcoin has no security definition, just a vague notion of what its users should not be able to do.
    - nullc 13y ago
      Malicious attacks are not the same as consensus failure. Consensus requires agreement, malicious attacks are orthogonal, unless you're hypothesizing a malicious party introducing an intentionally incompatible node and a significant fraction of users switching to it.
VMG 13y ago
Both implementations should run in parallel, differences in behavior will show bugs in either implementation.
- gcb1 13y ago
  you can detect bugs with one running alone as well. but so what. if i run one without the bug and accept a payment, you and millions with the bug will just say "meh. this one does not match. will just drop it" and my transaction goes out of the main block.
  - VMG 13y ago
    Some poorly-defined edge cases can only be found with alternative implementations. These are the edge cases that will cause trouble in a network with only one implementation.
javert 13y ago
> Both the original creator and the current developers are typically against re-implementations, with good reason. That is not true. Gavin Andressen supports alternate implementations. Take the following quote [1]: "Diversity is a good thing. Diverse, inter-operating implementations of the Bitcoin protocol make the network more robust against software bugs, denial-of-service attacks, and vulnerabilities. There are several projects re-implementing Bitcoin; if you are a Java or Go or Python or C programmer who wants to see Bitcoin succeed, you should consider helping them out by reviewing, testing, or contributing patches." He then goes on to list several alternatives, including btcd. [1] https://bitcoinfoundation.org/blog/?p=204 https://bitcoinfoundation.org/blog/?p=204
- nwh 13y ago
  Alright, it's at odds with the developers I've spoken to about it. GMaxwell cautions most developers when they attempt it, for example.
jedunnigan 13y ago
Yea, this is one of those things where that argument gets tricky. On the flip side one could argue that diversification of implementations is key to the long-term success of Bitcoin. If, let's say, there is a serious issue with bitcoind that shows up somewhere down the road that causes a fork and it is the only implementation everyone is using, there will be a network-wide problem. If there are a number of implementations in the wild, the fork would be contained to a smaller subset of users, and managed accordingly. Getting to this point of diversification safely is difficult, however, which is why I imagine some of the core devs might be against it. I remember Amir Taaki got a lot of flack when he came out with libbitcoin.