XMR & AEON Cryptonight Variant 1 Support

[LegolasGChief]

Hey :) any ideas what the https://github.com/Venthos/nodejs-pool/commit/c42c80819bbfeccfc304da4f8b5529131e88e1d0#diff-d1f20eb6706ccb31b4ef7371872ef6e9 equivalent for Aeon is?

[Venthos]

The xmr-cn-v1 branch that commit is a part of is a dev branch that has not been tested. In fact, I believe at this time it does not contain the latest VARIANT 1 algorithm changes and only the initial draft changes, meaning it won't work. I do not advise relying on it as production.

I read an AEON reddit post earlier that suggests they are 1:1 copying the algorithm change, but mysteriously also jumping their blockchain version straight to v7 in some confusing attempt to piggy bag on existing mining program changes. If so, the change should be near identical but require the same changes to the cryptonight_lite_hash function in node-multi-hashing.

Potentially I'll look at it later, but AEON is not a priority for me. XMR is vaguely a priority simply because Intense Coin is loosely tracking that coin's changes in the long term.

[ArqTras]

Hi Im using part of Your code to make testnet of rebase could we speak priv-send me contact info (discord or telegram or what you need) to support@supportaeon.com thanks

[Venthos]

If you can get a verified working change to node-multi-hashing then the nodejs-pool tweak is trivial. Has any AEON dev made efforts to make a compatible node-multi-hasing? The other pool software, not just nodejs-pool, pretty much relies on that. I may poke at it this week since it's in the same vein as Monero's change, but I do not have a testnet setup for AEON.

[LegolasGChief]

I don't have much right now but happy to donate a few Aeon if anyone can do it

[ArqTras]

https://aeonrebase.supportcryptonight.com/#/dashboard looks fine but still testing on testnet ofc

[Venthos]

What node-multi-hashing are you using? Because the one default used and the one referenced in my XMR test branch have no changes for AEON, so it should detonate the second the network hits v7 blocks (which use CN Variant 1)

[ArqTras]

https://github.com/ArqTras/node-cryptonight-hashing Thanks to MO For test im using xmrigCC with conf "force-pow-version" : 2, // force to use specific PoW variation (default: 0 POW_AUTODETECT, 1 POW_V1, 2 POW_V2)

[Venthos]

Ah, looks like MoneroOcean's fork? That's not something I am willing to use. But if it's working for you, then the simple changes to nodejs-pool from this fix should be workable, although I'd advise something like this for AEON:

this.cryptoNight = function(convertedBlob) {
        let cn_variant = convertedBlob[0] >= 7 ? 1 : 0;
        return multiHashing.cryptonight_light(convertedBlob, cn_variant);
    };

Since I wouldn't feel comfortable guaranteeing that AEON will follow +1 to each POW change just yet.

[ArqTras]

Ok will check

[ArqTras]

https://github.com/ArqTras/aeon-rebase-pool/commit/1937b95d5a46ebc82ab8c2f9fa74a40096510c1f

[Venthos]

I believe that I have both Monero and AEON new POW code working for nodejs-pool, but I need someone willing to test it (ideally on their respective testnets, of course). I don't have a pool setup for either and if someone has one ready to test with I'd rather just do that. Please let me know if you're able/willing to test a dev branch.

[ArqTras]

@Venthos send me info to your release code I will swap my test pool to Yours code, already is on main net using actual deamon to test unviersal solution from @camthegeek. Working with both version but i decide to use his due to universal and backward compatible to snippas

[Venthos]

I just pushed the branch now.

https://github.com/Venthos/nodejs-pool/tree/cn-v1

This branch should work fine whether you are on the original/current CryptoNight or if you're on XMR/AEON testnet with CryptoNight Variant 1. There should not be a situation where this pool breaks (on mainnet or testnet XMR/AEON/ITNS). If it does, please report it.

The branch is untested, so please use with caution

[Venthos]

Anyone able to give this a test?

[camthegeek]

I'll toss it on one of my dev servers and test with AEON soon.

As far as I know, the changes I did should be compatible with non-variant coins as well. I currently have it live on a few private pools and haven't hit any snags.

PS: I've seen your messages and scoured Snipa's repo for this thread before realizing I was tagged on yours! :D :D

[BKdilse]

Hey guys, need some help... my stellite pool is no longer finding blocks. I believe this is due to the hard fork.

Any advice on the best way to update this?

[Venthos]

@BKdilse If you use the cn-v1 branch on this repo, you should be able to adjust your coin file for Stellite to use the following cryptoNight function:

    this.cryptoNight = function(convertedBlob) {
        let cn_variant = convertedBlob[0] >= 3 ? 1 : 0;
        return cnHashing.cryptonight(convertedBlob, cn_variant);
    };

This is because it looks like the Stellite forked to the new CN Variant 1 on what is their next major block version (v3), which makes complete sense. They didn't do the weird crap that AEON did and skip several block versions to just match Monero's v7 version. That still seems so exceedingly lazy to me.

[BKdilse]

@Venthos thanks for that confirmation. What I did earlier to test this was to install "cryptonight-hashing", and change the coin file hard coding it to return cnHashing.cryptonight(convertedBlob, 1);

I take it convertedBlob[0] >= 3 ? 1 : 0; is checking if blockchain version is v3 or above, then setting cn_variant to 1 else set it to 0?

I'll go and amend this later, but should my config work ok for now?

[Venthos]

Correct. That logic sets cn_variant = 1 if the blockchain version is >= 3 (the first character of the block blob, or convertedBlob[0], else it sets cn_variant = 0.

Monero uses a tweaked bit of logic there that sets cn_variant +1 for each version of the blockchain in excess of 6. So v6 Blockchain = CN v0, v7 Blockchain = CN v1, v8 Blockchain = CN v2, etc. This is because Monero has publicly committed to tweaking the variant every time they hard fork. It wouldn't make sense to use this for Stellite because it's likely not a safe bet to assume Stellite will only ever fork in unison with Monero.

[BKdilse]

As always, thanks very much for that detailed explanation. :)

Just one last thing... Can I test this is working, or is it a matter of waiting for the next block?

[Venthos]

The logic is used to "verify" a miner's share. If this logic is not working, you would see a flood of Bad share from miner in the 'pool' process' log. Seeing the occasional bad share is not unexpected, but if it is constantly showing up for multiple miners it is likely that the code is not working for some reason or another.

[BKdilse]

OK, brilliant, already confirmed that, saw loads of bad shares, until I switched the miner to use the appropriate v1 coin code (XMR-STAK).

Thanks again.

[BKdilse]

@Venthos what's ur ITNS Wallet address, I'll send a little something... :)

[Venthos]

ITNS donation wallet is iz5imhe9C7vWnjZtZBFtT8MwNxVuJuryUUHXSAtnWUo93CJzNdZBizHQExPRCHUBi36tk2BcigPAFRDA4cnddGXF1R6j69n3w 😃

So I've seen reports of this branch working just fine for XMR on Snipa22's issue threads where people were using either camthegeek or my repos to fix things. So, I'm going to test this in production on my ITNS pool to verify that it does not at least break Variant 0 coins for now, and likely merge it unless I hear any negative reports.

[Venthos]

Looks fine in production on ITNS. I have no reason to believe it won't work on XMR/AEON. Please report if you find otherwise. This change is now in 'master' a 'la commit 33eebbd60c0f60360888f7d164ea2f119c4cef37

[BKdilse]

@Venthos I'll update my pool too soon, and a little something is on it's way to you. Thanks

[ArqTras]

I have no issues on aeon using camthegeek