user8728: 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.


user2343: 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.

user208: 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.


8728: <p>I have seen referred in a couple of locations (<a href="https://github.com/bitwisebank/btcd">bitcd</a> and <a href="https://code.google.com/p/bitcoinj/wiki/FullVerification">bitcoinj</a>) that fully verifying clients should match the satoshi bitcoind client implementation, <strong>including its bugs</strong>, presumably to prevent splitting the blockchain.</p>

<p>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 <a href="https://en.bitcoin.it/wiki/Protocol_specification">Bitcoin Protocol Specification</a> doesn't seem to mention any.</p>

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

<p>Edit: The references that triggered my curiosity are the following (my emphasis):</p>

<p>From <a href="https://github.com/bitwisebank/btcd">bitcd</a> : </p>

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

<p>From <a href="https://code.google.com/p/bitcoinj/wiki/FullVerification">bitcoinj</a>: </p>

<blockquote>
  <p>To be safe, bitcoinj must match the behavior of Satoshis code exactly,
  <strong>including all the bugs</strong>. Any deviation at all can be potentially used
  to split the consensus.</p>
</blockquote>
 2343: <p>One example of such bug lead to <a href="http://bitcoin.org/en/alert/2013-03-11-chain-fork" rel="nofollow">chain fork in May 2013</a>: newer clients (and miners) did support large blocks, while older ones did not (due to using other database engine). More technical details <a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#Root_cause" rel="nofollow">here</a>.</p>

<p>Another potential example is discussed <a href="https://github.com/bitcoin/bitcoin/issues/2256" rel="nofollow">here</a>: 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.</p>
 208: <p>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.</p>

<ul>
<li>The genesis block's coinbase output cannot be spent.</li>
<li>The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY operations pop one element too much from the stack (requiring an extra dummy push in the redeem script).</li>
<li>The checksig operations in a coinbase's scriptSig count towards the sigop limit of a block, even though that script can never be executed.</li>
<li>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.</li>
</ul>
