Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 186. (Read 794394 times)
April 17, 2015, 01:58:07 PM
With d= you can only set starting diff, then our proxy will adjust diff according to speed of your miner. If your miner sends too little shares, it will reduce diff (but never below buyers target pool diff) and if your miner sends too many shares, it will increase diff. Because number of shares depend on luck, even your slow miner can sometimes get high diff (winning streak), but as soon as this "luck" ends, it will get low diff. What is more important is that your miner shows approximate the correct speed (declared) over longer period of time.
April 17, 2015, 11:54:23 AM
And why do my slower rigs get hit with such high diff?
They are all asking for 8192 (except proxy which doesn't ever get the 32768 I'm asking for). The 60MH rig is especially prone to getting diff way too high as can be seen @ 131072.0000.
They are all asking for 8192 (except proxy which doesn't ever get the 32768 I'm asking for). The 60MH rig is especially prone to getting diff way too high as can be seen @ 131072.0000.
April 17, 2015, 11:50:58 AM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
Thanks for the reply.
I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.
The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.
I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.
Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.
As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.
Ahhhhh, I see. I misunderstood what you were saying.
In this example, from top to bottom: A2 90, A2 60, Titan, Achemist
The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?
Thanks
Proxifying will not help. If buyer has low diff pool or mines low diff coin, there is nothing you can do but to press your ASIC provider to give you better software/firmware (if anything can be improved with new software at all).
I understand that, what I meant was if I were to run all the rigs through a proxy they should all get the same diff (low or high) since they'd be seen as one available rig to your servers, correct?
April 17, 2015, 11:24:40 AM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
Thanks for the reply.
I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.
The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.
I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.
Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.
As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.
Ahhhhh, I see. I misunderstood what you were saying.
In this example, from top to bottom: A2 90, A2 60, Titan, Achemist
The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?
Thanks
Proxifying will not help. If buyer has low diff pool or mines low diff coin, there is nothing you can do but to press your ASIC provider to give you better software/firmware (if anything can be improved with new software at all).
April 17, 2015, 11:18:41 AM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
Thanks for the reply.
I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.
The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.
I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.
Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.
As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.
Ahhhhh, I see. I misunderstood what you were saying.
In this example, from top to bottom: A2 90, A2 60, Titan, Achemist
The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit?
Thanks
April 17, 2015, 11:10:22 AM
Service back up&running.
For those interested in mining Quark algorithm coins (Quark coin, etc.) on NiceHash/WestHash: Quark algorithm has been added
You can download sgminer with Quark support here:
https://www.nicehash.com/index.jsp?p=software#sgminer
MULTIALGO note:
Quark is disabled on multilago by default (transition will probably take a while). But nevertheless if you want to use multialgo you can still use it by manually adding Quark factor to your pool's password setting, for example:
"pass" : "f0=0;f2=0;f3=8.5;f4=4.5;f5=500;f6=3.5;f7=14;f8=0.35;f9=1.25;f10=135;f11=6.5;f12=2",
(as always, remember to add this to ALL your NiceHash/WestHash pools entries, not only for the new Quark entry).
For those interested in mining Quark algorithm coins (Quark coin, etc.) on NiceHash/WestHash: Quark algorithm has been added
You can download sgminer with Quark support here:
https://www.nicehash.com/index.jsp?p=software#sgminer
MULTIALGO note:
Quark is disabled on multilago by default (transition will probably take a while). But nevertheless if you want to use multialgo you can still use it by manually adding Quark factor to your pool's password setting, for example:
"pass" : "f0=0;f2=0;f3=8.5;f4=4.5;f5=500;f6=3.5;f7=14;f8=0.35;f9=1.25;f10=135;f11=6.5;f12=2",
(as always, remember to add this to ALL your NiceHash/WestHash pools entries, not only for the new Quark entry).
April 17, 2015, 10:25:56 AM
We have to apply a few updates, therefore connection to NiceHash web as well as stratum servers will be interrupted in the next hour. Thank you for understanding.
April 17, 2015, 03:48:58 AM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
Thanks for the reply.
I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.
The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.
I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.
Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.
As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares.
April 17, 2015, 02:52:23 AM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
Thanks for the reply.
I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter.
The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine.
I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user.
Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though.
April 16, 2015, 04:32:16 PM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers).
The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services.
April 16, 2015, 02:51:47 PM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
Hmm, looks like I'll have to dig. Thanks for the tip.
Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low.
April 16, 2015, 02:38:12 PM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect
. I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts.
April 16, 2015, 02:31:39 PM
Not sure what just happen i went to set up a order with the nice hash bot it did this
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
Wow that must have gone instantly! No speed limit either. Even if it ran at your specified price it would have taken seconds to drain. No speed limit means it'll throw wheatever it can at the order. If it could have found the miners quick enough you could have passed 2PH.
LOL 2 PH some thing went wrong i just hope i get back the BTC it took.
April 16, 2015, 02:08:12 PM
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
April 16, 2015, 01:20:27 PM
Not sure what just happen i went to set up a order with the nice hash bot it did this
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
Wow that must have gone instantly! No speed limit either. Even if it ran at your specified price it would have taken seconds to drain. No speed limit means it'll throw wheatever it can at the order. If it could have found the miners quick enough you could have passed 2PH.
April 16, 2015, 01:16:39 PM
Not sure what just happen i went to set up a order with the nice hash bot it did this
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
I did have it set start at 0.0106 and max at 0.0108 for some reason it put it at 99.9999 then finished the order and took the BTC.
what went or what if any thing did i do wrong ?.
DO i get back those 0.0221 BTC i never really used ?.
April 15, 2015, 01:14:48 PM
congrats to the winner!
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
Well, that's not exactly how randomness works...
http://en.m.wikipedia.org/wiki/Gambler%27s_fallacy
So much widespread...
April 15, 2015, 12:08:31 PM
Regarding last payments; one of the transactions was refused by our Bitcoin processing provider. We had to manually process it. As a result, some providers were paid 1 hour later than usual. We are sorry for the inconvenience.
April 15, 2015, 04:40:22 AM
congrats to the winner!
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
Well, that's not exactly how randomness works...
http://en.m.wikipedia.org/wiki/Gambler%27s_fallacy
So much widespread...
April 15, 2015, 12:22:31 AM
congrats to the winner!
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
If they were only mining with one S3 talk about Luck! Looks like they stopped after hitting because I couldn't see the address listed. Smart to stop - no shot for that miner to hit a second time. (well maybe 5 yrs later)
Well, that's not exactly how randomness works...
Jump to: