BCH2 Logo II BCH2

← Retour à l'accueil

Février 2026

BCH2 : Bitcoin Cash II

Un retour au minage décentralisé par une distribution équitable

Résumé

BCH2 (Bitcoin Cash II) est une cryptomonnaie SHA-256 qui associe le protocole Bitcoin Cash éprouvé à un modèle de distribution équitable, via un fork 1:1 de BC2 (BitcoinII). En se séparant de BC2 à la hauteur de bloc 53 200, BCH2 hérite de tout l'historique des transactions de BC2 tout en adoptant les règles de consensus de Bitcoin Cash : algorithme d'ajustement de difficulté ASERT (avec une demi-vie d'une heure, résistante aux attaques, au lancement), blocs de 32 Mo, adressage CashAddr et l'ensemble des mises à niveau du protocole BCH jusqu'à la mise à niveau 11 (ABLA).

Alors que Bitcoin et ses dérivés sont dominés par des exploitations minières industrielles, BCH2 propose un nouveau départ avec des niveaux de difficulté accessibles. Sans prémine, sans frais de développement et avec une distribution équitable 1:1 aux détenteurs de BC2, BCH2 marque un retour à l'esprit du minage décentralisé qui a fait la révolution Bitcoin.

1. Introduction

1.1 La vision d'origine

Quand Satoshi Nakamoto a lancé Bitcoin en 2009, n'importe qui avec un ordinateur personnel pouvait miner des blocs et gagner des récompenses. Cette accessibilité était essentielle au caractère décentralisé de Bitcoin : des milliers de mineurs indépendants sécurisaient le réseau, chacun avec une chance équitable.

1.2 L'évolution de Bitcoin

À mesure que Bitcoin a grandi, les désaccords sur la mise à l'échelle et la philosophie ont mené à des évolutions majeures :

  • 2017 : Bitcoin Cash (BCH) s'est séparé de Bitcoin au bloc 478 558, portant la taille de bloc à 8 Mo (puis 32 Mo) pour permettre plus de transactions et des frais plus bas. BCH n'a cessé de s'améliorer : algorithme d'ajustement de difficulté ASERT en 2020 et nombreuses améliorations du protocole jusqu’en 2025.
  • 2025 : BC2 (BitcoinII) a été lancé comme une implémentation neuve fondée sur Bitcoin Core v27, avec son propre bloc de genèse : une chaîne vierge pour l'expérimentation et de nouveaux usages.
  • 2026 : BCH2 (Bitcoin Cash II) se sépare de BC2 à la hauteur 53 200, conservant l'historique complet de BC2 tout en adoptant les règles de consensus de Bitcoin Cash. D'où une combinaison inédite : la distribution initiale équitable de BC2 et les améliorations de protocole éprouvées de BCH.

1.3 Le problème aujourd'hui

La difficulté du réseau Bitcoin a atteint des niveaux astronomiques, tout comme BCH et la plupart des dérivés SHA-256. Cela pose plusieurs problèmes :

  1. Domination industrielle — Seules les exploitations de grande échelle, avec électricité bon marché et achats d'ASIC en gros, minent de façon rentable sur les grandes chaînes.
  2. Exclusion du mineur à domicile — Avec de petits appareils, un particulier n'a quasiment aucune chance de trouver un bloc sur un réseau à forte difficulté.
  3. Centralisation par les pools — Les mineurs sont poussés vers les pools, paient des frais et doivent faire confiance aux opérateurs, ce qui affaiblit le caractère pair-à-pair de la cryptomonnaie.
  4. Algorithmes de difficulté hérités — Les chaînes qui conservent la période d'ajustement de 2016 blocs de Bitcoin peuvent connaître des écarts extrêmes de temps de bloc quand le hashrate fluctue.

1.4 La solution BCH2

BCH2 répond à ces problèmes en :

  • Partir d'un niveau de difficulté accessible, héritée des premiers blocs de BC2
  • Mettre en œuvre ASERT avec une demi-vie d'une heure, pour que la difficulté se rétablisse vite après une attaque par manipulation
  • Offrir des blocs de 32 Mo pour la montée en charge future
  • Utiliser le format CashAddr pour des adresses commodes
  • Rester totalement compatible avec les améliorations du protocole Bitcoin Cash
  • Passage automatique de la demi-vie ASERT d'une heure à deux jours au bloc 92 736 (environ 9 mois après le fork), sans hard fork

2. Pourquoi BCH2

2.1 Principes d'un lancement équitable

BCH2 rejette les modèles de jetons extractifs qui ont gangrené les lancements récents :

Pas de prémine : La totalité de l'offre BCH2 au fork est distribuée aux détenteurs de BC2 selon leurs avoirs au bloc du fork. Aucune pièce n'est créée pour des développeurs, des fondations ou des initiés.

Pas de frais de développement : 100 % des récompenses de bloc vont aux mineurs. Le développement est financé par la communauté et bénévole, il n'est pas prélevé sur les récompenses.

Pas d'ICO/IEO : BCH2 n'est ni vendu ni pré-attribué. La distribution se fait par le fork BC2 et le minage continu.

Base de code éprouvée : BCH2 repose sur BitcoinII Core v27.1, le socle même qui sécurise des milliards de valeur sur Bitcoin et ses dérivés.

2.2 Distribution du fork aux détenteurs de BC2

Suivant le précédent établi par Bitcoin Cash en 2017, BCH2 reconnaît les détenteurs de BC2 par un fork 1:1 :

  • Tous les soldes BC2 au bloc du fork sont crédités en BCH2 (environ 2 660 000 pièces au moment du fork)
  • Qui détient les clés privées BC2 détient automatiquement les BCH2 correspondants
  • Ni inscription, ni réclamation, ni KYC : il suffit d'importer les clés dans un portefeuille BCH2

Ce modèle garantit :

  • Une distribution équitable pour ceux qui ont soutenu BC2
  • Une liquidité immédiate dès le premier jour
  • Aucune concentration de l'offre entre les mains des développeurs
  • Les intérêts des premiers soutiens alignés sur le succès du réseau

2.3 Rendre le minage à nouveau accessible

La difficulté de BCH2 au fork offre des chances réalistes aux petits mineurs :

  • Mineurs « loterie » bienvenus — Des appareils comme Bitaxe, Nerdminer et autres mineurs à faible hashrate ont une réelle chance de trouver des blocs.
  • Le minage à domicile est viable — Les ASIC grand public peuvent concourir pour la récompense de bloc complète.
  • Le minage en solo revient — Un particulier peut miner directement, sans devoir rejoindre un pool.
  • Croissance naturelle — À mesure que l'adoption progresse, la difficulté monte organiquement avec le réseau.

3. Spécifications techniques

3.1 Paramètres de consensus

ParamètreValeur
AlgorithmeSHA-256 (proof-of-work)
Temps de bloc cible10 minutes (600 secondes)
Récompense de bloc50 BCH2 (selon le calendrier de halving de Bitcoin)
Intervalle de halving210 000 blocs
Offre maximale21,000,000 BCH2
Limite de taille de bloc32 MB
Taille minimale de transaction65 octets
Ajustement de difficultéASERT DAA (aserti3-2d)
Demi-vie ASERT (lancement)3 600 secondes (1 heure)
Demi-vie ASERT (après mise à niveau)172 800 secondes (2 jours, comme BCHN)
Protection contre la répétitionSIGHASH_FORKID

3.2 Paramètres du fork

ParamètreValeur
Origine du forkChaîne BC2 (BitcoinII)
Logiciel de baseBitcoinII Core v27.1
Hauteur du fork53,200
Historique avant le forkBlocs BC2 0–53 200 (compatibles BTC)
Règles après le forkConsensus BCH complet (actif à partir du bloc 53 201)
Distribution du forkTout le BC2 existant au bloc du fork (1:1)
Bloc genèse
0000000028f062b221c1a8a5cf0244b1627315f7aa5b775b931cfec46dc17ceb
Lancement visé~7–9 mars 2026

3.3 Configuration réseau

ParamètreValeur
Port P2P (mainnet)8339
Port P2P (testnet)18338
Port RPC (mainnet)8342
Magic réseau0xb2c2b2c2
Format d'adresseCashAddr
Préfixe d'adressebitcoincashii:
Répertoire de données~/.bitcoincashII

3.4 Hauteurs d'activation avant le fork (historique BC2)

Ces activations ont eu lieu dans l'historique de BC2 et sont conservées dans BCH2 :

Mise à niveauHauteur
BIP34 (hauteur dans la coinbase)250
BIP65 (CHECKLOCKTIMEVERIFY)260
BIP66 (signatures DER strictes)270
BIP68/112/113 (CSV)280
SegWit (avant le fork uniquement)290

3.5 Activations BCH2 (après le fork)

Toutes les mises à niveau du protocole Bitcoin Cash s'activent simultanément au bloc 53 201 :

Mise à niveauDate d'origine BCHActivation de BCH2
UAHF (blocs de 8 Mo, SIGHASH_FORKID)1er août 2017Bloc 53 201
New DAA13 novembre 2017Bloc 53 201
Magnetic Anomaly (CTOR, OP_CHECKDATASIG)15 novembre 2018Bloc 53 201
Graviton (signatures Schnorr)15 novembre 2019Bloc 53 201
Phonon (OP_REVERSEBYTES, SigChecks)15 mai 2020Bloc 53 201
Axion (ASERT DAA)15 novembre 2020Bloc 53 201
Mise à niveau 8 (introspection native, entiers 64 bits)15 mai 2022Bloc 53 201
Mise à niveau 9 (limites CHIP, P2SH32)15 mai 2023Bloc 53 201
Mise à niveau 10 (limites de la VM, BigInt)15 mai 2024Bloc 53 201
Mise à niveau 11 (ABLA)15 mai 2025Bloc 53 201

3.6 Fonctions désactivées (vs BTC/BC2)

Les fonctions BTC/BC2 suivantes sont désactivées après le fork, conformément au consensus BCH :

FonctionÉtatRaison
SegWit (BIP141)Pas de nouvelles sortiesLes nouvelles sorties SegWit sont rejetées après le fork ; les UTXO SegWit existants restent dépensables via scriptSig (voir §5.4)
Taproot (BIP340-342)Par clé uniquementLes nouvelles sorties Taproot sont rejetées ; les P2TR existants ne sont dépensables que par scriptSig en chemin de clé (voir §5.4)
Replace-By-Fee (RBF)DésactivéBCH applique la politique first-seen

3.7 Algorithme d'ajustement de difficulté ASERT

BCH2 emploie ASERT (Absolutely Scheduled Exponentially Rising Targets), l'algorithme d'ajustement de difficulté adopté par Bitcoin Cash en novembre 2020 (mise à niveau Axion). BCH2 utilise aserti3-2d exactement tel qu'implémenté dans BCHN v29.0.0, avec une demi-vie modifiée pour la sécurité au lancement.

Algorithme central :

ASERT calcule la difficulté à partir du temps écoulé depuis un « bloc d'ancrage » (pour BCH2, le bloc du fork), en visant exactement 10 minutes par bloc en moyenne :

next_target = anchor_target * 2^((actual_time - scheduled_time) / halflife)

Avec :

  • anchor_target = cible de difficulté au bloc d'ancrage (bloc du fork)
  • actual_time = temps écoulé depuis le parent du bloc d'ancrage
  • scheduled_time = temps attendu, soit l'écart de hauteur × 600 secondes
  • halflife = constante de temps qui règle la vitesse d'ajustement

Demi-vie ASERT : paramètre critique au lancement :

ParamètreBCH2 (lancement)BCHN
ASERT Half-Life3 600 secondes (1 heure)172 800 secondes (2 jours)
Vitesse d'ajustement48× plus rapideStandard
Récupération après un pic de difficulté de 10×~7 heures~6,6 jours

Pourquoi une demi-vie d'une heure :

Une chaîne récente au hashrate limité (~1 PH/s) est vulnérable aux attaques par manipulation de la difficulté. Un acteur disposant d'une forte puissance peut miner vite pour faire grimper la difficulté, puis retirer sa puissance : les mineurs honnêtes ne trouvent plus de blocs à cette difficulté gonflée. Avec la demi-vie de 2 jours de BCHN, se remettre d'un pic de 10× prendrait environ 6,6 jours — le réseau serait inutilisable près d'une semaine, les mineurs partiraient vers des chaînes rentables, au risque d'une spirale mortelle.

Avec la demi-vie d'une heure de BCH2, la même attaque ne provoque qu'environ 7 heures de blocs lents avant le retour à la normale. Les mineurs peuvent attendre ou continuer à miner, et le coût de l'attaquant est gaspillé.

Analyse du compromis :

Mesure1-Hour Half-Life2-Day Half-Life
Récupération après attaque~7 heures~6,6 jours
Volatilité de la difficultéPlus élevéPlus faible
Variance du temps de blocPlus élevéPlus faible
Adapté aux petites chaînesMeilleurMoins bon
Adapté aux grandes chaînesMoins bonMeilleur

La demi-vie d'une heure convient à la phase de lancement de BCH2, au hashrate limité. La volatilité accrue est un compromis acceptable au regard de la résistance aux attaques.

Configuration de l'ancrage ASERT :

ParamètreValeur mainnet
Hauteur d'ancrage53,201
nBits d'ancrage0x1903a30c
Heure du parent d'ancrageÀ déterminer (horodatage Unix du bloc 53 200 une fois miné)
Difficulté initiale attendue~140 MH (0x1903a30c)
Hashrate cible1 PH/s pour des blocs de 10 min

4. Format d'adresse

4.1 Spécification CashAddr

BCH2 utilise le format CashAddr mis au point par Bitcoin Cash, qui apporte :

  • Un préfixe lisible qui identifie le réseau
  • Détection d'erreurs par somme de contrôle en code BCH
  • Un encodage insensible à la casse, plus simple à saisir
  • Une distinction nette avec les adresses Bitcoin/BC2

4.2 Exemples d'adresses

P2PKH (Pay to Public Key Hash) :

bitcoincashii:qz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcr7hxlmnj

P2SH (Pay to Script Hash) :

bitcoincashii:pz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcfnk4xmwy

4.3 Indicateurs de type d'adresse

PréfixeType
qP2PKH (standard)
pP2SH (multisig/scripts)

5. Paramètres de transaction

5.1 Spécifications des transactions

ParamètreBCH2BCHN
Algorithme de signatureECDSA + SchnorrECDSA + Schnorr
Drapeaux sighashSIGHASH_FORKID obligatoireSIGHASH_FORKID obligatoire
Version de transaction1, 21, 2
Taille max. de TX standard100 KB100 KB
Limite de poussière182 satoshis182 satoshis
Frais minimaux de relais1 sat/octet1 sat/octet

5.2 Protection contre la répétition

MécanismeImplémentation
SIGHASH_FORKIDObligatoire pour toutes les transactions après le fork
Fork ID0x000000 (standard BCH)
EffetLes transactions valides sur BCH2 sont invalides sur BC2/BTC

Les signatures incluent le fork ID dans la préimage du sighash, ce qui empêche de rejouer une transaction d'une chaîne à l'autre. Les transactions BCH2 signées après le bloc 53 200 sont invalides sur BC2, et inversement.

5.3 Protection contre la double dépense (DSProof)

BCH2 intègre DSProof (preuve de double dépense), un mécanisme au niveau du protocole pour détecter en temps réel les tentatives de double dépense sur des transactions non confirmées. Conçu à l'origine pour Bitcoin Cash, DSProof renforce la sécurité sans confirmation pour les commerçants et les prestataires de paiement.

ComposantDétail
Type de message P2Pdsproof-beta
Couche de détectionIntégration au mempool
Interface RPCInterroger l'état de double dépense par transaction
PropagationDiffusion à tout le réseau à la détection

Lorsqu'un nœud détecte des transactions conflictuelles dépensant la même entrée, il construit et diffuse un message DSProof sur le réseau. Les commerçants et portefeuilles à l'écoute de ces alertes peuvent signaler une transaction suspecte en quelques secondes, sans attendre la confirmation en bloc.

Le commerce sans confirmation en devient plus sûr — un cas d'usage central de la monnaie électronique pair-à-pair.

5.4 Migration des UTXO SegWit (witness via scriptSig)

BC2 a hérité de SegWit de Bitcoin : l'ensemble des UTXO au bloc du fork contient donc des pièces verrouillées dans des sorties SegWit (P2WPKH, P2WSH, P2TR et variantes encapsulées en P2SH). Comme BCH2 supprime les règles de consensus SegWit, ces UTXO deviendraient normalement indépensables après le fork.

BCH2 règle cela avec witness via scriptSig — un mécanisme de migration qui permet de dépenser les UTXO SegWit existants en plaçant les données de signature dans le champ scriptSig traditionnel plutôt que dans le champ witness.

Type de sortiePre-Fork (BC2)Post-Fork (BCH2)
P2WPKHscriptSig: empty, witness: [sig, pubkey]scriptSig: [sig, pubkey], witness: empty
P2WSHscriptSig: empty, witness: [...args, script]scriptSig: [...args, script], witness: empty
P2TR (key-path)scriptSig: empty, witness: [schnorr_sig]scriptSig: [schnorr_sig], witness: empty
P2SH-P2WPKHscriptSig: [redeemScript], witness: [sig, pubkey]scriptSig: [sig, pubkey, redeemScript], witness: empty

Processus de vérification :

  • P2WPKH (v0, 20 octets) : attend [signature, clé publique] dans scriptSig. Le nœud construit un script P2PKH implicite et vérifie par rapport à lui.
  • P2WSH (v0, 32 octets) : attend [...arguments, script] dans scriptSig. Le nœud vérifie que SHA256(script) correspond au hachage de la sortie.
  • P2TR (v1, 32 octets) : attend [signature Schnorr] dans scriptSig, pour la dépense par voie de clé uniquement.
  • Encapsulé en P2SH : le script de rachat figure dans scriptSig, à côté des données de signature.

Sécurité :

  • La même sécurité cryptographique que SegWit : des signatures valides restent exigées
  • SIGHASH_FORKID est imposé à toutes les signatures après le fork (protection contre le rejeu)
  • La dépense par la voie de script de Taproot n'est pas prise en charge : seule la voie de clé l'est. Qui utilise des scripts Taproot complexes devrait déplacer ses pièces avant le fork.

Important : ce mécanisme ne concerne que les UTXO SegWit existant au bloc du fork ou avant. Après le fork, aucune nouvelle sortie SegWit ne peut être créée : le consensus BCH2 les rejette.

Algorithme de sighash :

Sur BCH2, les UTXO SegWit se dépensent avec l'algorithme de sighash BIP143 et 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)
))

