Five Technical Takeaways From The Bitcoin Bug

It’s been more than a week since the initial disclosure of CVE-2018-17144. In that time, more details have been filled in, including the fact that the bug could not only crash clients, it could also create inflation— and that the bug was discovered and responsibly reported by a developer working on the “Unlimited” Bitcoin Cash client.

There has also been much discussion in the crypto world about the nature of this bug and what lessons we should takeaway from it. This article will detail my biggest takeaways, looking at it primarily from a technical perspective.

#1 The risk of a critical software flaw disrupting Bitcoin, or another major crypto network, is still under-appreciated.

At the beginning of August, it was revealed that Bitcoin Core developer Corey Fields had discovered and disclosed a chain split but in Bitcoin Cash. In his write up detailing that incident, Corey had this to say:

Working through this bug, which certainly had the potential for catastrophe, has reaffirmed my belief that the threat of software bugs is severely underestimated in the cryptocurrency world. I’m presenting a detailed report of this incident… as a wake-up call to companies who have not adequately prepared for this type of scenario.

This seems especially prescient in light of this latest vulnerability, and I fear many people are still failing to account for the risk. I’ve seen many folks on Twitter say things like “bugs can always be fixed” or “whats the big deal— it wasn’t even exploited.” We should make no mistake: Bitcoin dodged a bullet.

#2 Bitcoin development is under-provisioned given the enormity of what is now at stake.

A couple of months ago, Naval Ravikant set off an uproar amongst Bitcoiners for saying that incentives for Bitcoin developers are out of whack. Rather than discussing a very good point, most seized on the use of the economic term “free-rider” to imply, incorrectly, that Naval was criticizing all Bitcoin “hodlers”.

When some in the community did get around to addressing Naval’s actual point, most insisted that Bitcoin did not have a developer problem, that the contributions of passionate experts are sufficient, and that no conversation around how to fund additional eyes on the code was needed. I tweeted about this earlier in the week.


The commit that introduced this vulnerability was made by a single developer and merged after a cursory review by only one other. This, despite the fact the change was to a critical section of the code dealing with transaction validation. It subsequently remained in the code for a eighteen months before being discovered by someone working for a different project.

For a project with a $100 Billion market cap, which aims to make itself a store of value for people’s wealth, and on which many of us are resting our hopes for a more decentralized monetary future, this is simply unacceptable. I’m not saying I have the answers for how to solve this problem, but we damn well better acknowledge there is a problem, here!

#3 It’s totally unclear whether having only one widely used implementation of Bitcoin is a good idea.

Bitcoin Core is far and away the most widely used client software on the Bitcoin network, with over 95% of all nodes running it. Other networks have much more diverse topologies, such as Ethereum, which has multiple widely used clients built in different languages and by different teams.

There is a downside to heterogeneous networks, most critically that a consensus difference between two or more clients could lead to a chain split. This vulnerability lends credence to those who argue the benefits to multiple clients is worth this risk.


Had the bug been exploited, virtually all clients on the Bitcoin network would have been affected. Only those still running very outdated versions of the software would have been safe. A heterogeneous network would be more robust to these sorts of vulnerabilities, and arguably might result in their discovery sooner as well.

#4 Mining is (still) centralized, and mining pool operators have an outsized impact on consensus.

There’s no real new information here, just a dramatic demonstration of the reality. When this bug was discovered, the Bitcoin Core developers reached out to the operators of a handful of mining pools. Once some were patched, it was “safe” to reveal the full nature of the bug, despite the fact that 85% full nodes (like my own!) had not yet been patched.


Bitcoin hashrate distribution via


Running a full node is still a good idea for one’s own security— you don’t have to trust anyone to carry out transactions. And it does impute some measure of greater decentralization to have more full nodes in operation. At the end of the day, though, those in control of the hash rate have an outsized control on consensus, and at the moment, that means just a handful of pool operators.

Something that should create some cognitive dissonance for those of us who care about decentralization: the fact the hash rate is relatively centralized actually made patching this issue easier.

#5 If/when a sophisticated nationstate decides to attack cryptocurrencies, things will get ugly, fast.

What are the odds that someone inside a government agency, be it the NSA, or an equivalent agency in China or Russia, knew about this vulnerability before it was discovered and patched? I’d say they’re relatively high. If I headed up one of those agencies, I would certainly have a team reviewing the code of Bitcoin and other major cryptocurrencies, looking for exactly these types of weaknesses.

