Bitcoin Forum
August 20, 2018, 10:49:33 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5761180 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
November 26, 2012, 12:07:43 AM
 #8201

Ok... I think maybe part of the fundamental problem here is that Slush's view is that all work sent out to a miner is related to work that has come before it (and work that will be sent after it), whereas, at least in my view, work that is sent out is discrete; it's completely immaterial what's come before or what is going to come after.  Correct me if I'm wrong here, but it seems that this is the root of the issue and why difficulty is not tied to work in Stratum.  

Maybe if you (Slush) can explain why a work packet being sent to a miner needs to be related to another work packet (either being sent to the same miner or someone else) as opposed to being discrete?  I'm just not seeing why work at difficulty X needs to be related to work at difficulty X + 1.  The miner is assigned work at difficulty X.  If they do the work, they should be rewarded for that work, regardless of the fact that difficulty changed since the work was sent out... they still did the work!  So rejecting the work because the pool arbitrarily decided to change the difficulty on the miner is rude if not outright dishonest.

Rejecting shares because difficulty changes AFTER the fact could easily be exploited by a malicious pool and amount to a very, very significant income stream at a miners expense.  For example, say I setup a malicious pool... every 10th share, I code the pool to raise the difficulty (then reduce it a short while later), thereby "rejecting" 1 out of every 10 shares that miner sends back... but I keep those shares and assign them to another user or the pool itself, etc... because those shares are still valid.  Now the pool gets 10% of the shares a user sends, the user thinks "crap, I'm getting 10% rejects because of my hashrate" or whatever reason you want to assign to it and it looks totally legitimate.  Now reduce that to .1% and spread that across 100 TH and 2000 miners... the miners won't notice such a small amount, but now the pool op gets the equivalent 100 GH/s for free and no one is the wiser.  This is what the Stratum protocol allows as designed, and if I'm wrong about this please let me know and explain why this can't be done?  This is also why difficulty needs to be tied to the work, so that work performed is never rejected because the pool decided to change the rules after the fact.

A more extreme example would be:  Pool keeps increasing the difficulty every set interval, causing all shares to be discarded by a miner until a valid block share is found.  Now that miner gets credit for 1 share, even though they should have sent 20,000 shares.  Yeah, this is unrealistic, but it illustrates the point that it's possible to exploit the protocol to the detriment of the miner.

I will be happy if I'm wrong and if someone can point out where I'm mistaken.  This is really my only major problem with Stratum at the moment, everything else is fairly minor in comparison.  I apologize if my tone appears aggressive towards you, Slush.  It was not intended to be, beyond my minor irritation with the way Stratum was rolled out... and that irritation is minor and not worth complaining about.  My "bashing" of Stratum is because the problem has been beat to death and you basically ignored anyone who disagreed with the work/difficulty being uncoupled.  Regardless, moving on to the solution you mentioned:

How does it address the following scenario:

Miner is given work at difficulty 2.  Miner begins processing work at difficulty 2 and finds a valid share... while processing the work Stratum sends mining.set_difficulty 3.  

What happens to that share found at difficulty 2, which was valid at the time it was issued?  The miner did the work based on the rules it was given, but the rules got changed after it already agreed to the work.



If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
1534805373
Hero Member
*
Offline Offline

Posts: 1534805373

View Profile Personal Message (Offline)

Ignore
1534805373
Reply with quote  #2

1534805373
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
November 26, 2012, 12:14:01 AM
 #8202

Miner is given work at difficulty 2.  Miner begins processing work at difficulty 2 and finds a valid share... while processing the work Stratum sends mining.set_difficulty 3.  

What happens to that share found at difficulty 2, which was valid at the time it was issued?  The miner did the work based on the rules it was given, but the rules got changed after it already agreed to the work.

What exactly is unclear on the sentence (from stratum docs):

Quote
This means that difficulty 2 will be applied to every next job received from the server.

If pool sends new difficulty, but then receive the solution from previous job, user must be credited for previous difficulty.

Edit: Although I don't fully understand these scenarios described by you, I think understanding of ^^ will give you the answer to some points. Also, if I understand some of your questions, Stratum proposal doesn't target scenarios with poolop cheating with counting shares.

Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
November 26, 2012, 12:18:16 AM
 #8203

Ok, if that's the case then that solves the issue.  Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?

Quote
Edit: Although I don't fully understand these scenarios described by you, I think understanding of ^^ will give you the answer to some points. Also, if I understand some of your questions, Stratum proposal doesn't target scenarios with poolop cheating with counting shares.

