Coinbaser #719

This enables miners to manipulate their coinbases. Documented on the wiki.

At least Eligius (400 GH/s) and Eclipse (235 GH/s) are already using it, and slush (1.3 TH/s) intends to.

Accepted by Gavin for merging in the 0.6 window December 02, 2011.

1. can we get by with just 'setworkaux' and no -coinbaser?
2. if we are doing -blocknotify as system() only (see separate pull), drop TCP socket here and do same
3. meta: should be collapsed into fewer commits
4. mapAuxCoinbases seems like it should really be a vector
5. truncating script at 100 bytes creates more problems than it solves. we should fail large scriptSig, not truncate. search for "resize(100)" and kill.

1. no reason to; people are moving to other software for mining because bitcoind doesn't support these
2. system() is too simplified, this needs popen() to get stdout from process; TCP socket can probably go, but might be needed since this could potentially be higher-load (new blocks, on the other hand, are only once every 10 mins on avg)
3. could be, but not should be; multiple steps makes bisecting and merging easier and cleaner
4. it's a map so there are names for updates/deletes
5. it already fails at large scriptSig; the truncate is a "just in case" since nobody wants to lose a block just because somehow there's too much data for the coinbase (for example, if some internal-to-bitcoind feature in the future starts manipulating aux data, such as an automated miner voting thing)

Also, the current code has had months of testing. Any major restructures just for the sake of restructuring are liable to possibly introduce bugs, and there's really no reason or need to do so.

This is needed, there's no known problems with it, it's had months of testing and reviews, and Gavin OK'd it months ago. Why are we going out of the way to look for stuff to change when it works well?

1. I'd rather see setworkaux and coinbaser in separate requests as well; the latters seems a lot more intrusive and maybe much less needed
2. is popen() so difficult?
3. i don't care
4. i don't care
5. as long as pre-automated-modifications to the coinbase are guaranteed to cause failure if it's over 100 bytes, i don't care

1. -coinbaser has zero "intrusive" unless enabled, is very isolated, and very well tested for nearly a full year.
2. popen() "just works" on every OS

3. Rebased into 5 logical commits
4. Now using std::numeric_limits instead of limits.h, like the rest of Bitcoin as of recently
5. Removed OP_EVAL-specific advertisement; miners can still advertise it (or any other vote) via setworkaux, or a similar vote can be re-added the same was as before in a new commit
6. Refactored "%d" replacement using boost::lexical_cast and boost::replace_all

Fixed a bug sipa found and one it made me think to check:

• pclose() might not be portable on sockets, so use fclose for those
• Windows needs closesocket() after fclose(), and in case of error, to cleanup the socket

Not sure still about necessity, but ACK on the code changes.

It would be really handy if coinbaser were merged with the mainline. I have to do enough changes to my code to upgrade and then test without having to also do basics like this. It seems like it would be an addition that has no drawbacks to those who do not use it and advantageous to those who do, like EMC.

ACK on the changes to RPC getmemorypool.

Since this has gone two .y releases without merging, and I no longer have any use for it myself, I have decided that unless someone (with push access) agrees to merge it, I will no longer be rebasing it, and it will drop from my 'next' branch when the inevitable 0.7 changes conflict with it. If you are using Coinbaser, I recommend migrating to other software for generating work, such as Eloipool.

This no longer merges cleanly; closing. Reopen if someone is willing to merge to master.