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

[[Tycho]]

...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.

[Psychoactive]

Can the same shares be sent to different pools ?

[[Tycho]]

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]

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 ?

[commlinx]

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.

[Meni Rosenfeld]

"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%.

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.

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.

[Psychoactive]

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.

[xenon481]

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

[xenon481]

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.

[Psychoactive]

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 ?

[Meni Rosenfeld]

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]

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?

[xenon481]

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]

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.

[melchior]

...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

[xenon481]

...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.

[Psychoactive]

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.

?

[Miner-TE]

Something not right with round #3546

#   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

[Ian Maxwell]

Yeah, that's kind of worrying.

But hey, it's confirmed already!

[Veldy]

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

Up here in the great white North, all the heat is useful about 7 months out of the year, neutral for one to two months and detrimental for the remainder.  Net positive for the year however.  So, the cost of electricity heating the home as opposed to the cost of using our natural gas forced air furnace is really the difference that matters on an annual basis and all I have to do is make a reasonable profit from mining that is greater than that such that it remains worth mining   I think I will be mining for quite awhile yet.  All the southerners are at a huge disadvantage I think.