It needs to... not to keep pool ops honest so much as to allow miners to verify that what they THINK is happening is really happening.  It's about empowering the miners, not policing the pool ops.

Quote
No, this still does not address D.

Is this relevant though?  I'm not sure I'm comfortable with this, as it flips the exploit over to the miners side (although it has much less of an impact).  I don't want to issue difficulty 32 shares, have them reduce their hashrate while they save up a bunch of shares until their difficulty reduces then submit them all as valid.  Again, we go back to difficulty being tied to the work sent out.  Allowing it to "leak" out to other work/difficulty relationships is not the correct way to go about it IMHO.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2618
Merit: 1123


Ruu \o/


View Profile WWW
November 26, 2012, 12:29:41 AM
 #8204

Ok, if that's the case then that solves the issue.  Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?
For scenario A, if the old diff applies to work given out prior to the diff change it's almost the same as tying it with the work, and is how cgminer currently manages difficulty already for rising diff. Scenario C will sort itself out as well. So this works for me.

What about if diff drops as in scenario B? Do you credit work to the new difficulty or does the old difficulty still apply?

There is still the potential for lost opportunity in scenario D, and this would be no different if difficulty is tied with work or not, with gbt or stratum, as every window lost is the time of a one way trip from the server to the miner. While small, if done often it would start to add up. Thus it would still be prudent to minimise the diff changes to avoid this.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
November 26, 2012, 12:50:07 AM
 #8205

For scenario B, the old difficulty would still apply to work for that discrete issue of work.  I definitely do not want to create a potential scenario where it could be exploited by forcing a difficulty change.  One way can be exploited by pool ops (not accepting work once difficulty changed), one way can be exploited by miners (accepting work for higher difficulty work as valid once work drops) and one way (tying difficulty to work) can not be exploited by either, and this seems the most sane way to handle it. 


If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
optimator
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile WWW
November 26, 2012, 12:59:58 AM
 #8206


What about if diff drops as in scenario B? Do you credit work to the new difficulty or does the old difficulty still apply?


I think for scenario B, the pool must either a) credit the miner the shares at the new difficulty; or b) push cleanjobs=true. There is an advantage for the pool op in pushing cleanjobs=true, but the visible result will be in stale rejects.

mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
November 26, 2012, 01:44:53 AM
 #8207

With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively.

It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2.  I couldn't tell by the share output, because it always says x/1, but I see this on top:

Code:
(5s):1.928G (avg):1.963Gh/s | Q:167  A:1075  R:6  HW:0  E:644%  U:20.2/m
TQ: 0  ST: 7  SS: 1  DW: 328  NB: 7  LW: 1789  GF: 0  RF: 2  WU: 27.9

The WU is around what I expect U to be when dealing with difficulty 1 work.  Am I reading this right?

Any change we could get a decimal point or two in the cgminer output to show this? Smiley

Regards,

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2618
Merit: 1123


Ruu \o/


View Profile WWW
November 26, 2012, 01:47:19 AM
 #8208

With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively.

It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2.  I couldn't tell by the share output, because it always says x/1, but I see this on top:

Code:
(5s):1.928G (avg):1.963Gh/s | Q:167  A:1075  R:6  HW:0  E:644%  U:20.2/m
TQ: 0  ST: 7  SS: 1  DW: 328  NB: 7  LW: 1789  GF: 0  RF: 2  WU: 27.9

The WU is around what I expect U to be when dealing with difficulty 1 work.  Am I reading this right?

Any change we could get a decimal point or two in the cgminer output to show this? Smiley
Not much point when we'll all be mining difficulties in the 10s to 100s soon.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
DrHaribo
Legendary
*
Offline Offline

Activity: 2436
Merit: 1019


Bitminter.com Operator


View Profile WWW
November 26, 2012, 06:37:47 AM
 #8209

send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5 135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000 000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21 a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}

! :-)

That did it, thanks!

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
P_Shep
Legendary
*
Offline Offline

Activity: 1176
Merit: 1000


View Profile
November 26, 2012, 06:19:21 PM
 #8210

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
November 26, 2012, 06:25:13 PM
 #8211

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?
cgminer isn't switching to new work right away.

Here's the fix in bfgminer 2.9.3, though I'm not sure it will work as-is in cgminer without some other changes too.

juhakall
Sr. Member
****
Offline Offline

Activity: 586
Merit: 250



View Profile WWW
November 26, 2012, 07:26:09 PM
 #8212

Noticed a share rejection problem with 2.9.5. I removed failover-only from my config because share leakage is lower, only ~0.01% of all accepted shares are sent to backup pools now. My setup on all rigs is the same, CoinLab as the main pool, BitMinter as first backup and Eclipse as last resort. All the accepted leaked shares go to BitMinter, and that's no problem anymore because they are so rare. However, my miners only gather rejects on Eclipse, about 10 rejects for every share leaked to BitMinter. No shares have been accepted on Eclipse so far, and one rig has already marked it as Rejecting.

If I also account for rejected leaked shares, the total amount is still only ~0.1%, so it doesn't matter much. But this definitely isn't behaving correctly now. I can help testing this if it's not obvious what the problem could be.

Elitehash PPS Pools: Bitcore, Gincoin, Raven
Lem
Jr. Member
*
Offline Offline

Activity: 78
Merit: 0


View Profile
November 26, 2012, 08:32:14 PM
 #8213

I removed failover-only from my config because share leakage is lower

I did the same. I can confirm that with 2.9.5 share leakage has actually gone back down to a negligible minimum. Smiley

Well done! Smiley

--
Bye
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2618
Merit: 1123


Ruu \o/


View Profile WWW
November 26, 2012, 08:47:16 PM
 #8214

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.

This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.

Try the EMC GBT server until it's resolved.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
November 26, 2012, 09:06:44 PM
 #8215

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.
That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

juhakall
Sr. Member
****
Offline Offline

Activity: 586
Merit: 250



View Profile WWW
November 26, 2012, 09:09:56 PM
 #8216

The share rejection problem I have on EMC (described a few posts ago) isn't connected to stratum. I'm using http://us2.eclipsemc.com:8337 as the URL and miner.php says it's not using stratum. I'm not sure if it's using GBT, though. How do I check that?

Elitehash PPS Pools: Bitcore, Gincoin, Raven
P_Shep
Legendary
*
Offline Offline

Activity: 1176
Merit: 1000


View Profile
November 26, 2012, 09:11:01 PM
 #8217

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.
That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

I'm miss-labelling here, sorry. I didn't mean stale, I meant rejected (for whatever reason).
kano
Legendary
*
Offline Offline

Activity: 2548
Merit: 1052


Linux since 1997 RedHat 4


View Profile
November 26, 2012, 09:25:39 PM
 #8218

So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?

I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises.
That wouldn't make them stale... and EMC accepts shares at the lower target for work issued before it changed...

I'm miss-labelling here, sorry. I didn't mean stale, I meant rejected (for whatever reason).
Yes we all understood that ... except one 'person' Tongue

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
November 26, 2012, 09:46:03 PM
 #8219

My EMC rejects are 1.2% with stratum. I understand the post LP dump and I appreciate the chance at a paid share. The intermediate Rejected [Blah blah blah] (Unknown-Work). Usually this is in the middle of 2 other results found in a work unit or at least the 2nd submission at a time. Sometimes its first, sometimes last I guess.

It doesn't seem like unknown work. Things before it get accepted, after it also accepted. If the work was actually unknown wouldn't I expect more then a single reject in a batch of submissions? I suppose I could be piling up a result every so often that isn't accepted and on resubmit it is rejected. Expiry is likely a little high at 120s but my lower results are running the same.

Setup 1 BFL Single and CGMiner 2.9.5.

Before junior pipes up about GBT. I ran .2% rejects on GW, .8% on GBT, 1.2% on stratum on eclipse. All results on eclipse. The reduction of network traffic is far nicer then the slight reduction in rate.

Also on Stratum I am seeing a 856.X overall hashrate, Last week I managed 852.X with GBT and more network load. This could be new difficulty related or luck as it has only been on for 26K shares.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2618
Merit: 1123


Ruu \o/


View Profile WWW
November 26, 2012, 09:54:03 PM
 #8220

There's something else about stratum on EMC, and that appears to be lots of disconnects? That's another limitation of stratum, that once you disconnect the shares cannot be submitted on reconnect. Slush is going to have to add a reconnect option to it, or any disconnect of the socket will always be associated with shares lost if you're actively mining on it. Certainly it appears to be a combination of things and not just the frequent retargetting, although that is easy to see - the reject will say something like "share above target". "Unknown work" after longpoll is a true stale, work from the previous block. Not sure what's going on with GBT on EMC, but yes the rejects appear higher there too. For the time being you can still mine on getwork with --fix-protocol, but I'd rather see the pool issues sorted out.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 847 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!