Quote from: talkmeout on June 04, 2020, 08:42:38 PM

Quote from: SteamCoin on June 04, 2020, 09:23:57 AM

Quote from: talkmeout on June 03, 2020, 01:47:36 AM

Quote from: SteamCoin on June 01, 2020, 02:15:47 AM

Quote from: talkmeout on May 31, 2020, 09:25:50 AM

Quote from: SteamCoin on May 28, 2020, 02:59:52 AM

Quote from: talkmeout on May 27, 2020, 03:54:26 AM

Quote from: SteamCoin on May 27, 2020, 03:50:12 AM

Quote from: talkmeout on May 25, 2020, 06:13:56 AM

Quote from: SteamCoin on May 24, 2020, 01:37:40 AM

Quote from: talkmeout on May 23, 2020, 10:25:20 AM

Quote from: SteamCoin on May 22, 2020, 05:32:43 AM

Quote from: talkmeout on May 21, 2020, 05:37:33 PM

Quote from: kushti on May 20, 2020, 09:43:40 PM

Quote from: tromp on February 21, 2020, 03:49:49 PM

Quote from: kushti on February 21, 2020, 08:08:09 AM

Quote from: tromp on February 12, 2020, 06:22:45 PM

Quote from: kushti on February 05, 2020, 12:49:00 PM

- New Proof-of-Work scheme, Autolykos a variant of Equihash with better ASIC-resistance

How does it have better ASIC resistance, when Equihash is claimed to have superlinear time-memory tradeoffs (TMTO)
while Autolykos can be solved with no memory and constant slowdown?

IMHO it's closer to Ethash than to Equihash.

Autolykos is pretty close to Equihash, it is based on k-sum problem , but also adds a signature component for somewhat pool-resistance. Parameters are chosen in order to be much more memory-intensive (and memory-bandwidth intensive) than ZCash's and other popular Equihash coins PoWs.

Autolykos is very different from Equihash in memory requirements.

Equihash searches for an arbitrary size 2^k subset of indices,
whose corresponding items must xor to 0 (as well as satisfy
other conditions on the ordered binary tree of indices and items).
Memory is needed to sort and combine partial solutions.
Without memory, finding a solution would take longer than the age of the universe.

Autolykos instead generates the possible subsets as genIndexes(m||nonce),
as shown in Algorithm 1 of https://docs.ergoplatform.com/ErgoPow.pdf
The element at an index j is trivially computed as H(j||M||pk||m||w)
No memory at all is required for that.
It could be used to cache the hash computation of elements, but that is at best
a constant factor speedup.

Ah I see. We're discussing it, see https://github.com/ergoplatform/ergo/issues/1100 (are you BigEvilSoloMiner aka AsicResearcher maybe though? )

Oh actually I was wondering about it too, thanks

Yeah, that's definitely very helpful and useful!

I totally agree with you Wink

When Ergo pump Grin

All in good time, but I think on the wave of good news (and I'm sure there will be more)!

You're definitely right, and a little marketing will help

They're marketing, they're getting Ergo on social networks more and more, and it's pretty awesome!

Yeah, I've noticed that, as well as the fact that the community is increasing a lot (there is really a percentage of people who came because of the recent airdrop)

Yeah, and it's very awesome, and, I hope, important

Yes, it's really important, no doubt. Because the product must have an end-user!

As I told you in the other topic, the product will definitely find its end-user, because the project is very good!

Since the project is very technically oriented, it avoids any unwanted folks, which is a kind of a plus

It's okay, it's not a hindrance at all

Well, I agree, but only partially, and also, listing to other exchanges will be very helpful to the project