Questions, answered from the repository.

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.

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.

Proof-of-work remains SHA256d. The design avoids unnecessarily invalidating existing SHA256 mining investment as part of the fork. That is a continuity choice about the capital that secures Bitcoin — not a promise of mining profitability, and not a guarantee that every miner is protected from economic loss.

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.

No. Each node maintains its own mempool. There is not one shared mempool across histories. Compatible transactions may be valid on both histories and may propagate to nodes on both, depending on each node’s rules, policy, and chain state.

The design intentionally avoids a mandatory one-time asset conversion. Transaction compatibility is meant to leave a path open rather than force every user through a claim event. Actual transaction safety still depends on current chain state, replay behavior, and network conditions. That is not a promise of effortless migration under every possible future state.

After activation, difficulty uses aserti3-1d with a 24-hour half-life, intended to adapt more responsively when available hash rate differs substantially from the pre-fork network. That does not promise regular block times. Until hash rate and block production are stable and sufficient, treat settlement conservatively: do not treat unconfirmed or lightly confirmed payments from untrusted counterparties as final.

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.

No. Deep-reorg parking is local node policy requiring operator review. It is reorganization risk mitigation, not a consensus guarantee, and not 51% attack immunity. It does not make a majority-hash attack impossible.

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.

Preserve Bitcoin’s monetary character — peer-to-peer electronic cash, not a general-purpose data platform — and allow economic consensus to choose the Purity rules without deliberately introducing a new asset identity. The intent is that economic activity migrates toward those rules rather than that a permanently separate “new coin” is engineered.