EthereumStratum_NiceHash_v1.0.0.txt

3 years ago · 6b8c25ce2e
1 changed files with 365 additions and 0 deletions
--- a/EthereumStratum_NiceHash_v1.0.0.txt
+++ b/EthereumStratum_NiceHash_v1.0.0.txt
@ -0,0 +1,365 @@
 -------------------------------------------------------------------------
 			   NiceHash presents
 =========================================================================
 	     	Ethereum stratum mining protocol v1.0.0
 =========================================================================
 revision of this document: R2
 I. Introduction
 II. Concept
 III. Specifications (RFC)
 IV. Real world scenario
 V. Planned improvements
 VI. Contact
 I. Introduction
 ---------------
 Ethereum does not have official stratum protocol. It supports only
 GetWork, which is very resource hoggy as miners need to constantly
 poll pool to obtain possible new work. GetWork thus affects performance
 of miners and pools. Due to demand for more professional Ethereum
 mining, several versions of "stratum" for Ethereum emerged. These
 "stratums" utilize GetWork on server side (pool side) to obtain work,
 which would be fine, if careful considerations and precautions were
 taken when creating such protocols. But this was not done. Issues of
 these protocols are following:
 1. No unique data per miner/worker. Extranonce is ignored (but still
 sent). Each miner gets seedhash (which is always the same for every
 30k blocks) and headerhash (which changes every block). Then miner uses
 these two values and own nonces to generate hashes. Miners may be
 doing duplicate work (if they choose same nonces).
 2. Difficulty redundancy. Difficulty is sent in mining.notify message
 as a third parameter named target. This is not needed, because miners
 can calculate target hash on their own out of provided difficulty.
 3. Overall data redundancy. There are several fields that are not needed
 to be sent over network. Firstly; if extranonce is not used, it does not
 have to be sent. Secondly; seedhash changes every 30k blocks - there is 
 no need to send it with every mining.notify. Thirdly; as already pointed
 out in 2 - target in mining.notify is redundant as set_difficulty is
 being used. Fourthly; mining.submit actually only needs to send nonce.
 Pool needs to verify nonce for validity and will calculate hash and
 mixhash. Bandwidth usage can be easily reduced by 50% or more if removing
 all mentioned redundancies.
 4. There are some inconsistencies compared to original slush's stratum
 specifications. One of them are ids. Ids should increase so that the pool
 can keep track of data being received. Another thing are HEX marks '0x'
 starting with each string field. This is, again, redundant and we will
 save some bandwidth if not using them.
 5. No specifications, only projects with implemented solutions. This
 usually lead to several similar versions of protocol; exactly what
 happened.
 Our goal is to make a solid, non-redundant, bullet-proof stratum mining
 protocol for Ethereum that does not have issues pointed out above.
 II. Concept
 -----------
 Ethereum's GetWork gives us 3 values:
 { ... "result":[
 "0x645cf20198c2f3861e947d4f67e3ab63b7b2e24dcc9095bd9123e7b33371f6cc",
 "0xabad8f99f3918bf903c6a909d9bbc0fdfa5a2f4b9cb1196175ec825c6610126c",
 "0x0000000394427b08175efa9a9eb59b9123e2969bf19bf272b20787ed022fbe6c"
 ]}
 First value is headerhash, second value is seedhash and third value is
 target. Seedhash is used to identify DAG file, headerhash and 64 bit
 nonce value chosen by our miner give us hash, which, if below provided
 target, yield block/share.
 Since nonce is 64 bit (8 bytes) wide and considering very bad possible
 scenario, that Ethereum does not find a block in 5 minutes time, 8 bytes
 of nonce can support miner with speed of up to:
 	(2^64 / 300) / 1G ~ 61,489,147 GH/s
 This is a very big number so we can easily consider taking some bytes off
 for our stratum protocol.
 	---------------------------------------
 	| Bytes | Max supported hashing speed |
 	|   8   |        ~61,489,147.000 GH/s |
 	|   7   |           ~240,192.000 GH/s |
 	|   6   |               ~938.000 GH/s |
 	|   5   |                 ~3.665 GH/s |
 	|   4   |                 ~0.014 GH/s |
 	---------------------------------------
 Having only 4 bytes for nonce is not an option, since we already have
 miners capable of reaching 14 MH/s and more. Nonce width of 5 bytes
 allows max speed of 3.665 GH/s which shall be enough for quite some time,
 even if ASICs arrive.
 The miner needs to get seedhash, headerhash, difficulty and part of
 nonce (called extranonce) from pool. Miner chooses on it's own second
 part of the nonce (called minernonce). Extranonce glued with minernonce
 gives us 64 bit Ethereum nonce.
 III. Specifications (RFC)
 -------------------------
 Handshake happens after TCP connection is established from miner to the
 pool. Miner sends data first:
 {
  "id": 1, 
  "method": "mining.subscribe", 
  "params": [ 
    "MinerName/1.0.0", "EthereumStratum/1.0.0" 
  ]
 }\n
 First parameter is miner name and version (as with standard stratum
 protocol). Second parameter must be "EthereumStratum/Version" where
 Version is version of EthereumStratum miner is using according to this
 document's version. If pool does not support this version, it may
 terminate the connection or respond back with error.
 Note that miner iterates ids and can start with any number. Each message
 from miner to the pool needs to have unique id for miner to properly read
 responses as pool may not process miner's messages in FIFO manner.
 Server replies back:
 {
  "id": 1, 
  "result": [
    [
      "mining.notify", 
      "ae6812eb4cd7735a302a8a9dd95cf71f",
      "EthereumStratum/1.0.0"
    ],
    "080c"
  ],
  "error": null
 }\n
 Response is almost the same as with standard stratum protocol with
 following differences; Third parameter of first parameter of result array
 is "EthereumStratum/Version"; If pool does not report this parameter or
 version is different than supported by miner, miner can expect
 compatibility issues and should terminate connection. Second parameter
 of result array is extranonce (in HEX) set by pool. There is no third
 parameter, because there is no extranonce2 (as with standard stratum).
 Extranonce may be max 3 bytes in size.
 Miner shall authorize during initial handshake; this is done the same way
 as in standard stratum protocol and will not be explained here in
 details.
 Before first job (work) is provided, pool MUST set difficulty by sending:
 { 
  "id": null, 
  "method": "mining.set_difficulty", 
  "params": [
    0.5
  ]
 }\n
 First item of params array is difficulty in double data type. Conversion
 between difficulty and target is done the same way as with Bitcoin; 
 difficulty of 1 is transformed to target being in HEX:
 00000000ffff0000000000000000000000000000000000000000000000000000
 If pool does not set difficulty before first job, then miner can assume
 difficulty 1 was being set.
 When difficulty is changed, miner starts using new difficulty for every
 NEXT job that arrives.
 If miner has subscribed to extranonce notifications (detailed explanations
 is here: https://www.nicehash.com/?p=software#devs), then pool may change 
 miner's extranonce by sending:
 { 
  "id": null, 
  "method": "mining.set_extranonce", 
  "params": [
    "af4c"
  ]
 }\n
 New extranonce is valid for all NEXT jobs sent by the pool.
 Pool informs miners about job (work) by sending:
 {
  "id": null,
  "method": "mining.notify",
  "params": [
    "bf0488aa",
    "abad8f99f3918bf903c6a909d9bbc0fdfa5a2f4b9cb1196175ec825c6610126c",
    "645cf20198c2f3861e947d4f67e3ab63b7b2e24dcc9095bd9123e7b33371f6cc",
    true
  ]
 }\n
 First parameter of params array is job ID (must be HEX number of any
 size). Second parameter is seedhash. Seedhash is sent with every job to
 support possible multipools, which may switch between coins quickly.
 Third parameter is headerhash. Last parameter is boolean cleanjobs. 
 If set to true, then miner needs to clear queue of jobs and immediatelly
 start working on new provided job, because all old jobs shares will
 result with stale share error.
 Miner uses seedhash to identify DAG, then tries to find share below
 target (which is created out of provided difficulty) with headerhash,
 extranonce and own minernonce.
 When share below target is found, miner submits it to the pool:
 { 
  "id": 244,
  "method": "mining.submit", 
  "params": [
    "username",
    "bf0488aa",
    "6a909d9bbc0f"
  ]
 }\n
 Second parameter of params array is job ID, third parameter is
 minernonce. Note in above example that minernonce is 6 bytes, because
 provided extranonce was 2 bytes. If pool provides 3 bytes extranonce,
 then minernonce must be 5 bytes.
 For every work submit, pool needs to respond back with standard stratum
 response:
 {
  "id": 244,
  "result": true,
  "error": null
 }\n
 Or if share was not accepted (standard stratum response):
 {
  "id": 244,
  "result": false,
  "error": [
    -1,
    "Job not found",
    NULL
  ]
 }\n
 IV. Real world scenario
 -----------------------
 Miner connects to the pool and sends:
 {
  "id": 1, 
  "method": "mining.subscribe", 
  "params": [ 
    "EthereumMiner/1.0.0", "EthereumStratum/1.0.0" 
  ]
 }\n
 Pool responds:
 {
  "id": 1, 
  "result": [
    [
      "mining.notify", 
      "ae6812eb4cd7735a302a8a9dd95cf71f",
      "EthereumStratum/1.0.0"
    ],
    "a2eea0"
  ],
  "error": null
 }\n
 Miner then authorize:
 {
  "id": 2, 
  "method": "mining.authorize",
  "params": [
    "test", 
    "password"
  ]
 }\n
 And pool confirms:
 {
  "id": 2,
  "result": true,
  "error": null
 }\n
 Pool sends difficulty:
 { 
  "id": null, 
  "method": "mining.set_difficulty", 
  "params": [
    1.0
  ]
 }\n
 And job:
 { 
  "id": null,
  "method": "mining.notify",
  "params": [
    "bf0488aa",
    "abad8f99f3918bf903c6a909d9bbc0fdfa5a2f4b9cb1196175ec825c6610126c",
    "fc12eb20c58158071c956316cdcd12a22dd8bf126ac4aee559f0ffe4df11f279",
    true
  ]
 }\n
 After a while, miner finds share and submits it:
 { 
  "id": 3,
  "method": "mining.submit", 
  "params": [
    "test",
    "bf0488aa",
    "cfae7df760"
  ]
 }\n
 Response from the pool:
 {
  "id": 3,
  "result": true,
  "error": null
 }\n
 The share was valid considering data:
 seedhash=abad8f99f3918bf903c6a909d9bbc0fdfa5a2f4b9cb1196175ec825c6610126c
 headerhash=fc12eb20c58158071c956316cdcd12a22dd8bf126ac4aee559f0ffe4df11f279
 nonce=a2eea0cfae7df760
 Result is share with difficulty of 1.863 which is above 1.0.
 V. Planned improvements
 -----------------------
 Ethereum has RPC method eth_getBlockByNumber which can return some data about
 next block that is yet to be mined. Among data is next block number (block
 height). This number could be used instead of seedhash; every miner would then
 calculate seedhash on it's own thus bandwidth usage would be reduced even more.
 There are plans to make eth_getBlockTemplate method. When this is made, this
 stratum protocol may get very similar to standard stratum.
 VI. Contact
 -----------
 www.nicehash.com
 info@nicehash.com