After a few months of debate, development and testing, NeoScrypt is ready for public. It is the next generation proof-of-work algorithm designed to replace Scrypt. It consumes less memory than the latter yet is more memory intensive and stronger cryptographically. Combines power of Salsa20/20, ChaCha20/20, BLAKE2s and FastKDF into a secure ASIC resistant solution. It isn't some kind of Scrypt-Jane or Scrypt-N or whatever.

NeoScrypt, a Strong Memory Intensive Key Derivation Function (white paper)

NeoScrypt - the latest proof of work algorithm (press release)

NeoScrypt (source code)

NeoScrypt CPUminer (source code)

Implemented in Phoenixcoin v0.6.6.0 already and waiting for a hard fork at block #400K (~10th of August). Phoenixcoin testnet runs with NeoScrypt since the 17th of July. Feathercoin will switch to NeoScrypt when a GPU miner and pool software are ready. Updates will be posted in this thread.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

All above this line is original announcement by Ghostlander.

Please spread the word!

Related threads at Bitcointalk:

https://bitcointalk.org/index.php?topic=712650.0 -main thread

https://bitcointalk.org/index.php?topic=649737.0

https://bitcointalk.org/index.php?topic=704588.0

https://bitcointalk.org/index.php?topic=707376.0

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Most important parts of the press release:

As of the 26^th of July 2014, NeoScrypt will be the latest proof of work (PoW) algorithm to hit the cryptocurrency world. It has been designed as an "ASIC-resistant" algorithm for GPU and CPU miners. The first alt-coin to adopt NeoScrypt will be Phoenixcoin, soon followed by Feathercoin.

Why NeoScrypt?

As Application Specific Integrated Chip (ASIC) devices transformed the world of SHA256 (e.g. Bitcoin) mining, ASIC devices for Scrypt currencies threaten to do the same thing. The technological arms race that this technology creates means that those who have invested heavily in GPU mining would potentially lose their investments overnight.

NeoScrypt, a strong memory intensive key derivation function, was developed by John Doering (aka "Ghostlander"), a developer for Feathercoin and Phoenixcoin, to tackle that problem.

John Doering, developer for Phoenixcoin and Feathercoin

"Mining is not the perfect way to manage coin distribution and transaction processing, but there is no better alternative. Since mining cannot be avoided, it's better to keep it as decentralised as possible. This protects the network from interruptions and abuses.

If ASICs were inexpensive and affordable for most people, then currency networks would not become as centralised as, for example, Bitcoin has.

On the other hand, computer processors (CPUs) and video cards (GPUs) are produced in large quantities by several vendors and many people can afford them. Whereas ASICs are more expensive, depreciate very quickly and have little to no value outside of mining."

Feathercoin's founder, Peter Bushnell (aka Bushstar), also said:

Advantages and Specifications

"Avoiding ASICs forever may not be possible, but the current version of Scrypt makes this easier than it should be, as it uses relatively weak components that have been broken by differential analysis, this means you can get the same result without going through the process expected by Scrypt design. This is why you now see cheap ASICs for Scrypt coins coming out. We are moving to a hashing solution that uses stronger components that have not been broken yet and should not be for the next decade at least. The performance and cost of NeoScrypt ASICs would be prohibitive and this is the best way to protect the decentralised mining of Feathercoin."

NeoScrypt will replace the Scrypt PoW algorithm, initially in Phoenixcoin (block #400K, expected to be the 10th^th of August) followed by Feathercoin. Scrypt was made popular by Litecoin. The hashing technologies used by this algorithm starts with PBKDF2-HMAC-SHA256 key derivation, and ends with 8 rounds of the Salsa20 cipher as its mixing engine. However, it has been shown that only having 8 rounds of Salsa20 can be broken through differential cryptoanalysis (source).

Doering created NeoScrypt to be compatible with Scrypt, but has functional differences which provide advantages over Scrypt. He has written a custom key derivation algorithm which is stronger and faster.

Furthermore, NeoScrypt's mixing engine employs 20 rounds of Salsa20, followed by 20 rounds of ChaCha20 (read more about Salsa and ChaCha here). Not only is this combination faster and more secure than standard Scrypt, but it only takes 32Kb to 64Kb of memory, compared to the 128Kb of memory used by Scrypt.

NeoScrypt based currency is set to become the best option for those who have a low to medium budget for mining equipment and therefore cannot afford ASIC rigs.

Mining

Feathercoin has always been a community focused altcoin. With that in mind, its adoption of NeoScrypt will ensure that its loyal miners will still be able to viably mine by not competing against miners who have bought Scrypt ASICs.

Peter Bushnell said:

When the Neoscrypt source is released, a functional CPUMiner will already be available. However, as the code is open, those with the skills necessary to create the first open source GPU miner for NeoScrypt are highly encouraged to do so. Bounties have been issued for this work.

"It is clear that Scrypt ASICs are going to be expensive so the smaller hobbyist miner is going to have no place left on Scrypt based coins just like GPUs have no place on Bitcoin any more. Only those with deep pockets can mine Bitcoin and this will end up being just a few large companies. This does not make a good case for decentralisation."

Having Pheonixcoin available to test NeoScrypt on should greatly help development of third party software like pool software and miners. Once the necessary tools are available Feathercoin will release NeoScrypt onto its network

Release notes

Phoenixcoin will use the new hashing algorithm from block 400K, which will fall on the 10^th of August 2014. Feathercoin has said that it will make an announcement on the timing of its hard fork in plenty of time for everyone to test the new miners and be sure that the community is ready for such a major shift.

Most important part of the whitepaper:

3. 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. [5] 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 2^255

to 2^251with 50% success probability. It was improved by Shi et. al [7] in

2012 to 2^250. 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 [3].

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) [8]. 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 [9] 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.