 Show Posts
|
|
Pages: [1] 2 »
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed. I am fairly sure the idle bug is fixed, but I have heard the extranonce stuff seems possibly unstable. If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason. Ah, alright. Well that was my poor judgement just blindly adding in the pool->idle = true; in addition to the suspending pool thing. I'll try to debug the issue further if it occurs again - the issue is that it takes so damn long to trigger  |
|
|
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed. |
|
|
|
Yes, miner subscribes to extranonce changes and receives extranonce updates just like job updates. If miner does not subscribe to extranonce, server will never send mining.set_extranonce. With set_extranonce, next work has to be built with new extranonce. The sequence of methods send from NiceHash is following when switching order:
mining.set_extranonce
mining.set_difficulty
mining.notify
That means switching order is as fast as changing work/job. No more reconnects. If there are orders paying less than what you want, you will be of course disconnected.
Does this fork of sgminer address the idle bug, or is that still a work in progress? |
|
|
|
qbitx: In the "Receive Money" tab you can now see a button that shows you all the generated addresses with number of tx. It's not too pretty yet but soon we are integrating some pretty block explorer which will probably be used in various places  Awesome  looks good to me. |
|
|
|
I hope BitGo doesn't generate all three the private keys on their servers because then the security of all this service is very low.
You could always try reading... BitGo today allows you to create one in your browser, import one (public key only) from a 3rd source of your choosing (offline, your existing wallet, etc), and one is created on the BitGo service. If you use this option, you've used 3 independent sources for key generation which means that your wallet starts out in great shape.
|
|
|
|
Looks awesome so far, the only issue I had with the wallet so far was that it doesn't keep a list of my previously generated/used addresses somewhere where I can query it (but if I'm not mistaken, that's planned for the future) A firefox add-on would be awesome too  This looks like one of the best options for multisig wallets at the moment. Keep up the good work. |
|
|
|
This comment makes no sense! Both of those lines do literally the exact same thing. The first one might actually make some compilers mad for setting a uint32_t (32 bits!) to a value that appears to be padded out to 48 bits in length (why?!) In C, setting "a = 0xFFFF", "a = 0x00FFFF", "a = 65535", "a = 0x0000FFFF", all have the same EXACT RESULT. The only difference is readability. Please explain why you would ever use the first statement. |
|
|
|
yes, I know that BTC/mhash is for accepted Mhash not total Mhash, thats why hinted on mining with same rig on different pools as for high duplicate shares reject rate, this usually is client side issue with multiple gpu's running in same cgminer instance (and something broke there). Another explainantion would be really badly broken stratum, but as it seems most the other users do not have this issue I think its client on side. cgminer debug log could show more... The guy above quoted and said my 10% reject rate was 'not bad at all'... That seems to indicate to me that other people are having this issue - seeing that 10% is considered decent  I will check the cgminer logs for anything out of the ordinary. I believe this to be a server-side issue though, however, considering that this is literally the only pool that I have this issue on (and I've gone through at least 30+ pools in my time mining)... |
|
|
|
I run on Wafflepool w/ xintensity 768; I get approx 1% reject rate. I run on CoinMine.pw w/ xintensity 768; I get approx 0.1% reject rate. I read on the Clevermining site that they've 'fixed' the reject rate issues so I come back to run a test... I'm running w/ xintensity 320; I get approx 10% reject rate! They aren't even stales either, it's just this bullshit:  Why don't you guys just like... Use better stratum software? I mean it must exist... Just look at the other pools. Numbers don't lie. |
|
|
|
poolwaffle - Is the 5.6 GH/s dude like... all coming from a single IP range, or is it a ton of different clients? Clearly just AMD doing some QA on their new chips |
|
|
|
|
A large chunk of my profits for today seem to have just mysteriously disappeared...
Looks like it's time to switch back to middlecoin (oh gawd the reject rates T_T) until stability improves.
|
|
|
|
|
I want to link my Bitcointalk name with BTCJam's. Verification code: 6f8c5989-8cae-44a2-adb1-6940ef157f3a
|
|
|
|
Hey guys, I purchased the 'dogeco.in' domain... I set up a basic MediaWiki installation there - it should be edittable by anyone. It's essentially empty / crap at the moment, I've got a lot of other projects going at the moment so I can't be updating it full time I'm afraid. Here's the main page |
|
|
|
pool is down?
The Announcement : The server is under heavy load and as a result the site is becoming slow. I'm migrating us to a better server so the lag will be gone soon. Thanks for your patience. So he is migrating. You need to wait. Such downtime. Many panicked Doge Wow |
|
|
|
|
Wow. Such generous.
Many impress.
DFfnzgnaH1tzCUMp4qTW8rXdYgdRGVQoeo
|
|
|
|
lol
I'm seeing much lower numbers xD Like in the 130 MH/s range for the total network hash rate o_o; Such hash. Many CPU cycles. Wow |
|
|
|
|
DFfnzgnaH1tzCUMp4qTW8rXdYgdRGVQoeo
Want millionaire Please assist
Such innovate
Many coin Wow
|
|
|
|
|
Most innovative coin by far
|
|
|
|
|
I want to link my Bitcointalk name with BTCJam's. Verification code: 6f8c5989-8cae-44a2-adb1-6940ef157f3a
|
|
|
|
I followed some transaction history myself just for kicks, These are the results I found from my Inputs/CL deposits for anyone that may be interested. Perhaps more of us should post their findings? Initial deposit: https://blockchain.info/tx/148abefc28a16195eacf888d065d845b76f12cdd53f0ef278738b1da372e1cc0114yugTxx2thCw7CxAKyqes8KM6T72Hohi - One of my wallets. Current value is 0 1ArJVWBJG2qdofFsWMWhXJWwjVgx4hq9LW - The Inputs IO wallet I sent to for the initial deposit. Current value is 0 https://blockchain.info/tx/abb65fee5d7e7b6997a5e3d7f1ce86270b010f8ec86f20f09ce51c0a359c98bcTransaction was made 2013-07-28, which is only 2 days after I started my "CD" with CoinLenders. 1DEPogxtJfQdwJa7WboujYMDYXGV2T2T6n - Unknown, I had originally assumed that this address was owned by whoever the BTC was loaned out to. The 50 BTC amount seemed like a nice round number for a loan.. After following the transaction for a few hops though, now it appears that it's just part of a chain of "Mixing" addresses that all have a final balance of 0 BTC. [EDIT] I didn't really want to follow the taint analysis very far, but this is what I found after ~5 minutes https://blockchain.info/address/1PemyGsGeWaFzaR6TChY5ubQp5SFpPqqT9 This address has 10.7102250864% taint from the 1DEP address above and appears to be heavily involved with the chain of "Mixing". It has a count of 40 on the taint analysis (I honestly have no idea what that means). I just found it interesting that this account gets so many incoming transactions of exactly 5 BTC... https://blockchain.info/address/12tcJxPwLHbByn8NPHpPqwzhdRDoJQuHWs This address was fed large amounts by the '1Pemy' address above, and currently has 3010 BTC at the time of making this post. That's all I've got. |
|
|
|
|
