nodemaster wrote:
My biggest concern ATM is merged-mine-proxy. I'd really like to see the functionality added to pushpoold.
I agree this is a big worry... Once merged starts there's going to a lot more hash power directed at some of the NMC pools. Given that existing NMC pools are likely to be the earliest adopters.
There's already scalability issues for btc pools and from what I can see from the the merged mining proxy code (I don't know python so apologies if I'm wrong) it's not really designed for scale, just as a reference implementation to make it possible to mine without modifying pools/miners.
I'd like to try and integrate this functionality into poolserverj but I'm having trouble getting my head around exactly what needs to be done. Reading the python code isn't making me much wiser... Could someone who understands the requirements possibly give a step-by-step process flow for getwork and submit work?
What I've worked out so far is roughly... getwork:
- build some derivative of merkle-root = aux
- send getworkaux rpc request with aux parameter
- rpc presumably returns work with multiple targets. (somehow keyed to the chain the target is applicable to?)
- build normal work response and set lowest target
- return to client
submit work:
- send getworkaux call to one daemon with solution which returns hash (of what)? + merkle root that corresponds to original work?
- somehow validate if solution solves for any chain by checking the merkle root returned from setworkaux is contained in some other merkle tree we have stored in the proxy.
- for each blockchain (this is the part where I'm really lost): I'm not even going to try an descibe how I'm interpreting this, probably safer to say I'm not...
- for each blockchain that is solved: send getworkaux with solution, merkle index, the entire branch?