F32 is not defined in the specs

[lucasbalieiro]

we can see that f32 is not listed in Data Types Mapping list: https://github.com/stratum-mining/sv2-spec/blob/main/03-Protocol-Overview.md#31-data-types-mapping

But this type is used in messages like OpenStandardMiningChannel::nominal_hash_rate :

sv2-spec/05-Mining-Protocol.md

Lines 223 to 228 in 83799d3

	| Field Name | Data Type | Description |
	| ----------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
	| request_id | U32 | Client-specified identifier for matching responses from upstream server. The value MUST be connection-wide unique and is not interpreted by the server. |
	| user_identity | STR0_255 | Unconstrained sequence of bytes. Whatever is needed by upstream node to identify/authenticate the client, e.g. "braiinstest.worker1". Additional restrictions can be imposed by the upstream node (e.g. a pool). It is highly recommended that UTF-8 encoding is used. |
	| nominal_hash_rate | F32 | [h/s] Expected hashrate of the device (or cumulative hashrate on the channel if multiple devices are connected downstream) in h/s. Depending on server's target setting policy, this value can be used for setting a reasonable target for the channel. Proxy MUST send 0.0f when there are no mining devices connected yet. |
	| max_target | U256 | Maximum target which can be accepted by the connected device or devices. Server MUST accept the target or respond by sending OpenMiningChannel.Error message. |

[TheBlueMatt]

Ugh, floats in a wire format really suck. Is there some way to avoid using floats here instead? Maybe switching to order-of-magnitude hashrate listing (ie log scale)?

[plebhash]

it's been on the spec since the beginning 24302f7

so it looks like maybe it was a deliberate decision, but just lacks formal definition

I'd say we have two alternatives:

• [non-breaking] introduce a formal definition for F32 type
• [breaking] replace with some integer-based alternative approach (tbh log scale feels interesting)

[TheBlueMatt]

Ugh. I mean we could specify it as IEEE but its certainly annoying (infinite hashrate? negative zero hashrage? NaN hashrate?) but maybe the simplest thing to do.

[plebhash]

@Shourya742 pointed out on dev call that IEEE-754 is what Rust does, which is what DMND does and I assume also Braiins and whoever else that uses SRI

so this feels like the right thing to do

it will need to be a bit verbose, because indeed we will have to forbit all the nonsense edge-cases

[plebhash]

@jakubtrnka can you confirm Braiins follows IEEE-754?

[jakubtrnka]

@plebhash Yes, we do use IEEE 754