The differences between a hard fork, a soft fork, and a chain split, and what they mean for the future of bitcoin

Note: In this post, I will describe soft and hard forks in the context of the bitcoin protocol specifically, but generally speaking, these definitions and effects are the same for other blockchain protocols as well.

Update #1 07/31/17: Since the time that I first started writing this, a small group of bitcoin miners have decided to run software called “Bcash” that will initiate a hard fork on August 1, 2017. Godspeed to them.

Ever since the New York Agreement led to a new implementation of bitcoin called btc1, the topic of a bitcoin hard fork has been top of mind for many people in the bitcoin community, including myself. The btc1 implementation is designed to activate a hard fork (“Segwit2x”) approximately three months after the activation of Segregated Witness (“SegWit”), a soft fork upgrade to the bitcoin protocol.

With SegWit activation seemingly just around the corner, anxiety is building about the upcoming Segwit2x hard fork activation. But what is a hard fork, how is it different than a soft fork, and why are people so anxious about it?

To illustrate the difference between a hard fork and a soft fork, and the potential effects each may have on the bitcoin network, I will create several hypothetical scenarios. These scenarios will be intentionally extreme so that a hard fork and a soft fork can be shown in stark contrast and the differences may be clearly understood. By the end, I hope to permanently put to rest any misconceptions about each style of change and any misunderstandings about their definitions.

Soft forks

A soft fork is a change to the bitcoin protocol that restricts the ruleset enforced by full nodes that upgrade to enforce the soft fork rules. A block that is considered valid before the soft fork activates will be considered invalid by upgraded full nodes if it violates the new soft fork rules after the soft fork activates.

An example is a soft fork that restricts the block size limit from 1MB to 500kB. Even though a 1MB block was previously considered valid, full nodes that upgrade to support this soft fork will reject any blocks larger than 500kB after the soft fork activates.

Soft fork scenarios

In these example scenarios, I will show a soft fork “activating” even if there are no nodes or miners forcing activation simply for the sake of illustration. Imagine that there is software that would have activated the soft fork if it had been deployed.

All full nodes and all miners upgrade

SF - All nodes and all miners upgrade

In this scenario, there are no full nodes enforcing legacy rules and no miners producing blocks that conform to the legacy rules. All full nodes have upgraded to enforce the soft fork rules and all miners are producing blocks that conform to the soft fork rules. As a result, there is no chain split.

The winning blockchain in this scenario is the soft fork blockchain.

All full nodes but one upgrade and all miners but one with 1% of the hashpower upgrade

SF - All but one full node upgrades and all but one miner with 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the legacy rules. The rest of the full nodes are enforcing the new soft fork rules and the rest of the miners are mining blocks that conform to the new soft fork rules.

Since soft fork blocks are compatible with legacy rules, and the miners producing soft fork blocks have more hashing power than the one miner producing legacy blocks, both legacy nodes and soft fork nodes will follow the soft fork blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost cerainly the soft fork blockchain. The only way the legacy blockchain could win in this scenario is if it can attract substantial economic investment to catch up to the soft fork blockchain and overtake it. If it can do that, then in the eyes of the legacy nodes, the legacy blockchain will cause a reorganization of the blockchain and wipe out the soft fork blockchain. Soft fork nodes will not be aware of the legacy blockchain and will be safe from a blockchain reorganization.

All full nodes but one upgrade and only one miner with 1% of the hashpower upgrades

SF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the soft fork rules. The rest of the full nodes are enforcing the new soft fork rules and the rest of the miners are mining blocks that conform to the legacy rules.

Since legacy blocks are incompatible with soft fork rules, and legacy miners have more hashpower than the one miner producing soft fork blocks, legacy nodes and soft fork nodes will each see two different versions of the blockchain. This creates a chain split, albeit one that progresses very slowly on the soft fork side since the soft fork miner has only 1% of the hashpower.

However this scenario is not as clear-cut as it may seem. Remember that all full nodes but one have upgraded to support the soft fork rules, while all but one miner with 1% of the hashpower are producing legacy blocks. The miners on the legacy blockchain have only one full node that they can sell legacy bitcoin to, since all of the soft fork full nodes are rejecting legacy blocks.

Either the one legacy node will have to have a lot of purchasing power to sustain the legacy miners’ hashpower or the legacy miners will have to quickly upgrade to conform to the soft fork rules so that their blocks will be accepted by the larger soft fork-supporting full node network. This scenario is most likely to occur as a User Activated Soft Fork, a soft fork that is intended to be signaled by economic full nodes ahead of the activation date to give the miners time to upgrade and avoid a chain split.

The winning blockchain in this scenario is uncertain, depending on the relative economic power of the nodes enforcing the new soft fork rules and their willingness to experience long confirmation delays in the event of a chain split. The longer they can wait after a split, the more economic pressure they can put on the miners to upgrade.

