Safety
During the transition, treat settlement conservatively.
High-value transactions should use stricter confirmation requirements or be delayed until network conditions are sufficiently stable.
Be alert to chain reorganizations, replay behavior, and double-spend risk during periods of low or volatile hash rate.
Before hash rate stabilizes
- Do not accept zero-confirmation payments as final.
- Be cautious with low-confirmation payments from parties you do not trust.
- Require more confirmations for economically significant transactions.
- Consider delaying high-value settlement during severe hash-rate instability.
- Monitor chain reorganizations and node warnings.
- Understand replay behavior before spending coins during coexistence of Purity and legacy histories.
- Run your own Bitcoin Purity node when making important settlement decisions.
There is no fixed confirmation count that guarantees safety. Security depends on available proof-of-work and economic conditions.
What majority hash power can — and cannot — do
A party controlling sufficient competing proof-of-work may attempt to reorganize recent blocks, reverse its own previously confirmed payments, double-spend its own inputs, and censor or delay transactions.
Hash power alone does not provide the private keys required to spend arbitrary coins belonging to other users. Without the relevant private keys, majority hash power does not grant arbitrary authority to spend someone else’s UTXOs.
Bitcoin Purity currently uses operational defenses including 24-hour ASERT difficulty adjustment after activation, SHA256d remaining unchanged, and default parking of reorganizations deeper than 6 blocks for operator review.
Those measures are intended to improve operation under changing hash-rate conditions. They are not guarantees against every possible attack. Prefer the phrase reorganization risk mitigation over any claim of 51% attack immunity.
Deep-reorg parking
Blocks requiring a reorganization deeper than 6 blocks are parked rather than automatically reorganizing the active chain.
Deep-reorg parking is local node policy, not a consensus guarantee. It does not make a majority-hash attack impossible.
Replay behavior
Bitcoin Purity adds no transaction-level replay protection. 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. Each node has its own mempool.
Double-spend freeze is not implemented
Automatic freeze of double-spend coinbases and inputs is specified as draft work. It is not implemented and is not an active protection.