Scrypt Jane Research - Post Ideas Here
-
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.
