[500 GH/s]HHTT -Selected Diff/Stratum/PPLNS/Paid Stales/High Availability/Tor

[fireduck]

It looks like something is wrong with whatever mechanism is calculating the 'owed' amt,

http://hhtt.1209k.com/

as an example, it says it owes the 3rd user 3 BTC, from 10 hrs of ~3.5ghash

possibly giving too much for lower difficulty blocks.  My amt seems accurate

also

http://hhtt.1209k.com/user-details.php?user=14uNqUQNqbKLTFZGGqyR2pgkHeMvUNv9Fm

apparently it's actually making the payments, since that one was about 2.5x too high

Thanks for pointing this out.  I think I know what happened.  I was updating a bitcoind on my backend.  It switched to level db and was downloading the blockchain.  That is all good, except it is used to determine the difficulty for the purpose of share payments.  It probably ran a number of times while the blockchain was being downloaded and got some incorrect difficulties in the process.

I've stopped payments for a little while I cleanup the DB.  Some people will probably have been paid too much and go negative for a while (maybe forever if they stop mining).  But I won't ask people to be responsible for my mistake.

[1714253838]

1714253838

[fireduck]

It looks like something is wrong with whatever mechanism is calculating the 'owed' amt,

http://hhtt.1209k.com/

as an example, it says it owes the 3rd user 3 BTC, from 10 hrs of ~3.5ghash

possibly giving too much for lower difficulty blocks.  My amt seems accurate

also

http://hhtt.1209k.com/user-details.php?user=14uNqUQNqbKLTFZGGqyR2pgkHeMvUNv9Fm

apparently it's actually making the payments, since that one was about 2.5x too high

Thanks for pointing this out.  I think I know what happened.  I was updating a bitcoind on my backend.  It switched to level db and was downloading the blockchain.  That is all good, except it is used to determine the difficulty for the purpose of share payments.  It probably ran a number of times while the blockchain was being downloaded and got some incorrect difficulties in the process.

I've stopped payments for a little while I cleanup the DB.  Some people will probably have been paid too much and go negative for a while (maybe forever if they stop mining).  But I won't ask people to be responsible for my mistake.

Should be fixed now.  Will be reflected on the web page in a little bit.

[Carnth]

I was updating a bitcoind on my backend.  It switched to level db and was downloading the blockchain.  That is all good, except it is used to determine the difficulty for the purpose of share payments.  It probably ran a number of times while the blockchain was being downloaded and got some incorrect difficulties in the process.

I've stopped payments for a little while I cleanup the DB.  Some people will probably have been paid too much and go negative for a while (maybe forever if they stop mining).  But I won't ask people to be responsible for my mistake.

Well, I'm glad you got this sorted out. Thanks for the loan. I'll keep my miners working until my over payment is paid back.

This is a fantastic pool, and I want to see it going for a long time.

[fireduck]

I'm looking into spinning up a stratum node now.
 

AWESOME!  You are my planned public pool when BFL delivers almost 2Th to my doorstep.  Would like to see you dig out of the deficit that was created before the reward drop...

Sweet.  I am working on my own stratum mining pool implementation in java.  I have the stratum side working, which includes getting work to miners and processing the shares.  I am working on the bitcoin side of actually making the blocks.

If anyone has an pointers on making a two part coinbase transaction in Java (in which I can cram my 8 bytes of extra-nonce), I'd love to hear about it.

With some help with Mr. Hearn over on the bitcoinj mailing list I think I have it figured out.  I also have a grip on the merkle branches sent over the wire with the stratum jobs.  I hope to have the entire thing working on testnet tomorrow or the day after.  I expect tons of silly endian problems.

After that, I'll do some cleanup and make it configurable and put it on github.

[eleuthria]

(snip) I expect tons of silly endian problems.

Oh, you have no idea.  Your blood will boil with the endianess and byteswappery nonsense.

[fireduck]

(snip) I expect tons of silly endian problems.

