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?

[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

[plebhash]

I had to re-read this discussion while working on #121 and now I'm revisiting it, as it's important to clarify a few points

previously on this thread @TheBlueMatt said:

I also don't really get why DeclareMiningJob uses a coinbase_tx_prefix and coinbase_tx_suffix rather than the same fields from SetCustomMiningJob (i.e. coinbase_tx_version, coinbsae_prefix, coinbase_tx_input_nSequence, coinbase_tx_value_remaining, coinbase_tx_outputs, and coinbase_tx_locktime).

that used to be the case, but this was changed on this commit 9b0e40b

IMHO I find this commit quite problematic since:

• it doesn't belong to any PR (seems to be made over Github UI?)
• it doesn't provide any context to that motivated this change
• it introduced inaccurate/nonsensical descriptions for coinbase_tx_prefix and coinbase_tx_suffix

so a few questions for @Fi3:

• what motivated this change?
• how can JDS assert for correctness of fee revenue?
• how can JDS assert for correctness of payouts?

[plebhash]

• how can JDS assert for correctness of fee revenue?
• how can JDS assert for correctness of payouts?

perhaps this is based on the assumption that JDS can de-serialize coinbase_tx_prefix and coinbase_tx_suffix?

but then the question becomes: why don't we have the same assumption for SetCustomMiningJob?