As you may be aware, Bitcoin Gold has a Responsible Disclosure policy listed on the website, which is basically a (bug) bounty program for reporting security vulnerabilities in our stable software versions or infrastructure.

It allows people to safely report an issue to us, and if they follow the rules set out in the Responsible Disclosure policy, we will not take any legal action against them in regard to the report (hacking is still illegal).

The Report

Through the end of March, we received only false reports of “non-existing” issues, which we rejected. However, we recently received the first report which our SYSOPS and CERT team could accept. Although the security issue was very minor, we acted on it directly.

It was a DLL vulnerability that affects Bitcoin and all coins that use Bitcoin’s installer methods (including BTG.) We used the fix in our recent Network Upgrade and shared it for the rest of the community’s benefit.

Timeline:

You might have noticed there was a sizable time span between the report and the fix. That is correct: it takes time to build a fix, especially if the issue stems from a third party module and your entire build process is wrapped around it. It took a long time to test, build, and test again before we could implement the fix as a replacement for our current build process.

The Fix

The specific issue addressed by the bug was as follows: Bitcoin Gold uses the NSIS Installer module, which basically wraps our code into a nice install package for people. Our code uses the v2.46 NSIS installer module, the same as in the Bitcoin source. This outdated code had a bug in LoadLibrary: by default, it looks in the current directory of the process and into the Folder of the Executable. This is bad (especially in common use case when users execute our installer from the downloads folder) because an attacker is able to drop a DLL into the Folder of the Executable and give themselves high privileges. To try it out, just place a fake shfolder.dll (which brings up a message box in its DllMain) in the same directory as an NSIS installer and run the installer to see the message box appear. This bug has recently been found in many products and is called ‘.DLL sideloading’ or ‘.DLL hijacking’. Only Windows 7 and very old builds of Windows 8 are vulnerable. An updated Windows 8.1 or any Windows 10 system is not vulnerable.

Although the fix may appear easy (just install the new version 3.03 NSIS installer module!), it is, unfortunately, not that simple. With deterministic builds, we have to make sure the installer matches our code, which involves a lot of trial and error. Also, with our upcoming Upgrade hardfork and another update in the code, all updates needed to be added into the latest releases (as they are mandatory upgrades.)

Our developers did the careful work necessary to implement the new module into the existing build process before our next release. Any developer that is interested in how we resolved the issue can find our fix on our GitHub repo code commit, Switch to NSIS 3.03 (borrowed some code from TOR project).

The (low) Risk

To be clear, your system had to be compromised in advance for the attacker to have used this vulnerability. The installer software was not compromised, nor was our code modified or hacked. An attacker had to download a malicious .DLL file and put it in the same folder where you downloaded and run the installer. The Bitcoin Gold code, daemon and cli are not affected, nor is any Linux or Windows system (8/10) that is up-to-date. Even if you are running Windows 7, it’s unlikely that an attacker would have been able to download a malicious .DLL file into the right folder at the same moment as you launched the installer. And users would only install a (new) version once on their system.

Our recommendation: remove any and all previously downloaded installers and only use the latest version from our website or Git repository.

Because this fix was implemented well before our recent Network Upgrade on July 3rd, everyone who downloaded our software or code in preparation for the Upgrade was safe from this vulnerability.

It’s important to note that this issue is not specific to Bitcoin Gold: it can affect any coin that uses Bitcoin’s code as a basis. Some repositories, including Bitcoin itself, are currently vulnerable to this issue.

To ensure awareness of the issues and the fix, we submitted our work to the Bitcoin code repository in this Pull Request: Switch to NSIS 3.03 to avoid DLL hijacking.

Credits

The BTG team would like to thank the original Reporter (Shah from FortiGuard Labs), the TOR Project (where helpful code was sourced), and we’d like to call out the efforts of our SYSOPS and DEV teams, who managed the issue and the resolution for us. We’re happy to be able to contribute back to the Bitcoin project and provide a fix which can potentially be used by multiple projects which rely on the Bitcoin codebase.

Supporting the ecosystem,
The Bitcoin Gold Organization
#1CPU1VOTE

The BTG blockchain has been performing wonderfully since the successful Network Upgrade last week. If you’re using our ElectrumG wallet, make sure you update to the latest version, published last week:

ElectrumG 3.2.1

ElectrumG 3.2.1 is a stable release and is fully compatible with the recently Upgraded Bitcoin Gold Network.

What is ElectrumG?

ElectrumG is our version of the popular Electrum Bitcoin Wallet, modified for BTG. It’s is a full-featured wallet that’s easy to use for beginners but provides many advanced features – including invoices, multisig wallets, cold storage, and a rich set of functionality for advanced users and developers.

Most importantly, ElectrumG is very quick to load and very lightweight, consuming a lot less disk space than a full node wallet.

How’s it so Lightweight?

Unlike a “full node” wallet, ElectrumG on your computer doesn’t validate every BTG transaction and maintain a full copy of the BTG blockchain, so it doesn’t need hundreds of gigabytes of space on your computer. Instead, it relies on lightweight block headers and uses SPV (Simplified Payment Verification, as described in the Bitcoin Whitepaper) to verify payments. Like any SPV wallet, ElectrumG relies on ElectrumX servers for some functions, such as receiving new block headers, or broadcasting new payments after they are signed – but the private keys used to sign those transactions never leave your computer. You remain in complete control of your private keys.

Production vs Beta

The current production version, ElectrumG 3.2.1, was released just before the Network Upgrade hardfork. The wallet and back-end ElectrumX servers were upgraded to remain functional after the fork. This version does not include support for hardware wallets, which will be added in an upcoming Beta. (Hardware wallet support was initially planned for the 3.2.1 release, but needed to be delayed in favor of rolling out support for the Network Upgrade.)

Free and Open Source!

ElectrumG will continue to be free and open-source, with ongoing development and support provided by the Bitcoin Gold Organization. (See the full source code on GitHub.)

The Bitcoin Gold Organization also hosts and maintains a globally distributed set of ElectrumX servers, which were upgraded for the Network Upgrade.

We’d like to thank Spesmilo (Electrum) and Kyuupichan (ElectrumX) for their hard work on the Electrum projects over the years, as well everyone else in the Open Source Community that has contributed to the creation and growth of projects like these.

We’ll continue to work hard to provide the kind of software users want, the services developers need, and to continue expanding and supporting the Bitcoin Gold Ecosystem.

Working hard and making progress,
The Bitcoin Gold Organization
#1CPU1VOTE

Where do I get it?

ElectrumG 3.2.1

Please report Issues on GitHub or the Forum.

Feature List

Beyond a pleasant interface, ElectrumG provides users with a full suite of functions:

• seed recovery phrases, a secure system which is more user-friendly than hexadecimal codes
• wallet encryption
• multi-signature wallets, for cases where control of funds needs to be distributed
• easy import of Bitcoin address or private keys
• cold storage – the ability to create and sign raw transactions offline and then broadcast
• invoicing functionality

In the near future, ElectrumG will also include:

• hardware wallet connectivity, so you can use ElectrumG while keeping your private keys on a hardware wallet like Trezor, Ledger, or KeepKey

For developers, ElectrumG provides:

• a powerful command line interface
• ability to use cold storage with the command line
• a GUI Python console
• an ElectrumG daemon for scripted uses, such the ability to accept BTG on a website with signed payment requests

Our current mining algorithm, Equihash, is used by many different coins without any personalization. It was originally developed by Zcash and based on the parameter set <200,9>. We are going to upgrade to Equihash with a the parameter set <144,5>, with some customization. We’ll call it “Equihash-BTG,” for now. This will keep our blockchain ASIC-resistant and add an immediate measure of safety from 51% attacks.

About Equihash

Equihash, which was first developed and used by Zcash, was designed from the outset to be an “ASIC-resistant” Proof of Work algorithm. The developers set out to accomplish this by making it a memory-hard algorithm. (See the Biryukov and Khovratovich paper on Equihash.) What does this mean, how does it make mining ASIC-resistant?

A memory-hard algorithm is one which requires a lot of memory to be able to run. It simply won’t work on hardware that doesn’t have enough memory.

When making an ASIC – an Application-Specific Integrated Circuit – adding memory is very expensive, and the more memory you need, the more expensive it gets. With a high enough memory requirement, building a “single-chip solver” on an ASIC becomes so expensive that you could not hope to earn enough in mining to pay for the ASIC. It’s impossible to profit.

