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

[plebhash]

from the current definition of SetCustomMiningJob:

Can be sent only on extended channel.

• Why do we have this restriction?
• Is this a fundamental restriction?

And most importantly:

• Why can't we have Custom Jobs over Standard Channels?

[plebhash]

when you're saying that Standard Channels incur in more bandwidth consumption, are you referring to multiple NewMiningJob vs one single NewExtendedMiningJob arriving into a Proxy?

my counter arguments to that would be:

• NewExtendedMiningJob messages can be sent over Standard Channels (they only need to belong to a Group Channel)
• all NewMiningJob messages are constrained to the LAN environment of the miner, so this optimization of one message vs multiple only applies over the Internet

on the other hand, (I assume) SubmitSharesStandard can ONLY be sent over Standard Channels, but currently the spec only allows for JDC to establish Extended Channels with the Pool

and being forced to send SubmitSharesExtended (which carries extra data with extranonce) from JDC to Pool incurs in increased network traffic over the Internet, which is the main point I'm trying to clarify here

[plebhash]

it's worth to point out that one feedback we're getting from adopters is that they want the Pool to be able to have granular data over Workers (Mining Devices)

if we were to aggregate hashrate on JDC and only submit high difficulty shares via SubmitSharesExtended (as a bandwidth optimization technique), this kind of granularity would be lost

[TheBlueMatt]

I do wonder if that's not better done with some "worker info" extension/message rather that submitting actual shares, but that's a pretty separate conversation.

[GitGab19]

I do wonder if that's not better done with some "worker info" extension/message rather that submitting actual shares, but that's a pretty separate conversation.

That's what I started to create as a draft here: https://github.com/GitGab19/sv2-spec/blob/set-user-identity/user-identity-extension.md. Will keep you posted about that.
Related to this, I know it's a tiny detail, but I really don't understand why we couldn't use the common worker_name or worker_identity instead of the current user_identity which doesn't follow the current mining scenario and doesn't sound like a good thing :)

[plebhash]

yeah after some discussions with @GitGab19 I also arrived to this conclusion that an extension is the best course of action

[plebhash]

definition of SetCustomMiningJob has a field called min_ntime, where the description is:

TBD: Can custom job ever be future?

We should take #98 as an opportunity to fix that.

I believe Custom Jobs can be future. Were there any discussions around this?

[GitGab19]

We never discussed properly about this. I don't think we could have them btw, since a prev-hash is required in the SetCustomMiningJob.

[Fi3]

I don't thing that having a future SetCustomMiningJob make much sense. You can handle future and non future jobs at proxy level. When you need to mine on a future job the proxy will immediately send the job downstreams and in the meantime will start the job declaration procedure. As soon as the jd procedure is ok will send the job with SetCustomMiningJob. Note that we will not have any delay from when the proxy know that we need to mine a job to when the miners will start mine.

[plebhash]

ok thanks, I will fix this field description on #98 to make it clear that future jobs are not an option in this message.

[plebhash]

SetCustomMiningJob has a coinbase_prefix field which is type B0_255.

NewExtendedMiningJob has a coinbase_tx_prefix field which is type B0_64K, which is the same for DeclareMiningJob.

why are we using different types for representing the same kind of data?

or are those fields representing different things, despite their almost identical names?

[Fi3]

I was answering to prev comment by gitgab then started doing another thing and didn't see that conversation further evolved

[Fi3]

IMO we should provide a set of outputs and a payout script. The outputs are copied as-is without modification as the first outputs in the coinbase tx, then the payout output is added with any remaining values, followed by any the miner wants to add (incl the segwit commitment).

Can you provide an example of how the tokenSuccess message should look like?

What isn't clear to me is if the SetCustomMiningJob.coinbase_tx_outputs includes all outputs or just a subset (I imagine all, but the description text needs to be rewritten).

I think all cause the pool need them to verify the share's validity

[TheBlueMatt]

Can you provide an example of how the tokenSuccess message should look like?

Question to me is basically should we add a new field (payout_script_pubkey I guess) or just keep the existing one and have some kind of special case for the first/last output to be "the one that gets the payout".

[TheBlueMatt]

The new field approach is maybe a bit cleaner, but the special-case approach means we don't have to change the spec too much and mostly just write out more text and handle the case of more outputs.

[Fi3]

I would go with the latter