Why? Because that would be my job! Bitcoin, and other networks, have become too important on the international stage not to warrant attention from such agencies. And make no mistake, while these agencies are bureaucratic, they still employ and provide resources to brilliant people who, working in small teams, can accomplish incredible feats.

If, or more likely, when a major nationstate decides to become hostile to crypto, things could get…messy

A Developer's Guide To Running A Bitcoin Full Node And Local Block Explorer

The goal of this guide is set up a Bitcoin Node that is useful for tinkering with as a developer. If you complete this guide successfully, you'll have a node that is in sync with the network, contains the full history of the Bitcoin blockchain, and is fully validating all transactions.

Obligatory Image Evoking the idea of networked nodes

Obligatory Image Evoking the idea of networked nodes


You'll also be able to communicate with your node via simple JSON-RPC calls. This means you can interact with the Bitcoin Network at large without relying on any trusted third party. As a simple example of what can be done with this, we'll run an open source block-explorer, providing you with a trustless interface to view activity on the network.


Because this guide is for developers, it assumes you're comfortable doing developery things, such as running Linux, using bash, and executing Python scripts. We will not utilize the Bitcoin QT GUI to set up our wallet-- in fact none of the steps in this guide will assume a GUI at all.

Where more in-depth usage of some other tech is an out of scope pre-requisite, I'll provide links to useful guides as appropriate for those portions. If you're looking to run a full node as a standard user, check out the guide on

There are a few hardware and software requirements, as enumerated below:

  • A modestly spec'd computer with at least 2 GB of RAM (4+ suggested)
  • At least 150 GB of free disk space
  • A reasonably fast network connection without stringent bandwidth requirements
  • An installation of Ubuntu 18.04
    • If you're running this on your dev machine that already has macOS or Windows installed, you can do so in VM
    • Older versions of Ubuntu probably work fine as well, but weren't tested
    • Other variants of Linux should also work fine, but you'll have to install bitcoind and handle dependencies as appropriate for your distro (more below)

I run my node with fast residential broadband on a 6 year old desktop PC. It has an Athlon FX processor, 4 GB of RAM, and slow 250 GB spinning disk. It runs like champ! The Bitcoin Core team's focus on making it possible for anyone to run a node truly has paid off.

Installing bitcoind

The Bitcoin network follows a protocol for communication and consensus. While several clients for this protocol exist, the "canonical" and most widely used version is referred to as Bitcoin Core.

To install Bitcoin Core on Ubuntu, you have a few choices:

  1. Clone the repository from GitHub and build from source
  2. Download and install official pre-compiled binaries
  3. Installing the binaries via apt from the Bitcoin Personal Package Archive (PPA)

Each method has its tradeoffs. In this guide, we'll opt for using apt and the PPA, because it's the simplest and easiest way, and makes upgrading to new versions of the software easy as well. One downside is it requires trusting the software that comes from the PPA which could, for example, be compromised by an attacker. Please evaluate these tradeoffs yourself and choose the method thats best for you.

If you're just using your node for development and tinkering and want to proceed with option #3, simply run the following commands and follow the associated prompts:

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

When these commands are complete successfully, run bitcoind -version. You should see some output showing the version of the bitcoind software you're using.

Initial Block Download

You've now got the latest software needed to run a node, but you're missing 10+ years of the network's history. Remember, this is a full node! That means it stores and validates the full history of the blockchain, starting from the very first block mined by Satoshi himself. That history will need to be downloaded.

Unfortunately, this process takes a while and requires about 150 GB of disk space as of today. On my reasonably fast residential internet, I was able to download the full blockchain in about 4 days. Your mileage may vary based on your connection and geography.

Run the following command:

bitcoind -daemon -txindex=1

This runs the bitcoind process in the background with transaction indexing on. You may also want to start this process automatically on every reboot as well. You can do this by running: crontab -e and adding the following line:

@reboot bitcoind -daemon

Note that we didn't add the txindex option to the crontab. Later in this guide we'll put this option in a config file instead, which is a better way to set options for your node.

When the node software starts for the first time, it creates ~/.bitcoin/. Let's navigate there now and poke around:

cd ~/.bitcoin/

You'll notice a number of files and directories have been created. We'll examine just a few of these now. First, run tail -f debug.log. You'll notice a series of log messages that look something like this:

2018-08-10 17:22:15 UpdateTip: new best=00000000000000000011b735b8fde14db39704c446dd2b1ae4b8db198c255e0d
height=536128 version=0x20000000 log2_work=89.424049 tx=333938835
date='2018-08-10 17:22:26' progress=1.000000 cache=71.6MiB(529075txo)

(When the node first begins syncing, these may be flying by pretty fast. Hit Ctrl-C to quit tailing the file and examine the messages).

These messages represent blocks being downloaded from the network. The one shown here represents the latest block mined at the time I'm writing this tutorial, but you'll be well behind this. You'll note each message shows a number of parameters, including the hash of the block (best=X), the block height (height=X), and a timestamp of when this block was mined (date=X).

To monitor the progress of the initial download, you can tail this file and look at the historical date you've caught up to. Note that, since most blocks early in the network's history were mostly empty, early blocks will download fast. As you get further along, download times will increase. My node spent a majority of the time downloading blocks from 2017 onwards.

You can also interact with the blockchain using the bitcoin-cli command line interface. For example, you can run bitcoin-cli stop to safely shutdown your node, or run bitcoin-cli -getinfo to get a summary of your node's status:

  "version": 160000,
  "protocolversion": 70015,
  "walletversion": 159900,
  "balance": 0.00000000,
  "blocks": 536128,
  "timeoffset": 0,
  "connections": 33,
  "proxy": "",
  "difficulty": 5949437371609.53,
  "testnet": false,
  "keypoololdest": 1531965982,
  "keypoolsize": 1000,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "warnings": ""

One more small piece of fun. The block data that your node is downloading is stored in binary files in the ~/.bitcoin/blocks/ directory. You won't normally interact with this data directly, but try running this quick command:

head -c 210 ~/.bitcoin/blocks/blk00000.dat && echo '\n'`.

You'll see something like this:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks��

Do you recognize that sentence? If you do, it might send chills down your spine to see it on your machine! If you don't, go Google it and learn why it should.

As mentioned, initial block download is going to take at least a few days. During this phase, the daemon may use a lot of resources. Mine pegged my processor at a consistent 20-30%, utilized over 2 gigs of RAM, and generally made my admittedly old machine slow. Once you're caught up, running the node software has a negligible effect on performance with even a modest machine.

If you've made it this far, bookmark the page and come back in a few days when your node is in sync!

Server Configuration

Welcome back! It's time to configure your node to act as a JSON-RPC server, so we can run and write code in our favorite language to interact with it.

Navigate back to the bitcoin directory and create a flat-text file called bitcoin.conf.

cd ~/.bitcoin/
touch bitcoin.conf

Henceforth, this file will be read when bitcoind starts and will be used to configure options for your node. There are a number of options you can set, and each of these can also be set at command line as well. To get a sense of the options available to you, run:

bitcoind --help

Open up the bitcoin.conf file in your favorite text editor and add the following lines:

## Configuration for the Bitcoin Core Daemon

# Accept command line and JSON-RPC commands

This is a good start, but not sufficient to enable RPC interaction with our node. To do so, we also have to create authentication credentials for the user who will log in.

It used to possible to specify a username and password in flat text in the config file, but this method is clearly insecure and has been deprecated. Instead, we have to provide the username along with the hash value of the password-- in conjunction with a salt used during hashing.

To generate this, use the following commands to download the canonical Python script provided by the Bitcoin Core team and run it with your own username and password.

python3 myusername mysecretpassword

Be sure to replace the username and password values with something sane! The script should produce a result like this:

String to be appended to bitcoin.conf:
Your password:

As instructed, add this line to your bitcoin.conf file, which should now look something like this:

## Configuration for the Bitcoin Core Daemon

# Accept command line and JSON-RPC commands

# Index all transactions

# Auth Credentials For JSON-RPC server

Next, restart your node to make sure the configuration changes take effect:

bitcoin-cli stop
bitcoind -daemon

At this point, you're ready to make JSON-RPC requests to your node, as long as they're coming from the node itself. To test this out, try running the following command (note: you may have to install curl first via apt).

curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;'

Be sure to replace myusername with username you actually created. You'll be prompted for the associated password, and if all worked properly, you should see something like the following:

    "result": {
        "chain": "main",
        "blocks": 536148,
        "headers": 536148,
        "bestblockhash": "00000000000000000028fab7a6b5035e2745fe06ef58d817bb32f35924198f97",
        "difficulty": 5949437371609.53,
        "mediantime": 1533926692,
        "verificationprogress": 0.9999864596463776,
        "initialblockdownload": false,
        "chainwork": "000000000000000000000000000000000000000002af5dee686cd058c3ec064d",
        "size_on_disk": 203955272825,
        "pruned": false,
        "softforks": ["..."],
        "bip9_softforks": { "..." : "" },
        "warnings": ""
    "error": null,
    "id": "curltest"

If this works, you're ready to start using your full node for building/running an app that interacts with it. To learn more about the full set of API calls available, and various libraries that exist that wrap the API, checkout this reference on

IP Whitelisting

By default, your node is configured to only accept JSON-RPC requests from localhost, i.e. the machine where it runs. This is fine if you'll be developing on the same box the node is on, and you can skip this section.

If you're developing from a different machine, like a Windows or macOS computer, you'll have to use the rpcallowip option to whitelist IP addresses which are allowed to make calls, and also ensure port 8332 is reachable. (Note that a VM, though running on the same hardware, does in fact have a unique IP).

My local development machine runs macOS, so I can use the ifconfig to determine my local ip, then whitelist it by adding something like rpcallowip= to my config file. Note that you can include this option more than once to whitelist multiple IP addresses.

The specifics of finding your development machine's IP and making port 8332 available on your node are dependent on your platform and network. These are left as an exercise to the reader. Here's an example of what your final bitcoin.conf might look like.

#### Configuration for the Bitcoin Core Daemon

# Keep my daily upload bandwith around 1 GB

maxuploadtarget=1024  # Note that if your node isn't exposed to the internet on
                      # Port 8333, you're not feeding data to other nodes and this
                      # setting won't matter.
                      # While not required, if you'd like to support the network
                      # by servering data, make sure your router is configured to
                      # forward port 8333 to the machine with your.

# Accept command line and JSON-RPC commands

# Index all transactions

# Auth Credentials For JSON-RPC

# Whitelist only my Mac's local IP for JSON-RPC calls

Running A Block Explorer

With your full node up and running, synced to the network, and configured for use as JSON-RPC server, it's time to run your own local blockchain explorer! We'll use the open source btc-rpc-explorer, created by Dan Janosik.

This explorer is great because it doesn't use a database-- it just needs access to your node, which it interacts with via the RPC interface we just configured.

btc-rpc-explorer is written in JavaScript using Node.js, so you'll need to have the latest stable version of node and npm installed. If you don't already have these, checkout the instructions for your development platform of choice.

Once Node and npm are ready to go, clone the repo from GitHub and build it with the following commands (which assume a Unix dev environment):

git clone
cd btc-rpc-explorer
npm install
npm run

Next, open the app/credentials.js file in your text editor of choice and update the username and password to the values you used during the RPC configuration.

If you're dev box is not the same as your node, you'll also have to update the host parameter to the IP address of your node. This will likely be a local area network IP, unless your node is hosted outside your LAN. (Note also that your router may assign either you development box or your node a new IP in the future. Look into configuring static local IPs based on MAC addresses in your router's config panel to solve this issue).

With the credentials updated, you're ready to run the explorer. Execute the following command, then visit in your browser of choice.

npm start

If all has gone well, you should see something like this:

locally sourced, organic block explorers

Congratulations, you now have your very own Bitcoin full node, and a locally sourced, organic block explorer to go with it 🎉. Happy hacking!

The Two Views Of Crypto: Sound Money Vs. Global Computer

Each of us has a unique personality and history that influences the way we perceive the world-- our own set of lenses through which we view reality.  It turns out, those lenses can result in dramatically different conceptions of the same phenomenon.

It will Shock some of you To Learn all three versions look 100% Gold & White to Me ¯\_(ツ)_/¯

It will Shock some of you To Learn all three versions look 100% Gold & White to Me ¯\_(ツ)_/¯


In the crypto world, amongst those who believe this technology to be lasting and important, there seem to be two dominant viewpoints. In this post, we'll elucidate these two lenses, explore what each perspective gets right and wrong, and seek to unify the two if possible.

A World Computer

Many people view blockchain networks as giant, decentralized, global computers. Henceforth, we'll call people who tend toward this perspective "Computerians". (It's a dumb name, but I really don't want to type "people who have this perspective" over and over, so let's go with it).

A blockchain computer is everywhere and nowhere. Code IS run and State is Replicated across Thousands of Nodes

A blockchain computer is everywhere and nowhere. Code IS run and State is Replicated across Thousands of Nodes


Computerians tend to be developers and software people. They recognize blockchains as a new place to run their code and store their data. Compared to traditional computers, blockchain computers are wildly inefficient, expensive, and hard to program safely.

Despite this, Computerians are excited to write software for these global computers, and believe this software will change the world. Thats because they recognize a host of new capabilities these computers bestow on software, namely:

  • Digital scarcity
  • Data storage that is immutable, auditable, and censorship resistant 
  • Code that is unchangeable once deployed (i.e. the ability to provide guarantees to users about how a system will behave)

To put it succinctly, Computerians believe software is eating the world-- blockchain computers enable them to write new kinds of software and thus devour parts of the world previously thought indigestible.

Sound Money

In contrast to the Computerians, there are a group of people who view blockchain as primarily a monetary innovation. For these folks, "blockchain" is an implementation detail. We'll call them the "Fiscalites."

Is Bitcoin a Better Gold Than Gold?

Is Bitcoin a Better Gold Than Gold?


Fiscalites are more likely to have a background in economics, finance, or political science. They understand that, historically, things that become money-- like shells or precious metals-- have had certain properties, such as:

  • Durability and secure-ability
  • Measurability and divisibility
  • Forgery resistance

Looking at cryptocurrencies, Fiscalites recognize them as a revolutionary new form of sound money. Fiscalites tend to be skeptical of fiat money, that is, money issued and controlled by a government. They view centrally controlled, inflationary monetary policy as dubious.

Concisely, Fiscalites see cryptocurrencies as an ascendant new form of global money and the antidote to the questionable modern experiment of fiat currency.

Each Side's View Of The Issues

Unsurprisingly, viewing the world through these different lenses leads to different conclusions regarding various matters. Let's examine how each side perceives:

  1. The concept of cryptocurrencies
  2. Altcoins and other tokens
  3. Scaling and network upgrades


It should be self evident that to a Fiscalite, cryptocurrency is the whole ball game. The underlying blockchain technology is an afterthought. It's the sound money it enables that matters.

A Computerian views cryptocurrencies as a fundamental component of blockchain computers, but not as their singular end. A network's currency underpins the incentive structure that allows it to function in a decentralized manner, and it enables powerful use cases in the form of programmable money. While Computerians recognize the importance of these functions, the currency doesn't conclusively define the utility of the network.

Altcoins and Tokens

Fiscalites tend to be Bitcoiners. Since Fiscalites are focused on sound money, they see the network effects of Bitcoin as unstoppable. The more people who store their wealth in Bitcoin, the more its value increases, and the more likely others are to use it to store their wealth.

To a Fiscalite, unless a large number of people are willing to store their wealth in a given coin or token, it's useless. Most believe only one asset can accrue such broad social trust. An open minded Fiscalite might be interested in altcoins that improve on the money-ness of cryptocurrencies, such Zcash and Monero, but thats about as far as it goes.

Fiscalites Put Bitcoin On A Pedestal.

Fiscalites Put Bitcoin On A Pedestal.


As engineering minded folks, Computerians are more open to new projects which experiment, add features, and explore the blockchain tradeoff-space. As such, many of them are excited about Ethereum, but not exclusively so. They're multicoiners.

Computerians can envision a world where multiple blockchain networks see mainstream adoption, and where technologies like decentralized exchanges and atomic swaps allow users and software to transact seamlessly between them. Many Computerians even envision a world where a multitude of tokens and assets are implemented in code on top of these networks, each providing some narrow utility or incentive structure.

Scaling and Network Upgrades

Fiscalites don't want to change the network. Period. If the network can be changed, then theoretically it could be censored, broken, or have its monetary policy altered. This would damage its social credibility as money. For Fiscalites, intractable governance deadlock is a feature, not a bug, and suggesting a change to the network for scaling purposes is like proposing we alter the atomic composition of gold to make it easier to carry around.

Fiscalites want to scale the network on the second layer-- i.e. by leaving the base protocol untouched, but building on top of it, even if that comes with some tradeoffs. A historical analog would be government issued gold notes. They made using "gold" easier, albeit with some tradeoff towards trust. This was acceptable as long as there was an easy way to opt out of that trust by exchanging notes for physical gold.


Gold Notes Could Be Redeemed For Gold On-Demand


Computerians see scaling as an engineering problem, and one that must be urgently solved. If blockchain networks are all about creating new kinds of software, then we need lots of people to be able to use that software. These networks need to scale. As such, Computerians don't take an either-or view of scaling when it comes to layer 1 vs. layer 2. Why not both?

Naturally, this means lots of changes to the network. "Fine, let's get to 'em," says the Computerian. Even changing the monetary policy is not off the table in service of making the global computer work better.

What Each View Offers The Other

As we've seen, Computerians and Fiscalites seem to disagree on quite a lot, despite both being bullish about the overall importance of crypto. The truth is, the two views are complimentary, and each is necessary to keep the other in check.

We are the proverbial blind men, each feeling a different part of the elephant while arguing over its nature. We ought to be triangulating our viewpoints.

The Blind Men and The Elephant, Via Wild Equus

My background lends me to a more Computerian disposition. I've come to realize there is much we should learn from our Fiscalite friends.

Computerians ought to take more seriously the history of money, and tread more carefully with regards to network changes as a result. The Ethereum DAO hardfork makes a good example of where this can go awry.

To an engineer, the hardfork felt like fixing a bug-- correcting a piece of software that had not behaved according to its design. In reality, the hardfork was a breach of social trust that damaged the credibility of the Ethereum's decentralized nature. For ETH to be money, this is unnaccetpable. Hopefully, history will view it as a one time event that is forgivable due to the network's nascency.

The Ethereum community also tends to have an unbridled optimism and confidence around fixing problems through engineering. This can be energizing, but it can also border on dangerous naiveté. The push towards Proof-of-Stake, for example, strikes me as more risky than the community admits.

Finally, while Computerians may always remain multicoiners at heart, they should probably recognize that at some point, consolidation to a small handful of networks is not only inevitable, it's desirable. We almost certainly don't need a token for every decentralized app under the sun.

For their part, I think Fiscalites could stand to learn a few things from Computerians as well.

For one, Fiscalites are painfully narrow-minded when it comes to anything other than sound money. In fact, this narrow-mindedness can turn to actual hostility towards those who suggest other use cases for decentralized networks. This is foolhardy, as these other use cases do not preclude cryptocurrency being used as sound money in any way.

Smart contracts are the most obvious example. Fiscalites downplay their importance or outright write them off, as Jimmy Song does in the piece linked below. But an army of tinkerers and builders are flocking to these platforms to see what they can create with the new capabilities they've been granted. Underestimate them at your own risk, but perhaps do a bit of research on the history of personal computers, open source, or the web before you do.


Finally, Fiscalites ought to at least consider the idea that multiple crypto-networks can coexist. Perhaps they'll be proven right in the long run and Bitcoin will dominate. Even if so, pretending to know right now, with certainty, that Bitcoin is the only coin that can possibly prosper is beyond presumptuous, it's preposterous. The world is simply too complex.

Can't We All Just Get Along?

If these two vantage points are to be reconciled, we must find common ground. The essential point of contact between the two ways of thinking is decentralization. Both sides deeply value the potential for crypto-networks to disintermediate entrenched central powers.

Fiscalites are focused on state-backed central banks who tinker with the economy through top down monetary policy. Computerians are concerned by the giant internet aggregators who increasingly control the web, wielding broad power to promote or censor what is seen. Both are rightly uneasy about deepening concentrations of power in the modern world. Both recognize the immense promise and importance of dispersing it.

This vision of a bottom-up, decentralized world, enabled by crypto-networks, is one worth fighting for. Hopefully, those who share it can be persuaded-- despite their distinct perspectives-- to work together to see it realized.

Note: Build Blockchain Tech may not hold rights to the images used in this post. In such cases, images are reproduced here under the doctrine of fair use.

Against Narrow Minded Maximalism

What is a Bitcoin Maximalist? Some insist the term is derogatory, akin to a slur. Others seem to own the term proudly. Whatever your opinion on the term itself, there is no doubt that within the blockchain/cryptocurreny world, there is a group of people who:

  1. Are singularly focused on the idea of creating "sound money" and believe Bitcoin does this in a superior way to all other cryptocurrency networks.
  2. Subsequently believe Bitcoin will dominate in the long run, and most/all other projects will die.

These are reasonable positions to hold. I am quite sympathetic to both of them. In my probabilistic view of the future of crypto, a non-negligible weight is assigned to the possibility that Bitcoin will become the dominant network by an order of magnitude or more.

There are, however, two corresponding traps that I see Bitcoin Maximalists fall into:

  1. The Either-Or Trap: Being so focused on creating sound money that one becomes actively hostile to other obviously valuable use cases.
  2. The Predestination Trap: Viewing Bitcoin's dominance as a fait accompli, and allowing no consideration for other outcomes.
Obligatory meme

Obligatory meme


Both of these stem from what can only be described as narrow-mindedness.

The Either-Or Trap

A great example of the first trap can be seen in Jimmy Song's blog post, "The Truth about Smart Contracts". In it, Song takes aim at Ethereum and argues:

"smart contracts are simply too easy to screw up, too difficult to secure, too hard to make trustless and have too many external dependencies to work for most things."

As a developer, it's hard for me to believe another technologist would downplay the incredible disruptive potential of smart contracts. Software is eating the world, and smart contracts allow us to do things with software that were previously unimaginable.

Are there issues to work through and best-practices yet to be developed? Sure. It's fair to point these issues out and Jimmy does a good job of covering some of them in his piece.

But we're talking about trust-minimized code manipulating immutable, auditable data code that can create, manage, and move a multitude of scarce digital assets. To dismiss the far reaching implications of that outright simply because the ecosystem is still in an embryonic state is preposterous. 

Jimmy is smart enough to know better, but his narrow-minded focus on cryptocurrency as sound money makes other use cases seem like a threat. If smart contracts will detract from sound money, then for maximalists, smart contracts must be bad. But the two are not in opposition. In fact, they're quite complimentary. Which would you rather have: sound money, or programmable sound money?

This same negative attitude is on display for other obviously disruptive use cases as well, such as tokenized securities.

Many maximalists, like Kevin Pham, dismiss tokenized securities as a purely sustaining technology. They're not. The ability to spin up tokenized equity and encode the ownership/distribution rules around that equity on a blockchain will likely be huge. It could change the way companies are formed and how capital is raised. It could enable a new wave of global entrepreneurship.

The point here is not to downplay the importance of sound money.  Rather, it's to recognize that we don't have to choose between sound money and other disruptive use cases. These things can coexist and compliment each other. But if Bitcoin proponents continue to ignore or attack these other applications, we may see them flourish on other networks instead. Which brings us to the second trap.

The Predestination Trap

Bitcoin may very well end up the single, dominant public blockchain, but this is not guaranteed. That should be obvious, yet some maximalists react defensively to what should be uncontroversial observations, like this one from Naval:

The best we can do is to view the future probabilistically, and even then it is unwise to assign too great a probability to any one outcome. There are simply too many variables and non-linearities to make a pronouncement; the future is fractal and these systems are too chaotic to submit to naive models.

We may end up with multiple valuable chains. Another chain might overtake Bitcoin. Chains may segment regionally or ideologically or based on functionality. Any number of outcomes are possible. It is wise to take all these possibilities seriously, to invest to capture upside from any of them, and to build and advocate for the vision of the world you'd like to see.

Productive Maximalism

Bitcoin Maximalism, whatever exactly it is, is not necessarily a bad thing. That Bitcoin has a rabid, committed fanbase is, in some ways, a very good sign for its future. Should said maximalists invest their energy in building the future in which they believe, their prophecies may be self fulfilling. It has the potential to be a very productive force.

The danger, though, lies in a narrow minded maximalism one that needlessly ignores powerful applications of blockchain technology and dismisses other projects embracing those possibilities. If too many maximalists fall for these traps, their devotion may preclude the very outcome for which they yearn.