Algorithm and Merge-Mining Line-Up

[melvincarvalho]

I am convinced that we must have some algorithms returned to native-only status. Currently, since Fork 1 in June of 2018, all 8 Proof-of-Work algorithms are merge-mine enabled.

The advantage of merge-mining is that very large hashpower secures our blockchain throught harnessing hashrate of other coins via the AuxPoW mechanism. (This is particularly true of SHA256 and Scrypt) The disadvantage is that there is no native mining any longer, and anyone interested in the Bitmark project and in mining bitmark must compete with very large "foreign" hashrate, unrelated to the Bitmark project. There is no focused, Bitmark-only dedicated mining for us now; all the mining is mostly the by-product of miners mining other coins and regarding Bitmark as a mere "small bonus".

Most other, if not all other, coins that allow merge-mining, always reserve some algos as exclusive to their blockchain I believe we must address this by returning at least 1/3 or perhaps as many as 1/2 of our algorithms to native-only status. This will be a net improvement, with no downsides. This change does not affect neither the emission rate nor the total emission. We have always respected the total cap on emission. Security is rock solid with several algos and several of those with very large hash rates.

It only means that those with an interest in Bitmark for its own sake will have the ability to mine it without having to compete with any foreign, unrelated hashrate; in the native-only algos, they will have to compete only with other Bitmark miners.

We are due to freshen our algos in any case, because as several were chosen because of the hashrate or philosophy (democratic mining) of the coins implementing them and those coins have improved or changed the algos as well, we should keep up to date.

This is the case with Lyra2REv2, which was used by VertCoin. Now, VertCoin has adopted a proof-of-space algo developed by their team, to ensure widespread democratic mining, "VertHash". I believe we should replace Lyra2REv2 with VertHash CryptoNight has also evolved and we should update it accordingly to harness the hashrate of the popular privacy coin, Monero; the same is true for ZCash's EquiHash.

To achieve at least 1/3 native algos, I recommend:

• Swapping Yescrypt merge-mined for Yespower as a native algo. The developer of both these algos, SolarDesigner, developed Yespower expressly for cyrptocurrency.
• Returning Argon2d to native mining.
• Introducing a 9th algo as native-only: our original algorithm SCrypt. We would then have merge-mined SCrypt, and the same algorithm SCrypt but in a native-only flavor.

I think these algo updates and restoring a measure of native mining are justified and desirable. There are also some minor bugs outstanding that need to be fixed, but require a hard fork. For these reasons, I think that another fork, Fork 2 is warranted and should be undertaken. We have traveled that road, and done it before, succesfully.

from @dbkeys in https://github.com/project-bitmark/bitmark/issues/103

Getting everyone on the same page. The original emergency fork was a response to the inconsistent mining, firstly, famine and feast, and then large reorgs. Specifically it was unanimously agreed that the fork was a one off

By that reasoning a 2nd fork aka "Fork 2", is a hard NACK by default, unless as a bug fix. So, we should separate out bug fixes from new development. This is not a project with continuous rolling forks, like many other coins, we are simply a stable block chain on which to build our signature use case, namely marking

That said, I think we should stay open minded, and consider proposals on their merits, over time. We should keep up to date with innovation in the space. As before, the bar is extremely high and requires unanimous approval. The proposal should contain a logic and a motivation. Such as to allowing greater decentralization away from large mining pools

[randomminer]

"Swapping Yescrypt merge-mined for Yespower as a native algo. The developer of both these algos, SolarDesigner, developed Yespower expressly for cyrptocurrency."

DO NOT do this. I mine Yescrypt on discarded smartphones BECAUSE of merged Bitmark. If you change to Yespower I will probably never mine another block of Bitmark (not a threat, just a fact).

I would love to merge mine Equihash but can't find a pool that does it. If you have one or can get someone to set it up with ARRR I will happily mine Bitmark there too. Even a HOW-TO setup my own Bitmark merge mine would suffice.

FYI: For a while now I have been making sure mining-dutch.nl is on top of keeping Bitmark blocks flowing.

[melvincarvalho]

@randomminer noted! We wont change the current algos in that case. The aim was simply to get the blocks flowing to facilitate the marking use case

[melvincarvalho]

Even a HOW-TO setup my own Bitmark merge mine would suffice.

@randomminer we'll prioritize this as a work item

[randomminer]

After significant research it appears there isn't a pool in the wild that supports both merged mining and the equihash algorithm. I've been gathering information on both and am looking into merkle trees and such so may be able to get something going. I'm thinking more along the lines of a proxy that supports local merging than a pool as I don't need the payout system.

[bitmarkcc]

@randomminer

I've merge mined equihash successfully with Zcash testnet back in 2018 when I worked on launching the hard fork. There is no standard for equihash merge mining but I made it work very similarly to the current auxpow standard, just we don't parse all the parts of equihash transactions, we just keep them serialized as vectors and hash that directly, then we look for that hash in the merkle branch. I can help with integrating this if anyone wants. Cryptonight may also need some help for integration.

Does Zcash still use equihash or some proof of stake system? Who else uses this algo?

[randomminer]

Pirate, Horizen, Komodo, ZCash are the big players in equihash. There are some big AISCs out there that could mine more Bitmark if we can come up with something that pool owners can integrate. I am starting from zero with my knowledge on the inner workings of auxpow so it is going to take me some time for me to catch up.

[bitmarkcc]

@randomminer

Thanks I will look into those and make sure it's the original equihash and not some variant as Monero did with cryptonight.