Changing the hashing algorithm
-
The idea of changing our hashing algorithm when Scrypt ASICs arrive came up early on in the days of Feathercoin as one of the first points I made was that more Scrypt coins were needed with the advent of SHA-256 ASICs. Now we can see that Scrypt ASICs will soon become a reality.
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. Personally I purchased a BFL 60Gh miner which retailed for $2,599 is pretty much useless now (I sold 20,000 Litecoin to buy that BFL, fool on me!). 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.
The fact is that Litecoin rules Scrypt hashing and we compete with them for their hashes. We do not have a great enough share and I expect that we will suffer at the hands of those first few who own Scrypt ASICs. From history you can see that Terracoin got heavily abused by ASICs and had to hard fork to protect themselves, they went through this process as they got attacked by ASICs several times and were often left with crushing difficulty.
What made Litecoin in the first place was that it was at the top of the Scrypt tier of coins. When I started in crypto everyone could see that ASICs were going to become a reality so I moved directly into Litecoin. When ASICs hit all GPUs started moving over to Litecoin, now Litecoin pretty much own GPU mining. What we have here is an opportunity to be top in a new tier of crypto and move out of Litecoin’s shadow.
There is the potential to be the next top GPU coin with a move to a new hashing algorithm. However the current choice out there is not the best, there are a few Scrypt-Jane coins which do not perform well on GPUs and some other coins choose a blend of hashing solutions like DarkCoin and Quark that will have trouble getting truly optimised for GPUs. A solution is required that provides the same efficiency of Scrypt for GPU miners and this should be achievable.
I spoke to Ghostlander last night who was talking about replacing Salsa and SHA-256 in Scrypt with Chacha and Keccak. There is a coin called Yaccoin out there that uses this but has variable N. The current flavour of Scrypt uses (1024,1,1), where Yaccoin uses (N,1,1) and N is variable which makes it inefficient for GPU as well as ASICs. Yaccoin was intended to be a CPU coin but was quickly ruled by virtual machines which could run hundreds of vCPUs.
I suggest that we earnestly look into a version of Scrypt with the same settings as the current solution but with replacement Salsa and SHA-256. If people were buying ASICs to mine Feathercoin I do not think that we could make this move, imagine if Bitcoin changed their hashing algorithm. People are not buying ASICs for us but for Litecoin mainly. Let’s leave Litecoin to Scrypt as people have left SHA-256 to Bitcoin and move to a new tier where we can be one of the predominant coins.
We could feel safe if people were building ASICs for Feathercoin as the hashes will safe guard us but on Scrypt as we stand they are more of a threat. We cannot run from ASICs forever but right now it could well be the right choice and we get to stay in the realm of the regular user.
With all the GPU mining coming to Feathercoin we would be in a position to disable ACP. In case of attack people could enable by their own choice. You could imagine that this would not happen unless a Government decided to attack our network. It may appear completely redundant.
Let me know what you think.
-
It seems like a very sensible and well documented option.
To be precise I really appreciate sentences like “realm of the regular user”; as you pointed out only the big money industries will be left mining when prices get prohibitive and that’s not good for the decentralization.
Just keep in mind that FTC is still a CPU mineable currency and it would be great if it could remain like that after the algo change. I know it utopy but…
-
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
