Bitcoin Forum
December 09, 2016, 11:40:01 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: Should "setauxwork" be accepted as a new JSON-RPC method?
No - 6 (26.1%)
Yes - 17 (73.9%)
Total Voters: 23

Pages: [1] 2 3 »  All
  Print  
Author Topic: Coinbaser branch's new JSON-RPC method  (Read 5137 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 05, 2011, 04:23:12 PM
 #1

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. Smiley

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.

1481326801
Hero Member
*
Offline Offline

Posts: 1481326801

View Profile Personal Message (Offline)

Ignore
1481326801
Reply with quote  #2

1481326801
Report to moderator
1481326801
Hero Member
*
Offline Offline

Posts: 1481326801

View Profile Personal Message (Offline)

Ignore
1481326801
Reply with quote  #2

1481326801
Report to moderator
1481326801
Hero Member
*
Offline Offline

Posts: 1481326801

View Profile Personal Message (Offline)

Ignore
1481326801
Reply with quote  #2

1481326801
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481326801
Hero Member
*
Offline Offline

Posts: 1481326801

View Profile Personal Message (Offline)

Ignore
1481326801
Reply with quote  #2

1481326801
Report to moderator
1481326801
Hero Member
*
Offline Offline

Posts: 1481326801

View Profile Personal Message (Offline)

Ignore
1481326801
Reply with quote  #2

1481326801
Report to moderator
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 05, 2011, 05:46:22 PM
 #2

I'd love to hear why someone voted No.

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 05, 2011, 06:11:22 PM
 #3

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.

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 05, 2011, 06:19:18 PM
 #4

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
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
October 05, 2011, 09:30:42 PM
 #5

So, how do you intend setworkaux to be used?

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 05, 2011, 10:22:23 PM
 #6

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
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 05, 2011, 10:24:09 PM
 #7

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
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
October 06, 2011, 06:04:37 AM
 #8

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?

PoolServerJ Home Page - High performance java mining pool engine

1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq - http://payb.tc/shads

Quote from: Matthew N. Wright
Stop wasting the internet.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 09, 2011, 06:11:36 PM
 #9

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
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
October 10, 2011, 09:32:33 AM
 #10

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
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 10, 2011, 01:08:26 PM
 #11

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
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
October 10, 2011, 02:03:18 PM
 #12

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
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 10, 2011, 02:14:51 PM
 #13

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... Wink)

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 10, 2011, 03:08:55 PM
 #14

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?

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 10, 2011, 03:33:05 PM
 #15

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 10, 2011, 03:38:11 PM
 #16

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.

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 10, 2011, 05:20:16 PM
 #17

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
Legendary
*
Offline Offline

Activity: 1708



View Profile
October 10, 2011, 06:13:19 PM
 #18

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.
 

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 10, 2011, 06:25:41 PM
 #19

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
Legendary
*
Offline Offline

Activity: 1708



View Profile
October 10, 2011, 06:41:16 PM
 #20

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".

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!