0

I am modifying a cryptonote to transition over to PoW algo cryptonightv1 from cryptonightv0 and I am having a weird issue that I can't figure out...I'm starting to pull out my hair over this. I've studied the changes that Monero, Turtlecoin, Electroneum and Masari have done and implemented it on my own coin (which shares a similar code base to turtlecoin/original bcn) yet miners seem to be able to mine with either PoW algo now (cryptonightv0 or v1) instead of just v1, at least as far as I can tell when using a pool. The tests/hash_tests app verifies that the PoW algos work correctly as I have these functions here that test cn_slow_hash with a variant=0 (for v0) and then with variant=1 (for v1):

static void cn_slow_hash_0(const void *data, size_t length, char *hash) {
      return cn_slow_hash(*context, data, length, *reinterpret_cast<chash *>(hash), 0);
  }
static void cn_slow_hash_1(const void *data, size_t length, char *hash) {
      return cn_slow_hash(*context, data, length, *reinterpret_cast<chash *>(hash), 1);
  }

The tests pass so I know that the actual PoW algorithm is implemented correctly in the sense that when cn_variant 0 is passed to cn_slow_hash() that it retrieves the hash for cryptonightv0 and when cn_variant 1 is passed it retrieves the hash for cryptonightv1.

The issue I am having is that when I start a local test net or live test net, I can mine with a pool with xmr-stak-nvidia with the miner algo set to "cryptonight" or "monero7" regardless of what height I am at (if I have the pool set to cryptonight then cryptonight works, if I have it set to v1 then monero7 works). I've done all the appropriate upgrade height changes and the block's major version even changes yet the get_block_longhash function doesn't seem to run the appropriate cn_long_hash variant. Even if I manually set cn_variant to 1 for ALL heights the miners are STILL able to mine either PoW algo if the pool allows it. Here is what my get_block_longhash function has to supply the correct variant to the cn_slow_hash function:

const int cn_variant = b.majorVersion >= 5 ? b.majorVersion - 4 : 0;
cn_slow_hash(context, bd.data(), bd.size(), res, cn_variant);

So if the version is 5 or greater the cn_variant should equal 1. When I print the blocks they show that they are majorVersion 5, yet the old PoW algo is still working to mine blocks! Unless there is something wrong with my pool setup that is tricking me (https://github.com/dvandal/cryptonote-nodejs-pool/). Is there another way that I could test this without question to make sure it is swapping over to the new PoW correctly? I am running out of ideas because, like I said, even if I manually force cn_variant to be 1 without the ternary operator it doesn't fix the issue. What am I missing here? Any advice is GREATLY appreciated. I am so stuck right now.

EDIT: Am I not understanding this correctly? I just tried the pool with a different coin that is cryptonightv0 only, and it allowed me to mine with "monero7" in xmr-stak-nvidia and accepted the shares?

0

The solution was that my checkpoints were messing everything up. Once I got rid of the checkpoints everything worked correctly (this is a hard fork of an existing coin so I need the checkpoints in the final version but for testing I was using a new separate network starting at height 0. I commented out the checkpoints and it works correctly now).

  • If you need the checkpoints in the final version, then this suggests you will be reusing that coin's chain instead of having your own genesis block, right ? If so, are you aware of monero.stackexchange.com/questions/7826/… ? If yes, why are you doing this ? – user36303 May 29 '18 at 8:37
  • Yes it is a continuation of the main chain (not a new coin), aka a hard fork but same coin so I do not need to worry about that. It is more comparable to Monero's fork that they had earlier this year and not MoneroV's etc etc – gibbonz May 30 '18 at 15:56
  • I assume you intend people to use your coin ? When Monero forks, it does not intend to continue using both versions. The old version is obsolete (though this time round some people jumped at the chance to continue mining on it for quick money). – user36303 May 30 '18 at 19:09
  • Yes, that is the case. – gibbonz May 31 '18 at 19:46
  • How do you reconcile this with "so I do not need to worry about that" ? Am I missing something ? – user36303 May 31 '18 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.