Implement Detective Mining (Pool Software Change, No Protocol Change Required)

[fluffypony]

We should encourage pools to adopt the "detective mining" strategy from Lee and Kim, which leverages information pools already leak in their job messages to collapse a selfish miner's private lead. Crucially, this is deployable at the pool or Stratum-proxy level with no consensus or protocol changes.

Paper: https://eprint.iacr.org/2019/486

Thanks to @AJ__1337 on X for highlighting the paper.

One-paragraph explainer

Selfish pools must distribute jobs that tell their workers which parent to mine on (eg. Qubic uses pool.qubic.li). Those jobs reveal the pool's private tip via the previous block hash. A detective miner subscribes to those jobs, detects when the leaked prevhash does not match the public tip, and immediately mines a "counter" child block on top of the selfish pool's hidden parent. Publishing that child forces the selfish pool to reveal its private block or lose it, repeatedly cutting off the attacker's lead and eroding their advantage. The original paper models and simulates this dynamic and shows the attacker's extra revenue disappears as detective adoption grows.

Practically, if ~50% of the Monero hashrate (the largest pools) implement this, then the selfish miner’s break-even jumps to roughly 42 percent if tie-breaking favours the honest chain, ~37 percent under neutral tie-breaking, and ~32 percent if tie-breaking favours the attacker (see Figure 11 in the paper). Comparatively, the baseline without detective miners is the classical Eyal–Sirer threshold that can be near 25 percent when tie-breaking favours the attacker, rising toward one third otherwise. If we are between 50% and 100% hashrate adoption across pools then it wipes out the ability to selfish-mine entirely across the tested splits (see Figures 14 and 15).

Why this is pool-side: Stratum job messages include a prevhash or equivalent parent reference that pools must share with miners. In Stratum v1 job payloads this field is explicit, and in Stratum v2 there is a dedicated SetNewPrevHash message. That is the hook detective mining exploits.

Actionable plan for pools and stratum proxies

Scope. All work is at the pool or proxy layer. No protocol or consensus changes are needed.

1) Instrumentation and detection

• Add a lightweight "sensor" client that subscribes to competing pools' job streams. Capture the current prevhash and job IDs.
• Continuously compare the observed prevhash with your node's public tip. If it diverges for more than T seconds, flag a likely private branch.

2) Counter-template construction

• When a leak is detected, construct a valid block template whose parent equals the leaked prevhash. Keep the template minimal if needed. For Bitcoin-style stacks this means a legal header, coinbase, and a conservative transaction set.

3) Hash allocation and switching

• Immediately redirect a configurable fraction of your pool's hashrate to the counter-template, even if that means the entire pool's hashrate uses this new template. Revert to public-tip templates when the competitor's jobs return to the public parent.

4) Submission and networking

• On a find, broadcast your child block immediately. The selfish pool must then publish its private parent to avoid losing it, collapsing its lead.

Why this helps

• Mechanism. Detective mining repeatedly cuts the attacker's private lead by forcing reveals whenever the attacker tries to extend a hidden branch.
• Practicality. It exploits fields pools already expose in job messages, and it works today with Stratum, which means it works with Monero.
• Economics. The paper's simulations show the attacker's excess revenue shrinks quickly as the detective share grows, and multiple selfish pools cannibalise one another even more once detective miners are active.

Pool Software Anti-Decoy Counter-Measures

Pool software should include some sneakiness to prevent their sensor probes from being detected. Here's a checklist:

Detection and corroboration

• Require quorum: do not act unless the same off-tip prevhash is observed by multiple independent sensors on different IP ranges and regions.
• Verify persistence: the off-tip parent must persist across multiple mining.notify messages or SV2 SetNewPrevHash updates for T seconds before diverting any hash.
• Share-acceptance check: each sensor submits a few shares on the leaked job and proceeds only if the pool accepts them, proving the job is live and not a read-only decoy.
• P2P sanity check: confirm the leaked parent is not yet known to your full node or the public tip.

Sensor hygiene

• Make sensors hard to fingerprint: rotate IPs and providers, vary user agents, and keep normal share cadence and difficulties so targeted fake jobs are harder to aim at. Stratum sessions are per-connection with per-connection state (extranonce1), so blend in.
• Use multiple ingress points: subscribe to several pool endpoints when available and compare job streams in real time.

Activation policy

• Two-stage diversion: on a valid signal, divert a tiny fraction H of hash first, auto-ramp only if corroboration continues during a grace window. Roll back automatically if any check fails. The detective-mining literature supports that even modest detective share reduces attacker advantage.
• Rate-limit triggers: bound how often you will divert within a rolling window and cap the maximum detective-hash allocation to limit worst-case decoy cost.
• Cross-sensor consistency: abort if the pool delivers inconsistent prevhashes across your own sensors in close time proximity, which is a strong indicator you are being singled out. Stratum allows different jobs per connection, so inconsistency is meaningful.

Telemetry and audits

• Log every incident: prevhash, job IDs, times seen, which sensors corroborated, share-acceptance results, diversion start/stop, and outcomes.
• Track false positives and orphan rate during trials, then tighten thresholds based on empirical results.

[kayabaNerve]

Can't a malicious pool (as we're discussing here) lie about having a private chain to cause other pools to divert hashpower? The counter seems to be 'the malicious pool is itself distributing work on an alt-chain', but I wouldn't be surprised if a pool could identify the connections another pool is listening via.

[fluffypony]

Can't a malicious pool (as we're discussing here) lie about having a private chain to cause other pools to divert hashpower? The counter seems to be 'the malicious pool is itself distributing work on an alt-chain', but I wouldn't be surprised if a pool could identify the connections another pool is listening via.

Yes but that's easy to mitigate - a pool could easily operate their sensors on different IP addresses with different addresses, and only shift hashrate if a quorum of sensors see the same prev_id. The pool software should also require the leaked parent to persist across time and messages, not a single notify or SetNewPrevHash, and then abort if the pool flips parents or sends mutually inconsistent jobs across your own connections, which is a strong sign you’ve been singled out. Also there's no need for the whole hashrate to flip to that block - even if single-digit percentages mine it, it forces the malicious pool to disclose.

[fluffypony]

Added an anti-decoy counter-measure checklist to the issue.

[SChernykh]

The selfish pool must then publish its private parent to avoid losing it, collapsing its lead.

No they won't publish it. If a block at height N+1 is private and someone mines a child block at height N+2, it will not become the longest chain because of the missing N+1. It will just dangle in node's memory, or will be rejected.

[fluffypony]

No they won't publish it. If a block at height N+1 is private and someone mines a child block at height N+2, it will not become the longest chain because of the missing N+1. It will just dangle in node's memory, or will be rejected.

You’re right that an N+2 child without its N+1 parent will not be accepted. That isn’t the claim. Detective mining doesn’t magic N+2 onto the main chain; it changes the attacker’s pay-off so they either reveal N+1 now or eat the loss.

Two outcomes once the detective child is broadcast:

1. Attacker reveals. To realise any revenue from their private branch, the selfish pool must publish N+1 so the network can validate the detective’s N+2. Publishing early collapses their private lead back toward parity and neuters the selfish-mining advantage. This is exactly the dynamic modelled in the detective-mining paper (see Fig. 2(c)–(d); the authors explicitly assume the rational response is to release the private blocks when a child appears)

2. Attacker withholds. Then they forfeit N+1’s reward and keep hashing on a branch that other pools can keep targeting with further detective children. Meanwhile, the public chain advances. Economically this is worse than revealing, which is why the paper’s state machine and simulations show the attacker’s extra revenue shrinking as detective share grows

Network mechanics are straightforward: nodes that see a block whose parent is unknown don’t attach it; they request or await the missing parent and hold the child as an orphan until the parent arrives. That’s normal Bitcoin/Monero behaviour and precisely why the attacker must release the parent to get paid.

So the sentence should read more precisely: “Publishing the detective child forces a choice. If the selfish pool wants any revenue from its private fork, it must reveal the parent now, which collapses its lead; otherwise it burns its private blocks.” That is the incentive lever detective mining exploits, and it requires only pool-side changes, not protocol changes.

[SChernykh]

If an attacker withholds, and mines their own version of N+2, then what will happen? Detectives will mine on top of attacker's N+2, or their own N+2?

[preoncyber]

This is with known dark pools. How do we counter unknown pools?

[stringhandler]

No they won't publish it. If a block at height N+1 is private and someone mines a child block at height N+2, it will not become the longest chain because of the missing N+1. It will just dangle in node's memory, or will be rejected.

Not sure if it's better here or as a new proposal, but to allow mining without the having N+1, you could change the block hashing structure to be longer, and have x blocks hashes. So for example if you wanted to prevent a selfish mine of 5 blocks, you could have the block_hash_blob that is fed into randomx be <block n-5><block n-4>...<block n-1><block_hashing_blob>.

The reason this needs to be in the block_hashing_blob is so that selfish pools must publish it to their miners. In this case I believe the miners for qubic are mercenary, so they are in the public and anyone can mine to their pool, seeing the chain.

If you change the way a block is hashed together, you could potentially even form a merkle tree, ideally with enough data to calculate the difficulty of each block.

So prev_block_hash becomes a node in a merkle tree, prev_block_mr = Hash(prev_prev_block_mr, other_blob_hash) and is recursive.

Then stratum blobs are a short merkle tree of prev_block_mrs with enough data to know the strength of the chain, even if they don't have the full blocks. The non-selfish pools can mine on the chain, even though they don't have it.

[fluffypony]

If an attacker withholds, and mines their own version of N+2, then what will happen? Detectives will mine on top of attacker's N+2, or their own N+2?

Detectives always target the attacker’s latest leaked tip. If the attacker withholds and privately finds their own N+2, your sensors will see the pool’s jobs switch to prevhash = that N+2, and you switch to mining N+3 on top of it.

The reason is:

• You cannot profitably extend your own N+2, because you do not have the attacker’s hidden N+1. Any N+3 you mine on your own N+2 will remain unprovable until the attacker reveals N+1.
• By targeting the attacker’s current private tip every time it advances, you keep creating a child that becomes valid the moment they reveal. To realise any reward on their private branch, they must publish the missing parent(s), which collapses their lead.
• If they still refuse to reveal, they are burning their own N+1 (and possibly N+2) rewards while you have only diverted a bounded fraction of hash for a bounded time.

So here's the sequence:

1. Public at N. Attacker withholds N+1a.
2. Detective mines and broadcasts N+2d on top of N+1a. It waits as an orphan until N+1a appears.
3. Attacker withholds further and finds N+2a. Their jobs now reference N+2a.
4. Detectives pivot to mine N+3d on top of N+2a.
5. To get paid, the attacker must reveal N+1a (and N+2a if they have it). Once revealed, your N+2d/N+3d immediately contend, cutting their advantage. If they do not reveal, they forfeit those rewards.

[fluffypony]

This is with known dark pools. How do we counter unknown pools?

You cannot preempt a pool you cannot see. Detective mining only triggers when a pool leaks its private tip in Stratum jobs. But any pool that recruits external hash leaks by design, so the counter is to maximise sensor coverage. A perfectly closed, in-house farm can hide, but getting to ~34 percent that way is operationally very hard - AND we'd see the global / unknown hashrate increasing and have nothing to attribute it, which is a totally different threat to the one we've seen recently.

If another threat emerges that is trying to get 34% through bribery / merge-mining, it's easy to get "on the inside" with them and get the pool address, even if it's not publicly disclosed.

[tevador]

If the attacker withholds and privately finds their own N+2, your sensors will see the pool’s jobs switch to prevhash = that N+2, and you switch to mining N+3 on top of it.

The sensors won't recognize N+2, they will just see some unknown prev_id in the block template. Only the miner who found the winning nonce will recognize N+2.

This is an important distinction because the "detective miners" need to make sure that the secret chain actually starts from the known chain tip, otherwise they might accidentally help a 51% attacker build a parallel chain. This is a problem because the Monero block template doesn't include the block height.

Even if you can somehow ensure you are advancing the chain, the detective N+2 block would probably need to be empty to avoid accidental double spends because the set of transactions included in N+1 is unknown.

nodes that see a block whose parent is unknown don’t attach it; they request or await the missing parent and hold the child as an orphan until the parent arrives

A quick look at the source code suggests that monerod will currently reject blocks with an unknown parent. However, this could be changed.

https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/cryptonote_core/blockchain.cpp#L2122-L2126

[BawdyAnarchist]

At a minimum it looks like a really good way to detect a potential selfish mining reorg in progress.

I wonder about the incentives of an attacker like Qubic, who might not be mining with profit in mind. (In their case, likely considering mining as a marketing expense for their token). But more generally, let's say that an attacker's goal is network disruption. They could simply withold the parent indefinitely, regardless of profit, and cause chain delays. If they do this enough times over 720 blocks, it might even cause difficulty adjustment swings.

[fluffypony]

If the attacker withholds and privately finds their own N+2, your sensors will see the pool’s jobs switch to prevhash = that N+2, and you switch to mining N+3 on top of it.

The sensors won't recognize N+2, they will just see some unknown prev_id in the block template. Only the miner who found the winning nonce will recognize N+2.

This is an important distinction because the "detective miners" need to make sure that the secret chain actually starts from the known chain tip, otherwise they might accidentally help a 51% attacker build a parallel chain. This is a problem because the Monero block template doesn't include the block height.

