Topic: NSGminer v0.9.4: The Fastest NeoScrypt GPU Miner - page 33. (Read 221777 times)

It may take years to see any NeoScrypt ASICs.

1) NeoScrypt is much different to any existing algorithm including Scrypt, so it's unfeasible to implement it as a by-product to them;
2) NeoScrypt market share needs to exceed 100M USD in order to justify the ASIC development costs and it isn't going to happen any time soon.

The idea of developing neoscrypt for Feathercoin was not to prevent ASICs all together, but prevent Scypt ASICs. Litecoin has a huge hash rate advantage such that pools or large players can coin swap to attack the Feathercoin network. The idea being that, at a later stage, an ASIC would be developed just for Feathercoin.

I am just pointing out that we could design the ASIC first, then change Feathercoin to compatible algorythm. As opposed to designing the ASIC to do neoscrypt.

(Note. Ghostlander implemented the new hashing algo in Phoenixcoin first, Feathercoin will not swap algo till GPU miners are available.)

I am not sure what you are trying to say here?

Feathercoin can be switched back to a compatible ASIC at any time in the future, in the same way it is opting out of Scrypt ASIC mark 1. The ASIC development could be done backwards,,

1. Develop an ASIC that can only be run on one algoryth (not scrypt)

2. Change Feathercoin Hashing Algorythm to accept those transactions including updated miners for ASIC and GPU.

I'm excited to get mining again 

Awesome, now the only thing which needs to be developed is the GPUminer

thanks!

Supplied with the PXC v0.6.6.0 wallet, 32-bit and 64-bit.

A cpu miner for windows? 

NeoScrypt Pool Modules Released:

NOMP MultiHashing PR: https://github.com/zone117x/node-multi-hashing/pull/26

Stratum Algo Module: https://github.com/ahmedbodi/neoscrypt_python

Stratum Mining Repo: https://github.com/ahmedbodi/stratum-mining-multialgo

^ You need to choose Algo 9 in the config


BTC Address for any Bounties/Donations for the hard work:  1NSm8i7R1JerA9SdbxaUPUQeTZLfoUkEeb

Ahmed

No official numbers until GPU miner is tested. If anybody gave you numbers like 30% it is from thin air.
Testing is needed first.

Any numbers to indicate this new algo is energy efficient, compared to X11, FRESH, WHIRL, etc? Scrypt generates a lot hot, if NeoScrypt is doing the same or not less significantly, don't see a good point people will be on. Or if the memory is the point with with ASIS will never arrive.

I am curious to see how Nvidia and their maxwell chips will fair with this algo....

Thanks for all your hard work Ghostlander

Neoscrypt, a Strong Memory Intensive Key Derivation Function
Neoscrypt，一种超强的强化内存型加密算法

ABSTRACT. Hereby presented a new password based memory intensive cryptographic solution designed for general purpose computer hardware. A particular 32-bit implementation is described and evaluated.
摘要——特此呈现一款新的专为普通计算机硬件设计的内存密集型加密解决方案，它属于一个特殊的32位描述和评价。

NEOSCRYPT SPECIFICATIONS
Although a very innovative design back in time, Scrypt has developed certain vulnerabilities. The first announced differential cryptanalysis of Salsa20/8 by Tsunoo et al.in 2007 did not deliver any advantage over 256-bit brute force attack, but the following research by Aumasson et al. [6] reduced time complexity to break it from 2255 to 2251 with 50% success probability. It was improved by Shi et. al in 2012 to 2250. Although this is not critical yet, better attacks on Salsa20/8 may be developed in the future.

PBKDF2 is a very popular KDF and may be configured to require considerably large amounts of processor time, but it does not require complex logic or significant amounts of memory to operate. Therefore brute force attacks can be carried out on general purpose hardware such as GPUs or custom designs (ASICs) with reasonably low costs.

SHA-256 also allows numerous performance optimisations in this context. It is also worth to mention that Scrypt relies very little on PBKDF2-HMAC-SHA256 strength as it is configured to run in the fastest 1-iteration mode even though 1000-iteration minimum advised in general.NeoScrypt addresses these issues. The core engine is configured to employ non-reduced Salsa20 of 20 rounds (Salsa20/20) as well as non-reduced ChaCha20 of 20 rounds (ChaCha20/20). Both of them are used to produce the final salt as their outputs are XOR’ed into it.

They may be configured to run either in series or parallel depending on application objectives. The default NeoScrypt configuration is (128,2,1). A single instance of NeoScrypt utilises (N + 3) * r * 128 bytes of memory space, i.e. 32.75Kb, in series mode or (2 * N + 3) * r * 128 bytes, i.e. 64.75Kb, in parallel mode. Every run of the NeoScrypt core engine executes Salsa20/20 and ChaCha20/20 1024 times each which might seem inferior to 4096 times of Salsa20/8 of the Scrypt core engine. However NeoScrypt operates with double the memory segment size requiring larger temporal buffers, also with higher round count of each stream cipher iteration as explained above. If approximated to abstract load/store units, NeoScrypt is 1.25 times more memory intensive than Scrypt.
There are no known successful attacks on non-reduced Salsa20 and ChaCha20 other than exhaustive brute force search.NeoScrypt replaces SHA-256 with BLAKE2s which is a further development of BLAKE-256 [10], one of 5 NIST SHA-3 contest finalists. Based upon ChaCha20 , operates with a lower round count of 10, supports keyed hashing, is native little endian and faster significantly than SHA-256 and even BLAKE-256. It could be interfaced directly to PBKDF2 with no need of HMAC. However PBKDF2 constructs derived keys using blocks. It means a minor change in an input datum, such as nonce increment, may not result in an entirely different derived key. A replacement KDF has been developed to address this issue.

FastKDF is a buffered password based KDF which also supports salting. It operates with 2 primary buffers for password and salt each.They must be a power of 2 in size and not less than any input
(password, salt) or output (derived key) data. The default configuration works with 256-byte buffers. Password and salt are loaded initially into these buffers in a repetitive manner until the end of buffer is reached. The salt buffer is modified through operations while the password buffer remains constant. The buffer pointers are set to zero (start) on the first run. When a PRF chosen delivers a digest, a sum of all its bytes modulo buffer size defines the next buffer pointer. The digest is XOR’ed into the salt buffer at the new buffer pointer and the next iteration starts. If a read or write operation goes past a buffer end, it is continued from the buffer start. BLAKE2s is configured to operate with 64-byte input (password), 32-byte key (salt) and 32-byte output (digest). When the final FastKDF iteration is completed, the password buffer using zero buffer pointer is XOR’ed into the salt buffer using the last buffer pointer to produce the derived
key of length required which is copied into the output buffer. FastKDF-BLAKE2s is configured to run through 32 iterations by default. It is little endian for easier deployment and additional minor performance advantage on popular general purpose computer hardware.

If there is a working GPUminer we are able to tell.

any idea's on possible expected power consumption at this stage? or to early to be
able to tell that.

fantastic

Nice to see active development on both coins! Hopefully other coins will follow and save themselves from those bad ASICs

How am I going to get any work done today with the white paper out?!

Now someone go code yourself an awesome GPU miner!