mimblewimble / grin

Minimal implementation of the Mimblewimble protocol.
https://grin.mw/
Apache License 2.0
5.04k stars 990 forks source link

Dual Proof-Of-Work: cuckatoo32+ and 2nd PoW To Be Announced closer to launch #1438

Closed tromp closed 6 years ago

tromp commented 6 years ago

Implement dual pow as proposed in https://www.grin-forum.org/t/proof-of-work-update

ignopeverell commented 6 years ago

We should get started with extending the header format and validation first before settling on the 2nd proof of work.

timolson commented 6 years ago

May I suggest you try to freeze the PoW soon? Constant changes prevent miner writers from releasing well-optimized solutions at Genesis, and you will end up with a situation where those who have the best miners dominate the hashrate. I thought you wanted to avoid that.

tromp commented 6 years ago

We can't announce the 2nd PoW too soon, since its Asic Resistance relies on leaving ASIC manufacturers too little time to design and develop an ASIC. There will be reasonably optimized open source GPU miners available before launch.

timolson commented 6 years ago

Respectfully, no. Even if RTL is fully complete and verified, you’re looking at 6-9 months to produce a chip. Without RTL it’s 12 months+. At this point you are only hurting GPU writers.

timolson commented 6 years ago

Also, I cannot agree that there will be optimized open source GPU miners at launch. Look at the Zcash launch for example. Closed source miners were quickly multiples faster than the performance of open source ones. Mine was one of them.

tromp commented 6 years ago

A big outfit like Bitmain or Innosilicon could go from complete chip design to 28nm chip in 2 months, especially when using some reserved capacity, and have rigs up and running in another month. If we announce all PoW details 3 months ahead of launch, then that leaves a lot of room to wreak havoc.

1 month should be plenty of time to get open source miners more fully optimized, give the experience that miner devs have with algorithms like Equihash.

timolson commented 6 years ago

A big outfit like Bitmain or Innosilicon could go from complete chip design to 28nm chip in 2 months

I’m sorry but that is simply not true. Where do you get that information? I get my information from producing mining ASIC’s with TSMC. Wafer production is necessarily scheduled many months in advance to keep the foundry’s pipeline efficient. Even if you already have tapeout on a proven design, which takes many months, you’re talking about three months to wafers, plus additional time for testing, dicing, packaging, and finally system assembly. And no one can possibly be close to tapeout since you are changing things. Most of the physical design work cannot be done until RTL is frozen, even for standard cell ASIC’s.

As for Equihash derivatives, which it sounds like you may use, it is not really possible to change parameters at the last minute and have an optimized miner. Sure you can use generics to abstract type information but your miner will be slow. For speed, you must design tightly around memory and bandwidth constraints, with correct packing and word alignment, and crossing certain thresholds triggers big code changes.

Anyway all I’m asking for is clear parameters. It doesn’t help to spread FUD and hide your PoW plans from the public. How is that open and distributed? Maybe we should suspect that the dev team wants to give their own cronies a secret head start on implementation?

timolson commented 6 years ago

By the way of full disclosure, I did look seriously at Grin for an ASIC. We’re not doing a Grin ASIC but plan to (maybe) write a GPU miner instead. Consider me a friendly adversary ;) I just want a level playing field. If you are hiding the PoW, it is not fair to miner writers who do not have special access to the dev team.

ignopeverell commented 6 years ago

A friendly adversary is welcome. However it seems we have more and more adversaries showing up these days, friendly and unfriendly. A courteous and constructive tone helps in making the difference. Consider that the majority of the team (including John) isn't paid to work on this project.

There have been quite a few lengthy discussions with David Vorick of Obelisk on the Gitter lobby (you can search archives) with numbers along those lines. It's also consistent with information from other sources. If anything, the feedback has been that 6 months to our first hard fork may be too short.

We have no intention of leaving the specs of the ASIC-resistant (AR) PoW unspecified forever, we're just doing our best to balance multiple constraints. Let me ask you this: what do you see as a reasonable and as shortest time frames to publish finalized specs before mainnet?

timolson commented 6 years ago

If it’s ASIC-resistant, why do you need to hide it at all? If it’s crucial that parameters remain hidden, then we cannot call it ASIC-resistant.

If we look at Zcash for an example of Equihash miners, it took about 4 months post genesis before publicly available miners were at 75% of their final stable optimized hashrate. During that time, private miners were cleaning up. An Equihash derivative will benefit from previous engineering, so it’s probably nowhere near that long. But it will take at least two months to put together a decent miner, and you guys effectively have two miners I need to write.

Sorry if my tone sounds off. I am genuinely trying to help with a fair launch. I’ve been approached by big miners to write software for them and have well-founded concerns about the equity of miner performance at launch. I just think being open about everything is in the best interest of everyone. Isn’t that the spirit of crypto?

I’ll shut up now.

tromp commented 6 years ago

Our 2nd PoW is not inherently ASIC resistant. Almost nothing is. Progpow claims to give only a 20% efficiency benefits to ASICs over GPUs, but that is very much unproven. So we use "ASIC resistant" in the sense of Monero, relying on frequent changes to to brick any ASICs.

Announcing 2nd PoW details is thus a trade-off. Giving more time for miner devs to optimize GPU code also gives ASIC manufacturers more time to rush out a miner. The latter has a lot more "cleaning up" potential though.