If the miners do not upgrade, the soft fork blockchain will need to attract substantial economic investment to keep it safe from a 51% attack. With enough investment in hashpower, the soft fork blockchain could cause either a sustained chain split or, if it can catch up and overtake the legacy blockchain, a blockchain reorganization that wipes out the legacy blockchain.

Only one full node upgrades and only one miner with 1% of the hashpower upgrades

SF - Only one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is only one full node enforcing the soft fork rules and only one miner with 1% of the hashpower producing blocks that conform to the soft fork rules. The rest of the nodes are enforcing the legacy rules and the rest of the miners are producing legacy blocks.

Since the miners producing legacy blocks have more hashpower than the one miner producing soft fork blocks, the legacy nodes will follow the version of the blockchain produced by legacy miners. However because legacy blocks are considered invalid by the one soft fork node, there is a chain split, albeit one that progresses very slowly since the soft fork miner has only 1% of the hashpower.

The winning blockchain in this scenario is almost certainly the legacy blockchain unless the soft fork blockchain attracts substantial economic investment to keep it safe from a 51% attack, in which case the soft fork blockchain could cause either a sustained chain split or, with enough hashpower, a blockchain reorganization that wipes out the legacy blockchain.

No full nodes upgrade and no miners upgrade

SF - No nodes upgrade and no miners upgrade

In this scenario, all full nodes are enforcing the legacy rules and all miners are producing blocks that conform to the legacy rules. No full nodes have upgraded to enforce the soft fork rules, so there is no chain split.

The winning blockchain in this scenario is the legacy blockchain.

Hard forks

A hard fork is a change to the bitcoin protocol that loosens the ruleset enforced by full nodes that upgrade to enforce the hard fork rules. A block that is considered invalid before the hard fork activates will be considered valid by upgraded full nodes if it follows the new hard fork rules after the hard fork has activated.

An example is a hard fork that increases the block size limit from 1MB to 2MB. Even though a 2MB block was previously considered invalid, full nodes that upgrade to support this hard fork will accept any blocks up to 2MB in size after the hard fork has activated.

Hard fork scenarios

In these example scenarios, I will show a hard fork “activating” even if there are no nodes or miners forcing activation simply for the sake of illustration. Imagine that there is software that would have activated the hard fork if it had been deployed. I will also assume that the new hard fork rules do not contain a soft fork rule that makes legacy blocks invalid.

All full nodes and all miners upgrade

HF - All nodes and all miners upgrade

In this scenario, there are no full nodes enforcing legacy rules. All full nodes have upgraded to enforce the hard fork rules and all miners are producing blocks that conform to the hard fork rules, so there is no chain split.

The winning blockchain in this scenario is the hard fork blockchain.

All full nodes but one upgrade and all miners but one with 1% of the hashpower upgrade

HF - All but one full node upgrades and all but one miner with 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the legacy rules. The rest of the full nodes are enforcing the new hard fork rules and the rest of the miners are mining blocks that conform to the new hard fork rules.

Since hard fork blocks are incompatible with legacy rules, and there is one full node enforcing the legacy rules, there is a chain split, albeit one that progresses very slowly since the miner producing legacy blocks has only 1% of the hashpower.

The winning blockchain in this scenario is almost certainly the hard fork blockchain. For all intents and purposes, legacy nodes and miners have been “forked off” the network. The only way the legacy blockchain could survive is if it attracts a substantial economic investment to keep it protected from a 51% attack, in which case there could be a sustained chain split or, with enough hashpower, a blockchain reorganization that wipes out the hard fork blockchain.

All full nodes but one upgrade and only one miner with 1% of the hashpower upgrades

HF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the hard fork rules. The rest of the full nodes are enforcing the new hard fork rules and the rest of the miners are mining blocks that conform to the legacy rules.

Since legacy blocks are compatible with hard fork rules, but hard fork blocks are not compatible with legacy rules, the legacy blockchain will out-compete the hard fork blockchain and both hard fork nodes and legacy nodes will follow the legacy blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost certainly the legacy blockchain. Although identical in network topology, this scenario ends differently than the soft fork version described above because hard fork nodes will not reject legacy blocks. So even though the vast majority of the network is running hard fork full nodes, there is no chain split and no economic pressure on miners to upgrade.

The only way the hard fork blockchain could win in this scenario is if it can attract substantial economic investment to catch up to the legacy blockchain and overtake it. If it can do that, then in the eyes of the hard fork nodes, the hard fork blockchain will cause a reorganization of the blockchain and wipe out the legacy blockchain. Legacy full nodes will not be aware of the hard fork blockchain and will be safe from a blockchain reorganization.

Only one full node upgrades and only one miner with 1% of the hashpower upgrades

HF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is only one full node enforcing the hard fork rules and only one miner with 1% of the hashpower producing blocks that conform to the hard fork rules. The rest of the nodes are enforcing the legacy rules and the rest of the miners are producing legacy blocks.

