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

Bitcoin Gold is in the process of a mandatory Network Upgrade. Executing this upgrade requires a hard fork, but we anticipate a smooth upgrade with no chain splits (and no new coins created.)

We have successfully Upgraded the Testnet via hard fork. Our Partners and we are proceeding to finalize the necessary upgrades to related software and preparing for the upcoming Mainnet upgrade.

Our target date for the Mainnet Upgrade is sometime in the first week of July, depending on feedback from critical Partners in the Ecosystem. The actual target will be specified as a block height, not a date.

Technical Changes:

• Implement new PoW: Equihash-BTG
  • “Equihash-BTG” is Equihash<144,5> with BTG-specific Personalization
  • (Old PoW was “Equihash,” which is Equihash<200,9> with generic implementation)
  • See https://btgofficial.org/equihash-btg/ for more detail.
• Deliver improved Difficulty Adjustment Algorithm
  • New DAA is LWMA with optimized parameters
  • (Old DAA was Digishield v3 with inferior parameters)

Goals:

• ASIC resistance
  • Equihash-BTG is dramatically more ASIC-resistant than the generic Equihash, rendering the recently-available Equihash ASICs ineffective for mining BTG
  • Equihash-BTG will probably make future ASIC designs non-competitive for a significant period of time
• Safety
  • PoW & personalization changes create BTG-specific hashpower, and therefore a new “hashpower market segment” specific to BTG
  • BTG will be the dominant coin in the Equihash-BTG hashpower market, increasing security against 51% attacks
  • Although we expect Equihash-BTG rental markets to emerge quickly, they will be more transparent because there is only one practical use for Equihash-BTG hashpower. This means easier monitoring for potentially malicious activity.
• Consistency and Regularity
  • New DAA (Difficulty Adjustment Algorithm) delivers much better responsiveness to hashpower shifts (which happen due to changing market prices and hashpower market dynamics)
  • This will smooth out block times, reducing the incidence of “fast” and “slow” periods
  • Will also increase average profitability for “steady miners” of BTG

[table id=2 /]

Mining Software and Pools

The first few Equihash-BTG capable miners for NVidia cards are already available, and we expect AMD-based miners to be available soon. We will begin maintaining a list of known compatible mining software and expected mining pool availability on the Forum as details become publicly available from the 3rd parties who make and maintain them.

In Closing

We’re very happy with the cooperation we’re getting from many of our Partners in the Ecosystem, but also from the community of Equihash-based coin teams with which we’ve been collaborating these past weeks. We know some wish this Upgrade could be delivered sooner, but coordinating with all our Partners and ensuring the mining infrastructure is ready are crucial to minimize disruption – and, of course, critical for safety.

We look forward to sharing many additional details in the next few days!

Improving every day,
The Bitcoin Gold Organization
#1CPU1VOTE

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

Background

The key element here is the Bitcoin Gold blockchain, which is maintained by an independent network of thousands of computers doing calculations to process and secure transactions. Just like the Bitcoin and the Bitcoin Cash blockchains, the BTG blockchain is designed to produce blocks at an average interval of ten minutes, but the actual time to find any particular block is a random distribution, based on a “race” between those thousands of computers. A block might be found in two minutes, but might take twenty. It’s the average time that matters.

Our network’s block generation rate has been steady, finding new blocks as planned after the expected burst in the first 24 hours after MainNET Launch. After public mining began, the per-block Difficulty adjustment algorithm ratcheted up the Difficulty rapidly in response to a massive influx of mining hashpower, eventually stabilizing the average block find time at the target 600 seconds (ten minutes.)

Since then, the overall network Hashrate has been fluctuating significantly, as should be expected – the market for GPU hashpower is competitive, and responds rapidly to changes in market prices of multiple different cryptocurrencies. Our Difficulty adjustment algorithm quickly compensates for these conditions and has maintained an average time to find a block that is very close to the 600-second target.

Variability in Hashrate and the Difficulty Setting

It’s a mistake to focus on fluctuations in the actual Hashrate and the Difficulty: a varying Hashrate is entirely expected, and the changing Difficulty is designed specifically to compensate for the varying Hashrate. This is how the BTG blockchain produces a relatively constant block find time despite a fluctuating GPU hashpower market.

It’s important to recognize that changes in Difficulty are just a means to an end: what matters is the time to find blocks. It is explicitly because our Difficulty responds rapidly that none of the following problems have been occurring:

• a drop in block time, due to incoming hashpower, which happens when BTG price rises or prices fall
• an increase in block time, due to outgoing hashpower, which happens when BTG price falls or other prices rise
• any dramatic change in block times when a significant amount of hashpower enters or leaves, whether based on whim or malicious intent

We’re pleased that our adjustment algorithm (a variant of Digishield V3) has been so efficient. Some might recall that we adjusted the algorithm during the Testnet period in early November. We considered it critical to get the adjustment algorithm working right – not to do so would be careless and could be harmful to other coins in the ecosystem. Bitcoin Gold always strives to be a Friendly Fork, so we’re pleased to have had no adverse impact on our predecessor coin, Bitcoin.

We’ve also become aware that some people have the mistaken notion that our block times are not stable because, quite frankly, they’ve seen some new charts they’re not familiar with! Traditional blockchain explorers graph the average time per day for Bitcoin and for Bitcoin Cash (one day is roughly 144 blocks), but some of the new explorers for Bitcoin Gold are reporting the find time per block. This new reporting made sense – after all, the Bitcoin system only adjusts the Difficulty once every 2016 blocks (about two weeks), so showing the daily average is fine. The Bitcoin Cash system added an EDA (Emergency Difficulty Adjustment) to compensate for fluctuations but was still based on a two-week adjustment. It was only after Bitcoin Gold came along with a per-block adjustment that it made sense to start reporting on a per-block basis.

