Changing the hashing algorithm
-
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.
-
I could not agree with you more Bushstar. Although, I did not consider the possibility of essentially coming up with our own algo.
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. I also highly doubt they will follow the same path as ASIC gen 2’s but surely it will follow a similar path. The product lifecycle of the gen 3 ASICS will probably be shorter or longer. Either way, we would have to consider if it would be beneficial to choose a hardware setup that will either be cheap and short to develop or long and expensive to develop.
2. This could be a good thing. It will give us a longer period of time to capture a greater market share. (not greater than bitcoin, maybe, but would simply mean more time to gain more loyal miners)
3. Maybe our choice in algo change will determine whether or not an ASIC can be made for us, but surely in time, any algo could have an asic? It might be less inefficient but technology will always improve. Do we think Moore’s Law comes into this in the near future? (by near i mean 30 years)
4. Not sure what you mean here. Are you saying that in the end, regardless what happens in regards to crypto hardware, programming and algo’s, multipools will ultimately win over?
But yeah. I’m fully in support, this is way better than just simply dodging ASICs.
It’s more like just buying ourselves time to rule our own domain.
-
Random thought…
5. Would this have any effect on Link and Flux? It’s kinda important these still remain as a part of feathercoin.
-
I’m fully supportive of this! It’ll have loyal FTC miners to stay profitable for quite a bit of time before multipools catch on us! As we lead on the new algorithms, we’ll get more traction + more loyal miners.
-
Bushstar, I’m glad you have such thoughts . I would like to say goodbye for LTC and Scrypt . The current algorithm is too volatile, mineral pools and miners are facing great risk.
So we can refer to a number of new algorithms coin.
-
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.
Salsa20 was developed by Daniel Bernstein in 2008. ChaCha20 was also developed by him as a further improvement of Salsa20. There are also BLAKE and BLAKE2 based upon ChaCha, very fast ciphers.
-
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.
http://en.wikipedia.org/wiki/Poly1305-AES
Could this be used?
Saw it mentioned here:
OpenSSH Has a New Cipher â€" Chacha20-poly1305
http://beta.slashdot.org/story/195463First 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.
Random thought…
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
Ha! +1,
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 :D
-
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!
Maybe:
NuScrypt
FeatherScrypt (obviously links it to the currency that it evolved from)
-
SubScrypt and SuperScrypt
