Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning Pool-to-Miner Protocol v2 #18

Open
0xbitcoin opened this issue May 1, 2018 · 2 comments
Open

Planning Pool-to-Miner Protocol v2 #18

0xbitcoin opened this issue May 1, 2018 · 2 comments
Labels
enhancement New feature or request

Comments

@0xbitcoin
Copy link
Collaborator

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

@0xbitcoin 0xbitcoin added the enhancement New feature or request label May 1, 2018
@azlehria
Copy link

azlehria commented May 1, 2018

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
Copy link

snissn commented May 1, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants