How to Pin Stratum Authority Keys for Miners

A miner can receive accepted-share messages from the wrong server. Encryption alone does not prevent that if the client has no trusted identity for the server it intended to reach. When you pin Stratum authority keys, you give your mining client a specific public-key identity to expect. If the other side cannot prove it holds the matching private key, the connection should fail.

That is a meaningful boundary for a home miner. DNS can be redirected. A local network can be hostile. A compromised router can point a familiar hostname somewhere else. None of those events changes your hardware's hashrate display immediately. A pinned authority key gives the miner one test that is harder to fake: prove you are the operator whose key I chose.

What an authority-key pin actually changes

A public key is not a password. It is meant to be shared. The private key behind it is the secret. Pinning records the public half, or a fingerprint derived from it, in the client configuration. During a Stratum V2 connection, the client checks cryptographic identity material presented by the server against the pin it already has.

If the identity does not match, a correctly configured client does not treat this as a minor warning. It refuses the session. That is the point. A connection that works after an unexpected identity change is convenient, but it is not pinned in any useful sense.

The exact handling depends on the Stratum V2 implementation and the authority-key support it exposes. Do not assume every public key associated with a pool is interchangeable. A website signing key, a payout-proof key, a Noise static key, and a Stratum authority key may have different purposes and formats. Use the key and pin format documented for the specific Stratum endpoint and client version you run.

This is also why a hostname is not an identity guarantee. A hostname tells your miner where it was told to connect. A pinned key tells it which cryptographic authority answered.

Pin Stratum authority keys before first connection

The safest time to establish a pin is before your miner sends meaningful work anywhere. Once a machine has been trained to accept whatever key it sees first, a network attacker present at that moment can become the identity your miner remembers. That is trust on first use. It can be acceptable for some local systems, but it is weaker than comparing a published key through an independent channel.

Get the full key from a source you can check

Start with the pool's published Stratum V2 authority key, not a key pasted into a chat message or copied from an error log. Record the complete value exactly as the client expects it. If the operator publishes a fingerprint, compare that too, but do not substitute a short fingerprint for the full key when your software supports the full value.

A fingerprint is useful for human comparison. The complete public key is what gives the client a precise identity target. A single changed character should cause a failed comparison, not a quiet fallback.

At NexusPool, the relevant question is not whether a dashboard says your worker is online. It is whether the endpoint proves the authority identity you configured before it receives your hash rate. That distinction matters most when you cannot personally inspect the network path between your miner and the pool.

Put the pin in the client, proxy, or firmware that speaks V2

Where you configure the pin depends on your setup. A native Stratum V2 miner may expose an authority-key field in its pool configuration. A V2 translation proxy may hold the pin instead, because it is the component negotiating V2 upstream. Read the configuration labels carefully. A generic TLS certificate option is not necessarily a Stratum authority-key setting.

For home-mining hardware, this distinction is practical. Bitaxe units running firmware with native Stratum V2 support can use the protocol directly when their firmware supports key pinning. Many standard ASICs still speak Stratum V1. They can connect to a pool's V1 service without a translator, but that V1 connection does not become an authority-pinned V2 session by changing the pool URL.

If you place a translator between a V1 ASIC and a V2 pool, the translator becomes part of your security boundary. Pin the upstream authority key there. Then protect the local link between ASIC and translator according to where they run. A translator on the same trusted LAN presents a different risk than one on a shared host or remote server.

Test failure before relying on it

Do not stop at a green status indicator. Make a copy of the configuration, replace one character of the pin in the copy, and test it during a maintenance window. The connection should fail with an identity, authority, or key-verification error. Restore the correct value and confirm that it reconnects.

This test answers a question documentation cannot answer for your exact firmware build: is the pin actually being enforced? Some clients display a field but do not enforce it in every transport mode. Others distinguish between a warning, a first-use enrollment event, and a hard failure. Find out before a DNS problem finds out for you.

Keep a local record of the following: the endpoint hostname, port, full authority key, the software version that accepted it, and the date you verified it. This is not bureaucracy. It gives you a known-good baseline when you update firmware, move a proxy, or troubleshoot a failed connection later.

What pinning proves, and what it cannot prove

Authority-key pinning addresses server identity at connection time. It helps prevent a party with control over name resolution or network routing from impersonating the expected Stratum authority without the private key. It also makes accidental connection to an unintended endpoint easier to detect.

It does not prove every property of pool operation. It does not prove that a proposed block template is valid. It does not prove how a pool accounts for shares. It does not make solo mining less variable. It does not protect a compromised miner whose configuration has already been altered to trust an attacker's key.

Those limits are not a reason to skip pinning. They are a reason to describe it honestly. Security controls have scopes. A pin verifies the identity expected at the protocol boundary. Bitcoin validates blocks. Your own payout address and on-chain transaction verification address payment ownership. Each check covers a different claim.

There is a trade-off. A fixed pin can interrupt mining when an operator legitimately rotates keys. That interruption is preferable to silently accepting a new identity, but it means you need an update process. Miners who value unattended operation sometimes configure broad trust rules to avoid outages. They are choosing availability over identity assurance. Make that choice consciously.

Handle key rotation as a security event

An authority key should not change casually. If it does, treat the change as an event that needs verification, not as a support ticket to clear as quickly as possible. Check the operator's announced replacement key through more than one available channel. Compare the full new value. Confirm whether the old key remains valid during a transition and whether your client supports multiple pins.

Update a small number of miners first. Verify the new connection and inspect logs for the expected identity result. Then update the rest of the fleet. Keep the old configuration until the change is complete, but do not leave an obsolete key enabled indefinitely if the documented rotation process says it has been retired.

A legitimate rotation can happen after planned operational changes or a suspected key compromise. The proper response is not panic. It is verification. An unexplained key mismatch is exactly what a pin is supposed to surface.

Make the check part of normal miner operations

For one Bitaxe on a shelf, pinning may take minutes. For a rack of ASICs behind a translator, it belongs in your configuration management. Store the expected key alongside your endpoint settings. Back up the working configuration offline. Review it after firmware updates. If a device suddenly reports a different authority identity, stop treating that as an ordinary connectivity issue.

The practical benefit is simple. Your miner should not hand work to a server just because it answered first and used a familiar name. It should require the identity you selected.

Trust nothing. Verify the authority key.