Expectations

These instructions require that you understand how files are stored in your computer (abstractly; if you know what a directory/folder is, you’re probably okay) and how to use the command line to run programs and access files. If you don’t understand these concepts, first start with a guide explaining them to you.

Be mindful that the instructions here can only help you install Bitcoin securely. It does not attempt to help you secure your hardware, your operating system, or avoid malware introduced by other applications you install. Generally, if anything else in your computer is compromised, your node will also be at risk, no matter how secure you verify its own install.

If you want an absolutely secure node, in addition to the instructions herein, you will need to (at least) avoid backdoored hardware (including Raspberry Pi, and anything produced by Intel or AMD), run a trustworthy Linux-based operating system, only install or use software either provided by your OS vendor, or otherwise verified using GnuPG (such as described in this article), and ensure it’s kept up to date with the latest vulnerability patches.

Even if you can’t get maximum security by addressing these other concerns, that doesn’t mean you should give up, however: it is still a good idea to verify your Bitcoin node software anyway.

Overview

There are three important steps to ensuring your install of Bitcoin is secure and free of malware:

• Verifying the OpenPGP key(s)
• Verifying the signature(s)
• Verifying the file itself

Each step depends on the previous steps being successful, and while it is possible to skip a step, it is important to understand that your install is not verified unless all the steps are successful.

Note that for examples, I will be verifying my own signature on Bitcoin Knots v0.19.0.1.knots20200104 for ppc64le Linux. To verify someone else’s signature and/or another file, you will need to change the command line to use that fingerprint and/or filename.

Step 0: Installing GNU Privacy Guard (GPG)

Before you can begin, you will need to ensure you have the GNU Privacy Guard (GPG) tools installed. This is what does all the cryptographic verification needed to ensure your files are safe.

If you run a Linux-based system, you can usually install it from your OS vendor. These days, it’s usually already installed “out of the box” — you can check by running gpg --version. If not, try installing it with one of these commands (if they fail, move on to the next):

apt-get install gnupg
dnf install gnupg2
yum install gnupg2
emerge app-crypt/gnupg
pacman -S gnupg 
apk add gnupg

If you have the misfortune of using Windows or macOS, you can download GnuPG from their website, but I’m not aware of any secure way to verify that download. They do, of course, provide signatures, but you have a chicken-and-egg problem: until you install a good copy, you have no way to verify those signatures!

Step 1: Verifying the OpenPGP key(s)

This is arguably the most difficult step of the process: you need to confirm that the key(s) you are using actually are the correct keys used by the people you trust to produce malware-free software. If you’re not careful, you could end up with a fake key for “Luke Dashjr” — which would result in checking that the fake person signed the program, not the real one!

Each OpenPGP key has a “fingerprint”, which is 40 hexadecimal characters (numbers 0–9 and A-F), sometimes shown with spaces to make them easier to read. If you ensure the fingerprint of the key you are using matches the fingerprint of the trusted signer, you know you have the right key.

Obtaining keys and/or fingerprints

The most secure way to verify the keys, is to meet us in person and confirm the key “fingerprint”. Almost nobody memorises their key fingerprint, so it’s normal that we might have to look it up on our own laptop or phone.

Once in a while — usually at conferences or meetups — there may be “key signing parties” where a group of people meets to confirm the fingerprints of everyone else, by each participant either reading their own fingerprint aloud in person, or otherwise manually confirming that what everyone sees/hears is correct. If you get the opportunity to go to one, this is a good way to verify many keys at once.

If you’re not interested in or don’t have the chance to meet up in person, you should ideally verify a key from multiple sources.

Sometimes, conferences post video of presentations, where a key fingerprint might be shown in a slide. While “deep fake” technology is fairly new, do note that slides in video are much easier to manipulate.

Developers will usually post their keys or fingerprints on their website, and perhaps a few others (mine is on my personal website, bitcoinknots.org, bitcoin.org, and GitHub).

If you already have an installed copy of the software you trust, sometimes it will include the keys needed to verify updates (Bitcoin Core only includes it with source code at this time).

Checking the fingerprint of a key file