We’re not doing a Grin ASIC but plan to (maybe) write a GPU miner instead.

Why don't you try to claim a GPU bounty? Or were you thinking of keeping your miner private?

timolson commented 6 years ago

I agree nothing is ASIC-resistant really.

I tried to search Gitter for that conversation with Vorick, but the archive search isn't giving me anything. 2 months from design to chip is just ridiculous. There must be some miscommunication, misunderstanding, or caveats there.

I have no problem with the Cuckoo Cycle part of the mining; that has been well documented for a long time, thanks John. It's the mystery PoW which is the problem, especially when it's overweighted at the beginning. People with inside access to your project are developing and optimizing, while I can't even start. Not fair.

As for the bounty, $10,000 is an amazing amount for a bounty and shows your earnestness. However, even an inexperienced software developer makes that amount in a month, and compared to revenue from a successful miner... We can safely assume Claymore makes orders of magnitude more. I noticed he did collect one of the bounties, which is rather generous on his part. But the fact that Proton miner was someone's first effort at writing a GPU miner should say it all. You must assume that most optimizations have been, and will continue to be, kept private, until most everyone figures them out.

My plan would be a closed-source release, yes, but publicly available. I think that's a reasonably fair compromise between public interest and getting paid. Like I said, I've rejected private offers and know that big farms are developing their own miners in secret. I don't want to be that guy.

I just want a fair chance to compete. You're hiding the PoW from the public, but I can't believe you've successfully kept the secret from all interested parties, especially those with ties to the project.

lehnberg commented 6 years ago

I tried to search Gitter for that conversation with Vorick, but the archive search isn't giving me anything.

@timolson see these links, you might need to scroll a bit before the fun kicks off:

...obtained via old issues of GrinNews™ ;)

tromp commented 6 years ago

People with inside access to your project are developing and optimizing

Nobody knows what the 2nd PoW is going to be; it hasn't been picked yet. Nobody is developing or optimizing.

I'm still busy rewriting my solvers from cuckoo to cuckatoo. Then I may need to help with getting dual-pow ready for testnet T4. After that we can start looking at the choice of 2nd PoW.

Claymore makes orders of magnitude more. I noticed he did collect one of the bounties

No; Claymore is only mentioned on my page for donating to the bounty fund.

It was Photon who claimed the GPU bounty, with the "GrinGoldMiner".

ignopeverell commented 6 years ago

I'll second that: right now nobody knows what the 2nd PoW is going to be. John and I have some ideas but they likely differ and haven't had time to hash it out very much. We're both provably busy.

timolson commented 6 years ago

Ok then I don’t have much to complain about. Please give us time though.

If I may offer an opinion, the most ASIC resistant approach is still to tie the PoW to DRAM which is by far the most commoditized part. Access large enough blocks to hide the latency (32 bytes per access) or else SRAM will outperform, and avoid the lazy-evaluation technique that sunk Scrypt.

Thanks for the convo.

dewdeded commented 6 years ago

Maybe cooperate in research with Monero devs and scientists on https://github.com/tevador/RandomJS PoW

tromp commented 6 years ago

I don't believe in that approach. I expect ASICs to vastly outperform CPUs on RandomJS.

timolson commented 6 years ago

I’ve been aruging with the Monero PoW team trying to convince them that RandomJS will have fast ASIC’s. They’re trying to improve the PoW to be fair, but IMO it’s futile. Tromp’s right; it’s not a good approach. I know what I’m talking about: https://github.com/altASIC/Open-CryptoNight-ASIC

timolson commented 6 years ago

BTW, Vorick does not think 3 months for a new ASIC. It’s 4-5 for “tweaking” an already-existing chip, which I’d agree with. If it’s a new PoW it takes considerably longer.

https://blog.sia.tech/the-state-of-cryptocurrency-mining-538004a37f9b

Waiting to reveal the new PoW until close to launch will only cause high disparity in miner performance at Genesis, accruing the largest share of early Grin to the miner whose implementation is (far) better than others. It takes time for disparity in implementations to narrow... look at the development of Cuckoo miners for example. Your own public miner has gone through many revisions with many different approaches, gained tremendous speed along the way. Imagine if someone had a mean miner while everyone else is using simple miner. That’s what you’re setting up for by hiding the second PoW.

ignopeverell commented 6 years ago

It's coming, give us a bit of time. Remember there aren't that many of us contributing to Grin, and we have quite a few other things to worry about beside PoW.

We're focused on T4 at the moment, once that's released we should be able to come up with a spec of the 2nd PoW (which we're not hiding, as we've made clear before, we just haven't discussed it in detail yet).

ignopeverell commented 6 years ago

Closing this as it was meant to track all the changes to adopt a dual PoW for T4. We'll create another PR in a bit to track the changes to the ASIC-resistant PoW for mainnet (and in a less measure, the changes to the ASIC-friendly one).

tromp commented 6 years ago

On Sun, Oct 14, 2018 at 7:00 PM Tim Olson notifications@github.com wrote:

Waiting to reveal the new PoW

Here are our plans for the Asic Resistant PoW:

https://www.grin-forum.org/t/choice-of-asic-resistant-pow-for-gpu-miners

regards, -John