Once upon a nonce..
It’s become clear to me that, despite two months of publicly addressing this issue and explaining that I’ve developed and patented a tech solution to combat nonce spamming, including competing cryptocurrency developers, mining pools, and content creators are still completely confused. Personally I don’t want to chat about this constantly with different people!
Lets start with the fact, that this problem exists and the feasibility can be argued for every cryptocurrency. Bigger hashrate protects the cryptocurrency's network, because valid block finding becomes harder.
It may be argued that nonce-spamming will require doing the pow calculations for validation. It is about who does the calculations. Is it the nonce-spammer or the network where nonce-spammer submits packets?
The real problem:
A Bitcoin or any Proof of Work miner only needs to submit a nonce & (worker id, job id, extranonce2, ntime) to the node. As a result, the node cannot verify the actual work performed by the miner, it can only recompute the hash using the given nonce’s to check if it meets the required criteria.
This issue also extends to pooled mining, introducing additional vulnerabilities. However, the core problem is not just limited to mining pools; it is a network-wide flaw in the PoW validation itself.
The search space:
In bitcoin mining the search space is nonce, extranonce1, extranonce2 and ntime.
- Nonce, 32 bits is the main iterative data on the PoW algorithm.
- Extranonce 1, variable length, but usually 32 bits to 64 bits is decided by the pool for the miner to divide nonce search space between miners.
- Extranonce 2, variable length, but usually 32 bits to 64 bits is decided by the miner and incremented if the valid pow hash can not be found from the nonce search space.
- ntime, 32 bit representation of current time.
Educational Example:
Below is a minimal nonce-spamming python script (Untested & generated by ChatGPT for the article), illustrating how a malicious actor can exploit this weakness to generate blocks without the intended PoW algorithm. We assume that we only need to brute-force the nonce, because this affects more slow algorithm coins.
import socket
import json
import time
# Stratum server details (replace with your target server)
HOST = "your-mining-pool.com"
PORT = 3333
USERNAME = "your_username"
PASSWORD = "your_password"
def recv_json(sock):
"""Receive JSON data from the Stratum server."""
data = b""
while True:
chunk = sock.recv(1024)
if not chunk:
break
data += chunk
if b"\n" in chunk:
break
return json.loads(data.decode())
def send_json(sock, message):
"""Send a JSON message to the Stratum server."""
sock.sendall((json.dumps(message) + "\n").encode())
def connect_to_stratum():
"""Connects to the Stratum server and subscribes to jobs."""
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((HOST, PORT))
print(f"Connected to {HOST}:{PORT}")
# Subscribe to mining jobs
send_json(sock, {"id": 1, "method": "mining.subscribe", "params": []})
response = recv_json(sock)
print(f"Subscribed: {response}")
# Authenticate
send_json(sock, {"id": 2, "method": "mining.authorize", "params": [USERNAME, PASSWORD]})
response = recv_json(sock)
print(f"Authenticated: {response}")
return sock
def main():
"""Main loop to get jobs and submit sequential nonces."""
sock = connect_to_stratum()
job = None
nonce = 0
while True:
response = recv_json(sock)
if "method" in response and response["method"] == "mining.notify":
job = response["params"]
print(f"New job received: {job}")
nonce = 0 # Reset nonce when a new job arrives
if job:
# Submit sequential nonces
send_json(sock, {
"id": 3,
"method": "mining.submit",
"params": [USERNAME, job[0], job[1], f"{nonce:08x}", job[2], job[3]]
})
nonce += 1
if nonce >= 2**32:
nonce = 0 # Wrap around after max nonce
time.sleep(0.01) # Adjust delay to control spam rate
if __name__ == "__main__":
main()The educational example:
- Does not respect pool or network difficulty.
- Does not run PoW algorithm.
- Only spams packets with nonce's.
Nonce spamming encounters a significant challenge with mining pools, it’s largely ineffective. Pools have built-in defenses against nonce spamming, which renders the script unusable in most cases. Since the script generates an overwhelming number of invalid nonce’s at an extremely high rate, any reputable public mining pool will detect and ban it almost instantly.
However, if you set up your own pool and disable these defenses, you could spam the node behind the Stratum pool with nonce’s. For instance, the Kaspa Stratum Bridge doesn’t have these banning mechanisms, aside from validating the nonce before submitting it to a pool. If you remove the nonce validation from the Stratum protocol, you could directly spam the node.
In this scenario, your only limitation would be the node’s processing power to validate the nonce's. But let’s take it further: if you remove nonce validation from your mining node and connect it to a network of nodes, you could effectively spam nonce's to this network of nodes to handle the processing for your blocks.
The real problem lies in the possibility of generating valid blocks without performing the actual computational work!
Get Hoosat Network’s stories in your inbox
Join Medium for free to get updates from this writer.
This is incredibly dangerous and has major security implications. It highlights a potential vulnerability in every PoW cryptocurrency that can be exploited on a large scale and it is being exploited!
How This Issue Extends to Pooled Mining
Malicious actors have identified a significant vulnerability. it’s possible to generate a large number of acceptable nonce’s using the wrong algorithm.
In a typical mining setup, a miner runs the Proof of Work (PoW) algorithm, validates the work, and then submits the nonce to the Stratum server. This process helps filter out many invalid nonce's generated by the miner’s algorithm.
This may not be feasible for Bitcoin because of the high network hashrate. This is serious problem for slow algorithms proof of work cryptocurrencies, which can be attacked easier with nonce-spamming like we’ve seen that Kaspa CPU and GPU forks which are constantly mined with kHeavyHash ASICs.
Now, consider a kHeavyHash ASIC miner targeting a slower cryptocurrency, which we’ll refer to as Sathash. When we start the ASIC, we begin spamming nonce's intended for Sathash. Since we’re using the wrong algorithm (kHeavyHash instead of Sathash), many invalid nonce's are filtered out. However, we still end up submitting both valid and invalid nonce’s. The crucial point here is that the ratio of invalid nonce’s is significantly reduced due to the similarity between how kHeavyHash and Sathash handle the nonce in their algorithms.
This issue is particularly problematic when it comes to pool payment schemes. Even if you can’t generate valid blocks, you can still produce acceptable nonce’s. In essence, an acceptable nonce is same as a share. Pools use these nonce’s to calculate your share of the work done in finding blocks. So, by submitting a high volume of acceptable nonce’s, you can get paid, even without actually finding a valid block.
This phenomenon is already present in many slower algorithm-based cryptocurrencies. Some mining pools have put measures in place to mitigate this, while others have found ways to take advantage of it.
The pool difficulty is not related to the issue. It’s the fact that faster and wrong algorithm can submit more nonce’s than supposed algorithm. The misunderstanding comes from the fact that lower pool difficulty can be used to submit nonce’s faster with the correct algorithm.
The issue is even more concerning in the context of merged mining. Since merged mining is possible because of the same reason why nonce spamming is possible. In merged you mine one cryptocurrency and when you find acceptable nonce for the cryptocurrency it will be submitted also for the secondary cryptocurrency using same algorithm. Because of the same algorithm the nonce can create valid block on the secondary cryptocurrency. This creates significant risks for both pool security and the overall health of the network. Bad acting pool could be doing this even without the miners knowing.
It is impossible for pool to distinguish between algorithms, because only nonce's are submitted to stratum. Pool can basically distinguish only between between invalid and valid nonce’s submitted for cryptocurrency’s algorithm. Though if you think about using “stratum to stratum bridge” to filter out the all of the invalid nonce’s you will be doing the PoW calculations.
Known nonce spamming methods
Any machine submitting nonce’s can do this.
- Basic brute-force, like above python script.
- Faster wrong algorithm machine.
- Grover’s algorithm which is Quantum brute-force.
You could use heuristic, replay attacks and other methods to attack the problem also. That is up to the bad actors finding the most optimal way to take advantage of the problem.
Closing Thoughts
The vulnerabilities I’ve outlined here aren’t just theoretical , they’re real, they exist, and they’re being exploited right now. The ability to generate valid blocks without doing the actual computational work, or to manipulate pool payment schemes through nonce spamming, represents a major threat to the integrity of Proof of Work (PoW) systems.
Despite the awareness, even with a patented solution that addresses this issue, there is still a large gap in understanding and action across the community. Pools, miners, and developers alike need to face this problem head-on. The exploit isn’t just a nuisance; it’s a ticking time bomb that can weaken entire networks, disrupt mining fairness, and, ultimately, compromise the security of cryptocurrencies built on PoW.
If we don’t take these vulnerabilities seriously and address them now, we risk creating an ecosystem where bad actors thrive, and the very foundation of decentralized trust is undermined. It’s time for the mining community to unite and build better defenses, educate those who still don’t understand the problem, and prevent the potential chaos that could arise from a system designed to work against us.
The question remains: how long will it take before the community as a whole realizes the true scale of this issue and acts on it? Until then, those of us who understand the risk must continue to raise awareness and push for solutions. The nonce spammer problem is not going away on its own.
Hoosat Networks solution “Securing Proof-of-Work integrity” patent filing have been done in EU and US, it has been implemented in Hoosat Network main network in February 12, 2025. If the patent applications pass, we are ready to license our solution.
