01
Permanent RDTS
BIP110 / Reduced Data rules become permanently active under the Purity hard-fork rules at the hardcoded mainnet activation height (961637), and they do not expire.
CONSENSUS
Bitcoin Purity
Whitepaper
now available.
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
Network
Live mainnet tools
For miners
Pool monitor
Monitor the trial solo pool — hash rate, workers, blocks, and payout status on Purity mainnet.
pool.bitcoinpurity.org → (opens in a new tab)For everyone
Mempool explorer
Browse pending transactions, recent blocks, and fee estimates on the Purity network.
mempool.bitcoinpurity.org → (opens in a new tab)Community
BBS
Username registration bulletin board — post and reply after signing up. Email optional, used only for password reset.
bbs.bitcoinpurity.org → (opens in a new tab)For users
Wallet connection
Connect BlueWallet, Sparrow, or any wallet that supports custom Electrum servers to view balances and send on Purity mainnet.
Connection settings →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
Pinned activation block
Mainnet accepts only activation block 0000000000000000003ea74f4dafdda7ed4e02c4c1ccb9768e0ca4f9e1a35159 at height 961637. This consensus pin remains enforced when checkpoints are disabled.
CONSENSUS
03
SHA256d
Proof-of-work remains SHA256d.
UNCHANGED
04
ASERT / 24H
Difficulty uses aserti3-1d after Purity activation.
ACTIVE IN THIS TREE
05
Deep-reorg parking
Reorganizations deeper than 6 blocks are parked for operator review by default. Local policy — not consensus.
LOCAL POLICY
06
Bitcoin transaction compatibility
Address formats, transaction serialization, and sighash remain Bitcoin-compatible.
UNCHANGED
07
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
How are Bitcoin Purity versions numbered?
Bitcoin Purity now uses its own independent MAJOR.MINOR.PATCH release series. The current mainnet release is v1.0.0rc3 (release candidate). Git tags use a leading v (for example v1.0.0, v1.0.0rc3). This is separate from the upstream Bitcoin Knots version (29.4.0) and the Bitcoin Core consensus baseline (29.4). On the P2P network, nodes identify as /Satoshi:29.4/Purity:1.0.0/. Older date-based tags such as v29.4.purity20260830rc2 are legacy identifiers. See doc/VERSION.md in the repository for the full convention.
Is Bitcoin Purity live on mainnet?
Yes. Mainnet launched at 10:00 UTC on 19 August 2026, at block height 961637. Mainnet activation is hardcoded, and the activation block is consensus-pinned to 0000000000000000003ea74f4dafdda7ed4e02c4c1ccb9768e0ca4f9e1a35159. The official release is v1.0.0rc3 (source and binaries). If an existing block index contains a conflicting block at the activation height after upgrading, rebuild it with -reindex. Trial solo pool endpoints are stratum+tcp://pool.bitcoinpurity.org:3333 and stratum+tcp://pool.bitcoinpurity.org:4444 (port 4444 for low-hash-rate miners).
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.
Contact
Get in touch.
Bitcoin is enough.
Money does not need to become everything.
PEER-TO-PEER
ELECTRONIC
CASH