Changing the hashing algorithm
-
if it is blake we are going for should we not just stick with blakeScrypt or just blake or something.
I agree though these kind of name discussions are not the most productive but thats my two feathers… ill get my coat.
-
I’m guessing the Crypt in scrypt is for Cryptography and not related to any particular algorithm? What’s the S for, just to turn crypt into a clever play on words or does it have a meaning?
-
Sorry if I’m repeating something but has X11 been looked into? (if I understand it correctly it’s a collection of different algos being used?)
-
You could hint at feathercoin origins, without actually branding it.
Ideas like
Rachis (In biology it’s the central vain or shaft from a feather or leaf)
Or perhaps one of the many feathered creatures of legends.
I agree, not a huge fan of NeoScrypt. (wouldn’t say I detest it though ;D )
I like the idea of the sly branding where if you really wanted to dig up the origins you could, but to the layperson, it’s just a name.
Rachis has a coolness to it I think. You could also do something like avian, quill, or wing-script… or not, you get the idea.
-
I am not a coumputer science guy, but why could we not add an additonal sha-256 hash ontop of the scrypt? Would the scrypt ASICs still be able to mine faster than a gpu(7950) ?
-
I guess an additional round of hashing using the sha256 would likely make little difference to a dedicated ASIC.
Essentially a high power graphics card is a lot like a simplified CPU but with many more cores that can be used for lots of different things i.e. gaming mining all different hash types etc.
An asic is a single purpose chip that can be made much more efficient at one single task due to the fact it does not need to be durable or able to perform anything else. This is why a sha256 or a scrypt ASIC could not be used on Feathercoin if we changed to Blake or any other different algorithm.
But ultimately if an ASIC was built for the new algorithm or combination of algorithms it would likely be as effective or more so than a graphics card and use less power.
-
(wouldn’t say I detest it though ;D )
Yeah, hence my back peddling, it’s not the word I was looking for.
-
I would like just one algorithm not multiple ones. The extra work seems anti environmental. I think we should not be against ASICs per say. At the moment I agree, they are being centralising.
-
To be honest I don’t think a name really is important is it? Considering what we’re doing, the name it self would have little impact.
I’m just saying I’m not so stressed, I thought ABC would of been a good one but the more I think about it, a name for the algo is really the last of our concerns at the moment.
-
I think we should not be against ASICs per say. At the moment I agree, they are being centralising.
Isn’t the idea to make our own asic in time?
My belief, was that we wanted to dodge the scrypt asics so we could develop our own open source algo, miner and asic.
-
The problem is, that creating an ASIC is relatively cost intensive and this is one of the reasons for a high price.
The Gridseed alpha test units seemed to be quite cheap in hardware but to build a farm generating 500 -1000 kHash again becomes a rather high invest, that pays back over time. F we talk about 100 -500 MHash, the cost will be close to the already available ASICS.
This high upfront invest drives centralization, as many people can’t affort that.
I doubt, that creating our own ASICs would help here.
-
I actually like the use of Neo in the name. It’s already being associated with Bitcoin (in Cyprus).
-
Another reason not to panic into choosing the wrong solution is that Scrypt or S-Crypt was actually designed to be resistant to ASICs decryption, so intrinsically not as scalable as SHA-256.
https://www.tarsnap.com/scrypt.html
The high speed capability of the SHA256 hashing will be ameliorated by the memory speed for the Scrypt version of any ASIC device. Modern GPUs have the benefit of scale and are making significant improvements in efficacy.
The ASICs will not be as good or as quick to increase in speed for scrypt as they were for plain SHA256. The memory usage is the bottleneck.
Another point in making sure any software release has quality and is stable. We are announcing our probable intention to change, if we feel that scrypt ASICs are centralising the network.
We are certainly entering a new phase of multiple viable coin networks, where a coin will be only require enough miners to ensure the transactions are processed in a secure and consistent manner. With the improvements Feathercoin has already made it is already potentially outperform Litecoin. In particular the increased transaction speed.
As far as testing any new hashing algorithm, the main thing is to prove “how it is resistant to ASICS”, and “does it work?” , is it “the least amount of change for the greatest effect?” “How much inefficiency has it added to the system?”
-
i really like the idea of designing our own. It has 2 advantages I see, 1 if no one else shares it, it is less likely to be worthwhile to try build an asic out of it. And 2 we can build in key features specifically designed to thwart effecient asic design. And as far as making it non-asicable a few thoughts come to mind.
Make the algorithm’s mechanism for the process not static. Maybe have the rules of the logical flow be dictated by some hash. Then if someone does implement an asic, the best they could hope to accomplish is a mechanism that works like a processor and changes its flow based on meta data.
Another thought is to make the algorithm solvable in more than one way. An itterative process that degrades so that the longer you work on the problem the easier it gets to solve but the more resources it takes. I don’t off hand have such an algorithm but it would make asic circuitry reach a limit and have to reset back to the harder problem but try a new seed since it ran out of resources. a cpu based or even gpu based system however could continue to allocate off line storage or memory not available to the asics. In this case that’s ideal cause the next itteration would be easier still to solve … better than starting over. Such a “magic algorithm” would really do wonders. such a system might have 1 solution that can be reached a number of ways or another way to do it would be to have multiple solutions that are all valid like “itteration 1000, seed xx2400” works as does “itteration 2 seed aa4azzz231a”.
The final way that making asics less desirable that comes to mind is having a planned algorithm change. every 9 months the algorithm is changed. which is kind of what is going on right now.
*edit* i realize I’m talking in generalities and this is specifically about making a hash. that in turn is used by looking at leading digits hoping it has a series of 0s. something set up so we can easily adjust difficulty. just take my thoughts in that context.
-
Or once a year? Happy algo change day everyone Lol.
:) -
Yeah, hence my back peddling, it’s not the word I was looking for.
Bad joke, sorry. No offense intended.
To be honest I don’t think a name really is important is it? Considering what we’re doing, the name it self would have little impact.
I’m just saying I’m not so stressed, I thought ABC would of been a good one but the more I think about it, a name for the algo is really the last of our concerns at the moment.
Yeah, you’re probably right. The reason is I’m talking about the name is because I want to feel like I’m contributing. I don’t know enough to make recommendations of the what and how for changing the hash type.
-
The final way that making asics less desirable that comes to mind is having a planned algorithm change. every 9 months the algorithm is changed. which is kind of what is going on right now.
At first this sounds like a totally daft idea, but actually, the more I think about it the more appealing it sounds. It would however demand a mining client that can handle the change of algorithms so you don’t need to switch software every time the algo changes.
-
I like SuperScrypt too. It makes everything else seem inferior.
-
I have been wondering what effect on the block chain the algo change would make?
Is it just the mining that would be affected or would it also affect what is held in the block chain? Would there need to be any specific Code to deal with blocks before a cut off point and blocks after.
This may seem like a silly question to those in the know but if this is the case would every client of the block Chain would need this workaround?
-
I have been wondering what effect on the block chain the algo change would make?
Is it just the mining that would be affected or would it also affect what is held in the block chain? Would there need to be any specific Code to deal with blocks before a cut off point and blocks after.
This may seem like a silly question to those in the know but if this is the case would every client of the block Chain would need this workaround?
Blocks will be mined with one code before the switch and other code after. It also applies to block verification. A hash is a hash no matter what produces it as long as it’s a valid one. There is nearly a zero chance of two blocks to have the same hash even if they’re produced using the same hashing algorithm.
A switch is a hard fork and every client needs to be updated in advance preferably. The mining transition is more complicated.
