<p>There are two Bitcoin softwares that should be differentiated: (i) the <strong>client</strong> software that everyone uses and (ii) the full Bitcoin <strong>node</strong> used by the miners.</p>

<p>With regards to implementations, there are a variety of different clients. Just look at MultiBit, Electrum, Armory, Hive etc. Many are implemented using different programming languages and libraries. For example MultiBit uses the bitcoinj library, while others use something else.</p>

<p>Then there's the <em>nodes</em> which is what the miners use. This is a vastly different scenario from the client software because essentially the only player in town is the official Bitcoin software, Bitcoin Core (also called bitcoind or Bitcoin-QT).</p>

<p>The important difference is that if there's a bug in a <em>client</em> implementation, this won't effect the integrity of the network. It might lose you some coins or do other weird things with your money, but the Bitcoin network will still function. However, if there's a bug in the software being used by the miners (bitcoind, a full-node) then funny and unpredictable things may happen, because they're the ones securing and reaching consensus over the state of the network.</p>

<p>This is why variety of implementations for nodes isn't that easy. Because even the slightest change of code could trigger unwanted behavior that could jeopardize the validity of the network, such as a fork in the block chain.</p>

<p><strong>EDIT</strong> I'd like to clarify that nodes aren't only used by miners. In fact anybody can run a full-node and this should be incentivized because, as Pieter in the comments said, it allows you to independently verify the validity of the network.</p>

CC BY-SA 3.0
2014-05-11T10:19:36.033Z
Please don't claim that only miners run nodes. The ability to be able to run a full node is the ability to independently verify that nobody is cheating on the network. It's essential for decentralization.
Pieter Wuille
CC BY-SA 3.0
2014-05-11T10:21:35.803Z
Hi Pieter, did I make that claim though? Certainly wasn't my intent. I will clarify with an edit thanks.
Luca Matteis
CC BY-SA 3.0
2014-05-11T09:47:31.723Z
2014-05-11T10:24:30.470Z
2014-05-11T10:24:30.470Z
Luca Matteis
<p>(disclaimer: I work on Bitcoin Core)</p>

<p>As Luca already mentioned, you have to distinguish wallet implementations and the fully verifying nodes on the network. </p>

<p>Because of how Satoshi wrote his code (a node and a wallet in the same program), the two are often confused, but this is considered a bad idea now. They can perfectly function independently. The reference client's wallet is only one of multiple wallets now, and certainly not the most used or in any privileged position.</p>

<p>When we're talking about validation on the network, things are more complex. Bitcoin is a consensus system, where every node in the network must be able to independently judge the validity of blocks, and come to the exact same conclusion as everyone else. If two nodes disagree about the validity of blocks, they will ignore the other (considering each other's blocks as attacks). If two groups of nodes with different rules both have mining power, a fork will appear, where both groups believe they're the only ones around. This is a disaster, as it means every coin that existed before the fork can be spent once on each side.</p>

<p>Thus, the actual rules of the network are those that full nodes implement. We can try do describe the behaviour, but can't prescribe it. If the rules would be written down in some unambiguous formal document, and a difference would be found between the rules and the implementation, we might say the implementation has a bug... but new nodes on the network would have to copy that bug nonetheless.</p>

<p>Unfortunately, reimplementing those rules is far from trivial. Many people who have tried doing so have actually discovered weirdnesses in what is considered valid by the reference client, and weren't previously known. For example, Bitcoin relies on OpenSSL for signature verification, and early versions just passed whatever was found in transactions to OpenSSL. Turns out that OpenSSL actually accepts incorrectly-encoded signatures to some degree. Without knowing it, several wallet implementation had appeared over time that created such signatures (they're accepted, they must be valid, right?). This means that any new fully validating node implementation must either use OpenSSL too, or mimick it exactly by accepting the exact same set of invalid encodings. There's been progress towards making these signatures invalid (since 0.8 they're not relayed anymore), but making them actually invalid will require a coordinated soft-fork of the consensus rules (EDIT: this has happened on july 4th 2015 with BIP66 being activated).</p>

<p>Examples such as that make me very uncertain about whether exact reimplementation is possible with the current state of the art. That's certainly partly due to implementation details in the reference client, but also because of how hard consensus systems are. There are unit tests for several parts of the logic, and a network interaction test that simulates several weird edge cases to see how a node responds, but they are far from complete (especially because maybe not all edge cases are even perfectly understood). Differences are unlikely to be things found through random testing.</p>

<p>In my opinion, we should aim at modularizing the reference client code, and abstracting the consensus-critical part out into a library, so that it can be reused by several clients without these risks. That will inevitably take time, though.</p>

CC BY-SA 3.0
2014-05-11T15:15:58.370Z
Thanks Pieter.  I probably should have known that from one of the bitcoin Zurich meetups!
Winslow Strong
CC BY-SA 3.0
2014-05-22T16:26:01.270Z
@Pieter, I am aware that there are a variety of *client* softwares, but Do you mean that there's only *one* node software used in the wild? And all of the big companies (that do broadcasting) use this *one* node software instead of writing their own?
Pacerier
CC BY-SA 4.0
2021-05-12T02:05:20.253Z
Pieter, I wonder if this answer would be different if it was written today, (exactly) 7 years later?  Has bitcoin core modularization progressed or some other factor been discovered (or allieviated)?
davidbak
CC BY-SA 3.0
2014-05-11T10:53:42.350Z
2015-11-28T17:36:29.400Z
2015-11-28T17:36:29.400Z
Pieter Wuille
<p>The "reference client" bitcoin-qt receives a lot of complaints from developers on the messy way it was coded.  It seems to require a big overhead to learn, and a lot of time is being spent on modularizing it.  Yet we have other implementations (bitcoinj, libbitcoin, etc)  that are already modular, and coded in a much clearer way.  Considering these facts, why wouldn't the developers switch their active development to one of these codebases?</p>

