Altcoin Genesis block fails after changing block reward

1

I have been struggling with this issue for a week. I have created an altcoin forking litecoin code, i have mined genesis block, the compiled code works fine with 50*COIN genesis block reward.

When i change GenesisBlockreward in chainparams.cpp, to 1000*COIN, i get debug assertion failed. My coins have limited supply of 10 million.

    genesis = CreateGenesisBlock(1518803474, 2297622, 0x1e0ffff0, 1, 1000 * COIN);

Why is this happening?

Here the code for main network.

class CMainParams : public CChainParams {
public:
    CMainParams() {
        strNetworkID = "main";
        consensus.nSubsidyHalvingInterval = 100000;
        consensus.BIP34Height = 710000;
        consensus.BIP34Hash = uint256S("fa09d204a83a768ed5a7c8d441fa62f2043abf420cff1226c7b4329aeb9d51cf");
        consensus.BIP65Height = 918684; // bab3041e8977e0dc3eeff63fe707b92bde1dd449d8efafb248c27c8264cc311a
        consensus.BIP66Height = 811879; // 7aceee012833fa8952f8835d8b1b3ae233cd6ab08fdb27a771d2bd7bdc491894
        consensus.powLimit = uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"); 
        consensus.nPowTargetTimespan = 3.5 * 24 * 60 * 60; // 3.5 days
        consensus.nPowTargetSpacing = 2.5 * 60;
        consensus.fPowAllowMinDifficultyBlocks = false;
        consensus.fPowNoRetargeting = false;
        consensus.nRuleChangeActivationThreshold = 6048; // 75% of 8064
        consensus.nMinerConfirmationWindow = 8064; // nPowTargetTimespan / nPowTargetSpacing * 4
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

        // Deployment of BIP68, BIP112, and BIP113.
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1517356801; // January 31st, 2018

        // Deployment of SegWit (BIP141, BIP143, and BIP147)
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1517356801; // January 31st, 2018

        // The best chain should have at least this much work.
        consensus.nMinimumChainWork = uint256S("0x00000000000000000000000000000000000000000000002ebcfe2dd9eff82666");

        // By default assume that the signatures in ancestors of this block are valid.
        consensus.defaultAssumeValid = uint256S("0x59c9b9d3fec105bdc716d84caa7579503d5b05b73618d0bf2d5fa639f780a011"); //1353397

        /**
         * The message start string is designed to be unlikely to occur in normal data.
         * The characters are rarely used upper ASCII, not valid as UTF-8, and produce
         * a large 32-bit integer with any alignment.
         */
        pchMessageStart[0] = 0xfb;
        pchMessageStart[1] = 0xc0;
        pchMessageStart[2] = 0xb6;
        pchMessageStart[3] = 0xdb;
        nDefaultPort = 26201;
        nPruneAfterHeight = 100000;

        genesis = CreateGenesisBlock(1518803474, 2297622, 0x1e0ffff0, 1, 1000 * COIN);
        consensus.hashGenesisBlock = genesis.GetHash();
        assert(consensus.hashGenesisBlock == uint256S("0x326bcc5731fba75254090bcd460d2e514c0ba86f91f7ef30ba48ff8a32e99c5e"));
        assert(genesis.hashMerkleRoot == uint256S("0xd242c6e48edac265167f85ae2e6de488287fe89c0152343e1cb27216ce282d27"));

        // Note that of those with the service bits flag, most only support a subset of possible options
        //vSeeds.emplace_back("seed-a.litecoin.loshan.co.uk", true);
        //vSeeds.emplace_back("dnsseed.thrasher.io", true);
        //vSeeds.emplace_back("dnsseed.litecointools.com", true);
        //vSeeds.emplace_back("dnsseed.litecoinpool.org", true);
        //vSeeds.emplace_back("dnsseed.koin-project.com", false);

        base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,11);
        base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
        base58Prefixes[SCRIPT_ADDRESS2] = std::vector<unsigned char>(1,50);
        base58Prefixes[SECRET_KEY] =     std::vector<unsigned char>(1,176);
        base58Prefixes[EXT_PUBLIC_KEY] = {0x04, 0x88, 0xB2, 0x1E};
        base58Prefixes[EXT_SECRET_KEY] = {0x04, 0x88, 0xAD, 0xE4};

pbu

Posted 2018-02-18T15:53:33.160

Reputation: 203

Answers

4

Looks like amount is a part of block information influencing hashes. Try to debug or log resulting hashes before assert:

logging.info("Genesis Block Hash " + consensus.hashGenesisBlock);
logging.info("Compared to Hash " + uint256S("0x326bcc5731fba75254090bcd460d2e514c0ba86f91f7ef30ba48ff8a32e99c5e"));

And then check debug.log in your coin folder.

Oleksandr Stepaniuk

Posted 2018-02-18T15:53:33.160

Reputation: 56

1The genesis block's coinbase transaction would be the where the new 'amount' is influencing the hash. – lastcanal – 2018-02-18T19:52:09.917

Thats correct! It generates new hash Genesis hash: Genesis hash:7fc34ec30e346ec63369d23ba2721a80fb1d5309314d23bbcf3cea1ac8aa06a5 Compared to Hash 0x336bcc5731fba75254090bcd460d2e514c0ba86f91f7ef30ba48ff8a32e99c5e Abort trap: 6 – pbu – 2018-02-18T20:24:22.143

1It worked finally, after i used -v flag in GenesisH0 with new reward value – pbu – 2018-02-20T16:11:40.400

@pbu by generating genesis hash with value coins are you able to get genesis coins or have you changed the reward system too ? Like by adding condtion if block is 0/1 reward should be different ...

– user1140237 – 2018-10-01T10:43:25.097

yes i was able to get reward for genesis block. – pbu – 2018-10-07T09:40:17.677