<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>

CC BY-SA 3.0
2014-01-17T01:01:26.850Z
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](https://github.com/bitcoin/bitcoin/issues?labels=Bug&state=open) 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
CC BY-SA 3.0
2014-01-17T07:20:28.207Z
@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](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#Action_items) for example of how it was done in the past).
aland
CC BY-SA 3.0
2014-01-17T08:02:41.790Z
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
CC BY-SA 3.0
2014-01-16T06:21:24.997Z
2014-01-16T06:21:24.997Z
aland
<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>

CC BY-SA 3.0
2014-01-17T14:23:10.943Z
since you are a core dev I think this is the closest I will get to the list I was seeking. Thanks!
ktorn
CC BY-SA 3.0
2014-01-17T13:12:42.833Z
2014-01-17T13:12:42.833Z
Pieter Wuille
<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>

<bitcoind><client><bitcoin-core>
Satoshi's bitcoind implementation bugs
ktorn
# Satoshi's bitcoind implementation bugs

(Asked by: username_0 on 2014-01-16)

I have seen referred in a couple of locations ([bitcd](https://github.com/bitwisebank/btcd) and [bitcoinj](https://code.google.com/p/bitcoinj/wiki/FullVerification)) 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](https://en.bitcoin.it/wiki/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](https://github.com/bitwisebank/btcd) :

> 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](https://code.google.com/p/bitcoinj/wiki/FullVerification):

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

**Tags:** bitcoind, client, bitcoin-core


---

## 2 answers

### Answer by username_2 on 2014-01-17. Score: 9 | Accepted answer

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.

> **Comments:**
> **username_0**: since you are a core dev I think this is the closest I will get to the list I was seeking. Thanks!  

---

### Answer by username_1 on 2014-01-16. Score: 2

One example of such bug lead to [chain fork in May 2013](http://bitcoin.org/en/alert/2013-03-11-chain-fork): newer clients (and miners) did support large blocks, while older ones did not (due to using other database engine). More technical details [here](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#Root_cause).

Another potential example is discussed [here](https://github.com/bitcoin/bitcoin/issues/2256): 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.

> **Comments:**
> **username_0**: 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](https://github.com/bitcoin/bitcoin/issues?labels=Bug&state=open) 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?  
> **username_1**: @username_0 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](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#Action_items) for example of how it was done in the past).  
> **username_0**: 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?  

---