Since legacy blocks are compatible with hard fork rules, but hard fork blocks are not compatible with legacy rules, the legacy blockchain will out-compete the hard fork blockchain and both hard fork nodes and legacy nodes will follow the legacy blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost certainly the legacy blockchain unless the hard fork blockchain can attract substantial economic investment to catch up to the legacy blockchain and overtake it. If it can do that, then in the eyes of the hard fork nodes, the hard fork blockchain will cause a reorganization of the blockchain and wipe out the legacy blockchain. Legacy full nodes will not be aware of the hard fork blockchain and will be safe from a blockchain reorganization.

No full nodes upgrade and no miners upgrade

HF - No nodes upgrade and no miners upgrade

In this scenario, all full nodes are enforcing the legacy rules and all miners are producing blocks that conform to the legacy rules. No miners have upgraded to produce hard fork blocks, so there is no chain split.

The winning blockchain in this scenario is the legacy blockchain.

Chain splits

As described in some of the scenarios above, a chain split is a scenario where there are two or more competing versions of the blockchain that share the same history up to the point that their rulesets diverge. While the term “chain split” can elicit feelings of fear among even the most battle-hardened bitcoin veterans, a chain split is not always the disaster scenario that some make it out to be.

As shown in the above hypothetical scenarios, it is possible for both a soft fork and a hard fork to cause a chain split. For example, in July 2016 a planned soft fork rule change called BIP66 led to a chain split and blockchain reorganizations due to some miners not validating the rules of the blocks they were mining on. Bitcoin recovered and here we are today.

Equally important to note is that it is possible for both a soft fork and a hard fork to avoid a chain split. The barrier to avoiding a disruptive chain split is much higher for a hard fork due to its incompatibility with legacy full nodes, but it is technically possible. For example, in August 2013 a planned hard fork was deployed in order to fix a bug that caused a chain split and blockchain reorganization in March 2013. The August 2013 hard fork resulted in virtually no disruption to the network since nearly all miners and economic nodes had upgraded their software by then.

It is also worth noting that chain splits can occur without a planned soft or hard fork rule change. A chain split can be caused by an unintentional incompatibility between two different versions of full node software, such as with the March 2013 chain split. Chain splits can even occur during normal bitcoin network operations as miners race to build a “winning” version of the blockchain that earns them new block rewards. The latter happens quite regularly, which is likely one reason why older versions of the Bitcoin Core wallet suggested waiting six confirmations before considering a transaction settled.

Sustained chain splits

The type of chain split that is perhaps most damaging to bitcoin, at least in the short term, is the sustained chain split. In a sustained chain split, there is sufficient economic and hashpower support on two or more versions of the blockchain to lead to there being multiple competing versions of the blockchain for an extended period of time. Holders of bitcoin on the “legacy” blockchain will also control an equal balance of “forkcoin” on each version of the blockchain that is extended when the divergence occurs.

There are several technical issues that can arise with a sustained chain split. One is the issue of replay attacks, where transactions meant for one blockchain are confirmed on another, which can lead to accidental losses of money. Another issue is the blockchain reorganization, where one version of the blockchain gets overtaken by another, potentially leading to a loss of funds by users who were relying on the history of the blockchain that was overtaken.

One of the biggest issues with a sustained chain split is longer-term and more social than technical: which blockchain gets to keep the name “bitcoin”? And will the brand confusion between the multiple competing versions of the blockchain damage investor confidence in bitcoin? These are questions that cannot be answered with a simple software patch, instead requiring subjective decision-making on the part of developers and industry leaders with regards to branding and public relations.

What these differences mean for bitcoin now and in the future

The version of SegWit that is activating soon is a soft fork. As of the time of this writing, 100% of the last 100 blocks are signaling support for SegWit (you can monitor this progress here). If this trend continues, then SegWit will activate with 0% chance of a temporary or permanent chain split. However three months after SegWit activates, btc1 will trigger the activation of the Segwit2x hard fork. Miners representing over 80% of the network hashpower committed in writing to supporting Segwit2x, leaving 20% who may continue to support the legacy blockchain, or possibly another blockchain, potentially causing a temporary or sustained chain split.

There is also the possibility of an “emergency” hard fork (EHF) at the time of the Segwit2x hard fork if there is a large enough part of the economy that rejects Segwit2x. This EHF may include a difficulty adjustment and/or a change to the Proof of Work algorithm to preserve the usability and security of the EHF blockchain. If users take this route, then Segwit2x could still lead to a chain split even with 100% legacy miner adoption. The probability of this happening depends on how strong the negative feelings are that users have towards Segwit2x.

This year will be looked back on as a pivotal year in the history of bitcoin. Given the incentives built into the system, I am confident that bitcoin will come out of all of this stronger than it was before. Multiple forks of the bitcoin blockchain may be competing for liquidity as a result of various fork proposals, and that’s okay as long as there is no unnecessary brand confusion in the marketplace. The incentives ensure that miners will eventually converge on the most valuable blockchain, or else go bankrupt.

I know what blockchain I’ll be using: the blockchain that secures the most value, with the most hashpower, the greatest potential for future adoption, and the best ability to preserve the “golden rule” of transaction immutability.

Header image via http://distributingchains.info/resources/the-blockchain-is/


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

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1Cj8hNg9joC8FnS8D2FVFCvQUVy975VJZi

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

New feature on the blog: bitcoin payment codes

Yesterday I took some time to download the latest version of the Samourai Bitcoin Wallet and register my new bitcoin payment code on their website paymentcode.io. I have started going through my back-catalog of blog posts and adding the payment code so people can send me tips if they like the content. You can see an example of what this looks like at the bottom of this post.

I have been interested in the idea of “stealth addresses” since they were first proposed several years ago and later implemented in Dark Wallet, and am glad to see the concept live on in the Samourai wallet in the form of BIP47 Reusable Payment Codes. Definitely check it out if you are interested in preserving your financial privacy while using bitcoin. Be aware that Samourai is still in alpha so manage your expectations accordingly.

Here is a video showing how payment codes work in the Samourai wallet:

 


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

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1Cj8hNg9joC8FnS8D2FVFCvQUVy975VJZi

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

37 Days to SegWit: When SegWit is Live…

Ever since SegWit was first introduced at Scaling Bitcoin Hong Kong in 2015, I have found myself starting sentences with, “When SegWit is live…”, followed by some prediction about how this technology will supercharge bitcoin. In the spirit of the optimism around growing support for SegWit among miners and the broader bitcoin economy, I thought I’d share some of the things I’m excited about for “when SegWit is live” on bitcoin in 37 days (or less!).

When SegWit is live…

  • More transactions will fit in each block, and as far as I can tell this will not come at the expense of node or hashpower decentralization. In my humble opinion, more transactions per block is always a good thing as long as we don’t sacrifice the security of the system.
  • Transaction malleability will be fixed for SegWit transactions, enabling advanced scaling technology such as a more secure version of the Lightning Network. Lightning Network is very exciting because it opens up whole new micropayment-related use-cases that have simply not been possible on-chain.
  • It will be safer to increase the block size limit, due to the way that SegWit fixes the quadratic scaling of hashed data problem. As mentioned earlier in this post, more transactions per block is a good thing so long as bitcoin’s security is not compromised.

I’m very excited to see these and other benefits added to bitcoin because taken together, they strongly reenforce bitcoin’s leadership in the cryptocurrency market since virtually any cryptocurrency feature or use-case someone could think of will be possible either on bitcoin’s “mainchain” or a Layer 2 protocol such as sidechains or Lightning. This adds a tremendous amount of utility for the millions of people using bitcoin, and further increases the network effect and security that makes bitcoin such a powerful technology.

To the moon!


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

Bitcoin tips accepted:

Bitcoin address (what’s this?)

16XukVGi8YCiHwxrfjbmmXL241Dpmf9NcH

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

46 Days to SegWit: Growing Consensus in the Bitcoin Economy

You can read previous posts in this series here and here. You can find my guide about how to enforce the BIP148 UASF with your Electrum bitcoin wallet here. For templates that you can use to fill-in-the-blank and request that your favorite economic nodes and mining pools support the BIP148 UASF, scroll to the bottom of this post.

A lot has happened since last week’s blog post about the BIP148 UASF. Bitmain, the largest ASIC miner manufacturer, released their “contingency plan” for a “User Activated Hard Fork” in case the BIP148 UASF activates before the Segwit2x soft fork. The way I read this is that Bitmain is willing to do whatever it takes to avoid activating SegWit, which is quite surprising given that less than a month ago they signed the Segwit2x agreement to activate SegWit. If Bitmain would just signal for SegWit via BIP141 now, that would go a long way towards preventing a chain split on August 1. But I digress.

In more positive news, bitcoin developer James Hilliard submitted a pull request to the Segwit2x GitHub repository yesterday with code that attempts to make the Segwit2x deployment compatible with BIP148. While it’s not as good a solution as it would have been to make the proposal compatible from the start, this is likely the next best thing at this juncture. For that, I thank James for making the effort.

Continuing the theme of support for SegWit and BIP148, several important economic nodes have recently announced their support, undoubtedly thanks to the many supporters who have voiced their preference in public and private messages. These economic nodes include Ledger, a hardware wallet manufacturer, and the team behind Bitsquare, a decentralized exchange application. You can learn more about the growing support for SegWit and BIP148 among developers and economic nodes on this page of the bitcoin wiki.

If you support the BIP148 UASF, you should contact the folks behind your favorite wallets and exchanges if you haven’t already and ask them to enforce the BIP148 UASF. You can find fill-in-the-blank templates to do this at the bottom of the post here.

