pushpool issue?

[shamen]

Heya
Sorry its on the wrong forum section, but my account is limited to just here

Ive noticed soemthing odd with our pool (we run pushpool). Normally our share logs show 'IP username Y - -'

[2011-06-15 07:58:45.226391] ::ffff:87.194.1.1 test Y - - 000000016bb097662658dc02c5c94b269f91fe4357d882529ddfa69b000015a9000000009772fa1 8de12513b0e7f1b9c7776827e4f3ebc17a3a4bd693fab809cfa4b5da04df866331a1d932f1fba8c 0300000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000

However every now and then, something crops up. Instead of the upstream result being '-' (NULL in DB) it comes through as 'N'

So 'IP username Y N -'

Anyone know what this means?

[2011-06-15 11:51:3.691804] ::ffff:87.194.1.1 test Y N - 000000015d59759d9d64a30622943f5ad37efcad184935b5de6e84bf00000a81000000005508473 8be6f076686f2a3c98f61e19659a18908788fe79f7fa2fa0ed439d8144df89ca51a1d932ff3fde9 7400000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000

[1714834568]

1714834568

[1714834568]

1714834568

[Bert]

Did you read through the source code of pushpool ?

The first line says that hash is sufficient for share, but not for target.
And the second line from the log file I'll let you workout, but it should be easy to guess.

msg.c
... snip ...
        /* if hash is sufficient for share, but not target,
         * don't bother submitting to bitcoind
         */
        if (srv.easy_target && check_rc == 1) {
                *json_result = true;
                sharelog(remote_host, auth_user, "Y", NULL, NULL, hexstr);
                return true;
        }
... snip ...


P.S. Use the Source Luke, always use the source code Luke.

[shamen]

Hi Bert,
Thanks for the reply. I did check the source code and thats whats puzzled me you see. As far as I can see, there is only one section that will print the following (and thats the section you highlighted):

(remote_host, auth_user, "Y", NULL, NULL, hexstr)

But thats not what I saw in the log. There was no 'NULL' for upstream_result. it was 'N'

However, thats what I saw in the log:

[2011-06-15 11:51:3.691804] ::ffff:87.194.1.1 test Y N - 000000015d59759d9d64a30622943f5ad37efcad184935b5de6e84bf00000a81000000005508473 8be6f076686f2a3c98f61e19659a18908788fe79f7fa2fa0ed439d8144df89ca51a1d932ff3fde9 7400000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000

Ive checked in the mysql DB and upstream_result written in there with the 'N' too:

select * from shares where solution like '000000015d59759d9d64a30622943f5ad37efcad184935b5de6e84bf00000a81000000005508473%';
+------+------+---------------------+----------+------------+-----------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+
| id   | time | rem_host            | username | our_result | upstream_result | reason | solution                                                                                                                                                                                                                                                         |
+------+------+---------------------+----------+------------+-----------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+
| 3228 |    2011-06-15 11:51:03 | ::ffff:87.194.1.1 | test   | Y          | N               | NULL   | 000000015d59759d9d64a30622943f5ad37efcad184935b5de6e84bf00000a81000000005508473 8be6f076686f2a3c98f61e19659a18908788fe79f7fa2fa0ed439d8144df89ca51a1d932ff3fde9 7400000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000

My guess would be this section that has caused it

   sharelog(remote_host, auth_user,
       srv.easy_target ? "Y" : *json_result ? "Y" : "N",
       *json_result ? "Y" : "N", NULL, hexstr);

but then I dont fully understand the reasons why pushpool would think the share work is enough to submit to bitcoind, but then get an upstream result of 'N' ?

Sorry if im sounding a bit thick.

[Bert]

N means that it was not the solution, it was not the 50BTC + fees block.

[shamen]

Thanks Bert.

So if im getting this correctly, pushpool thought the solution was sufficient for the block, but bitcoind said 'no' ?

Really appreciate the help, cheers!

[Bert]

Exactly. Most shares sent out to miners are never expected to produce the solution, the miners reply proves that they are working on the problem. But every now and again one of their solutions looks like the answer. Most times it isn't, but sometimes it is (50BTC+fees).

[shamen]

Brilliant. Thanks so much !

Pool should be at 500MH/sec by tonight. Hopefully 1GH/sec by the weekend.

Ive looked at the calculator and from what I can see we should be expecting our first block within a week, does that sound reasonable with current difficulty and our hash rate?

[imafish2002]

I think with 1Ghash/s you would have to be fairly lucky to hit a block within a week.

Trying to find a calculator that I used the other day to work out my chances of hitting a block with my 880Mhash! Will report back if I find it although someone will probably beat me to it!

[Bert]

http://www.alloscomp.com/bitcoin/old_calculator.php for 1000000 khash/sec (it is a bit old), but it's answers are right.

Average   43 days, 14 hours, 35 minutes
50%   30 days, 5 hours, 26 minutes
95%   130 days, 15 hours, 17 minutes

You have a 95% chance of getting a block with in 130 days.
You have a 50% of getting a block within 30 days.
But on average (assuming that the difficulty doesn't increase, which it will) you should fine one block every  43 days.

Most miners join others pools, for a more constant predictable income.
If you had/joined a pool with 4Ghash/second you would get a block on average once every 10 days (big payouts).
If you had/joined a pool with 40Ghash/second you would get a block on average once every day (small payouts).
If you had/joined a pool with 400Ghash/second you would get a block on average 10 times a day (smaller payouts).
...

This calculator will give you your expected average daily return in BTC per Mhash/second.
http://www.alloscomp.com/bitcoin/calculator.php

I've been mining in a pool for a week and a half at 1.6GHash/second and none of my workers have found a block yet. But I still have income coming in.

In reality all pools pay out exactly the same over time for the same difficulty.. except those who charge miners more fees to pay for their multiple servers across the globe, but even this is tiny.

[imafish2002]

Ah ha! Thats the one, bookmarked this time around. Thanks Bert!

[shamen]

Thanks Bert Thats brilliant

cheers

[Bert]

One last thing - Here is a list of current pools https://en.bitcoin.it/wiki/Comparison_of_mining_pools
I wouldn't join the largest pool, because if one pool gains more than 50% control of the network bitcoins could drop in value (https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power) . I'd pick one 3+ down from the largest. Your income on average will be exactly the same.