Add client.reconnect hostname/port/waittime support

[parabitdev]

Parse optional params from client.reconnect messages per the stratum protocol spec. The client disconnects, waits the requested time, then reconnects to the specified host/port. Hostname defaults to the current server and is validated against the configured pool domain (including subdomains) to prevent redirection to unrelated servers.

Added Params:

• Hostname - Allows a pool to redirect a miner to a different instance behind a DNS load balancer, or to a geographically closer / better-peered server for improved latency
• Port - Enables moving miners between difficulty-tier ports (ex. redirecting a high-hashrate device that mistakenly connected to a low-diff port)
• Waittime - Gives the pool control over reconnection timing, useful for staggering reconnects during server maintenance to avoid a thundering herd of simultaneous connections

Cases and what I believe the correct resolution is:

• No params
  • {"method":"client.reconnect"}
  • Reconnect as previously defined
• Hostname-only
  • {"method":"client.reconnect","params":["us1.pool.example.com"]}
  • Reconnect to specified host IF it shares a domain with the current server ELSE use the configured server instead
• Port-only
  • {"method":"client.reconnect","params":["",8333]}
  • Reconnect to the configured server on the specified port
• Waittime-only
  • {"method":"client.reconnect","params":["",0,30]}
  • Disconnect, wait the specified time, then reconnect to the configured server
• Hostname + port
  • {"method":"client.reconnect","params":["us1.pool.example.com",8333]}
  • Reconnect to specified host:port IF hostname shares a domain ELSE use the configured server on the specified port
• Hostname + waittime
  • {"method":"client.reconnect","params":["us1.pool.example.com",0,30]}
  • Disconnect, wait, then reconnect to specified host IF hostname shares a domain ELSE use the configured server
• Port + waittime
  • {"method":"client.reconnect","params":["",8333,30]}
  • Disconnect, wait, then reconnect to the configured server on the specified port
• All three
  • {"method":"client.reconnect","params":["us1.pool.example.com",8333,30]}
  • Disconnect, wait, then reconnect to specified host:port IF hostname shares a domain ELSE use the configured server on the specified port

[johnny9]

Please add a unittest for this helper to make sure pool.co.uk and evil.co.uk fail the check

[parabitdev]

Excellent catch, I will add testing/handling of multipart TLDs prior to converting from draft.

[mutatrum]

Is this an extension of the stratum protocol, and is it documented somewhere?

[mutatrum]

Is this an extension of the stratum protocol, and is it documented somewhere?

https://en.bitcoin.it/wiki/Stratum_mining_protocol#client.reconnect

https://bitcointalk.org/index.php?topic=557866.0

Oh I totally missed that. Not many pools implement it, I guess.

Should it try to connect to the fallback pool if there's a wait period longer than a certain amount?

[parabitdev]

Should it try to connect to the fallback pool if there's a wait period longer than a certain amount?

This is an opinionated question. I personally lean towards the miner<->pool relationship being symbiotic and as such it makes no sense to send a long wait time. There is an argument though that a miner should never be locked out for long periods by a pool's decision ("It is the user's hardware, not mine.").

I am happy to follow your guidance on if you want one (or more) of the following safeguards added wrt this point:

• Set an upper-bound and if exceeded:
  • clamp to upper limit
  • ignore waittime
  • reject the reconnect completely (discarding hostname/port provided)
• Add configurability to allow limiting the maximum waittime at build/runtime.
• Drop support for waittime (opinionated, but valid as it isn't the pool's miner to decide)

[mutatrum]

I tend to the last one, if the pool is not available the firmware tries a few times, fails to do so and connect to the fallback pool. Also, I'm not sure why a pool would say how long that is, maybe to spread the load of reconnects over time?

Counter to that is what you also said, it's symbiotic, so if a pool says it's not available for x amount of time, we can adhere to that. But maybe it's for another PR, and just ignoring the time value for now is one step closer.