La signature est placée dans scriptSig et non dans witness : scriptSig: <signature> <pubkey>, witness: (vide)

Types d'adresses pris en charge pour la migration :

TypeFormatChemin de dérivationExemple
Legacy P2PKH1xxxm/44'/0'/0'/0/x1A1zP1eP5QGefi2DMPTfTL...
Native SegWit P2WPKHbc1q...m/84'/0'/0'/0/xbc1qar0srrr7xfkvy5l643...
Wrapped SegWit P2SH-P2WPKH3xxxm/49'/0'/0'/0/x3J98t1WpEZ73CNmQviecrn...

5.5 Procédure de réclamation de la distribution du fork

BCH2 distribue 1:1 tous les soldes BC2 à la hauteur de fork 53 200. La procédure de réclamation prend en charge tous les types d'adresses via une interface de portefeuille unifiée.

Dérivation et balayage :

Le portefeuille dérive les adresses d'une phrase mnémonique BIP39 selon les chemins de dérivation standards :

PathTypeAdresses analysées
m/44'/0'/0'/0/0–19Legacy (P2PKH)Externe (réception)
m/44'/0'/0'/1/0–19Legacy (P2PKH)Interne (monnaie)
m/84'/0'/0'/0/0–19Native SegWit (P2WPKH)Externe (réception)
m/84'/0'/0'/1/0–19Native SegWit (P2WPKH)Interne (monnaie)
m/49'/0'/0'/0/0–19Wrapped SegWit (P2SH-P2WPKH)Externe (réception)
m/49'/0'/0'/1/0–19Wrapped SegWit (P2SH-P2WPKH)Interne (monnaie)

