DragonX/hush3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ensure ASSETCHAINS_MINOPRETURNFEE modifies chain magic and document why

Browse Source
This commit is contained in:
Duke
2025-05-16 21:18:56 -04:00
parent ad51bc424f
commit dd4aac4f5f
2 changed files with 41 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
doc/DEVELOPING.md
View File

@@ -89,6 +89,41 @@ After successfully compiling Hush, you can generate a debian package of these bi
This command will not work on Mac OS X. Currently you cannot generate a Debian package
from operating systems other than Linux. Oh well.
## Adding new CLI options that change consensus rules
If you are adding a new CLI option that changes consensus rules such as
`-ac_foo` then make sure to also modify the the `extraptr` variable in
`src/hush_utils.h` with the value of the `ASSETCHAINS_FOO` variable. Our
convention is that if a CLI option affects consensus, it MUST begin with `-ac_`
and if it does not affect consensus (such as -datadir) then it MUST NOT begin
with `-ac_`. Originally the `ac` meant "asset chain" but now it means "affects
consensus" or "arrakis chain", take your pick.
The reason for this is the `extraptr` variable is used to deterministically
generate the "chain magic" `ASSETCHAINS_MAGIC` as well as the default p2p and
rpc ports for a HAC. This means that if two HACs have *exactly* the same
consensus options except for `-ac_foo` (even if they have the same `-ac_name`)
then they will still get different chain magic values and p2p and rpc ports.
This is a way of preventing HACs with different consensus rules from trying to
talk with each other when they should not. For instance, if you make a HAC with
`-ac_name=MYCOIN` on one machine with one set of consensus rules and then
another HAC with the same name on a different machine but with different
consensus rules, the chain magic being different (as well as the default p2p
port) are ways to prevent them from communicating. This is good because these
two HACs will eventually chain fork due to their different consensus rules and
ban each other, wasting time, bandwidth and sanity.
An example of doing this can be seen in the commit
https://git.hush.is/hush/hush3/commit/d39503c13b7419620d138050899705ced557eef9
which added the `-ac_burn` consensus changing option.
The chain magic value is the CRC32 checksum of every non-default consensus
option the HAC uses.
Also make sure to actually validate the new consensus option! That is probably
going to happen in `src/main.cpp` . If you don't, a malicious node can just
modify `src/miner.cpp` to do whatever they want.
## Updates to this document
If you think something else should be in this guide, please send your suggestions!