Changing the hashing algorithm
-
DarkCoin uses eleven different hashing functions, the BMW one you linked in being one of them. Thinking about it we should probably aim for the better known solutions as the extra exposure should reduce the risk of undiscovered vulnerabilities.
I think good idea will be implementing single hashing function ( not used until now and BMW was just an example ) and giving support for it via CPU and GPU cuda + opencl based miners. This way we will be original, will be ready to get the old + new GPU users and there won’t be a reason for someone to point at feathercoin as not original or stealers… This way if we reach the point of building ASIC processors for it we will be one #win coin.
Another important thing we fail to deliver is support software and services for fethercoin ( blockchain dot info, coinbase like services, wallets mobile + desktop ). Yup I’m aware that this services must be delivered by investors…
-
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?
I welcome this idea, though it needs to be discussed with our development team members. Maybe other coin developers would also like to join this adventure.
Presumably it’ll wear a GPL license anyways? … in that case I don’t know that it’d matter that much. You make a good point, but for a community that talks about marketing and spreading the word… just being devils advocate Bush-man >:D
Any GPL code isn’t acceptable because it cannot be integrated into the BSD/MIT licenced code of Bitcoin and its derivatives.
-
Any GPL code isn’t acceptable because it cannot be integrated into the BSD/MIT licenced code of Bitcoin and its derivatives.
I didn’t know it was MIT! Thanks for the correction. I made a silly assumption…
-
…And back on topic, I think you made a good point about widening the net to other coin devs too.
-
I like where this idea is headed. Keeping the mining distributed over a wider selection people is beneficial not only from a blockchain security perspective, but also from an adoption perspective.
-
MegasCrypt :D
-
Seeing as keccack won the sha3 competition because it was innovative in its design but ultimately slower than the skein entry could this be a candidate for scrypt replacement.?
Edit:
I see darkcoin use this as well.
Greedy darkcoin. Lol -
I read the graph that Calem posted wrong, the lower score is better with Blake2 coming out best. Blake is actually the evolved version of Salsa that we are currently using. I’m happy to take Ghostlander’s advice on what is most suitable as he is the most informed person on this and he came up with this ingenious idea. Right now I do not believe that this is urgent, GPU miners will only start looking for alternatives when the Scrypt hash starts climbing rapidly and their kits stop generating a profit like we saw with Bitcoin.
If we can come up with a working specification then we can take this to the altcoin forum on Bitcointalk to gain interest of other altcoin devs.
-
OK , Can we consider adding POS system ? POW + 25%POS . This is another way can be selected.
-
the NeoScrypt
-
I was thinking more about names last night. Another suggestion that’s much less obvious. “Idavoll”, from what I remember it’s a place in norse mythology untouched by the battle of Ragnarok (end of the world). Those that meet up there take the seeds of Idavoll and use them to reseed the scorched lands.
If you think of ASIC landing as an ‘end of the world’ event, it works.
-
I was thinking more about names last night. Another suggestion that’s much less obvious. “Idavoll”, from what I remember it’s a place in norse mythology untouched by the battle of Ragnarok (end of the world). Those that meet up there take the seeds of Idavoll and use them to reseed the scorched lands.
If you think of ASIC landing as an ‘end of the world’ event, it works.
Nice!
-
It should be possible to create installable binaries together with a basic configuration… :D
-
OK , Can we consider adding POS system ? POW + 25%POS . This is another way can be selected.
If you mean Peercoin PoS, it breaks existing FTC coin distribution model and offers unlimited coin stake generation over time. Peercoin controls inflation by destroying transaction fees.
-
Or implementing unique PoW that really solves some problems that require processing power ( Primecoin like )
-
Improved algorithm relies on the CPU . XPM is a reference.
-
If you mean Peercoin PoS, it breaks existing FTC coin distribution model and offers unlimited coin stake generation over time. Peercoin controls inflation by destroying transaction fees.
I have seen that sometimes the destroyed transaction fees are greater than the stake generated.
Something that occurs to me, it is presumed that we are attacked by resources that are intended for Litecoin. Warren from Litecoin said as much when he took the time to attack us on the Litecoin forum when he thought we were going to be removed from BTC-e. Moving to a new algo stops a huge amount of hash easily being thrown our way to toy with our difficulty. We need to get out of Litecoin’s shadow as the pioneer’s for altcoins are not altcoin friendly. Oh the irony.
On a side note Warren appears to be an excellent dev who has made good progress with Litecoin, he may not like us but we can still like him :)
-
I kinda changed my mind about changing the algo. I think if we do a switch to a new algo which isnt present at the moment, we could come out big of this.
But Ive got some concerns about that:
At the time we switch to a new algo, all hashing power will be rejected, everyone needs to update to a new miner to continue mining
-
How would we calculate the new difficulty?
-
How long would it take, cause in this switching time, nobody could sent/receive any Feathercoin at that certain point.
-
If we stay at the same diff ~200 and not all are switching to our new algo or not fast enough, it would roughly take a good bunch of minutes to solve the first block to proceed transactions again.
-
Next Question is, a new algo means a new/different hashingpower - or would it stay the same? If it wouldnt, its needed to recalculate the whole difficulty to transport it to the same level as we left it on the algo switch.
BUT if that can be managed that well, that the transfer is one smooth transition, we gonna rule the #world (jk but yeah that would be awesome)
Just my opinion.
-
-
very valid points, ChekaZ
I think, we are just in the initial phase, where an idea is born. Then there will be a developement, a test and an implementation phase.
Some of your questions can’t answered right now, but will be later.
Regarding the new difficulty calculation,with the new algorithm, that will be implemented with 0.8.6.1 the difficulty adapts much faster to hash rate changes and therefore it should be no problem, even if we would start with a very low hashrate, let’s say 50.
If we assume, that the real hashrate would be ~3Ghash after the change, the difficulty would adapt in 3-4 blocks and we would start with 2blocks mined very fast and then come back to the 2.5 minutes interval again.
The bigger proble I see, is that we may end up with 2 different branches of the blockchain, one with the old version and another one with the new one.
How could a wallet decide,which one to use, when sending ftc?
-
@CheckaZ
When the new algo hits everyone would need to stop their miners and start them back up again. We would probably want some miners running the new algo before hand which would generate rejected shares until the change. The difficulty is probably the hardest thing to get right. Some of the large mining pools may not follow us to start with and there will be no multipools switching on to us anymore so our difficulty will need to drop drastically. We could drop our difficulty 10 fold and it might still not be enough! It is probably safer to drop our difficultly too far than have it too high, there may be some fast blocks it will work out the new difficulty quick enough that way, leave the difficulty too high and we may be waiting an hour a block!
Ghostlander’s suggestion on how to change algo would give us a solution that behaves in the same way as the current one. I look forward to seeing a lower diff without attackers toying with it and multipools stripping us,
I would not to consider changing the hashing algorithm without something like ACP to cover the vulnerabilities during that period. Hopefully in the long term this change means that we can disable ACP by default but during the change we need this protection more than ever. An attacker could really run riot while everyone tries switching algo.
