It's not difficult, really. There are a lot of misconceptions about what scrypt can and can't do. I doubt there is a value or N or p for which GPU mining isn't advantageous.
Maybe for high Nfactor values, massive amounts of memory will be used. Then again gpus with big memory will sure take the advantage. You can use less memory by just lowering the lookup_gap on the current GPU implementation and recomputing the lookup table on the fly. The amount of memory used is O(L^(-1) * m) where L is the lookup_gap and m is the size of the lookup table. Hence with L=2, threads only utilize 64 KB instead of 128 KB. Performance goes down per thread, but you can still calculate any size of N.
|
|
|
K, thanks. Wasn't paying a whole lot of attention to where it came from. The point, though, is the non-standard scrypt that it's using that's supposedly difficult for GPUs to work with. I don't know if it is or not, but if it is, that's interesting.
It's not difficult, really. There are a lot of misconceptions about what scrypt can and can't do. I doubt there is a value or N or p for which GPU mining isn't advantageous. I'll be back soon, promise guys. I've been going through something, and after this weekend things should smooth out for me again. I'm sorry for this period of unexpected absence.
|
|
|
My first guess: VRM failed, you're no longer delivering consistent voltage to the VRM and voltage spikes are causing your heat issues. Replace all the MOSFETs or eBay it.
|
|
|
I think the biggest thing to remember here is that right now Litecoin is dying out, just like all the other altcoins. I suppose if everyone GPU mining Bitcoin moves over to Litecoin it might pick up, or die entirely. I don't think anyone has an idea at this point. Litecoin values are so tied to Bitcoin that it's difficult to think of it as an actual currency. This whole thing is completely unknown at this point, even the financial "experts" are stumped. But your main point is valid, buying GPUs now with the idea that you can switch to Litecoin afterwards is not a safe plan.
So, newbies, don't buy a bunch of Radeons right now. ASICs will be readily available to all very soon. Avalon, ASICminer and BFL apparently all have products available or close to available. Of course those ASICs are priced crazily high, I expect that eventually prices will come down.
Come back in six months, you should see something interesting happen to LTC price. I already made about 3500% mining Litecoins from 2011 onwards, so I won't worry. There's still time to be an early adopter on the Litecoin network before BTC is made totally unmineable by the presence of ASICs, though.
|
|
|
I have some family related issues going on right now, I will give an update on this when time allows it.
|
|
|
you cant atm...
yac uses scrypt-jane, and is/was designed to be cpu mined only..
If you could, it would be the end of yac, as its core ethos would be pointless
If you think a GPU miner can't be coded for it, you're mistaken. Both chacha20 and keccak have faster throughputs than salsa20 and sha2-256, and the value of N right now should provide extremely good GPU performance. Except N will change _tomorrow_ and then what? Doesn't matter -- because of the TMTO tradeoff and higher GPU memory bandwidth I doubt you'll see a point where GPU implementation is slower. Once you have the GPU implementation adjusting it for higher N values will be trivial.
|
|
|
you cant atm...
yac uses scrypt-jane, and is/was designed to be cpu mined only..
If you could, it would be the end of yac, as its core ethos would be pointless
If you think a GPU miner can't be coded for it, you're mistaken. Both chacha20 and keccak have faster throughputs than salsa20 and sha2-256, and the value of N right now should provide extremely good GPU performance. Basically the first person to get a large GPU mining farm on this will shred the network -- assuming this hasn't already been done.
|
|
|
Yeah, I may have scammed some stuff. But I did it the legit way, not by spreading trojans.
|
|
|
Indeed. It's always the victim's fault if they get something stolen from them. Signed limitless, 100% pro YACoin shill.
|
|
|
Hey, Tacotime! Thanks for the suggestion. I didn't realize when installing Win8 that I was logged in as admin. But it seems the behavior of cgminer hasn't improved. I can get it to mine SHA coins no problem. But as soon as I try to mine a scrypt coin it just hangs at 'starting' and then crashes. Are my environment vars messed up so that scrypt mining is broken? That seems weird but I am at a total loss at this point. In summary, cgminer works for BTC or TRC but breaks for scrypt mining. I am starting to think something is wrong with my RAM/mobo connection. But sys info correctly reads amount of RAM installed. I don't know...
edit:
And Reaper just hangs in 'compiling kernel'...
I've got no experience with Win8, which may be what's causing the problem, but it's hard to tell from here. You should try installing Win7 instead and see if that works better for you.
|
|
|
If you could do one more thing, get this coin ready on an exchange site before launch, I think that would help the coin tremendously because it prevents people from getting scammed.
Just my two cents.
+1 I fully agree. If BTC-E can add a copycat coin shortly after launch they should have no problem adding a planned out coin that adds some true innovation like this one (ahead of release). Very pleased with the concept of this coin, nice work tacotime. The way this coin is being released should have been a standard for all of the recent coins. Community feedback, support, planning, and involvement are key to the longterm success of the coin. We're hoping to have an exchange ready too, yes. Fixed the section numbering being messed up in the paper (whoops), newest is 0.31 but I'm sure there are lots of typos still in it that need adjusting. If you're interesting in helping crowdfunding for this coin (and possibly acquiring some coins from it) please head to the thread about it on the official forums: http://platinumdigitalreserve.com/forum/index.php?topic=16.0The latest means seems to be offering stakeholder tickets, which means that investors will get some coins in the first 91 days in exchange for securing the blockchain. Unlike a premine, some work securing the network will be used in exchange for coins given to the investors.
|
|
|
Just downloaded this on my third rig with duo 7970s. Rig I built yesterday was completed flawlessly. Today's rig hates me. Guiminer-scrypt will cause cgminer to crash when attempting to start mining. I can run cgminer via cmd prompt, and I have uninstalled/installed amd sdk/CCC drivers several times. Unstalled/installed guiminer as well. And running guiminer as admin doesn't seem to help either. Saved working guiminer from from other rig on a flash drive and running it on new rig, but still getting same cgminer error when starting to mine. Any sugesstions?
Here's the error in the exe log file:
Traceback (most recent call last): File "guiminer.py", line 1033, in toggle_mining File "guiminer.py", line 1338, in start_mining File "guiminer.py", line 1167, in configure_subprocess_cgminer IOError: [Errno 2] No such file or directory: u'C:\\Windows\\System32\\cgminer\\mine-ryc6.bat'
edit:
same with reaper. Tries to compile kernel since first time running it but immediately crashes.
edit 2:
did a fresh install of Windows 8 and still the same problem.
edit 3:
I can get guiminer (non scrypt version) to mine BTC and TRC using poclbm, so at least I know my gpu is working. Next I'm going to replace my RAM and mess with my bios as well to see if I can get anything.
I'm about to pass out, time for sleep. Hopefully someone can shed light on my issues.
You're running the program as an administrator, it looks like, because pwd is being set to C:\\Windows\\System32\\
|
|
|
Of course I believe, compilation with -O0 flag it's just an accidental bug
|
|
|
Pocopoco added a checkpoint via a GitHub pull despite not saying anything at all over here, and at block 15,000 no less. Why?
To mitigate 51% attack, no? Possibly, it's hard to tell. He might also be locking in blocks that are his own if he mined a bulk of them in the first 15k blocks. This is getting more and more bizzarre. Do you argument the same way for checkpoints on the BTC and LTC networks? You don't like a checkpoint because of what? Because it prevents people to attack the network and steal coin? I would think this a very positive thing. This is a young coin, so the fear of a 51% attack is real. Why would it be good if someone could do that? BTW, pocopoco did announce the checkpoint in his original thread here https://bitcointalk.org/index.php?topic=196196.msg2083242#msg2083242. I rest my case. Stop being bitter if you feel that you've missed out. If anything you can complain that the starting diff was too low (and that you were not online then, see my posts on "fairness"). There are ~2.34 Mio coins out by now. That still is much less than FTC (6.5 Mio) and CNC (5 Mio). As I said before, I didn't miss out and made a lot of coins myself.
|
|
|
Mmh, does the address change when restarting? I fiddled a lot with the number of cores setting.
...not as far as I know. I messed with mine a lot and all my generation blocks have the same coinbase transaction. It's possible that if you have multiple addresses in the wallet it might use them all, though.
|
|
|
So the software can have a wide release without the first-10-people-to-download-profit-handsomely drama. If the code was available in advance, people would start mining right away. Although this raises the potential threat level that tacotime is fooling everyone and putting in a wallet stealer for every *coin out there for everyone greedy enough to just run the binaries at launch. I'd say that probability is pretty low, but it would be hilarious.
|
|
|
Pocopoco added a checkpoint via a GitHub pull despite not saying anything at all over here, and at block 15,000 no less. Why?
To mitigate 51% attack, no? Possibly, it's hard to tell. He might also be locking in blocks that are his own if he mined a bulk of them in the first 15k blocks.
|
|
|
Anyone else notice this? namespace Checkpoints { typedef std::map<int, uint256> MapCheckpoints;
// // What makes a good checkpoint block? // + Is surrounded by blocks with reasonable timestamps // (no blocks before with a timestamp after, none after with // timestamp before) // + Contains no strange transactions // static MapCheckpoints mapCheckpoints = boost::assign::map_list_of ( 0, hashGenesisBlockOfficial ) ( 15000, uint256("0x00000082cab82d04354692fac3b83d19cbe3c3ab4b73610d0e73397545eb012e")) // ( 6000, uint256("0x000000000945e3c9d8e15df834e802521eb79f9ceb4191a27bdfadad4b777f4a")) // ( 8700, uint256("0x00000000014270724837789c9a69859290f6bdee38556bc4561c21f17935a178")) // ( 13560, uint256("0xa1591a0fcbf11f282d671581edb9f0aadcd06fee69761081e0a3245914c13729")) // ( 14189, uint256("0x00000000020f76474d2522b19c7bfafc43ba6ecbabae54293bcd9546159c8c1d")) ;
static MapCheckpoints mapCheckpointsTestnet = boost::assign::map_list_of ( 0, hashGenesisBlockOfficial ) ; Pocopoco added a checkpoint via a GitHub pull despite not saying anything at all over here, and at block 15,000 no less. Why?
|
|
|
Mayhaps, we have two good options : 1) Don't use PoW in cryptocoin at all. 2) Use PoW scheme maximally ASIC-friendly, with cheapest ASIC we can build for in our garages. ------------------- All other options will lead to future disaster(s). You can also always just merge mine with say, LiteCoin. Then you have all the security of the Litecoin network with no extra hash power being expended.
|
|
|
After looking at source for pushpool, I can at least conclude that porting something over is nontrivial. Here's what I think is necessary: 1. Change scrypt to scrypt_n, calculate n from the timestamp (relatively trivial) 2. Find a working implementation of SHA3 - since OpenSSL doesn't have one, either porting poco's code over or writing your own. Either way, I can't read assembler so no help there. (the nontrivial part) 3. Making requisite changes to config.json (trivial) 3. Putting the two together and testing and fixing inevitable bugs (another challenging part) As I said, I probably don't have the skills to do this, but if you found this post helpful, then hey I contributed something. Think I found a keccak implementation here: https://github.com/Fackelmann/SHA3 , still don't understand how it's used in the actual code though. In place of SHA256? You want the scrypt-jane implementation of CHACHA20/KECCAK-512 to verify new blocks. https://github.com/floodyberry/scrypt-jane
|
|
|
|