Les deux chaînes d'adresses, externe (réception) et interne (change), sont balayées pour repérer tous les UTXO éligibles au fork.

Protection contre les abus :

Pour empêcher une double réclamation en changeant de type d'adresse, le portefeuille vérifie l'origine du solde :

isFromForkDistribution = (BC2_balance > 0)

Si un solde BCH2 existe alors que le solde BC2 correspondant est nul, les fonds ont été reçus après le fork et sont signalés comme ne provenant pas de la distribution. Cela bloque le vecteur d'attaque suivant :

  1. Réclamer des BCH2 sur une adresse SegWit
  2. Déplacer les fonds BC2 d'origine vers une adresse legacy
  3. Tenter une nouvelle réclamation sur l'adresse legacy

Le portefeuille affiche des avertissements appropriés, distinguant les dépôts postérieurs au fork des soldes issus de la distribution.

6. Capacités de script (après le fork)

BCH2 prend en charge l'intégralité du jeu d'instructions de script BCH :

CatégorieCapacités
CryptographiqueOP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKDATASIG, OP_CHECKDATASIGVERIFY
Type de signatureECDSA (hérité), Schnorr (après Graviton)
IntrospectionOpcodes d'introspection natifs (mise à niveau 8)
ArithmétiqueEntiers 64 bits, BigInt (mise à niveau 10)
PileOP_REVERSEBYTES, limites étendues
CovenantsActivé via l'introspection

