Braidpool Extension

[plebhash]

a place for discussions around a potential SV2 extension for Braidpool

[plebhash]

during the review of #98 @mcelrath pointed out said the following about Future Jobs:

... when a block (or share) is found, within Braidpool we have to update more than just prev_hash. We also have to update DAG parents, and possibly our metadata. If we assume all that is encoded in some TX somewhere in the Merkle tree (e.g. an OP_RETURN or pubhash tweak) we would need to update that as well.

... I think providing a new prev_hash and full coinbase tx would do it.

that means that SetNewPrevHash is not sufficient and a new message will be required to trigger Future Jobs for Braidpool

[plebhash]

this could be an interesting optimization, but I wonder if this is a strict requirement for a Braidpool MVP that still leverages SV2?

every time braidpool-node needs to update the jobs for its downstreams, can't it simply send a fresh NewExtendedMiningJob or NewMiningJob to them?

[mcelrath]

I think (correct me if I'm wrong) the idea here is to pre-announce a "next block" so that miners can start mining more or less immediately when a block is found (by us), avoiding computational latency on the SV2 (or braidpool) server/proxy. (For instance, when the block wasn't mined by us and the tx set may conflict with the "next block").

Just thinking out loud..., a message MineFutureJob from the server could tell the miner to mine the previously announced FutureJob and any extra data would need to be a payload of the MineFutureJob message, including prev_hash. For braidpool, for now, I'm assuming that replacing the coinbase tx will allow us to include all (cheaply computable) updates, including DAG/braid parents. Parent beads are very cheaply computable, and committed metadata should also be cheaply computable. (I put "committed metadata" in the spec but the exact contents of this are as-yet undecided, but may contain FROST signing ceremony consensus checkpoints as the most important other thingy) Ping @pool2win for more on that.

This all presumes that the mining device already knows what it's corner of nonce space is for FutureJob, which is a fairly nontrival question in itself. Presumably it's exactly the same nonce space as the previous block.

Where this optimization fails is when there's latency on the server (recomputing the tx set) or network latency to the server is high (so you've failed at decentralization).

One thing in the back of my mind is that if connections to mining ASICs use a broadcast mechanism (multicast or UDP) rather than a pairwise TCP connections, this saves a ton of bandwidth and back-and-forth acks and their implicit latency. If announcement of a successful solution is also a broadcast that all mining devices in the cluster can see (because, multicast), and the update is cheaply-enough computable by the mining device itself (e.g. replacing prev_hash and coinbase) we can avoid having to talk to the server at all in this circumstance.

I think this is a rather small optimization. If you have mining servers on-site we're talking milliseconds to let the server send a MineFutureJob message. So if it takes 10ms for that we're talking a 0.002% efficiency improvement. Having typed all that out, it's clearly not worthwhile to have mining devices do this. But let's consider a MineFutureJob message with whatever payload is necessary.

That said, I like thinking of small optimizations that make SV2 and Braidpool's solutions economically better. We're going to squeeze 1% here and 1% there but it can add up.