Oh, you have no idea.  Your blood will boil with the endianess and byteswappery nonsense.

Probably.  I'm just glad I have the miner side working, that way I can validate shares submitted by cgminer and assuming cgminer is correct I'll know if the rest of my nonsense is correct or not.  So I should have a solid idea before I even try making some blocks on testnet.

[fireduck]

(snip) I expect tons of silly endian problems.

Oh, you have no idea.  Your blood will boil with the endianess and byteswappery nonsense.

Probably.  I'm just glad I have the miner side working, that way I can validate shares submitted by cgminer and assuming cgminer is correct I'll know if the rest of my nonsense is correct or not.  So I should have a solid idea before I even try making some blocks on testnet.

Ok, mined some blocks on testnet3.  http://blockexplorer.com/testnet/address/mjo9y54EJthcxpZc4pLGHWvf4n8E3vaTrN

Since I am making this terrible coinbase transaction myself, I'm thinking of doing something fun like half of the transaction fees to miner who found the block right from the coinbase.  Since I am building the transaction per job that isn't really much trouble. 

[fireduck]

Ok, mined some blocks on testnet3.  http://blockexplorer.com/testnet/address/mjo9y54EJthcxpZc4pLGHWvf4n8E3vaTrN

Since I am making this terrible coinbase transaction myself, I'm thinking of doing something fun like half of the transaction fees to miner who found the block right from the coinbase.  Since I am building the transaction per job that isn't really much trouble. 

If anyone wants to try it out, it is operational:

stratum+tcp://stratum.hhtt.1209k.com:3333/

I'd like to run it for a few days with some test users and then I'll put that header in the pushpool.

[fireduck]

If anyone wants to try it out, it is operational:

stratum+tcp://stratum.hhtt.1209k.com:3333/

I'd like to run it for a few days with some test users and then I'll put that header in the pushpool.

I am impatient, I've put in the redirect header and we shall see what happens.

[ShadesOfMarble]

Let's see.

[ShadesOfMarble]

Stratum node is "dead", according to my cgminer.

[fireduck]

Stratum node is "dead", according to my cgminer.

Yeah, I was restarting it to try to improve something and it didn't work so well.  It is back up now.

[TheOtherGuy]

"Unable to get work from pool" error in BAMT with cgminer 2.9.5?

[fireduck]

"Unable to get work from pool" error in BAMT with cgminer 2.9.5?

I don't know what the issue is, but I can't get 2.9.5 to work either.  Later versions seem to be fine.

[fireduck]

I've put the code on github:

https://github.com/fireduck64/SockThing

[ShadesOfMarble]

Rejects are very high  (6% with stratum, ~1% with getwork), I also get reject messages like "H-not-zero". Looks like something is screwed up...

[fireduck]

Rejects are very high  (6% with stratum, ~1% with getwork), I also get reject messages like "H-not-zero". Looks like something is screwed up...

Rejects over all are very low:
+-------------+----------+
| reason      | count(*) |
+-------------+----------+
| NULL        |     3756 |
| H-not-zero  |       20 |
| quite stale |       16 |
+-------------+----------+


The last two here are from me testing the difficulty target check.  It looks like the rest of these are failing the check, as they should.  Those hashes certainly aren't right.  That means there is some mismatch of data between the client and server.

Is it possible that your client is reconnecting and trying to submit shares for jobs it learned about on a previous connection?  I don't have that working quite yet.

