June 08, 2020
Monero merge-mining + Tari standalone. Is this still the consensus? Let’s make sure!
Tari’s testnet is now a month old. As mainnet launch approaches, one of the undecided questions that we as a community must answer is:
What does the proof-of-work algorithm for Tari mainnet look like?
The developer community discussed this topic late last year, but the broader Tari community has grown since then and we thought it would be prudent to re-open the discussion to determine whether the decision made in October still has broad consensus.
There are several options available to us:
- Merge mine with Monero
- Hybrid mining, with 50% - 75% of blocks being mined through Monero merge mining and the remainder using a CPU/GPU-friendly algorithm to mine Tari directly
- Hybrid mining: 50% - 75% of blocks merge mining Monero, and the remainder merge mining another coin
Option 1 is the Simplest
Tari can instantly leverage Monero’s hash-rate security; and given the relationship between the Monero and Tari communities, we are optimistic that Tari will get the support of several large Monero pool operators.
However, there are significant risks to “putting all your eggs in one merge-mined basket”. Cheap 51% attacks are possible, as this report and a few members of the Monero development community have pointed out.
Option 2 is the Next Easiest
Testnet is already a Tari-only Proof-of-work chain. Mainnet could mitigate the merge-mined 51% attack risks by hybrid mining using a Tari-only algorithm in addition to Monero merge-mining.
The choice of algorithm, and overall contribution to the block emission is yet to be decided. Testnet uses a double Blake hashing algorithm, but this isn’t an optimal choice for several reasons.
A better choice would be a “memory hard” hashing algorithm, like Argon2; or one that is likely to become an ASIC-based commodity in future, like SHA-3.
Algorithms that already have high hash rates on other coins, including SHA-256, Ethash, Scrypt and Equihash are not good choices.
Option 3 is Tougher
Mainly because it requires convincing an additional set of pool operators to support Tari. But it is not much more difficult to implement from a technical point of view.
The result of the Development Discussion back in October was to take Option 2.
Come Join the Tari Community
Friday, June 12th @ 16:00 UTC (9:00 PDT, 12:00 EDT, 17:00 CET, 18:00 SAST) on Telegram or #Tari on Freenode* to discuss the proof-of-work algorithm for Tari.
*There is a bridge routing messages from either platform to each other