Bitcoin Forum
January 18, 2018, 04:49:36 AM *
News: Electrum users must upgrade to 3.0.5 if they haven't already. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: X-Roll-Ntime extension  (Read 4888 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2310



View Profile
June 25, 2011, 09:08:24 PM
 #1

As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.

Thoughts?

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2394



View Profile
June 26, 2011, 03:20:12 AM
 #2

As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.
Thoughts?

N seconds or ntime incremented by N?


Bitcoin will not be compromised
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2310



View Profile
June 26, 2011, 05:30:46 AM
 #3

As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.
Thoughts?
N seconds or ntime incremented by N?
There shouldn't be a difference...

fpgaminer
Hero Member
*****
Offline Offline

Activity: 560



View Profile WWW
June 26, 2011, 07:25:34 AM
 #4

Quote
This can allow miners to know precisely when to give up on it and get new work.
How would the pool provide a sane value, since it doesn't know when the next block will be found?

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2394



View Profile
June 26, 2011, 07:29:46 AM
 #5

Quote
This can allow miners to know precisely when to give up on it and get new work.
How would the pool provide a sane value, since it doesn't know when the next block will be found?

Long polling, of course. The pool knows how old a block header its willing to accept, which is what this is useful for.


Bitcoin will not be compromised
JoelKatz
Legendary
*
Offline Offline

Activity: 1582


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 27, 2011, 10:53:14 AM
 #6

Quote
This can allow miners to know precisely when to give up on it and get new work.
How would the pool provide a sane value, since it doesn't know when the next block will be found?
The pool operator will choose a sane value, or a sane algorithm based upon the difficulty.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2310



View Profile
July 15, 2011, 08:10:48 PM
 #7

Due to network latency, I recommend the following design for miners:
1. getwork, record <duration of getwork request> and <time+getwork expire> , and begin mining on it
2. every second, update ntime and reset nonce to <first nonce>
3. when a share is found, submit it. record the duration of the submit request.
4. if a share submission fails due to a network error, save the share and retry it a second later the same as step 3; also immediately (regardless of how long the current work has been active) begin trying to get new work (which is treated the same as step 5+6 when done)
5. when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work
6. when new work arrives, discard old work and begin using the new work.

vector76
Member
**
Offline Offline

Activity: 70


View Profile
July 15, 2011, 08:48:41 PM
 #8

Due to network latency, I recommend the following design for miners:
1. getwork, record <duration of getwork request> and <time+getwork expire> , and begin mining on it
2. every second, update ntime and reset nonce to <first nonce>
3. when a share is found, submit it. record the duration of the submit request.
4. if a share submission fails due to a network error, save the share and retry it a second later the same as step 3; also immediately (regardless of how long the current work has been active) begin trying to get new work (which is treated the same as step 5+6 when done)
5. when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work
6. when new work arrives, discard old work and begin using the new work.

If I understand this correctly, rather than waiting until the exact getwork expire deadline, you are getting new work a little bit early, based on how long the getwork/submit request takes?  So for example if getwork takes at most 5 seconds you get new work 20 seconds before the current work expires, to avoid submitting expired shares.

What about just a fixed percentage or a fixed duration?  I might worry that this scheme could have unintended side-effects.  If server load increases lagginess, it could be self-reinforcing if it increases the chances that the miners will decide to refresh their work.  What might have been randomly spread out over time could become concentrated and bursty.  I am visualizing sand dunes but I can't connect it with words.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2310



View Profile
July 15, 2011, 08:54:08 PM
 #9

If I understand this correctly, rather than waiting until the exact getwork expire deadline, you are getting new work a little bit early, based on how long the getwork/submit request takes?  So for example if getwork takes at most 5 seconds you get new work 20 seconds before the current work expires, to avoid submitting expired shares.
Correct.
What about just a fixed percentage or a fixed duration?  I might worry that this scheme could have unintended side-effects.  If server load increases lagginess, it could be self-reinforcing if it increases the chances that the miners will decide to refresh their work.  What might have been randomly spread out over time could become concentrated and bursty.  I am visualizing sand dunes but I can't connect it with words.
I don't think there is any way to avoid this potential problem. Surely you don't want to suggest miners do stale work? A fixed percentage/duration would not adapt well to the many different network links/distances that can affect latency.

vector76
Member
**
Offline Offline

Activity: 70


View Profile
July 16, 2011, 01:31:23 PM
 #10

Not a big deal.  I guess if it becomes a problem the pool can dither N.  Which they would probably want to do anyway to avoid a spike exactly N seconds after a new block.
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!