Skip to content

Commit

Permalink
replace miner with hasher terminology
Browse files Browse the repository at this point in the history
  • Loading branch information
@plebhash
plebhash committed Oct 14, 2024
1 parent bce5fa3 commit 0d08032
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions 05-Mining-Protocol.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@

The Mining Protocol is used to distribute work to Mining Devices, and it's also how they submit their proof of work.

It can be used without Job Declaration and Template Distribution Protocols, where a subset of the messages are used by a pool to unilaterally distribute work to miners.
It can be used without Job Declaration and Template Distribution Protocols, where a subset of the messages are used by a pool to unilaterally distribute work to hashers.

Alternatively, it can be used in conjunction with Job Declaration and Template Distribution Protocols, where both pool and miners coordinate to decide what is valid work.
Alternatively, it can be used in conjunction with Job Declaration and Template Distribution Protocols, where both pool and hashers coordinate to decide what is valid work.

## 5.1 Jobs

Expand All @@ -22,8 +22,8 @@ The other portion of the block header that is used to define the full search spa
- Transaction set: practically unbounded space.

All roles in Stratum v2 MUST NOT use transaction selection/ordering for additional hash space extension.
This stems both from the concept that miners/pools should be able to choose their transaction set freely without any interference with the protocol, and also to enable future protocol modifications to Bitcoin.
In other words, any rules imposed on transaction selection/ordering by miners not described in the rest of this document may result in invalid work.
This stems both from the concept that hashers/pools should be able to choose their transaction set freely without any interference with the protocol, and also to enable future protocol modifications to Bitcoin.
In other words, any rules imposed on transaction selection/ordering by hashers not described in the rest of this document may result in invalid work.

Mining servers MUST assign a unique subset of the search space to each mining device, otherwise the mining devices will waste energy with overlapping search.

Expand Down Expand Up @@ -348,7 +348,7 @@ The message is the same as `SubmitShares`, with the following additional field:

### 5.4.13 `SubmitShares.Success` (Server -> Client)

Response to `SubmitShares` or `SubmitSharesExtended`, accepting results from the miner.
Response to `SubmitShares` or `SubmitSharesExtended`, accepting results from the hasher.
Because it is a common case that shares submission is successful, this response can be provided for multiple `SubmitShare` messages aggregated together.

| Field Name | Data Type | Description |
Expand All @@ -366,7 +366,7 @@ It is the client’s responsibility to keep the sequence numbers correct/useful.

An error is immediately submitted for every incorrect submit attempt.
In case the server is not able to immediately validate the submission, the error is sent as soon as the result is known.
This delayed validation can occur when a miner gets faster updates about a new prevhash than the server does (see `NewPrevHash` message for details).
This delayed validation can occur when a hasher gets faster updates about a new prevhash than the server does (see `NewPrevHash` message for details).

| Field Name | Data Type | Description |
| --------------- | --------- | ----------------------------------------------------------- |
Expand All @@ -391,7 +391,7 @@ If the `min_ntime` field is set, the client MUST start to mine on the new job im
| ----------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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. |
| 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 hasher 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 | B32 | Merkle root field as used in the bitcoin block header |

Expand All @@ -415,7 +415,7 @@ A proxy MUST translate the message for all downstream channels belonging to the
| ----------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| channel_id | U32 | For a group channel, the message is broadcasted to all standard channels belonging to the group. Otherwise, it is addressed to the specified extended channel. |
| job_id | U32 | Server’s identification of the mining job |
| 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. immediately. |
| 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 hasher must start mining on it immediately. In this case, the new mining job uses the prev_hash from the last received SetNewPrevHash message. immediately. |
| version | U32 | Valid version field that reflects the current network consensus |
| version_rolling_allowed | BOOL | If set to True, the general purpose bits of version (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. If set to False, the downstream node MUST use version as it is defined by this message. |
| merkle_path | SEQ0_255[U256] | Merkle path hashes ordered from deepest |
Expand Down

0 comments on commit 0d08032

Please sign in to comment.