To look at the fingerprint of a key file, you can use this command:

gpg --import-options show-only --import --with-fingerprint luke-jr.asc

This will print a lot of information about the key file, but the relevant information is at the very top:

pub   rsa8192 2012-03-23 [SC] [expires: 2020-06-09] 
      E463 A93F 5F31 17EE DE6C  7316 BD02 9424 21F4 889F

In this case, E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F is the fingerprint for my key.

NOTE: If GPG says the key is expired, that is probably okay! In Step 2, you will update it to the newest version of the same key, which usually extends the expiration date.

Importing the verified key

Regardless of how you verify the key, you should make sure to remember which key you used, so you can verify the same key is used when you update in the future. Even if you skip verifying the key (not safe), at least this will ensure your updates are signed by the same person as the version you are installing today.

When you’re comfortable that the key you have is correct, import it like this (replace luke-jr.asc with the filename holding the key you want):

gpg --import < luke-jr.asc

Or if you only have the fingerprint, like this (put the key fingerprint you want to use!):

gpg --keyserver hkp://keyserver.ubuntu.com --recv-key E463A93F5F3117EEDE6C7316BD02942421F4889F

Step 2: Verifying the signature(s)

Now that you know what key you wish to verify with, the next step is to check the signature is valid.

Before you can proceed with this step, you must be sure your copy of the signer’s key is up to date. If you fail to do so, you may get a message about the key being expired. Run (again, use the actual fingerprint you want):

gpg --keyserver hkp://keyserver.ubuntu.com --refresh-key E463A93F5F3117EEDE6C7316BD02942421F4889F

Next, you will need two files (in addition to the program file you’re checking): the “.assert” file which contains a list of file fingerprints, and the “.assert.sig” file which contains the signature for that list. This is because instead of signing the program file itself, what we do is fingerprint all the files, and then sign that list. You will need both files.

• Bitcoin Core’s “assert” file pairs are published here: https://github.com/bitcoin-core/gitian.sigs/find/master
• Bitcoin Knots’s “assert” file pairs are published here: https://github.com/bitcoinknots/gitian.sigs/find/knots

Note that there is a separate file pair for each signer. If you are verifying that multiple people have signed your file (which you should), you will need to check each file pair. Also be sure you are getting the files for the version you intend to verify!

When you find the files you want on the list, open it in your browser by clicking the link, then right-click on the “Raw” or “Download” button and select “Save Link As”.

Once you have both “assert” files, you can then check the signature by running (adjust the file name to your specific .assert.sig):

gpg --verify bitcoin-core-linux-0.19-build.assert.sig

If this is successful, it will tell you:

gpg: Signature made Sun 19 Jan 2020 03:47:15 AM UTC 
gpg: using RSA key E463A93F5F3117EEDE6C7316BD02942421F4889F 
gpg: Good signature from “Luke Dashjr <luke@dashjr.org>” [ultimate] 

Notice the key fingerprint in bold. That must match the key you verified in step 1, or it may have been signed by someone else! The part about “Good signature” is also important, but the name and email address are not — if the fingerprint is wrong, those can both be faked.

Assuming all went well, you now know the “.assert” file is vouched for by the person who controls the key in question, and can proceed to verify that your actual program file is the one listed in that “.assert” file…

Step 3: Verifying the file itself

To verify your program file, you must first take a cryptographic hash of it (essentially taking its fingerprints). This is done with a simple command (substitute the actual filename you’re verifying!):

Linux: sha256sum bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz

Windows: certUtil -hashfile bitcoin-0.19.0.1.knots20200104-win64.zip SHA256

macOS: shasum -a 256 bitcoin-0.19.0.1.knots20200104-osx-unsigned.dmg

This will print something like:

d370692590c4546ac0de250da91c6c288d9ee5252f1a4b857a5b80c4e3d81149  bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz

This is the fingerprint of the file content, followed by the filename you specified.

Now open the “.assert” file in any plain text editor/viewer, and look for that fingerprint. It should be in the “out_manifest” section at the top— if you get as far as “in_manifest” or “base_manifests”, you’ve gone too far.

