tokenpool
tokenpool copied to clipboard
Planning Pool-to-Miner Protocol v2
Due to increased complexity for the pool and miner interface, the following pool method has been added to the JSONRPC protocol:
getPoolProtocolVersion()
In order to make everyone's life easier, we intend to develop a common specification. In 1.00 the following methods are used:
ping()
getPoolEthAddress()
getMinimumShareDifficulty(minerAddress) //Really used to understand a particular miners recommended diff.. so misnamed
getMinimumShareTarget(minerAddress) ////Really used to understand a particular miners recommended target.. so misnamed
getChallengeNumber()
submitShare(nonce,minerEthAddress,digest,difficulty,challengeNumber)
getMinerData //returns ALL miners data .. maybe should rename
What sorts of changes should we consider ?? I do not like how vardiff works right now we should probably lock it or something.. I like how Mikers uses different ports for this!! Let us know your thoughts
setCustomDiff
method:
arg string minerAddress
arg integer customDiff
return integer customDiff
if accepted
return error if rejected or not implemented; compatible with existing servers
so my thinking based on scaling this pool was that i will want to have a few different servers, each with a single function: a) a geth node b) ideally N>3 redis nodes but at least master + slave c) multiple nodejs front ends with their own key pairs and fixed difficulty that link back to the same redis server. They shall have fixed difficulty and miners working at that difficulty with the ethereum address of the minting wallet to remove the idea of diff gaming
and not necessarily require anything new from the miners