`channel_msg` bit for `NewMiningJob` message is wrong

[lucasbalieiro]

The spec is setting the channel_msg bit to 0 for the NewMiningJob message. But we can see in the message definition that it needs to be sent to a specific channel. So, the channel_msg bit should be 1:

sv2-spec/08-Message-Types.md

Line 16 in 5b5eb4a

| 0x15 | 0 | NewMiningJob |

sv2-spec/05-Mining-Protocol.md

Lines 389 to 401 in 5b5eb4a

	### 5.3.15 `NewMiningJob` (Server -> Client)
	The server provides an updated mining job to the client through a standard channel. This MUST be the first message after the channel has been successfully opened. This first message will have min_ntime unset (future job).
	If the `min_ntime` field is set, the client MUST start to mine on the new job immediately after receiving this message, and use the value for the initial nTime.
	| Field Name | Data Type | Description |
	| ----------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
	| channel_id | U32 | Channel identifier, this must be a standard channel |
	| job_id | U32 | Identifier of the job as provided by NewMiningJob or NewExtendedMiningJob message |
	| min_ntime | OPTION[u32] | Smallest nTime value available for hashing for the new mining job. An empty value indicates this is a future job to be activated once a SetNewPrevHash message is received with a matching job_id. This SetNewPrevHash message provides the new prev_hash and min_ntime. If the min_ntime value is set, this mining job is active and miner must start mining on it immediately. In this case, the new mining job uses the prev_hash from the last received SetNewPrevHash message. |
	| version | U32 | Valid version field that reflects the current network consensus. The general purpose bits (as specified in BIP320) can be freely manipulated by the downstream node. The downstream node MUST NOT rely on the upstream node to set the BIP320 bits to any particular value. |
	| merkle_root | U256 | Merkle root field as used in the bitcoin block header |

[warioishere]

Hit this in production today. A BraiinsOS S19kPro (bosminer-plus-tuner 0.9.0) connecting to my SV2 pool: SetupConnection and OpenStandardMiningChannel.Success go through fine, then bosminer drops the first NewMiningJob with:

WARN bosminer::client::stratum_v2:
  Header { is_channel_message: false, extension_type: 00, msg_type: 15, msg_length: 2d }
  error=Unknown message type [0] from stratum v2 extension [21]

Pool was sending the frame with channel_msg=0 per the spec table. Setting it to 1 (matching CHANNEL_BIT_NEW_MINING_JOB = true in the SRI Rust reference) made the miner accept the job immediately. Extended-channel miners weren't affected because NewExtendedMiningJob is correctly marked channel_msg=1 already.

Could also be that we're misreading the spec rather than the spec being wrong — happy to be corrected. But empirically the bit needs to be 1 for the message to route, which is consistent with the structural argument in this issue (first payload field is channel_id).

Same flavor of doc/impl mismatch appears for PushSolution (§6.4.9 lists payload field order nonce, ntime; SRI's push_solution.rs has them as ntime, nonce — wire matches SRI). Different message, same kind of thing; happy to open a separate issue for that one if useful.

[plebhash]

SetCustomMiningJob is also wrong:

sv2-spec/08-Message-Types.md

Lines 29 to 31 in 5b5eb4a

	| 0x22 | 0 | SetCustomMiningJob |
	| 0x23 | 0 | SetCustomMiningJob.Success |
	| 0x24 | 0 | SetCustomMiningJob.Error |

[GitGab19]

@warioishere thanks for signalling this, I just opened a PR which fixes the channel_msg bit of NewMiningJob: #196

While doing that, I noticed that the channel_msg bit was wrongly set to 1 for the PushSolution message, which doesn't have any reference to any channel. So my PR also fixes that.

Same flavor of doc/impl mismatch appears for PushSolution (§6.4.9 lists payload field order nonce, ntime; SRI's push_solution.rs has them as ntime, nonce — wire matches SRI). Different message, same kind of thing; happy to open a separate issue for that one if useful.

About this, I think we need to fix it on the implementation side, and not change the specs. Please @plebhash let me know what you think of this.

[GitGab19]

SetCustomMiningJob is also wrong:

sv2-spec/08-Message-Types.md

Lines 29 to 31 in 5b5eb4a
| 0x22 | 0 | SetCustomMiningJob |
| 0x23 | 0 | SetCustomMiningJob.Success |
| 0x24 | 0 | SetCustomMiningJob.Error |

I'll push a new commit to #196 to fix it.

Done: fbf87d8