A useful mining worker name answers one operational question: which physical machine does this pool record represent? Give each device a distinct worker identifier, then keep the relationship in a private asset register. The name alone is not an inventory, a serial number or evidence of ownership.
This guide is about designing that mapping and maintaining it when equipment moves, is replaced or changes pools. It is not a connection-repair procedure or a claim that renaming a worker improves earnings. The proposed register and examples below are editorial templates, not records from a customer installation.
Worker, account and asset: keep three identities separate
A pool account identifies the destination within a service. A worker distinguishes activity within that account. Your asset record identifies the physical equipment you manage. A useful register links these identities without pretending they are interchangeable.
F2Pool describes separate worker names as a practical way to match each machine with pool-side activity and locate abnormal or offline units. Several machines can also share a name, so a worker count should not automatically be treated as a physical inventory count. F2Pool worker explanation.
For your register, use a stable internal asset key as the anchor. Keep model, serial number, current location and current pool identity in separate fields. This makes a change visible: moving a unit to another rack changes its location, not its history. A replacement chassis should receive its own record rather than silently inheriting the identity of the removed machine.
Choose a naming convention before copying settings
Prefer a short, readable identifier with an explicit relationship to the asset register. For example, fictional asset LM0042 could use worker suffix lm0042. This is an illustration of a convention, not a credential or an instruction to enter that name into your pool.
There are two common design choices for your internal process:
| Proposed convention | Why an operator might choose it | Maintenance responsibility |
|---|---|---|
Stable asset-based suffix, such as lm0042 | The name follows the equipment record | Keep the current location in the register |
Location-based suffix, such as r03u12 | The name helps someone identify a position | Record every move and which unit occupied that position |
| Mixed identifier | The name includes both an asset key and a location hint | Define which part changes and preserve the previous mapping |
These examples do not establish what characters any particular service accepts. Before adopting a convention, check the chosen pool's current rules and the miner interface. Avoid a design that depends on punctuation, length or case behavior that you have not verified.
For a small operation, an asset-based name plus a separate location column is often the simplest editorial choice. For a larger site, agree the convention with the people who actually locate and service equipment. A clever abbreviation that only one person understands creates a different identification problem.
Check pool-specific naming behavior
Braiins documents case-sensitive worker names and a specific permitted-character pattern. Missing or invalid names can be attributed to its automatic worker. It also states that reconnecting a deleted worker name re-enables its previous configuration. These are Braiins-specific behaviors: read the current rules before reusing names or assuming a deletion creates a clean start. Braiins worker management.
Record the pool and account context beside the exact worker spelling. In your register, account A / lm0042 and account B / lm0042 should be distinguishable entries. Do not force an accountant, technician or support contact to guess which dashboard a screenshot came from.
Also distinguish the editable worker suffix from the complete login field required by the service. Our Parasite Pool connection guide covers that service's separate setup format. Its address-based example is not a template to paste into an unrelated account-based pool.
BITMAIN specifically flags spaces and full-width versus half-width symbols as possible worker-name errors. Compare the exact configured text with the intended value when checking a mapping, rather than relying only on how similar two strings look. This is a configuration check, not a reason to reset a whole fleet. BITMAIN pool-connection troubleshooting.
Build a private register that supports a real handover
The following is a proposed minimum record, not a manufacturer-required form. It can be a controlled spreadsheet or an existing inventory system. The important part is that someone owns updates and another person can interpret them.
| Field | What the record should clarify |
|---|---|
| Internal asset key | Which equipment record remains stable over time |
| Model and variant | Which physical version is being discussed |
| Serial reference | Where the verified serial is stored privately |
| Current location | Site, rack or position used by the operations team |
| Pool and account reference | Which service and account contain the worker |
| Exact worker identifier | The spelling actually configured and observed |
| Effective time | When this mapping started, with time zone |
| Previous mapping | What changed, without erasing the earlier record |
| Verification and owner | Who checked the mapping, when, and where evidence is stored |
Use references to private records instead of embedding passwords, API tokens or wallet secrets in a shared worksheet. Limit serial and customer information to people who need it. The public worker label does not need to contain a customer's name, telephone number or delivery address.
A register is also not proof that equipment is online. Include a verification date so that an old mapping is visibly old. Keep the current mapping and operational status separate; otherwise an inventory edit may look like a successful mining check even though nobody inspected the device.
Introduce or rename workers in a controlled batch
Start with one identified unit. Preserve its existing configuration privately, record the intended change, then follow the relevant miner and pool instructions. Avoid combining a naming cleanup with pool migration, firmware work and performance tuning.
After applying the change, compare the configured identity with fresh activity in the intended account. Write down what you observed and the time of the check. Do not mark every row verified because one representative unit appeared successfully. For additional units, repeat the identity check and record exceptions individually.
If several machines currently share a worker, plan how their identities will be separated before changing them. Keep the old group record as historical context. Do not retroactively assign its aggregate history to one newly named unit. For interpreting performance figures across those periods, see miner hashrate versus pool hashrate.
Preserve history through moves and replacements
When a machine moves, update the location and effective time. If your convention includes location, record both old and new worker names. When equipment is replaced, close the old mapping and create a new one for the replacement. Reusing a rack position should not erase which machine previously occupied it.
When switching pools, retain a dated mapping for each service. Treat the register update and confirmation of activity as separate tasks. If the expected worker does not appear, pause the rollout and use the network-outage connection checklist to organize the next investigation; repeated renaming is not a diagnosis.
For a hosting handover, agree which party maintains the register and how changes are reported. Ask for a current, attributable equipment list rather than assuming dashboard access proves the identity or ownership of every machine. Contact LeedMiner to discuss the equipment information needed for a miner or hosting inquiry; share sensitive records privately.
