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. …

CVE-2018–20586 is a log injection vulnerability which allows any software with access to the RPC port to create fake or confusing entries in the debug log. Valid authentication (username/password/cookie) for the RPC service is NOT required to exploit this vulnerability, only the ability to connect to the RPC port (which is by default only exposed to the local machine).

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…

CVE-2017–18350 is a buffer overflow vulnerability which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed `char` type (including common 32-bit and 64-bit x86 PCs).

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. …

CVE-2018–20587 is an Incorrect Access Control vulnerability that affects all currently released versions of Bitcoin Core, including the latest 0.17.1 (and probably future releases too), as well as Bitcoin Knots prior to 0.17.1.knots20181229.

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. …

What was going to happen (BIP148)

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. …

Over the last several weeks, I’ve seen a lot of people promoting BIP148/UASF on social media. Just the other day, someone announced they’d purchased numerous Raspberry Pis to run BIP148 full nodes. However, do these things really help BIP148? Not really.

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. …

The changes in Segwit2x’s beta can be divided into 5 categories.

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. …

BIP148 is happening beginning on August 1st, 2017. But what does that mean for the average user?

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. …