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

[yuancraft]

server have a trouble ? the hash going down men
my miner going down too 

[1714222023]

1714222023

[1714222023]

1714222023

[1714222023]

1714222023

[cablepair]

somethings going on

my miners keep getting disconnected.

(problems connecting with bitcoin rpc)

then they go back up and back down again...

edit...


I think we are back in business ;>

[tunganh91]

Rewards are not confirmed until 120 new blocks have been generated.  Bitcoin tries to generate a block on average every 10 minutes, but that varies.  You can look at the stats page to see how many blocks remain for each reward.

Thanks so much 

[Jaime Frontero]

all better?

[slush]

Rewards are not confirmed until 120100 new blocks have been generated. 

Pool is waiting 100 confirmations, which is minimum required by bitcoin network. Next 20 blocks on top are required by bitcoin client itself, but it can be changed (as I did for the pool).

[slush]

somethings going on

Looked like issues of provider; pool itself performed well, just traffic went a little down (but not too much, so majority of users were still mining). It recovered after ~45 minutes to original throughput, now is traffic fine again.

[tunganh91]

I can see some BTC in Confirmed reward, but in my client,  balance's still blank?? So does is take time to tranfer or anything wrong???

[slush]

I can see some BTC in Confirmed reward, but in my client,  balance's still blank?? So does is take time to tranfer or anything wrong???

Confirmed reward is still waiting on the pool. Once BTC on your pool account cross the threshold (by default 1 BTC), bitcoins are sent to your wallet. If you hurry, please set the threshold to something like 0.01..

[ItsASpork]

I'm using GUIminer, so no command line. Is that what I'm doing wrong?

No, it should work. GUIminer has 'console window' somewhere, there you can find used parameters for the miner, please post them here (except password, of course).

Ok, this is what it says:

Running command: poclbm.exe --user=[username] --pass=[password] -o mining.bitcoin.cz -p 8332 -d0 --verbose
Listener for "Default" started

Maksure that it is

--user=Username.Workername

not just

--user=Username


and --pass=WorkerPassword not User's Site Password.

Just checked both of those, and it still won't connect...

Anyone have an idea of what I'm doing wrong? Maybe I should add I'm using a GTX 460.

[Jarredm]

Hey, so I have a few questions about cooperative mining and mining in general,
1) Would it be a good idea to create a hash-lookup table from the already generated hashes and then when a new block is released, just see if it is already in the hash table?
2) in the cooperative mining project, couldn't somebody just check the hashes to see if they match he block before they send them to the group, and thus getting bitcoins if they don't find it and the whole 50 if they do? (I know this isn't fair, but people rarely are)
3) Finally, the last graph here: http://mining.bitcoin.cz/stats/graphs/ seems to indicate that 100% of the blocks that this group attempts are found by this group. This seems odd because from what I understand about bitcoin mining, which is not very much, this is very improbable. Am I reading the graph incorrectly, have the blocks that were solved by others been edited out of the data, or am I making some other silly mistake?

Thank you in advance for you replies

Let me address you first question.  While a rainbow table it technically possible it appears to be practically unattainable as of now.  The reason for this is the current block being hashed has multiple inputs.  The first input is the hash of the previous block, which is why it is referred to as the block chain.  The second is the input of the new transactions waiting for confirmation (simplified I know).  The third is a random set of data.  What this means is that in order for a rainbow table to be created you have to create a resultant set of data comprising all possible inputs and the table would have to be extremely large. It is the addition of the random data that makes the table so large.  See http://en.wikipedia.org/wiki/Salt_(cryptography).  While the generation of these tables isn't out of reach for a "No Such Agency" governmental organization.  It is practically impossible for mining operators.  Bottom line, you could potentially create a master rainbow table covering all of the possible hashes but it would be 1.06x10¹⁸³ bytes in size.

Question number 2.  No because the next block's hash uses the current hash as an input.  Therefore you haven't hashed it before.

On the last question.  Please see the wikipedia link that slush provided in order to understand what the CDF data means.

[anisoptera]

The real answer to question 2 is that the block you are hashing contains the pool's address as where the generated btc should be sent. You could publish it yourself but it wouldn't gain you anything.

[Jarredm]

The real answer to question 2 is that the block you are hashing contains the pool's address as where the generated btc should be sent. You could publish it yourself but it wouldn't gain you anything.

You are right @anisoptera  I did not understand the question the first time around.  That is correct in that if you tried to claim if for yourself you would have to insert your address which would change the hash output and render it an invalid solution.

[SJ]

While the generation of these tables isn't out of reach for a "No Such Agency" governmental organization.  It is practically impossible for mining operators.  Bottom line, you could potentially create a master rainbow table covering all of the possible hashes but it would be 1.06x10¹⁸³ bytes in size.

The number of atoms in the observable universe is 10⁸⁰[1]. No need to overestimate gov organisations.

[slush]

That is correct in that if you tried to claim if for yourself you would have to insert your address which would change the hash output and render it an invalid solution.

It is even more simple. Worker cannot publish block directly to the bitcoin network, because he does not know block sources, only hash of blockheader, for which he is trying to find proper "nonce" value.

[allinvain]

wow slush, your pool has grown quite considerably lately..almost 400 Ghashes!! Congrats.

[mhajicek]

Forgive me if this has already been covered; I did some searching and came up empty.  I'm just starting to dabble here, and the total reward doesn't seem to add up.  Here's what I'm seeing:

Estimated reward: 0.01120823 BTC
Unconfirmed reward: 0.10141200 BTC
Confirmed reward: 0.16376258 BTC
Total reward: 0.44276681 BTC

Thanks!

[BitterTea]

Estimated reward: based on your current share submission rate, what will (probably) be your slice of the next 50 BTC pie?
Unconfirmed reward: you only get your reward after 120 blocks, these are the ones that are less than that age
Confirmed reward: rewards older than 120 blocks
Total reward: sum of all of the above

[commlinx]

Normally I get unconfirmed + confirmed = total (estimated is ignored) and right at the moment mine adds up that way. However I've noticed around the time a block is solved it takes a while for some things to get added and you can get some odd results. Wait until a round has been in progress 10 mins or more and then check again and see how it looks.

[BitterTea]

Normally I get unconfirmed + confirmed = total (estimated is ignored) and right at the moment mine adds up that way. However I've noticed around the time a block is solved it takes a while for some things to get added and you can get some odd results. Wait until a round has been in progress 10 mins or more and then check again and see how it looks.

You're right, estimated reward is not included in total reward.

[mhajicek]

Okay, what confused me was that the total reward number was more than confirmed + unconfirmed.