<bitcoin-core><client><development>
Why don't developers switch from bitcoin-qt to a cleaner implementation?
Winslow Strong
# Why don't developers switch from bitcoin-qt to a cleaner implementation?

(Asked by: username_0 on 2014-05-11)

The "reference client" bitcoin-qt receives a lot of complaints from developers on the messy way it was coded. It seems to require a big overhead to learn, and a lot of time is being spent on modularizing it. Yet we have other implementations (bitcoinj, libbitcoin, etc) that are already modular, and coded in a much clearer way. Considering these facts, why wouldn't the developers switch their active development to one of these codebases?

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


---

## 2 answers

### Answer by username_2 on 2014-05-11. Score: 14 | Accepted answer

(disclaimer: I work on Bitcoin Core)

As username_1 already mentioned, you have to distinguish wallet implementations and the fully verifying nodes on the network.

Because of how Satoshi wrote his code (a node and a wallet in the same program), the two are often confused, but this is considered a bad idea now. They can perfectly function independently. The reference client's wallet is only one of multiple wallets now, and certainly not the most used or in any privileged position.

When we're talking about validation on the network, things are more complex. Bitcoin is a consensus system, where every node in the network must be able to independently judge the validity of blocks, and come to the exact same conclusion as everyone else. If two nodes disagree about the validity of blocks, they will ignore the other (considering each other's blocks as attacks). If two groups of nodes with different rules both have mining power, a fork will appear, where both groups believe they're the only ones around. This is a disaster, as it means every coin that existed before the fork can be spent once on each side.

Thus, the actual rules of the network are those that full nodes implement. We can try do describe the behaviour, but can't prescribe it. If the rules would be written down in some unambiguous formal document, and a difference would be found between the rules and the implementation, we might say the implementation has a bug... but new nodes on the network would have to copy that bug nonetheless.

Unfortunately, reimplementing those rules is far from trivial. Many people who have tried doing so have actually discovered weirdnesses in what is considered valid by the reference client, and weren't previously known. For example, Bitcoin relies on OpenSSL for signature verification, and early versions just passed whatever was found in transactions to OpenSSL. Turns out that OpenSSL actually accepts incorrectly-encoded signatures to some degree. Without knowing it, several wallet implementation had appeared over time that created such signatures (they're accepted, they must be valid, right?). This means that any new fully validating node implementation must either use OpenSSL too, or mimick it exactly by accepting the exact same set of invalid encodings. There's been progress towards making these signatures invalid (since 0.8 they're not relayed anymore), but making them actually invalid will require a coordinated soft-fork of the consensus rules (EDIT: this has happened on july 4th 2015 with BIP66 being activated).

Examples such as that make me very uncertain about whether exact reimplementation is possible with the current state of the art. That's certainly partly due to implementation details in the reference client, but also because of how hard consensus systems are. There are unit tests for several parts of the logic, and a network interaction test that simulates several weird edge cases to see how a node responds, but they are far from complete (especially because maybe not all edge cases are even perfectly understood). Differences are unlikely to be things found through random testing.

In my opinion, we should aim at modularizing the reference client code, and abstracting the consensus-critical part out into a library, so that it can be reused by several clients without these risks. That will inevitably take time, though.

> **Comments:**
> **username_0**: Thanks username_2.  I probably should have known that from one of the bitcoin Zurich meetups!  
> **username_3**: @username_2, I am aware that there are a variety of *client* softwares, but Do you mean that there's only *one* node software used in the wild? And all of the big companies (that do broadcasting) use this *one* node software instead of writing their own?  
> **username_4**: username_2, I wonder if this answer would be different if it was written today, (exactly) 7 years later?  Has bitcoin core modularization progressed or some other factor been discovered (or allieviated)?  

---

### Answer by username_1 on 2014-05-11. Score: 8

There are two Bitcoin softwares that should be differentiated: (i) the **client** software that everyone uses and (ii) the full Bitcoin **node** used by the miners.

With regards to implementations, there are a variety of different clients. Just look at MultiBit, Electrum, Armory, Hive etc. Many are implemented using different programming languages and libraries. For example MultiBit uses the bitcoinj library, while others use something else.

Then there's the *nodes* which is what the miners use. This is a vastly different scenario from the client software because essentially the only player in town is the official Bitcoin software, Bitcoin Core (also called bitcoind or Bitcoin-QT).

The important difference is that if there's a bug in a *client* implementation, this won't effect the integrity of the network. It might lose you some coins or do other weird things with your money, but the Bitcoin network will still function. However, if there's a bug in the software being used by the miners (bitcoind, a full-node) then funny and unpredictable things may happen, because they're the ones securing and reaching consensus over the state of the network.

This is why variety of implementations for nodes isn't that easy. Because even the slightest change of code could trigger unwanted behavior that could jeopardize the validity of the network, such as a fork in the block chain.

**EDIT** I'd like to clarify that nodes aren't only used by miners. In fact anybody can run a full-node and this should be incentivized because, as username_2 in the comments said, it allows you to independently verify the validity of the network.

> **Comments:**
> **username_2**: Please don't claim that only miners run nodes. The ability to be able to run a full node is the ability to independently verify that nobody is cheating on the network. It's essential for decentralization.  
> **username_1**: Hi username_2, did I make that claim though? Certainly wasn't my intent. I will clarify with an edit thanks.  

---

