My thoughts on scaling bitcoin

This is a somewhat long post, so I’ll give you the opportunity now to save yourself some reading time. Most of the post is historical context. If you are familiar with the history of bitcoin’s scaling debate, or are otherwise uninterested in my take on it, you can skip to the section at the end called “My conclusion”. If you’re like “damnit John just get to the point,” read the TL;DR at the bottom and you can read the rest of the post to fill in the details later.

I have been following the discussion around how to scale bitcoin since I first started researching the technology. I knew then as I do now that this will be the “make or break” debate for bitcoin, and also the most contentious given the challenges involved. I just did not know then how contentious it would be. Rather than solve the problem through hard forks or whatever other means necessary while bitcoin was small and relatively malleable, bitcoin grew very big, very fast, and the can has been repeatedly kicked down the road by developers and users to the point we are at today.

Even though it was obvious years ago that the only way bitcoin would reach global scale is through the widespread use of off-chain transactions, the systems needed to support such usage have only recently begun to be developed and none of any significance have yet been released in production. Thankfully, some forward-looking companies and bitcoin developers have been making the necessary investments to support such systems, including the Lightning Network and sidechains. Unfortunately, these systems are not ready yet, and the altcoins that have been nipping at bitcoin’s heel are now gnawing off its foot. There’s still a chance to save the rest of bitcoin and mend the wounds, but decisive action is needed, stat.

When I first gained an understanding of the issues at play in scaling bitcoin – mainly the effects on hashpower and full node centralization – I imagined that the off-chain technologies required to scale bitcoin would be ready by the time bitcoin hit its stride and gained mainstream adoption. I envisioned that there would be a graceful transition from on-chain to off-chain networks for daily “retail” usage. Not only has the transition not happened yet, when it does happen, it will hardly be considered “graceful”.

Due to various factors, bitcoin has gained a lot of attention recently. This has led to increased usage, and, subsequently, higher per-transaction fees. The average transaction fee today is about $1.00 USD. Just a year ago, it was less than $0.15. I am not opposed to high on-chain fees – in fact, I expect them to be at least 10x-20x higher or more in the future, and am completely ok with that. What I am opposed to is all bitcoin transactions being priced that high. Currently, users have no safe alternative if they want to transact in bitcoin. Either they swap IOUs on some trusted third party’s centralized database, or they pay $1.00 or more for every on-chain transaction. This isn’t the way it’s supposed to be.

Many of the decentralized “layer 2” off-chain solutions that have been proposed require slight modifications to bitcoin’s base “layer 1” protocol to work securely. One of the proposed modifications is called Segregated Witness (SegWit). While it’s not a scaling silver bullet, it paves the way for some exciting changes to bitcoin that will provide significant advancements for on-chain and off-chain scaling. Segregated Witness is not the only such proposal, but it is the one that has received the most attention and testing. And most importantly, it is production-ready today.

Despite a prior agreement to support SegWit, a large contingent of miners have failed to give it the support it needs to be activated on the main bitcoin network. The exact reasons that outspoken miners have given for their refusal to support SegWit activation vary, but the most common reason is that they won’t support SegWit unless a hard fork “non-witness” block size increase is bundled with it.

For various reasons, including concerns about the length of time it would take to test and safely deploy a hard fork, bitcoin developers have been unwilling to release a version of Bitcoin Core that would hard fork the network. They have presented several hard fork proposals for peer review, but none have yet gained the support required to merit merging into Bitcoin Core.

And so we have a stalemate.

My conclusion

After reviewing the arguments on all sides, and investigating nearly every scaling proposal put forward for public review, I have come to the conclusion that the miners should run SegWit software and signal for activation immediately, followed by a user-activated soft fork led by the economic majority when sufficient miner support is reached. Since signaling can be faked, a UASF will expose anyone who is swimming naked when the tide goes out (see: BIP66 fiasco).

If current holdout miners do not signal their support for SegWit, then the economic majority should still do a UASF, because the miners will quickly change their mind anyways (or else risk losing a lot of money). If the miners attempt to attack the UASF chain, then I will advocate for a transition away from double-SHA256 Proof of Work.

As stated earlier in this post, SegWit is the only proposal that has been rigorously examined and tested and put into production use by miners and full nodes. SegWit is being used in production by multiple altcoins, and to date there have been no bad incidents attributed to its deployment on these networks.

Additionally, SegWit does not preclude other on-chain scaling proposals, including non-witness block size increases. Given the nature of the anyone-can-spend hack, yes, we would (probably?) be locked into SegWit for the foreseeable future, but we can still layer other solutions on top – and there are a lot of great proposals that I would love to see tested and, if given a high safety rating, implemented in the future.

I have read and understand (to the extent possible given that I am not a software engineer) most of the reasons for opposing SegWit. Based on what I have read, heard, and have been told by engineers that I trust, the benefits of SegWit outweigh the costs. The developers that have spent time adding support for SegWit to their wallet and node software seem to agree. No other scaling proposal has such widespread support.

What’s important to understand is that SegWit is production-ready today, and any modification to include a hard fork or any other significant changes would simply delay scaling even further due to the time needed for testing and deployment. A hard fork requires an ecosystem-wide upgrade to go into effect, which takes time. A soft fork only requires miner support, and the SegWit soft fork is ready for activation today. We need scaling now, not in another six-to-twelve months.


Activate SegWit on bitcoin as soon as possible. Investigate other scaling solutions in parallel and implement the best of those later.


I realize that the debate has evolved from “what is the best way to scale bitcoin?” to “should Bitcoin Core continue to be the ‘reference implementation’ of the bitcoin protocol?” That question is outside the scope of this post and may be addressed in a future post. In any case, activating SegWit and changing the reference implementation are orthogonal issues; neither precludes the other.

Relevant links

Scaling Bitcoin series [link]

On Chain Scaling series [link]

Segregated Witness information [link]

ViaBTC: Why We Don’t Support SegWit [link]

Bitcoin miner: Why We Must Oppose Core’s SegWit Soft Fork [link]

Bitmain: Regarding Recent Allegations and Smear Campaigns [link]

Bitcoin Hard Fork Research [link]

Bitcoin Roundtable Consensus [link]

User-Activated Soft Fork (UASF) information [link]

BIP66 fork information [link]

A summary of the opposition to SegWit [link]

Email is probably the most popular decentralized messaging protocol. Add yourself to my email contacts if you would like to stay in touch!

Securing Bitcoin Core with Blockstack

Update September 15, 2016: I would like to thank the Bitcoin Core and Blockstack Core developers who have responded to this post in the threads here, here, and here. I will update this post again if I receive more relevant feedback.

A message recently appeared on the website warning visitors that: has reason to suspect that the binaries for the upcoming Bitcoin Core release will likely be targeted by state sponsored attackers.

The warning does not provide any evidence to back up these claims or specify what kind of attack will be attempted. However, the warning does suggest a mitigation tactic:

The hashes of Bitcoin Core binaries are cryptographically signed with this key.

We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries.

The focus on the use of signing keys, signatures, and hashes of the Bitcoin Core binaries to mitigate the risk of installing malware leads to the following assumptions:

  • The Bitcoin Core developers are not compromised.
  • The private signing keys of the Bitcoin Core developers are not compromised.
  • The computers the developers use to build the binaries are not compromised.
  • The SSL/TLS connections used to secure the download links for the public signing keys, signatures, and hashes are not compromised.

The conclusion here is that the author of the warning is concerned about an attack where the binaries available for download through official channels will be swapped out for malware, and users who do not check the signatures or hashes risk having their computers infected.

Note: here is a good discussion about the warning on the r/bitcoin subreddit.

Traditional mitigation tactics

The mitigation tactics suggested by the warning rely heavily on SSL/TLS to protect the integrity of the public signing keys, signatures, and hashes that users are expected to check against. Unfortunately, this is not enough to protect against a determined attacker. If the website is compromised, then any information hosted on the site is suspect. It is also possible for an attacker to compromise an SSL/TLS connection by compromising a Certificate Authority and issuing a fake SSL certificate. The attacker would then use the fake certificate to launch a man-in-the-middle attack on people visiting the target website, in this case to trick them into downloading fake keys, signatures, and hashes (and possibly fake binaries as well).

If users don’t trust the website or the Certificate Authorities that secure the connection used to download the Bitcoin Core signing keys, then there are two other verification methods that can be used: direct verification or the PGP Web-of-Trust. Direct verification is the strongest method, but can also be the most inconvenient. Users have to verify the PGP fingerprint of the signing key directly with the developer whose key they are trying to verify. This is challenging because it doesn’t scale well. Not everyone is able to meet developers directly, and it would be unproductive for developers to spend all their time verifying their keys with everyone who asks.

One way to scale direct verification is for developers to publish videos where they say their key fingerprints out loud. As long as people trust that the people in the videos are actually the developers and that the videos haven’t been tampered with in any way, this could work quite well. Another way to scale direct verification is through the Web-of-Trust. With the Web-of-Trust, user download the key they want to verify and then use PGP software to see if anyone they trust has signed the key in question to attest to its authenticity. If no one the user trusts has signed the key, or signed the key of someone who signed the key, etc, then the user needs to find someone they trust who they can use to create a chain of trust back to the key in question. Eventually, the user would find someone who trusts someone who trusts… the key in question.

Downsides of traditional mitigation tactics

Both direct verification and Web-of-Trust verification methods are effective, but can be inconvenient. Most users expect software to “just work,” without having to do any extra work to verify the integrity of the software. These verification methods also have a shelf-life. It is standard practice (and good crypto hygiene) for developers to rotate their signing keys after a certain period of time, creating a new keypair every so often to stay one step ahead of attackers. Every time a new keypair is created, the verification process has to be repeated by everyone who trusted the old keypair (unless everyone still trusts the old keypair, in which case developers can just sign their new public key with their old private key to indicate ultimate trust for the new keypair).

What if there was a way for Bitcoin developers to secure updates to their software with the same level of assurance provided by Bitcoin itself, and the same ease-of-use as popular applications like email? This is possible today with software called Blockstack, a decentralized key-value store built on Bitcoin.

Blockstack verification

Blockstack can combine the benefits of direct verification and the Web of Trust with the ease of use of popular apps like email by linking signing keys to easily-memorable usernames. A Blockstack username, also called a “blockchain ID,” is owned by a bitcoin address. Records associated with the blockchain ID are stored in a file called a “zone file” and cryptographically linked to every Blockstack transaction using the OP_RETURN field. These records can contain any information the user wants to provably link to their blockchain ID.

In this example, the user is a Bitcoin Core developer named Alice, and Alice wants to link her PGP signing key to her blockchain ID. These are the steps Alice would take to secure the next release of Bitcoin Core:

  1. Obtain a trustworthy copy of Bitcoin Core. This is easy for Alice because she is a Bitcoin Core developer. It is harder for other users due to the aforementioned challenges, but the good news is that a trustworthy copy of Bitcoin Core only needs to be obtained once for this method to work forever (assuming no epic pwnage, etc etc).
  2. Obtain a trustworthy copy of Blockstack. Same caveats as mentioned in step 1.
  3. Assuming the username isn’t taken yet, use Blockstack to register the blockchain ID alice in the .id namespace. The full blockchain ID is then
  4. Create a PGP keypair if she doesn’t already have one yet. This will be used to sign software binaries, hashes, and other important messages.
  5. Update the zone file record for to include the fingerprint of her public signing key and a link to the key itself so that it is easy to find. Once the zone file update is confirmed in the blockchain, anyone can use Blockstack to look up the new contents of the zone file.
  6. Advertise ownership of as publicly as possible. Tell all her collaborators over secure channels, publish messages confirming ownership of on social media, conference presentation slides, business cards, etc. Anyone who can verify the authenticity of these messages can then use Blockstack to look up and retrieve Alice’s up-to-date public key. This key will then be used to verify the signatures on updates to Bitcoin Core.

Alice could go even further and register a blockchain ID for Bitcoin Core itself, then update the zone file to include the blockchain IDs of all the other Bitcoin Core developers, as well as the hashes of the latest Bitcoin Core software. The bitcoin address that owns the Bitcoin Core blockchain ID could be a multisignature address that requires signatures from multiple Bitcoin Core developers to update the zone file, preventing Alice from becoming a central point of failure. This is essentially a way to secure Bitcoin software with Bitcoin itself – very meta.

Once Bitcoin Core developers have established a jointly-controlled blockchain ID, users will be able to use the Bitcoin Core blockchain ID as the authoritative source for Bitcoin Core updates without having to rely on untrusted third parties like Certificate Authorities or go through the hassle of direct contact or the Web of Trust every time they need to verify a signing key.

Putting theory into practice

I have taken the initiative to register a blockchain ID for Bitcoin Core: If the Bitcoin Core developers want to use this ID for the purpose described in this post, I am happy to donate to the project. To claim the ID, Wladimir J. van der Laan will need to send me a message signed by a key that I can confirm with any of the Core developers in the SF Bay Area who trust Wladimir’s key and are willing to meet me in person to confirm the key. This message must indicate a desire to claim and contain the bitcoin address that Wladimir wants me to transfer the ID to.

By the time I receive such a message from Wladimir, I will assume that he has familiarized himself with Blockstack and understands how to use the software. The exact protocols used to govern control of the blockchain ID address, updates to the ID, and contingencies in case private keys are compromised are to be determined by Wladimir (likely through consultation with the Bitcoin Core community).

Further reading

More information about the shortcomings of Certificate Authorities, how Blockstack works, and ways this technology can be applied to concepts like the PGP Web-of-Trust can be found in the following links:

Blockstack white paper – describes how Blockstack works.

Blockstack documentation – describes what Blockstack is and how to use it.

Decentralized Public Key Infrastructure white paper – describes how blockchains and similar technologies “address[] many usability and security challenges that plague traditional public key infrastructure.”

DNSChain – a similar project that pre-dates Blockstack and uses blockchains to fix SSL/TLS vulnerabilities.

DNSChain white paper – describes the problems with SSL/TLS and how DNSChain can fix them.

Email is probably the most popular decentralized messaging protocol. Add yourself to my email contacts if you would like to stay in touch!