If you find it in the “.assert” file, then you’ve verified the file you have, is the same one the signer vouches for (you’ll see their filename in the “.assert” file to the right of the fingerprint — it will likely be the same as your filename).

If it’s missing in the “.assert” file, that can mean either you are using the wrong “.assert” file, or your file does not match (in which case, you will see a different fingerprint next to the expected filename). If the file is listed, but has a different fingerprint, please do not open your file, but instead save it (we may ask you for a copy later) and contact the security team of the affected project.

Lately some users have reported their antivirus software telling them that my personal domain and other domains* hosting the Bitcoin DNS seeds “contain malware”, are “suspected of a trojan”, and such.

This is probably true. These domains are specially designed so that they resolve not to a website, but to a random list of real peers on the Bitcoin P2P network. So it’s entirely possible — indeed, even probable — that some of these peers are running webservers hosting malware.

But your Bitcoin node should never access them as a website, only as an untrusted peer. And you shouldn’t be typing these domains into your web browser either — they’re not intended for that usage. Whatever you do, don’t download anything from them!

If your malware software is blocking your node from accessing them, should you whitelist/allow it? Nah, probably not. Your node should only even attempt to resolve these domains if it fails to find any other peers. If it’s working, you don’t need to use the DNS seeds, and might as well let your system block it. (On the other hand, if you’re having trouble with your node not getting online, feel free to allow access to the DNS seeds. Its usage is safe.)

* Affected domains include not only x9.dnsseed.bitcoin.dashjr.org, but also x9.seed.bitcoin.sipa.be, x9.dnsseed.bluematt.me, x9.seed.bitcoinstats.com, x9.seed.bitcoin.jonasschnelli.ch, x9.seed.btc.petertodd.org, x9.seed.bitcoin.sprovoost.nl, x9.dnsseed.emzy.de, and possibly others.

The vulnerability was introduced in 40b556d3742a1f65d67e2d4c760d0b13fe8be5b7 (“libevent-based http server”) and first released in Bitcoin Core v0.12.0rc1 in 2016 Jan 13. A fix was hidden in 79358817e53ac0a7afa64c747115d492a74e3155 (“rpc: Make HTTP RPC debug logging more informative”) released in v0.17.1, 2018 Dec 22.

Note that as of today, this fix has NOT been backported to older versions. When/if v0.16.4 is released, it may also include a fix, but due to the minor severity of this vulnerability, it does not merit a dedicated release on its own. (The 0.16 git branch is also NOT fixed at this time.)

To be vulnerable, the malicious software must either be running on the same machine as the node, have the ability to proxy connections to the node via the local machine, or the node must be configured to accept RPC connections from a network via which the attacker can connect. Additionally, a human user must read the debug log and act on or otherwise believe the injected data, in a way that is somehow harmful.

Because the node would log the arbitrary POST request from any connection, an attacker can add nearly any content to the request to inject it into the log. To ensure their entire request is injected, standard spaces would need to be replaced with alternative whitespace characters, and newlines would need to become other control characters (such as “\r\v”). Because the injected data must use such non-standard characters, it is most likely to not fool other software parsing the debug log, and only a human visually reading it.

To fix this vulnerability, POST requests are now sanitised before being logged, removing all characters that shouldn’t be in an ordinary POST request.

Credit goes to practicalswift (https://twitter.com/practicalswift) for discovering and fixing the vulnerability.

Timeline:
- 2015–01–18: Vulnerability introduced in PR #5677.
- 2015–09–04: Vulnerability merged to master git repository.
- 2016–01–13: Vulnerability published in v0.12.0rc1.
- 2016–02–18: Vulnerability released in v0.12.0.
…
- 2018–10–25: practicalswift discloses vulnerability to security team.
- 2018–10–31: practicalswift opens PR #14618 to quietly fix vulnerability.
- 2018–11–05: Fix merged to master git repository.
- 2018–11–30: Fix merged to 0.17 git repository.
- 2018–12–07: Fix published in v0.17.1rc1.
- 2018–12–22: Fix released in v0.17.1.
…
- 2019–06–22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019–11–22: Vulnerability details disclosure to bitcoin-dev ML.

The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5 (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27. A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 (“Improve and document SOCKS code”) released in v0.15.1, 2017 Nov 6.

To be vulnerable, the node must be configured to use such a malicious proxy in the first place. Note that using any proxy over an insecure network (such as the Internet) is potentially a vulnerability since the connection could be intercepted for such a purpose.

Upon a connection request from the node, the malicious proxy would respond with an acknowledgement of a different target domain name than the one requested. Normally this acknowledgement is entirely ignored, but if the length uses the high bit (ie, a length 128–255 inclusive), it will be interpreted by vulnerable versions as a negative number instead. When the negative number is passed to the recv() system call to read the domain name, it is converted back to an unsigned/positive number, but at a much wider size (typically 32-bit), resulting in an effectively infinite read into and beyond the 256-byte dummy stack buffer.

To fix this vulnerability, the dummy buffer was changed to an explicitly unsigned data type, avoiding the conversion to/from a negative number.

Credit goes to practicalswift (https://twitter.com/practicalswift) for discovering and providing the initial fix for the vulnerability, and Wladimir J. van der Laan for a disguised version of the fix as well as general cleanup to the at-risk code.

Timeline

- 2012–04–01: Vulnerability introduced in PR #1141.
- 2012–05–08: Vulnerability merged to master git repository.
- 2012–08–27: Vulnerability published in v0.7.0rc1.
- 2012–09–17: Vulnerability released in v0.7.0.
…
- 2017–09–21: practicalswift discloses vulnerability to security team.
- 2017–09–23: Wladimir opens PR #11397 to quietly fix vulnerability.
- 2017–09–27: Fix merged to master git repository.
- 2017–10–18: Fix merged to 0.15 git repository.
- 2017–11–04: Fix published in v0.15.1rc1.
- 2017–11–09: Fix released in v0.15.1.
…
- 2019–06–22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019–11–08: Vulnerability details disclosure to bitcoin-dev ML.

You may be affected by this issue if you have the RPC service enabled (default, with the headless bitcoind), and other users have access to run their own services on the same computer (either local or remote access). If you are the only user of the computer running your node, you are not affected. If you use the GUI but have not enabled the RPC service, you are not affected.

Generally, it is not recommended to trust a computer that other users have access to, so this vulnerability is considered low risk, and may not be fixed in Bitcoin Core at all.

Note that in all cases with multiple users, attempting to use the RPC service while your node is not running may create a security risk. While your node is not running, it can do nothing to prevent this. Always ensure your node is running before you attempt to access the RPC service! Note that making another RPC call is not sufficient to safely check that it is running. (This risk is not covered by the CVE, and indeed affects all software with RPC services, not just Bitcoin nodes.)

(Also, as a reminder, please note that the RPC service should never be exposed to any untrusted network or host. Do not set “rpcbind” or “rpcallowip” to anything other than “127.0.0.1” unless you are familiar with network security and aware of the potential consequences.)

Workarounds

There are multiple ways to eliminate the risk:

• Forbid usage of your computer by other people. This includes remote access. Securing access to login to the computer is outside the scope of this advisory.
• Forbid other users of your computer from binding to the RPC port on any network interface. (How to do this is non-trivial and outside the scope of this document.)
• Turn off the RPC service, and never attempt to use it. To do this, ensure that your bitcoin.conf file includes the line “server=0”. You can confirm it has been disabled, if the bitcoin-cli program fails to execute any command, saying “Could not connect to the server”.
• Before accessing the RPC service, check that your node’s debug.log does not contain any “Binding RPC on address … failed” lines.
• Configure your node to only bind a single RPC port. To do this, make sure your bitcoin.conf contains exactly one line beginning with “rpcbind=” and at least one line beginning with “rpcallowip=”. Generally, you want to ensure these are “rpcbind=127.0.0.1” and “rpcallowip=127.0.0.1” (any other values may fail to eliminate the danger). With this configuration, the software will refuse to start unless it successfully binds the appropriate port.

You can also upgrade to Bitcoin Knots 0.17.1.knots20181229 or newer, which has an experimental fix for this issue (but only while it is running, obviously). Since this fix has not been extensively tested, you should still mitigate the vulnerability with one of the above methods, or attempt to compromise your own node as described below (if you do test the exploit, please report whether Knots’ fix does or does not work on your system to luke_bcknots_cve2018_20587@dashjr.org).

Technical Details

By default, the RPC service attempts to bind and listen for connections on both IPv4 localhost and IPv6 localhost. So long as either of these succeeds, startup is considered successful, even if the other fails.

However, this means it is possible for another user on the system to quietly bind the IPv4 localhost port, and forward requests to the IPv6 localhost port, intercepting the request, response, and authentication credentials (including both the RPC server authentication, as well as any wallet password(s) if such wallets are unlocked in this way).

The other user can then use the credentials to make his own requests, including RPC calls that may compromise consensus, send the wallet’s bitcoins elsewhere, and so on.

Timeline

• 2018–12–10 Bui Thanh, on behalf of a team of security researchers from Aalto University and University of Helsinki, reports the issue to a number of Bitcoin Core developers.
• 2018–12–13 Upon further inquiry from Bui Thanh, Matt Corallo confirms receipt of original report, and reaffirms that users have always been advised not to expose the RPC service to untrusted networks/hosts.
• 2018–12–14 Bui Thanh recommends that Bitcoin Core should not silently ignore failures to bind RPC listening ports.
• 2018–12–15 Wladimir J. van der Laan submits pull request #14968 to fix the issue.
• 2018–12–28 Due to the fix proposed in #14968 breaking the RPC service working on IPv4-only systems, and no straightforward way to resolve both issues, the fix is deferred.
• 2018–12–30 A complex and experimental solution to fix both issues is released in Bitcoin Knots 0.17.1.knots20181229.
• 2018–12–30 The vulnerability is officially assigned CVE-2018–20587.
• 2019–01–15 Proposal to disclose vulnerability and mitigations shared with other involved parties.
• 2019–01–21 David Harding submits pull request #15223 to document the issue, along with other RPC service risks in general.
• 2019–01–21 PR #15223 documenting the issue is merged into Bitcoin Core.
• 2019–02–07 At the weekly Bitcoin Core meeting, the issue is discussed and ultimately it is decided that a dedicated advisory will not be published to bitcoincore.org.
• 2019–02–08 Advisory and full disclosure is posted to Luke Dashjr’s personal blog.

A number of months ago, the community decided to coordinate the activation of Segwit on August 1st, rather than continue delegation of this coordination to the miners, who had collectively been stalling the upgrade. This proposal was numbered BIP148, and widely supported by Bitcoin users. There was fear that 51% of miners might retaliate by splitting the blockchain, using invalid blocks light clients could not detect in order to solidify the split in perpetuity.

Why BIP148 is no longer relevant

Last week, miners finally decided to stop stalling Segwit, and have begun the activation process on their own, prior to BIP148’s August 1st flag day, and in a manner that is essentially embracing BIP148 themselves using a miner-activated method early. Therefore, BIP148’s new rule is redundant, since miners are already enforcing it as of Sunday. Users should still run BIP148 code to ensure they retain full node security, but the probability miners will attempt to split the chain in retaliation at this point is pretty much zero. Basically, BIP148 was an early success.

New altcoin launching August 1st, “Bitcoin Cash”

In the meantime, a new altcoin calling itself “Bitcoin Cash” has been formed, aiming to take advantage of the previous talk of an August 1st fork, to try to hijack Bitcoin users for their altcoin. By using the name “Bitcoin”, they may fraudulently fool people into switching to their new altcoin.

But at the end of the day, “Bitcoin Cash” (or, perhaps more accurately called, “Bitmain-coin”) is just yet another altcoin. It has no effect on the real Bitcoin network, and users who stick to Bitcoin Core and compatible full node software will be entirely unaffected.

Note also that this isn’t a particularly unique or even first-of-kind altcoin: “Bitcoin Dark” and “Bitcoin Plus” have tried to hijack the “Bitcoin” name previously. Bitmain-coin also gives a premine to all Bitcoin holders as of their launch date, but this too has been done before, by an altcoin called CLAMs and another more recent altcoin calling itself “Bitcore”.

However, there is a “gotcha”: At least the current Bitmain-coin code will use the original Bitcoin directories by default. This means if you wish to install or use Bitmain-coin yourself, it will mess up your Bitcoin installation! Using both together is outside the scope of this blog post, however, and I personally will only be supporting real Bitcoin.

At this point, probably almost everyone reading r/Bitcoin or using Twitter regularly knows about BIP148. Most of them have probably upgraded or even started their first node to support it. But what about people who don’t use these social media? Many people work hard all day at Bitcoin-unrelated jobs, and don’t want to spend the rest of their days thinking about their bitcoins. So the number one first thing everyone can do to help BIP148 is to talk to bitcoiners you know in the real world, and make sure they’re aware of and prepared for BIP148. Also consider spreading BIP148 awareness on any less popular social media you might use, such as Facebook or online poker sites.

Many people are already running a BIP148 node. But does this help? Not simply by running a node! A common misconception is that nodes are voting for BIP148, but this is not correct. Anyone can run any number of nodes, so this wouldn’t even be a good idea if it were possible. Rather, what matters is not that you’re running a node, but that you’re using it to receive transactions. This is what it means when people talk about economic nodes: nodes that people use for economic activity. So, if you use the wallet built-in to your Bitcoin Core+BIP148 node to receive your bitcoins, you’re doing your part to enforce BIP148. But if you use another wallet, you need to make sure you’ve configured it to actually use your own node. (How? It varies from wallet to wallet; if you can’t find instructions online, contact your wallet’s development team and ask!) If you use a wallet that can’t be configured to use your own node (including webwallets), be sure they’re either publicly committed to support BIP148, or withdraw your bitcoins before August.

This also means if you run more than one node, the others are not doing anything particularly useful. If you actually bought a bunch of Raspberry Pis to run nodes, not all is lost, however. You can sell or donate these to other bitcoiners who don’t have nodes yet, and help them setup and use their own BIP148 node. Even if you don’t have hardware to get rid of, you can still offer to help others who don’t have a node set one up!

Also of important note: make sure you’re actually running BIP148 for real. Early BIP148 proponents recommended simply setting a “uacomment” in your bitcoin.conf configuration file. This is not sufficient to support BIP148, and in fact leaves you just as vulnerable to attack as any other non-BIP148 node! To actually support BIP148 with your node, you must upgrade to a BIP148 build of Bitcoin Core. The best website to download this from is https://bitcoinuasf.org/ and you can install it just like any other update to Bitcoin Core (it will use your existing blockchain and wallet). You can verify your upgrade was successful by opening the “Help” menu, selecting “Debug window”, and checking that the “User Agent” line says exactly “/Satoshi:0.14.2/UASF-Segwit:0.3(BIP148)/”. If you use Bitcoin Knots rather than Core, it should say instead exactly “/Satoshi:0.14.2(+BIP148)/Knots:20170618/” (make sure it’s “+BIP148” and not “!BIP148” which means the opposite).

A lot of economic activity happens using exchanges. A good part of Bitcoin’s economy is offering services or goods for bitcoins, but at least as much of it is also buying and selling bitcoins for other currencies. Chances are, you’ve bought or sold bitcoins too. Contact your exchange(s) and ask them to upgrade to BIP148. If you want to strengthen your request, you can inform them that you will take your business elsewhere if they don’t. Keep asking them until they make a public statement of support. And most importantly, plan to switch to an exchange that supports BIP148 to buy any bitcoins after July — and be sure you don’t leave bitcoins on exchanges that might fail to upgrade in time.

The same also goes for merchants that accept bitcoins as payment. Make sure the people you do business with know about BIP148, and ideally publicly support it. You can also offer to patronise merchants [more] if they support BIP148. Keep in mind that many businesses don’t really accept bitcoins directly, but rather simply get fiat currency using a payment processor that accepts bitcoins. In those cases, you may need to focus on the payment processor rather than the business directly.

A final note: if we get to August and many miners are violating the new rule, there will likely be a campaign to try to get people to give up on BIP148 and downgrade to a miner-controlled network. Don’t give up. Even if there aren’t any miners, we can still move forward safely, but it may require upgrading nodes again (possibly with a change to the proof-of-work algorithm if necessary — don’t believe the FUD making this sound worse than it really is). As usual, be sure to check that trustworthy developers and/or community members have signed off on the update first. I will make a point to post on this Medium blog with advice in such circumstances. You can also follow me on Twitter https://twitter.com/LukeDashjr for updates more often (although I post about other things on Twitter too). Be sure anyone you’ve informed/helped with BIP148 is aware of this too!

I’ll start with the simplest part: branding. “Bitcoin Core 0.14.1” has become “btc1 Core 1.14.3”. Not much to say about this (although it’s interesting to note it’s based on the old 0.14.1 rather than 0.14.2 — which fixed a number of bugs including a miniupnpc vulnerability).

Next up is “testnet5". It’s a new testnet, for reasons never made clear to me. It would seem if you wanted to test a change to Bitcoin, you’d test it as a change to testnet rather than make a new one. It’s not clear to me why a new testnet was created instead.

There are a few policy changes that take effect immediately upon switching to btc1, even before any softfork or hardfork activates. Most notably, transactions are now allowed to use up to 32k sigops, rather than the 16k limit in Core.

Additionally, pools/miners connected to a btc1 node that claim to support Segwit2x will be told the size limit is 8 MB, and the sigop limit 160k. This last part is probably a bug (it should wait for the hardfork to activate), but in practice, it doesn’t matter since the actual block template given won’t overflow the limit, and I’m not aware of any miner that will actually add transactions up to the limit.

btc1 includes the now-well-known BIP91, which reduces the Segwit activation threshold to simply 80% for a few days on bit 4. It’s essentially the same as BIP148, but allows miners with 20% hashrate (ie, Bitmain) a veto.

Finally, we get to the actual hardfork. It does not actually use bit 4 at all, but activates 12960 blocks (90 days) after Segwit activates, no matter how Segwit is activated; this means that even if Bitmain blocks Segwit2x, btc1 nodes will still hardfork 90 days after BIP148 activates Segwit. (Clarification: A hardfork wouldn’t happen if Segwit never activated at all, but BIP148 is happening, so Segwit will definitely activate.)

As for the hardfork itself, it includes an 8 MB max block size limit (with the code obfuscated to make it look like 2 MB), a 160k max block sigop limit (obfuscated to look like 20k), and an 8M max block weight limit (ie, typical block size around 4 MB). To address the sighash scaling issue, a new 1 MB limit is imposed on each transaction’s non-witness data. To avoid being at risk of the original Bitcoin overwriting its chain in a reorganisation, the first block under the hardfork rules is required to have more than 1 MB of non-witness data (a better way to do this would have been to use the hardfork bit, which would prevent reorgs from affecting “SPV” light clients also).

Now for my thoughts: 4–8 MB block sizes are not sane. Even 1 MB blocks are already clearly dangerous to Bitcoin. I cannot foresee myself consenting to the hardfork proposal under almost any circumstances, except perhaps with a softfork to limit the size to something reasonable. Even then, I would still not positively support this proposal: if we are going to hardfork, we should actually make some useful changes in it (for example, native merge-mining, as Satoshi suggested as the first hardfork many years ago), not to mention fix some outstanding bugs (such as the time warp vulnerability). I am certainly not by far the only person with these concerns, so I can say with a relatively high level of confidence that Segwit2x’s hardfork will fail.

Overall, Segwit2x seems to have one real purpose*: to try to stall Segwit longer. It is a distraction from the upcoming BIP148 softfork, which is already irreversibly deployed to the network. By promoting BIP91 and Segwit2x as an alternative to BIP148, what miners are really doing is another power grab to try to take back their veto, which has no purpose other than to be used by Bitmain to block the whole thing at the last minute. If too little of the economy has upgraded to BIP148 in time for August, it gives Bitmain the opportunity to perform a chain split attack, and fool outdated nodes into following their invalid chain, possibly becoming financially dependent on it before realising the attack has occurred.

The only solution to this is to spread awareness of BIP148 and ensure as much of the economy as possible has upgraded before August. This is true whether or not you support Segwit2x’s hardfork — in fact, even if you oppose Segwit, you should still help ensure everyone is upgraded to BIP148. BIP148 does not prohibit Segwit2x, nor does it require you or anyone else (not even miners) to even support or use Segwit themselves. The only thing BIP148 requires, is that miners can no longer stop others from adopting Segwit, and with enough support, that miners cannot perform a chain split attack against old nodes without taking a financial loss. If Segwit2x participants are honest, there are no risks to running BIP148; if they are dishonest, then BIP148 is necessary to keep your node secure.

* Re: Segwit2x’s one real purpose… I don’t mean to imply that all the participants to the NYA have this goal in mind! But rather that the design of Segwit2x is such that it fits this purpose. Bitmain may very well have done this intentionally, but it seems unlikely anyone else intended it.

For purposes of reading clarity, “legacy” means nodes not enforcing BIP148.

Risks for both legacy and BIP148 nodes (and the wallets trusting them)

If and only if BIP148 has minority hashrate support, there will be a chain split. Whether your node supports BIP148 or not, there is a risk that your economic counterparties (ie, people you want to pay and people you want to pay you) will be on the other side of the split. So long as nobody double-spends, this should be mostly okay for 100 blocks (about 16 hours); the only difference will be that transactions might confirm at different times. But if 100 blocks pass and miners begin spending their newly mined bitcoins (different on each side of the split), the chains’ balances will begin to diverge, and transactions will become tied to one side or the other. There will be two “bitcoins”.

Risks only for BIP148 nodes

Hey, there are none! :)

Risks only for legacy nodes

If the chain splits, then when / if / every time the BIP148 chain gets longer*, it will replace the legacy chain. Transactions that had confirmed on the legacy chain will become unconfirmed (unless they are also confirmed on the BIP148 chain). Bitcoins mined by legacy miners will cease to exist, as they lose their blocks. (This cannot occur in the inverse direction: no matter how long the legacy chain gets, BIP148 nodes will never let it reorg out the BIP148 chain.)

If the chain splits, the BIP148 side will have Segwit activating, whereas the legacy side will remain stagnated. There is a possibility this will give a market bias in favour of the BIP148 side, even independently from its initial adoption.

* Note that even a minority-hashrate chain can get longer than the majority-hashrate chain with some variance, although this becomes less probable with time. (On the other hand, the longer the chain split goes on, the more likely the BIP148 side grows in hashrate relative to the legacy side.)

Avoiding a chain split (and all the risks above)

A chain split can be avoided entirely if a sufficient amount of the economy adopts BIP148. Miners depend on their minted bitcoins in order to pay electric costs and recoup ASIC R&D costs. If the price they can sell their legacy bitcoins drops too significantly (possibly to zero when/if their blocks get reorg’d out by the BIP148 chain), they will have no choice but to switch to the BIP148 chain themselves, ensuring it is the longest chain for both BIP148 and legacy nodes. If the economy shows strong enough deployment of BIP148 prior to August 1st, it is even possible miners may switch preemptively, avoiding a chain split from occurring altogether. Note that only 51% of miners need to switch to the BIP148 chain to resolve or prevent the chain split, not the original 95% target.

BIP148 can also be automatically cancelled entirely by locking in Segwit before August 1st.

So there are a few ways a persistent chain split might be avoided:

• 95% of hashrate locks-in segwit before August 1st. No chain split at all.
• 51% of hashrate deploys BIP148 before August 1st. No chain split at all.
• 51% of hashrate deploys BIP148 after August 1st. Chain split gets resolved.
• Legacy miners are compelled by the economy to switch to BIP148 after Aug 1st. Chain split gets resolved.

Basically, everyone’s risks go down with more people running BIP148 nodes. :)

Note: This is more people running BIP148 nodes, not merely people running more BIP148 nodes. Nodes only have significance when you’re using them to receive, so more than one or two per person is meaningless.