I think I have an idea to discourage this. It's not entirely novel, but I think it can be done as a soft fork (I've heard others suggest it would require a hard fork).
Alongside the existing requirement that the hash of the header be smaller than the current 'target', I would add a new requirement to include a signature of a message - signed by the coinbase output's key - where that signature begins with four zero bytes.
The controller of the coinbase - i.e. the pool operator - might be tempted to share the private key with the 'hashers' in order for the hashers to compute the signature locally. But of course the controller won't want to share the private key, and instead the hashers will submit their shares to the controller such that the controller will compute the signature and check if they have achieved a full block.
With this, the hashers don't know if their 'mining share' is a 'full block' and therefore they don't know which shares to withhold.
Unfortunately, we would also need to softfork a new signature scheme with deterministic signatures, which also means a new curve. "BLS signatures — Boneh–Lynn–Shacham — often used over pairing-friendly curves such as BLS12-381."
Also, this signature would need to be passed 'out of band', i.e. it's an extension to the relay protocol. But it's a soft fork because nodes don't need to be upgraded. Non-upgraded nodes might be "confused" because they would see an *apparent* drop in difficulty
SatsAndSports
npub1zt…wxm56
2026-05-19 22:07:03 UTC
in reply to nevent1q…xls2
Author Public Key
npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56Published at
2026-05-19 22:07:03 UTCEvent JSON
{
"id": "78da4d80c71f62b6977a33847f7038ce82f6bee4113c294f139bd49f69c7c55c",
"pubkey": "12ee03d11684a125dd87be879c28190415be3f3b1eca6b4ed743bd74ffd880e6",
"created_at": 1779228423,
"kind": 1,
"tags": [
[
"e",
"706338e4654929b5da7cc9ba13bbad4b33c42543a70a6fa547cc28d233e4733f",
"wss://nos.lol/",
"root",
"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd"
],
[
"p",
"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd"
]
],
"content": "I think I have an idea to discourage this. It's not entirely novel, but I think it can be done as a soft fork (I've heard others suggest it would require a hard fork).\n\nAlongside the existing requirement that the hash of the header be smaller than the current 'target', I would add a new requirement to include a signature of a message - signed by the coinbase output's key - where that signature begins with four zero bytes.\n\nThe controller of the coinbase - i.e. the pool operator - might be tempted to share the private key with the 'hashers' in order for the hashers to compute the signature locally. But of course the controller won't want to share the private key, and instead the hashers will submit their shares to the controller such that the controller will compute the signature and check if they have achieved a full block.\n\nWith this, the hashers don't know if their 'mining share' is a 'full block' and therefore they don't know which shares to withhold.\n\nUnfortunately, we would also need to softfork a new signature scheme with deterministic signatures, which also means a new curve. \"BLS signatures — Boneh–Lynn–Shacham — often used over pairing-friendly curves such as BLS12-381.\"\n\nAlso, this signature would need to be passed 'out of band', i.e. it's an extension to the relay protocol. But it's a soft fork because nodes don't need to be upgraded. Non-upgraded nodes might be \"confused\" because they would see an *apparent* drop in difficulty",
"sig": "9f6ee4d4a9a3377e2240c937097f13f2f4efe6a0243c6f16b56d385547ef014f464986539b37803f311aa2a11e1492d6b11012ea929399bfb581b43a7e35d2c3"
}