7. Paramètres de sécurité de la chaîne

ParamètreValeurRôle
nMinimumChainWorkChainwork à la hauteur du forkRejeter les chaînes d'attaque à faible travail
Point de contrôleHash du bloc 53 200Point de fork d'ancrage
assumevalidHash du bloc 53 200Accélérer la synchronisation initiale

8. Transition de la demi-vie ASERT

8.1 Transition automatique

La demi-vie ASERT de BCH2 passe automatiquement d'une heure à deux jours à une hauteur de bloc fixée d'avance. Aucun hard fork n'est nécessaire.

ParamètreLancement (bloc 53 201+)Après la transition (bloc 92 736+)
ASERT Half-Life3 600 secondes (1 heure)172 800 secondes (2 jours, comme BCHN)
TransitionAutomatique—
CalendrierActivation du fork~274 jours (~9 mois) après le fork

8.2 Mécanisme de transition

La demi-vie est déterminée par la hauteur de bloc :

if (height < 92736):
    nASERTHalfLife = 3600       (1 hour)
else:
    nASERTHalfLife = 172800     (2 days, matching BCHN)

Le bloc 92 736 correspond à l'époque 46, environ 9,15 mois après le fork au bloc 53 200. Les paramètres d'ancrage ASERT restent inchangés : seule la constante de demi-vie change.

