Old daemon and wallet version 0.18.3
Changing the hashing algorithm
SHA-256 ASICs are expensive and Scrypt ASICs are going to be even more pricey due to higher memory size and bandwidth requirements. If we want to reach as many people as possible, we want to stay with CPU and GPU miners.
It’s a dead end to increase N factor constantly like YAC and VTC do. GPUs run out of memory quickly and become very inefficient, so they switch elsewhere. Only CPUs remain, but it means botnet mining in fact. This is even worse than ASICs.
The idea is to modify the LTC Scrypt to make enough trouble to ASIC designers while keeping the modifications easy to implement and maintain, so we needn’t re-invent the whole tool chain of mining software. In addition to scrypt(1024,1,1), the LTC hashing engine also uses Salsa20/8 at the initial stage and SHA-256 at the final stage.
lizhi last edited by | Tip lizhi
YACoin differs from other cryptocurrencies in its usage of these newer technologies:
- Proof of Work key derivation function known as Scrypt.
- The N parameter of Scrypt(N, 1, 1) increases over time and 256 bits of its output are used by the YACoin protocol.
- SHA-3/Keccak-512 as a hashing used in Scrypt
- ChaCha20/8 stream cypher used as a mixing function in Scrypt
Another random algo I came across was Poly1305-AES.
Could this be used?
Saw it mentioned here:
OpenSSH Has a New Cipher â€" Chacha20-poly1305
First time accepted submitter ConstantineM writes “Inspired by a recent Google initiative to adopt ChaCha20 and Poly1305 for TLS, OpenSSH developer Damien Miller has added a similar protocol to ssh, [email protected], which is based on D. J. Bernstein algorithms that are specifically optimised to provide the highest security at the lowest computational cost, and not require any special hardware at doing so. Some further details are in his blog, and at undeadly. The source code of the protocol is remarkably simple â€” less than 100 lines of code!"
So I had a post prior to my previous… I think I must have accidentally deleted it… I was asking about the difference in BLAKE2b and BLAKE2s
BLAKE2 comes in two flavors:
- BLAKE2b (or just BLAKE2) is optimized for 64-bit platformsâ€"including NEON-enabled ARMsâ€"and produces digests of any size between 1 and 64 bytes
- BLAKE2s is optimized for 8- to 32-bit platforms and produces digests of any size between 1 and 32 bytes
Wouldn’t changing to an equally memory intensive Algo only make us Asic proof by obscurity?
I totally agree with you Bushstar I believe this is a great evolution if we want to keep Feathercoin accessible for the many and not for a minority of asic owners. i hope this idea will become reality
I think the idea is, is that maybe we could say, develop an asic miner for ourselves…
An open source one? Get a minor prototype running and releasing it to the world?
Forgive me here, but I’m thinking the idea was this.
Bitcoin owns the SHA ASIC’s
Litecoin will ultimately own the Scrypt ASIC’s
Feathercoin should be the next in line to be the predominant coin of it’s own new algo.
The change would have to be done sooner rather than later because once the Scrypt ASIC’s are out, we may have lost our chance of changing without ruining the coin in some manner shape or form.
It’s just a matter of finding the right change that:
a. can still be mined on gpu’s to the same efficiency.
b. having it so an ASIC miner for it can be produced cheaply and efficiently
c. done so we don’t have to “re-invent the whole tool chain”
d. can successfully make the network changeover of algo’s swift and painless.
If this could be coupled in with a planned open-source ASIC miner, then ftc could have a chance of “having it’s cake and also eating it”, the same way btc does and ltc probably will.
If the plan is to support GPU mining, then we should aim to be masters of it, perhaps the best algo then, is the one which is best suited to the GPU and should be able to take advantage and benefit from future improvements in both GPU mhz improvements and GPU RAM increases.
The exact technical details of the “upgraded” Scrypt will have to be investigated. We probably have a good idea of where to start, SHA-3 for the hash function and replace Salsa with its newer variant Chacha. Looking at your graph Calem blake is slow but it is based on Chacha and there may some reason for the lag in performance. I have not looked into Blake enough yet to know if Blake can actually be used in place of Salsa or provides a subset function.
I agree with the discussion and will consider the options.
These are the points I see for maintaining ASIC scrypt compliance.
1. The scrypt ASICs are no.2, so it is wrong to assume they will follow the same development path as Bitcoin SHA 256 ASICs, since the chip companies are already competing and there is no pre order (+ Butterfly Labs (eek!)).
2. The scrypt memory component, and improvements in GPUs, will mean GPUs will be usable by “hobbyists” for a longer period than with Bitcoin.
3. There may be no 3rd round of ASICs as Litecoin and Bitcoin and Feathercoin will miss the merchant deployment boat, from the efficiency point of view…
4. Mulipools are already ruling, so hobbyist miners may be old Skool any way.
1. Alpha-T took pre-orders. Their units were around $5k for 5Mh if I remember right, last time I looked they had already hit issues with power requirements being more than in simulation. I think they are going to go through some of the learning curve that BFL and others had to go through beforehand.
2. You could well be correct. The BFL 60GH unit was half the price of Alpha-T 25MH model and offered the performance of 90x 7970 where as Alpha-T offer the performance of 37x 7970 for twice the cost. This shows that the threat from first generation Scrypt ASICs is not as great as first gen SHA-256 ASICs. Scrypt ASICs may one day rule but not straight away.
3. This may well be the case which I do not see as a problem. We want to make this move and not be alone so that the new algo can be a standard for GPU coins going forward. This would certainly make it more viable for future ASICs to exist but more importantly optimised tools like mining software.
4. I do not personally believe that multipools are de-facto. There is a lot of hashing power on dedicated pools for various coins.
5. Would this have any effect on Link and Flux? It’s kinda important these still remain as a part of feathercoin.
Tech that relies on and uses the blockchain can continue in the same way they did before.
One of the biggest tasks is going to be choosing a name I’m going around talking to people about “new Scrypt”, we need something to refer to it by.
PostScrypt or TranScrypt
Or even better, SuperScrypt
*edit* or should that be SuperScrypt
PostScrypt or TranScrypt
Both of those sound kinda appropriate!
Although we could wait till weve settled on the algo mix first and try derive a name from that?
I’m kewl either way
PostScript already exists in the print world, so perhaps Post_Scrypt_ is a little too similar/confusing… maybe not though, it just sounded wrong to me.
The name game is fun though!
FeatherScrypt (obviously links it to the currency that it evolved from)
SubScrypt and SuperScrypt
PostScript already exists in the print world,
That’s kinda why I liked it haha.
*edit* or should that be SuperScrypt
That’s epic also
FeatherScrypt seems a little like we are taking ownership of it and this should be for everyone. Cryptocoin communities are far to segregated and this may put some off.
As Scrypt with Chacha and SHA-3 seem a possibility there is a miner that is for Yacoin that could be easily ported if not simply work.
It is by mikaelh the same chap who created the HP miner for Primecoin and now works with SunnyKing on Primecoin. mikaelh would be the person to have on board when it comes to an optimised miner.
kris_davison last edited by | Tip kris_davison
could we talk with a few other coins and make this a movement away from scrypt rather than us out on our own? maybe PXC as I see ghostlander has commented in this thread already?