01
Permanent RDTS
BIP110 / Reduced Data rules become permanently active under the Purity hard-fork rules at the operator-set activation height, and they do not expire.
CONSENSUS
Bitcoin Purity
Bitcoin is money.
Keep it that way.
Bitcoin Purity is a Bitcoin full node built to preserve Bitcoin as peer-to-peer electronic cash — not a general-purpose data-storage or application platform.
View Source on GitHub (opens in a new tab)
Monetary transfers belong in the block. Excessive arbitrary-data payloads are rejected by the Reduced Data consensus boundary.
SHA256d · Bitcoin addresses · Bitcoin transactions · Permanent Reduced Data rules
Purpose
What is Bitcoin for?
MONEY
- Peer-to-peer electronic cash
- Value transfer
- Proof-of-work security
- Self-verification
- Scarce block space
NOT A GENERAL-PURPOSE DATABASE
- Arbitrary file storage
- A general application layer
- Consensus optimized around data embedding
- Unbounded expansion of base-layer purpose
Block space is for money.
Why the hard fork exists
Policy can change.
Consensus endures.
Relay and mempool policy are configurable. Consensus is what fully validating nodes actually enforce. Bitcoin Purity exists because Bitcoin’s monetary purpose should not depend only on mempool policy. BIP110 / RDTS Reduced Data rules are made permanent through the Purity hard fork.
The short-term consensus document in the repository is the source of truth. Read purity-consensus.md (opens in a new tab)
Continuity
Preserve Bitcoin's economic continuity.
Miners
Keep SHA256d.
Bitcoin Purity keeps Bitcoin’s SHA256d proof-of-work rather than switching to an incompatible mining algorithm. The design avoids unnecessarily invalidating existing SHA256 mining investment as part of the fork. It does not promise mining profitability, and it does not imply every miner is guaranteed protection from economic loss.
Users
Keep Bitcoin transactions.
Bitcoin address formats remain unchanged. Transaction serialization remains unchanged. Sighash remains compatible. Bitcoin Purity deliberately introduces no transaction-level replay protection. Users do not receive a new token.
Network
Keep the path open.
Bitcoin Purity maintains transaction compatibility rather than forcing every user through a one-time token-claim or asset-conversion event. The intended long-term outcome is economic migration toward the Purity rules rather than the creation of a permanently separate “new coin.”
Don't destroy the capital that secures Bitcoin in order to save Bitcoin.
Project philosophy — not an empirical guarantee
Proof-of-work
Keep hashing Bitcoin.
SHA256d is unchanged. Hash-rate defense in this tree is operational: difficulty that tracks available work, and parking of deep reorgs — not an algorithm change. Mining involves substantial technical and economic risk.
UNCHANGED
Replay compatibility
No forced migration day.
Bitcoin Purity intentionally adds no transaction-level replay protection. Because addresses, transaction formats, and sighash remain compatible, a transaction may be valid on both Purity and a compatible legacy history.
Compatible transactions can potentially propagate to and be accepted by nodes on both histories, subject to each node’s current policy, chain state, and validity rules. Nodes maintain their own mempools.
The protocol does not require users to convert Bitcoin into a newly created asset simply to remain compatible with Purity.
Difficulty
Difficulty follows available hash rate.
After Purity activation, difficulty uses aserti3-1d with a 24-hour half-life and a 600-second target interval. SHA256d proof-of-work is unchanged. The algorithm is intended to adapt more responsively when available hash rate differs substantially from the pre-fork network. It does not promise perfectly regular block times.
- Algorithm
- aserti3-1d
- Half-life
- 86400 seconds
- Anchor height
- 961632
Reorganization risk mitigation
Deep reorgs wait for an operator.
If connecting a block would rewind the active chain by more than 6 blocks, that block is parked rather than automatically reorganizing the active chain. This is local node policy, not a consensus guarantee. It is not 51% attack immunity.
LOCAL POLICY
Local policy — not consensus
This tree
Protocol specification
Summaries only. The repository consensus specification is authoritative. (opens in a new tab)
02
SHA256d
Proof-of-work remains SHA256d.
UNCHANGED
03
ASERT / 24H
Difficulty uses aserti3-1d after Purity activation.
ACTIVE IN THIS TREE
04
Deep-reorg parking
Reorganizations deeper than 6 blocks are parked for operator review by default. Local policy — not consensus.
LOCAL POLICY
05
Bitcoin transaction compatibility
Address formats, transaction serialization, and sighash remain Bitcoin-compatible.
UNCHANGED
06
No transaction-level replay protection
This is intentional. Read the Safety explanation.
SAFETY NOTE
Direction
Current tree, later research.
ACTIVE IN THIS TREE
Short-term
- Permanent BIP110 / RDTS
- 24-hour ASERT, SHA256d unchanged
- Deep-reorg parking
- Double-spend freeze specified, not implemented
ROADMAP
Later / research
- SEAL-2 block header
- Removal of Taproot, and possibly Segwit
- Post-quantum signatures and 32 MB block size
Roadmap items are research/product direction, not active consensus rules. They require separate specification and implementation decisions.
Questions
FAQ
Is Bitcoin Purity live on mainnet?
No. Bitcoin Purity is actively under development. There is no live mainnet launch yet. This website describes the protocol and source tree, not a production network.
Is Bitcoin Purity a new cryptocurrency?
No. Bitcoin Purity does not position itself as a newly issued asset and does not introduce a ticker. It is a Bitcoin full node that claims continuity with Bitcoin: the same addresses, transaction serialization, sighash, P2P magic, default port, binary names, and default data directory. The project is a path for Bitcoin, not another coin.
Why is a hard fork necessary?
Relay and mempool policy can be changed by node operators and software defaults. Consensus is what every fully validating node actually enforces. Bitcoin Purity exists because the project believes Bitcoin’s monetary purpose should not depend only on configurable policy. BIP110 / RDTS Reduced Data rules are made permanent through the Purity hard fork. The short-term consensus document in the repository is the source of truth for those rules.
Is there replay protection?
No transaction-level replay protection is intentionally added. Because addresses, transaction formats, and sighash remain compatible, a transaction may be valid on both Purity and a compatible legacy history. Compatible transactions can potentially propagate to and be accepted by nodes on both histories, subject to each node’s current policy, chain state, and validity rules. Read the Safety guide before spending during coexistence.
Can a majority-hash attacker steal my coins?
Not arbitrarily. Without your private keys, hash power alone cannot authorize spending your UTXOs. Sufficient competing hash power can still reorganize recent blocks, censor or delay transactions, and reverse an attacker’s own earlier payments in order to double-spend them. Those are serious risks. They are not the same as spending other people’s coins.
Is double-spend freezing implemented?
No. Automatic freeze of double-spend coinbases and inputs is specified as draft work in the repository and is not implemented. Do not treat it as an active protection.
Bitcoin is enough.
Money does not need to become everything.
PEER-TO-PEER
ELECTRONIC
CASH