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

[azlehria]

setCustomDiff method:
arg string minerAddress
arg integer customDiff

return integer customDiff if accepted
return error if rejected or not implemented; compatible with existing servers

[snissn]

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