8.3 Justification

Une hauteur de transition fixe évite un hard fork coordonné et les critères subjectifs qui l'accompagneraient. Au bout de 9 mois, le réseau aura eu le temps d'établir un hashrate stable et une diversité de mineurs. La transition est inscrite dans les règles de consensus dès l'origine : tous les nœuds s'accordent sur le changement sans concertation supplémentaire.

RéseauHauteur de transitionCalendrier
Mainnet92,736~9 mois après le fork
Testnet40,320~9 mois
Regtest432Faible (pour les tests)

9. Minage

9.1 Calendrier des récompenses de bloc

BCH2 suit le calendrier d'émission d'origine de Bitcoin :

EraPlage de blocsRécompenseOffre ajoutée
10 – 209,99950 BCH210,500,000
2210,000 – 419,99925 BCH25,250,000
3420,000 – 629,99912.5 BCH22,625,000
4630,000 – 839,9996.25 BCH21,312,500
............
Total——21,000,000

9.2 Pool de minage

Le Forge Pool fournit l'infrastructure de minage de BCH2, avec une architecture répartie dans le monde entier :

Paramètres de connexion :

Stratum: stratum+tcp://pool.bch2.org:3333

Fonctionnalités :

  • Une seule adresse de connexion — Connectez-vous à une adresse unique, avec routage automatique vers le proxy régional le plus proche
  • Réseau mondial de proxys — Des connexions à faible latence depuis n'importe où
  • Commandes via l'interface web — Changez de mode de minage (solo/pool) et de réglages de difficulté sans reconfigurer votre machine
  • Paiement en solo — Minez en solo et recevez la récompense de bloc entière directement dans votre portefeuille
  • Prise en charge du vardiff — Ajustement automatique de la difficulté selon votre hashrate
  • Paiement PPLNS — Répartition équitable de la récompense selon les parts fournies
  • Paiement minimum : 5 BCH2
  • Frais du pool : 1 % (0,5 % en minage solo)

