Extranonce handling is no-standard for STRATUM

[AndreaLanfranchi]

After implementation of "extranonce" in STRATUM flavor I see there's a non-standard behavior in submitting solution.

Extranonce implementation SHOULD behave like this:

1. workprovider (pool) sends extranonce, say, 127be1
2. workconsumer (miner) sets its nonce search range as

0x127be00000000000 // low bound
0x127befffffffffff // high bound

3. Say miner finds solution 127be10002d9b189. Solution submission SHOULD report nonce as 0002d9b189 (i.e. the substring of full hex nonce - omitting the Extranonce initial part). Actually kawpowminer reports the full nonce hex representation.

Tested with minermore to send only the variable part of the nonce and got rejects

Rejected in 142 ms. by rvnt.minermore.com Reason: 20 incorrect size of nonce, must be 8 bytes

While this is not technically a bug it may lead to confusion in implementations.

Why should this matter ?
There are two reasons.

1. Reporting only the variable part of the nonce (when extranonce is set) saves bytes (which pools should be happy of when handling tons of connections)
2. Slightly mitigates the man-in-the-middle attack which is possible on non-SSL connections to pools (the sniffer should listen to the whole session and keep track of the extranonces set).

[AndreaLanfranchi]

@traysi
I also suggest to have the Extranonce set to a maximum of 2 bytes and leave wider space for miner to choose its search range within the boundaries.

[traysi]

This would have been a fine change to make some weeks ago but we're 4 days away from the fork and this has already been codified in 5 different miner implementations and all known pools. I don't think altering it is a feasible option at the moment. We should consider a long term solution eventually, though.

[AndreaLanfranchi]

Sure. I keep the issues as "note" references maybe for future implementations