Quote from: b4h4mu7 on April 27, 2018, 01:19:45 PM

Quote from: smooth on April 23, 2018, 11:23:13 PM

Quote from: teknohog on April 21, 2018, 06:43:16 PM

Agreed. Monero's idea of slightly altering the PoW parameters every X months is just whack-a-mole, and doesn't sound like a proper development plan for any serious tech person.

No, but in a sense they did take credit for it by promoting the algorithm as such without making improvements to harden it, so the burden is theirs to carry just the same. I fully agree with teknohog's assumption that their decision to alter PoW parameters every quarter is flawed logic and shows level of amateur design and development going into Monero. It's no wonder why Edward Snowden classifies it as an amateur cryptocurrency project.

Nobody sane would suggest that slightly tweaking the PoW algo every few months is a viable strategy. That's obvious and well understood.

https://github.com/monero-project/monero/issues/3545#issuecomment-378437013

Quote from: b4h4mu7 on April 27, 2018, 01:19:45 PM

Quote from: smooth on April 23, 2018, 11:23:13 PM

Quote from: teknohog on April 21, 2018, 06:43:16 PM

multi-gigabyte memory requirements

Large memory requirements will not in and of themselves make it ASIC resistant. If just the amount of memory is the the main issue, then ASIC builders can just attach a lot of cheap external memory as they are doing with Ethereum ASICs. (Not intended as a review of MTP generally, just the comment about memory usage.)

Or the more logical approach would be to simply just take up an interest in Boolberry and support the superior project. Now that Crypto_zoidberg is back with a full team of developers to support him and the fundamental flaws present in Monero's design it's the only logical decision at this point. Instead of simply migrating to Monero's codebase like Aeon is doing, Zoidberg is making substantial improvements with his own unique LMDB implementation (due for release next week) which leaves 3 unique cryptonote codebases: Bytecoin, Monero and Boolberry.

https://github.com/cryptozoidberg/boolberry/branches

(work on LMDB can be viewed on LMDB and LMDB_Core branches).

https://medium.com/@BoolberryBBR/boolberry-monthly-progress-report-march-ccb7d1433472

Quote from: smooth on April 23, 2018, 11:23:13 PM

(Not intended as a review of MTP generally, just the comment about memory usage.)

Not taken as one, however, our our full review on MTP-Argon2 can be viewed at the ePrint below.

"Itsuku: a Memory-Hardened Proof-of-Work Scheme"
https://eprint.iacr.org/2017/1168

What started as an initial review of Cryptonight, Wild Keccak and later MTP-Argon2 spiraled into full blown R&D of a new algorithm Itsuku. Over the course of the last year we've achieved 1/16th the proof size of the original MTP design and hardened it against all known attack vectors. We also provide proper hardware design for the algorithm. Among other things, the beauty of Itsuku is that memory bandwidth is the limiting factor, not the size, so even 64GiB over 4GiB will not see much improvement. This algorithm will be used in our upcoming Moneda [XMN] and Doubloon [XDB] reference projects. ZCoin and Turtlecoin are the only projects I know of waiting for us to release either reference project so they can use the algorithm in their system.

https://github.com/turtlecoin/meta/issues/74

Feel free to read through it. In section 6, we briefly outline comparative analysis between Cryptonight, Wild Keccak and Itsuku. That will give you a better understanding of the underlying systems here. We plan on releasing another paper that focuses purely on Cryptonight vs Wild Keccak with improvements that will be made to the latter increase egalitarian properties however this will be released after only after our next paper is published.

In our initial discovery we've found that WK is much better suited than CN to retain said properties. As stated earlier the quick and easy solution would be to adopt WK but again at that point you'd be better off just supporting Boolberry as the original developer is back on the project full time.

Fyi, HBM High Bandwidth Memory is a thing. Relying on high latency of data accesses (so-called memory-hardness) is also a fallacy wrt ASIC resistance. The PoW approach I'm working on will succeed because it also mandates instruction fetching - code accesses, not just data accesses. And the instruction stream is highly branchy, with poorly predictable branch frequencies, which will guarantee long pipeline stalls without expensive CPU-style branch prediction hardware.

hyc

Posts

Merits