Since last week’s blog post I was also invited onto three different YouTube shows to discuss SegWit and the BIP148 UASF. You can watch these episodes below:

Hungarian Crypto Show

https://www.youtube.com/watch?v=dmtaQ55AZac

This Week in Bitcoin

https://www.youtube.com/watch?v=0wiWWQKswuY

Bitcoin News #42

https://www.youtube.com/watch?v=fXxW5wyeGrk


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

Bitcoin tips accepted:

Bitcoin address (what’s this?)

12Y353a3o6vLCNxEuenqydcc3jq47qKUwc

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

How to enforce the BIP148 UASF with the Electrum bitcoin wallet

During a recent interview I did on This Week In Bitcoin, I was asked how to enforce the BIP148 UASF with the Electrum bitcoin wallet. I didn’t have a quick answer at the time so I decided to write up this guide.

Here are some easy instructions for how to do that:

(You can skip to step 3 if you already have the Electrum bitcoin wallet installed.)

Step 1. Install Electrum

Step 2. Create a new wallet and save your master seed in a safe place. You can also hook up your hardware wallet if you have one. [Ledger] [Trezor]

Step 3. In the menu bar click Tools -> Network

Step 4. Uncheck “Select server automatically”, paste electrum.satoshiportal.com into the Server field, then click OK.

Screen Shot 2017-06-10 at 12.57.56 AM

That’s it! The wallet is now talking to a server run by Francis Pouliot that will automatically enforce BIP148 for you. Use this wallet for all of your transactions to ensure that your wallet is enforcing BIP148. If you’re really tech-savvy you can also run your own Electrum server and configure it to enforce BIP148 for you.

WARNING: In the event that neither the economic nor hashpower majority supports BIP148 by August 1, you should undo the steps taken here to enforce BIP148. You can do that by checking the “Select server automatically” box on the Network page as in Step 3 above. If you don’t check this box, you could end up transacting on a minority blockchain after August 1, and your transactions will be at risk of getting reversed.

If you want to better protect your privacy when using Electrum, then on the Network screen select “SOCKS5” proxy on localhost port 9150 then click OK. Close Electrum then open Tor on your computer. Restart Electrum and it should sync with the Electrum server over Tor. Make sure whenever you use Tor with Electrum that you start Tor BEFORE you open Electrum and close Tor AFTER you close Electrum.

For more info about the BIP148 UASF you can read through these posts and the links contained therein:

https://lightco.in/2017/06/02/segwit-uasf/

https://lightco.in/2017/06/09/no-chain-split/


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

Bitcoin tips accepted:

Bitcoin address (what’s this?)

13aTqJXeRUDrfjBU8VwyWKvWpjNfFtvM5J

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

52 Days to SegWit: Why the chain won’t split

Last week’s post about the BIP148 UASF ended up generating quite a bit of discussion on reddit and twitter, which you can read here and here, respectively.

I have since received a lot of comments about BIP148 from people who read the post or otherwise used it as an opportunity to voice their opinions about BIP148. The vast majority of these comments were positive, and the comments that were negative were mostly supportive of the idea of a UASF, just not this particular UASF. The remainder was trolling (lol).

As I stated in last week’s post, the main reason that I’m supporting BIP148 is because I don’t think we need to wait for either Segwit2x to roll out or BIP149 to activate (if it ever even gets deployed). This is not a matter of me taking my impatience out on the bitcoin network, potentially putting the sanctity of the blockchain on the line in the process. I have no intention of helping to violate bitcoin’s core value as a reliable p2p electronic cash system.

My support of BIP148 is an acknowledgement and open embrace of the fact that individuals and companies representing over 80% of the hashpower on the bitcoin network recently signed an agreement to activate SegWit and dozens of the most influential wallets, exchanges, and infrastructure providers have signaled their readiness for SegWit since it was first introduced in December 2015.

To this moment I have assumed that the reason that SegWit supporters are not yet enforcing BIP148 is because they aren’t educated about it. There are a lot of proposals up in the air, so it’s understandable that some don’t get the scrutiny they otherwise might if there were more hours in the day.

To help educate the public I published the blog post last week and am sharing additional information here. There will likely be many others who come forward to educate those around them about BIP148 (I have already had offers to have last week’s post translated into three different languages). By August 1, we’ll be able to see who is being honest about their support of SegWit and who, if anyone, is not.

An important point to acknowledge is that many of the important stakeholders BIP148 needs to succeed recently signed the Segwit2x agreement. As far as I can tell, BIP148 is not incompatible with the Segwit2x agreement. At the very least, BIP148 does not violate the spirit of the agreement, since it both activates SegWit and in no way prevents signatories from running code for a 2MB hard fork once it’s ready.

