Bitcoin Forum
December 10, 2016, 10:28:14 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: X-Roll-Ntime extension  (Read 4594 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



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?

1481408894
Hero Member
*
Offline Offline

Posts: 1481408894

View Profile Personal Message (Offline)

Ignore
1481408894
Reply with quote  #2

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

Posts: 1481408894

View Profile Personal Message (Offline)

Ignore
1481408894
Reply with quote  #2

1481408894
Report to moderator
1481408894
Hero Member
*
Offline Offline

Posts: 1481408894

View Profile Personal Message (Offline)

Ignore
1481408894
Reply with quote  #2

1481408894
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



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?

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



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: 546



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: 2030



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.

JoelKatz
Legendary
*
Offline Offline

Activity: 1386


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.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



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: 2100



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!