Provide network_receive_minimum in RPC/WS active_difficulty #2903
Conversation
The recommended workflow is using `network_minimum` for any block, specializing with `network_receive_minimum` for receive blocks, and updating with `network_current` to get priority.
On mainnet I get the following response:
```json
{
"multiplier": "1",
"network_current": "fffffff800000000",
"network_minimum": "fffffff800000000",
"network_receive_minimum": "fffffe0000000000"
}
```
guilhermelawless
added
documentation
|
How about a |
|
@PlasmaPower thanks for the suggestion and for the original suggestion of adding this to the RPC (was already in the works, just waiting for epoch 2 to finish 👍). The node applies a function to normalize the prioritization with respect to the block type and even the epoch, so that a receive block doesn't have 10x the priority of a send block with less work generated. Essentially this means |
guilhermelawless
dismissed stale reviews from SergiySW and argakiig
via
71c0b50
|
@PlasmaPower thanks for clarifying via DM, indeed it is possible to take advantage of the normalization to still provide less work for receive blocks and obtain the same priority. Added |
Example response:
```json
{
"multiplier": "1.5",
"network_current": "fffffffaaaaaaaab",
"network_minimum": "fffffff800000000",
"network_receive_current": "fffffff07c1f07c2",
"network_receive_minimum": "fffffe0000000000"
}
```
On mainnet I get the following response:
{ "multiplier": "1.5", "network_current": "fffffffaaaaaaaab", "network_minimum": "fffffff800000000", "network_receive_current": "fffffff07c1f07c2", "network_receive_minimum": "fffffe0000000000" }The multiplier between
network_receive_minimumandnetwork_receive_currentis 33, plugging that into our normalization expression(33 (64 - 1)) / 64yields 1.5 as expected.