[ANN][ARG] Argentum || A New Begining || UPDATE YOUR WALLET ||

[Plutus47]

Glad to see some activity around this great coin again.

However, changing the mining algorithms without a good reason and consensus makes little sense to me. At least you're not talking of changing Scrypt & SHA256, those algorithms have an important advantage: they are merge-mineable with other coins, allowing miners to support Argentum while mining compatible chains at essentially the same time.

If replacing Lyra2REv2 the logical candidate IMO would be VertHash, which was explicitly designed to keep it CPU friendly (huge space requirement) and has the backing of a strong and long established VertCoin community. If so, then make it merge-mineable with VertCoin.

Before replacing them, I think we should be clear about what problem we're actually trying to solve—and whether changing the algorithms would provide enough benefit to justify losing existing mining compatibility and infrastructure.

Take a look at the current network and mining activity on this coin, which shares several algorithms with Argentum:

https://explorer.bitmark.one

Glad to have you adding to the discussion.

Here is the problem I am trying to solve, specifically.

https://plutus47.github.io/ARG-algo-upgrade/

In my current working tree, I have disabled the algo swap because most still don't understand the importance of consolidating into fewer, but hardened (still cpu/gpu friendly) mining algorithms. That's ok, they will in time. Zpool has enabled support for all 6 algos, which we greatly appreciate. But it still doesn't solve the long term issues. I have not considered swapping out scrypt or sha256, they were added on as auxpow for obvious reasons and have kept the chain alive after all  these years. All 6 mining algorithms are available on v26 in development right now.

As far as the emissions are concerned, I have taken a very slow approach due to the sensitive nature this mechanism. I think the 5 year proposal is very fair but also gives plenty of time for adjustments.

As far as v14 is concerned, it is important for the transition period, but ultimately, it's obsolete. v26 has so much more potential for building an ecosystem for ARG it's not even funny. And v26 is a path to v28 etc...

I'm also working on argentum support for c2pool based on https://github.com/frstrtr/c2pool. I hope to have it fully ready with the v26 release. Once again, all current algo's will be available. Is anyone willing to run a seed node for this? I would like to have it hard coded into the source.

I almost forgot. Segwit/Taproot. I've planned add that activation since it opens up a lot of features. Would like to hear opinions.

[dbkeys]

Regarding hard-coded seed nodes:

I believe a better approach is to run one or more node-tracker DNS seeders, which resolve a DNS hostname to a dynamically maintained list of active peer IP addresses.

These seeders, developed from SIPA's original Bitcoin Seeder, continuously crawl the network, identify reachable nodes, and maintain a current database of healthy peers.

When a new wallet queries the DNS seed, it receives a list of currently active nodes on the coin's network rather than depending upon a fixed IP address.

That's better than  relying on a single hard-coded IP seed node for several reasons:

• No single point of failure — the DNS seed can return many independent peers.
• Less centralization — new wallets are not all directed through one particular node.
• Dynamic discovery — dead or unreachable nodes naturally disappear from the returned list as the seeder updates its view of the network.
• Better scalability — a single hard-coded node won't become overwhelmed by every new wallet attempting to bootstrap from it.

Ideally, a coin should have at leat two or three independently operated DNS seeders for additional redundancy.

For example, I am currently running a DNS node-tracker seeder for Argentum (ARG) under the DNS name:

dnsseed.argentum.cc

(The .cc is convenient here — it can stand for cryptocurrency.)

You can query the seeder manually with the standard dig command:

Code:

$ dig dnsseed.argentum.cc

;; ANSWER SECTION:
dnsseed.argentum.cc.	3597	IN	A	47.28.170.78

At the moment, my Argentum tracker is seeing only one suitable node, so the DNS answer contains a single IP address:
Of course, an actual wallet doesn't require the user to run dig. The wallet/node performs the DNS lookup internally during startup and receives a list of IP addresses for known-good peers it can try to connect to.

The important point is that this list is dynamic. The DNS seeder continuously tracks the network, tests nodes, and returns addresses of peers that are currently considered suitable — rather than embedding one permanent IP address in the wallet.

As a better example of this in action, my Bitmark (BTMK) tracker is currently tracking about 50 nodes. A DNS query presently returns a subset of nine good nodes that a new nodes for that coin can use for bootstrapping:

Code:

$ dig btmk.bitmark.guru

;; ANSWER SECTION:
btmk.bitmark.guru.    3131    IN    A    46.105.78.216
btmk.bitmark.guru.    3131    IN    A    194.163.150.200
btmk.bitmark.guru.    3131    IN    A    51.83.11.113
btmk.bitmark.guru.    3131    IN    A    157.90.144.229
btmk.bitmark.guru.    3131    IN    A    45.33.65.161
btmk.bitmark.guru.    3131    IN    A    83.221.211.116
btmk.bitmark.guru.    3131    IN    A    81.66.137.244
btmk.bitmark.guru.    3131    IN    A    157.161.128.56
btmk.bitmark.guru.    3131    IN    A    31.202.69.187

So instead of telling every newly started wallet, "Go connect to this one hard-coded IP address," the software can essentially ask:

"Which good nodes are available on the network right now?"

and receive a rotating selection of currently reachable peers.

That is what's great about DNS node-tracker seeder: peer discovery remains dynamic, distributed, and self-updating as nodes enter and leave the network.

An important advantage of Multi-Algorithm Proof-of-Work

One of the less obvious advantages of a multi-algorithm Proof-of-Work blockchain is that the different mining algorithms provide redundancy not only in mining hardware, but also in time-keeping, which maintains the blockchain running.

Block production is the operational clock of a blockchain. If a single-algo coin suddenly loses most of its hashrate while difficulty remains high, blocks can become extremely slow or even effectively stop. This makes recovery difficult because the blockchain needs new blocks in order to measure what is happening and adjust its difficulty.

With multiple algorithms, if one algorithm loses its miners, the other algorithms will continue producing blocks and advancing the chain. Their blocks provide continuing evidence of the passage of time, allowing the network to recognize that the stalled algorithm is producing blocks too slowly and reduce its difficulty accordingly.

