Skip to content

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Dec 20, 2011

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.

@jgarzik
Copy link
Contributor

jgarzik commented Jan 11, 2012

  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.

@luke-jr
Copy link
Member Author

luke-jr commented Jan 11, 2012

  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)

@luke-jr
Copy link
Member Author

luke-jr commented Jan 11, 2012

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?

@sipa
Copy link
Member

sipa commented Jan 11, 2012

  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

@luke-jr
Copy link
Member Author

luke-jr commented Jan 11, 2012

  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

@luke-jr
Copy link
Member Author

luke-jr commented Jan 12, 2012

  1. Rebased into 5 logical commits
  2. Now using std::numeric_limits instead of limits.h, like the rest of Bitcoin as of recently
  3. 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
  4. Refactored "%d" replacement using boost::lexical_cast and boost::replace_all

@luke-jr
Copy link
Member Author

luke-jr commented Jan 12, 2012

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

@sipa
Copy link
Member

sipa commented Jan 12, 2012

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

@Nitrowolf
Copy link

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.

@forrestv
Copy link
Contributor

ACK on the changes to RPC getmemorypool.

@luke-jr
Copy link
Member Author

luke-jr commented Mar 19, 2012

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.

@luke-jr
Copy link
Member Author

luke-jr commented Mar 25, 2012

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

@luke-jr luke-jr closed this Mar 25, 2012
destenson pushed a commit to destenson/bitcoin--bitcoin that referenced this pull request Jun 26, 2016
destenson pushed a commit to destenson/bitcoin--bitcoin that referenced this pull request Jun 26, 2016
rajarshimaitra pushed a commit to rajarshimaitra/bitcoin that referenced this pull request Aug 5, 2021
Offers some minor spelling updates
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants