Der Altcoin Genesis-Block schlägt fehl, nachdem die Blockbelohnung geändert wurde

Ich kämpfe seit einer Woche mit diesem Problem. Ich habe einen Altcoin-Forking-Litecoin-Code erstellt, ich habe einen Genesis-Block abgebaut, der kompilierte Code funktioniert gut mit der 50 * COIN-Genesis-Block-Belohnung.

Wenn ich GenesisBlockreward in chainparams.cpp auf 1000*COIN ändere, bekomme ich die Debug-Assertion fehlgeschlagen. Meine Münzen haben ein begrenztes Angebot von 10 Millionen.

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

Warum passiert das?

Hier der Code für das Hauptnetz.

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};

Antworten (1)

Sieht so aus, als ob die Menge ein Teil der Blockinformationen ist, die Hashes beeinflussen. Versuchen Sie, die resultierenden Hashes zu debuggen oder zu protokollieren, bevor Sie sie bestätigen:

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

Und dann überprüfen Sie die debug.log in Ihrem Coin-Ordner.

Die Coinbase-Transaktion des Genesis-Blocks wäre der Ort, an dem der neue „Betrag“ den Hash beeinflusst.
Das ist richtig! Es generiert neuen Hash Genesis-Hash:Genesis hash:7fc34ec30e346ec63369d23ba2721a80fb1d5309314d23bbcf3cea1ac8aa06a5 Compared to Hash 0x336bcc5731fba75254090bcd460d2e514c0ba86f91f7ef30ba48ff8a32e99c5e Abort trap: 6
Es hat endlich funktioniert, nachdem ich -v Flag in GenesisH0 mit neuem Belohnungswert verwendet habe
@pbu Durch die Generierung von Genesis-Hash mit Wertmünzen können Sie Genesis-Münzen erhalten oder haben Sie auch das Belohnungssystem geändert? Wie durch Hinzufügen einer Bedingung, wenn der Block 0/1 ist, sollte die Belohnung anders sein ...
Ja, ich konnte eine Belohnung für den Genesis-Block erhalten.
Der Altcoin Genesis-Block schlägt fehl, nachdem die Blockbelohnung geändert wurde
AntwortenHierDatenschutz-Bestimmungen1y, 0v