Questions about Mining Protocol

[plebhash]

A place for Q&A around the SV2 Mining Protocol

[plebhash]

recently while chatting with @TheBlueMatt he asked:

how does the pool currently spot-check the work miners are mining on? Or can it?
Can it still request the transactions being worked on/get the block template before the block is found?
...
If a pool wants to check that miners are actually mining valid blocks, at least probabilistically

I didn't know the answer, and I've been stuck on this rabbit hole ever since.

I'm particulary curious about the "Future Job" flag on the Mining Protocol.

What if:

• Proxy has speculated on a future template that includes tx A, leading up to Job A (future_job=true).
• Some other pool mines block B, which includes tx A (which cannot be mined again), and triggers a SetNewPrevHash, which triggers Job A downstream.
• Job A is now wasted PoW downstream? For how long?

@Fi3 @rrybarczyk what is your current understanding of this? Also, @TheBlueMatt please feel free to elaborate on your question.

[plebhash]

here's Ocean's Jason Hughes aka @wk057 raising some concerns around that:

https://youtu.be/4BkyhdxnDrM?si=_JP0yWmrnnr2c3a-&t=791 (at 13 min 11 s)

[TheBlueMatt]

The miner should never mine a future job which has a conflicting transaction, and the proxy/pool should never send work referencing a job that had a conflicting transaction. In general this is going to be pretty rare, however, as the job declarator can update future jobs as it identifies CPFPs and always have one ready. Another miner could, of course, deliberately select transaction for their block which are likely to break other miners' future jobs, but they won't gain a hell of a lot in doing so, and future work constructors can respond by introducing more randomness into their future templates, reducing the value of their future templates marginally while making them more likely to work (they can, of course, mix and match and have multiple future templates as well).

[Fi3]

When you send a prev hash you reference the job id, so @plebhash the answer is just not sending prev hash that references future jobs that will result in invalid jobs. You can send 2 future jobs one with very low fee txs for example. (I didn't watched the video)

[plebhash]

@Fi3 I'm re-watching your BTC Prague 2023 presentation.

I'm trying to connect some dots with the SV2 mining protocol spec, where we have:

• on Extended Channels: coinbase = coinbase_tx_prefix + extranonce_prefix + extranonce + coinbase_tx_suffix
• on Standard Channels: coinbase = coinbase_tx_prefix + extranonce_prefix + coinbase_tx_suffix

some questions:

• is it correct to say that coinbase_prefix = scriptSig, containing the BIP34 bytes + pool ASCII signature?
• is it correct to say that extranonce_prefix = "pool reserved bits"?
• is it correct to say that extranonce = "miner reserved bits"?

[Fi3]

this are just very generics slides to help someone that know nothing or very little about mining so take them with a grain of salt.

about yous qs, the answer is yes for all them.

[Fi3]

in sv2 signature is not required to be valid ASCII or any specific encoding