Bitcoin Forum
March 19, 2024, 02:29:35 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Mining protocol extension: noncerange  (Read 4508 times)
Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 29, 2011, 02:31:04 PM
Last edit: July 18, 2011, 11:46:27 AM by Luke-Jr
 #1

I propose that miners which support this extension send a "X-Mining-Extensions: noncemask" header when requesting work. If the server supports the extension, it should respond with the same header. For other extensions, "X-Mining-Extensions" should be a space-delimited list of elements which can have parameters after an "=" character.

When this extension is active, the server should send an additional field in the JSON-RPC reply: "noncemask" is a hexadecimal-encoded mask of the nonce bits a miner is allowed to change in the header.

For example, if the server sends
Code:
    "noncemask" : "e0000000"
then the miner should change only the last 29 bits of the nonce.

This allows the server to give the same work to multiple miners with different nonce ranges for each to scan. Combined with X-Roll-Ntime, this can greatly improve efficiency of the work-generating component.

In addition, miners may send a "X-Mining-Hashrate" header set to their average hashrate (in hashes per second) which the upstream server might use to choose a proper sized noncemask.

Thoughts?

Edit: noncemask has been superceded by noncerange

1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
1710815375
Hero Member
*
Offline Offline

Posts: 1710815375

View Profile Personal Message (Offline)

Ignore
1710815375
Reply with quote  #2

1710815375
Report to moderator
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 29, 2011, 03:12:21 PM
 #2

What's the primary goal? Is it to reduce the number of times the pool manager has to do a 'getwork' call?

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
johncarl
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
June 29, 2011, 03:34:31 PM
 #3

Thoughts?

Would you see this replacing a stale work timeout?
gnukix
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
June 29, 2011, 04:15:38 PM
 #4

I propose that miners which support this extension send a "X-Mining-Extensions: noncemask" header when requesting work. If the server supports the extension, it should respond with the same header. For other extensions, "X-Mining-Extensions" should be a space-delimited list of elements which can have parameters after an "=" character.

When this extension is active, the server should send an additional field in the JSON-RPC reply: "noncemask" is a hexadecimal-encoded mask of the nonce bits a miner is allowed to change in the header.

For example, if the server sends
Code:
    "noncemask" : "70000000"
then the miner should change only the last 29 bits of the nonce.

This allows the server to give the same work to multiple miners with different nonce ranges for each to scan. Combined with X-Roll-Ntime, this can greatly improve efficiency of the work-generating component.

In addition, miners may send a "X-Mining-Hashrate" header set to their average hashrate (in hashes per second) which the upstream server might use to choose a proper sized noncemask.

Thoughts?



I don't understand why this should be a HTTP header and muddy things up with side-band information.  Why not just put it in-band, in the JSON request itself?  The current clients and servers are all looking for specific fields, so add a field there?  Then the parsing is very well defined instead of ad-hoc.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
June 29, 2011, 11:15:44 PM
 #5

Yeah, just put it in the JSON request.  I don't think anyone anywhere is doing validation that would reject it because of extra fields.

Leave the meta-channel for information/negotiation about the channel.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 12, 2011, 05:53:56 AM
 #6

No extension is sane if it breaks the specification for the low-level protocol.

However, one real problem found is that a mask like ff00ff00 would be a pain to implement.

Therefore, I am proposing replacing noncemask with noncerange, with a value of two 32-bit integers (encoded as hex) specifying the initial value, and last acceptable value. So for example, to give a miner the first 29 bits of nonce space (up to 536 MH/s):
Code:
"noncerange": "000000001fffffff"

ah42
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
July 15, 2011, 05:22:51 PM
 #7

I think it actually makes good sense for the client to use a header: it is often a common practice to advertise capabilities in HTTP headers (or even e-mail headers...)

However, it might make sense for the server to respond with the noncemask in the JSON content, as the client has already advertised its capability to handle such content.
Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 28, 2011, 07:02:46 PM
 #8

In the attempt to implement noncerange, I came across a dilemma: while all the existing share data is in big-endian blocks of 32 bits (with larger numbers being little-endian otherwise), it seems OpenCL miners at least choose their range in little-endian. Since nonce is only 32-bits, and all 32-bit fields are standardized on big-endian (not to mention it being the standard network endian), I'd much prefer to maintain the actual nonce field as big-endian. Can someone familiar with OpenCL and/or other mining platforms (SSE2, etc) tell us whether endian will hurt performance, and if so which endian is needed to maintain the current performance? Miner implementations welcome also! (gMinor has broken noncerange support!)

-ck
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
July 29, 2011, 01:06:35 AM
 #9

Keep the delivery of the data consistent by being in big endian. It should be up to the coders to flip the endianness before feeding it to openCL.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 29, 2011, 01:23:09 AM
 #10

Keep the delivery of the data consistent by being in big endian. It should be up to the coders to flip the endianness before feeding it to openCL.
You can't just flip endians when you're hashing.

Schleicher
Hero Member
*****
Offline Offline

Activity: 675
Merit: 513



View Profile
July 29, 2011, 05:02:29 AM
 #11

You can flip endianness while converting the hex values

Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 29, 2011, 05:05:15 AM
 #12

You can flip endianness while converting the hex values
But then your hashes will all be wrong...?

1bitc0inplz
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
July 29, 2011, 05:22:08 AM
 #13

In regards to this being an HTTP header....

In order for this to be truly successful, the pool would need to know which miners supported such a feature. The reason for this, is the pool needs to know which miners to send the same work to multiple times (differing only by nonce range). If the pool accidentally sent the same work to multiple miners and they didn't support this feature, the pool would just be wasting somebody's resources.

At the very least, the miner needs to set an HTTP header on the getwork request to inform the server that it supports such a feature.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
Schleicher
Hero Member
*****
Offline Offline

Activity: 675
Merit: 513



View Profile
July 29, 2011, 05:23:29 AM
 #14

You can flip endianness while converting the hex values
But then your hashes will all be wrong...?
We only have to agree on a endianness for the communication between server and client. Big or little doesn't really matter. The value has to be converted only once for every getwork request.
Or are we misunderstanding you?

Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 29, 2011, 05:30:40 AM
 #15

You can flip endianness while converting the hex values
But then your hashes will all be wrong...?
We only have to agree on a endianness for the communication between server and client. Big or little doesn't really matter. The value has to be converted only once for every getwork request.
Or are we misunderstanding you?
0 to 1000000 is very different in little endian and big endian. Since SHA256 is on the byte level, the hash for 1000000 in little endian and big endian will be different.

Schleicher
Hero Member
*****
Offline Offline

Activity: 675
Merit: 513



View Profile
July 29, 2011, 05:34:32 AM
 #16

0 to 1000000 is very different in little endian and big endian. Since SHA256 is on the byte level, the hash for 1000000 in little endian and big endian will be different.
Sure. That's why you convert all values to the proper endianness before hashing.

Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 29, 2011, 05:53:07 AM
 #17

0 to 1000000 is very different in little endian and big endian. Since SHA256 is on the byte level, the hash for 1000000 in little endian and big endian will be different.
Sure. That's why you convert all values to the proper endianness before hashing.
And what kind of overhead will that have? I'm under the impression it's pretty bad.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 29, 2011, 06:41:45 AM
 #18

I don't think it will be much of a performance hit to make the mining client keep their counter in a non-native byte ordering.  If their native byte ordering is messed up, they will just have to use an 8 bit counter for the inner loop, and have a tiny bit of logic for incrementing and checking the rest when it overflows every 256 hashes.

Even if the conversion from network order to native order took as much work as a full (double) SHA256 hash, the performance it would be under 0.4%.  In practice, it will be MUCH less overhead.  On an Intel, it won't even take an extra register.

Just make sure that all of your range boundaries are multiples of 256.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Luke-Jr (OP)
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
July 29, 2011, 06:46:00 AM
 #19

I don't think it will be much of a performance hit to make the mining client keep their counter in a non-native byte ordering.  If their native byte ordering is messed up, they will just have to use an 8 bit counter for the inner loop, and have a tiny bit of logic for incrementing and checking the rest when it overflows every 256 hashes.

Even if the conversion from network order to native order took as much work as a full (double) SHA256 hash, the performance it would be under 0.4%.  In practice, it will be MUCH less overhead.  On an Intel, it won't even take an extra register.

Just make sure that all of your range boundaries are multiples of 256.
Except that AIUI, GPUs don't iterate. They run them all at once...

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 29, 2011, 06:51:30 AM
 #20

I don't think it will be much of a performance hit to make the mining client keep their counter in a non-native byte ordering.  If their native byte ordering is messed up, they will just have to use an 8 bit counter for the inner loop, and have a tiny bit of logic for incrementing and checking the rest when it overflows every 256 hashes.

Even if the conversion from network order to native order took as much work as a full (double) SHA256 hash, the performance it would be under 0.4%.  In practice, it will be MUCH less overhead.  On an Intel, it won't even take an extra register.

Just make sure that all of your range boundaries are multiples of 256.
Except that AIUI, GPUs don't iterate. They run them all at once...

No, they still iterate.  They just use larger increments.  Unless there is a chip out there with 4 billion ALUs that I don't know about.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!