+------------------------------------+------------+------------+------------+---------------------+------------------------------------------------------------------+
| username                           | our_result | reason     | difficulty | time                | hash                                                             |
+------------------------------------+------------+------------+------------+---------------------+------------------------------------------------------------------+
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 07:58:52 | 743523edf408749ae13d9ee873c092f3b8edf728eee6d184bc9ce0952f6e500b |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:44 | 757a6e1c4113c1f7501c36bd31ce7e4e4ce4d7eb234ecab9e1602bc85dce73de |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:41 | 4890db9d3eef1fd2d3ebbe842460d066958021fc8c6390db149621bf5814e969 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:37 | 76dc456b0b1636ccdfa32f8baf1ad96474c283ad5a991ff40a45a6ea7947b5ac |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:35 | 6faecf3b91bde22c912c1406918beb3838f1ae148ebbacfc83a5e1e7347295fd |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:22 | 9384c003d606b77f46ad474d87d74e693e709d6a9d8e1c1e23d08d906ee11cbd |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:14 | c5def3f1a5b47dfc9d9219f5192a4c62a5d6c7fe7502d5eca1c3cf721ce2925d |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:12 | c47bec16ae761e326d5f57ecce3d720bea977ec26ea9d21664280ffb314c9bb2 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:12 | c50de5de26c86d2227bf1d15df1a4b8f096eb0b1bd7fb8b78ac4a2739f49dd82 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:37:01 | 0027b7553f825aa14bb188f5a034d172eab22ce7802adc63f96efc103d9a182f |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:36:52 | af0ca2e7217a48cae672e05318dbae53b1ad1cdc7be87c57826215269bef2943 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:36:45 | 231392a762f6c4b1551e39e6b5b64407b4d956024418df2db403fe65289502c3 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:36:39 | 3170f121c3591406476deacc8eb8c5f0c9f4a227e72ed7f1509e632c5ec68de8 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 05:36:39 | a9692eb13e11e2a2b9bf6efb4b9cc1a6fe4d8d03ac847e61e91759065020e678 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 02:24:45 | 79627670370a6c3670fabed26eb5537e7634544a1e397f4febd32f2d33b97d50 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 02:21:42 | 80aedaae2514553fcdee97296def3670d2ef66d44d24ffe3b5c7da729fb61709 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 01:24:01 | 8e8dc6c6354d3def9061cefdebdbb70622528969e57eb1dda03b86273ba7efa2 |
| 139Ez4YdvCU1dgbXVqAcsB62zzTdRMA43g | N          | H-not-zero |         64 | 2013-02-14 01:15:08 | 727be5db1bb10faa88f7950c837a62d7e811967d3c58ad92e91e609c012eff27 |
| 1FdKhHttWiwq6Wip1BBJG1f6ffD8pWYFiE | N          | H-not-zero |          4 | 2013-02-13 20:11:48 | 0000000027cb6379960f461326a676f1493d074803b0172ae3ca7e05b6d63410 |
| 1FdKhHttWiwq6Wip1BBJG1f6ffD8pWYFiE | N          | H-not-zero |          4 | 2013-02-13 20:11:38 | 000000001e9b9a1470e322aaac34201678b1f42244e29d39b794b8b6241cd964 |
+------------------------------------+------------+------------+------------+---------------------+------------------------------------------------------------------+

[ShadesOfMarble]

Is it possible that your client is reconnecting and trying to submit shares for jobs it learned about on a previous connection?

I'm using latest cgminer. If cgminer does that, then: yes.

But the hashes actually look very strange, don't they? Shouldn't the first 4 bytes always be zero?

[fireduck]

Is it possible that your client is reconnecting and trying to submit shares for jobs it learned about on a previous connection?

I'm using latest cgminer. If cgminer does that, then: yes.

But the hashes actually look very strange, don't they? Shouldn't the first 4 bytes always be zero?

Yes, that is why they were rejected.  They should start with zeros and if they don't have enough zeros they are rejected as something your client should never have submitted.  Now, this shouldn't happen.  For this to happen there needs to be some misunderstanding between the client and the server about what data you should be hashing.  I'm not sure what caused that.

[fireduck]

In case anyone was paying attention, HHTT just had a 30 minute outage as a database table change took longer than I thought it would.

I'm going to change the stratum server to save shares via SQS rather than a database so that the pool can stay up for an outage like this.  In that case, it would just delay processing and payments for shares but not block solving and all the shares would eventually be counted correctly.

Sorry for the trouble.