Emergency Local-State Proof of Work is a research proposal for a Bitcoin hard-fork contingency that preserves existing SHA-256 ASIC silicon while forcing major changes to miner firmware, pool architecture, state access, and block construction.
The motivating question is whether Bitcoin could retain the sunk investment of small and medium independent SHA-256 miners while disrupting an attacking mining cartel more severely than an ordinary rule change—but less destructively than replacing SHA-256 with a CPU, GPU, FPGA, or unrelated ASIC algorithm.
The proposed construction is deliberately two-stage:
- Existing ASIC cores search ordinary 80-byte SHA256d work and return moderately difficult inner tickets.
- Each unpredictable ticket selects authenticated pages from recently committed Bitcoin state. A nearby node or state service supplies a canonical proof, after which a cheap outer hash determines whether the ticket is a block.
The realistic objective is not to prove geography. Permissionless consensus cannot prove that a machine is in a home, measure private network latency, or distinguish a full node from a specialized state mirror. The objective is to make efficient mining require a new, stateful control plane at each mining site, breaking unchanged centralized-pool workflows and increasing the transition burden of large heterogeneous fleets.
- Technical proposal — full protocol sketch, threat model, security comparison, implementation plan, test program, and activation considerations.
- Design variants and limitations — the optional miner key, the keyless version, comparison with the 2016 history-byte/KNB proposal, and hard-fork versus soft-fork boundaries.
- No-fork path with decentralized pools — practical steps using local templates, GridPool-like decentralized accounting, Stratum V2/DATUM-style gateways, and open low-latency relay.
- Deterrence and activation — how ELSPoW could function as a credible emergency outside option, what BIP-110's stalled fork illustrates, and why pool operators are not identical to physical hash owners.
This repository contains exploratory research, not a BIP, implementation, production specification, activation client, or recommendation to fork Bitcoin. Several components—notably the authenticated state representation, proof canonicalization, difficulty adjustment, chainwork calculation, and any nonoutsourceable-key construction—require extensive simulation, independent review, and multiple implementations.
The first proposed experiment is a keyless simulator, followed by an ESP-Miner/Bitaxe control-plane prototype on a private development network. Consensus code should come only after those experiments survive attempts to find grinding, caching, pipelining, and central-service bypasses.
- Existing SHA-256 hashing cores can be reused if the ASIC-facing operation remains an 80-byte SHA256d search.
- A post-ticket state challenge is better targeted than putting historical data directly inside every hash, because changing any header field produces a new ticket and therefore a new challenge.
- Pure latency is not enforceable. A prepared farm can deploy a state mirror onsite, so ELSPoW creates transition friction rather than permanent exclusion.
- A miner-held VRF key can make centralized finalization harder, but a hot key adds significant home-miner security complexity and is not necessary for the first prototype.
- Full ELSPoW is a hard fork. A soft-fork relative can preserve legacy header validity, but cannot create a high-rate ticket stream immediately and is a poor break-glass mechanism.
- Local template construction and decentralized reward accounting can reduce pool control today without any consensus change.
- A credible contingency must be built and exercised before a crisis. Software written only after a chain stalls is a rescue attempt, not a strong deterrent.
Technical criticism is particularly useful. High-priority questions include:
- Can a miner obtain more than one outer attempt from one paid ASIC ticket?
- How effectively can a remote service batch, cache, compress, or pipeline the selected state proofs?
- What state layout creates meaningful proof-serving work without imposing unacceptable costs on validating nodes or home miners?
- How quickly can an industrial miner neutralize the intended friction by deploying onsite mirrors and replacement controllers?
- Can decentralized pool accounting and local templates capture most of the governance benefit without changing consensus?
Please open an issue with a concrete attack, parameter critique, prior-art reference, implementation concern, or proposed experiment.
No license has been selected yet. The repository is public for review and discussion, but publication alone does not grant reuse rights. A license should be chosen explicitly before accepting substantial outside contributions.