Bitcoin Forum
June 20, 2024, 07:53:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 »
1361  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 18, 2011, 05:39:54 AM
How many other people saw "None" for their Payments on the following rounds/blocks?

#      Block found                 Duration     Total shares      Your reward        Block #   
1207   2011-02-17 23:46:14   0:00:58   682                   none                   108812   
1206   2011-02-17 23:45:16   0:00:20   178                   none                   108811

I should have at least seen something on the 1207 round...but didn't.  Using a regular miner with a askrate of 5.

I had the *exact* same number of shares, and duration, but i got a reward:

#      Block found                 Duration     Total shares      Your reward        Block #   
1207   2011-02-17 23:46:14   0:00:58   682   0.20091418   108812    105 confirmations left
1206   2011-02-17 23:45:16   0:00:20   178   0.26010487   108811    104 confirmations left

That's not the number of shares that YOU had, that's the total number of shares that were submitted for that block before it was solved. I had 1 of the 178 and so did you. FairUser didn't submit any shares before the 178th share which solved it.

Thank you for the response.
1362  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 18, 2011, 12:08:22 AM
How many other people saw "None" for their Payments on the following rounds/blocks?

#      Block found                 Duration     Total shares      Your reward        Block #   
1207   2011-02-17 23:46:14   0:00:58   682                   none                   108812   
1206   2011-02-17 23:45:16   0:00:20   178                   none                   108811

I should have at least seen something on the 1207 round...but didn't.  Using a regular miner with a askrate of 5.
1363  Bitcoin / Bitcoin Discussion / Re: Abusing Bitcoin mining pools: strategies for egoistical but honest miners on: February 17, 2011, 04:46:31 AM
Is this strategy is based on making a choice of whether to join or not to join, to keep working or to stop working, to/for some particular pool out of a given set of pools at any given time?

If so than to me this seems to be an exercise in futility. Past performance does not guarantee the future results. You have nearly perfect model of random walk here, at any given time chances of finding a solution for a given contribution (i.e. risk reward) is about the same. By jumping around a bunch of pools you win some than loose some. Over longer period of time it will be all the same. More likely though you lose some on overheads related to pool jumps.

It is nearly the same as day trading on stock market following some pundit recommendations or some TA strategy, i.e. you win some, you lose some but in the end you are inescapably screwed by broker fees and liberated from your money.

Agreed.  Jumping pools doesn't damage/cause any time of fraud or attack against that pool.  That's just someone who is *trying* to play their odds, but the odds of winning in some pools and loosing in others will balance out.  The point being, it's useless to jump pools.

Pick one and stick with it.  Why anyone put any credit into pool jumping I don't know, but if you think it's worth it, then give it a try.....you'll be back to mining in a single pool within a few days.

1364  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 09:38:48 AM
Exactly. No reason to remove everything else if you're only accepting shares for the current block. Not round. Block.

I'm kindly asking you, geebus and FairUser, to stop trolling here again, as you did in m0mchil thread few days ago.

Dude, our modifications to momchill's miner would seriously reduced the load on your server......yet we're trolling?  WTF Ever.
Diablo's miner does this already, but momchills doesn't. That's the point we were making on m0mchill's thread.
1365  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 09:32:37 AM
That would be a viable option for the extra paranoid server operator.

If I did not do anything to stop possible cheating, YOU will be the first person complaining I don't care enough.

Bullshit.  You and I discussed in PM about how to stop this.. I even told you how to modify your bitcoind to prevent an attacker from taking advantage of the 8 connection max hardcoded limit (then it got fixed officially)....so don't give me that shit.
1366  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 09:05:10 AM
"Anti cheating" is totally a straw-man's argument.  How can the Hall of Fame can be used to cheat the pool?
If I'm wrong then please explain how can the Hall of Fame be used by me or anyone else to cheat the pool?

Cheating requires knowing when the current round started.

Negative.  Because slush implemented the "if the answer for your getwork didn't come from the current bitcoin block, then it's going to be treated as invalid" rule, letting people see when the round begins or ends doesn't magically enable them to "spend" their getwork answer's on the next round...and it's  *BECAUSE* of that new rule the fraud stopped (which is good). 

Stripping all the extra stats from accounts was not required to stop fraud, it was excessive, and taking down the hall of fame was not required, it was overkill.  His one fix was sufficient, while still enabling the users to know the operator was being honest.  Now that's not the case.

But why not delay the Hall of Fame by 2 hours?

