Scrypt Jane Research - Post Ideas Here
-
N = 1024, r = 1, p = 1
N must be a power of 2 between 1 and 2^(128*r/8). Any of three parameters above can be changed. Increase of N and/or r (block size parameter, B = 128*r) and/or p (parallelisation parameter) decreases performance. N*B memory per instance required.
My concern is what kind of scrypt-jane are we going to implement? YACoin replaced Salsa20/8 with ChaCha20/8 (mix function) and SHA-256 with Keccak-512 (hash function). ChaCha20/8 seems to be a good choice since it’s both faster and stronger than Salsa20/8. Keccak-256, the NIST SHA-3 contest winner, is also fast, though I’m inclined to think that [url=https://blake2.net]BLAKE2sp-256[/url] is a better choice.
-
[quote name=“ghostlander” post=“16296” timestamp=“1371598493”]
My concern is what kind of scrypt-jane are we going to implement? YACoin replaced Salsa20/8 with ChaCha20/8 (mix function) and SHA-256 with Keccak-256 (hash function). ChaCha20/8 seems to be a good choice since it’s both faster and stronger than Salsa20/8. Keccak-256, the NIST SHA-3 contest winner, is also fast, though I’m inclined to think that [url=https://blake2.net]BLAKE2sp-256[/url] is a better choice.
[/quote]YAC uses chacha and keccak512.
Onecoin uses salsa64 and blake512.
Both use the scrypt-jane implementation, but with a different function to increase Nfactor.
-
So, right back to basics… Why exactly are we wanting to change the algo? What are we trying to achieve? Is it simply to stop rogue pool admins flicking their LTC pools to FTC?
All the techno-babble is good but it makes my head hurt. I’m sure Bush, Coinotron, Klovias et-al can make it work technically. We need to ask ourselves “why?”.
If we change the algo we’ll loose miners as it’ll break the autominers the hardcore ftc guys will stay but the profit miners will drop us from their scripts. On the flip side it will [s]stop[/s] reduce the hash/diff spikes so you’ll end up with a more stable hash rate… for about a week. Then everyone will see success, fork the code and start a new coin based on Scrypt-jane and we’ll be back to hash/profitabilty spike again.
Or have i missed the point completely? :-[
As a side note, if you need some hash power and server space to test on i can lend 3MHs and some server space to the cause.
-
[quote name=“liteuser” post=“16368” timestamp=“1371636297”]
[quote author=ghostlander link=topic=1839.msg16296#msg16296 date=1371598493]
My concern is what kind of scrypt-jane are we going to implement? YACoin replaced Salsa20/8 with ChaCha20/8 (mix function) and SHA-256 with Keccak-256 (hash function). ChaCha20/8 seems to be a good choice since it’s both faster and stronger than Salsa20/8. Keccak-256, the NIST SHA-3 contest winner, is also fast, though I’m inclined to think that [url=https://blake2.net]BLAKE2sp-256[/url] is a better choice.
[/quote]YAC uses chacha and keccak512.
Onecoin uses salsa64 and blake512.
Both use the scrypt-jane implementation, but with a different function to increase Nfactor.
[/quote]Seems so, but they utilise 64-bit calculations in order to produce 512-bit hashes. They run slow on GPU hardware, though run anyway. There is absolutely no need for us to switch from 256-bit to 512-bit hashes. BLAKE-512 used by Onecoin is the original version submitted for the NIST contest, BLAKE2 is much improved in means of performance. If we decide to switch over to scrypt-jane, let’s choose the strongest and fastest implementation.
-
[quote name=“Nutnut” post=“16372” timestamp=“1371639727”]
So, right back to basics… Why exactly are we wanting to change the algo? What are we trying to achieve? Is it simply to stop rogue pool admins flicking their LTC pools to FTC?All the techno-babble is good but it makes my head hurt. I’m sure Bush, Coinotron, Klovias et-al can make it work technically. We need to ask ourselves “why?”.
If we change the algo we’ll loose miners as it’ll break the autominers the hardcore ftc guys will stay but the profit miners will drop us from their scripts. On the flip side it will [s]stop[/s] reduce the hash/diff spikes so you’ll end up with a more stable hash rate… for about a week. Then everyone will see success, fork the code and start a new coin based on Scrypt-jane and we’ll be back to hash/profitabilty spike again.
Or have i missed the point completely? :-[
[/quote]Agreed. There will be serious complications in the short run. The idea is to get out of Litecoin’s shadow completely, so no one would say FTC is a tweaked clone of LTC. It’s supposed to deliver advantage in the long run. I must say such a cryptocurrency algorithm change is unprecedented, so it brings us an additional credit for sure.
-
The coin is new enough that it makes sense to change the hash algorithm now if it is ever planned to do it. Many people that mine already follow the forums. If we wait until it is a lot larger there will be more of the mining problems that everyone has already described.
-
Truthfully, I think keeping Scrypt will benefit FTC in the long run. Every bit of research I’ve done on Scrypt ASICs point to the fact that they will not be remotely as efficient as their sha256 counterparts. At most, they’d be 4-5x more efficient than GPU setups, which may not be worth it for the majority of miners.
Getting out of LTC’s shadow simply requires more and more market services. Yes, you have a lot of people that are opportunistic on FTC, but FTC actually has a decent network backbone… Which no other coin, sans LTC really has at this point.
I think you’d be better off developing a payment handler for FTC for merchants such as myself. That will attract long term investment, and longer term hashrates, as miners will want to keep on FTC due to it always being profitable due to innovations - rather than just difficulty.
-
[quote name=“Benny” post=“16495” timestamp=“1371673968”]
Truthfully, I think keeping Scrypt will benefit FTC in the long run. Every bit of research I’ve done on Scrypt ASICs point to the fact that they will not be remotely as efficient as their sha256 counterparts. At most, they’d be 4-5x more efficient than GPU setups, which may not be worth it for the majority of miners.Getting out of LTC’s shadow simply requires more and more market services. Yes, you have a lot of people that are opportunistic on FTC, but FTC actually has a decent network backbone… Which no other coin, sans LTC really has at this point.
I think you’d be better off developing a payment handler for FTC for merchants such as myself. That will attract long term investment, and longer term hashrates, as miners will want to keep on FTC due to it always being profitable due to innovations - rather than just difficulty.
[/quote]I agree w/your entire post, assuming the reason for making this change is to simply [i]“get out of LTC’s shadow”. [/i]
There’s no reason to do this if it’s simply to “be different” from litecoin. Nothing’s wrong with Litecoin from my perspective, except it just kind of stopped and I see no bright future and I was not enthused about Coblee’s responses at the Bitcoin Conference. Coblee did not inspire hope for the future with litecoin (for me) and seemed to be very passive about doing anything other than the status quo (just my opinion).
So I saw Feathercoin as litecoin [b]actually moving forward[/b]; as did the attackers (I believe). I’m sure litecoin fanboys would want nothing more than feathercoin to “be different”, because if feathercoin remains as is, [i][b]it will destroy litecoin[/b][/i] eventually simply by out innovating and out marketing litecoin.
If this move is about stopping 51% attacks and future innovations, then I think it’s a good move; assuming there are no major pitfalls and assuming there will actually be more attacks that will succeed and can’t be stopped any other way (more hash anyone?).
However, other than the attacks … I see it as completely unnecessary and believe, as Benny does, focusing more on getting Feathercoin into the merchants hands and innovating uses for the coin would better suit the future of the Feathercoin.
But what do I know. For the past 20 years I thought the US Government was spying on it’s citizens illegally and starting covert wars to build pipelines. :o
-
The 51% attack is caused by the fact that confirmations are costly but reorganizations are free. Let’s change that. Rather than merely making it more difficult to hash, it will make attackers have to split their resources in several uncertain directions with no guarantees.
-
I really don’t think Scrypt-Jane solves the 51% attack.
If I really wanted to be malevolent towards FTC, it makes it easier, really. To mine FTC, you’d have to re-configure all of your GPUs if you want to mine it, meaning only a small portion of current FTC GPU miners (if any - as the Scrypt-Jane algo may not support GPUs, depending on how its implemented).
Comparatively, a malevolent force could easily buy a botnet, and go to town on the coin, as a botnet would be vastly cheaper to utilize than any other form of attack. Likely, this is what forked FTC before. The only major difference is that its easier under a CPU-only scenario, as there is no specter of GPUs bloating the network with extra hashes.
-
I don’t think changing the scrypt is the way forward. Having the same scrypt makes us compatible with other developments.
ASICs are inevitable, lets just work to make them cheep, efficient and evenly distributed, when they come out. Maybe, in the future, retail outlets need to run a small USB miner as it increases their confirm rate. Or some other (cleverer) nudges in the right direction.
For instance, if we changed to a fairer transaction fee system, the miners would be paid by transaction, not flat fee. This would encourage small miners to get their fees back, by micro mining.
Perhaps we should write to Satoshi and ask him what he thinks?
-
I want a site like bitmit but for FTC.
-
Cool man id love to post my ideas if I had some
-
[quote name=“ronthedon” post=“20965” timestamp=“1373430637”]
I want a site like bitmit but for FTC.
[/quote]That’s definitely the long-term goal, couldn’t agree more.
-
I have read through all the post a number of times. This is a very complex issue.
Work should be done against the cause (of failure), I therefore think, a change to randomise the confirms over a larger number of miners. Or, that some mining must be done by each wallet, are better less intrusive solutions to prevent ASICs taking over the network.
I believe the GPus should move on as there are thousands of coins needed. Us miners should be paid back on our investment starting the network, so we can invest in a low powered USB ASIC. Also, when Feathercoin is being used in shops, they will each have there own miner, to speed confirmations.
-
A good place to start would be implementing it in our partner internal coin. I’ll address that tomorrow in the press release thread.
-
My take on things should we decide on changing algos. This was a response I made to a thread in the suggestion box subforum.
[quote name=“aysyr” post=“20787” timestamp=“1373373454”]
Been suggested so many times, including by yours truly haha.That said, I forgot to make an important point before in comments regarding a proprietary Feathercoin miner, which is this:
“Using a proprietary or built in miner allows us to easily change the hashing algorithm without affecting miners, since an update to the mining software can be done simultaneously with the blockchain since they’re in the same client. Because the miner will be tied with the wallet software, it allows the miner to see the current block #, which allows it to make hashing changes at the appropriate time as well. This makes our goal of being ASIC-hostile much easier and feasible should we need to implement something along the lines of a new algorithm such as the possibly planned Scrypt-jane somewhere down the line, and any other algo changes thereafter”
Thus, we can have two clients available… a simple wallet client as we have now for people who merely want to use the coin, and a larger miner’s client which can have both the wallet and proprietary miner built into one.
[/quote] -
There are much higher priorities in the near future, however, testing these options behind the scenes is something that will start to happen.
-
Well, if you’re considering changing encryption algos, perhaps FTC could bring something to the table by doing something entirely new…
http://newsroom.ucla.edu/portal/ucla/ucla-computer-scientists-develop-247527.aspx
I don’t know if this is specifically the solution, but an algorithm that was less speed-dependent and somehow more time-dependent would enable hashing on much lower-powered devices, and possibly shield FTC from FPGA and ASIC mining for a lot longer than scrypt will.
