Checked my miner today and found it outputting all kinds of negative number jargon. Negative hash rate, negative mining time. WTF!

Speed: -5940 h/s, TotalHashes: 53089K, DevHashes: 1326K Mining time: -2:-31
10/16/14-20:56:18 - SHARE FOUND (target 250012) - (GPU 5 of 6)
GPU 0 t=74C fan=57; GPU 1 t=75C fan=61; GPU 2 t=74C fan=56;

Miner appears to still be working. Restarting it corrected the problem. No idea what happened, figured I'd report it.

Is there a v8.0 Linux build in the works? I finished shuffling everything over to Linux only a few days before v8.0 came out. I figure Claymore is working on a new version that can compete with this strange Russian miner people are chatting about here. Whatever the reason, Claymore, please don't forget about us Linux users!

Fair enough. I am relieved to know there's a good reason for what happened. I've heard of people using bitcoin accidentally giving away their balance as fees by not sending transactions correctly, and I just wanted to make sure this wouldn't happen when I'm holding 15 XMR and trying to send 1 XMR.

Thanks a lot.

I have had an issue regarding Monero TX fees. I had in my wallet, exactly 1.539246463904 XMR, and sent 1.4 XMR to an exchange. The resulting transaction is in the blockchain here:

https://minergate.com/blockchain/mro/transaction/6140829924b68547172fa16069a343632b6f653e8d04fb3b239b9edf55689eb6

Notice the three input transactions correctly total my wallet balance, and the two output transactions total the sent 1.4. What confuses me, is the remainder of my entire balance, turned into the transaction fee, 0.139246463904, leaving me with 0 XMR. I thought the network fee was 0.1 XMR, thus I would have expected one additional output, returning the change back to me.

I'm obviously haven't lost a lot here (0.039246463904 XMR) but I want to make sure I didn't make a mistake, which may result in me losing much more coin next time.

Is it normal for GPU activity to hang around 93-96% rather than 99% I usually got with LTC mining?
Periodically the GPU activity will drop to 50% or so, for about 10 sec before resuming 90+%. This occurs every minute or so. Is this normal? What could the bottleneck be? It looks like the drops are correlated with a new block being found on the network. I am assuming its just spending time generating new work or something.....

I'm having some out of memory issues with this miner, perhaps there is a memory leak? My machine has 4 280x, and 4 GB memory. Is this too little? Perhaps it was just a fluke, but I woke up this morning to find the miner spitting out a blank error dialog, and windows complaining it had to shut down the miner due to memory. So far I am frustrated, being unable to keep the miner stable for more than 24 hours. For the amount of time it did run however, it mined coin extremely well, clearly Claymore knows his shit and I am grateful! Hopefully I can figure out this issue, has anyone else had memory related problems?

Thank you deepceleron for your answer. I'm convinced what you posted is correct, but I am stumped by one last thing. I've used the "BouncyCastle" library for .NET to perform this encoding. Sample code:

DerInteger integ = new DerInteger((int)template.Height);
byte[] heightBytes = integ.GetDerEncoded();
string hex = Util.ByteArrayToString(heightBytes);
hex = hex.Substring(2); //Strip off the INTEGER starting tag "02"

For value 128 this results in:
02 00 80
Rather than the expected
02 80 00

Why does bitcoin differ in byte order from the specification? I suppose it is easy enough to write some byte order reversing logic, but I want to make sure I'm not missing something.

I'm also assuming it uses "varint" as specified on the bitcoin wiki. I guess I am confused over what determines the "length" of a number.

I'm confused, the varint spec says single byte storage is good up to 252

< 0xfd    1    uint8_t

In case anyone would like more context here, this is an example attempted submission. (Submitted hex to "submitblock")

0200000062BDE75A8EF452C5489925E0439FFB42DA9C03B9152E4F361C75C2D400000000A548FD7 DADA0874163A7480A114F1EB2DE0A1BA0CFF667444867A421907865A14999D852FFFF001D600B96 520101000000010000000000000000000000000000000000000000000000000000000000000000f fffffff20018000002f503253482f04b8864e50080800000209020000072f736c7573682f000000 000100f2052a010000001976a91445434bcc52d8e4255d1a5d624854b11fd3a9853188ac0000000

I am working on a self education project, where I am attempting to build a cheap miner application. I have set up "testnet in a box" and have written a small miner that builds version 2 blocks. The miner mines successfully, all blocks up to and including 127, but when attempting to submit block 128 blocks become rejected citing error "AcceptBlock() : block height mismatch in coinbase"

The coinbase script I am using looks like this: (example does not include the script length varint prefix)
0180 00002f503253482f04b8864e50080800000200000001072f736c7573682f



It is curious, how the block that fails is the one immediately past the max value of a signed byte (127) I suspect there may be a genuine bug here, related to how bitcoin computes the expected prefix.

Internally height is stored as a "signed" int: (Collected from AcceptBlock() function in main.cpp)
int nHeight = 0;

I suspect errors occur when these signed values get compacted into a variable integer. We may simply have never seen this, because of the possibility block version 2 was not introduced until both testnet and mainnet were sufficiently long to mask the problem. Sadly, I don't have the environment or tools set up to compile and rake around in bitcoin code. Can someone here more equipped, and more knowledgeable than I help me investigate this? I'd be curious of the result of the following snippit of code:

int nHeight = 128;
CScript expect = CScript() << nHeight;

See if the bytes built by CScript turn out to be "0180" as expected.


Thanks in advance!

Matt

Getting "Pool 0 JSON stratum auth failed: (null)" consistently.... My workers are all falling back to other pools. Please fix......

And yes I've double checked my credentials...

Some really good information in here. I personally do not trust any 3rd party with my coins. I use an old laptop, with no hard drive, and no internet connection to fire up locally saved copies of bitaddress.org (on a USB stick) or liteaddress.org. I will print out 50 or so paper wallets, and store them in a safe. (Safety deposit box works too) It's not a bad plan to print two copies.... I like to think this is the highest security you can get, short of people breaking into my house.

77c I don't think is too hot. I run a 7970 here at 80c with no problems. Additionally I run quad 7990s at 92c and so far had no issues. Keep in mind though, 7990s are dual GPU and naturally put out far more heat, so maybe they are more tolerant.