@Akrmn, your RandomX suggestion sent me down a rather interesting rabbit hole.
@Plutus, I think this changes the RandomX vs. VerusHash comparison considerably.
I initially looked at the three CPU candidates we've discussed -- VerusHash, RandomX and yespower -- simply in terms of their existing mining constituencies. RandomX appears to have by far the largest, principally because of Monero.
But merely sharing an algorithm doesn't give Argentum any of that hashpower. A VerusHash miner would normally have to choose:
mine VerusCoin
OR
mine Argentum
Likewise, simply adding RandomX would normally mean competing with Monero for CPU miners.
The interesting discovery is that RandomX doesn't necessarily have to work that way.Tari already merge-mines with Monero using RandomX. More importantly, the Tari design explicitly provides an auxiliary-chain Merkle proof for
multi-chain Auxiliary Proof of Work.
Monero already provides the merge-mining commitment in its coinbase, and current Monero P2Pool has generalized merge-mining support. Tari demonstrates that an independent auxiliary chain can validate Monero RandomX work without requiring a Monero consensus change.
That suggests Argentum and Bitmark could potentially implement the same model:
Monero / RandomX
XMR
|
same CPU work
|
+-------------+-------------+
| | |
Tari Argentum Bitmark
XTM ARG BTMK
The pool would construct one Monero mining job containing an auxiliary Merkle root committing to the participating auxiliary chains.
A returned RandomX result could then independently be tested against each chain's target:
RandomX result
|
+--> Monero target? -> XMR block
+--> Tari target? -> XTM block
+--> Argentum target? -> ARG block
+--> Bitmark target? -> BTMK block
It doesn't have to satisfy the Monero target to satisfy an auxiliary-chain target.
So the proposition to a Monero pool potentially becomes:
"Keep mining Monero exactly as you already do, but use the same RandomX work to compete for ARG and BTMK as additional rewards."That is fundamentally different from trying to persuade Monero miners to redirect their CPUs to Argentum.
Importantly, this appears achievable from
our side of the fence. We can potentially change Argentum and Bitmark and develop the necessary pool/P2Pool integration without requiring Monero developers to alter Monero consensus. Tari has already supplied much of the architectural precedent.
This makes me reconsider the CPU slot rather strongly.
VerusHash may well have the advantage Plutus identified: extremely fast/light verification. But its existing merge-mining ecosystem is primarily within Verus Public Blockchain as a Service. Unless Argentum can participate in that system without requiring cooperation or changes from Verus, adopting VerusHash alone doesn't give Argentum existing Verus hashpower.
RandomX potentially gives us something quite different:
a demonstrated route to sharing existing Monero CPU work rather than competing for it.For Bitmark this is particularly interesting because CryptoNight is already one of our eight algorithms. Monero itself ultimately replaced CryptoNight with RandomX, so RandomX is a fairly natural candidate when reconsidering that Bitmark CPU slot.
I'm therefore leaning much more strongly toward RandomX than I was when Akrmn first suggested it.
I don't think the case is closed, though. Plutus's verification-overhead objection is the remaining technical question I would particularly like to quantify.
The comparison I'd now like to make is not simply:
but:
RandomX:
heavier verification
* enormous established CPU ecosystem
* demonstrated external-chain merge mining
* potential access to existing Monero work
versus
VerusHash:
very lightweight verification
* established CPU ecosystem
* excellent internal Verus merge mining
- no demonstrated path yet for ARG/BTMK to share existing Verus work
If RandomX verification overhead is acceptable on Argentum's multi-Proof-of-Work chain, the ability to make Argentum and Bitmark additional auxiliary destinations for work already being performed by Monero miners seems to me a very substantial advantage.
References for anyone wanting to dig into it:
Tari Monero merge-mining specification:
https://rfc.tari.com/RFC-0132_Merge_Mining_MoneroTari mining design:
https://rfc.tari.com/RFC-0131_MiningMonero P2Pool:
https://github.com/SChernykh/p2poolI'd be particularly interested in Plutus's view of the verification cost once weighed against
shared existing Monero hashpower, rather than against RandomX operating as a standalone Argentum CPU algorithm.
RandomX will add a lot of technical debt and overhead that I do not think is worth the cost. I haven't even got deep into the weeds yet and, and already see we would need a secondary auxpow path.
Overhead debt is the real issue. RandomX's is a 256MB and a VM run per header, on every node, with periodic cache rebuilds. This one algo slot (~15-25% of the security roughly) creates permanent debt for the entire chain and users. Additionally, if I am understanding this correctly, ARG would have to fork whenever Monero does. There's only a few BTC derived blockchains that use randomX, and the one that that is merge-mined is Mimblewimble lineage. So there's no precedent for a multi-algo merge-mined BTC derived blockchain. Bitmain also shipped asics for RandomX, so that's another issue.
We have the ability to unlock an incredible amount of SHA256 and SCRYPT hashpower that I don't think the benefits or RandomX out-weight the cons. I believe is better for us to keep a low technical cost network. I think it would be better to reach out to verus auxpow communities. I am also working on implementing arg merged-mining in p2pool/c2pool, so I believe we will have many options.
