XelisHash to XelisHashV2 auto‐switch

This guide lists the necessary steps to configure a seamless transition from xelishash mining algorithm to xelishashv2 following the Xelis hard fork https://github.com/xelis-project/xelis-blockchain/releases/tag/v1.13.0.

Step 1. Check prerequisites

Make sure:

• Miner version is 1.18.0 or newer
• You are mining to a node or one of the pools that support the auto-switch. At the time of writing this guide those are:
  • Vipor
  • K1Pool
  • Kryptex
  • HeroMiners
• The algorithm you are mining is either xelishash or xelishash+zil
• Built-in watchdog is enabled (it is always enabled unless the miner is run with --no-watchdog)

Step 2. Enable the auto-switch

Modify your existing config by passing an extra --enable-fork parameter to explicitly opt in for this feature.

Step 3. Set up overclock

⚠️ Warning: If you skip this step, the miner will be mining xelishashv2 with factory OC settings potentially making the GPUs draw a lot of power which may overload your PSUs.

If you overclock your GPUs by using miner parameters (as opposed to MSI Afterburner or your mining OS overclocking tool), you need to specify them for xelishashv2 too so that the miner would apply them after switching to the new algo. You can do so by prefixing the relevant entries with [fork], for example:

XEL only

Old config:

--lock-cclock 1470 --lock-mclock 5000 --cclock 100

New config:

--lock-cclock 1470 --lock-mclock 5000 --cclock 100                  // xelishash OC (pre-fork)
--lock-cclock [fork]1470 --lock-mclock [fork]X --mclock [fork]1000  // xelishashv2 OC (post-fork)

XEL+ZIL

Old config:

--lock-cclock [1]1470 --lock-mclock [1]5000 --cclock [1]100
--lock-cclock [2]1200 --lock-mclock [2]X --mclock [2]1000

New config:

--lock-cclock [1]1470 --lock-mclock [1]5000 --cclock [1]100                  // xelishash OC (pre-fork)
--lock-cclock [fork][1]1470 --lock-mclock [fork][1]X --mclock [fork][1]1000  // xelishashv2 OC (post-fork)
--lock-cclock [2]1200 --lock-mclock [2]X --mclock [2]1000                    // zil OC (both pre- and post-fork)

See full examples in xel-fork and xel-zil-fork script files in the miner archive.

💡 Reminder: if you're running Linux, don't forget to halve your memory offsets for Rigel (set the same values as if you were running Windows).

💡 Tip: you can simulate post-fork miner behaviour by using --activate-fork parameter. This is a good way to verify that the xelishashv2 OC settings are set correctly. You may want to use the testnet endpoint of your pool for this particular test.

FAQ

What happens at the time of the fork?

When the network reaches block 434100, the pool will send a signal to the mining client telling it to switch the algorithm. The watchdog will then restart the miner with a new, post-fork, config, and the miner will reconnect to the URL and start mining xelishashv2.

What do I do after the fork?

After Xelis has switched over to xelishashv2, it is time to change your Rigel config back to normal, namely remove --enable-fork, all [fork] prefixes, old xelishash settings, and change the algorithm to -a xelishashv2 or -a xelishashv2+zil.

What should I do as a pool operator to support the auto-switch?

You need to change the algorithm name in mining.notify messages for post-fork jobs from "xel/0" to "xel/1":

pre-fork:

{"id":<id>,"method":"mining.notify","params":["<job_id>","<timestamp>","<header hash>","xel/0",true]}

post-fork:

{"id":<id>,"method":"mining.notify","params":["<job_id>","<timestamp>","<header hash>","xel/1",true]}

⚠️ This would only work if your pool's post-fork xelishashv2 stratum URL is the same as pre-fork xelishash.