That would be a viable option for the extra paranoid server operator.
1367  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 08:35:44 AM
Quote
Quote
Why not show the Hall of Fame anymore?  How can that screw anyone?

Anti cheating. 60% of blocks were generated by top20 users.


What?!  If anything it provided a means for the top20 users to make sure we weren't being cheated!!

"Anti cheating" is totally a straw-man's argument.  How can the Hall of Fame can be used to cheat the pool?
If I'm wrong then please explain how can the Hall of Fame be used by me or anyone else to cheat the pool?

1368  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 06:38:31 AM
Am I just unlucky, or is something screwy going on here?

A lot of people seem to be getting unlucky here.
1369  Bitcoin / Pools / Re: Cooperative mining (>20Ghash/s, join us!) on: February 15, 2011, 02:23:08 AM
It seems like you took the option to change passwords away too. 
How do I delete my account, or change my password?
Why not show the Hall of Fame anymore?  How can that screw anyone?
Seriously, what's your deal dude? 
Why are you taking away all the features/information people want? 
Every week something else is going away...
Next week we won't even have graphs or a stats page at this rate.

1370  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: February 06, 2011, 06:05:40 AM
I'm still seeing several invalid stale hashes being submitted.
Any idea as to why?

Maybe because they are really stale? http://blockexplorer.com/block/00000000000018cf119be227dcf0d7403b20dc9b8fa0c3d6bc9022c65baf9a39

So getworks are now going stale even faster....thanks for clarifying.
1371  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: February 06, 2011, 06:02:48 AM
Literally just got these

05/02/2011 22:00, 2a07e960, accepted
05/02/2011 22:00, fe7439af, accepted
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale
05/02/2011 22:01, 2a07e960, invalid or stale
05/02/2011 22:01, fe7439af, invalid or stale

This is on a stock miner....no mods of any kind.
6 getworks were requested, and the answer found were repeats.
1372  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: February 06, 2011, 12:21:47 AM

No server accept shares for whole round, not only for current block.


So it's been changed back to how it was. The server accepts shares for the current round, even if the block count changed by 1?
Any old work from previous rounds are ignored?
1373  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: February 06, 2011, 12:19:00 AM
I've updated my miner to reduce share loss in pool situations. Update to newest.

Thank you.
1374  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: February 06, 2011, 12:16:19 AM
I'm still seeing several invalid stale hashes being submitted.

05/02/2011 16:12, 3725321b, accepted
05/02/2011 16:13, b794eb73, invalid or stale
05/02/2011 16:13, 898ceca7, invalid or stale
05/02/2011 16:13, bde1a5f3, invalid or stale
05/02/2011 16:14, 0a07cf1a, accepted

Any idea as to why?
1375  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: February 05, 2011, 11:46:17 PM
Damn, I leave for 1 week, come back and the server stats are totally different and gone.
All this crap to try and prevent "fraud".  Delaying/removing stats doesn't stop that BTW.
The server already only accepts shares for current blocks, but what you've done is overkill, plain and simple.

Time for a new pool server to be born, cause this just blows now.
1376  Bitcoin / Mining / Re: Mining inefficiency due to discarded work on: February 01, 2011, 08:58:08 AM

And no, title of this topic should not be 'how is poclbm skipping blocks', because it isn't true.

You misquoted me.
I never said "how is poclbm skipping blocks". 
What I did say was "How Python OpenCL (poclbm) is mining inefficiently".
Can you read/see the difference?  If you're going to quote someone, get it right.

poclbm has found 10 blocks for your pool on my machines. 
It's the number of answer's per getwork that I've been questioning, NOT BLOCKS.
1377  Bitcoin / Mining / Re: Mining inefficiency due to discarded work on: February 01, 2011, 08:16:44 AM
Only 1 answer get's the block.  So when you say "You can skip an answer by going on to the next work", are you saying that the likely hood of that skipped getwork/answer being *the answer* is sooooooooo small that it's just not worth it to find it, and we should just move on to the next getwork?

I'm saying that there are 1.224 × 10^63 answers which get the block, so skipping one of them is inconsequential.

The answer which counts is simply the first one of those 1.224 × 10^63 valid answers which is found, but it is by no means the only answer.

We simply stop looking after we find it.  If we had wanted to, we could hash the same block for a month and find about 4,380 valid answers for it in that time.