The difficulty system should distinguish between an algorithm that is actually producing blocks too quickly versus one that merely represents a larger percentage of the blocks because another algorithm has stopped. The healthy algorithms should not be penalized simply because they are keeping the chain moving.

Reducing the difficulty of the under-mined algorithm also creates an economic incentive for miners to return. The same block reward can now be earned with less expected hashing work, making that algorithm more attractive to mine.

So a properly designed multi-algorithm system creates a useful feedback loop:


Hashrate falls -> Block production slows ->

Difficulty is reduced -> Mining becomes more profitable ->

Hashrate is attracted back -> Block production recovers


In this way, multiple PoW algorithms can provide both technical redundancy and a built-in economic mechanism for restoring balance when one part of the mining network loses hashrate.

For this reason, I'm not too keen on reducing the number of algorithms.

I think its preferable to replace the least-mined algorithms with more actively mined algorithms, particularly where those algorithms can take advantage of merge mining and therefore bank on hashrate from larger, established mining networks.

At the same time, I would keep at least several native-only algorithms, particularly algorithms suitable for ordinary CPU hardware. This preserves an avenue for independent miners who don't operate specialized ASIC equipment or participate in large merge-mining pools.

In other words, rather than simply reducing the number of algorithms, I would favor improving the mix and, most importantly, carefully designing the difficulty-adjustment algorithm specifically to take advantage of the fact that this is a multi-PoW chain. The difficulty of each algorithm should be adjusted intelligently so that each tends toward its expected rate of block production. If one algorithm falls behind, the blocks produced by the others provide a continuing measure of elapsed chain time, allowing its difficulty to be eased appropriately. Conversely, an algorithm should not be penalized merely because its share of recent blocks has increased due to another algorithm falling behind. The objective should be to use the information provided by all of the algorithms to keep each one producing approximately its expected number of blocks over time, while preserving the redundancy and mining diversity that multi-PoW provides.

[dbkeys]

