Tari Protocol Discussion 47
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
18:02 <@CjS77> Hi everybody 18:03 <simian_za> Heya 18:03 <neonknight64> Hi 18:04 <Blackwolfsa> Hi 18:05 <stanimal6> Hey 18: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 18:06 <@CjS77> So tl;dr, Tari's original plan was to go 100% merge mined with Monero 18:07 <@CjS77> However, that strategy has some significant risks, particularly wrt 51% attacks. 18:09 <Blackwolfsa> How does monero's pool devision look these days 18: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 18:09 <@CjS77> on Tari) 18:09 <@CjS77> I don't know -- neonknight64 might have some numbers 18:10 <Hansie> Hi 18:10 <@CjS77> hey Hansie 18:10 <neonknight64> https://minexmr.com/pools.html 18:11 <@CjS77> Hansie did some nice work on 51% attacks here: https://tlu.tarilabs.com/merged-mining/merged-mining-scene/MergedMiningIntroduction.html#51-attacks 18:11 <simian_za> Wow that is actually a better distribution than the last time we looked at the Monero hashrate 18:12 <neonknight64> Jip, the distribution of hashrate looks good. 18: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 18:14 <@CjS77> It'll be very interesting to see what happens when RandomX goes live 18:14 <Hansie> Did some digging into Myriad, which was reported on in the TLU report mentioned 18:15 <Hansie> Myriad has 3 PoW and 2 merged mined PoW algos 18:16 <Hansie> Seems to be very 51% resistant 18:16 <Blackwolfsa> We need to simulate that 18:17 <Hansie> https://yac.metalworks.tarilabs.com/uploads/c46de3c2d4837f3a/BlockExplorers.ods 18:17 <Hansie> https://yac.metalworks.tarilabs.com/uploads/e301f69d2ec27e60/BlockExplorers.xlsm 18:17 <simian_za> Myriad seems very interesting but the variance in blocktime is pretty extreme 18:17 <Hansie> Depends on the value system I guess 18:17 <Blackwolfsa> From the newest data their variance is, I agree 18:18 <Hansie> Myriad PoW was designed to be 51% attack resistant, not necessarily with smooth block times 18:19 <Hansie> The spreadsheet shows history of a thousand blocks 18:20 <@CjS77> How does their algo work? 18:20 <Hansie> Each of the 5 algos has equal probability to solve the PoW 18:20 <Hansie> Difficulty adjusted to 5 min for each 18:20 <Blackwolfsa> Having block times that almost 50% in the low end opens you up toe other attacks 18:20 <Hansie> Target block rate at 1 min 18:21 <Hansie> Any algo can build on top of the longest chain, even consecutively 18:21 <Blackwolfsa> We need to simulate it too see if it's more stable if it's more active 18:22 <@CjS77> Ok, so the consensus rules just accept any PoW at the requisite difficulty 18:22 <Hansie> So with the 5 algos, any 1 pool can only achieve 20% of the efficient hash rate 18:22 <Hansie> Yes cjs77 18:22 <Hansie> https://cryptapus.org/myr/myrstat/ 18:23 <Hansie> See above for share of algos that solved the PoW 18:23 <Hansie> Yes blackwolfsa, agreed 18:24 <Hansie> We can do some studies 18: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 18:25 <tar1b0t_> [mattermost] <stringhandler> We need to investigate how it is affected by selfish mining 18:25 <simian_za> indeed, I suspect it will be fine but the sim should be able to show the effect of that 18: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 18:26 <@CjS77> *nicehash* 18: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 18: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/" 18:27 <Hansie> cjs77, I think more than 2 is better 18:28 <Blackwolfsa> But I suspect their will be a thing as too much as well 18:30 <Hansie> Yes, one has to be practical 18:30 <sarang> Jumping in after lurking... has anyone followed the earlier Zcash discussion where they were also investigating the use of multiple mining algorithms? 18:30 <@CjS77> Hansie, my gut says that 1x merge mined and 2x PoW is worse than 1-1. 18:30 <sarang> They called it "harmony mining" (because why not have a classy name too) 18:30 <@CjS77> If you go for 3, you should have 2x MM and 1x PoW 18:31 <@CjS77> Hey sarang 18:31 <Hansie> cjs77, maybe merged mined with Monero, Bitcoin and then standalone 18:31 <@CjS77> But do you see why I say that? 18:32 <Hansie> Hi sarang, I did not 18:32 <@CjS77> It's a hunch though, and not fully thought through 18:32 <sarang> I _think_ that this is the GitHub thread I am thinking of: https://github.com/zcash/zcash/issues/3672 18:32 <sarang> They concluded the risk of 51% was too great to adopt at the time 18:32 <sarang> It is absolutely worth a read 18:32 <sarang> (Daira had run some simulations as well) 18:32 <@CjS77> Thanks Sarang. I've got to go, but I think we've set up a good platform for next week 18: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 18:33 <Hansie> Thanks sarang, will definately look at it 18: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%. 18:36 <@CjS77> In a 2-1 split, you have at most 33% 18:37 <Blackwolfsa> You just have to whatch that each pow has enough pow to keep it secure... 18:37 <Hansie> And it works the other way round as well, depending on which pools will do the mining 18: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 18:38 <Blackwolfsa> If a pow has too little one can easily mine a few blocks in a row cheaply... 18:39 <tar1b0t_> [mattermost] <stringhandler> The difficulty would need to be adjusted every block to stop 6 blocks being mined by the same algo 18: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 18:40 <tar1b0t_> [mattermost] <stringhandler> You actually want consensus to be achieved only when every algo has a block 18:40 <tar1b0t_> [mattermost] <stringhandler> So perhaps 2 * num algos 18: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 18:43 <Hansie> stringhandler I guess it depends on the strategy. Different options definitely worth looking into 18: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 18:43 <Hansie> simian yes, I agree we need to do the simulations 18:44 <tar1b0t_> [mattermost] <simian> But the difficulty of those algorithms will go up 18:44 <tar1b0t_> [mattermost] <stringhandler> Just some ideas to add to the simulations 18:44 <Hansie> stringhandler see Myriads "Algorithm Share" graph - link above. They have very few transactons, but it seems all 5 algos are always represented 18:45 <tar1b0t_> [mattermost] <stringhandler> The difficulties must go up, but they only provide a probability of finding a block 18:45 <tar1b0t_> [mattermost] <stringhandler> But I'm saying that if you have 7 algos then 6 blocks is not enough for consensus 18:46 <tar1b0t_> [mattermost] <stringhandler> Just my gut feeling though 18:47 <Hansie> Ok, so you are talking about confirmation times. Makes sense 18:47 <Blackwolfsa> I think I follow your reasoning 18:47 <Blackwolfsa> And I tend to agree 18:48 <Hansie> I have to run, thanks for the chat 19:17 <moneromooo> Would someone not need 50% of the monero network to double spend on tari if it were merged mined ? 19: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:19 <moneromooo> And therefore better than not merge mining, presumably. 19: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. 19:20 <moneromooo> Is that correct ? 19: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 19:25 <tar1b0t_> [mattermost] <stringhandler> Kind of hedging 19: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 19:26 <tar1b0t_> [mattermost] <stringhandler> Not 100% sure though 19:27 <moneromooo> You mean... if the "neutral" miners could be paid off by the attacker to mine the double spending tx ? 19:27 <moneromooo> Effectively becoming the attacker. 19:29 <tar1b0t_> [mattermost] <stringhandler> Thinking about it, I dont think my scenario makes financial sense 19:29 <tar1b0t_> [mattermost] <stringhandler> Think we need cjs77 to elaborate a bit 19:31 <tar1b0t_> [mattermost] <stringhandler> But there definitely is a case where an attacker can delay or confuse the Tari chain while still earning monero 06: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. 08:00 <tar1b0t_> [mattermost] <the_square> Hmm is it easy to merge mine multiple chains at the same time? 08:02 <tar1b0t_> [mattermost] <the_square> Oh I guess it would be trivially easily 08:25 <@CjS77> Not trivially easy, there's work that goes into it; and every merge mined coin needs pools to buy into it 08:26 <@CjS77> i.e. Monero pool operators have to change their pool software to merge mine Tari 08:26 <@CjS77> same for Bitcoin, if we choose that