February 2026
BCH2 (Bitcoin Cash II) is a SHA-256 cryptocurrency that combines the proven Bitcoin Cash protocol with a fair distribution model through a 1:1 fork from BC2 (BitcoinII). Forking from BC2 at block height 53,200, BCH2 inherits the complete transaction history of BC2 while upgrading to Bitcoin Cash consensus rules—including the ASERT difficulty adjustment algorithm (with an attack-resistant 1-hour half-life for launch), 32MB blocks, CashAddr addressing, and the full suite of BCH protocol upgrades through Upgrade 11 (ABLA).
As Bitcoin and its derivatives have become dominated by industrial mining operations, BCH2 offers a fresh start with accessible difficulty levels. With no premine, no developer fees, and a fair 1:1 fork distribution to existing BC2 holders, BCH2 represents a return to the decentralized mining ethos that made Bitcoin revolutionary.
When Satoshi Nakamoto launched Bitcoin in 2009, anyone with a personal computer could mine blocks and earn rewards. This accessibility was fundamental to Bitcoin's decentralized nature—thousands of independent miners securing the network, each with a fair chance at block rewards.
As Bitcoin grew, disagreements over scaling and philosophy led to significant developments:
-
2017: Bitcoin Cash (BCH) forked from Bitcoin at block 478,558, increasing block size to 8MB (later 32MB) to enable more transactions and lower fees. BCH has continuously improved, implementing the ASERT difficulty adjustment algorithm in 2020 and numerous protocol enhancements through 2025.
-
2025: BC2 (BitcoinII) launched as a fresh implementation based on Bitcoin Core v27 with a new genesis block, providing a clean blockchain for experimentation and new use cases.
-
2026: BCH2 (Bitcoin Cash II) forks from BC2 at block height 53,200, preserving BC2's complete history while upgrading to Bitcoin Cash consensus rules. This creates a unique combination: BC2's fair initial distribution with BCH's battle-tested protocol improvements.
Bitcoin's network difficulty has reached astronomical levels, as has BCH and most SHA-256 derivatives. This creates several challenges:
-
Industrial Dominance — Only large-scale operations with access to cheap electricity and bulk ASIC purchases can mine profitably on major chains.
-
Home Miner Exclusion — Individual miners with small devices have effectively zero chance of finding a block on high-difficulty networks.
-
Pool Centralization — Miners are forced into pools, paying fees and trusting operators, reducing the peer-to-peer nature of cryptocurrency.
-
Legacy Difficulty Algorithms — Chains using Bitcoin's 2016-block adjustment period can experience extreme block time variance when hashrate fluctuates.
BCH2 addresses these challenges by:
- Starting at an accessible difficulty level inherited from BC2's early blockchain
- Implementing ASERT with a 1-hour half-life for rapid difficulty recovery against manipulation attacks
- Providing 32MB blocks for future scalability
- Using CashAddr format for user-friendly addressing
- Maintaining 100% compatibility with Bitcoin Cash protocol improvements
- Automatic ASERT half-life transition from 1 hour to 2 days at block 92,736 (~9 months post-fork) — no hard fork required
BCH2 rejects the extractive token models that have plagued recent cryptocurrency launches:
No Premine: The entire BCH2 supply at fork is distributed to BC2 holders based on their holdings at the fork block. No coins are created for developers, foundations, or insiders.
No Developer Fee: 100% of block rewards go to miners. Development is community-funded and voluntary, not extracted from block rewards.
No ICO/IEO: BCH2 is not sold or pre-allocated. Distribution occurs through the BC2 fork and ongoing mining.
Proven Codebase: BCH2 is built on BitcoinII Core v27.1, the same foundation that secures billions in value across Bitcoin and its derivatives.
Following the precedent set by Bitcoin Cash in 2017, BCH2 recognizes existing BC2 holders through a 1:1 fork:
- All BC2 balances at the fork block are credited as BCH2 (approximately 2,660,000 coins at fork)
- Users controlling BC2 private keys automatically control equivalent BCH2
- No registration, claims, or KYC required—import keys into a BCH2 wallet
This model ensures:
- Fair distribution to those who supported BC2
- Immediate liquidity from day one
- No concentration of supply in developer hands
- Alignment between early supporters and network success
BCH2's difficulty at fork provides realistic opportunities for smaller miners:
- Lottery Miners Welcome — Devices like Bitaxe, Nerdminer, and similar low-hashrate miners have meaningful odds of finding blocks.
- Home Mining Viable — Consumer ASICs can compete for full block rewards.
- Solo Mining Returns — Individual miners can mine directly without mandatory pool participation.
- Natural Growth — As adoption increases, difficulty rises organically with the network.
| Parameter | Value |
|---|---|
| Algorithm | SHA-256 (Proof of Work) |
| Block Time Target | 10 minutes (600 seconds) |
| Block Reward | 50 BCH2 (following Bitcoin's halving schedule) |
| Halving Interval | 210,000 blocks |
| Maximum Supply | 21,000,000 BCH2 |
| Block Size Limit | 32 MB |
| Min Transaction Size | 65 bytes |
| Difficulty Adjustment | ASERT DAA (aserti3-2d) |
| ASERT Half-Life (Launch) | 3,600 seconds (1 hour) |
| ASERT Half-Life (Post-Upgrade) | 172,800 seconds (2 days, matching BCHN) |
| Replay Protection | SIGHASH_FORKID |
| Parameter | Value |
|---|---|
| Fork Origin | BC2 (BitcoinII) blockchain |
| Base Software | BitcoinII Core v27.1 |
| Fork Height | 53,200 |
| Pre-Fork History | BC2 blocks 0–53,200 (BTC-compatible) |
| Post-Fork Rules | Full BCH consensus (active from block 53,201) |
| Fork Distribution | All BC2 in existence at fork block (1:1) |
| Genesis Block | Inherited from BC2: 0000000028f062b221c1a8a5cf0244b1627315f7aa5b775b931cfec46dc17ceb |
| Target Launch | ~March 7–9, 2026 |
| Parameter | Value |
|---|---|
| P2P Port (Mainnet) | 8339 |
| P2P Port (Testnet) | 18338 |
| RPC Port (Mainnet) | 8342 |
| Network Magic | 0xb2c2b2c2 |
| Address Format | CashAddr |
| Address Prefix | bitcoincashii: |
| Data Directory | ~/.bch2 |
These activations occurred in BC2's history and are preserved in BCH2:
| Upgrade | Height |
|---|---|
| BIP34 (Height in Coinbase) | 250 |
| BIP65 (CHECKLOCKTIMEVERIFY) | 260 |
| BIP66 (Strict DER Signatures) | 270 |
| BIP68/112/113 (CSV) | 280 |
| SegWit (Pre-fork only) | 290 |
All Bitcoin Cash protocol upgrades activate simultaneously at block 53,201:
| Upgrade | Original BCH Date | BCH2 Activation |
|---|---|---|
| UAHF (8MB blocks, SIGHASH_FORKID) | Aug 1, 2017 | Block 53,201 |
| New DAA | Nov 13, 2017 | Block 53,201 |
| Magnetic Anomaly (CTOR, OP_CHECKDATASIG) | Nov 15, 2018 | Block 53,201 |
| Graviton (Schnorr Signatures) | Nov 15, 2019 | Block 53,201 |
| Phonon (OP_REVERSEBYTES, SigChecks) | May 15, 2020 | Block 53,201 |
| Axion (ASERT DAA) | Nov 15, 2020 | Block 53,201 |
| Upgrade 8 (Native Introspection, 64-bit Integers) | May 15, 2022 | Block 53,201 |
| Upgrade 9 (CHIP Limits, P2SH32) | May 15, 2023 | Block 53,201 |
| Upgrade 10 (VM Limits, BigInt) | May 15, 2024 | Block 53,201 |
| Upgrade 11 (ABLA) | May 15, 2025 | Block 53,201 |
The following BTC/BC2 features are disabled post-fork, in alignment with BCH consensus:
| Feature | Status | Reason |
|---|---|---|
| SegWit (BIP141) | No new outputs | New SegWit outputs rejected post-fork; existing SegWit UTXOs spendable via scriptSig (see §5.4) |
| Taproot (BIP340-342) | Key-path only | New Taproot outputs rejected; existing P2TR spendable via key-path scriptSig only (see §5.4) |
| Replace-By-Fee (RBF) | Disabled | BCH uses first-seen policy |
BCH2 employs ASERT (Absolutely Scheduled Exponentially Rising Targets), the difficulty adjustment algorithm adopted by Bitcoin Cash in November 2020 (Axion upgrade). BCH2 uses the aserti3-2d algorithm exactly as implemented in BCHN v29.0.0, with a modified half-life parameter for launch security.
Core Algorithm:
ASERT calculates difficulty based on the time elapsed since an "anchor block" (the fork block for BCH2), targeting exactly 10 minutes per block on average:
next_target = anchor_target * 2^((actual_time - scheduled_time) / halflife)
Where:
anchor_target= difficulty target at the anchor block (fork block)actual_time= time elapsed since anchor block's parentscheduled_time= expected time based on block height difference × 600 secondshalflife= time constant controlling adjustment speed
ASERT Half-Life: Critical Launch Parameter:
| Parameter | BCH2 (Launch) | BCHN |
|---|---|---|
| ASERT Half-Life | 3,600 seconds (1 hour) | 172,800 seconds (2 days) |
| Adjustment Speed | 48× faster | Standard |
| Recovery from 10× difficulty spike | ~7 hours | ~6.6 days |
Rationale for 1-Hour Half-Life:
A new chain with limited hashrate (~1 PH/s) is vulnerable to difficulty manipulation attacks. A malicious actor with significant hashpower can mine blocks rapidly to spike difficulty, then withdraw hashpower, leaving legitimate miners unable to find blocks at the inflated difficulty. With BCHN's 2-day half-life, recovery from a 10× difficulty spike would take approximately 6.6 days—effectively rendering the network unusable for nearly a week, causing miners to leave for profitable chains and potentially triggering a network death spiral.
With BCH2's 1-hour half-life, the same attack results in only ~7 hours of slow blocks before normal operation resumes. Miners can wait it out or mine through the disruption, and the attacker's cost is wasted.
Trade-off Analysis:
| Metric | 1-Hour Half-Life | 2-Day Half-Life |
|---|---|---|
| Attack recovery | ~7 hours | ~6.6 days |
| Difficulty volatility | Higher | Lower |
| Block time variance | Higher | Lower |
| Small-chain suitability | Better | Worse |
| Large-chain suitability | Worse | Better |
The 1-hour half-life is appropriate for BCH2's launch phase with limited hashrate. The increased volatility is an acceptable trade-off for attack resistance.
ASERT Anchor Configuration:
| Parameter | Mainnet Value |
|---|---|
| Anchor Height | 53,201 |
| Anchor nBits | 0x1903a30c |
| Anchor Parent Time | TBD (Unix timestamp of block 53,200 when mined) |
| Expected Initial Difficulty | ~140 MH (0x1903a30c) |
| Target Hashrate | 1 PH/s for 10-min blocks |
BCH2 uses the CashAddr format developed by Bitcoin Cash, providing:
- Human-readable prefix identifying the network
- Error detection via BCH code checksum
- Case-insensitive encoding for easier entry
- Clear differentiation from Bitcoin/BC2 addresses
P2PKH (Pay to Public Key Hash):
bitcoincashii:qz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcr7hxlmnj
P2SH (Pay to Script Hash):
bitcoincashii:pz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcfnk4xmwy
| Prefix | Type |
|---|---|
q |
P2PKH (standard) |
p |
P2SH (multisig/scripts) |
| Parameter | BCH2 | BCHN |
|---|---|---|
| Signature Algorithm | ECDSA + Schnorr | ECDSA + Schnorr |
| Sighash Flags | SIGHASH_FORKID required | SIGHASH_FORKID required |
| Transaction Version | 1, 2 | 1, 2 |
| Max Standard TX Size | 100 KB | 100 KB |
| Dust Limit | 182 satoshis | 182 satoshis |
| Min Relay Fee | 1 sat/byte | 1 sat/byte |
| Mechanism | Implementation |
|---|---|
| SIGHASH_FORKID | Required for all post-fork transactions |
| Fork ID | 0x000000 (BCH standard) |
| Effect | Transactions valid on BCH2 are invalid on BC2/BTC |
Signatures include the fork ID in the sighash preimage, preventing transaction replay across chains. BCH2 transactions signed after block 53,200 are invalid on BC2, and BC2 transactions are invalid on BCH2.
BCH2 integrates DSProof (Double-Spend Proof), a protocol-level mechanism for real-time detection of double-spend attempts on unconfirmed transactions. Originally developed for Bitcoin Cash, DSProof strengthens zero-confirmation security for merchants and payment processors.
| Component | Detail |
|---|---|
| P2P Message Type | dsproof-beta |
| Detection Layer | Mempool integration |
| RPC Interface | Query double-spend status per transaction |
| Propagation | Network-wide broadcast on detection |
When a node detects conflicting transactions spending the same input, it constructs and broadcasts a DSProof message across the network. Merchants and wallets monitoring for DSProof alerts can flag suspect transactions within seconds of a double-spend attempt, without waiting for block confirmation.
This enables safer zero-confirmation commerce — a core use case for peer-to-peer electronic cash.
BC2 inherited SegWit from Bitcoin, meaning the UTXO set at the fork block contains coins locked in SegWit outputs (P2WPKH, P2WSH, P2TR, and P2SH-wrapped variants). Since BCH2 removes SegWit consensus rules, these UTXOs would ordinarily become unspendable after the fork.
BCH2 solves this with witness-via-scriptSig — a migration mechanism that allows holders to spend existing SegWit UTXOs by placing signature data in the traditional scriptSig field instead of the witness field.
| Output Type | Pre-Fork (BC2) | Post-Fork (BCH2) |
|---|---|---|
| P2WPKH | scriptSig: empty, witness: [sig, pubkey] | scriptSig: [sig, pubkey], witness: empty |
| P2WSH | scriptSig: empty, witness: [...args, script] | scriptSig: [...args, script], witness: empty |
| P2TR (key-path) | scriptSig: empty, witness: [schnorr_sig] | scriptSig: [schnorr_sig], witness: empty |
| P2SH-P2WPKH | scriptSig: [redeemScript], witness: [sig, pubkey] | scriptSig: [sig, pubkey, redeemScript], witness: empty |
Verification process:
- P2WPKH (v0, 20-byte): Expects [signature, pubkey] in scriptSig. The node constructs an implicit P2PKH script and verifies against it.
- P2WSH (v0, 32-byte): Expects [...args, script] in scriptSig. The node verifies SHA256(script) matches the hash in the output.
- P2TR (v1, 32-byte): Expects [schnorr_signature] in scriptSig for key-path spending only.
- P2SH-wrapped: The redeem script is included alongside the signature data in scriptSig.
Security:
- Same cryptographic security as SegWit — valid signatures are still required
- SIGHASH_FORKID is enforced on all post-fork signatures (replay protection)
- Taproot script-path spending is not supported — only key-path. Users with complex Taproot scripts should migrate their coins before the fork.
Sighash Algorithm:
SegWit UTXOs on BCH2 are spent using the BIP143 sighash algorithm with SIGHASH_FORKID (0x41):
sighash = SHA256(SHA256(
nVersion ||
hashPrevouts ||
hashSequence ||
outpoint ||
scriptCode || // P2PKH script for pubkeyhash
value || // 8-byte little-endian satoshis
nSequence ||
hashOutputs ||
nLockTime ||
hashType // SIGHASH_ALL | SIGHASH_FORKID (0x41)
))
The signature is placed in scriptSig rather than witness: scriptSig: <signature> <pubkey>, witness: (empty)
Supported Address Types for Migration:
| Type | Format | Derivation Path | Example |
|---|---|---|---|
| Legacy P2PKH | 1xxx | m/44'/0'/0'/0/x | 1A1zP1eP5QGefi2DMPTfTL... |
| Native SegWit P2WPKH | bc1q... | m/84'/0'/0'/0/x | bc1qar0srrr7xfkvy5l643... |
| Wrapped SegWit P2SH-P2WPKH | 3xxx | m/49'/0'/0'/0/x | 3J98t1WpEZ73CNmQviecrn... |
Important: This mechanism only applies to SegWit UTXOs that existed at or before the fork block. New SegWit outputs cannot be created after the fork — BCH2 consensus rejects them.
BCH2 provides a 1:1 distribution of all BC2 balances at fork height 53,200. The claim process supports all address types through a unified wallet interface.
Derivation and Scanning:
The wallet derives addresses from a BIP39 mnemonic using standard derivation paths:
| Path | Type | Addresses Scanned |
|---|---|---|
| m/44'/0'/0'/0/0–19 | Legacy (P2PKH) | External (receive) |
| m/44'/0'/0'/1/0–19 | Legacy (P2PKH) | Internal (change) |
| m/84'/0'/0'/0/0–19 | Native SegWit (P2WPKH) | External (receive) |
| m/84'/0'/0'/1/0–19 | Native SegWit (P2WPKH) | Internal (change) |
| m/49'/0'/0'/0/0–19 | Wrapped SegWit (P2SH-P2WPKH) | External (receive) |
| m/49'/0'/0'/1/0–19 | Wrapped SegWit (P2SH-P2WPKH) | Internal (change) |
Both external (receive) and internal (change) address chains are scanned to locate all fork-eligible UTXOs.
Anti-Gaming Protection:
To prevent double-claiming through address type manipulation, the wallet implements balance origin verification:
isFromForkDistribution = (BC2_balance > 0)
If a BCH2 balance exists but the corresponding BC2 balance is zero, the funds were received post-fork and are flagged as non-fork-distribution funds. This prevents the following attack vector:
- Claim BCH2 on a SegWit address
- Move the original BC2 funds to a legacy address
- Attempt to claim again on the legacy address
The wallet displays appropriate warnings for post-fork deposits versus fork distribution balances.
BCH2 supports the full BCH script instruction set:
| Category | Capabilities |
|---|---|
| Cryptographic | OP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKDATASIG, OP_CHECKDATASIGVERIFY |
| Signature Type | ECDSA (legacy), Schnorr (post-Graviton) |
| Introspection | Native introspection opcodes (Upgrade 8) |
| Arithmetic | 64-bit integers, BigInt (Upgrade 10) |
| Stack | OP_REVERSEBYTES, enhanced limits |
| Covenants | Enabled via introspection |
| Parameter | Value | Purpose |
|---|---|---|
| nMinimumChainWork | Fork height chainwork | Reject low-work attack chains |
| Checkpoint | Block 53,200 hash | Anchor fork point |
| assumevalid | Block 53,200 hash | Speed initial sync |
BCH2's ASERT half-life transitions automatically from 1 hour to 2 days at a predetermined block height. No hard fork is required.
| Parameter | Launch (Block 53,201+) | Post-Transition (Block 92,736+) |
|---|---|---|
| ASERT Half-Life | 3,600 seconds (1 hour) | 172,800 seconds (2 days, matching BCHN) |
| Transition | Automatic | — |
| Timeline | Fork activation | ~274 days (~9 months) after fork |
The half-life is determined by block height:
if (height < 92736):
nASERTHalfLife = 3600 (1 hour)
else:
nASERTHalfLife = 172800 (2 days, matching BCHN)
Block 92,736 corresponds to epoch 46, approximately 9.15 months after the fork at block 53,200. The ASERT anchor parameters remain unchanged — only the half-life constant changes.
A fixed transition height eliminates the need for a coordinated hard fork and the subjective criteria that would accompany it. By 9 months post-launch, the network will have had sufficient time to establish stable hashrate and miner diversity. The transition is built into the consensus rules from genesis, ensuring all nodes agree on the change without additional coordination.
| Network | Transition Height | Timeline |
|---|---|---|
| Mainnet | 92,736 | ~9 months after fork |
| Testnet | 40,320 | ~9 months |
| Regtest | 432 | Low (for testing) |
BCH2 follows Bitcoin's original emission schedule:
| Era | Block Range | Reward | Supply Added |
|---|---|---|---|
| 1 | 0 - 209,999 | 50 BCH2 | 10,500,000 |
| 2 | 210,000 - 419,999 | 25 BCH2 | 5,250,000 |
| 3 | 420,000 - 629,999 | 12.5 BCH2 | 2,625,000 |
| 4 | 630,000 - 839,999 | 6.25 BCH2 | 1,312,500 |
| ... | ... | ... | ... |
| Total | - | - | 21,000,000 |
The Forge Pool provides mining infrastructure for BCH2 with a globally distributed architecture:
Connection Details:
Stratum: stratum+tcp://pool.bch2.org:3333
Features:
- Single Address Connection — Connect to one address with automatic routing to nearest regional proxy
- Global Proxy Network — Low-latency connections from any location
- Web UI Controls — Change mining method (solo/pool) and difficulty settings without reconfiguring your miner
- Solo Payout — Mine solo and receive full block rewards directly to your wallet
- Vardiff Support — Automatic difficulty adjustment based on your hashrate
- PPLNS Payout — Fair reward distribution based on shares contributed
- Minimum Payout: 5 BCH2
- Pool Fee: 1% (0.5% for solo mining)
BCH2's accessible difficulty makes solo mining viable. Configure your miner to connect directly to your BCH2 node:
# bitcoin.conf for solo mining
server=1
rpcuser=your_username
rpcpassword=your_password
rpcallowip=127.0.0.1
BCH2 operates seed nodes across multiple continents:
| Location | Region |
|---|---|
| Dallas, USA | North America (Primary/Forge Pool) |
| Los Angeles, USA | North America |
| New Jersey, USA | North America |
| Frankfurt, Germany | Europe |
| Singapore | Asia |
| Service | URL |
|---|---|
| Website | https://bch2.org |
| Block Explorer | https://explorer.bch2.org |
| Mining Pool | https://pool.bch2.org |
| Source Code | https://github.com/BitcoincashII |
BCH2 is compatible with Bitcoin Cash wallet infrastructure:
- Standard BIP32/39/44 HD wallet derivation
- CashAddr address encoding (prefix:
bitcoincashii:) - Standard transaction format (with SIGHASH_FORKID)
- Native BCH2 derivation path: m/44'/145'/0'/0/x
- Legacy format (1xxx) remains valid for display compatibility
Address Format:
bitcoincashii:qp63uahgrxged4z5jswyt5dn5v3lzsem6cy74rqsfs
Balance and UTXO queries use scripthash-based methods for universal address type support:
scripthash = REVERSE(SHA256(scriptPubKey))
| Method | Purpose |
|---|---|
| blockchain.scripthash.get_balance | Confirmed and unconfirmed balance |
| blockchain.scripthash.listunspent | Available UTXOs |
| blockchain.scripthash.get_history | Transaction history |
| blockchain.transaction.broadcast | Submit signed transaction |
| Category | Amount | Percentage |
|---|---|---|
| Fork distribution to BC2 holders | All BC2 at fork | 100% of existing |
| Premine | 0 BCH2 | 0% |
| Developer allocation | 0 BCH2 | 0% |
| Foundation reserve | 0 BCH2 | 0% |
All new BCH2 enters circulation exclusively through mining:
- Block Reward: 50 BCH2 per block
- Miner Share: 100%
- Developer Fee: 0%
- Distribution Method: Proof of Work only
| Milestone | Circulating Supply |
|---|---|
| Fork | All BC2 in existence |
| Block 100,000 | ~5,000,000 BCH2 |
| First Halving (210,000) | ~10,500,000 BCH2 |
| Second Halving (420,000) | ~15,750,000 BCH2 |
| Maximum Supply | 21,000,000 BCH2 |
BCH2 operates without central authority:
- No Foundation: No legal entity controls BCH2
- No Benevolent Dictator: No individual has special protocol authority
- Open Source: All code publicly auditable under MIT license
- Community Funded: Development supported by voluntary contribution
Changes to BCH2 consensus rules require:
- Proposal: Public specification of proposed changes
- Review: Community and developer analysis
- Implementation: Code development and testing
- Signaling: Miner and node operator support measurement
- Activation: Coordinated upgrade at specified height/time
BCH2 intends to maintain compatibility with Bitcoin Cash protocol improvements:
- ASERT DAA (implemented)
- 32MB blocks (implemented)
- Native introspection (implemented)
- Future BCH upgrades evaluated for adoption
- ✅ Fork from BC2 at designated block height
- ✅ ASERT difficulty adjustment active
- ✅ 32MB block size enabled
- ✅ CashAddr addressing (
bitcoincashii:) - ✅ Global node network operational
- ✅ Mining pool (Forge Pool) live
- ✅ Full node software released
- Desktop wallets (Electron Cash fork)
- Mobile wallets (Android, iOS)
- Web wallet
- Block explorer enhancements
- Additional mining pools
- Exchange listings
- Merchant payment tools
- Hardware wallet support (Ledger, Trezor)
- CashFusion privacy implementation
- CashTokens integration
- Developer SDK and documentation
- Continued BCH protocol alignment
- Privacy enhancements
- Token/NFT ecosystem development
- Continued decentralization of infrastructure
- Community-driven feature development
BCH2 uses the same SHA-256 proof-of-work algorithm that has secured Bitcoin since 2009:
- No novel cryptographic assumptions
- Billions of dollars of mining hardware compatible
- 15+ years of real-world security validation
BCH2 implements SIGHASH_FORKID replay protection:
- Transactions signed for BCH2 are invalid on BC2
- Transactions signed for BC2 are invalid on BCH2
- Users cannot accidentally spend on the wrong chain
BCH2 is based on:
- BitcoinII Core v27.1 (based on extensively audited Bitcoin Core)
- Bitcoin Cash protocol changes (battle-tested since 2017)
- CashAddr implementation (standard BCH code)
- ASERT implementation (deployed on BCH since 2020)
BCH2 represents a synthesis of Bitcoin Cash's proven protocol improvements with a fair distribution model. By forking from BC2 at block height 53,200, BCH2 provides:
For BC2 Holders:
- Automatic 1:1 fork distribution of BCH2
- No action required—same keys work on both chains
- Continued value from BC2 investment
For Miners:
- Accessible difficulty levels
- ASERT with 1-hour half-life ensuring rapid recovery from difficulty attacks
- Planned half-life normalization to 2 days once hashrate stabilizes
- 100% of block rewards (no developer fee)
For Users:
- 32MB blocks for scalability
- Low fees enabled by block space
- CashAddr for user-friendly addresses
- Fast confirmations via consistent block times
- Full BCH script capabilities including covenants and introspection
For the Ecosystem:
- No premine or insider allocation
- Community governance
- Open source development
- Bitcoin Cash protocol compatibility
- Clear upgrade path toward full BCHN parameter alignment
BCH2 is cryptocurrency as it was meant to be: open, accessible, fair, and truly decentralized.
- Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System"
- Bitcoin Cash Protocol Documentation, https://documentation.cash/
- Sechet, A. (2020). "ASERT DAA Specification"
- CashAddr Specification, https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md
- BC2 (BitcoinII) Technical Documentation
- BCHN v29.0.0 ASERT Implementation Reference
Download:
https://bch2.org/download
Configuration (~/.bch2/bitcoin.conf):
server=1
daemon=1
listen=1
port=8339
rpcport=8342
rpcuser=your_username
rpcpassword=your_secure_password
# Seed nodes
addnode=144.202.73.66:8339
addnode=108.61.190.83:8339
addnode=64.176.215.202:8339
addnode=139.180.132.24:8339
Start:
bitcoincashIId -daemonPool Mining:
Pool: stratum+tcp://pool.bch2.org:3333
Worker: your_bch2_address
Password: x
Solo Mining: Configure your ASIC to connect to your local node's RPC port.
If you held BC2 at block 53,200:
- Export your BC2 private keys (WIF format)
- Import into BCH2 wallet
- Your BCH2 balance equals your BC2 balance at fork
| Feature | BTC | BCH | BC2 | BCH2 |
|---|---|---|---|---|
| Block Size | 4MB weight | 32MB | 4MB weight | 32MB |
| Difficulty Adj. | 2016 blocks | ASERT (2-day) | 2016 blocks | ASERT (1-hour launch / 2-day post-upgrade) |
| SegWit | Yes | No | Yes | No (post-fork) |
| Address Format | bech32 | CashAddr | bech32 | CashAddr |
| Replay Protection | — | SIGHASH_FORKID | — | SIGHASH_FORKID |
| Block Time | 10 min | 10 min | 10 min | 10 min |
| Supply Cap | 21M | 21M | 21M | 21M |
| RBF | Yes | No | Yes | No |
| Aspect | BCH2 | BCHN | Convergence Plan |
|---|---|---|---|
| Chain History | BC2 blocks 0–53,200 | BCH genesis chain | N/A (permanent) |
| ASERT Half-Life | 1 hour (transitions at block 92,736) | 2 days | Automatic at block 92,736 |
| P2P Port | 8339 | 8333 | N/A (permanent) |
| Address Prefix | bitcoincashii: | bitcoincash: | N/A (permanent) |
| Consensus Rules | Identical post-fork | Reference | Maintain parity |
| Script VM | Identical | Reference | Maintain parity |
Q: Is BCH2 a fork of Bitcoin Cash? A: BCH2 is a fork of BC2 (BitcoinII) at block height 53,200 that adopts Bitcoin Cash consensus rules. It preserves BC2's blockchain history while upgrading to BCH's protocol improvements.
Q: Do I need to do anything to receive my BCH2? A: No. If you controlled BC2 private keys at block 53,200, you automatically hold the same amount of BCH2 by virtue of the fork. Simply import your keys into a BCH2 wallet.
Q: Why fork BC2 instead of BCH directly? A: BC2 had a fair distribution from its genesis and accessible mining. By forking BC2 and upgrading to BCH rules, BCH2 combines fair distribution with proven protocol improvements.
Q: Is SegWit supported? A: New SegWit outputs cannot be created after the fork. However, existing SegWit UTXOs from BC2's history (P2WPKH, P2WSH, P2TR, and P2SH-wrapped variants) can be spent using BCH2's witness-via-scriptSig mechanism, which moves signature data from the witness field into the traditional scriptSig. Taproot key-path spending is supported; Taproot script-path spending is not — users with complex Taproot scripts should migrate their coins before the fork. RBF is also disabled.
Q: What wallet should I use? A: Any wallet supporting CashAddr format can be adapted for BCH2. Official wallets will be released following the Electron Cash codebase.
Q: How do I mine BCH2? A: Connect any SHA-256 ASIC to pool.bch2.org:3333 or run solo mining against your own node.
Q: Why is the ASERT half-life different from BCH? A: BCH2 launches with a 1-hour ASERT half-life (vs BCH's 2-day half-life) to protect against difficulty manipulation attacks that could cripple a new chain with limited hashrate. The half-life automatically transitions to 2 days at block 92,736 (~9 months after fork) — no hard fork required.
Q: When is the fork happening? A: The fork occurs at BC2 block height 53,200, with a target launch of approximately March 7–9, 2026. BC2 holders should ensure they control their private keys before this date.
BCH2: Bitcoin Cash II — Fair Distribution, Proven Protocol, Decentralized Future
This document is dated February 2026. Updates will be published at https://bch2.org/whitepaper