Merge pull request #10 from jolan/jolan_rfp0005

add rfp-0005 (Mining Protocol Development and Pool Integration)

README.md

@@ -6,3 +6,4 @@
 |[0002](./rfp-0002/rfp-0002.md)|WebWallet StakeTickets|Draft|
 |[0003](./rfp-0003/rfp-0003.md)|Network Status Dashboard|Draft|
 |[0004](./rfp-0004/rfp-0004.md)|Refactor and update wiki documentation|Draft|
+|[0005](./rfp-0005/rfp-0005.md)|Mining Protocol Development and Pool Integration|Draft|

rfp-0005/rfp-0005.md

@@ -0,0 +1,37 @@
+# Mining Protocol Development and Pool Integration
+
+## Description
+There is not currently a standard protocol for Decred mining. Decred has many unique features not currently available in other coins, such as an extended extra nonce space and per-miner voting. The goal is to integrate Decred-specific features into an extensible protocol that allows for the easy addition of future features. The protocol should then be integrated into an open source pool and a single, open-source miner codebase that supports both OpenCL+ADL for AMD GPUs and CUDA for NVIDIA GPUs. The miner must be able to easily integrate future devices, such as FPGAs and ASICs.
+
+## Requirements
+Familiarity with the stratum and getblocktemplate protocols, JSON data parsing, cryptocurrency miner development, OpenCL/ADL/CUDA, and proof-of-work mining pool development.
+
+## Scope
+The first task will be to analyze existing protocols and design a protocol that is flexible enough to meet the demands of any miner. It should include the best features of both the stratum and getblocktemplate protocols. The design must be able to scale from being lightweight and low bandwidth (stratum) to full knowledge of block information (getblocktemplate). The miner should have the ability to select from the pool UI which data they will be served. As the current standard for pool/miner software is JSON, it should use this encoding standard. The protocol should make efficient use of extra nonce space and dictate which extra nonce data must be exhausted first before proceeding to the next nonce space.
+
+Extended voteBits is a 73-byte field that will eventually be held in the coinbase signature script. It will be used to provide a larger space for voting on future issues. The pool UI should give the end user the ability to store the extended voteBits for a proof of work, and all work given to them should contain their selected voteBits. When work is updated and a change to the merkle root of a block is required, the miner should be broadcast a proof of inclusion for their extended voteBits at minimum. This includes the path to the coinbase transaction, the data in the coinbase witness, and the hash of the coinbase prefix.
+
+The pool UI should allow the end user to select the verbosity of their provided work. For example, including all transaction hashes, including all transactions, including all vote transactions, and so on.
+
+The provided miner should be well commented, readable, and have the ability to easily integrate future devices. In addition, the build process must be documented in detail for the Decred Tier 1 OSes (Windows, Linux) and platforms (x86 and x86-64) and be capable of providing static binaries.
+
+## Estimated Working Time
+
+21-28 days FTE or greater (1 FTE = 40 hrs/week).
+
+## Proposal
+
+Proposals should include:
+
+1. References to prior work on miners, pools, and protocols
+2. Initial overview of how you would construct the protocol
+3. Estimated completion time
+4. Payment required
+
+## Milestones
+
+1. Completion of the initial mining protocol draft
+2. Overhaul of the draft into a final draft based on feedback from the Decred developers
+3. Integration of the protocol into a pool
+4. Integration of the protocol into an open-source miner that handles both OpenCL and CUDA implementations of BLAKE256 and supports GPU monitoring
+5. Documentation of toolchain/build environment for providing static or nearly static binaries for Linux/Windows 32-bit/64-bit