October 14, 2019
Proof of Work for the Tari Chain

On Monday, the Tari community discussed proof of work strategies.
Join us for our next discussion on Freenode in #tari-dev.
Discussion times proposed by the Tari community:
Mondays: 6pm CAT (12pm EST)
Thursdays: 11am CAT (5am EST)
To keep up with the latest Tari developments, you can follow the project on Twitter.
Transcript of Monday discussion

02 <@CjS77> Hi everybody
03 <simian_za> Heya
03 <neonknight64> Hi
04 <Blackwolfsa> Hi
05 <stanimal6> Hey
06 <@CjS77> I know we're having a discussion around PoW next monday, but it won't hurt to get some context out of the way now
06 <@CjS77> So tl;dr, Tari's original plan was to go 100% merge mined with Monero
07 <@CjS77> However, that strategy has some significant risks, particularly wrt 51% attacks.
09 <Blackwolfsa> How does monero's pool devision look these days
09 <@CjS77> Essentially, if you don't have the majority of the network "on your side"; you can be 51% attacked by the remainder of the Monero hashrate.. _with very little opportunity cost_ (because normally, a 51% attack means a miner is giving up mining rewards by not co-operating; in this case he's still getting his Monero, and is only potentially losing out
09 <@CjS77>  on Tari)
09 <@CjS77> I don't know -- neonknight64 might have some numbers
10 <Hansie> Hi
10 <@CjS77> hey Hansie
10 <neonknight64> https://minexmr.com/pools.html
11 <@CjS77> Hansie did some nice work on 51% attacks here: https://tlu.tarilabs.com/merged-mining/merged-mining-scene/MergedMiningIntroduction.html#51-attacks
11 <simian_za> Wow that is actually a better distribution than the last time we looked at the Monero hashrate
12 <neonknight64> Jip, the distribution of hashrate looks good.
13 <simian_za> but either way if we don't get the buy in of the majority of those pools we will be vulnerable and that will be quite a task
14 <@CjS77> It'll be very interesting to see what happens when RandomX goes live
14 <Hansie> Did some digging into Myriad, which was reported on in the TLU report mentioned
15 <Hansie> Myriad has 3 PoW and 2 merged mined PoW algos
16 <Hansie> Seems to be very 51% resistant
16 <Blackwolfsa> We need to simulate that
17 <Hansie> https://yac.metalworks.tarilabs.com/uploads/c46de3c2d4837f3a/BlockExplorers.ods
17 <Hansie> https://yac.metalworks.tarilabs.com/uploads/e301f69d2ec27e60/BlockExplorers.xlsm
17 <simian_za> Myriad seems very interesting but the variance in blocktime is pretty extreme
17 <Hansie> Depends on the value system I guess
17 <Blackwolfsa> From the newest data their variance is, I agree
18 <Hansie> Myriad PoW was designed to be 51% attack resistant, not necessarily with smooth block times
19 <Hansie> The spreadsheet shows history of a thousand blocks
20 <@CjS77> How does their algo work?
20 <Hansie> Each of the 5 algos has equal probability to solve the PoW
20 <Hansie> Difficulty adjusted to 5 min for each
20 <Blackwolfsa> Having block times that almost 50% in the low end opens you up toe other attacks 
20 <Hansie> Target block rate at 1 min
21 <Hansie> Any algo can build on top of the longest chain, even consecutively
21 <Blackwolfsa> We need to simulate it too see if it's more stable if it's more active 
22 <@CjS77> Ok, so the consensus rules just accept any PoW at the requisite difficulty
22 <Hansie> So with the 5 algos, any 1 pool can only achieve 20% of the efficient hash rate
22 <Hansie> Yes cjs77
22 <Hansie> https://cryptapus.org/myr/myrstat/
23 <Hansie> See above for share of algos that solved the PoW
23 <Hansie> Yes blackwolfsa, agreed
24 <Hansie> We can do some studies
24 <simian_za> I look forward to a parametrised sim of this approach. I suspect that it can be tuned to be far better than that data shows
25 <tar1b0t_> [mattermost] <stringhandler> We need to investigate how it is affected by selfish mining
25 <simian_za> indeed, I suspect it will be fine but the sim should be able to show the effect of that
26 <@CjS77> So if we went for 1x merge-mined and 1x PoW (where the PoW is not necessarily ASIC resistant but is unique -- i.e. not currently available on hashnice), would could have good 51% attack resistance too? One doesn't need to have 5x algos I'd say
26 <@CjS77> *nicehash*
27 <Hansie> So quoted from the web: "Myriadcoin has 5 algorithms (SHA256d, Scrypt, Skein, Qubit, and Myriad-Groestl) that can independently solve blocks. They have independent difficulties that are adjusted using the same formula. Any algorithm can solve the next block even if it is the same algorithm. Each algorithm targets the same block time and the block r
27 <Hansie> ewards are the same no matter which algorithm solves the block. From Multi-vPoW: Myriadcoin's Solution to Merge-Mining https://99bitcoins.com/myriadcoin-merge-mining/"
27 <Hansie> cjs77, I think more than 2 is better
28 <Blackwolfsa> But I suspect their will be a thing as too much as well
30 <Hansie> Yes, one has to be practical
30 <sarang> Jumping in after lurking... has anyone followed the earlier Zcash discussion where they were also investigating the use of multiple mining algorithms?
30 <@CjS77> Hansie, my gut says that 1x merge mined and 2x PoW is worse than 1-1.
30 <sarang> They called it "harmony mining" (because why not have a classy name too)
30 <@CjS77> If you go for 3, you should have 2x MM and 1x PoW
31 <@CjS77> Hey sarang
31 <Hansie> cjs77, maybe merged mined with Monero, Bitcoin and then standalone
31 <@CjS77> But do you see why I say that?
32 <Hansie> Hi sarang, I did not
32 <@CjS77> It's a hunch though, and not fully thought through
32 <sarang> I _think_ that this is the GitHub thread I am thinking of: https://github.com/zcash/zcash/issues/3672
32 <sarang> They concluded the risk of 51% was too great to adopt at the time
32 <sarang> It is absolutely worth a read
32 <sarang> (Daira had run some simulations as well)
32 <@CjS77> Thanks Sarang. I've got to go, but I think we've set up a good platform for next week
33 <Hansie> No cjs77, I do not. In essence if you have 1 GPU mining standalone, it has equal probability to solve the PoW to say a pool of Monero miners
33 <Hansie> Thanks sarang, will definately look at it
35 <@CjS77> If we assume merge miners don't want to leave the parent chain; and the fact that GPU PoW algos are pretty fungible, so you can grab 66% of the hashrate in a 1-2 split. Whereas in a 1-1 split, you have at most 50%.
36 <@CjS77> In a 2-1 split, you have at most 33%
37 <Blackwolfsa> You just have to whatch that each pow has enough pow to keep it secure... 
37 <Hansie> And it works the other way round as well, depending on which pools will do the mining
38 <tar1b0t_> [mattermost] <simian> That'd only if the algos are run in sequence if any algo can solve a given block and the difficulty retargeting is applied correctly I don't think those assumptions are strictly correct
38 <Blackwolfsa> If a pow has too little one can easily mine a few blocks in a row cheaply... 
39 <tar1b0t_> [mattermost] <stringhandler> The difficulty would need to be adjusted every block to stop 6 blocks being mined by the same algo
39 <Hansie> See here for dangers of merged mining: https://tlu.tarilabs.com/merged-mining/merged-mining-scene/MergedMiningIntroduction.html#analysis-of-mining-power-centralization-issues
40 <tar1b0t_> [mattermost] <stringhandler> You actually want consensus to be achieved only when every algo has a block
40 <tar1b0t_> [mattermost] <stringhandler> So perhaps 2 * num algos
42 <tar1b0t_> [mattermost] <simian> I think that if you get the difficulty adjustment right you don't need that. However we are speculating, a sim would answer a lot of these questions
43 <Hansie> stringhandler I guess it depends on the strategy. Different options definitely worth looking into
43 <tar1b0t_> [mattermost] <stringhandler> The thing is that if not all the algos are included then you only need to control 51% of the algos that are
43 <Hansie> simian yes, I agree we need to do the simulations
44 <tar1b0t_> [mattermost] <simian> But the difficulty of those algorithms will go up
44 <tar1b0t_> [mattermost] <stringhandler> Just some ideas to add to the simulations
44 <Hansie> stringhandler see Myriads "Algorithm Share" graph - link above. They have very few transactons, but it seems all 5 algos are always represented
45 <tar1b0t_> [mattermost] <stringhandler>  The difficulties must go up, but they only provide a probability of finding a block
45 <tar1b0t_> [mattermost] <stringhandler> But I'm saying that if you have 7 algos then 6 blocks is not enough for consensus
46 <tar1b0t_> [mattermost] <stringhandler> Just my gut feeling though
47 <Hansie> Ok, so you are talking about confirmation times. Makes sense
47 <Blackwolfsa> I think I follow your reasoning 
47 <Blackwolfsa> And I tend to agree
48 <Hansie> I have to run, thanks for the chat
17 <moneromooo> Would someone not need 50% of the monero network to double spend on tari if it were merged mined ?
18 <moneromooo> Oh, because most of the network will not care. OK. You still need the attacker to have more than the part of the monero network which merges mines (though variance is higher) AFAICT.
19 <moneromooo> And therefore better than not merge mining, presumably.
20 <moneromooo> I'm assuming that if someone tries to double send some tari, the part of the monero network that merge mines will reject it, the part controlled by the attacker will try to mine it, and the remainder of the monero network will ignore it.
20 <moneromooo> Is that correct ?
25 <tar1b0t_> [mattermost] <stringhandler> I think the remainder of the network will mine non Tari blocks, but there could be a problem where a large percentage of the miners mine valid monero blocks but alternate between 2 chains of Tari in each block
25 <tar1b0t_> [mattermost] <stringhandler> Kind of hedging
26 <tar1b0t_> [mattermost] <stringhandler> The same problem that PoS has. Then only the miners that choose a particular chain are contributing to the hash rate
26 <tar1b0t_> [mattermost] <stringhandler> Not 100% sure though
27 <moneromooo> You mean... if the "neutral" miners could be paid off by the attacker to mine the double spending tx ?
27 <moneromooo> Effectively becoming the attacker.
29 <tar1b0t_> [mattermost] <stringhandler> Thinking about it, I dont think my scenario makes financial sense
29 <tar1b0t_> [mattermost] <stringhandler> Think we need cjs77 to elaborate a bit
31 <tar1b0t_> [mattermost] <stringhandler> But there definitely is a case where an attacker can delay or confuse the Tari chain while still earning monero
51 <Hansie> If Tari is merged mined with Monero, and only one pool is interested, Tari will be at the mercy of that pool. The hash power distribution that Monero has will not be a given for Tari.
00 <tar1b0t_> [mattermost] <the_square> Hmm is it easy to merge mine multiple chains at the same time?
02 <tar1b0t_> [mattermost] <the_square> Oh I guess it would be trivially easily
25 <@CjS77> Not trivially easy, there's work that goes into it; and every merge mined coin needs pools to buy into it
26 <@CjS77> i.e. Monero pool operators have to change their pool software to merge mine Tari
26 <@CjS77> same for Bitcoin, if we choose that
Back to Discussions