[Mining] Build empty block on when chainTip changes. #7104

Reduce latency of switching to new block.

Edit: I'm not really sure this is a good idea.

We're still building on a fully validated chainTip right?

Personally I'd even go as far as saying we should explicitly support SPV mining, so this is definitely a Concept ACK for me.

@petertodd That's correct.

@pstratem This should probably be a configurable option. I'm also not entirely sure how this would affect block notifys, maybe one way to handle this would be to have two notify triggers, one for when the empty template is ready and one when the full is so that the stratum server can push out full templates as soon as they are ready. @petertodd I'm not sure how one could properly implement SPV mining, even if you implement a timeout you can't easily roll back stratum templates to the previous block in most(maybe all) the deployed cgminer versions.

@jameshilliard I don't see the point of it being a configurable option.

Using blocknotify only is dangerous, you can and will miss notifications. Because of this the only wy to get a truly low latency pool is to run multiple bitcoind nodes and merge the result of getblocktemplate at the pool level.

@pstratem The point for having it configurable would be in cases where this makes a minimal difference in GBT times while at the same having higher costs for sending stratum updates(I could potentially see this as an issue for some pools with very large amounts of connections).

The current behavior with ckpool for is that a notify immediately triggers a GBT call and template update in addition to the normal 30 second GBT polls. How would using only blocknotify's miss notifications, is it not reliable in core? I haven't noticed any reliability issues with blocknotify(from my benchmarking the 3 public ckpool based pools are generally some of the fastest pools to send out updates aside from f2pool and btcchina, which SPV mine of course).

Using blocknotify only is dangerous, you can and will miss notifications.

That sounds like the bigger problem here?

@dcousens There isn't a reasonable way to ensure that the notifications are delivered and correctly processed.

It's a byzantine consensus problem all by itself.

@jameshilliard And what happens when the notify triggers during the middle of a getblocktemplate scheduled poll? It stalls for the full interval of a getblocktemplate call.

That's the last piece of optimization advice I'm ever giving to anybody concerning ckpool.

It's a byzantine consensus problem all by itself.

That should only be the case in terms of the network consistently receiving the same notifications, not whether our software processes notifications or not. If a block notification happens [locally], it should be processed deterministically?

@pstratem what's the best way to handle this situation? If the getblocktemplate call from the scheduled poll returns an updated template it will get pushed out to miners anyways(shouldn't bitcoind be interrupting CNB and rerunning it if a new block comes in?), I thought CNB is single threaded and that doing simultaneous getblocktemplate calls would not make the second return any faster.

@dcousens blocknotify can fail in a bunch of ways that getblocktemplate calls cannot.

Relying on it for low latency operation is a Bad Idea (tm).

@jameshilliard In any case, in the example that you gave you'll pick up the new work at the 30 second poll; which isn't so unreasonable (it's a 5% capacity loss); especially compared to avoiding parties mining without validation which radically undermines the security assumptions of lite wallets.

A simple heuristic would be to decrease the poll interval to 2 seconds when the current template is under a threshold size... but I expect people don't actually want to issue reissue work that fast in any case.

Alternatively, one can immediately poll GBT again after getting the empty result; and hold off on notifying miners until it results, but use the empty template for any work requests that come in while waiting. @pstratem One thing you could do instead is have a fast argument to GBT that only returns cached or empty templates. (IMO fast should be the default: to do otherwise is to just set a trap for users, but I don't think it's worth arguing with anyone.)

@gmaxwell Current behavior is to queue the notify and issue another GBT request right after the scheduled one finishes, this usually results in two quick stratum updates one right after the other. I think it would be ideal if core would make sure the first one always return updated work that way updates can be pushed out faster since you wouldn't have to wait for the second to return.

but I expect people don't actually want to issue reissue work that fast in any case.

This isn't really an issue for most smaller pools AFAIK.

@gmaxwell it cant be based on a parameter since you dont know whether you want a fast call until you've already made the call

Modified to interact with the long polling code.

Now we will return an empty block only to longpoll callers.

This has the advantage of supporting multiple callers that want an empty template.