9

I have seen referred in a couple of locations (bitcd and bitcoinj) that fully verifying clients should match the satoshi bitcoind client implementation, including its bugs, presumably to prevent splitting the blockchain.

I guess the bugs that need replicating are in the block acceptance rules, however I failed to find any specific references to the issues in question. The main Bitcoin Protocol Specification doesn't seem to mention any.

Can someone please explain (or link to a document that explains) these bugs?

Edit: The references that triggered my curiosity are the following (my emphasis):

From bitcd :

It currently properly downloads, validates, and serves the block chain using the exact rules (including bugs) for block acceptance as the reference implementation (bitcoind).

From bitcoinj:

To be safe, bitcoinj must match the behavior of Satoshis code exactly, including all the bugs. Any deviation at all can be potentially used to split the consensus.

Improve this question

2 Answers 2

Reset to default
9

I'll try to give a list of the cases I know of. Whether these are considered bugs or implementation oddnesses is debatable, I guess.

  • The genesis block's coinbase output cannot be spent.
  • The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY operations pop one element too much from the stack (requiring an extra dummy push in the redeem script).
  • The checksig operations in a coinbase's scriptSig count towards the sigop limit of a block, even though that script can never be executed.
  • Encoded public keys and signatures are valid if and only if OpenSSL accepts them, including the many non-standard or simply broken encodings it accepts. Since 0.8, such non-canonical encodings are considered non-standard, but still valid inside blocks.
Improve this answer
1
  • since you are a core dev I think this is the closest I will get to the list I was seeking. Thanks!
    – ktorn
    Commented Jan 17, 2014 at 14:23
2

One example of such bug lead to chain fork in May 2013: newer clients (and miners) did support large blocks, while older ones did not (due to using other database engine). More technical details here.

Another potential example is discussed here: certain types of transactions take a very long time to be verified by standard client. Including such transaction in block will delay its validation and there's a chance someone will probably mine a "better" block and the slow one will be orphaned. However, it might lead to chain fork if significant portion of miners use faster verification code.

Improve this answer
3
  • I'm really looking for a full list of "well-known" bugs that new fully verifying client implementations should adhere to in order to prevent such chain forks. I suppose the bitcoind's issue list in github may be the closest we can get to such an authoritative reference, and one just has to dig through all the bugs to identify those of importance to block acceptance. Isn't there anything else out there?
    – ktorn
    Commented Jan 17, 2014 at 1:01
  • @ktorn IMHO, the second example I mentioned fits your description, though it's not so much of a "bug" but rather "implementation detail", but it can lead to chain fork if other popular client implements that check faster. I really doubt there are known discrepancies between code and specs, since a) standard client is heavily tested, b) if such deviation would be found, dev team is likely to carefully fix it (see postmortem of May2013 chain fork for example of how it was done in the past).
    – aland
    Commented Jan 17, 2014 at 7:20
  • Sure the bug that you pointed out certainly applies to the "chain splitting" category, however the references that I just added to the question (see my edit) imply that there are other well-known and unaddressed issues that all fully verifying nodes must comply with. Perhaps the authority "document" in this regard is the reference test suite?
    – ktorn
    Commented Jan 17, 2014 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.