There is a possibility that Segwit2x developers will not hit their milestones on schedule without issue. I believe it would be in the spirit of consensus for everyone who signed the Segwit2x agreement to update their nodes to enforce BIP148 so that we can ensure a smooth SegWit activation on or before August 1. Developers will then be freed to focus on coding, testing, and deploying the hard fork software.

The criticisms of BIP148

After last week’s blog post was published, there were two major criticisms of BIP148 that came up repeatedly. I was aware of these criticisms before I published the post, but enjoyed engaging one on one with people who have these concerns and asking direct questions to learn more and solidify my understanding. The two major criticisms go something like:

  1. If the BIP148 chain has a minority of hashing power, then there will be a chain split. This will cause all kinds of problems for bitcoin users, including increased confirmation times and the potential for replay attacks to happen between the BIP148 chain and the legacy chain. okTurtles co-founder Greg Slepak discussed the consequences of a chain split with me in a recent YouTube Live session.
  2. BIP148 activates too soon, which increases the chance of the disruptive scenarios described in (1) above playing out. We should either stick with the status quo or support something that gives us more time, like BIP149, instead. Jorge Timón brought this up on Twitter, as have others.

My response to critics is that I, too, think a chain split would be very disruptive – unacceptable even – and I would be right there with you advocating that BIP148 supporters stand down if not for the fact that a supermajority of hashpower and a large part of the economic majority have publicly pledged support for activating SegWit.

Of course, if neither the economic majority nor the majority of the hash power are enforcing BIP148 on August 1, the advice as published on uasf.co is to stop enforcing BIP148 and switch back to the legacy consensus rules. But again, a supermajority of hashpower and a large part of the economic majority have publicly pledged support for SegWit, so we should have no problem activating it on or before August 1.

My appeal to all bitcoin users, miners and economic nodes alike

If you have publicly stated support for activating SegWit, either as part of the Segwit2x agreement or at any other time, make your support and enforcement of BIP148 known so we can smoothly activate SegWit on or before August 1, the way it was designed to be and the way I know we would all prefer it to be done.

SegWit is designed to be the safest, fastest way for us to add capacity to the bitcoin network and fit more transactions into every block. SegWit could have the effect of lowering per-transaction fees in the short term, but more importantly it paves the way for longer-term on- and off-chain scaling improvements. SegWit in no way prevents us from implementing a hard fork block size limit increase in the future, provided there is consensus around a safe solution that does not compromise bitcoin’s core value.

We are working on what is perhaps the most important project we will ever devote our time to. While some look at bitcoin and only see dollar signs, many of us still understand that the end-game of bitcoin means much more than making some early adopters rich. Previous efforts to scale this system to support current and future influxes of users have had their flaws, but we are at the point where we have broad consensus around a safe solution and growing consensus around additional capacity increases in the future.

Let’s activate SegWit via BIP148 and give the Segwit2x team the breathing room they need to work on a safe hard fork implementation as agreed. In the mean time, other contributors can continue working on separate on- and off-chain scaling solutions, as well as research into communications layers that could help make discussion and coordination for soft- and hard-forks better in the future.

We have the opportunity of a lifetime to build the foundational layer of the future of money, one that could possibly be in use for as long as the internet itself exists. Let’s not squander it over… whatever it is that has kept SegWit from activating to date!

☮ ❤ 


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

Bitcoin tips accepted:

Bitcoin address (what’s this?)

1A2SWzwbCCaB2EDPvkPtjot9w8kctgYxYY

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

SegWit in 60 Days: How to ensure the BIP 148 User Activated Soft Fork succeeds

Update: You can read some of the conversation around this post happening on social media here and here.

The first section of this post is a background on the SegWit UASF and the two main proposals that would enforce it, BIP 148 and BIP 149. If you are already familiar with these details, you can skip to the section called “What you need to do to help BIP 148 succeed”.

P.S. I would love help translating this whole post, including the message templates at the end, into Chinese, Japanese, Korean, and Spanish, in particular. If you can help translate these posts into these or any other language, please get in touch, or just do it, publish it somewhere prominently, and share widely!

On February 25, 2017, bitcoin developer shaolinfry introduced a proposal to the bitcoin-dev mailing list suggesting the use of a technique referred to as a “User Activated Soft Fork” or “UASF” to activate the SegWit soft fork in bitcoin. (You can read more background about SegWit and the surrounding scaling debate in this post).

The concept of a UASF is not new, having previously been used to activate the BIP 16 P2SH soft fork. A UASF relies on the fact that it is not the miners but the economy of bitcoin users that set the rules of the bitcoin network by throwing their economic weight behind one rule set over others.

Once a UASF is enforced by a given full node, any blocks produced by miners that do not comply with the rules of the UASF will be rejected by that node. If enough economic nodes enforce the UASF, then miners will be strongly incentivized to comply with the rules so that they’ll be able to sell the bitcoin mined in their blocks (and avoid losing their block rewards in a reorg).

