Skip to content

PoW hardfork network upgrade spec and guide #331

@h4x3rotab

Description

@h4x3rotab

(This issue will be converted to a Wiki page when the content is fixed)

0. This hardfork network upgrade will not create a new coin

1. Changes

  1. Fork height: 536200 (accomplished via successful hardfork on July 3rd, 2018, at 9:59:26 PM UTC)
  2. Switch to Equihash-BTG
  3. Difficulty adjustment: Testnet hardfork upgrade #330
    • At the fork height, the difficulty will be reduced to 1/100th
    • Subsequent per-block Difficulty adjustments will be made via the LWMA difficulty adjustment algorithm.

2. Run a new full node

Anyone running full node should upgrade to the latest version v0.15.1, which can be compiled from 0.15 branch:
https://github.com/BTCGPU/BTCGPU/tree/0.15

Precompiled binaries (v0.15.1):
https://github.com/BTCGPU/BTCGPU/releases/tag/v0.15.1

If you are running it on the mainnet or the testnet-v3 (learn more), the in-place upgrade should be ok. If you are running on the old testnet, you need to clean up the testnet datadir first.

3. Upgrade guide for pool operators

You will need to upgrade the full node as well as the pool software. The full node can be updated in-place. Details on updating pool software follow below. Please don't hesitate to reach out to us for help:

Why do we need to upgrade the pool software?

The change in PoW algorithm means that both the validation function and solution size will be different, and the block header size has changed. Old pools won't support the new blocks.

Is there any working pool software?

We have a reference implementation of z-nomp for the fork:
https://github.com/BitcoinGold-mining/z-nomp-bitcoin-gold

Please carefully test it before using it on production and run it at your own risk. The BTG Org can't take any responsibility for losses potentially caused by running the reference pool.

What if we want to change our own pool?

Please change the following components and check commits of the reference z-nomp:

  • Block header handling: solution size is now 100 vs. the original 1344 bytes. (Don't forget the leading encoded length before the solution is also changed)
  • PoW validation

There are a few useful tools for pool development in this GitHub project:
https://github.com/BitcoinGold-mining

How to test the pool?

You can run your pool on the BTG testnet, which has already forked to the new code. Then you can connect any working miner to the pool. (nheqminer and EWBF currently work, and more are being announced by their developers.)

The naive nheqminer on a typical GPU finds ~2.5 Sol/s while EWBF can be 10x more efficient. EWBF Cuda Equihash Miner v0.2 should work with the following parameters: --algo 144_5 --pers BgoldPoW.

Upgrade procedure

We suggest running a new pool for the upgraded chain. Unlike Monero, it's difficult to do an in-place pool upgrade because Equihash-BTG (144,5) is very different than the original Equihash (200,9). The recommended procedure is:

  1. Replace the full node with v0.15.1 (or the latest master branch)
  2. Launch a new pool for upgraded chain
  3. Ask miners to download the new miner software
  4. Miners can keep mining on their current pool before the fork
  5. When it reaches the fork height, stop the old pool and turn on the new pool
    • The old pool won't find any more valid blocks because the full node will reject Equihash (200,9) blocks.
  6. Miners turn off the old software and turn on the new software

4. Upgrade guide for miners

Please follow the guide from your pool if they provide one. You should know the information below:

  1. NV miners: EWBF, see above for details (the list is growing)
  2. AMD miners: lolMiner, ...
  3. It's likely that you will need to watch the blockchain and switch your miners manually when it reaches the fork height.
  4. There's an intentional difficulty discount at the time of the fork which should make it temporarily extra-profitable to mine.

The difficulty will be reduced to 1/100th of what it was before. This is partly to compensate for the new PoW being much harder, and partly to compensate for the possibility that some miners or pools are slow to upgrade. This will reduce the likelihood of a slow-block start, but means that mining immediately after the fork will temporarily be extra-profitable until the DAA adjusts the Difficulty and hashrates stabilize.

Before the hardfork upgrade:

  1. Make sure your pool will support BTG hardfork network upgrade
  2. Install the new miner software
  3. Config and test the miner on a testnet pool, either from your usual pool or our official testnet pool: https://test-pool.bitcoingold.org (Backup: http://test-pool.btcgpu.org, http://btg-testnet.miningspot.net/)
  4. Wait for the hardfork block height 536200

Where to check the block height?

During the hardfork upgrade:

  1. Stop the old miner
  2. Start the new miner

5. Upgrade guide for Exchanges

Exchanges should pause BTG deposits and withdrawals one day before the fork height. When the hashrate of the blockchain becomes stable after the fork, Exchanges can resume regular deposit and withdrawal operations.

A fork period typically has no effect on trading with coins that are already held on Exchange.

Risk warning:

  • Not pausing the wallet before the hardfork may result in loss of funds because reorgs can happen during the fork
  • Resuming wallets too early after the hardfork may result in losing money because reorgs can occur during the fork
  • Not upgrading full nodes before the fork may result in loss of funds because an old node may stay on an abandoned chain

We are more than willing to help our partners to prepare for the hardfork. Please don't hesitate to contact us for help:

6. Upgrade guide for Wallet Providers

Wallet service providers should upgrade the full node and change the block validation logic before the fork.

Risk warning:

  • Not upgrading the full node before the fork may result in loss of funds because you may stay on an abandoned chain

7. Upgrade guide for Payment Gateways

Similar to exchanges, payment gateway providers should:

  • Upgrade the full node before the fork
  • Pause the service one day before the fork height
  • Resume the service when the hashrate becomes stable after the fork

Risk warning: same as Exchanges.

8. Upgrade guide for Blockchain Explorers and other services

All services should upgrade the full node before the fork.

9. Upgrade guide for users

Users should upgrade their wallet software as directed by their wallet provider.

Users should avoid sending or receiving BTG during the fork. More specifically, we suggest all users stop sending or receiving BTG at least a few blocks before the fork, and wait for an official announcement of the blockchain being stable enough after the fork before resuming activity.

Please stay tuned. Watch our official twitter account, and subscribe to our email notifications (The homepage is temporarily unavailable due to an network attack. It will be back soon).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions