Coinbaser branch's new JSON-RPC method

[Luke-Jr]

Link to coinbaser pull request

My coinbaser branch adds a "setworkaux" method to allow miners to add arbitrary coinbase data to their blocks. This is mainly useful to implement merged mining (mining for both bitcoins and namecoins concurrently), but could also be used for miner voting in the future. As with any JSON-RPC change, adding this requires some kind of consensus. Please vote in support.

This is a backward compatible change.

Unrelated to this poll:
In addition to "setworkaux", coinbaser also adds (non-Windows only!) a "-coinbaser=<cmd>" command line option to specify a command to execute during "getwork" calls; the command may output data specifying where to assign the generated coins (this is how I do generated payouts on Eligius). It also adds a minor internal restructure of coinbase-creation code, which can be used to more easily implement automatic feature upgrades (OP_EVAL, for example) by miner adoption. These changes are also backward-compatible, and provide useful functionality.

[Luke-Jr]

I'd love to hear why someone voted No.

[Gavin Andresen]

I voted no because of the fine-print in your original post.

I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool.

[Luke-Jr]

I voted no because of the fine-print in your original post.

The poll was, as stated, unrelated to the "fine print". You asked for consensus on JSON-RPC changes, which has nothing to do with the fine print.

I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool.

It might work on Windows with a few changes, but I don't have a Windows system to test on. http://msdn.microsoft.com/en-us/library/96ayss4b(v=vs.71).aspx

Also, there's nothing Eligius-specific about it.

[simplecoin]

So, how do you intend setworkaux to be used?

[Luke-Jr]

So, how do you intend setworkaux to be used?

From the code:

Code:

setworkaux <id> [data]
If [data] is not specified, deletes aux.

[Luke-Jr]

I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool.

It might work on Windows with a few changes, but I don't have a Windows system to test on. http://msdn.microsoft.com/en-us/library/96ayss4b(v=vs.71).aspx

Ok, ported coinbaser to Windows. Surprisingly, the problem wasn't popen, but fdopen (for TCP support).

[shads]

I'm not going to vote until I understand it better.

I think it replicates some of the functions of getworkaux from vinced's merged-mining fork.  If so there should be some discussion of which to use before considering either for pulling into the main branch.

Given that merged-mining-proxy uses getworkaux along with a couple of other new rpc calls, and that merged-mining-proxy will most likely be the fallback option for pools using pushpool to become merged-mining capable... and that I'm currently implementing merged mining into poolserverj using these calls from vinced's fork it would seem likely that it's going to gain wider adoption.

I'm totally open to using your method if it's somehow an improvement on the vinced method but simply saying it allows you insert data into the coinabse doesn't really explain the workflow of constructing a merged mining block.  You still need a way to get the header hash of each aux chain block (getwork and hash yrself?), contruct a merkle tree then presumably pass the merkle root of this to setworkaux.  I can figure it out that far but how under your scheme do you submit a solution to an aux chain?

[Luke-Jr]

Gavin has apparently decided (for no reason) that he isn't going to merge this, even though this thread met his requirement of having "community support" for the new "setworkaux" JSON-RPC method. I doubt I'll bother maintaining this through the next version, so I guess pester Gavin if you want it (or hope it gets merged to post-0.5 git before it needs yet another rebase...)

[Mike Hearn]

I'd really like to see something like this get in, but I agree with Steve - it's not clear why this is different to what Vince has already done.

[Luke-Jr]

I'd really like to see something like this get in, but I agree with Steve - it's not clear why this is different to what Vince has already done.

Vince's stuff is a mess of unreadable code, that requires putting a proxy (additional point of failure/bottleneck) in front of bitcoind. This approach is much simpler (at least insofar as modifications to bitcoind) and has no effect on the stability of the primary Bitcoin mining operation (since the merged-mining manager runs parallel to bitcoind, not in front of it). These changes are also more abstract, not necessarily tied to merged-mining specifically.

[Mike Hearn]

setworkaux looks pretty much like what I'd imagined. You might want to split the command line option out, as that's a separate and unrelated change.

BTW, what's the backwards-time detection stuff about? I know time can sometimes go backwards on some machines, but you could add a comment explaining why this code is there (was it observed in the wild on eligius machines)? Also it doesn't currently log anything when extraNonce overflows - is that an exceptional condition or something that's expected to happen normally? If the former (it's a bug) maybe assert/terminate. If the latter does it need to be logged? If it's unknown, logging for a while seems to make sense.

[Luke-Jr]

setworkaux looks pretty much like what I'd imagined. You might want to split the command line option out, as that's a separate and unrelated change.

They're very much the same change: they both together support customization of the coinbase transaction.

BTW, what's the backwards-time detection stuff about? I know time can sometimes go backwards on some machines, but you could add a comment explaining why this code is there (was it observed in the wild on eligius machines)? Also it doesn't currently log anything when extraNonce overflows - is that an exceptional condition or something that's expected to happen normally? If the former (it's a bug) maybe assert/terminate. If the latter does it need to be logged? If it's unknown, logging for a while seems to make sense.

Just a safety precaution. I don't know if it's possible or ever occurs. (otoh, it's very easy to see many existing code paths in bitcoind cannot possibly occur... )

[Gavin Andresen]

This is why I don't pull additions or major changes to RPC commands without at least a couple of people looking at them and either saying "yup, that's exactly how I would do it" or "it'd be better if...."

I agree with Mike, the -coinbaser <cmd> should be separate from setauxwork.

Does setauxwork interact with the new getmemorypool RPC command at all?  Should it?

And should there be a listauxwork RPC command?

[Luke-Jr]

Does setauxwork interact with the new getmemorypool RPC command at all?  Should it?

No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool.

And should there be a listauxwork RPC command?

Possibly as a debugging tool.

[Gavin Andresen]

No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool.

Huh?  getmemorypool discussion is/was here:  https://bitcointalk.org/index.php?topic=39088.0

I'll just note that I'm damned if I do pull stuff that has some discussion here (and no objections raised), but damned if I don't pull stuff that first had no discussion, and then had a little discussion with some dissent.

[Luke-Jr]

No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool.

Huh?  getmemorypool discussion is/was here:  https://bitcointalk.org/index.php?topic=39088.0

I'll just note that I'm damned if I do pull stuff that has some discussion here (and no objections raised), but damned if I don't pull stuff that first had no discussion, and then had a little discussion with some dissent.

1-2 people supporting getmemorypool vs 9 supporting coinbaser. hmm.

What dissent? I see questions, and some "no" votes (strangely, most of which just appeared today), but no arguments against this.

[2112]

What dissent? I see questions, and some "no" votes (strangely, most of which just appeared today), but no arguments against this.

The argument that I have: it appears that "getmemorypool" is a step towards allowing the miner to record a reasonably accurate time of finding the block. Which is in turn a step towards more tight and accurate timekeeping in the whole block chain.

Your patch just perpetuates the existing bad situation where the block times are untrustworthy and acausal.

Thank you for your time and understanding.
 

[Luke-Jr]

The argument that I have: it appears that "getmemorypool" is a step towards allowing the miner to record a reasonably accurate time of finding the block. Which is in turn a step towards more tight and accurate timekeeping in the whole block chain.

Your patch just perpetuates the existing bad situation where the block times are untrustworthy and acausal.

Block times will always be untrustworthy to a degree, and are already trustworthy to a degree. It is impossible and unreasonable to force everyone to have the exact same system clock. "getwork" does not enforce the time header, anyhow, so "getmemorypool" does not change this reality in any way. (that is, "getwork" allows miners to change the time at will)

[2112]

It is impossible and unreasonable to force everyone to have the exact same system clock.

I think that Lolcust and ArtForz provided a good counter-example by their GeistGeld alt-chain that uses SNTP for time synchronization. The objective is not "exact-same" system clock, but the system clock differences that are within currently acceptable norms: I think it is still one minute in the insurance industry and in something close to one second in the finance industry.

I'm sorry I misunderstood the difference in time-keeping between "getwork" and "getmemorypool".