Slush,
I just want to say THANK YOU! You have done so much for the community. (And I know that thank you's tend to be few and far between.)
I'm using the stratum mining server and it's working very well.
I solomine (slush as backup of course) with about 20 clients (some run bfl kit) and using pool software is a good way to monitor/manage them.
I hacked in the db code to get it reporting. Do you want any contributions to the code? I could put in some db code and a simple setup how-to (since it's a bit confusing.) If not I understand.
Topic: [ANN] Stratum mining protocol - ASIC ready - page 22. (Read 146083 times)
I am so sorry, I didn't quite ask that right.... how do we know if the share solves/generates a block? i.e. how do we know when we generated a block.
Oh, this. Yes, it is on_submit_block, as you guessed by self:
Quote
on_submit_block(self, is_accepted, worker_name, block_header, block_hash, timestamp):
Share is sent to the bitcoind everytime its share difficulty>network difficulty and result is passed into this method. is_accepted indicates that the solution has been accepted and you "won" a block.
Quote
def on_submit_share(self, worker_name, block_header, block_hash, shares, timestamp, is_valid):
is_valid is boolean indicating that share has been accepted.
I am so sorry, I didn't quite ask that right.... how do we know if the share solves/generates a block? i.e. how do we know when we generated a block.
Quote
def on_submit_share(self, worker_name, block_header, block_hash, shares, timestamp, is_valid):
is_valid is boolean indicating that share has been accepted.
A hopefully quick question, and pardon my ignorance.
in stratum-mining/mining/interfaces.py I see where we see submitted shares, but how do we know if the result is accepted as a share? Is is related to on_submit_block?
in stratum-mining/mining/interfaces.py I see where we see submitted shares, but how do we know if the result is accepted as a share? Is is related to on_submit_block?
Why does this job have transactions, but no merkle links? :/
Heh, thank you for pointing at it. It is bug with caching of transaction list in my implementation. It affects only get_transaction method and only for first template after new block announcement. I'll fix it tomorrow!
Code:
I: {"params": ["b57e", "3cc177a87a3bedf6f6d25d8a09801c4450ebccf3cb5d02a0000002a600000000", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff21033b2703062f503253482f04f03b985008", "072f736c7573682f000000000100f2052a010000001976a914e8e6ace10f10ce5ed479c7188c9b4061e53aa90688ac00000000", [], "00000002", "1a0513c5", "50983bf0", true], "id": null, "method": "mining.notify"}
O: {"params": ["b57e"], "id": "txlistb57e", "method": "mining.get_transactions"}
I: {"error": null, "id": "txlistb57e", "result": ["0100000001e45eb5311f14f66eff9351134265e33dbd41daa8110acc5b031e80de38893a65000000006b483045022028837a004078689c927fdc794a1e1a15b90671e90cd77e3f98c1c8776b7a9054022100c5c803954112f0ce183041c38b2e31e38bf91c61c3a5cc2b981b23665e7c1d240121029b497b642311bb84f184c0534d3874182035e77c8b1a48c35d3e9e8a390c93c3ffffffff0200a78c13180000001976a914b4eac5b7bba166b7f8c8cd195d6cb3f4680eede788ac80267241000000001976a9147ff701619769fbd1a12f8d0f440c3cfa50adfefe88ac00000000", ...]}
Almost implemented the first working version of GBT within cgminer.
This sort of behaviour tells the story well though:
Now pool 3 here is slush on stratum (ping time 335ms), while pool 2 is EMC on GBT (ping time 225ms).
Note how stratum picks up the block change and notifies me 10 seconds before GBT does. However, this is not the GBT pool simply learning of the block change later, because it starts rejecting my shares as being from the previous block before I even got the longpoll from the GBT pool. Then of course there's a second longpoll with the transactions, which is not an unusual practice.
This sort of behaviour tells the story well though:
Code:
[2012-11-05 22:28:08] Accepted 23c0ba9a Diff 7/1 GPU 2 pool 2
[2012-11-05 22:28:08] Accepted 163ec800 Diff 11/1 GPU 0 pool 2
[2012-11-05 22:28:13] Stratum from pool 3 detected new block
[2012-11-05 22:28:13] Accepted 61bdf4a7 Diff 2/1 GPU 3 pool 2
[2012-11-05 22:28:13] Stale share detected, submitting as user requested
[2012-11-05 22:28:14] Accepted 00feebca Diff 257/1 GPU 1 pool 2
[2012-11-05 22:28:19] Rejected 70b76eb2 Diff 2/1 GPU 1 pool 2 (stale-prevblk)
[2012-11-05 22:28:19] Rejected 47b723ef Diff 3/1 GPU 3 pool 2 (stale-prevblk)
[2012-11-05 22:28:20] Rejected 9644eef7 Diff 1/1 GPU 2 pool 2 (stale-prevblk)
[2012-11-05 22:28:21] Rejected 4cafa99d Diff 3/1 GPU 1 pool 2 (stale-prevblk)
[2012-11-05 22:28:22] Rejected 093dc4cd Diff 27/1 GPU 0 pool 2 (stale-prevblk)
[2012-11-05 22:28:23] GBT LONGPOLL from pool 2 requested work restart
[2012-11-05 22:28:24] Accepted 375a5178 Diff 4/1 GPU 1 pool 2
[2012-11-05 22:28:25] Accepted 047206f4 Diff 57/1 GPU 3 pool 2
[2012-11-05 22:28:25] GBT LONGPOLL from pool 2 requested work restart
[2012-11-05 22:28:30] Accepted 72bee5f8 Diff 2/1 GPU 0 pool 2
[2012-11-05 22:28:31] Accepted 8e63856d Diff 1/1 GPU 2 pool 2
Now pool 3 here is slush on stratum (ping time 335ms), while pool 2 is EMC on GBT (ping time 225ms).
Note how stratum picks up the block change and notifies me 10 seconds before GBT does. However, this is not the GBT pool simply learning of the block change later, because it starts rejecting my shares as being from the previous block before I even got the longpoll from the GBT pool. Then of course there's a second longpoll with the transactions, which is not an unusual practice.
This doesn't seem to actually work. I'm receiving some transaction data, but then the connection goes silent before the response is complete. By "silent" I mean it remains open and there are TCP keepalives going on, but no more data arrives. Some writebuffer-related bug perhaps?
Hrm, works for me. How big response you got when it crashed? And did you received complete response for get_transaction call?
Today I implemented and released to my pool new method called mining.get_transactions(job_id). This call simply dumps transactions used for given job. Thanks to this, miners now have everything needed to reconstruct source block template used by the pool and they can check online if pool isn't doing something nasty.
This doesn't seem to actually work. I'm receiving some transaction data, but then the connection goes silent before the response is complete. By "silent" I mean it remains open and there are TCP keepalives going on, but no more data arrives. Some writebuffer-related bug perhaps? Just added that to my pools list and it totally messed up cgminer - Ozcoin is the only pool I use to have stratum.
I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. thought cgminer crashed, but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
Yeah it seems at the time ozcoin kept the connection open but its own buffer was full and was not accepting anything the miner was trying to send, delaying submission. There currently is a very long timeout for submission of data in cgminer and it probably queued up heaps of shares it was trying to submit in that time and overflowed. I will address that in the future. Even if the connection is open, cgminer will have to assume a pool is as good as dead if it's failing to accept data for some arbitrary period. I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. thought cgminer crashed, but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
not sure of the timing of it all but we have had to restart our stratum a couple of times, might explain some of it
Don't you just love dripping wet, freshly released software? 
Does Eloipool support merged mining? I have not looked at it yet.
It's not the simplest thing to setup, though.
My hope going forward is that miners will setup their own merged mining, instead of relying on the pool for it, now that GBT enables this.
not sure of the timing of it all but we have had to restart our stratum a couple of times, might explain some of it
Don't you just love dripping wet, freshly released software? Does Eloipool support merged mining? I have not looked at it yet.
not sure of the timing of it all but we have had to restart our stratum a couple of times, might explain some of it
Don't you just love dripping wet, freshly released software? Just added that to my pools list and it totally messed up cgminer - Ozcoin is the only pool I use to have stratum.
I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. though cgminer crashed but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
not sure of the timing of it all but we have had to restart our stratum a couple of times, might explain some of itI suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. though cgminer crashed but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
Don't you just love dripping wet, freshly released software?
Just added that to my pools list and it totally messed up cgminer - Ozcoin is the only pool I use to have stratum.
I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. though cgminer crashed but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
not sure of the timing of it all but we have had to restart our stratum a couple of times, might explain some of it I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. though cgminer crashed but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
Just added that to my pools list and it totally messed up cgminer - Ozcoin is the only pool I use to have stratum.
I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. thought cgminer crashed, but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
I suspect it's my own doing, as I have a homebrew version of cgminer that I use.
Very strange failure though.
Added the pool through the API, then the API went off line for 30 seconds. thought cgminer crashed, but it came back.
Then the pool mined 457 shares and stopped
The 5s rolling average dropped to one BFL of the 6, but 6/6 devices were still reported. Hash rate on some BFLs dropped to 0, others were some fraction of one BFL.
I saved the config file through the API, then reset cgminer.
The first 2 BFLs where then reported sick, with garbled messages being returned in the comms (reporting 'USY').
The other BFLS were showing low, or no hash rates.
The pool I added was missing the 'stratum+tcp://' part when displayed through the API (when I added it via API the whole string was there).
Stopped cgminer, manually removed the pool from the conf. file, and restarted. Everything back to normal now.
I'm guessing there's some sort of buffer over-run going on somewhere.
I've been looking over the python code 
which works pretty well actually, just need to add DB work.
which works pretty well actually, just need to add DB work.I wish I could read python code, it's not structured code, it's not object oriented, it's not even assembly language. I can't follow control flow, I can't understand variable usage, nothing. I could learn it but, I don't believe computer languages should be harder to use for all developers at all levels. This is my opinion and I understand I may be wrong, I believe I'm right.
So why do you guys use Python?
I can't speak for those who use Twisted, but I use Python generally to make it more accessible to less experienced developers.
Thanks for clearing that up! I may check out regular python then.
I've been looking over the python code which works pretty well actually, just need to add DB work.
which works pretty well actually, just need to add DB work.I wish I could read python code, it's not structured code, it's not object oriented, it's not even assembly language. I can't follow control flow, I can't understand variable usage, nothing. I could learn it but, I don't believe computer languages should be harder to use for all developers at all levels. This is my opinion and I understand I may be wrong, I believe I'm right.
So why do you guys use Python?
I can't speak for those who use Twisted, but I use Python generally to make it more accessible to less experienced developers.
Jump to: