Update block rewards after token sale #40
Comments
|
Note that the algo-dependent block reward is a bit tricky. The straight-forward solution is to just assume we get one Neoscrypt and one SHA256D block per minute, and then compute the rewards for each algo based on the halving schedule (and still doing the halving at a predefined block height, like 4.2M). But by doing so, the resulting coin supply may vary depending on how many blocks of each algo are mined exactly. For instance, if only Neoscrypt blocks would be mined, then it would be 50% too large; if only SHA256D blocks are mined, it would be 50% too small. This is likely not a big deal, though, as over a halving period of four years it is very likely that blocks would be evenly distributed between the algos, since the difficulties adjust independently. But it means we cannot guarantee the final money supply. Alternatively, we could go away from halving at given block heights, and instead keep track (in the chain state) of the remaining coin supply available for PoW. Then, each block can "take out" from this supply as much reward as is appropriate for its algo; and when doing so would drop the supply below a 2^(-n) level, the block rewards are halved. This has the advantage of being flexible and also simple in that the desired PoW coin supply can just be specified and doesn't have to be defined indirectly through a fixed halving schedule. Something like this exists already in iXcoin. |
|
Another, perhaps simpler solution for making the block-reward algorithm-dependent while ensuring an exactly fixed supply: Instead of changing the actual reward per block for the two algorithms, we could change the spacing of blocks. For instance, Neoscrypt-blocks could be scheduled every 30 seconds, while SHA-256d blocks are scheduled only every 90 seconds. This means that - even if they have nominally the same reward - SHA-256d rewards will be 25% and Neoscrypt rewards 75% of the total supply. (It also means that blocks will be created every 22.5 seconds on average, but that is either not an issue we care about or we would just tweak the numbers a bit to get back to 30 seconds.) |
This implements a hard fork scheduled at certain heights (500 on regtest, 12000 on testnet and not yet active on mainnet) that allows non-zero nonce values in the main block header (not the fake header). This solves #50. Forks are added to Consensus::Params similar to how they are handled in Huntercoin. For now, there's only this one, but there will likely be more in the future; for instance, to change the standalone mining algorithm or when we implement ephemeral timestamps. The created POST_ICO fork will contain more things in the future, namely a change to the block reward and block interval as described in #40.
This implements a hard fork scheduled at certain heights (500 on regtest, 12000 on testnet and not yet active on mainnet) that allows non-zero nonce values in the main block header (not the fake header). This solves #50. Forks are added to Consensus::Params similar to how they are handled in Huntercoin. For now, there's only this one, but there will likely be more in the future; for instance, to change the standalone mining algorithm or when we implement ephemeral timestamps. The created POST_ICO fork will contain more things in the future, namely a change to the block reward and block interval as described in #40.
This implements a hard fork scheduled at certain heights (500 on regtest, 12000 on testnet and not yet active on mainnet) that allows non-zero nonce values in the main block header (not the fake header). This solves #50. Forks are added to Consensus::Params similar to how they are handled in Huntercoin. For now, there's only this one, but there will likely be more in the future; for instance, to change the standalone mining algorithm or when we implement ephemeral timestamps. The created POST_ICO fork will contain more things in the future, namely a change to the block reward and block interval as described in #40.
This implements a hard fork scheduled at certain heights (500 on regtest, 1M on testnet and mainnet for now, will be changed) that allows non-zero nonce values in the main block header (not the fake header). This solves #50. Forks are added to Consensus::Params similar to how they are handled in Huntercoin. For now, there's only this one, but there will likely be more in the future; for instance, to change the standalone mining algorithm or when we implement ephemeral timestamps. The created POST_ICO fork will contain more things in the future, namely a change to the block reward and block interval as described in #40.
|
The @xaya: Please let me know at what height you think we should activate the fork on testnet, then we are ready to merge the code into |
356be12 Set POST_ICO fork for testnet. (Daniel Kraft) 5752067 Increase block reward with POST_ICO fork. (Daniel Kraft) dd40da9 Make block target spacing fork-able. (Daniel Kraft) d7f7e84 Allow non-zero nonce with POST_ICO fork. (Daniel Kraft) Pull request description: This implements the planned "post ICO" hard fork. For now, it is scheduled at height 500 on regtest, 11k on testnet and 1M on mainnet. The mainnet height will be defined later after a (hopefully) successful activation on testnet. This changes three things: 1. The nonce values of main block headers no longer need to be zero (#50). 2. The block intervals are changed and made algorithm-dependent: Neoscrypt targets 40s and SHA-256d two minutes after the fork (for an average that is still 30s per block). See #67 for the discussion. 3. The block rewards are increased to 10 CHI on testnet and mainnet after the fork. For testnet, that is the (arbitrary) value we will use. For mainnet, the value will be changed when the actual fork height becomes known, so that we can calculate the correct value. This implements #40. Tree-SHA512: 20b0cc0ea020cdcf46bbb2476bdfe0799b02faffcaf23f0b312d76d351e735ff17ac294a6ad1b6dd865e5134ff15fa5a53a1b2869990efdbb51caa847ba827fd
|
Closing this now, as the main coding is done. Finalisation of the fork is being tracked in #70. |
b5ef9be675 Merge #1: Merge changes from upstream 9e7f512430 Merge remote-tracking branch 'origin/master' into bitcoin-fork 1f85030246 Add support for ARM64 darwin (#43) 3bb959c982 Remove unnecessary reinterpret_cast (#42) 2e97ab26b1 Fix (unused) ReadUint64LE for BE machines (#41) 47b40d2209 Bump dependencies. (#40) ba74185625 Move CI to Visual Studio 2019. efa301a7e5 Allow different C/C++ standards when this is used as a subproject. cc6d71465e CMake: Use configure_package_config_file() git-subtree-dir: src/crc32c git-subtree-split: b5ef9be6755a2e61e2988bb238f13d1c0ee1fa0a
Once the token sale is complete, we have to do a hard fork that updates the block rewards (currently set to 1 CHI) to higher values such that the final money supply is correct. At this point, we should also make the block rewards depend on the PoW algorithm (Neoscrypt 75%, SHA256D 25%) as per our mining design.
The text was updated successfully, but these errors were encountered: