Did you pick up the ltc asic companies on the litecoin forum?
|
|
|
Dead? doubt it, site looks pretty bad.
|
|
|
^ does not spend lots of time in glory barrels.
|
|
|
I have heard on the internet that some a very few have been able to mine scrypt with FPGA. There testing showed they could achieve about the same hash as GPUs with a decrease in TGP. When you search Gooble for Scrypt FPGA you get http://blockburner.net/ for the #1 search, not that actually means anything. It is possible and has been done but in its current state no practical, just yet. Commence the pre- orders. oops I am a bit tipsy, anyways FPGA Scrypt algo machines will need to be on par with ASIC in terms of BTC mined since LTC needs BTC milk for lifeforce. Scrypt, memory intensive slower . . . . . . . You are correct, it just mean's the SEO on the site is doing what it is supposed to We're as far along as anyone else with a Scrypt optimized FPGA as far as I can tell. The optimization will help though realistically won't produce any outrageous performance gains (but we will see with our first implementation), the real advantages to FPGAs over GPUs are in far less power usage and heat output, which translates into a better ROI over GPUs in the longer run and can be scaled up with much greater ease. I actually talked to Enterpoint before I ever started the BlockBurner thread here, I was told basically they were so backed up on other projects they likely would have a lead time of 6 months or more for anything new. No idea if that changed since then (back in march I think?) however. I just wrote them again to catch up. They had quoted me loosely at 30K GBP to design a Litecoin mining system, which is expensive no doubt. Although one wonders what it would be like to get a group of people together to raise the funds for that. Maybe jumping straight to building an ASIC would be expensive, but incredibly profitable potentially. (Potentially as is- can the Litecoin infrastructure survive currently at having mining becoming professional?) Just wondering, are you working with them directly to hype their product? For any company about to attempt a Salsa20 stream cipher hardware implementation is in for a lot of trial and error. By project completion I estimate we will have had a total of 12 redesigns.
|
|
|
^ trades tenebrix for other people to get a clue.
|
|
|
Or continue optimizing it to increase efficiency further as planned.
and take more risk, even if you planned to mine with these BFL style - its still very risky with sCrypt . I wasn't suggesting that you would release i know you will do what you think is right , you have the numbers not me . but i was suggesting that , the longer the lead time the larger the net risk. against the possible reward. we will have to see what happens . It is only risky if we are not able to get the price per fpga down or unable to increase the hash rate. Both of which are in the works. They are not ready to go live, people will just need to keep their pants on.
|
|
|
^ Does not still mine tenebrix.
|
|
|
Increased efficiency against the hashrate:price.
hows it turning out so far? 30% so I think its a good start. May I politely suggest at this efficiency , you should market and release, you see I know more than anyone else about the free-market , (see previous add I applied for ) , at this efficiency your proclivity to tend towards natural inequity is low. Plus in the open market you will then get the jump on the other., your dillema of courses protecting your investment, but unfortunately , I think that's as good as it gets . By the time you hold , you take exponentially more risk. I explained all this before , scrypt lead time to roi is much longer , (unless hacked) . That's the key parts to all your market equation. ! And it's going to make you : 1. Give up Or 2. Be more "honest"/equitable because your risk is greater. So thank you Colin Percival , you genius. Or continue optimizing it to increase efficiency further as planned.
|
|
|
well correct me if i am wrong, but scrypt algorithm is designed to prevent such hardware from being used by creating a large memory requirements, greater the speed, greater the memory requirements, FPGA's would also require in addition RAM chips to save to memory, i guess the RAM requirement would be extraordinarily high.
There certainly is a sweet spot we need to achieve before feeling comfortable selling the fpgas. What you are referencing is not the largest hurdle but I cannot go into details.
|
|
|
Increased efficiency against the hashrate:price.
hows it turning out so far? 30% so I think its a good start. FYI: 30% price to hash rate... I'm still interested. I'll save it in power costs over a year. That is the goal
|
|
|
Increased efficiency against the hashrate:price.
hows it turning out so far? 30% so I think its a good start.
|
|
|
Increased efficiency against the hashrate:price. I doubt anyone on here is attempting to shortcut sha256/scrypt or other hashing algos. But if someone accomplishes it we will likely see them on the cover of some very nerdy magazines.
|
|
|
There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum. There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash. And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.
^^^ this is what i think a few people have been working on , i wonder who if any got it ? That is not what we are working on actually.
|
|
|
E8Rn24gDV8bgK9UTSVFKtPdYWG2axBmR1m
Thanks!!
BTW, is the hashrate still good enough for solo mining with around 500 KHash/s??
Yes but barely.
|
|
|
Pumping/dumping a coin like this will be very difficult for since there are so few coins out there.
|
|
|
Everyone loves a good robot.
|
|
|
Yeah no issues here on that front.
|
|
|
Do you work with cryptocoin algos?
|
|
|
Nice to have a dev that keeps working on the coin.
|
|
|
|