fix channel_msg bit for NewMiningJob, PushSolution, SetCustomMiningJob, SetCustomMiningJob.Success, and SetCustomMiningJob.Error

[GitGab19]

This PR fixes the channel_msg bit for NewMiningJob, PushSolution, SetCustomMiningJob, SetCustomMiningJob.Success, and SetCustomMiningJob.Error messages.

Closes #185

[plebhash]

stratum needs to be fixed accordingly: stratum-mining/stratum#2150

[Sjors]

This doesn't impact the TP, right?

[GitGab19]

This doesn't impact the TP, right?

Nope, no TDP message is involved here, all good on that end.

[coleFD]

Does SetGroupChannel need the channel_msg bit set? It is technically has a 4 byte channel id as the first field of the message.

It's hard to say because I don't see where the channel_msg bit is even used in the implementation, but maybe I am missing it. Either way, I don't see why it is necessary to begin with since each message that requires a channel_id has the field defined in the associated struct, and the channel_id gets deserialized regardless through the Deserialize implementation. So in practice the 8-bit message_type alone suffices.

[plebhash]

Does SetGroupChannel need the channel_msg bit set? It is technically has a 4 byte channel id as the first field of the message.

hmm I guess that depends on how you define what a Channel really is

I mean yeah sure Group Channels have the word "Channel" in their names, but ultimately a client never really submits shares to a Group Channel

It is only an abstraction that helps broadcasting messages to multiple (actual) Channels

---

channel_msg bit encodes semantics about the message/frame routing context

an elaborate Sv2 Proxy might maintain the same Channel state across 2 different Connections (downstream and upstream)

when a message/frame's channel_msg bit is 1, that means its not necessarily only meant to be interpreted by the immediate receiver (the Proxy in this scenario), and it might need to keep traveling over more hops

if channel_msg bit is 0, the message/frame only has meaning on the context of the Connection, and it's meant to be interpreted by the immediate receiver

and SetGroupChannel can only carry meaning across the context of one specific Connection, therefore IMO channel_msg being 0 is appropriate, despite the fact that the message frame carries a group_channel_id

---

It's hard to say because I don't see where the channel_msg bit is even used in the implementation

SRI crates like framing_sv2 and parsers_sv2 do provide primitives for it

indeed it is not actively used for anything meaningful on sv2-apps, but it could potentially be used for more complex proxy implementations that would keep track of multiple Channels across different Connections at the same time

[Fi3]

ack

[coleFD]

ack