Neoscrypt is opensource now!
-
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 26th 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 10thth 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 10th 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.
-
Sweet. Hope we get this up with FTC ASAP.
-
I’m loving the buzz around NeoScrypt right now! Can’t wait until the 10th for the Phoenixcoin switchover
-
We have to say “thank you” to Charlie Lee for his work on Scrypt.
Scrypt made the big leap, similar to fish decision to live on earth.
Now Neoscrypt is like adding legs and real lungs to that fish!
Just tipped him 1FTC ;)
-
:)
-
Thanks for this most excellent read Mirrax and thanks to GL for his hard work in this and thanks to all for spreading the word :)
-
We have to say “thank you” to Charlie Lee for his work on Scrypt.
Scrypt made the big leap, similar to fish decision to live on earth.
Now Neoscrypt is like adding legs and real lungs to that fish!
Just tipped him 1FTC ;)Well, Scrypt was developed by Colin Percival actually and adapted to crypto by ArtForz. Litecoin copied his code from Tenebrix.
-
oh shit, I will request my ftc back then ;)
This is actually great firepower against trolls.
-
I’m guessing some time in the next 24 hours Phoenix coin will transition to Neoscrypt.
I think tomorrow night I will give a go at CPU mining it
-
I’m guessing some time in the next 24 hours Phoenix coin will transition to Neoscrypt.
I think tomorrow night I will give a go at CPU mining it
+1
-
Have you or anyone else made a GPU miner for Neoscrypt?
-
GPU miners are being beta tested as we speak, not quite ready for release yet, but getting close
-
WAITING GAME