Even if you can somehow ensure you are advancing the chain, the detective N+2 block would probably need to be empty to avoid accidental double spends because the set of transactions included in N+1 is unknown.

nodes that see a block whose parent is unknown don’t attach it; they request or await the missing parent and hold the child as an orphan until the parent arrives

A quick look at the source code suggests that monerod will currently reject blocks with an unknown parent. However, this could be changed.

https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/cryptonote_core/blockchain.cpp#L2122-L2126

Great points. Three clarifications and two concrete safeguards.

1. Sensors do not need to "recognize N+2" by hash, they only need to see that a pool's job prevhash switches from the public tip to an unknown hash. That flip is the signal a private child exists. In Stratum v2 this flip is explicit via SetNewPrevHash.

2. We can avoid helping deep reorgs by enforcing "adjacency" - ie. act only when you have continuity that the leak is the immediate child of the public tip, not some far-back ancestor. I think the way to do this is through two simple rules:

   • You observed the same pool issuing jobs on the public tip, then within a short window it switched to an unknown prevhash. Treat that unknown as N+1 of the current tip for that pool.
   • Prefer job streams that include a height field and require height == public_height + 1 before acting. afaik most XMR pools include height in the job payload already?

If a pool does not expose height, fall back to the continuity rule above and require multiple corroborating sensors before diverting any hash. For extra safety, start with a tiny detective fraction and auto-backoff if the signal diverges.

3. Unknown-parent children and Monero today: you're right that current monerod tends to reject unknown-parent blocks rather than caching them. That weakens the pure "pre-propagate the child" angle, but it does not break the incentive: the attacker still has to reveal their parent to realise revenue, and when they do you immediately submit your child. A separate improvement would be to accept and hold unknown-parent children as orphans for later attachment.

NOTE: we don't need to have such a thing running globally on the network, we could make that code change and pools could run it and peer with each other, ensuring that they get pre-propagated child blocks even if the network as a whole doesn't all have them.

Two other operational safeguards we can add:

• Something like an "adjacency gate" - only divert when we have continuity evidence from the same pool: jobs on the public tip followed immediately by jobs with an unknown prevhash, plus share-acceptance on that job, and quorum across multiple sensors. If the unknown prevhash appears without that sequence, we do not divert.

• Empty detective blocks by default - build the detective child with only the coinbase to avoid any accidental double spends, since the N+1 transaction set is unknown. Thanks to tail emission, the base reward is fixed at 0.6 XMR, so empty blocks are clean and predictable.

In terms of the net effect, even if the attacker keeps privately extending on top of our published child, they cannot capture that middle reward and must still reveal to get paid. With adjacency checks, quorum, and empty detective blocks, we avoid aiding a deep parallel chain while keeping the attacker's expected gain down and their time to reveal short.

If useful, we can also ask that xmrig etc. add a pool-side requirement to include height in job messages.

[fluffypony]

At a minimum it looks like a really good way to detect a potential selfish mining reorg in progress.

I wonder about the incentives of an attacker like Qubic, who might not be mining with profit in mind. (In their case, likely considering mining as a marketing expense for their token). But more generally, let's say that an attacker's goal is network disruption. They could simply withold the parent indefinitely, regardless of profit, and cause chain delays. If they do this enough times over 720 blocks, it might even cause difficulty adjustment swings.

Totally agree on the first line: detective mining is an excellent early warning.

On a disruption-motivated attacker who withholds indefinitely:

1. Detective mining is still useful because it caps the size of any eventual reorg. If the attacker ever reveals, our pre-mined children on their leaked tips attach immediately, so their reveal collapses to at most a 1-block lead instead of a multi-block jump. That reduces the blast radius of each attempt, even if the attacker is not profit-seeking. ALSO it gives operators live telemetry to coordinate responses in real time (raise confs, re-peer, temporarily reallocate hash away from suspected pools).

2. Detective mining can't force a reveal; if an attacker is willing to burn money to slow blocks, they can withhold forever. The effect is a temporary slowdown (as you highlighted) until difficulty readjusts, but to my mind this is no different from an attacker bringing hashrate on and off just to mess with the difficulty.

I think the bottom line here is that if the attacker is willing to light money on fire, they can slow blocks proportional to their private hash until difficulty catches up. Detective mining will not stop that, but it prevents those withheld blocks from being converted into profitable or deep reorgs, and it gives the ecosystem early, actionable signals to blunt the operational impact.