Yesterday I put the S1 back at the pool, after deciding i didnt like dust payments mounting up over the next week I will be going to hash more, after reading pretty much 900+ pages in this forum thread I had the inspiration to get my S3 running into the pool, which I have now done, however....
From looking at stats, I am getting a hell of a lot of discarded, wondering if it is normal after switching from 1 device to another, or do you think I could have a problem with the S3 that I have bought ?
Accepted 863
Discarded 8,346
Any help and advice will be appreciated. Thanks
Discards are irrelevant. Ignore them. It's just the shit way bitmain configure cgminer in their firmware. Alternatively, grab Kano's S3 binaries. |
|
|
|
What Bitmain actually did is to make miners turn their backs on S9. Miners will buy from their competitors instead, Bitmain is not so big as to pull the final shots in the mining industry.
Unfortunately that is smoking the crack pipe. There are pretty much no competitors to the S9 for now and by the time there is, no doubt the Bitmain gear will still be cheaper. The vast majority of miners do not make their purchase decisions on principles but on price. I'm not saying that's right, just pointing out reality. As for "cracking" the S9, unless they put their code up somewhere showing what differences there are in their cgminer fork, it will pretty much never happen. If/when they put their code up for public scrutiny, it would be a simple matter of porting whatever was different between the S7 and S9 into a new cgminer binary. I guarantee you there is likely to be only minuscule differences in the code between cgminer 4.8.0 and bmminer (mainly to support their custom antpool stratum extensions) and small differences between the S7 and S9 drivers. Making firmware is a lot of work, but building a cgminer binary wouldn't be that much work, and I could probably do it (if they put up their code somewhere to see) as I did for S5. That probably doesn't meet the criteria for your bounty so you if you're going to keep offering the bounty you'll have to be absolutely clear about what you want done. |
|
|
|
So it may have something to do with the hacker.. but what is most interesting to me is this address https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuEi know a bit about vanity address. i have one i made a long time ago with 1d57heinz(which took many days with a few gpu).. what is odd is how many characters they were able to find in a row.. This would have taken a huge super computer or a ton of gpu to find this address.. Or am i missing something here.. Next question is. If someone can find that many characters with a vanity gen then how safe are we? That address isn't owned by anyone. It's a valid address but that doesn't mean anyone actually has the private keys to it. You'll see that someone has been putting money into it but no one has ever taken money out of it. Anyone can make up an address name that sounds cool but that doesn't mean they actually have a wallet with private keys for that address. |
|
|
|
Hey Kano -- I've noticed that a Core developer offered the suggestion of a retrace to recapture the stolen coin from Finex.
I'm assuming that they would need 51% of mining power approval -- 144 blocks (since the theft) = 1800 btc which, presumably, Finex would pay.
What are your thoughts on this as controller of a mining pool?
This would be a disastrous move for bitcoin as it undermines one of the expected truths of the blockchain. It is NOT the responsibility of the blockchain to fix one company's security issues or deal with scams and so on. The blockchain is not the police and should not be viewed as such. If we do it for bitfinex why not roll all the way back to before mtgox? No, this would make confidence reach an all time low in bitcoin. Just because some other shitcoin did this, doesn't mean bitcoin should. |
|
|
|
I purchased some btc today.
Too early. Wait a bit more from the looks of it  |
|
|
|
Well after trying various options like switching to the USA server it seems that its pretty simple. Nicehash doesn't like it when your miner is set to "pool balance" it ran fine for 15mins with no rejects when it was set to "failover" as default, but as soon as I putty'd in and changed it to "balance" the rejects started to rise, but just for the nicehash server. Still cant explain why that would be though but I assume its as Laviathon has said.
Nicehash mines other coins when you point your miner at them. You can't mine two coins concurrently (which happens when you load balance in cgminer and mine bullshit coins at nicehash but bitcoin on anther pool); you have to hard switch from one coin to another. |
|
|
|
THX, also no chance to a successful run?
Let it cool down, try a lower voltage and then start lowering the clock speed on each startup. You might find a speed where it works again, or half works, or it may never work again. They're just not very reliable and don't have much of a life expectancy. |
|
|
|
I have an problem with the cgminer and th U3, anyone have an idea? cgminer version 4.9.2 - Started: [2016-07-30 23:57:50.402]
--------------------------------------------------------------------------------
(5s):1.349M (1m):9.538G (5m):28.75G (15m):18.21G (avg):43.79Gh/s
A:4898 R:0 HW:4 WU:612.0/m
Connected to multiple pools with block change notify
Block: 6084db13... Diff:2.52M Started: [00:03:33.486] Best share: 16.1K
--------------------------------------------------------------------------------
USB management Pool management Settings Display options Quit
0: AU3 0 : 225MHz 775mV | 1.349M / 43.79Gh/s WU:612.0/m
--------------------------------------------------------------------------------
[2016-07-31 00:06:45.165] AU3 0: Idle for more than 60 seconds, declaring SICK!
[2016-07-31 00:06:45.167] AU3 0: Attempting to restart  Looks typical of the U3, it's a steaming pile of shit and it's started failing for you. |
|
|
|
Give it a rest guys  |
|
|
|
|
No bearing. As ASIC mining is quadrillions of times faster than CPU mining this news has no bearing on current bitcoin mining.
|
|
|
|
[2016-07-28 07:07:54.614] Possible block solve diff 428832493559.277649 !
[2016-07-28 07:07:54.748] BLOCK ACCEPTED!
[2016-07-28 07:07:54.748] Solved and confirmed block 422592 by 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW
[2016-07-28 07:07:54.748] User 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW:{"hashrate1m": "4.42P", "hashrate5m": "4.2P", "hashrate1hr": "3.72P", "hashrate1d": "640T", "hashrate7d": "431T"}
[2016-07-28 07:07:54.748] Worker 1D6jWP3f9C8YevncEYiB7EZiuhkt4VypoW:{"hashrate1m": "4.42P", "hashrate5m": "4.2P", "hashrate1hr": "3.72P", "hashrate1d": "640T", "hashrate7d": "431T"}
[2016-07-28 07:07:54.748] Block solved after 494460446877 shares at 231.6% diff
|
|
|
|
Does anyone here have found a block? How do I know that my miner found a block?
As the thread title says, 187 blocks have been found here. If you get a big fat payment in your wallet, that's how you know you've found a block... plus I announce every block solved in this thread. And who solved, you also announce? Only their bitcoin address, yes... Look back two or three pages and see the last few announces for yourself. |
|
|
|
Does anyone here have found a block? How do I know that my miner found a block?
As the thread title says, 187 blocks have been found here. If you get a big fat payment in your wallet, that's how you know you've found a block... plus I announce every block solved in this thread. |
|
|
|
Perhaps some issue with the compac fork of cgminer in initial communications. I didn't think they changed that much though and others have been mining fine with them for ages. Anyway don't mess with it now that it's mining  |
|
|
|
|
If you're talking about mining bitcoin, running AWS instances costs a quadrillion times more than it earns in mining, and that's not an exaggeration.
|
|
|
|
|
I glossed over your complete data set, but you're probably communicating fine, it's just that finding 1k diff shares is a rare event on a compaq stick which is why you see the S7 communicating fine which makes 1k shares far more frequently. There's nothing to fix there, unless you want the feedback faster, in which case mine on a pool that supports the stratum specification command --suggest-diff (like kano.is or solo.ckpool.org) and use cgminer which supports the command and choose your starting diff.
|
|
|
|
Thanks. Ill keep things are the gh/s divided by 1.5 so that should be a pretty good starting place.
I figured the pook would just increase the value if needed from reading up on pool difficulty.
Error rate is definately lower on the last miner work restart when the last block was solved than using a factor of 1.4.
Trying to micromanage like this will drive you mad. Changing work difficulty has no effect on intrinsic error rates at the miner end, nor stales, nor anything else that matters and looking for the random differences in one run to another is fooling you. Since ckpool is very good at picking the right work difficulty for you, there really is no reason to adjust pool diff yourself. We pretty much only support it for legacy reasons since people expect it to be there, and some random old broken hardware doesn't work without fixed pool diffs. |
|
|
|
|
Show Posts
