Post
Topic
Board Announcements (Altcoins)
Re: [ANN?] Bytecoin (not a Bitcoin fork) + Giveaway
by
tromp
on 14/04/2014, 18:00:26 UTC
As it' s said in their whitepaper CryptoNight is "a new memory-bound algorithm for the proof-of-work pricing function. It relies on random access to a slow memory and emphasizes latency dependence. As opposed to scrypt every new block (64 bytes in length) depends on all the previous blocks. As a result a hypothetical "memory-saver" should increase his calculation speed exponentially".
More info you can get by yourself here.

So scrypt gives us ASIC-resistance, but this algo is much better at this field.
From 128KB (scrypt) to 2MB (CryptoNight) is a factor 16 increase in memory usage.

To improve ASIC-resistance further, you'd like to require hundreds of MB,
but that would make verification even slower than it already is.

Other memory-bound proofs-of-work avoid this problem (at the cost of introducing more parrallellism)
by having an asymmetry between computation and verification.
E.g. Momentum, memory-coin 2, my own Cuckoo Cycle, or Coelho's scheme
( "An (Almost) Constant-Effort Solution-Verification Proof-of-Work Protocol based on Merkle Trees" AfriCrypt 2008, Fabien Coelho)

Nice to see you took note of this, that's good news!

Would you mind going over some of the parallels/differences between some of these PoW's compared to this one? I'd especially like a comparison between this one and yours, as I've read some of your posts about it and have a little bit of an understanding.

I'm not really familiar with MMC2 (I know it uses AES, but not much more) or Coelho's scheme though.

I'll stick with         CryptoNight      vs      Cuckoo Cycle, assuming a size 2^{32} for the latter
memory                2MB                         512MB
memoy-hardness   solid                         can run twice as slow in 384MB, or 50% faster in 768MB
                                                          hardness hypothesized; not proven
parallellizable        not                          at least 20+ threads (probably less than 100)
access pattern       random                     random
latency                 low (cache)                high (main memory)
verification            slow                         instant
%computation       probably > 90%          33%
%memory             probably < 10%          67%