[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1068.

Miner-TE

hero member

Activity: 499

Merit: 500

Something not right with round #3546 Huh

#   Block found   Duration   Total shares    Your reward    Block #   Validity
3546    2011-04-22 23:52:36    1:24:13    214068    0.07049353    0    confirmed
3545    2011-04-22 22:28:23    0:19:40    49986    0.04585730    119661    91 confirmations left
3544    2011-04-22 22:08:43    0:08:19    20749    0.02477761    119659    89 confirmations left
3543    2011-04-22 22:00:24    0:33:20    83610    0.03953177    119657    87 confirmations left
3542    2011-04-22 21:27:04    0:02:25    5980    0.00819398    119651    81 confirmations left

Psychoactive

newbie

Activity: 55

Merit: 0

What about :

Have a big rig such that it finds a block rather often. (2-3GH/s+)

Have parts of this rig in multiple pools, with score-based and share-based reward. When the subrig on the pool with score-based reward solves a block, retain the solution for a moment. Shift all your other subrigs working on pools with share-based reward to this pool, increase your score (this is rather quick in Slush's pool) until it you reach the score corresponding to the whole rig involved. Then submit the winning solution.

You could also extend this if electricity is expensive and mining is unprofitable at times for a part of your rig, so that you have certain of your miners idle. You can then use them as extra power to increase your score for a low energy consumption, since you turn them on at the right moment, and off again.

?

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: melchior on April 22, 2011, 01:33:01 PM

Quote from: [Tycho] on April 22, 2011, 12:33:52 AM

Quote from: melchior on April 21, 2011, 11:14:18 PM

...successfully crippling half of the total network capacity, slowing down the solve rates (long term lowering the difficulty at the pools expense?), and frustrating people in the pools.
The worst thing is they still get paid for working against the pools, because they do report hashes of lesser difficulty. Granted they would need a good bit of hash power but they likely have that otherwise why bother attacking the pools.
Just my guess based on the recent unusual pool behavior.

They'll need to have a half of network capacity to "cripple" it.
If someone has 15% of pool's capacity then he can only make pool's luck 15% less.

But if they have been given a work unit that solves the problem and they report back that no solution found (on the full difficulty nonce) they have just made the effective CDF of the pool 200% because they never reported a valid nonce back your pool now has to solve the problem at current difficulty 2 times or at 200%. This makes it much less likely that the pool you are attacking would get the coins that round. They would not need a large percentage of the pools capacity only maybe 1% into yours and/or slush's pools and because doubling the number of solutions needed to solve a block will make it much more unlikely that the pool will be able to get the coins that round.

I just recommending that you watch the pools for accounts that are doing +1000Mh/s or so but never seem to find any full difficulty nonces (beyond what should be statically possible) because they may be your troll. Remember they not only make the luck of the pool less but they also take rewards for the lesser difficulty solutions found decreasing everyone earned reward. I don't want to describe how they could do it less we give our troll any ideas but we all know the open source clients can be modified.
-Melchior

You are confusing CDF and "Expected" time to completion.

CDF is asymptotic to 100%. CDF describes that if you have processed X number of hashes, then it is Y% likely that you have found a valid block. Even if you process 123445333 Bajillion hashes, you will not have 100% assurance that one of those would have found a valid block; only 99.9999999999etc%.

"Expected" time to completion is completely different. Your expected time to find a valid block is after X number of hashes processed depending upon difficulty.

melchior

newbie

Activity: 5

Merit: 0

Quote from: [Tycho] on April 22, 2011, 12:33:52 AM

Quote from: melchior on April 21, 2011, 11:14:18 PM

...successfully crippling half of the total network capacity, slowing down the solve rates (long term lowering the difficulty at the pools expense?), and frustrating people in the pools.
The worst thing is they still get paid for working against the pools, because they do report hashes of lesser difficulty. Granted they would need a good bit of hash power but they likely have that otherwise why bother attacking the pools.
Just my guess based on the recent unusual pool behavior.

They'll need to have a half of network capacity to "cripple" it.
If someone has 15% of pool's capacity then he can only make pool's luck 15% less.

But if they have been given a work unit that solves the problem and they report back that no solution found (on the full difficulty nonce) they have just made the effective CDF of the pool 200% because they never reported a valid nonce back your pool now has to solve the problem at current difficulty 2 times or at 200%. This makes it much less likely that the pool you are attacking would get the coins that round. They would not need a large percentage of the pools capacity only maybe 1% into yours and/or slush's pools and because doubling the number of solutions needed to solve a block will make it much more unlikely that the pool will be able to get the coins that round.

I just recommending that you watch the pools for accounts that are doing +1000Mh/s or so but never seem to find any full difficulty nonces (beyond what should be statically possible) because they may be your troll. Remember they not only make the luck of the pool less but they also take rewards for the lesser difficulty solutions found decreasing everyone earned reward. I don't want to describe how they could do it less we give our troll any ideas but we all know the open source clients can be modified.
-Melchior

Psychoactive

newbie

Activity: 55

Merit: 0

Quote from: xenon481 on April 22, 2011, 12:16:08 PM

You have a string of data (the block) which includes a portion which is essentially an incremented number and a set of transactions including the transaction giving 50BTC to the miner's account (pool's account).

You then generate a checksum (hash) for that set of data. If that checksum is below a given value, then you have a successful block (share for pooled).

Generating this checksum is the "intensive" part of the process.

If the checksum is not below a given value, then you increment the incrementor portion of the data and generate the checksum again. At which point you get a completely different value. Changing anything in the data gives you a completely different value. That includes changing the payment address. Thus, changing anything inside of the data forces you to recalculate the checksum.

OK, thanks, I see.

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: Psychoactive on April 22, 2011, 11:47:26 AM

OK. But one could test all his hashes (not shares) against different pools or bitcoin clients? That could possibly multiply the possibility it is a winning hash (there exists a pool such that the hash is a winning one).

When involved in multiple pools, this would allow to reuse your hashes. That would require checking the hash is a winning one (or a share) for all pools or bitcoin clients addresses. But that would save the time of generating a hash. I don't know though if the generation of the hash is the most time-consuming or the checking of its validity as a share?

No.

You have a string of data (the block) which includes a portion which is essentially an incremented number and a set of transactions including the transaction giving 50BTC to the miner's account (pool's account).

You then generate a checksum (hash) for that set of data. If that checksum is below a given value, then you have a successful block (share for pooled).

Generating this checksum is the "intensive" part of the process.

If the checksum is not below a given value, then you increment the incrementor portion of the data and generate the checksum again. At which point you get a completely different value. Changing anything in the data gives you a completely different value. That includes changing the payment address. Thus, changing anything inside of the data forces you to recalculate the checksum.

Psychoactive

newbie

Activity: 55

Merit: 0

Quote from: Meni Rosenfeld on April 22, 2011, 10:18:54 AM

Quote from: Psychoactive on April 22, 2011, 09:56:01 AM

I suppose I wasn't clear

Would it be possible for someone to use part of the calculations performed by his graphic card to participate in multiple pools at a time and earn more ?

No. The hashing function used is such that any change in the details of the block will alter the hash in ways we can't imagine, making it for all practical purposes uniformly random. Mining consists in randomly tweaking details of the block until we find a tweak that makes the hash less than some number, which happens once in 2^32*difficulty tries (shares submitted to a pool have difficulty=1). If you find a nonce which satisfies the difficulty-1 requirement and then try to change one of the details, the new hash will once again have one in 2^32 chance of being a valid share, so it's no better than just trying an arbitrary nonce as usual.

OK. But one could test all his hashes (not shares) against different pools or bitcoin clients? That could possibly multiply the possibility it is a winning hash (there exists a pool such that the hash is a winning one).

When involved in multiple pools, this would allow to reuse your hashes. That would require checking the hash is a winning one (or a share) for all pools or bitcoin clients addresses. But that would save the time of generating a hash. I don't know though if the generation of the hash is the most time-consuming or the checking of its validity as a share?

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: Psychoactive on April 22, 2011, 09:56:01 AM

I suppose I wasn't clear

Would it be possible for someone to use part of the calculations performed by his graphic card to participate in multiple pools at a time and earn more ?

No. The hashing function used is such that any change in the details of the block will alter the hash in ways we can't imagine, making it for all practical purposes uniformly random. Mining consists in randomly tweaking details of the block until we find a tweak that makes the hash less than some number, which happens once in 2^32*difficulty tries (shares submitted to a pool have difficulty=1). If you find a nonce which satisfies the difficulty-1 requirement and then try to change one of the details, the new hash will once again have one in 2^32 chance of being a valid share, so it's no better than just trying an arbitrary nonce as usual.

Psychoactive

newbie

Activity: 55

Merit: 0

Quote from: xenon481 on April 22, 2011, 08:36:43 AM

Quote from: Psychoactive on April 22, 2011, 08:35:03 AM

Thanks.

Is there a possibility that a non-winning hash associated to a receiving address may become a winning hash when associated to another address ? Then one could check the hash over various receiving addresses instead of only one (several pools or bitcoin clients) ?

Is the bottleneck in the number of Mh/s processors calculate on the generation of candidate hashes or on their evaluation as winning hashes ?

Hope this is clear.

That is the equivalent of solo mining.

I suppose I wasn't clear

Would it be possible for someone to use part of the calculations performed by his graphic card to participate in multiple pools at a time and earn more ?

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: Psychoactive on April 22, 2011, 08:35:03 AM

Thanks.

Is there a possibility that a non-winning hash associated to a receiving address may become a winning hash when associated to another address ? Then one could check the hash over various receiving addresses instead of only one (several pools or bitcoin clients) ?

Is the bottleneck in the number of Mh/s processors calculate on the generation of candidate hashes or on their evaluation as winning hashes ?

Hope this is clear.

That is the equivalent of solo mining.

xenon481

sr. member

Activity: 406

Merit: 250

I'm not mining anymore due to summer air conditioning, but it is nice to see the pool at ~205 GHash/sec.

Psychoactive

newbie

Activity: 55

Merit: 0

Thanks.

Is there a possibility that a non-winning hash associated to a receiving address may become a winning hash when associated to another address ? Then one could check the hash over various receiving addresses instead of only one (several pools or bitcoin clients) ?

Is the bottleneck in the number of Mh/s processors calculate on the generation of candidate hashes or on their evaluation as winning hashes ?

Hope this is clear.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: melchior on April 21, 2011, 11:14:18 PM

"There is no such thing, unless you are rounding. CFD cannot reach 100%, it can only approach it."

I think, gentlemen you are making an bad assumption. You assume that a person in the pool will report a winning hash...

Such an attack is possible and has been discussed before, but it has nothing to do with it. The CDF still can't reach 100%.

Quote from: Psychoactive on April 22, 2011, 04:24:25 AM

Quote from: [Tycho] on April 22, 2011, 03:57:49 AM

Quote from: Psychoactive on April 22, 2011, 03:55:58 AM

Can the same shares be sent to different pools ?

No.

All pools check if it's their or not.
When you calculate your share, a receiving bitcoin address for those 50 BTC is "embedded" inside, so even if you try to take a winning share and use it yourself, money will be sent to the pool anyway

I suppose if you change the receiving bitcoin address part in the share, the share isn't a winning one anymore ?

Right. Changing the receiving address changes the Merkle root of the block, thus changes the block hash, thus it will no longer meet difficulty requirement.

Quote from: commlinx

From my (limited) understanding you'd also need the private key of the pool operator.

No, the private key is unrelated to this. Even the operator can't change the receiving address after a winning share is found.

commlinx

full member

Activity: 294

Merit: 100

Quote from: Psychoactive on April 22, 2011, 04:24:25 AM

I suppose if you change the receiving bitcoin address part in the share, the share isn't a winning one anymore ?

From my (limited) understanding you'd also need the private key of the pool operator. Don't forget you're not really receiving it in the usual sense, it's only that you have the only matching private key on the network that proves you have the rights to it.

Psychoactive

newbie

Activity: 55

Merit: 0

Quote from: [Tycho] on April 22, 2011, 03:57:49 AM

Quote from: Psychoactive on April 22, 2011, 03:55:58 AM

Can the same shares be sent to different pools ?

No.

All pools check if it's their or not.
When you calculate your share, a receiving bitcoin address for those 50 BTC is "embedded" inside, so even if you try to take a winning share and use it yourself, money will be sent to the pool anyway

I suppose if you change the receiving bitcoin address part in the share, the share isn't a winning one anymore ?

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: Psychoactive on April 22, 2011, 03:55:58 AM

Can the same shares be sent to different pools ?

No.

All pools check if it's their or not.
When you calculate your share, a receiving bitcoin address for those 50 BTC is "embedded" inside, so even if you try to take a winning share and use it yourself, money will be sent to the pool anyway :)

Psychoactive

newbie

Activity: 55

Merit: 0

Can the same shares be sent to different pools ?

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: melchior on April 21, 2011, 11:14:18 PM

...successfully crippling half of the total network capacity, slowing down the solve rates (long term lowering the difficulty at the pools expense?), and frustrating people in the pools.
The worst thing is they still get paid for working against the pools, because they do report hashes of lesser difficulty. Granted they would need a good bit of hash power but they likely have that otherwise why bother attacking the pools.
Just my guess based on the recent unusual pool behavior.

They'll need to have a half of network capacity to "cripple" it.
If someone has 15% of pool's capacity then he can only make pool's luck 15% less.

melchior

newbie

Activity: 5

Merit: 0

"There is no such thing, unless you are rounding. CFD cannot reach 100%, it can only approach it."

I think, gentlemen you are making an bad assumption. You assume that a person in the pool will report a winning hash...
If you were a miserable little troll who wanted to interfere with a mining pool what is the worst thing you could do?
I think they have joined your pools and are taking out work but not reporting the winning hashes (hashes that meets full difficulty). This will make your pools think that it has assigned the work for the as yet unknown winning hash so it never reassigns it to a new worker. If they manage to do that on both pools they can send over 300 Gh/s on a wild goose chase, successfully crippling half of the total network capacity, slowing down the solve rates (long term lowering the difficulty at the pools expense?), and frustrating people in the pools.
The worst thing is they still get paid for working against the pools, because they do report hashes of lesser difficulty. Granted they would need a good bit of hash power but they likely have that otherwise why bother attacking the pools.
Just my guess based on the recent unusual pool behavior.
-Melchior

commlinx

full member

Activity: 294

Merit: 100

Hi slush, no big deal but I noticed that since around the time of the DOS attack the system daily reward graph seems stuck.

Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1068. (Read 4382653 times)