Getblocktemplate
Why change something that works?
Centralization
The original getwork mining protocol simply issues block headers for a miner to solve. The miner is kept in the dark as to what is actually in this block, and has no influence over it. In effect, the authority of the miner to decide which transactions are accepted, etc, is all transferred blindly to the pool operator. A corrupt (or compromised) pool operator could use the combined hash power of all the miners to execute double spend attacks or other similar attacks.
getblocktemplate moves block creation to the miner, while giving pools a way to set down the rules for participation. While pools can do just as much as they could before by expressing it in these rules, miners can not be kept in the dark and are enabled to freely choose what they participate in mining. This improves the security of the Bitcoin network by making blocks decentralized again.
ASICs
The original getwork protocol only provides a single block header, which is sufficient for a total of about 4 GH of mining. With the "rollntime" extension, this can be extended to 4 GH *per second*, but even that is far from sufficient for the next generation of mining equipment (ASICs) which are capable of 1000 GH/s on the high end.
By moving block creation to the miners, they are enabled to create as much work as they need locally, thus overcoming this limitation.
Scalability
Due to scalability problems, bitcoind's JSON-RPC stack has not been able to keep up with the hashrates needed for solo mining today. Since getblocktemplate drastically reduces the load required to a single request per new block on the network, direct solo mining on bitcoind is again possible. Poolservers likewise benefit from having to meet much lower demands of miners who can make their own blocks.
Extensible
The original getwork protocol was designed in a way that was very incompatible with extensions. As a result, as new functionality was needed, extensions were "hacked in" out-of-band using HTTP headers. getblocktemplate is designed from the start to be flexible for future extensions, and the BIP 23 specification already covers how the established getwork extensions can be implemented cleanly, regardless of transport protocol.
How to use it
For miners
Currently, BFGMiner 2.8+ is the first miner to support getblocktemplate.
The following miners have confirmed future support:
To take advantage of getblocktemplate, you also need a compatible pool:
- Eligius
- Bitparking merged mining pool (planned)
- EclipseMC (planned)
- TripleMining (planned)
- Encourage your favourite pool(s) to support decentralized mining!
For pool operators
See also: Poolservers
If you are implementing your own pool server, see the section for poolserver development.
For developers
Mining software
libblkmaker
If your miner can include C libraries, you can harness libblkmaker to do all the GBT interpretation for you: all your miner needs to do then is handle the networking (libblkmaker can prepare the JSON for you) and ask libblkmaker for data (block headers to search). Note that libblkmaker does not provide a SHA256 implementation, and your miner needs to provide one for it to work. libblkmaker currently only supports the Jansson JSON library, but was designed such that it can easily be ported to others; Luke Dashjr is willing to do this porting to other JSON libraries free of charge on request.
From scratch
TODO
Poolserver software
Recommended standards to start with (in order of importance):
- BIP 22 (non-optional sections)
- BIP 22 Long Polling
- BIP 23 Basic Pool Extensions
- BIP 23 Mutation "coinbase/append" (required for miner extranonce rolling)
- BIP 23 Submission Abbreviation "submit/coinbase"
- BIP 23 Mutation "time/increment" (be sure to specify "maxtime" or "maxtimeoff"!)