Shaolinfry has proposed two Bitcoin Improvement Proposals (“BIPs”) that enforce a UASF: BIP 148 and BIP 149. The difference between the two is that the BIP 148 UASF activates the current SegWit deployment on August 1, 2017, while the BIP 149 UASF activates a new SegWit deployment in July 2018 at the latest, the rationale for the latter being that it could be less disruptive since there is more time for nodes to upgrade.

You can read more about these proposals here and here. You can read bitcoin developer Luke Dashjr’s post about “BIP 148 and the risks it entails for you” here. I am aware that these proposals are also happening in the context of a “Segwit2x” agreement recently made between many companies. I believe that a UASF is still important in case that agreement breaks down or the code is not ready in a timely manner, and encourage all signatories to the agreement to use full node software enforcing the BIP 148 UASF.

What you need to do to help BIP 148 succeed

Throughout this section, wherever it says “enforce BIP 148” you should read this as “enforce BIP 148 before August 1”.

If you feel as I do that waiting until July 2018 at the latest to activate SegWit on bitcoin is an unnecessarily long time, then this section is relevant to you. As stated above, for a UASF to succeed, it needs the weight of the bitcoin economy behind it. This means that if you are a bitcoin user, you need to do three things:

Step 1. Update the full node your wallet uses.

If your bitcoin wallet uses your own full node to validate incoming transactions, update your node to enforce BIP 148. You can find the code for this at uasf.co. If your wallet does not use your own full node to validate incoming transactions, then either the wallet developer in the case of p2p SPV wallets or the operator of the node your wallet is connected to will need to update their software to enforce BIP 148 (the node operator for wallets is usually the wallet developer, but if you have doubts, check the settings or just ask the wallet developer). You should contact them and encourage them to update their software to enforce BIP 148. A template for this is included at the end of this post.

If you want to add some teeth to your message, let the node operator know that if they do not update their node infrastructure to enforce BIP 148 then you will have to switch to a service provider that does (you can find a list of companies who have taken a public position about BIP 148 at uasf.co). If the wallet developer is the node operator, and they do not update their node infrastructure, then after uninstalling the wallet you can also leave a review for them on the app store warning other people against using the app since it does not enforce BIP 148.

Step 2. Contact the economic nodes you do business with.

If you are a customer of a bitcoin exchange, OTC trader, or merchant payment processor, you should contact them and encourage them to update their node infrastructure to enforce BIP 148. Assume any companies not listed as “Ready” on uasf.co have not updated their software and need to be encouraged to do so.

When you contact them, be sure to respectfully but firmly remind them of all the transactions you have done using their service and let them know that despite how great you think they are that you will have to take your business elsewhere if they do not update their nodes to enforce BIP 148. A template for this is also included at the end of this post.

If you intend to use threats of boycott to persuade economic nodes to update their software, make sure you go through with it! The financial pain they will feel will make them question whether it is worth it to continue blocking progress in bitcoin.

Step 3. Sell your non-SegWit bitcoin.

If there is a long-lasting chain split after August 1, then you will have coins on both chains in any addresses that held a positive balance before the split. Using a wallet that supports spending on both chains, transfer the coins that are on the non-SegWit chain to an exchange that supports that chain and sell the coins for SegWit bitcoins. This will put sell pressure on the price of non-SegWit bitcoin and add buy support to SegWit bitcoin, increasing the chances of SegWit bitcoin’s success.

There is one additional step if you are a miner. If you are a solo miner, update your mining software to enforce BIP 148. If you mine on a pool, encourage your pool operator to enforce BIP 148. If they don’t, switch to a pool that does.

Stretch goal: add BIP 148 support to Bitcoin Core

If we really want BIP 148 to succeed, we should try hard to get it added to an official release of Bitcoin Core before August 1. This should be considered a stretch goal that comes after proving massive grassroots support via the steps taken above, and will nonetheless be a major accomplishment to achieve before August 1. This is not a necessity but a very important goal since Bitcoin Core’s developers are widely respected in the technical community.

Summary

To help BIP 148 succeed:

  • Update your full node to enforce BIP 148. Signaling is also good, but only enforcement matters.
  • If you do not run a full node, encourage the full node operator your wallet relies on to enforce BIP 148 if they do not already.
  • Encourage any bitcoin businesses you are a customer of to also update their full nodes to enforce BIP 148. If they do not run their own full nodes, then encourage them to encourage their full node operator to enforce BIP 148.
  • Sell your non-SegWit coins if there is a long-lasting chain split.
  • If you are a solo miner, update your mining software to enforce BIP 148. If you mine on a pool, encourage your pool operator to enforce BIP 148. If they don’t, switch to a pool that does.
  • Boycott any economic nodes that are not enforcing BIP 148 after August 1. Only do business with the economic nodes listed as “Ready” on uasf.co.