These two different views – per day averages versus per block reporting – make for very different pictures, and you just can’t compare them. If we compare these three chains directly, using the same method for all, we’ll see that Bitcoin Gold does well.

Some Hard Data: Scatter Plots

Here are three scatter plots – The first is original Bitcoin, the second is Bitcoin Cash, and the third is Bitcoin Gold. All three chains have a target Difficulty of 10 minutes (600 seconds), and all three have the same timescales. Each dot represents the time to find one particular block, and the black line shows a 72-block moving average. (With a ten-minute target, 72 blocks should be about 12 hours.)

(Note: the vertical scale is limited to 1200 seconds to make fluctuations in the average block time clear. All three blockchains have significant numbers of outliers well above 1200 seconds which are not shown here, but they are included in the averages.)

These plots of the block times and line graphs of the average time show that Bitcoin, Bitcoin Cash, and Bitcoin Gold are all exhibiting typical variability, but their averages are hovering around the 600-second target. Bitcoin is a touch more stable than the other two coins; this is likely a natural result of the fact the Bitcoin usually has more miners working on it than the other two currencies.

Although we’ve been stable for these two weeks, some people might ask why we don’t show the entire period since launch. It’s a fair question. There are two reasons: firstly, we had a very rapid series of blocks in our first day, both from establishing the Endowment and from the ramp-up afterward as massive new distributed hashpower came into our network. (Remember that we were not a live split at fork time which would capture a share of existing Bitcoin hashpower – our new network stood up from scratch, so after Launch, it needed to start from zero.) So it took a little time for our blockchain to stabilize.

The second reason: a few hours after our launch, on November 13th, Bitcoin Cash performed a hard fork to modify their Difficulty adjustment algorithm, and their network also needed time to stabilize. Using the first few days of our launch would not be fair to either Bitcoin Cash or to Bitcoin Gold.

In the end, we feel that these two weeks paint a fair picture of the current state of all three of these blockchains. However, to be comprehensive and transparent, we’re also publishing two more scatter plots covering earlier periods.

The second plot shows the time of our Launch, along with the ten days before and the ten days after, for 21 days, total. The vertical scale (seconds) has been increased to capture the broader fluctuation range of the 12-hour moving average in this period.

Above, you can see that the Bitcoin Gold blockchain started with a low Difficulty, and rapid blocks, followed by a quick rise as the system brought the network towards a 10-minute average despite a massive influx of hashpower after pools pointed their miners at the network.

Lastly, to help show the “big picture,” this last chart shows the entire lifespan of Bitcoin Gold, starting one week before the fork (the gold-colored point in the Bitcoin plot on October 24th is the forked block), and running all the way through December 6th.

Again, the vertical scale has been adjusted to account for higher peaks on moving averages.

The raw data for these scatter plots is publicly available, becasue each blockchain contains the timestamps. They are available here as a CSV for convenience for those who would like them – and please let us know if you have questions or comments.

We hope this helps clarify any misunderstandings and makes quite clear that the Bitcoin Gold Blockchain is Stable, and has been a Friendly Fork.

Thanks for reading!

Sincerely,
The Bitcoin Gold Community
#1CPU1Vote

We take the opportunity of this update to inform you of the latest news of BTG network tests and to invite all of the miners that are planning to participate in this project to test their machines in the Bitcoin Gold test blockchain.

The Bitcoin Gold testnet is proving the stability and security of the network, including the new difficulty adjustment algorithm and two-way replay protection, and is helping wallets, pools, and application developers to integrate BTG and fully prepare for the imminent mainnet launch.

What’s a testnet?

A testnet is a temporary blockchain used for testing the network. Testnet coins are useless and distinct from real Bitcoin or Bitcoin Gold (they are never supposed to have any real value). A testnet allows application developers and security researchers to perform experiments without having to risk losing real money or worry about breaking the main blockchain. https://en.bitcoin.it/wiki/Testnet

Who should use the testnet?

The Bitcoin Gold testnet can be useful for people who want to test the p2p network and consensus rules before the launch of the mainnet. Some of the more common uses of the testnet are for:

• Pool operators: Test the setup and the integration of Bitcoin Gold into their mining pools and test end-to-end CPU/GPU mining.
• Wallet developers: Test the integration of Bitcoin Gold into their software or hardware wallets.
• Exchanges: Test on-chain transactions.
• Pro users: Test security features like replay protection.

Track the process of testnet.

Click here for full technical info about testnet.

Bitcoin Gold team.

We are excited about the way the testnet is working.

On the second day we have applied changes about the starting difficulty, some more minor settings and restarted the network. Currently we have 57 operating nodes and more than 200 mined blocks. The network is stable and all of the transactions are executed.

Changes required:

• Currently we are not experiencing any issues of the network. We see that the difficulty is dynamically adjusted and the block time is between 3 minutes and 24 minutes.

Next steps:

• We are in touch with major exchanges and wallet providers that have asked for the replay protection and the unique address format in order to support us, follow their statements and start working on integration with Bitcoin Gold. So all the users can receive their funds without any problems.
• We will start planning the release of the main network very soon and will come up with release date as soon as we are ready to announce it.
• Go to previous BTG Daily Update to check our complete timeline.

We take advantage of the opportunity to thank to users, pools operators, wallets and exchanges that are helping with the development and the testnet progress.  

All the received help is highly appreciated! Thanks for all of the support!

Bitcoin Gold community.