OK, my mind just fucking flipped.  Nobody but you has said their are 1.224 × 10^63 answers to a block.  I've been under the impression (due to imformation provided by others) that only 1 answer was the correct answer to find the block, and that the getwork:solved ratio was always 1:1.
We've been talking about multiple solutions to a getwork....but that now makes a bit more sense as to why I'm seeing more than 1 answer in a getwork.

So ANY one of the possible 1.224 × 10^63 answers would catch me 50 bitcoins?


SO....

1.1579208923731619542357098500869e+77 (2^256) / 1.224e+63 (1.224x(10^63)) = 94601380095846.564888538386445008

94601380095846 / 30000000000 (pool speed) = 3153.3793365282 (seconds)
3153.3793365282 (seconds) / 60 (seconds) = 52.55632227547 (minutes)

That sounds about right.  You're the first one to explain this in that level of detail.  Thank you for clarifying.  Sure wish someone else had said it like that.
So if their are 1.224e+63 answers, the miner just says "10 seconds have passed so fuck it, move to the next getwork and hope we find something."  Something like that??
1378  Bitcoin / Mining / Re: Mining inefficiency due to discarded work on: February 01, 2011, 08:00:34 AM
Not every getwork is equal. Not every hash is equal. It's not random. There is a single answer per block. If that answer is never provided because you skipped it, it doesn't fucking matter how many wrong answers you provide to try and make up for it. They will still be wrong.

The entire search-space for a single block is 2^256 hashes.
There are 2^224 answers per block when difficulty is 1.
At the present difficulty of 22012.4941572, there are 2^224 / 22012.4941572 valid answers.
That's 1.224 × 10^63 valid answers.
Out of 1.157 × 10^77 total answers.
The pool can process about 30,000,000,000 hashes per second.
That's 3.0 × 10^10 hashes per second.
It would take 3.859e+66 seconds for the pool to search through every possible hash in a single block.
That's 6.432 × 10^64 minutes.
That's 1.072 × 10^63 hours.
That's 4.467 × 10^61 days.
That's 1.223 × 10^59 years.
That's 8.901 × 10^48 times the age of the universe.

You can skip an answer by going on to the next work.
This will leave you with a possible 1.224 × 10^63 - 1 valid answers.
That's 1.224 × 10^39 times more valid answers than there are stars in the universe.

We are searching through a possible 115 quattuorvigintillion, 792 trevigintillion, 89 duovigintillion, 237 unvigintillion, 316 vigintillion, 195 novemdecillion, 423 octodecillion, 570 septendecillion, 985 sexdecillion, 8 quindecillion, 687 quattuordecillion, 907 tredecillion, 853 duodecillion, 269 undecillion, 984 decillion, 665 nonillion, 640 octillion, 564 septillion, 39 sextillion, 457 quintillion, 584 quadrillion, 7 trillion, 913 billion, 129 million, 639 thousand and 936 hashes for every block.
Trying to find, at the current difficulty, one of 1 vigintillion, 224 novemdecillion, 756 octodecillion, 562 septendecillion, 96 sexdecillion, 912 quindecillion, 245 quattuordecillion, 974 tredecillion, 145 duodecillion, 865 undecillion, 520 decillion, 4 nonillion, 272 octillion, 488 septillion, 786 sextillion, 20 quintillion, 128 quadrillion, 241 trillion, 774 billion, 877 million, 474 thousand and 816 valid answers.



Only 1 answer get's the block.  So when you say "You can skip an answer by going on to the next work", are you saying that the likely hood of that skipped getwork/answer being *the answer* is sooooooooo small that it's just not worth it to find it, and we should just move on to the next getwork?

1379  Bitcoin / Mining software (miners) / Re: python OpenCL bitcoin miner on: February 01, 2011, 07:55:23 AM
Note: Many off-topic posts about mining efficiency were moved here.

Had you read it, you would know that it wasn't off topic.  Slush kept talking about the pool, but we're talking about the miner and the pool.
1380  Bitcoin / Mining / Re: Mining inefficiency due to discarded work on: February 01, 2011, 06:43:22 AM
This is the key point right here:
every box is equal - checking 100 tickets from a new box completely compensates not checking 100 tickets from the previous box.

Due to the way hashes are essentially random, it doesn't matter if you switch before completing work.

Yes it does.  It you don't complete your work, you *might* be skipping the correct answer/hash/nonce for the block.
If every getwork is only issued once, and the nonce/answer is skipped because your miner quit looking after finding only 1 answer (when more than 1 is possible), then YOU COULD HAVE SKIPPED THE ANSWER FOR THE BLOCK.  
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!