Remember, BIP 148 will only succeed without a chain split if it is supported by a majority of miners on August 1, and getting the economic majority of full nodes to enforce UASF is a great way to convince miners of how important SegWit is to bitcoin users. The whole reason SegWit was done as a soft fork was to minimize disruption, so let’s make sure that incentives are aligned to prevent a chain split.

Templates

Here are some suggested message templates that you can take and fill in the blanks and modify however you want to suit your particular purpose. Once you’ve modified the message to fit your purpose, you can send it in an email to the intended recipient.

Remember to be respectful but firm in all of your communications supporting BIP 148. Do not use ad hominem attacks, name-calling, or assume bad faith. Everyone is entitled to their opinions and it’s only natural that there is a diversity of opinions in a decentralized network like bitcoin. Vires in numeris!

Wallet node operators

Dear [wallet node operator],

My bitcoin wallet relies on your full node to validate incoming transactions, and I greatly appreciate the service you provide to make this possible. As you are probably aware, there is an upgrade to bitcoin called Segregated Witness that offers a lot of benefits to bitcoin users such as myself, and I would very much like to start getting the benefits of this upgrade as soon as possible.

Can you please update your node software to enforce the BIP 148 User Activated Soft Fork (UASF) before August 1 and post an announcement to your website when you have made this update? This would give miners the signal they need to show support for SegWit and help activate this important upgrade.

I am interested in using a wallet that enforces BIP 148 so that the bitcoin network can soon benefit from all the improvements Segregated Witness has to offer. If your node software is not updated to enforce BIP 148 then I will have to switch to using a wallet that does.

I have included links below with more information about Segregated Witness and the BIP 148 UASF.

Thank you for your consideration,

[your name]

https://bitcoincore.org/en/segwit_adoption/

https://segwit.org/

http://www.uasf.co/

Exchanges

Dear [exchange operator],

I have been trading bitcoin on your exchange for a while now, and I greatly appreciate the service you provide to make this possible. As you are probably aware, there is an upgrade to bitcoin called Segregated Witness that offers a lot of benefits to bitcoin users such as myself, and I would very much like to start getting the benefits of this upgrade as soon as possible.

Can you please update your node software to enforce the BIP 148 User Activated Soft Fork (UASF) before August 1 and post an announcement to your website when you have made this update? This would give miners the signal they need to show support for SegWit and help activate this important upgrade.

I am interested in using an exchange that enforces BIP 148 so that the bitcoin network can soon benefit from all the improvements Segregated Witness has to offer. If your node software is not updated to enforce BIP 148 then I will have to switch to using an exchange that does.

I have included links below with more information about Segregated Witness and the BIP 148 UASF.

Thank you for your consideration,

[your name]

https://bitcoincore.org/en/segwit_adoption/

https://segwit.org/

http://www.uasf.co/

Merchant payment processors

Dear [merchant payment processor],

I greatly appreciate the service you provide that enables me to accept bitcoin as a form of payment from my customers. As you are probably aware, there is an upgrade to bitcoin called Segregated Witness that offers a lot of benefits to bitcoin users such as myself and my customers, and I would very much like to start getting the benefits of this upgrade as soon as possible.

Can you please update your node software to enforce the BIP 148 User Activated Soft Fork (UASF) before August 1 and post an announcement to your website when you have made this update? This would give miners the signal they need to show support for SegWit and help activate this important upgrade.

I am interested in using a merchant payment processor that enforces BIP 148 so that the bitcoin network can soon benefit from all the improvements Segregated Witness has to offer. If your node software is not updated to enforce BIP 148 then I will have to switch to using a merchant payment processor that does.

I have included links below with more information about Segregated Witness and the BIP 148 UASF.

Thank you for your consideration,

[your name]

https://bitcoincore.org/en/segwit_adoption/

https://segwit.org/

http://www.uasf.co/

Mining pool operators

Dear [mining pool operator],

I have been a loyal miner in your pool for a while now, and I greatly appreciate the service you provide to make this possible. As you are probably aware, there is an upgrade to bitcoin called Segregated Witness that offers a lot of benefits to bitcoin users, and I would very much like to start getting the benefits of this upgrade as soon as possible.

Can you please update your pool software to enforce the BIP 148 User Activated Soft Fork (UASF) before August 1 and post an announcement to your website when you have made this update? This would give other miners the signal they need to show support for SegWit and help activate this important upgrade.

I am interested in using a mining pool that enforces BIP 148 so that the bitcoin network can soon benefit from all the improvements Segregated Witness has to offer. If your mining software is not updated to enforce BIP 148 then I will have to switch to using a mining pool that does.

I have included links below with more information about Segregated Witness and the BIP 148 UASF.

Thank you for your consideration,

[your name]

https://bitcoincore.org/en/segwit_adoption/

https://segwit.org/

http://www.uasf.co/


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

Bitcoin tips accepted:

Bitcoin address (what’s this?)

1GwbiEpMbVRNcYNduE2Y7WbUEL8ANYdr23

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