Equihash was engineered to make that to happen – it can be configured to need a lot of memory as a minimum requirement to run, and it needs several times that much to run efficiently. (If you use half the ideal amount of memory, it can be 1000 times slower.)

Exactly how much memory is required? That depends on a couple of parameters.

The current Equihash: <200,9>

Equihash is the name for the general algorithm, but the exact implementation depends on two parameters, < n, k >. Today’s common Equihash coins run on Equihash <200,9>, so n = 200 and k = 9. This setup is currently used interchangeably by Bitcoin Gold, Zcash, Zencash, and many other Equihash-based cryptos.

This <200,9> version of Equihash requires a minimum of 50 MB of memory but can run much faster with 144 MB of memory. This was not the most demanding (most memory-hard) version of Equihash considered at the time, but it appeared to be “good enough.” These memory requirements were previously sufficient to prevent building an ASIC, based on the comparison of ASIC cost to coin value a year or two ago. Since then, Zcash – which was worth $30 in Feb of 2017 – has grown to be worth over $250, and now there are multiple coins that can be mined with the same Equihash. Meanwhile, the cost of transistors in an ASIC has gone down.

With these changes, it became possible to build an ASIC that can work with just enough memory to profitably mine the current Equihash coins – and this is precisely what has come to pass. But this doesn’t mean that Equihash is defeated – just that Equihash <200,9>.

Equihash-BTG: <144,5>

We’ll be adopting different parameters, <144,5>, for Equihash-BTG. Although these numbers are smaller than <200,9>, it means the algorithm actually requires dramatically more memory to run – so much more that we believe ASICs will be impossibly unprofitable for quite some time. The <144,5> parameters require a minimum of 700 MB to run and use about 2.5 GB to run efficiently (that’s 17 times larger!) This should be too expensive to produce with an ASIC right now, while most graphics cards used by our miners already have that much memory or more.

We’ve seen the innards of the Z9 Equihash miner, and we’re no longer concerned that it might be able to mine Equihash-BTG effectively. We’ve tested the new algorithm with typical graphics cards and have confirmed that they can run the new algorithm with as little as 3GB of RAM (although it can be a bit tricky under Windows if trying to mine while still using the computer.)

The sheer amount of memory required for Equihash-BTG pretty much forces the use of DRAM, which calls for a dramatically different design than a single-chip solver for regular Equihash. Even if a specialty miner is developed for Equihash-BTG in the future, it will not have as dramatic an advantage over a GPU as the specialty Equihash <200,9> miners. This significantly decreases the threat ASICs can pose to our network. While we know that this parameter change is not a permanent fix – this one change won’t stop ASICs forever – we know it will solve the ASIC-resistance problem for now, and gives us time to consider other alternatives for the longer term, if necessary.

The new parameters in Equihash-BTG also provide a few other advantages over <200,9>, which you can read about in our more detailed Forum post about Equihash-BTG.

Enhanced Safety

The new algorithm doesn’t just protect us from ASIC miners – it moves us into a different “pool” of hashpower, which also gives us a measure of safety against the kind of 51% attacks against Exchanges that happened over three or four days this past May.

Why does the new algorithm make us safer? It has to do with the size of the pool of hashpower available as Equihash. The total supply of power is large because it’s currently used interchangeably by multiple coins, and some of those coins produce new coins quite liberally – they generate a lot of miner rewards, which attracts a lot of hashpower, making the total pool very big. Though the share of power available for rental may be a small fraction of the total power for all coins, it can be a large share compared to individual coins, such as Bitcoin Gold. When the power available to rent on demand is larger than the power mining our coin, our chain is potentially at risk of attack (if someone has the financial means to rent all of that hashpower while simultaneously having the resources to make an enormous double-spend attempt against an exchange.)

Because Equihash-BTG is different from the existing pool of regular Equihash power, we’ll effectively be in a separate pool of power. This means BTG will dominate the hashrate on this new PoW algorithm, which is “personalized” to BTG, adding a layer of incompatibility versus other coins that will be moving to the <144,5> parameter set, such as BTCZ (we’ve been collaborating with many other coin teams in the space.)

Timing and Future Updates

While we’re very close to being able to provide Release Candidate versions of all the software to the public, we still aren’t ready to commit to a specific fork date. We’ll begin releasing detailed information about progress with the code and timing to all of our partners in the coming days to assist them in preparations. Because this kind of Network Upgrade will be enacted via Hard Fork, we need to be sure our partners are prepared. (A Hard Fork does not mean there will be a new coin – it just means that the prior software won’t be compatible, so the Upgrade is not optional.) Our ecosystem includes dozens of partners, including mining pools, miners, the makers of mining software, blockchain explorers, wallet hardware and software providers, third-party merchant services, and over fifty exchanges! We’re doing our utmost to ensure that everyone in our community has the opportunity to prepare so that nobody is left behind when the time of the Upgrade comes.

Working towards a better future,
The Bitcoin Gold Organization
#1CPU1VOTE

References:

• Biryukov and Khovratovich paper: Equihash: Asymmetric Proof-of-Work Based on the Generalized Birthday Problem
• Blog Post: A Response to the ASIC Threat
• Forum Post: Our “New” Equihash: Equihash-BTG
• Blog Post: Responding to Attacks

Additional reference for 3rd-party miner developers:

• BTG Mining Tools GitHub Repository

New PoW Algorithm

One important change goes a long way to address both of these issues: a change in our Proof of Work algorithm. We’ll be moving our mining algorithm to a different version of Equihash that we’re calling Equihash-BTG, for now. You can read more detail about it on our Forum.

Most of the necessary components for the Network Upgrade have been coded, but need more thorough testing. We are still working on improving the mining software so that as many people as possible are free to mine as soon as the Network Upgrade happens. Until the mining software was ready, we weren’t able to thoroughly test the new components on a testnet. We’re now making good progress and expect to be able to establish a firmer timeline for the Upgrade shortly, which we intend to share in another update three days from now.

Testing and Go-Live Preparations

Please note that we will be providing at least seven days’ notice before the Network Upgrade, and perhaps more, depending on what we hear from our critical ecosystem partners. We want this upgrade up and running as soon as possible, but it doesn’t do any good if we upgrade the software before the wallets, mining pools, exchanges, and others are ready. It’s imperative that any of our partners who haven’t yet done so reach out to us to ensure we have the best methods to contact them with further information. (You can reach out to us via support email, or any of our social media channels.) We’ll also be posting detailed information on our Forum and in GitHub.

Attention to Security and Community

We’re also working hard on many fronts to improve security, both now and in the future. We’ve developed monitoring systems for our blockchain and our mining network, and have established channels to rapidly communicate risks to Exchanges. We plan to expand these tools and make them available to others. We’re also cooperating closely with other coin development teams to share what we’ve learned, and to work together to improve the safety of the crypto space. The recent Double Spend attacks using ZenCash remind us that we’re not out of the woods, yet.

We’ve said before that attacks on part of the ecosystem are attacks on us all. It’s also true that if we all work together, we can fight back against these attacks. We can report that the crypto community is coming together and will be supporting each other as we work to get through these difficult times as quickly as possible.

Earnestly yours,
The Bitcoin Gold Organization

Linked References:

• https://btgofficial.org/a-response-to-the-asic-threat
• https://btgofficial.org/responding-to-attacks
• https://forum.btgofficial.org/t/our-new-equihash-equihash-btg/1512
• https://forum.btgofficial.org/t/action-items-to-prevent-future-attacks/1447
• https://blog.zencash.com/zencash-statement-on-double-spend-attack

We want you to know what’s going on, what we’re doing, and what’s going to happen next.

Background

As anyone watching our Twitter or Forum posts was aware, there have been recent “51% Attacks” done using the Bitcoin Gold blockchain over a span of about three and a half days in May to attack Exchanges with something called a “Double Spend.”

This is not due to some flaw in blockchain technology; any blockchain – even Bitcoin – can theoretically be attacked by a malicious actor who can control more hashing (computing) power than all the honest miners. Of course, the biggest risk is to a smaller network in the shadow of a bigger one. Bitcoin has an order of magnitude more hashpower than some other coins mined with the same SHA256 algorithm, like Bitcoin Cash and Digibyte, so Bitcoin is relatively safe. Likewise, Zcash has an order of magnitude more hashpower than other coins mined with Equihash, like Bitcoin Gold, ZenCash, and Komodo, so Zcash is relatively safe.

So, why target us, and not another Equihash-based coin? Frankly, it’s likely because we are on more large Exchanges, with significant liquidity and fairly deep order books – these are necessary for an attacker to be able to profit from such an attack. And, as news reports show, we’re neither the first nor the last coin to be attacked this May.

Risks

Ordinary users aren’t at risk, funds held as BTG aren’t at risk, and any trades with known partners aren’t a risk, either. The only real danger is to anyone who unknowingly trades directly with the attackers for very large sums on an automated system. In other words, Exchanges.

The power to perform such an attack is expensive – the attackers need to control a huge wave of mining power. So mounting an attack is costly and, if it fails, will lose money. Attempting such attacks to steal $100 or $1000 can’t be profitable, but attacks for much larger dollar values will tempt criminals to attack Exchanges, and so they did. You can read more about how a Double-Spend attack works here.

While this problem isn’t unique to Bitcoin Gold and doesn’t represent a flaw, we consider our Exchanges to be critical partners in our Ecosystem, so in a theoretical sense, attacks on Exchanges are attacks on us all. And even when the attacker fails to steal BTC or some other currency from an Exchange after their double-spend, their 51% attack causes a “reorganization” on the blockchain, which is disruptive to honest users and steals mining revenue from honest miners… this means they literally are an attack on us all.

We can see how many attacks were made, but we can’t tell how many were fully successful against the Exchanges, nor can we be certain which Exchanges were attacked.

Response

To help them protect themselves, we’re monitoring the situation carefully in a variety of ways to rapidly alert the Exchanges when we can tell an attack is in progress. (The last known attempt was on May 19th.) This is why many Exchanges dramatically increased their confirmation requirements, or else closed their deposit wallets entirely. Of course, we need to be in close contact to be able to alert them promptly – any Exchange that has not yet joined our emergency communications channels should reach out to the team immediately!

Most of you also know that we were already planning a major upgrade soon, near the end of June. This was to change our Proof of Work algorithm so that BTG could not be mined on upcoming ASIC hardware – we expect ASIC hardware to ship from Bitmain around then, potentially delivering a huge wave of mining power, and we don’t want that to impact our existing miners.

This algorithm change has a second effect. Right now, we share our Proof of Work algorithm (Equihash) with many other coins, so collectively, the pool of Equihash power out there is much bigger than our individual network’s hashpower. But when we change our Proof of Work, we’ll be on a different algo which doesn’t have such a large amount of power out there which some entity could try to control. This means our blockchain will become dramatically safer from a 51% attack immediately when we fork to the new network… and which is why we’ve moved up the date to be As Soon As Possible.

Network Upgrade with new Proof of Work

We’ve been working at an incredible pace the past days to put the plan and pieces together, and we expect to upgrade our mainnet approximately seven days after the necessary software is up and running on our testnet. This upgrade will require some software updates on the part of Exchanges, Wallets, Pools, Explorers… While it would be better to give all our partners more than seven days to test and deploy to avoid disruption, these attacks have already forced disruption on us all, so we feel it’s best to get the upgrade completed as soon as we possibly can.

We’ll provide another update with a progress report on the testnet status within another three days, or sooner if it’s ready; we aim to be able to give a firm date for the actual mainnet upgrade at that time.

The Community considers these attacks on Exchanges to be attacks on us all, but we and our Community are resilient and remain dedicated to decentralized solutions.

We’re encouraged by and grateful for the responses and support we’ve been receiving from our Community, as well as the communities of other coin developers we’ve been in touch with, the developers of mining software, and even academics and industry researchers who work in hardware – it’s heartwarming to receive encouragement and advice from so many of you, and we deeply appreciate it. Thank you, all. We know that many are looking to us to lead the way, and it’s our intention to serve as an example to other projects in the community that are dealing with these sorts of malicious attacks from centralized mining power. In the end, decentralization is the answer.

We’ll continue working hard to get this out as soon as we can.

Sincerely,
The Bitcoin Gold Organization