I spun up a node from the code at https://github.com/hclivess/argentum.git, master branch
It sat for a whole day connected to a single node (addr": "91.206.16.214:13580") and did not download any blocks

After adding @minerja's node list to ~/.argentum/argentum.conf, it has started syncing  

Code:

addnode=51.83.11.113
addnode=85.15.179.171
addnode=91.206.16.214

[Plutus47]

An important advantage of Multi-Algorithm Proof-of-Work

One of the less obvious advantages of a multi-algorithm Proof-of-Work blockchain is that the different mining algorithms provide redundancy not only in mining hardware, but also in time-keeping, which maintains the blockchain running.

Block production is the operational clock of a blockchain. If a single-algo coin suddenly loses most of its hashrate while difficulty remains high, blocks can become extremely slow or even effectively stop. This makes recovery difficult because the blockchain needs new blocks in order to measure what is happening and adjust its difficulty.

With multiple algorithms, if one algorithm loses its miners, the other algorithms will continue producing blocks and advancing the chain. Their blocks provide continuing evidence of the passage of time, allowing the network to recognize that the stalled algorithm is producing blocks too slowly and reduce its difficulty accordingly.

The difficulty system should distinguish between an algorithm that is actually producing blocks too quickly versus one that merely represents a larger percentage of the blocks because another algorithm has stopped. The healthy algorithms should not be penalized simply because they are keeping the chain moving.

Reducing the difficulty of the under-mined algorithm also creates an economic incentive for miners to return. The same block reward can now be earned with less expected hashing work, making that algorithm more attractive to mine.

So a properly designed multi-algorithm system creates a useful feedback loop:


Hashrate falls -> Block production slows ->

Difficulty is reduced -> Mining becomes more profitable ->

Hashrate is attracted back -> Block production recovers


In this way, multiple PoW algorithms can provide both technical redundancy and a built-in economic mechanism for restoring balance when one part of the mining network loses hashrate.

For this reason, I'm not too keen on reducing the number of algorithms.

I think its preferable to replace the least-mined algorithms with more actively mined algorithms, particularly where those algorithms can take advantage of merge mining and therefore bank on hashrate from larger, established mining networks.

At the same time, I would keep at least several native-only algorithms, particularly algorithms suitable for ordinary CPU hardware. This preserves an avenue for independent miners who don't operate specialized ASIC equipment or participate in large merge-mining pools.

In other words, rather than simply reducing the number of algorithms, I would favor improving the mix and, most importantly, carefully designing the difficulty-adjustment algorithm specifically to take advantage of the fact that this is a multi-PoW chain. The difficulty of each algorithm should be adjusted intelligently so that each tends toward its expected rate of block production. If one algorithm falls behind, the blocks produced by the others provide a continuing measure of elapsed chain time, allowing its difficulty to be eased appropriately. Conversely, an algorithm should not be penalized merely because its share of recent blocks has increased due to another algorithm falling behind. The objective should be to use the information provided by all of the algorithms to keep each one producing approximately its expected number of blocks over time, while preserving the redundancy and mining diversity that multi-PoW provides.

I agree with most of this, and it's already how the chain works. Each algo retargets independently from its own last block, and each targets at its own expected block rate, not its share of recent blocks. Chainwork is a geometric mean across all of them. A healthy algo doesn't get penalized because another one stalled, that's the current design.

It's the same with 4 algos. Difficulty for an algo depends on when that algo last found a block, so one that nobody is mining just drifts down and stays there. An algo nobody mines keeps getting cheaper, that's the algorithm working, but six algos needs six crowds of miners, and competing CPU/GPU algorithms don't help.

And our two CPU algos ARE your stall scenario. Argon2d and Yescrypt split the same small pool of CPU miners in half. That's where the stalls come from. One hardened CPU algo fixes it: same miners, undivided. Same story on the GPU side, Groestl did 0.1% of blocks in October. Half the set is dead, or extremely inconsistent.


The post-swap set is SHA256d and Scrypt (both merge-mineable, banking hashrate from bigger networks), one hardened CPU algo, and Equihash for GPUs. That's your recommendation, not the opposite of it.

We differ on one number, not the principle. Block times should be reliable.

https://plutus47.github.io/ARG-algo-upgrade/

[dbkeys]

In theory, even a single CPU should be able to generate blocks with the correct difficulty factor. So perhaps a look at the difficulty setting algorithm would be productive. Since the merge-mine algo produce blocks reliably, the nodes should be able to use the knowledge of the passage of time to correctly adjust the difficulty for poorly-performing algos

[Plutus47]

In theory, even a single CPU should be able to generate blocks with the correct difficulty factor. So perhaps a look at the difficulty setting algorithm would be productive. Since the merge-mine algo produce blocks reliably, the nodes should be able to use the knowledge of the passage of time to correctly adjust the difficulty for poorly-performing algos

That is exactly how it works right now: the chain keeps measuring elapsed time from whichever algos are still producing, and a lagging algo is eased 12% for every block the others find — compounding up to thousands (and in severe cases, much higher) of times easier per hour. So within an hour or two the difficulty falls far enough that even a single CPU can find blocks again; the only thing no difficulty algorithm can fix is an algo with zero miners at all, and that's what merging the split CPU/GPU crowd onto two hardened algo's is for.

[dbkeys]

In theory, even a single CPU should be able to generate blocks with the correct difficulty factor. So perhaps a look at the difficulty setting algorithm would be productive. Since the merge-mine algo produce blocks reliably, the nodes should be able to use the knowledge of the passage of time to correctly adjust the difficulty for poorly-performing algos

That is exactly how it works right now: the chain keeps measuring elapsed time from whichever algos are still producing, and a lagging algo is eased 12% for every block the others find — compounding up to thousands (and in severe cases, much higher) of times easier per hour. So within an hour or two the difficulty falls far enough that even a single CPU can find blocks again; the only thing no difficulty algorithm can fix is an algo with zero miners at all, and that's what merging the split CPU/GPU crowd onto two hardened algo's is for.

Well then in theory any CPU could be making a many ARG's per hour ... I'll see if I can mine some with Argon2d (it won a cryptographic contest, which is why it was selected)

[Plutus47]

In theory, even a single CPU should be able to generate blocks with the correct difficulty factor. So perhaps a look at the difficulty setting algorithm would be productive. Since the merge-mine algo produce blocks reliably, the nodes should be able to use the knowledge of the passage of time to correctly adjust the difficulty for poorly-performing algos

That is exactly how it works right now: the chain keeps measuring elapsed time from whichever algos are still producing, and a lagging algo is eased 12% for every block the others find — compounding up to thousands (and in severe cases, much higher) of times easier per hour. So within an hour or two the difficulty falls far enough that even a single CPU can find blocks again; the only thing no difficulty algorithm can fix is an algo with zero miners at all, and that's what merging the split CPU/GPU crowd onto two hardened algo's is for.

Well then in theory any CPU could be making a many ARG's per hour ... I'll see if I can mine some with Argon2d (it won a cryptographic contest, which is why it was selected)

As you can see, when one mining algorithm stops mining the others make up for it the best they can, but the block-times will never be stable in the current configuration. I have already presented the fix for this.

https://ibb.co/Lhs30qft

[samurai619]

🚀 Argentum (ARG) is now listed on MiningChamp.com!
Track Network Stats, Active Mining Pools & Market Exchanges

Hello Argentum Community & Miners,

We are pleased to announce that Argentum (ARG) is now fully tracked on MiningChamp.com!

You can now monitor live network statistics, active mining pools, and check all supported cryptocurrency exchanges with real-time trading pairs and volume.

📌 Quick Links:

• Argentum Profile & Stats: https://miningchamp.com/coin/argentum
  
• All Pools: https://miningchamp.com/pools
  
• All Coins: https://miningchamp.com
  

⚡ Key Features & Data Tracked for Argentum:

• Market Exchanges & Pairs: View listed exchanges, trading pairs, real-time prices, 24h volume, and market liquidity aggregated across exchanges.
  
• Network Difficulty & Hashrate: Live network difficulty adjustments, total network hashrate, and chain growth metrics.
  
• Block Information: Current block height, average block time, and block rewards.
  
• Active Mining Pools: Overview of pools supporting ARG with their current hashrate and operational status.
  

Are you a pool operator or exchange running ARG? Feel free to reach out to ensure your stats are actively synced on MiningChamp.

Best regards,
The MiningChamp Team

[dbkeys]

In theory, even a single CPU should be able to generate blocks with the correct difficulty factor. So perhaps a look at the difficulty setting algorithm would be productive. Since the merge-mine algo produce blocks reliably, the nodes should be able to use the knowledge of the passage of time to correctly adjust the difficulty for poorly-performing algos

That is exactly how it works right now: the chain keeps measuring elapsed time from whichever algos are still producing, and a lagging algo is eased 12% for every block the others find — compounding up to thousands (and in severe cases, much higher) of times easier per hour. So within an hour or two the difficulty falls far enough that even a single CPU can find blocks again; the only thing no difficulty algorithm can fix is an algo with zero miners at all, and that's what merging the split CPU/GPU crowd onto two hardened algo's is for.

Well then in theory any CPU could be making a many ARG's per hour ... I'll see if I can mine some with Argon2d (it won a cryptographic contest, which is why it was selected)

As you can see, when one mining algorithm stops mining the others make up for it the best they can, but the block-times will never be stable in the current configuration. I have already presented the fix for this.

https://ibb.co/Lhs30qft

Thanks, that clarifies it. I went and checked the Argentum difficulty code, and you're right about how the existing mechanism works.

For a lagging algorithm, DigiSpeed finds the last block produced by that algo, but compares its height with the current chain tip. So while, say, Groestl is stalled, blocks found by SHA256d, Scrypt, Argon2d, etc. continue advancing the chain tip. The resulting increasing height deficit causes DigiSpeed to progressively ease Groestl's next target.

So my earlier concern that an algo might have to find another block at its old stranded difficulty before its difficulty could fall does not apply here. The other algorithms do indeed "keep the clock ticking."

That actually makes me wonder whether the more productive fix is not necessarily removing algorithms, but improving the recovery behavior of the difficulty controller.

Your data shows difficulty swings of extraordinary magnitude -- millions-fold in some cases -- and absences lasting many hours. If DigiSpeed is already capable of detecting that an algo is falling behind and lowering its difficulty while the other algos advance the chain, then perhaps the question becomes:

Is the present 12% compounded easing curve aggressive enough when an algorithm is obviously stranded?

A large transient miner or profit-switching pool can arrive, drive an algo's difficulty sharply upward, then disappear. The remaining miners inherit a difficulty representing hashpower which no longer exists. DigiSpeed eventually corrects this, but perhaps it should distinguish between ordinary variance and a genuine stranded-algo condition.

For example, we could retain the present adjustment during normal operation, but add a progressively stronger recovery mechanism after an algo has missed a certain number of its expected blocks:

Code:

normal lateness       -> existing DigiSpeed adjustment
moderately overdue    -> accelerated easing
severely overdue      -> much faster easing
extremely overdue     -> converge rapidly toward powLimit

The adjustment could use both the number of chain blocks since that algo last appeared and elapsed Median Time Past, so it responds to actual elapsed network time rather than block height alone.

I'd also look at the other side of the problem: how quickly difficulty is allowed to rise when a huge transient miner arrives.

If an algo can acquire difficulty appropriate for a massive visiting miner much faster than it can shed that difficulty after the miner leaves, that's an inherently asymmetric failure mode.

In other words, perhaps the desirable controller is:

Code:

normal hashrate variation -> smooth adjustment
sudden hashrate arrival   -> controlled upward adjustment
sustained algo absence    -> increasingly aggressive downward adjustment

That would directly attack the "visitor arrives -> difficulty rockets -> visitor leaves -> slot stranded" behavior your analysis identified.

There's another potentially useful signal available specifically because ARG is multi-algo: the algo's share of a rolling window of all blocks.

With six algorithms, we'd nominally expect roughly 1/6 of the blocks over a sufficiently large window to come from each algo. If an algo has produced 1 block out of the last 120 instead of roughly 20, the chain has very strong evidence that its effective difficulty is mismatched to the available hashpower. That information could supplement the existing last-algo-block calculation.

So I'd be interested in testing three things before concluding that reducing six algos to four is necessary:

• Existing per-algo DigiSpeed adjustment
• A more aggressive stranded-algo recovery curve
• A cap on upward difficulty excursions caused by transient hashpower

There is also a useful precedent for doing precisely this sort of thing in another mPoW chain: Bitmark's Resurrector / Surge Suppressor pair.

Rather than asking the normal difficulty algorithm to handle every possible condition gracefully, Bitmark treats pathological cases as pathological cases and responds accordingly. The Surge Suppressor deals with an abnormal concentration of blocks from one algorithm, while the Resurrector deals with the opposite extreme -- an algorithm that has failed to produce a block for an excessive period.

The principle is basically:

extreme conditions justify extreme, but bounded, corrective measures.

That may be particularly appropriate for ARG. DigiSpeed can remain responsible for normal difficulty regulation, while a Resurrector/Surge-Suppressor-type layer handles conditions that are clearly outside the range of ordinary mining variance.

Conceptually:

Code:

NORMAL
|
DigiSpeed handles it
|
+------------+------------+
|                         |
extreme dominance          extreme absence
|                         |
Surge Suppressor              Resurrector
|                         |
restrain difficulty       aggressively reduce
/ block-rate surge        stranded difficulty

In other words, we don't necessarily need to make DigiSpeed itself extremely aggressive under normal conditions. We can preserve its relatively smooth behavior and add safeguards which only engage after objective thresholds demonstrate that something exceptional has happened.

That also has the advantage of making the consensus behavior easier to reason about: ordinary variance gets ordinary treatment; pathological conditions trigger explicitly defined emergency treatment, bounded by powLimit and other consensus safeguards.

That said, I think your suggestion of VerusHash deserves separate consideration.

If the data really shows that Groestl has no miners at all for substantial periods -- rather than merely having miners unable to find blocks because of stranded difficulty -- then I agree that replacing Groestl with a substantially more widely mined algorithm such as VerusHash makes sense.

A better difficulty controller can rescue an algo from obsolete difficulty, but it cannot manufacture miners where none exist. If an algorithm has effectively lost its mining community while another suitable algorithm has an active pool of miners and readily available mining software, replacing the abandoned algo could improve both participation and the practical diversity of ARG's PoW.

So I see these as two complementary issues rather than competing proposals:

Code:

Groestl has miners, but difficulty strands them
-> improve difficulty recovery / Resurrector

Groestl genuinely has no miners for substantial periods
-> replacing it with VerusHash makes good sense

If an algo has literally zero miners, of course no difficulty algorithm can produce a block for it. I agree completely on that point.

But zero miners and stranded difficulty are two different problems, and I think it is important that we distinguish between them when looking at the block data.

If even one CPU/GPU is willing to mine an algo, the difficulty controller should ideally be capable of bringing that algo back into reasonable block production quickly, regardless of how much hashpower was pointed at it previously.

And since ARG's existing architecture already allows the healthy algos to drive the difficulty of a stalled algo downward, it seems we already have most of the machinery necessary to do this.

So perhaps the two changes aren't mutually exclusive: improve ARG's extreme-case difficulty handling along the lines of Bitmark's Resurrector / Surge Suppressor, while also replacing an algo such as Groestl if the evidence shows that its mining ecosystem really has disappeared.

[dbkeys]

One further thought on the proposed algo set.

I like the idea of adding VerusHash and Equihash. And if Groestl really has no miners for substantial periods, then replacing it with a substantially more widely mined algo such as VerusHash or VertHash makes sense.

However, rather than going from six algos all the way down to four, I'd consider five:

Code:

SHA256d
Scrypt
Argon2d
VerusHash
Equihash

In other words, yes lose Yescrypt and Groestl, but keep Argon2d.

There is a practical reason for giving Argon2d another look: Bitmark already has an active Argon2d mining community, and Bitmark can be merge-mined on Argon2d. Argentum could retain Argon2d as a native algo while encouraging the same miners to merge-mine Bitmark, giving that mining community additional incentive and potentially strengthening it for both projects.

Argon2 also has good pedigree -- it won the Password Hashing Competition -- and, as a small marketing bonus, there's a rather nice natural association:

ARGentum  <-->  ARGon2d

So while I agree with the principle of eliminating algos which genuinely have no mining constituency, I wouldn't necessarily put Argon2d in that category without first exploring the existing Bitmark miner base.

There is also the original security rationale for mPoW to consider. A diverse set of healthy PoW algorithms forces a would-be attacker to marshal different kinds of mining resources rather than simply overwhelming one homogeneous source of hashpower. Dominating SHA256d does not automatically give an attacker dominant Scrypt, Argon2d, VerusHash and Equihash capacity as well.

That security argument only holds, of course, if the additional algos have real honest miners. An abandoned algo doesn't become a security asset merely because we count it as another PoW algorithm. But if we can sustain five genuinely mined algos using different hardware and mining communities, I would regard that diversity as a feature rather than overhead.

So perhaps the relevant comparison isn't simply five algos versus four, but five healthy and substantially independent mining constituencies versus four.

The question I'd ask is whether five healthy mining constituencies might be better than four, particularly when one of those five already has a neighboring mining ecosystem that ARG can tap into.

[Plutus47]

One further thought on the proposed algo set.

I like the idea of adding VerusHash and Equihash. And if Groestl really has no miners for substantial periods, then replacing it with a substantially more widely mined algo such as VerusHash or VertHash makes sense.

However, rather than going from six algos all the way down to four, I'd consider five:

Code:

SHA256d
Scrypt
Argon2d
VerusHash
Equihash

In other words, yes lose Yescrypt and Groestl, but keep Argon2d.

There is a practical reason for giving Argon2d another look: Bitmark already has an active Argon2d mining community, and Bitmark can be merge-mined on Argon2d. Argentum could retain Argon2d as a native algo while encouraging the same miners to merge-mine Bitmark, giving that mining community additional incentive and potentially strengthening it for both projects.

Argon2 also has good pedigree -- it won the Password Hashing Competition -- and, as a small marketing bonus, there's a rather nice natural association:

ARGentum  <-->  ARGon2d

So while I agree with the principle of eliminating algos which genuinely have no mining constituency, I wouldn't necessarily put Argon2d in that category without first exploring the existing Bitmark miner base.

There is also the original security rationale for mPoW to consider. A diverse set of healthy PoW algorithms forces a would-be attacker to marshal different kinds of mining resources rather than simply overwhelming one homogeneous source of hashpower. Dominating SHA256d does not automatically give an attacker dominant Scrypt, Argon2d, VerusHash and Equihash capacity as well.

That security argument only holds, of course, if the additional algos have real honest miners. An abandoned algo doesn't become a security asset merely because we count it as another PoW algorithm. But if we can sustain five genuinely mined algos using different hardware and mining communities, I would regard that diversity as a feature rather than overhead.

So perhaps the relevant comparison isn't simply five algos versus four, but five healthy and substantially independent mining constituencies versus four.

The question I'd ask is whether five healthy mining constituencies might be better than four, particularly when one of those five already has a neighboring mining ecosystem that ARG can tap into.

What does argon2d have that verushash doesn't, and what benefit is there to have more than one CPU algorithm? As we have seen, having more than one does not benefit the network, and we have years of data to prove it. Verushash has been mined for over five years and no fpga or asic has ever appeared for it, and if one ever does the hash can be revised. Argon2d has neither the record nor that option, and the argon2d we actually run only uses 4 MB of memory. That is less than the cache on an ordinary CPU, so there was never much resistance there to begin with.

We can't just harden it (argon) either. When a new block arrives, a node has to check its proof of work before it can pass it on. I measured what that check costs on a normal desktop:

sha256d — about a millionth of a second
verushash — about a millionth of a second
equihash — about a hundred-thousandth of a second
argon2d at our 4 MB — about four thousandths of a second
argon2d at 250 MB, where it would actually resist hardware — about 1.3 seconds

Every other algorithm we have is effectively instant. A hardened argon2d would be over a second of dead time on every node a block passes through, on a chain with 45-second blocks. That is how you get orphaned blocks. So argon2d is either weak, which is what it is today, or it is a drag on the whole network. There is no setting where it is both safe and cheap. Maintaining two like algorithms is not a redundancy, it's a burden and we have years of data to prove it. More is not always better.

The same question can be asked of the difficulty adjustment algo. The DigiShield design has been tried and tested for a decade. Creating a new one is a very complex solution to a problem that can be fixed by refining our algorithms.

So the screenshot settles the difficulty question. No miners means no blocks, and the difficulty algo had already walked groestl down to the minimum a day earlier. There is nothing below that for a more aggressive curve to reach. What it also can't do is stop the slowdown, and that part is arithmetic. Each algo is held to 45 seconds times the number of algos, six, whether or not all six are alive so the survivors are never sped up to cover a missing one.

What four algos changes is how often a slot goes empty at all. Holding 45-second blocks means every slot has to be filled at the same time, that is six mining communities that all have to show up.

The same test decides the fifth slot. Sha256d and scrypt are their own worlds, equihash is GPUs, verushash is CPUs, and argon2d is also CPUs. At minimum difficulty one core finds a verushash block in about a second; the same core needs about an hour for an argon2d block, and a whole 12-core desktop still can't quite hold that slot. So who mines argon2d who would not otherwise mine verushash?

Five healthy constituencies would beat four. But a slot nobody mines isn't healthy, and it also opens up a hole. No algo may mine more than 6 blocks in a row, so an attacker on rented hashpower needs a second algo to keep going, and a slot sitting at minimum difficulty is exactly the cheap second algo they need. You said an abandoned algo doesn't become a security asset just because we count it as another PoW algorithm. I'd agree and take it a step further; it becomes a liability. I don't think argon2d is a fifth constituency, it's verushash's counted twice.

Maybe there is something truly unique we can add in place of argon2d, and if there is I want to hear it. But what would it capture? Adding an algorithm doesn't create miners, it divides the ones we have, and every slot we add is one more that has to be filled every 45 seconds or the chain slows down, and a hole opens up. Until there is real demand for argentum blocks, a fifth slot isn't a fifth community. It's the same miners spread thinner.

[dbkeys]

Those are good arguments, particularly your observation that Groestl had already been sitting at minimum difficulty for a day. In that case I agree: no amount of additional difficulty easing could have resurrected it. There simply wasn't anyone mining it.

I also take your point about Argon2d's present 4 MB implementation and the verification cost of substantially increasing its memory requirement.

But I think you've identified exactly the question that should decide whether Argon2d stays:

who mines argon2d who would not otherwise mine verushash?

Potentially, Bitmark's existing Argon2d miners.

There is an important practical point here: Bitmark's Argon2d is already merge-mineable. Argentum can remain the native parent chain and Bitmark the AuxPoW chain.

Code:

Argon2d hashrate
|
mining pool/server
|
+------+------+
|             |
Argentum        Bitmark
parent chain    AuxPoW chain
native PoW      merge-mined

So the immediate task isn't a new consensus mechanism. It's primarily a pool-support task: get Argon2d pools to use the same mining work for native Argentum while simultaneously merge-mining Bitmark.

That way we're not asking Bitmark miners to abandon Bitmark for ARG. A properly configured pool can make mining ARG additive to what they're already doing.

That gives us a straightforward experiment: enable and promote ARG + BTMK Argon2d merged mining and see whether the existing Bitmark mining community provides meaningful hashpower.

If they don't, then your argument wins. An empty Argon2d slot isn't useful diversity.

And if Argon2d itself is now such a weak proposition that neither network can attract a healthy mining constituency with it, perhaps the better question isn't whether Argentum should preserve Argon2d at all.

Maybe Bitmark should be looking at VerusHash and/or Verthash too.

That could open a more interesting possibility: coordinate compatible PoW between the two projects so that wherever practical the same mining constituency can help secure both networks through merge mining.

Verthash is particularly interesting because it already has an established GPU mining ecosystem around Vertcoin. DigiByte has also been considering adding Verthash to its MultiAlgo system together with AuxPoW specifically to enable merged mining with Vertcoin.

So perhaps the question isn't:

Code:

six algos vs. four algos

but:

Code:

How many genuinely healthy and substantially
independent mining constituencies can we attract?

I agree that keeping dead algorithms simply to maintain a larger number is counterproductive. But I also don't think reducing the algorithm count should itself be the objective.

More healthy, independently sourced PoW can still be an advantage; more empty slots clearly aren't.

So I'd be open to testing several possibilities rather than defending any particular algorithm:

Code:

SHA256d
Scrypt
VerusHash
Equihash
Verthash

And possibly Argon2d if the ARG/BTMK merge-mining experiment demonstrates that it actually brings a sustainable constituency.

If Argon2d can't do that, drop it. And perhaps Bitmark should reconsider it too.

Likewise, if Verthash can't bring meaningful additional GPU miners, don't add it.

The criterion should be empirical:

Does this algorithm bring sustainable hashpower that would not otherwise be securing the network?

If we can also make that hashpower productive across Argentum, Bitmark, Vertcoin or other compatible networks through merge mining, so much the better.

That seems more useful to me than choosing four, five or six as the target number in advance.

[Plutus47]

Those are good arguments, particularly your observation that Groestl had already been sitting at minimum difficulty for a day. In that case I agree: no amount of additional difficulty easing could have resurrected it. There simply wasn't anyone mining it.

I also take your point about Argon2d's present 4 MB implementation and the verification cost of substantially increasing its memory requirement.

But I think you've identified exactly the question that should decide whether Argon2d stays:

who mines argon2d who would not otherwise mine verushash?

Potentially, Bitmark's existing Argon2d miners.

There is an important practical point here: Bitmark's Argon2d is already merge-mineable. Argentum can remain the native parent chain and Bitmark the AuxPoW chain.

Code:

Argon2d hashrate
|
mining pool/server
|
+------+------+
|             |
Argentum        Bitmark
parent chain    AuxPoW chain
native PoW      merge-mined

So the immediate task isn't a new consensus mechanism. It's primarily a pool-support task: get Argon2d pools to use the same mining work for native Argentum while simultaneously merge-mining Bitmark.

That way we're not asking Bitmark miners to abandon Bitmark for ARG. A properly configured pool can make mining ARG additive to what they're already doing.

That gives us a straightforward experiment: enable and promote ARG + BTMK Argon2d merged mining and see whether the existing Bitmark mining community provides meaningful hashpower.

If they don't, then your argument wins. An empty Argon2d slot isn't useful diversity.

And if Argon2d itself is now such a weak proposition that neither network can attract a healthy mining constituency with it, perhaps the better question isn't whether Argentum should preserve Argon2d at all.

Maybe Bitmark should be looking at VerusHash and/or Verthash too.

That could open a more interesting possibility: coordinate compatible PoW between the two projects so that wherever practical the same mining constituency can help secure both networks through merge mining.

Verthash is particularly interesting because it already has an established GPU mining ecosystem around Vertcoin. DigiByte has also been considering adding Verthash to its MultiAlgo system together with AuxPoW specifically to enable merged mining with Vertcoin.

So perhaps the question isn't:

Code:

six algos vs. four algos

but:

Code:

How many genuinely healthy and substantially
independent mining constituencies can we attract?

I agree that keeping dead algorithms simply to maintain a larger number is counterproductive. But I also don't think reducing the algorithm count should itself be the objective.

More healthy, independently sourced PoW can still be an advantage; more empty slots clearly aren't.

So I'd be open to testing several possibilities rather than defending any particular algorithm:

Code:

SHA256d
Scrypt
VerusHash
Equihash
Verthash

And possibly Argon2d if the ARG/BTMK merge-mining experiment demonstrates that it actually brings a sustainable constituency.

If Argon2d can't do that, drop it. And perhaps Bitmark should reconsider it too.

Likewise, if Verthash can't bring meaningful additional GPU miners, don't add it.

The criterion should be empirical:

Does this algorithm bring sustainable hashpower that would not otherwise be securing the network?

If we can also make that hashpower productive across Argentum, Bitmark, Vertcoin or other compatible networks through merge mining, so much the better.

That seems more useful to me than choosing four, five or six as the target number in advance.

I do like your idea with Bitmark, but my issue with Argon is that it is not ASIC resistant, and in it's ASIC resistant form, it's not viable. Is it an issue right now, no. But looking ahead, coordinating an algo upgrade now is much easier done than when the userbase is much larger. We have our ASIC powered algos, for good reason, but our CPU/GPU algo's should stay ASIC proof.

From my understanding, DGB has been trying to swap algos for years, but its much more difficult with a large userbase.

I think the second option you presented is a great idea. Improve both networks by upgrading them to Verushash and partner up from there.

And if we keep an extra algo slot for another network, what happens if it doesn't work out, or the other network decides to upgrade, then we're back where we started with dead algos. The long term health and reliability of the network comes first, and we basically know what we need to do. I think CPU/GPU power should be concentrated on one CPU/GPU slot, otherwise, any way you look at it, it creates a vulnerability, or at best, its unreliable. Ask yourself if you would willingly choose either of those options.

[dbkeys]

I think you've persuaded me on the main point about the legacy CPU algos.

If Argon2d's present parameters don't provide much meaningful long-term resistance to specialized hardware, while increasing them enough to do so imposes substantial verification cost, then there isn't much reason to preserve it merely because Argentum already has it.

The same applies even more strongly to old Yescrypt. In looking into it, I found that Solar Designer himself now directs cryptocurrency PoW use toward yespower rather than modern yescrypt. So if we're going to make a disruptive consensus change anyway, I think it makes sense to look forward rather than preserve algorithms mainly for historical continuity.

I also have to confess that I had never heard of VerusHash until you brought it up, so I still have homework to do there. I don't want to pretend expertise I don't have.

Verthash, on the other hand, interests me because I know Vertcoin's history, its relatively strong mining community, and its explicit commitment to keeping mining accessible on general-purpose consumer hardware.

That leads me to a somewhat broader conclusion.

Rather than asking whether Argentum should have four, five or six algorithms, I think the better question is:

Code:

Which algorithms bring strong, sustainable
and substantially independent mining constituencies?

On that basis, your proposed core looks quite sensible:

Code:

SHA256d
Scrypt
VerusHash
Equihash

SHA256d and Scrypt clearly bring enormous established ASIC ecosystems. VerusHash is intended to bring a CPU constituency. Equihash provides a GPU constituency.

I would treat that as a strong baseline rather than assume in advance that four must be the permanent optimum.

If a fifth algorithm can bring genuinely additional hashpower rather than merely divide the same miners, then I think it deserves consideration.

That's why Verthash remains interesting to me. If it can bring a meaningful slice of the existing Vertcoin GPU-mining ecosystem to Argentum, particularly through practical merge-mining arrangements, then it may represent additional diversity rather than dilution.

There is also a larger opportunity here involving Bitmark.

Bitmark's current eight-algo lineup contains several algorithms that made sense when its mPoW system was introduced but look much less compelling today. If Bitmark is ever going to hard-fork its mining-algo lineup, I think the right approach would be a clean sweep:

• Retire legacy algos which no longer have a strong technical or mining rationale.
• Keep the proven anchor algos such as SHA256d and Scrypt.
• Evaluate modern CPU and GPU PoWs on their present merits.
• Coordinate with Argentum wherever sharing algorithms creates useful mining and merge-mining economics.

That seems much more valuable than Argentum modernizing in isolation while Bitmark continues indefinitely with an aging eight-algo set.

In fact, if VerusHash proves to be as good a CPU choice as you're arguing, perhaps Bitmark should adopt VerusHash too.

Likewise, Verthash might deserve consideration by both projects if the Vertcoin mining constituency and merge-mining possibilities are real.

That could produce a modern common core along the lines of:

Code:

Argentum        Bitmark

SHA256d          yes             yes
Scrypt           yes             yes
VerusHash        yes          investigate
Equihash         yes          modernize
Verthash      investigate     investigate

The exact lineup should come from testing, not aesthetics.

And I think this is where the original argument for mPoW still matters.

More algos are not automatically better. More healthy and substantially independent sources of PoW can be better.

An abandoned algo sitting at minimum difficulty doesn't add meaningful security. I accept your argument there.

But neither do I think we should conclude from that that fewer algorithms are inherently safer.

If honest mining is coming from genuinely different ASIC, CPU and GPU ecosystems, an attacker has a harder resource-acquisition problem than if the chain depends on fewer homogeneous sources of hashpower.

So I would use a simple test for every proposed algorithm:

Code:

1. Is it technically strong today?

2. Does it have a real mining constituency?

3. Does it add meaningfully different hardware/hashpower?

4. Can sharing it with Argentum, Bitmark or another
   established chain improve merge-mining economics?
   

If an algo fails those tests, retire it.

If it passes them, it should earn consideration regardless of whether that leaves us with four, five or six.

So I think your proposal has changed my position in an important way:

I no longer think preserving Argon2d or Yescrypt should be an objective.

What I do want to preserve is the underlying mPoW idea: build the strongest practical mixture of independently sourced mining power we can, and where possible make Argentum and Bitmark mining partners rather than two small projects independently trying to bootstrap the same kinds of miners.

That, to me, is a much more interesting direction than defending the existing algorithm count or lineup.

[akrmn2021]

Why don't you go with RandomX for a true CPU mining algo. As I understand versushash is a PoW/PoS combination, and can still be an algo if you want, but perhaps have both of them.

[Plutus47]

I think you've persuaded me on the main point about the legacy CPU algos.

If Argon2d's present parameters don't provide much meaningful long-term resistance to specialized hardware, while increasing them enough to do so imposes substantial verification cost, then there isn't much reason to preserve it merely because Argentum already has it.

The same applies even more strongly to old Yescrypt. In looking into it, I found that Solar Designer himself now directs cryptocurrency PoW use toward yespower rather than modern yescrypt. So if we're going to make a disruptive consensus change anyway, I think it makes sense to look forward rather than preserve algorithms mainly for historical continuity.

I also have to confess that I had never heard of VerusHash until you brought it up, so I still have homework to do there. I don't want to pretend expertise I don't have.

Verthash, on the other hand, interests me because I know Vertcoin's history, its relatively strong mining community, and its explicit commitment to keeping mining accessible on general-purpose consumer hardware.

That leads me to a somewhat broader conclusion.

Rather than asking whether Argentum should have four, five or six algorithms, I think the better question is:

Code:

Which algorithms bring strong, sustainable
and substantially independent mining constituencies?

On that basis, your proposed core looks quite sensible:

Code:

SHA256d
Scrypt
VerusHash
Equihash

SHA256d and Scrypt clearly bring enormous established ASIC ecosystems. VerusHash is intended to bring a CPU constituency. Equihash provides a GPU constituency.

I would treat that as a strong baseline rather than assume in advance that four must be the permanent optimum.

If a fifth algorithm can bring genuinely additional hashpower rather than merely divide the same miners, then I think it deserves consideration.

That's why Verthash remains interesting to me. If it can bring a meaningful slice of the existing Vertcoin GPU-mining ecosystem to Argentum, particularly through practical merge-mining arrangements, then it may represent additional diversity rather than dilution.

There is also a larger opportunity here involving Bitmark.

Bitmark's current eight-algo lineup contains several algorithms that made sense when its mPoW system was introduced but look much less compelling today. If Bitmark is ever going to hard-fork its mining-algo lineup, I think the right approach would be a clean sweep:

• Retire legacy algos which no longer have a strong technical or mining rationale.
• Keep the proven anchor algos such as SHA256d and Scrypt.
• Evaluate modern CPU and GPU PoWs on their present merits.
• Coordinate with Argentum wherever sharing algorithms creates useful mining and merge-mining economics.

That seems much more valuable than Argentum modernizing in isolation while Bitmark continues indefinitely with an aging eight-algo set.

In fact, if VerusHash proves to be as good a CPU choice as you're arguing, perhaps Bitmark should adopt VerusHash too.

Likewise, Verthash might deserve consideration by both projects if the Vertcoin mining constituency and merge-mining possibilities are real.

That could produce a modern common core along the lines of:

Code:

Argentum        Bitmark

SHA256d          yes             yes
Scrypt           yes             yes
VerusHash        yes          investigate
Equihash         yes          modernize
Verthash      investigate     investigate

The exact lineup should come from testing, not aesthetics.

And I think this is where the original argument for mPoW still matters.

More algos are not automatically better. More healthy and substantially independent sources of PoW can be better.

An abandoned algo sitting at minimum difficulty doesn't add meaningful security. I accept your argument there.

But neither do I think we should conclude from that that fewer algorithms are inherently safer.

If honest mining is coming from genuinely different ASIC, CPU and GPU ecosystems, an attacker has a harder resource-acquisition problem than if the chain depends on fewer homogeneous sources of hashpower.

So I would use a simple test for every proposed algorithm:

Code:

1. Is it technically strong today?

2. Does it have a real mining constituency?

3. Does it add meaningfully different hardware/hashpower?

4. Can sharing it with Argentum, Bitmark or another
   established chain improve merge-mining economics?
   

If an algo fails those tests, retire it.

If it passes them, it should earn consideration regardless of whether that leaves us with four, five or six.

So I think your proposal has changed my position in an important way:

I no longer think preserving Argon2d or Yescrypt should be an objective.

What I do want to preserve is the underlying mPoW idea: build the strongest practical mixture of independently sourced mining power we can, and where possible make Argentum and Bitmark mining partners rather than two small projects independently trying to bootstrap the same kinds of miners.

That, to me, is a much more interesting direction than defending the existing algorithm count or lineup.

I looked into Verthash, and some other DAG based algo's and concluded that DAG is not a good fit for UTXO, or blockchains in general. It destroys SPV verification and light clients (not so light with a DAG), and even ETC hard forked away from their DAG. Verthash is a modified version of a DAG, but still adds a lot of overhead, is burdensome (at best) for SPV clients, and doesn't add anything that we can't get elsewhere (Equihash). With a little investigating I think you will come to the same conclusion.

I am not opposed to a 5th algo, but I do not think splitting CPU/GPU power on multiple algo's is the correct path. So if there is something truly unique that can bring a large community, I'm all ears.

[Plutus47]

Why don't you go with RandomX for a true CPU mining algo. As I understand versushash is a PoW/PoS combination, and can still be an algo if you want, but perhaps have both of them.

RandomX is not a great lightweight verification algorithm and requires a lot of overhead. It offers nothing we can't already get with verushash, which is exponentially less overhead and has much faster verifications. And the multipow implications would be a nightmare.

[dbkeys]

@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:

Code:

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:

Code:

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:

Code:

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:

Code:

RandomX vs. VerusHash

but:

Code:

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_Monero

Tari mining design:
https://rfc.tari.com/RFC-0131_Mining

Monero P2Pool:
https://github.com/SChernykh/p2pool

I'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.

[akrmn2021]

@dbkeys:

For RandomX there is fast mode (used for mining) and that requires 2GB RAM and light mode (just for verification) and that uses about 256MB RAM. Light mode still takes about 13 miliseconds to compute a hash on a modern CPU. I think it's reasonable, but implementing the code would be more complicated: needs a VM and different block format to be compatible with merge mining.

For versushash the RAM requirement is like 1 MB and sub millisecond computation time. But I don't think it is as ASIC resistant as RandomX and would require scheduled hardforks to keep updating it to make sure ASIC-like devices aren't competitive, and to be able to merge mine with VerusCoin (not VersusCoin).

As a Bitmark developer I would like to see Argentum be merge mineable with Bitmark, but I'm not realy an Argentum user, so I don't have strong opinions on this. As for Bitmark hard forking in order to change a PoW algorithm, I would disagree with that, and in fact I am working on a different approach for PoW (dynamic algos) that I want to introduce soon as a soft fork.