Forking bitcoind (Bitcoin Core daemon)

Forking an existing codebase like that of Bitcoin’s may be the simplest option at the outset, but it has many drawbacks that are guaranteed to make your developer tear their hairs out maintaining your forked codebase.

Drawbacks

Technical debt . Bitcoin Core developers make bug fixes, patches, and upgrades via bandages, leading to legacy code riddled with technical debt. Navigating this terrain can take as much effort as writing your codebase from scratch.

. Bitcoin Core developers make bug fixes, patches, and upgrades via bandages, leading to legacy code riddled with technical debt. Navigating this terrain can take as much effort as writing your codebase from scratch. Unmaintainable codebase. Bitcoind is still in the midst of a substantial refactor and cleanup of the initial somewhat deficient codebase.

This results in frequent large changes that touch many parts of the codebase and puts substantial pressure on downstream maintainers. It takes a substantial effort for even seasoned C++ developers to familiarize themselves with the Bitcoin reference client written in C++.

Shortlist of Properties

UTXOs . The Unspent Transaction Output (UTXO) model is optimized for transaction validation in Bitcoin and is particularly specialized for payments. The innovation behind this model introduced the commutativity of transactions; the order of transactions is insignificant. This helps with better user experience under reorganizations (a consequence of Bitcoin’s decentralized nature) but is not an ideal model in other contexts. UTXOs allow you to do more parallel smart contract evaluation/verification. As such, it is only appropriate to model your application after this if you explicitly intend to. In addition, it is easier to apply privacy features like confidential transactions and a zero-knowledge protocol under a UTXO model. Cosmos and Ethereum are account-based systems.

. The Unspent Transaction Output (UTXO) model is optimized for transaction validation in Bitcoin and is particularly specialized for payments. The innovation behind this model introduced the commutativity of transactions; the order of transactions is insignificant. This helps with better user experience under reorganizations (a consequence of Bitcoin’s decentralized nature) but is not an ideal model in other contexts. UTXOs allow you to do more parallel smart contract evaluation/verification. As such, it is only appropriate to model your application after this if you explicitly intend to. In addition, it is easier to apply privacy features like confidential transactions and a zero-knowledge protocol under a UTXO model. Cosmos and Ethereum are account-based systems. Proof-of-Work. Bitcoin is deeply embedded in Proof-of-Work. Again, it is only appropriate to mirror the security model of your application after Bitcoin’s if you explicitly intend to. In a permissioned setting, Proof-of-Work (PoW) carries substantially greater overhead than security models such as Proof-of-Authority (PoA) or Proof-of-Stake (PoS). Tendermint BFT has been and continues to be stress-tested in enterprise today.

Alternative Bitcoin Implementations

The two alternative implementations of the Bitcoin reference client that have mined blocks on the live network are:

If you want to build your own application from an alternative implementation like btcd or bcoin, the same drawbacks hold. Changing an existing stack to meet your specific user requirements is significantly harder than starting from a solid base layer framework.

Case Study—Zcash

Zcash in 2016 forked bitcoind to become its own altchain (alternative chain forked from Bitcoin). It had all the bugs of bitcoind, but unfortunately, upstream fixes from Bitcoin Core were difficult to maintain in Zcash. Since the forked codebase had been changed with all the privacy enhancements and other features, upstream changes weren’t able to be merged. The Zcash team has occasionally voiced regret for the challenges posed as a fork of bitcoind.