search

tradecraftio / tradecraft

Tradecraft integration/staging tree https://tradecraft.io/download
Other
13 stars 9 forks source link

Add built-in Stratum v1 mining server for solo-mining #65

Closed maaku closed 4 years ago

maaku commented 4 years ago

Rather than individually support a variety of server or proxy back-ends, we should expose an ASICBoost-compatible Stratum v1 TCP server API endpoint, so that any Freicoin/Tradecraft full-node can be used to drive hashing hardware without requiring any additional software (other than the driver for the mining hardware itself).

This pull request tracks the initial implementation of a stratum v1 mining service, which will be considered feature complete when it is able to serve work to both cpuminer (for testing purposes) and bmminer (which drives a large percentage of the existing network hash power). Other issues and pull requests should be used to track additional features and extensions, or tweaks required for getting other mining backends to work.

maaku commented 4 years ago

In prototyping the stratum server endpoint, it was discovered that the new segwit commitment scheme which commits to the coinbase transaction is incompatible with unmodified stratum mining. This is because stratum miners expect to be able to modify the coinbase (via the extranonce2 pseudo-field), but such modification would require rebuilding the witness commitment, which no existing mining software does in the way we expect.

In all observed stratum protocol sessions, the extranonce2 has been set to 4 bytes by the server. As it happens, there is a field of this size present in all coinbase transactions which is currently unused and ignored by the consensus code: the nSequence field of the coinbase input. We can therefore clear this value prior to hashing the witness commitment, thus making it usable as a extranonce2 field for stratum miners.

I've pushed a commit which makes this change, and modifies the tests accordingly.

maaku commented 4 years ago

A performance issue has arisen, which will have to be tracked in a separate issue as resolving it will have to be pushed to after the release of v13. The code as written now works, is performant enough for our current transaction rate, and is already used in production. This is the last issue blocking release, and the release should move forward. Code is ready for merge.