Bitcoin Forum
December 02, 2016, 06:35:10 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3160 (80.5%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.1%)
Total Voters: 3924

Pages: « 1 ... 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 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 ... 1105 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3924750 times)
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
April 22, 2011, 05:33:52 AM
 #1721

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

Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks !
ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures (NEW!). Third year in bitcoin business.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 08:55:58 AM
 #1722


Can the same shares be sent to different pools ?

[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
April 22, 2011, 08:57:49 AM
 #1723

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 :)

Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks !
ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures (NEW!). Third year in bitcoin business.
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 09:24:25 AM
 #1724

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 Smiley

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

commlinx
Full Member
***
Offline Offline

Activity: 126



View Profile
April 22, 2011, 09:45:43 AM
 #1725

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
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 22, 2011, 10:23:45 AM
 #1726

"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 Smiley

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 01:35:03 PM
 #1727

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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 22, 2011, 01:35:52 PM
 #1728

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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 22, 2011, 01:36:43 PM
 #1729

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 02:56:01 PM
 #1730

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.

 Huh
I suppose I wasn't clear Smiley 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
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 22, 2011, 03:18:54 PM
 #1731

Huh
I suppose I wasn't clear Smiley 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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 04:47:26 PM
 #1732

Huh
I suppose I wasn't clear Smiley 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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 22, 2011, 05:16:08 PM
 #1733

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 06:09:27 PM
 #1734


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
Newbie
*
Offline Offline

Activity: 5


View Profile
April 22, 2011, 06:33:01 PM
 #1735

...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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 22, 2011, 07:24:27 PM
 #1736

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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Psychoactive
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 22, 2011, 11:23:00 PM
 #1737

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
Hero Member
*****
Offline Offline

Activity: 513



View Profile
April 23, 2011, 12:35:01 AM
 #1738

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

BTC - 1PeMMYGn7xbZjUYeaWe9ct1VV6szLS1vkD - LTC - LbtcJRJJQQBjZuHr6Wm7vtB9RnnWtRNYpq
Ian Maxwell
Full Member
***
Offline Offline

Activity: 140



View Profile WWW
April 23, 2011, 12:47:42 AM
 #1739

Yeah, that's kind of worrying.

But hey, it's confirmed already!

Ian Maxwell
PGP key | WoT rating
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
April 23, 2011, 02:33:21 AM
 #1740

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 Smiley  I think I will be mining for quite awhile yet.  All the southerners are at a huge disadvantage I think.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
Pages: « 1 ... 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 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 ... 1105 »
  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!