9.3 Minage solo

La difficulté accessible de BCH2 rend le minage en solo viable. Configurez votre machine pour se connecter directement à votre nœud BCH2 :

# bitcoincashII.conf for solo mining
server=1
rpcuser=your_username
rpcpassword=your_password
rpcallowip=127.0.0.1

10. Infrastructure

10.1 Réseau mondial de nœuds

BCH2 exploite des nœuds d'amorçage sur plusieurs continents :

EmplacementRégion
Dallas, États-UnisAmérique du Nord (principal/Forge Pool)
Los Angeles, États-UnisAmérique du Nord
New Jersey, États-UnisAmérique du Nord
Francfort, AllemagneEurope
SingapourAsia

10.2 Services

ServiceURL
Site webhttps://bch2.org
Explorateur de blocshttps://explorer.bch2.org
Pool de minagehttps://pool.bch2.org
Code sourcehttps://github.com/BitcoincashII

10.3 Compatibilité des portefeuilles

BCH2 est compatible avec l'infrastructure de portefeuilles de Bitcoin Cash :

  • Dérivation HD standard BIP32/39/44
  • Encodage d'adresses CashAddr (préfixe : bitcoincashii:)
  • Format de transaction standard (avec SIGHASH_FORKID)
  • Chemin de dérivation propre à BCH2 : m/44'/145'/0'/0/x
  • Le format legacy (1xxx) reste valide pour la compatibilité d'affichage

Format d'adresse :

bitcoincashii:qp63uahgrxged4z5jswyt5dn5v3lzsem6cy74rqsfs

10.4 Intégration du protocole Electrum

Les requêtes de solde et d'UTXO passent par des méthodes fondées sur le scripthash, afin de prendre en charge tous les types d'adresses :

scripthash = REVERSE(SHA256(scriptPubKey))
MéthodeRôle
blockchain.scripthash.get_balanceSolde confirmé et non confirmé
blockchain.scripthash.listunspentUTXO disponibles
blockchain.scripthash.get_historyHistorique des transactions
blockchain.transaction.broadcastSoumettre une transaction signée

11. Tokenomics

11.1 Répartition de l'offre au fork

CatégorieMontantPourcentage
Distribution du fork aux détenteurs de BC2Tout le BC2 au fork100 % de l'existant
Prémine0 BCH20%
Allocation aux développeurs0 BCH20%
Réserve de fondation0 BCH20%

11.2 Distribution continue

Tout nouveau BCH2 entre en circulation exclusivement par le minage :

  • Récompense de bloc : 50 BCH2 par bloc
  • Part des mineurs : 100 %
  • Frais de développement : 0 %
  • Mode de distribution : preuve de travail uniquement

11.3 Calendrier de l'offre

ÉtapeOffre en circulation
ForkTout le BC2 existant
Bloc 100 000~5,000,000 BCH2
Premier halving (210 000)~10,500,000 BCH2
Deuxième halving (420 000)~15,750,000 BCH2
Offre maximale21,000,000 BCH2

12. Gouvernance

12.1 Développement décentralisé

BCH2 fonctionne sans autorité centrale :

  • Pas de fondation : aucune entité juridique ne contrôle BCH2
  • Pas de dictateur bienveillant : aucune personne ne détient d'autorité particulière sur le protocole
  • Code ouvert : tout le code est publiquement auditable sous licence MIT
  • Financé par la communauté : le développement vit de contributions volontaires

12.2 Mises à niveau du protocole

