This issue will track RandomX support for Hush Smart Chains.
Bounty = 10000 HUSH
The bounty could be shared across a group of developers, and could be more or less depending on exactly what is done. 50% of bounty will be paid out when noticeable progress is made and the second 50% of the bounty will be paid out upon completion of the task and proof that a HSC can be mined on a CPU via randomX.
After this is complete, users will be able to choose the RandomX algorithm via:
hushd -ac_algo=randomx
when creating a new HSC. All existing RandomX miners and mining pools should be compatible, we want to integrate into the existing RandomX community.
This issue will track RandomX support for Hush Smart Chains.
# Bounty = 10000 HUSH
The bounty could be shared across a group of developers, and could be more or less depending on exactly what is done. 50% of bounty will be paid out when noticeable progress is made and the second 50% of the bounty will be paid out upon completion of the task and proof that a HSC can be mined on a CPU via randomX.
# Details
We would like to integrate this audited C++ code: https://github.com/tevador/RandomX
Example code: https://github.com/tevador/RandomX/blob/master/src/tests/api-example1.c
Header API: https://github.com/tevador/RandomX/blob/master/src/randomx.h
# Spec
After this is complete, users will be able to choose the RandomX algorithm via:
```
hushd -ac_algo=randomx
```
when creating a new HSC. All existing RandomX miners and mining pools should be compatible, we want to integrate into the existing RandomX community.
Write code which changes key+input for groups of blocks
Decompress solution to byte array and pass to validBlock()
port EhSolverCancelCheck to randomx solver
Use randomx hash in HushRandomXMiner to build block
Fix warning miner.cpp:1003:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
Verify blocks can be mined via randomx
Write a Python test that creates a randomx HSC and mines a block with it
Verify that transactions can be made on a randomx HSC
Verify that HUSH mainnet mining is not borked by these changes
Have a HUSH solo miner use the new code and verify they can mine blocks correctly
Give the Hush community details on how to connect to a public HSC using randomx so others can verify things work
Not required in this task:
RandomX code should be compatible with the built-in stratum code
Task checklist:
- [x] Add new -ac_algo parameter
- [x] Document new -ac_algo parameter
- [ ] Document ac_randomx_interval
- [ ] Document ac_randomx_lag
- [x] Choose new options as per https://github.com/tevador/RandomX/blob/master/doc/configuration.md
- [x] Change ARGON SALT and iterations param
- [x] Research what param values XMR, WOW, ARQ uses
- [x] Decided against this: Change some opcode freq's
- [x] Integrate randomx build system into hush3 build system
- [x] Compile randomx code (Linux)
- [x] Link against librandomx (Linux)
- [x] Add RandomX code to hush3 repo (./src/RandomX)
- [x] Add solver code to HushRandomXMiner()
- [x] Use https://github.com/tevador/RandomX/blob/master/src/tests/api-example1.c as guide to implementation
- [x] Decide on key to use (chain magic)
- [x] Decide on input hash (blake2b)
- [x] Decide on how key changes (key block)
- [x] Write code for key+input for genesis block
- [x] Write code which changes key+input for groups of blocks
- [x] Decompress solution to byte array and pass to validBlock()
- [x] port EhSolverCancelCheck to randomx solver
- [x] Use randomx hash in HushRandomXMiner to build block
- [ ] Fix warning `miner.cpp:1003:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]`
- [x] Verify blocks can be mined via randomx
- [ ] Write a Python test that creates a randomx HSC and mines a block with it
- [x] Verify that transactions can be made on a randomx HSC
- [ ] Verify that HUSH mainnet mining is not borked by these changes
- [ ] Have a HUSH solo miner use the new code and verify they can mine blocks correctly
- [ ] Give the Hush community details on how to connect to a public HSC using randomx so others can verify things work
Not required in this task:
- RandomX code should be compatible with the built-in stratum code
The randomx config params that WOWnero uses are here: 62c6ea1176
Memory usage was cut in half, salt changed and opcode frequencies were changed, with no explanation. One opcode frequency was set to 0, which seems weird.
The randomx config params that WOWnero uses are here: https://git.wownero.com/wownero/RandomWOW/commit/62c6ea1176f6e3085a04e3c72b174c776b7981d9
Memory usage was cut in half, salt changed and opcode frequencies were changed, with no explanation. One opcode frequency was set to 0, which seems weird.
Salt was changed. They did not change opcode frequencies, and lowered memory requirements and program iterations and argon iterations
The random config params for ARQ are here: https://github.com/arqma/RandomARQ/blob/master/src/configuration.h
Salt was changed. They did not change opcode frequencies, and lowered memory requirements and program iterations and argon iterations
I have determined that changing randomx config params at run-time will be too complex, so all Hush Smart Chains will share the same RandomX configuration. We will change to use a unique salt and change other config params to be different from any other existing coins. If an ASIC/FPGA is built to mine RandomX, then it will be able to mine any HSC that uses our variant of RandomX. This seems reasonable. If any HSC would like to change this in the future, it can fork the code or make a branch to change some values at compile-time.
I have determined that changing randomx config params at run-time will be too complex, so all Hush Smart Chains will share the same RandomX configuration. We *will* change to use a unique salt and change other config params to be different from any other existing coins. If an ASIC/FPGA is built to mine RandomX, then it will be able to mine any HSC that uses our variant of RandomX. This seems reasonable. If any HSC would like to change this in the future, it can fork the code or make a branch to change some values at compile-time.
SCX coin did nothing but change the salt value, which seems like they don't know what they are doing: ba7b5c426e
SCX coin did nothing but change the salt value, which seems like they don't know what they are doing: https://github.com/scalex-project/RandomSCX/commit/ba7b5c426ea59158efef577e330e7dfbb0fe2825
To explain a bit more, if a coin only changes the salt of their RandomX variant, that means an ASIC/FPGA built to do RandomX with custom salts could switch between XMR and that coin. Since XMR has the largest hashrate of any RandomX variant, this is not a good thing. This is why we will be changing a few more configuration values to make our RandomX variant incompatible with any ASIC/FPGA that are likely being built or already built for XMR's RandomX variant.
To explain a bit more, if a coin only changes the salt of their RandomX variant, that means an ASIC/FPGA built to do RandomX with custom salts could switch between XMR and that coin. Since XMR has the largest hashrate of any RandomX variant, this is not a good thing. This is why we will be changing a few more configuration values to make our RandomX variant incompatible with any ASIC/FPGA that are likely being built or already built for XMR's RandomX variant.
Interestingly they did not use the recommendations that were given in the audit by TrailOfBits
Arweave randomx config settings: https://github.com/ArweaveTeam/RandomX/blob/arweave/src/configuration.h which is mostly reducing memory usage
Interestingly they did not use the recommendations that were given in the audit by TrailOfBits
This issue will track RandomX support for Hush Smart Chains.
Bounty = 10000 HUSH
The bounty could be shared across a group of developers, and could be more or less depending on exactly what is done. 50% of bounty will be paid out when noticeable progress is made and the second 50% of the bounty will be paid out upon completion of the task and proof that a HSC can be mined on a CPU via randomX.
Details
We would like to integrate this audited C++ code: https://github.com/tevador/RandomX
Example code: https://github.com/tevador/RandomX/blob/master/src/tests/api-example1.c
Header API: https://github.com/tevador/RandomX/blob/master/src/randomx.h
Spec
After this is complete, users will be able to choose the RandomX algorithm via:
when creating a new HSC. All existing RandomX miners and mining pools should be compatible, we want to integrate into the existing RandomX community.
Task checklist:
miner.cpp:1003:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]Not required in this task:
This code should be implemented on the
randomxbranch which now exists, and merged intodevwhen completedThe randomx config params that WOWnero uses are here:
62c6ea1176Memory usage was cut in half, salt changed and opcode frequencies were changed, with no explanation. One opcode frequency was set to 0, which seems weird.
The random config params for ARQ are here: https://github.com/arqma/RandomARQ/blob/master/src/configuration.h
Salt was changed. They did not change opcode frequencies, and lowered memory requirements and program iterations and argon iterations
I have determined that changing randomx config params at run-time will be too complex, so all Hush Smart Chains will share the same RandomX configuration. We will change to use a unique salt and change other config params to be different from any other existing coins. If an ASIC/FPGA is built to mine RandomX, then it will be able to mine any HSC that uses our variant of RandomX. This seems reasonable. If any HSC would like to change this in the future, it can fork the code or make a branch to change some values at compile-time.
SCX coin did nothing but change the salt value, which seems like they don't know what they are doing:
ba7b5c426eTo explain a bit more, if a coin only changes the salt of their RandomX variant, that means an ASIC/FPGA built to do RandomX with custom salts could switch between XMR and that coin. Since XMR has the largest hashrate of any RandomX variant, this is not a good thing. This is why we will be changing a few more configuration values to make our RandomX variant incompatible with any ASIC/FPGA that are likely being built or already built for XMR's RandomX variant.
Arweave randomx config settings: https://github.com/ArweaveTeam/RandomX/blob/arweave/src/configuration.h which is mostly reducing memory usage
Interestingly they did not use the recommendations that were given in the audit by TrailOfBits
This code has been merged to
devand is undergoing testingWe have an issue dedicated to testing this, so this can be closed