Changing the hashing algorithm
-
I was reading Charlie Lee’s post about why Litecoin would not be changing their algorithm to prevent ASIC mining. For LTC it makes sense not to change as the ASICs would most likely be strictly mining LTC and, in the end, they could help make their network stronger and push adoption.
One of the things he mentioned is that he thought it would be hard to, “convince everyone (pools, exchanges, miners, users, etc.) to adopt the alternate code”. Again I could see that being the case for their coin. Does anyone anticipate a problem getting the whole Feathercoin community to change to a new algorithm?
-
How serious are you guys about changing to another algo? I’m watching to see where GPU’s go - or if they go anywhere.
Pretty sure all other scrypts are going to have to change or die with the ASICs judging by BTC \ ASIC history …
-
I was just about to reply to your post linking you to this thread haha. Welcome.
-
PoS will not be researched any further until the new hashing algorithm is ready. Cannot do all at once.
I agree that we need to move forward step by step. We are doing some directional selection,Including tracking and investigation.
-
I gotta say,
Long time feather enthusiast, and feather forum lurker.
This idea is both refreshing and innovative, I am confident that the active members will deliver.
I think this will both set us apart from the Litecoin crowd, and give much credit to all the stability of the Feathercoin.
Keep up the good work guys.
6ySt1dsCWpfkcGHdeBaBnVTBgKWkQhzUnU
-
What we decided to do?
-
Now 0.8.6.1 is released we can start to get back to investigating an appropriate ASIC Hashing Algorithm response…
1. I am completely against PoS (Proof of Stake), that is a complete change in coin Philosophy.
2. CPU mining should be discouraged due to Botnet use.
3. Changing the scrypt element will be easily reprogrammed on future more flexible ASICs
so
4. Changing to SHA-3 or similar for a 18 month wait for ASICs
For: mining codeing is done, investigation implementation possible,
Against: being used before, so similar problem with future ASICs to now with Litecoin.
or BLAKE etc .will give about 9 months delay
For: Will use standard Bitcoin Hash algorythm so current ASIC will work with some modification.
Against: Same
5. Develop a custom solution, 2 months -
For: Safer, greater expertise gain,
Against: More work, more to go wrong.
At the current time the general opinion is that Litecoin will effectively “own” Scrypt ASICs, which will be great. It is the way the coin network is supposed to develop, by encouraging miners to invest in new hardware. That would mean Litecoin is a “known investment”, like a company being formed or an infrastructure being completed. The choice will then move which will be the next coin to be worth promoting?.
In addition, this is a fragile open source development environment, trying to encourage new developments and community. So it is not just about what we do, it is also how we do it.
I’ve left the Testnet up, as Hashing algorithm changes now becomes proposed for inclusion in the next Feathercoind and Feathercoin-Qt release.
-
Just thought I would post this. It’s an interesting watch.
-
Hi wrapper, I think FTC need to use two kinds of algorithms, one is Blake, another is a custom algorithms from Scrypt. This is a Low-power scheme.
-
Feathercoin could switch to block retargeting to ever 2 blocks to prevent an attack when it occurs. Yes I agree the hashing algo should be changed but, for now a temp fix would be to retarget difficulty every two blocks. This would help so that when an evil miner hits the network with a 51 percent attack he/she cannot take full control of the block chain.
Not sure if Apriori could be used but, its a thought/suggestion.
Data Mining Algorithms on the Cell Broadband Engine
Rubing Duan and Alfred Strey
Institute of Computer Science, University of Innsbruck,
Technikerstrasse 21a, A-6020 Innsbruck, Austria
{rubing.duan,alfred.strey}@uibk.ac.atAbstract. The Cell Broadband Engine (CBE) is a new heterogeneous multi-core processor from IBM, Sony and Toshiba, and provides the potential to achieve an impressive level of performance for data mining algorithms. In this paper, we describe our implementation of three important classes of data mining algorithms: clustering (k-Means), classification (RBF network), and association rule mining (Apriori) on the CBE. We explain our parallelization methodology and describe the exploitation of thread- and data-level parallelism in each of the three algorithms. Finally we present experimental results on the Cell hardware, where we could achieve a high performance of up to 10 GFLOP/s and a speedup of up to 40.
Keywords: Cell Broadband Engine, multi-core, k-Means, RBF, Apriori.
3.3 Apriori for Association Mining
Apriori is a classic data mining algorithm for learning association rules. Given a set of itemsets, the algorithm attempts to find subsets of k elements which are common to at least a minimum part minsup of the itemsets. The algorithm uses a bottom-up approach: in each iteration frequent subsets of k elements are extended to subsets of k + 1 elements (candidate generation, see Alg. 3), and groups of candidates are tested against the data. The algorithm terminates when no further successful extensions are found. The complete Apriori algorithm is presented in Alg. 3.Source: http://forum.prisonplanet.com/index.php?topic=160968.0
FTC:
6u7Kz4h1rMzTCyGMAKW9ePeHGGsxZL67yh
tytytytytyvm for any FTC’s O0
-
Feathercoin could switch to block retargeting to ever 2 blocks to prevent an attack when it occurs.
The fork in the new release 0.8.6.2 has a re-target of every block and reduced block times to 60 seconds so I think we can concentrate on the algorithm change now
-
On April 08, 2014, AMD lauched R9 295X2, a dual R9 290X in a single PCB, with 11,6 TFlops.
http://www.ign.com/articles/2014/04/08/amd-radeon-r9-295x2-graphics-card-launching-april-21
You can pick up the R9 295X2 from retailers, starting April 21, for $1,500 USD
-
3. Changing the scrypt element will be easily reprogrammed on future more flexible ASICs
so
4. Changing to SHA-3 or similar for a 18 month wait for ASICs
For: mining codeing is done, investigation implementation possible,
Against: being used before, so similar problem with future ASICs to now with Litecoin.
or BLAKE etc .will give about 9 months delay
For: Will use standard Bitcoin Hash algorythm so current ASIC will work with some modification.
Against: Same
- the new algorithm is not necessarily resists ASICs.
Because there are several problems ,we abandon Scrypt, ASICs just one problem. Through innovation we need to get rid of the shadow of LTC and Scrypt.
I hope the new algorithm is low power consumption. It is very important. We were able to save some electricity charges. We need a green algorithm, eg: vertcoin(https://github.com/vertcoin/vertcoin/blob/master-0.8/src/scrypt.cpp), an improved algorithm is simple and unique.
I can say with certainty that if Feathercoin is an independent algorithm, would not exist ASICs problem. Because it does not meet the economic laws.
-
Just thought I would post this. It’s an interesting watch.
Hi Calem, interesting watch with regard to 51% attacks…
The trouble is 51% attack is now pretty visible. Also the perps don’t want to kill Bitcoin or the Litecoins otherwise they end up with 51% of nothing.
This means the 51% attack is not relevant as the most danger to the Bitcoin protocol. It is much easier and economical to raise a 20% attack and just exploit the difficulty calculation, even with Bitcoins raising hash rate this would still be much more viable, profitable and invisible use of your dirty money.
We, in the alt-coin community, also know there is real danger from evil pools, it is much easier and cheaper for psycho criminal who only cares about the thrill of the caper and enjoys robbing other human beings to manipulate a multipool of other miners to their end. They don’t even have to pay the electricity bill.
It is therefore obvious that at least efforts should be made within the normal protocol adjustments to reduce those manipulation windows and make those attacks more expensive, which is what Kimoto’s Gravity well and eHRC are designed to do.
As for changing the Hashing algorithm, I think that is much more risky and a lot more work. It does not prevent any of the consequences of ASICs, at best delays them. It also could go completely wrong and destroy the coin.
Just to get some idea, even part time, we have spent at least 6 man months on designing, developing and testing the new difficulty algorithm. I calculate double that at least for changing to an original hashing algorithm. i.e. 12 people working full time for a month.
We have probably done about 1 man month on that so far, 3 further man months of that are changing associated mining software etc… I have not calculated the associated work of Exchanges, block explorers miners and pools of updating the daemon software on their current systems.
-
What we need most right now I suppose is more programmers?
-
What we need most right now I suppose is more programmers?
We’ll need more programmers when the reference code is ready and runs on testnet. No matter what hashing internals there are, it’s going to be pure C and not very fast. CPUminer needs SSE2 and probably AVX assembly code, BFGminer/SGminer need new OpenCL kernels, P2Pool needs a Python module, and mobile clients need a Java implementation. For now, I can only tell that I’ve made a deep research of what to do and what not to, so my concept is ready. Need a few completely free days to get it coded/tested as I haven’t got much free time recently.
-
Hook me up whenever you guys need programmers :)
I’m on Java/node.js (server), C#/WPF/XAML (client) & MySQL/MSSQL.
-
One more thing on PoS. It’s slow and doesn’t work very well with fast blocks. If you look at those coins which support it and have block targets below 1 minute, you see that every time a PoS block hits the network, it orphans a PoW block or even a few. They also orphan each other often. That’s because of the way the PoS kernels are computed. Time lag is also important as PoS blocks are solo mined basically and propagate rather slowly. Mining pools are located in DCs connected to major backbones. They can also maintain hundreds of connections.
-
Are we considering using a current non scrypt algorithm. This may man we can reuse the current mining software and not have to develop our own. I’m thinking that may be the best option. Less work for us and a proven algo.
-
Are we considering using a current non scrypt algorithm. This may man we can reuse the current mining software and not have to develop our own. I’m thinking that may be the best option. Less work for us and a proven algo.
The trouble with doing that is it is a bit like if Bitcoin decided to change over to Scrypt at the last minute as SHA256 ASICs were released.
It’s a larger coin taking over a smaller coins algorithm.