Toute modification des règles de consensus de BCH2 exige :

  1. Proposition : spécification publique des changements envisagés
  2. Examen : analyse par la communauté et les développeurs
  3. Mise en œuvre : développement du code et tests
  4. Signalement : mesure du soutien des mineurs et des opérateurs de nœuds
  5. Activation : mise à niveau coordonnée à une hauteur ou une heure fixée

12.3 Alignement sur Bitcoin Cash

BCH2 entend rester compatible avec les améliorations du protocole Bitcoin Cash :

  • DAA ASERT (en place)
  • Blocs de 32 Mo (en place)
  • Introspection native (en place)
  • Les futures mises à niveau de BCH seront évaluées en vue d'une adoption

13. Feuille de route

Phase 1 : lancement ✓

  • Fork depuis BC2 à la hauteur de bloc désignée
  • Ajustement de difficulté ASERT actif
  • Taille de bloc de 32 Mo activée
  • Adressage CashAddr (bitcoincashii:)
  • Réseau mondial de nœuds opérationnel
  • Pool de minage (Forge Pool) en service
  • Logiciel de nœud complet publié

Phase 2 : adoption

  • Portefeuilles de bureau (fork d'Electron Cash)
  • Portefeuilles mobiles (Android, iOS)
  • Portefeuille web
  • Améliorations de l'explorateur de blocs
  • D'autres pools de minage
  • Référencements sur les plateformes d'échange

Phase 3 : écosystème

  • Outils de paiement pour commerçants
  • Prise en charge des portefeuilles matériels (Ledger, Trezor)
  • Mise en œuvre de la confidentialité CashFusion
  • Intégration de CashTokens
  • SDK et documentation pour développeurs

Phase 4 : croissance

  • Alignement continu sur le protocole BCH
  • Améliorations de la confidentialité
  • Développement d'un écosystème de jetons et de NFT
  • Poursuite de la décentralisation de l'infrastructure
  • Développement de fonctionnalités porté par la communauté

14. Considérations de sécurité

14.1 Sécurité de SHA-256

BCH2 utilise le même algorithme de preuve de travail SHA-256 qui sécurise Bitcoin depuis 2009 :

  • Aucune hypothèse cryptographique inédite
  • Compatible avec des milliards de dollars de matériel de minage
  • Plus de 15 ans de validation de sécurité en conditions réelles

14.2 Protection contre la répétition

BCH2 met en œuvre la protection contre le rejeu via SIGHASH_FORKID :

  • Les transactions signées pour BCH2 sont invalides sur BC2
  • Les transactions signées pour BC2 sont invalides sur BCH2
  • Impossible de dépenser par accident sur la mauvaise chaîne

14.3 État de l'audit du code

BCH2 repose sur :

  • BitcoinII Core v27.1 (fondé sur Bitcoin Core, largement audité)
  • Les modifications du protocole Bitcoin Cash (éprouvées depuis 2017)
  • L'implémentation de CashAddr (code standard BCH)
  • L'implémentation d'ASERT (déployée sur BCH depuis 2020)

15. Conclusion

BCH2 marie les améliorations de protocole éprouvées de Bitcoin Cash et un modèle de distribution équitable. En se séparant de BC2 à la hauteur 53 200, BCH2 offre :

Pour les détenteurs de BC2 :

  • Distribution automatique de BCH2 au ratio 1:1 lors du fork
  • Rien à faire : les mêmes clés fonctionnent sur les deux chaînes
  • La valeur de l'investissement en BC2 se poursuit

Pour les mineurs :

  • Des niveaux de difficulté accessibles
  • ASERT avec une demi-vie d'une heure, pour un rétablissement rapide après une attaque sur la difficulté
  • Retour prévu de la demi-vie à deux jours une fois le hashrate stabilisé
  • 100 % des récompenses de bloc (aucun frais de développement)

Pour les utilisateurs :

  • Des blocs de 32 Mo pour la montée en charge
  • Des frais bas grâce à l'espace de bloc
  • CashAddr pour des adresses commodes
  • Des confirmations rapides grâce à des temps de bloc réguliers
  • Toutes les capacités de script BCH, y compris les covenants et l'introspection

Pour l'écosystème :

  • Aucun préminage ni attribution aux initiés
  • Une gouvernance communautaire
  • Un développement en code ouvert
  • La compatibilité avec le protocole Bitcoin Cash
  • Un chemin clair vers l'alignement complet sur les paramètres de BCHN

BCH2, c'est la cryptomonnaie telle qu'elle devait être : ouverte, accessible, équitable et vraiment décentralisée.

16. Références

  1. Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System"
  2. Bitcoin Cash Protocol Documentation, https://documentation.cash/
  3. Sechet, A. (2020). "ASERT DAA Specification"
  4. CashAddr Specification, https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md
  5. BC2 (BitcoinII) Technical Documentation
  6. BCHN v29.0.0 ASERT Implementation Reference

17. Annexe A : guide de démarrage rapide

Faire tourner un nœud complet

Téléchargement :

https://bch2.org/downloads/

Configuration (~/.bitcoincashII/bitcoincashII.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

Démarrage :

bitcoincashIId -daemon

Minage

Minage en pool :

Pool: stratum+tcp://pool.bch2.org:3333
Worker: your_bch2_address
Password: x

Minage en solo :

Configurez votre ASIC pour se connecter au port RPC de votre nœud local.

Réclamer la distribution du fork BC2

Si vous déteniez des BC2 au bloc 53 200 :

  1. Exportez vos clés privées BC2 (format WIF)
  2. Importez-les dans un portefeuille BCH2
  3. Votre solde BCH2 égale votre solde BC2 au moment du fork

18. Annexe B : comparaison technique

FonctionBTCBCHBC2BCH2
Taille de blocpoids de 4 Mo32MBpoids de 4 Mo32MB
Ajust. de difficulté2016 blocsASERT (2-day)2016 blocsASERT (1 heure au lancement / 2 jours après la mise à niveau)
SegWitYesNoYesNon (après le fork)
Format d'adressebech32CashAddrbech32CashAddr
Protection contre la répétition—SIGHASH_FORKID—SIGHASH_FORKID
Temps de bloc10 min10 min10 min10 min
Plafond d'offre21M21M21M21M
RBFYesNoYesNo

BCH2 vs BCHN : résumé

AspectBCH2BCHNPlan de convergence
Historique de la chaîneBlocs BC2 0–53 200Chaîne genèse BCHS.O. (permanent)
ASERT Half-Life1 heure (transition au bloc 92 736)2 joursAutomatique au bloc 92 736
P2P Port83398333S.O. (permanent)
Préfixe d'adressebitcoincashii:bitcoincash:S.O. (permanent)
Règles de consensusIdentique après le forkRéférenceMaintenir la parité
VM de scriptIdentiqueRéférenceMaintenir la parité

19. Annexe C : questions fréquentes

BCH2 est-il un fork de Bitcoin Cash ?

BCH2 est un fork de BC2 (BitcoinII) à la hauteur 53 200 qui adopte les règles de consensus de Bitcoin Cash. Il conserve l'historique de la chaîne BC2 tout en reprenant les améliorations de protocole de BCH.

Dois-je faire quelque chose pour recevoir mon BCH2 ?

Non. Si vous déteniez les clés privées BC2 au bloc 53 200, le fork vous attribue automatiquement le même montant en BCH2. Il suffit d'importer vos clés dans un portefeuille BCH2.

Pourquoi forker BC2 plutôt que BCH directement ?

BC2 avait une distribution équitable dès son bloc de genèse et un minage accessible. En forkant BC2 et en adoptant les règles de BCH, BCH2 associe distribution équitable et améliorations de protocole éprouvées.

SegWit est-il pris en charge ?

Après le fork, aucune nouvelle sortie SegWit ne peut être créée. En revanche, les UTXO SegWit existants issus de l'historique de BC2 (P2WPKH, P2WSH, P2TR et variantes encapsulées en P2SH) peuvent être dépensés grâce au mécanisme « witness via scriptSig » de BCH2, qui déplace les données de signature du champ witness vers le scriptSig traditionnel. La dépense Taproot par la voie de clé est prise en charge, celle par la voie de script non : qui utilise des scripts Taproot complexes devrait déplacer ses pièces avant le fork. Le RBF est également désactivé.

Quel portefeuille utiliser ?

Tout portefeuille prenant en charge le format CashAddr peut être adapté à BCH2. Des portefeuilles officiels seront publiés à partir du code d'Electron Cash.

Comment miner du BCH2 ?

Connectez n'importe quel ASIC SHA-256 à pool.bch2.org:3333, ou minez en solo sur votre propre nœud.

Pourquoi la demi-vie ASERT diffère-t-elle de celle de BCH ?

BCH2 démarre avec une demi-vie ASERT d'une heure (contre deux jours pour BCH), pour se prémunir des attaques par manipulation de la difficulté qui pourraient paralyser une chaîne jeune au hashrate limité. La demi-vie passe automatiquement à deux jours au bloc 92 736 (environ 9 mois après le fork), sans hard fork.

Quand le fork a-t-il lieu ?

Le fork a lieu à la hauteur 53 200 de BC2, pour un lancement visé autour du 7-9 mars 2026. Les détenteurs de BC2 devraient s'assurer d'avoir la main sur leurs clés privées avant cette date.

BCH2 : Bitcoin Cash II — distribution équitable, protocole éprouvé, avenir décentralisé

Ce document est daté de février 2026. Les mises à jour seront publiées sur https://bch2.org/whitepaper