Bitcoin Forum
December 07, 2016, 06:41:35 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
Author Topic: [500 GH/s]HHTT -Selected Diff/Stratum/PPLNS/Paid Stales/High Availability/Tor  (Read 52448 times)
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 11, 2013, 06:41:52 AM
 #221

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

Posts: 1481136095

View Profile Personal Message (Offline)

Ignore
1481136095
Reply with quote  #2

1481136095
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 11, 2013, 06:52:06 AM
 #222

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

Activity: 634



View Profile
February 11, 2013, 04:52:39 PM
 #223

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

Activity: 366



View Profile
February 12, 2013, 01:03:17 AM
 #224


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

Activity: 1750


BTC Guild Owner


View Profile WWW
February 12, 2013, 02:16:16 AM
 #225

(snip) I expect tons of silly endian problems.

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

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 12, 2013, 03:25:28 AM
 #226

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

Activity: 366



View Profile
February 13, 2013, 04:03:15 PM
 #227

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

Activity: 366



View Profile
February 13, 2013, 09:06:39 PM
 #228


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

Activity: 366



View Profile
February 13, 2013, 09:20:28 PM
 #229

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

Activity: 543



View Profile
February 13, 2013, 11:30:38 PM
 #230

Let's see.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
February 13, 2013, 11:37:38 PM
 #231

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

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 13, 2013, 11:41:20 PM
 #232

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

Activity: 71



View Profile
February 14, 2013, 01:21:08 AM
 #233

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

1NDoRoTapFZNiUhzTPyFdKib66QLJfmcuR
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 14, 2013, 05:13:09 AM
 #234

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

Activity: 366



View Profile
February 14, 2013, 06:18:40 AM
 #235

I've put the code on github:

https://github.com/fireduck64/SockThing
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
February 14, 2013, 09:36:30 AM
 #236

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

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 14, 2013, 02:01:47 PM
 #237

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

Activity: 543



View Profile
February 14, 2013, 04:15:16 PM
 #238

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?

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
February 15, 2013, 02:32:12 AM
 #239

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

Activity: 366



View Profile
February 15, 2013, 07:02:57 AM
 #240

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
  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!