X-Roll-Ntime extension

[Luke-Jr]

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?

[1714971197]

1714971197

[1714971197]

1714971197

[1714971197]

1714971197

[1714971197]

1714971197

[1714971197]

1714971197

[1714971197]

1714971197

[gmaxwell]

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]

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]

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]

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]

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.

[Luke-Jr]

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]

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]

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]

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.