Bitcoin Forum
December 10, 2016, 09:08:34 AM *
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  
Pages: [1]
  Print  
Author Topic: Can a getwork be returned to different bitcoind than the one you got it from?  (Read 1247 times)
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 21, 2011, 07:56:23 AM
 #1

Building a multi source proxy in java, I haven't really got to the guts of verifying blockheaders yet but it's important to the design of the project to know if it matters.

i.e. say I'm taking getworks from multiple sources, when that getwork is solved and ready to be returned does it matter if I return it to a different bitcoin server or is the request somehow keyed to the bitcoin server that generated it?

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
1481360914
Hero Member
*
Offline Offline

Posts: 1481360914

View Profile Personal Message (Offline)

Ignore
1481360914
Reply with quote  #2

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

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 21, 2011, 01:16:08 PM
 #2

I believe that if you return it to a different client and that client had accepted a different list of transactions, it won't be able to claim the block.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 21, 2011, 02:22:26 PM
 #3

so even if the client passes it on as is?  What I mean is that I don't want the alternative client to try and claim the block, just that it should pass the block onto the network so the original issuer of the getwork request is credited with the new block.

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 21, 2011, 02:54:52 PM
 #4

The miner only has the block header, which is not useful without the actual block that goes with it.  The completed work must be returned to the pool (node) that issued it.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
June 21, 2011, 02:55:58 PM
 #5

The miner only sees the block header - the client remembers which block contents (=transactions) match with it. Since you need to know which transactions to add to it, you need the bitcoind that gave it to you. Furthermore, the header depends on all transactions in the block, so if you'd add the wrong ones, the header wouldn't be valid anymore.

Short answer: no

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 12:37:23 AM
 #6

So my next ask is to figure out how to match a submitted getwork to the server it came from.

i.e.
- client requests work
- proxy returns work from one of several servers
- proxy keeps mapping of work sent to upstream server
- Client submits completed work
- proxy verifies work and then looks up mapping to find correct server to submit to

The doco is a bit hazy on this.  I presume from here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
that the data is the actual block.  Proxy verifies by double hashing it and comparing difficulty.  But how do I match it?  All the proxy has is the original getwork request with:

    "midstate" : precomputed hash state after hashing the first half of the data
    "data" : block data
    "hash1" : formatted hash buffer for second hash
    "target" : little endian hash target

Is the block data contained within the block submitted by the client?  According to this page: https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers There's no data in the block header. 

The target is useless since they'll all have the same one.  No idea what the midstate and hash1 fields are.  So is there any what to identify it as the result of a particular work request or is it simply not built into the design to be able to match like this?

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 23, 2011, 12:42:21 AM
 #7

So my next ask is to figure out how to match a submitted getwork to the server it came from.

i.e.
- client requests work
- proxy returns work from one of several servers
- proxy keeps mapping of work sent to upstream server
- Client submits completed work
- proxy verifies work and then looks up mapping to find correct server to submit to

The doco is a bit hazy on this.  I presume from here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
that the data is the actual block.  Proxy verifies by double hashing it and comparing difficulty.  But how do I match it?  All the proxy has is the original getwork request with:

    "midstate" : precomputed hash state after hashing the first half of the data
    "data" : block data
    "hash1" : formatted hash buffer for second hash
    "target" : little endian hash target

Is the block data contained within the block submitted by the client?  According to this page: https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers There's no data in the block header. 

The target is useless since they'll all have the same one.  No idea what the midstate and hash1 fields are.  So is there any what to identify it as the result of a particular work request or is it simply not built into the design to be able to match like this?

The proxy is not limited to the information in the blocks itself.  It is allowed to keep a record for itself of which server provided the most recent work request for each client.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 01:08:18 AM
 #8

True but I'm assuming the client can make multiple getwork requests (which could each be served from a different upstream server) and that there's no garuntee that client is submitting the most recently aquired work.

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 23, 2011, 01:12:30 AM
 #9

True but I'm assuming the client can make multiple getwork requests (which could each be server from a different upstream server) and that there's no garuntee that client is submitting the most recently aquired work.

Your assumption is wrong.

Every client works on one getwork request at a time, and always the most recent.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 01:17:55 AM
 #10

For most clients you're correct that the assumption is wrong but I'm talking about a client that operates a little differently which is part of the same project I'm building.

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
June 23, 2011, 06:56:49 AM
 #11

First of all, why would you do that?  If you work on multiple getworks at the same time, you slow your completion rate down and increase your chance of a stale share.

I can't see any reason why you'd do that *except* to queue work up for a slow link.  But again, you run into the problem of increasing your stale shares dramatically.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 08:58:05 AM
 #12

I have a perfectly good reason which will be obvious when the project is ready for release.  You said 'first of all' so I guess next you were going to suggest an answer to the question?

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 23, 2011, 09:28:36 AM
 #13

For most clients you're correct that the assumption is wrong but I'm talking about a client that operates a little differently which is part of the same project I'm building.

I look forward to finding out what you hope to accomplish with this.

The data field will be unique, at the very least to the server and block in progress.  You can record that with the server it came from.  Or, since you are changing both the proxy and the client, you could just have the proxy add a field that just says what server to give the work back to, and have the client return that when it returns the candidate hashes.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 09:35:02 AM
 #14

I look forward to finding out what you hope to accomplish with this.

Shoudn't be more than a few days after I figure this bit out...

Quote
The data field will be unique, at the very least to the server and block in progress.  You can record that with the server it came from.  Or, since you are changing both the proxy and the client, you could just have the proxy add a field that just says what server to give the work back to, and have the client return that when it returns the candidate hashes.

So the 'data' field that the miner returns is somehow related to the 'data' field in the getwork response.  But it couldn't be the same or the server already has the block solved.  

Is the data field just the block header with the nonce altered to produce a valid block?

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 23, 2011, 09:40:52 AM
 #15

I look forward to finding out what you hope to accomplish with this.

Shoudn't be more than a few days after I figure this bit out...

Quote
The data field will be unique, at the very least to the server and block in progress.  You can record that with the server it came from.  Or, since you are changing both the proxy and the client, you could just have the proxy add a field that just says what server to give the work back to, and have the client return that when it returns the candidate hashes.

So the 'data' field that the miner returns is somehow related to the 'data' field in the getwork response.  But it couldn't be the same or the server already has the block solved. 

Is the data field just the block header with the nonce altered to produce a valid block?

Yes.  The server sends the data block to the client with the nonce field set to 0.  The client iterates through the 2^32 possible nonces, checking each one.  If it finds one that meets the target, it sends the modified block back.

There are circumstances where the server can send the exact same block out more than once, but this is rare, and you can't do anything about it until the node software is fixed.  But, each node will have a totally different coinbase transaction included in the Merkle tree, so you will never get the same data block from two different servers, allowing you to always identify which server gave which work.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
June 23, 2011, 10:06:21 AM
 #16

Quote
Yes.  The server sends the data block to the client with the nonce field set to 0.  The client iterates through the 2^32 possible nonces, checking each one.  If it finds one that meets the target, it sends the modified block back.

Thanks kkj.  That's exactly what I needed to know and exactly the part that is pretty fuzzy on the API calls and getwork wiki pages.  It does explain it in part but it doesn't really say clearly that 'data'=block_header.  Can anyone create an account on the wiki and edit?  If so I might try to tidy that up a bit because I'm sure I'm not the first or last person it's going leave scratching their head.

PoolServerJ Home Page - High performance java mining pool engine

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

Quote from: Matthew N. Wright
Stop wasting the internet.
Pages: [1]
  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!