Bitcoin Cash : Monnaie électronique pair-à-pair pour le monde
Bitcoin Cash（BCH）は2017年8月1日にBitcoinからハードフォークしました。独自のホワイトペーパーは存在しません。ここに掲載されている文書は、Bitcoin CashがそのP2P電子キャッシュビジョンの基盤として参照する、Satoshi NakamotoによるBitcoinのオリジナルホワイトペーパーです。
Abstract
Bitcoin Cash is a peer-to-peer electronic cash system that forked from the Bitcoin blockchain on August 1, 2017. Created in response to Bitcoin's scaling limitations, Bitcoin Cash increased the block-size/" class="glossary-link" data-slug="block-size" title="block size">block size limit to enable greater transaction throughput and lower fees, restoring the original vision of Bitcoin as a practical medium of exchange for everyday transactions. With 32MB blocks, an adaptive difficulty adjustment algorithm, and continued protocol development, Bitcoin Cash aims to scale on-chain to serve as global peer-to-peer cash.
The Bitcoin Cash project was born from a fundamental disagreement within the Bitcoin community about how the network should scale to accommodate growing demand. While one faction advocated for off-chain scaling solutions such as the Lightning Network built atop witness/" class="glossary-link" data-slug="segregated-witness" title="Segregated Witness">Segregated Witness (SegWit), another faction argued that increasing the block size limit was the most straightforward and proven approach to scaling. When consensus could not be reached, the latter group executed a hard fork, creating a new chain that preserved Bitcoin's transaction history while implementing a larger block size limit and rejecting SegWit. This document describes the technical specifications, design philosophy, and development trajectory of Bitcoin Cash.
Abstract
Bitcoin Cash est un système d'argent électronique pair-à-pair issu d'une bifurcation de la blockchain Bitcoin le 1er août 2017. Créé en réponse aux limitations de scalabilité de Bitcoin, Bitcoin Cash a augmenté la limite de taille de bloc pour permettre un plus grand débit de transactions et des frais plus bas, restaurant la vision originale de Bitcoin comme moyen d'échange pratique pour les transactions quotidiennes. Avec des blocs de 32 Mo, un algorithme d'ajustement de difficulté adaptatif et un développement continu du protocole, Bitcoin Cash vise à évoluer on-chain pour servir d'argent pair-à-pair mondial.
Le projet Bitcoin Cash est né d'un désaccord fondamental au sein de la communauté Bitcoin sur la manière dont le réseau devrait évoluer pour s'adapter à la demande croissante. Tandis qu'une faction prônait des solutions de scalabilité hors chaîne telles que le Lightning Network construit sur SegWit, une autre faction soutenait que l'augmentation de la limite de taille de bloc était l'approche la plus directe et éprouvée pour la mise à l'échelle. Lorsqu'un consensus n'a pas pu être atteint, ce dernier groupe a exécuté un hard fork, créant une nouvelle chaîne qui préservait l'historique des transactions de Bitcoin tout en implémentant une limite de taille de bloc plus grande et en rejetant SegWit. Ce document décrit les spécifications techniques, la philosophie de conception et la trajectoire de développement de Bitcoin Cash.
Introduction
The original Bitcoin whitepaper, published by Satoshi Nakamoto in 2008, described "a purely peer-to-peer version of electronic cash" that would "allow online payments to be sent directly from one party to another without going through a financial institution." This vision of Bitcoin as a medium of exchange for everyday transactions was central to its early adoption and community growth. Early Bitcoin proponents frequently cited low transaction fees and fast payments as key advantages over traditional financial systems.
However, as Bitcoin's popularity grew through the mid-2010s, a fundamental constraint began to limit its utility as electronic cash. The one-megabyte block-size/" class="glossary-link" data-slug="block-size" title="block size">block size limit, originally introduced as a temporary anti-spam measure, created an artificial ceiling on the number of transactions the network could process. As demand for block space increased, users were forced to compete for limited capacity by offering higher transaction fees. By early 2017, median Bitcoin transaction fees had risen to several dollars, making small-value transactions economically impractical. During peak congestion periods, fees could exceed twenty dollars, and transactions could remain unconfirmed for hours or even days.
This situation represented a fundamental departure from Bitcoin's original promise. A system designed to enable peer-to-peer electronic payments was becoming too expensive and too slow for the very use cases it was created to serve. While Bitcoin was increasingly positioned as "digital gold" — a store of value rather than a medium of exchange — many community members and developers believed this represented a betrayal of the project's founding principles.
Bitcoin Cash was created to resolve this crisis by taking the most direct approach to scaling: increasing the block size limit. By allowing more transactions to fit in each block, Bitcoin Cash aimed to restore low fees and fast confirmations, making peer-to-peer electronic cash practical again. The project's proponents argued that on-chain scaling was not only technically feasible but was the approach that Satoshi Nakamoto had originally envisioned, pointing to early communications in which Nakamoto discussed raising the block size limit as the network grew.
The creation of Bitcoin Cash on August 1, 2017, was one of the most significant events in cryptocurrency history. It represented the first major chain split in Bitcoin's history driven by a genuine philosophical disagreement about the protocol's future direction. The fork demonstrated that in a decentralized system, unresolvable disputes can be settled by allowing each faction to pursue its own vision independently, with the market ultimately determining the outcome.
Introduction
Le livre blanc original de Bitcoin, publié par Satoshi Nakamoto en 2008, décrivait « une version purement pair-à-pair d'argent électronique » qui permettrait « d'envoyer des paiements en ligne directement d'une partie à une autre sans passer par une institution financière ». Cette vision de Bitcoin comme moyen d'échange pour les transactions quotidiennes était au cœur de son adoption précoce et de la croissance de sa communauté. Les premiers partisans de Bitcoin citaient fréquemment les faibles frais de transaction et les paiements rapides comme des avantages clés par rapport aux systèmes financiers traditionnels.
Cependant, à mesure que la popularité de Bitcoin augmentait au milieu des années 2010, une contrainte fondamentale commença à limiter son utilité en tant qu'argent électronique. La limite de taille de bloc d'un mégaoctet, initialement introduite comme mesure temporaire anti-spam, créait un plafond artificiel sur le nombre de transactions que le réseau pouvait traiter. À mesure que la demande d'espace de bloc augmentait, les utilisateurs étaient contraints de rivaliser pour une capacité limitée en proposant des frais de transaction plus élevés. Début 2017, les frais médians de transaction Bitcoin avaient atteint plusieurs dollars, rendant les transactions de faible valeur économiquement irréalisables. Pendant les périodes de congestion maximale, les frais pouvaient dépasser vingt dollars, et les transactions pouvaient rester non confirmées pendant des heures, voire des jours.
Cette situation représentait une déviation fondamentale de la promesse originale de Bitcoin. Un système conçu pour permettre les paiements électroniques pair-à-pair devenait trop cher et trop lent pour les cas d'utilisation mêmes qu'il avait été créé pour servir. Alors que Bitcoin était de plus en plus positionné comme de l'« or numérique » — une réserve de valeur plutôt qu'un moyen d'échange — de nombreux membres de la communauté et développeurs estimaient que cela représentait une trahison des principes fondateurs du projet.
Bitcoin Cash a été créé pour résoudre cette crise en adoptant l'approche la plus directe de la mise à l'échelle : augmenter la limite de taille de bloc. En permettant à plus de transactions de tenir dans chaque bloc, Bitcoin Cash visait à restaurer des frais bas et des confirmations rapides, rendant l'argent électronique pair-à-pair à nouveau pratique. Les partisans du projet soutenaient que la mise à l'échelle on-chain était non seulement techniquement réalisable, mais qu'elle correspondait à l'approche que Satoshi Nakamoto avait initialement envisagée, citant des communications précoces dans lesquelles Nakamoto discutait de l'augmentation de la limite de taille de bloc à mesure que le réseau se développerait.
La création de Bitcoin Cash le 1er août 2017 fut l'un des événements les plus significatifs de l'histoire des cryptomonnaies. Elle représentait la première grande division de chaîne dans l'histoire de Bitcoin motivée par un véritable désaccord philosophique sur la direction future du protocole. La bifurcation a démontré que dans un système décentralisé, les différends insolubles peuvent être résolus en permettant à chaque faction de poursuivre sa propre vision de manière indépendante, le marché déterminant finalement le résultat.
Background: The Scaling Debate
The Bitcoin scaling debate was one of the most contentious and prolonged disputes in the history of open-source software development. At its core, the debate centered on a seemingly simple question: how should the Bitcoin network increase its transaction processing capacity? The answer to this question, however, touched on fundamental issues of governance, decentralization, technical philosophy, and the very identity of Bitcoin.
Bitcoin's block-size/" class="glossary-link" data-slug="block-size" title="block size">block size limit of one megabyte was introduced by Satoshi Nakamoto in 2010 as a temporary measure to prevent denial-of-service attacks in which an adversary could flood the network with oversized blocks. At the time, actual block usage was far below this limit, and Nakamoto suggested that the limit could be raised in the future through a simple code change. However, as Bitcoin's usage grew and blocks began to fill, raising the limit proved to be far more contentious than anyone had anticipated.
One faction, which came to be associated with the Bitcoin Core development team, argued that the block size should remain small to preserve decentralization. Their reasoning was that larger blocks would increase the computational and bandwidth requirements for running a node/" class="glossary-link" data-slug="full-node" title="full node">full node, potentially pricing out ordinary users and concentrating node operation among well-resourced entities. They proposed an alternative scaling path: witness/" class="glossary-link" data-slug="segregated-witness" title="Segregated Witness">Segregated Witness (SegWit), a protocol change that restructured transaction data to effectively increase the block's transaction capacity without raising the nominal size limit, combined with off-chain solutions such as the Lightning Network that would move most transactions off the main blockchain.
The opposing faction, which included prominent developers, miners, and businesses, argued that raising the block size limit was the simplest, most proven, and most urgent solution. They contended that the one-megabyte limit was an arbitrary constraint that had never been intended as a permanent feature of the protocol, and that the resulting fee increases and congestion were driving users and merchants away from Bitcoin. They were skeptical of SegWit's complexity and concerned that the Lightning Network, which was still largely theoretical at the time, might never deliver on its promises of cheap, instant transactions.
The debate escalated through a series of proposals and counter-proposals. Bitcoin XT, proposed by Mike Hearn and Gavin Andresen in 2015, sought to increase the block size to 8MB. Bitcoin Classic proposed a more modest increase to 2MB. Bitcoin Unlimited proposed removing the block size limit entirely, allowing miners to set their own limits through market dynamics. Each proposal generated fierce debate and none achieved the overwhelming consensus needed for a non-contentious hard fork.
Several attempts at compromise were made. The Hong Kong Agreement (February 2016) saw Bitcoin Core developers and miners agree to deploy SegWit followed by a hard fork to 2MB, but the agreement fell apart when the hard fork component was not pursued. The New York Agreement (May 2017), also known as SegWit2x, proposed activating SegWit immediately followed by a 2MB hard fork within six months. This agreement was signed by over fifty companies representing a majority of Bitcoin's hash power, but it was strongly opposed by the Bitcoin Core development team and a significant portion of the user community.
As it became clear that compromise was impossible, the big-block faction decided to act unilaterally. On August 1, 2017, they executed a hard fork of the Bitcoin blockchain, creating Bitcoin Cash with an initial block size limit of 8MB. This was not a decision taken lightly — it required splitting the blockchain, the network, the community, and the brand. But the proponents of Bitcoin Cash believed it was the only way to preserve Bitcoin's original vision as peer-to-peer electronic cash.
Background: The Scaling Debate
Le débat sur la scalabilité de Bitcoin fut l'un des différends les plus contentieux et prolongés de l'histoire du développement de logiciels open source. En son cœur, le débat portait sur une question apparemment simple : comment le réseau Bitcoin devrait-il augmenter sa capacité de traitement des transactions ? La réponse à cette question, cependant, touchait à des questions fondamentales de gouvernance, de décentralisation, de philosophie technique et de l'identité même de Bitcoin.
La limite de taille de bloc d'un mégaoctet de Bitcoin a été introduite par Satoshi Nakamoto en 2010 comme mesure temporaire pour prévenir les attaques par déni de service dans lesquelles un adversaire pourrait inonder le réseau de blocs surdimensionnés. À l'époque, l'utilisation réelle des blocs était bien en dessous de cette limite, et Nakamoto avait suggéré que la limite pourrait être relevée à l'avenir par un simple changement de code. Cependant, à mesure que l'utilisation de Bitcoin augmentait et que les blocs commençaient à se remplir, relever la limite s'avéra bien plus contentieux que quiconque ne l'avait anticipé.
Une faction, qui en vint à être associée à l'équipe de développement Bitcoin Core, soutenait que la taille de bloc devait rester petite pour préserver la décentralisation. Leur raisonnement était que des blocs plus grands augmenteraient les exigences en puissance de calcul et en bande passante pour faire fonctionner un nœud complet">nœud complet, excluant potentiellement les utilisateurs ordinaires et concentrant l'exploitation des nœuds parmi les entités bien dotées en ressources. Ils proposèrent un chemin alternatif de mise à l'échelle : SegWit, une modification du protocole qui restructurait les données de transaction pour augmenter efficacement la capacité de transactions du bloc sans relever la limite de taille nominale, combinée avec des solutions hors chaîne comme le Lightning Network qui déplaceraient la plupart des transactions hors de la blockchain principale.
La faction opposée, qui comprenait des développeurs éminents, des mineurs et des entreprises, soutenait que relever la limite de taille de bloc était la solution la plus simple, la plus éprouvée et la plus urgente. Ils affirmaient que la limite d'un mégaoctet était une contrainte arbitraire qui n'avait jamais été conçue comme une caractéristique permanente du protocole, et que les augmentations de frais et la congestion qui en résultaient éloignaient les utilisateurs et les commerçants de Bitcoin. Ils étaient sceptiques quant à la complexité de SegWit et inquiets que le Lightning Network, qui était encore largement théorique à l'époque, ne tienne peut-être jamais ses promesses de transactions bon marché et instantanées.
Le débat s'intensifia à travers une série de propositions et de contre-propositions. Bitcoin XT, proposé par Mike Hearn et Gavin Andresen en 2015, cherchait à augmenter la taille de bloc à 8 Mo. Bitcoin Classic proposait une augmentation plus modeste à 2 Mo. Bitcoin Unlimited proposait de supprimer entièrement la limite de taille de bloc, permettant aux mineurs de fixer leurs propres limites par le biais de la dynamique du marché. Chaque proposition engendra un débat féroce et aucune n'atteignit le consensus écrasant nécessaire pour un hard fork non contentieux.
Plusieurs tentatives de compromis furent faites. L'Accord de Hong Kong (février 2016) vit les développeurs de Bitcoin Core et les mineurs convenir de déployer SegWit suivi d'un hard fork à 2 Mo, mais l'accord s'effondra lorsque le volet hard fork ne fut pas poursuivi. L'Accord de New York (mai 2017), également connu sous le nom de SegWit2x, proposait d'activer SegWit immédiatement suivi d'un hard fork à 2 Mo dans les six mois. Cet accord fut signé par plus de cinquante entreprises représentant une majorité de la puissance de hachage de Bitcoin, mais il fut fortement combattu par l'équipe de développement Bitcoin Core et une portion significative de la communauté d'utilisateurs.
Lorsqu'il devint clair que le compromis était impossible, la faction des gros blocs décida d'agir unilatéralement. Le 1er août 2017, ils exécutèrent un hard fork de la blockchain Bitcoin, créant Bitcoin Cash avec une limite de taille de bloc initiale de 8 Mo. Ce ne fut pas une décision prise à la légère — elle nécessitait de diviser la blockchain, le réseau, la communauté et la marque. Mais les partisans de Bitcoin Cash croyaient que c'était le seul moyen de préserver la vision originale de Bitcoin comme argent électronique pair-à-pair.
The Fork
The Bitcoin Cash hard fork was executed on August 1, 2017, at block-height/" class="glossary-link" data-slug="block-height" title="block height">block height 478,558. At that point, the Bitcoin blockchain split into two separate chains: the original chain, which continued as Bitcoin (BTC) with SegWit activation, and the new chain, which became Bitcoin Cash (BCH) with an increased block size limit of 8MB.
The fork was technically clean and well-planned. Every Bitcoin address that held a balance at the time of the fork received an identical balance on both chains. If a user held 1 BTC before the fork, they would have 1 BTC on the Bitcoin chain and 1 BCH on the Bitcoin Cash chain after the fork. The entire transaction history prior to block 478,558 was shared between both chains.
One of the critical technical challenges of the fork was implementing replay protection. In the absence of replay protection, a transaction broadcast on one chain could be replayed on the other chain, potentially causing users to unintentionally spend coins on both chains. Bitcoin Cash implemented strong replay protection by modifying the transaction signing algorithm. Specifically, Bitcoin Cash introduced a new SigHash flag (SIGHASH_FORKID) that is included in the hash of each transaction signature. Transactions signed with this flag are valid on the Bitcoin Cash chain but invalid on the Bitcoin chain, and vice versa. This ensured a clean separation between the two networks from the moment of the fork.
The initial block size limit for Bitcoin Cash was set at 8MB, eight times larger than Bitcoin's 1MB limit. This represented a significant increase in on-chain transaction capacity, allowing Bitcoin Cash to process substantially more transactions per block while maintaining low fees. The first Bitcoin Cash block after the fork was mined by ViaBTC mining-pool/" class="glossary-link" data-slug="mining-pool" title="mining pool">mining pool and was approximately 1.9MB in size, demonstrating the immediate practical benefit of the larger block size.
The fork also removed SegWit, which had been activated on the Bitcoin chain. The Bitcoin Cash developers rejected SegWit for several reasons: they believed it introduced unnecessary complexity to the protocol, it created a two-tier transaction system with different fee structures, and it modified the block structure in ways that they argued undermined the UTXO model's simplicity. By choosing a straightforward block size increase instead, Bitcoin Cash maintained a simpler and more traditional Bitcoin-like protocol architecture.
In the aftermath of the fork, both chains had to contend with the challenge of difficulty adjustment. Bitcoin Cash initially used the same SHA-256 difficulty from the Bitcoin chain, but with significantly less hash power devoted to mining. To prevent a scenario in which blocks were mined extremely slowly, Bitcoin Cash implemented an Emergency Difficulty Adjustment (EDA) mechanism that would decrease the difficulty by 20 percent if fewer than 6 blocks were mined in a 12-hour period. While this mechanism successfully kept the chain alive during the critical early period, it proved to be unstable, causing wild oscillations in block production times and hash rate as miners switched between Bitcoin and Bitcoin Cash based on profitability. The EDA was replaced in November 2017 with a more stable difficulty adjustment algorithm based on a moving average of the previous 144 blocks.
The fork was met with significant controversy in the broader cryptocurrency community. Critics argued that Bitcoin Cash was an illegitimate attempt to co-opt the Bitcoin brand, while supporters maintained that it was a legitimate continuation of Bitcoin's original roadmap. Exchanges and service providers had to make rapid decisions about whether to support the new chain and how to handle the distribution of forked coins to their customers. Despite the controversy, Bitcoin Cash quickly established itself as a viable and actively used cryptocurrency, achieving significant trading volume and merchant adoption in the months following the fork.
The Fork
Le hard fork de Bitcoin Cash fut exécuté le 1er août 2017, à la hauteur de bloc 478 558. À ce point, la blockchain Bitcoin se scinda en deux chaînes distinctes : la chaîne originale, qui continua comme Bitcoin (BTC) avec l'activation de SegWit, et la nouvelle chaîne, qui devint Bitcoin Cash (BCH) avec une limite de taille de bloc augmentée à 8 Mo.
La bifurcation fut techniquement propre et bien planifiée. Chaque adresse Bitcoin détenant un solde au moment de la bifurcation reçut un solde identique sur les deux chaînes. Si un utilisateur détenait 1 BTC avant la bifurcation, il aurait 1 BTC sur la chaîne Bitcoin et 1 BCH sur la chaîne Bitcoin Cash après la bifurcation. L'intégralité de l'historique des transactions antérieur au bloc 478 558 était partagé entre les deux chaînes.
L'un des défis techniques critiques de la bifurcation fut l'implémentation de la protection contre le rejeu. En l'absence de protection contre le rejeu, une transaction diffusée sur une chaîne pouvait être rejouée sur l'autre chaîne, causant potentiellement des dépenses involontaires de jetons par les utilisateurs sur les deux chaînes. Bitcoin Cash implémenta une forte protection contre le rejeu en modifiant l'algorithme de signature de transaction. Spécifiquement, Bitcoin Cash introduisit un nouveau drapeau SigHash (SIGHASH_FORKID) qui est inclus dans le hash de chaque signature de transaction. Les transactions signées avec ce drapeau sont valides sur la chaîne Bitcoin Cash mais invalides sur la chaîne Bitcoin, et vice-versa. Cela garantit une séparation nette entre les deux réseaux dès le moment de la bifurcation.
La limite de taille de bloc initiale pour Bitcoin Cash fut fixée à 8 Mo, soit huit fois plus que la limite de 1 Mo de Bitcoin. Cela représentait une augmentation significative de la capacité de transactions on-chain, permettant à Bitcoin Cash de traiter substantiellement plus de transactions par bloc tout en maintenant des frais bas. Le premier bloc de Bitcoin Cash après la bifurcation fut miné par le pool de minage ViaBTC et faisait environ 1,9 Mo, démontrant le bénéfice pratique immédiat de la taille de bloc plus grande.
La bifurcation supprima également SegWit, qui avait été activé sur la chaîne Bitcoin. Les développeurs de Bitcoin Cash rejetèrent SegWit pour plusieurs raisons : ils estimaient qu'il introduisait une complexité inutile dans le protocole, créait un système de transaction à deux niveaux avec des structures de frais différentes, et modifiait la structure de bloc d'une manière qui, selon eux, sapait la simplicité du modèle UTXO. En choisissant une augmentation directe de la taille de bloc, Bitcoin Cash maintint une architecture de protocole plus simple et plus traditionnelle de type Bitcoin.
À la suite de la bifurcation, les deux chaînes durent faire face au défi de l'ajustement de la difficulté. Bitcoin Cash utilisa initialement la même difficulté SHA-256 que la chaîne Bitcoin, mais avec significativement moins de puissance de hachage consacrée au minage. Pour prévenir un scénario dans lequel les blocs seraient minés extrêmement lentement, Bitcoin Cash implémenta un mécanisme d'Ajustement d'Urgence de la Difficulté (EDA) qui diminuerait la difficulté de 20 pour cent si moins de 6 blocs étaient minés dans une période de 12 heures. Bien que ce mécanisme ait réussi à maintenir la chaîne en vie durant la période initiale critique, il s'avéra instable, provoquant de violentes oscillations dans les temps de production de blocs et le taux de hachage à mesure que les mineurs alternaient entre Bitcoin et Bitcoin Cash en fonction de la rentabilité. L'EDA fut remplacé en novembre 2017 par un algorithme d'ajustement de difficulté plus stable basé sur une moyenne mobile des 144 blocs précédents.
La bifurcation fut accueillie avec une controverse considérable dans la communauté crypto au sens large. Les critiques soutenaient que Bitcoin Cash était une tentative illégitime de s'approprier la marque Bitcoin, tandis que les partisans maintenaient qu'il s'agissait d'une continuation légitime de la feuille de route originale de Bitcoin. Les plateformes d'échange et les fournisseurs de services durent prendre des décisions rapides sur la question de savoir s'ils soutiendraient la nouvelle chaîne et comment gérer la distribution des jetons bifurqués à leurs clients. Malgré la controverse, Bitcoin Cash s'établit rapidement comme une cryptomonnaie viable et activement utilisée, atteignant un volume d'échanges significatif et une adoption par les commerçants dans les mois suivant la bifurcation.
Technical Specifications
Bitcoin Cash shares the fundamental technical architecture of Bitcoin, including the SHA-256 proof-of-work consensus mechanism, the UTXO transaction model, the secp256k1 elliptic curve for digital signatures, and the ten-minute target block-time/" class="glossary-link" data-slug="block-time" title="block interval">block interval. However, several key modifications differentiate it from the Bitcoin protocol.
The most prominent difference is the block size limit. Bitcoin Cash launched with an 8MB block size limit and subsequently increased it to 32MB in May 2018. This 32MB limit provides approximately 32 times the transaction capacity of Bitcoin's effective 1MB non-witness/" class="glossary-link" data-slug="segregated-witness" title="SegWit">SegWit block size (or roughly 8 times the capacity of Bitcoin's SegWit-enhanced effective limit of approximately 4MB). The larger block size is the cornerstone of Bitcoin Cash's on-chain scaling philosophy, providing ample room for transaction growth without the fee pressure that arises when blocks are consistently full.
Bitcoin Cash does not implement Segregated Witness (SegWit). Instead of separating witness data from transaction data as SegWit does, Bitcoin Cash keeps the original Bitcoin transaction format intact. All transaction data, including signatures, is stored within the block in the traditional manner. This simplifies the protocol and maintains backward compatibility with older Bitcoin software and infrastructure.
A significant protocol enhancement in Bitcoin Cash is the improved SigHash algorithm, which was introduced at the time of the fork. The new algorithm, based on BIP 143 (which was originally developed for SegWit), fixes the quadratic hashing problem that existed in the original Bitcoin signature verification scheme. In the original scheme, the computational cost of verifying a transaction's signature grew quadratically with the number of inputs, creating a potential denial-of-service vector. The new SigHash algorithm makes verification cost linear, enabling the network to safely process larger and more complex transactions.
Bitcoin Cash supports a larger maximum transaction size and a greater number of signature operations (sigops) per block compared to Bitcoin. The sigops limit is scaled proportionally with the block size, ensuring that the computational cost of block validation remains bounded while still allowing significantly more transactions per block.
The scripting system in Bitcoin Cash has been actively developed beyond Bitcoin's comparatively conservative approach. Bitcoin Cash has re-enabled and introduced several opcodes that expand the expressiveness of its scripting language. Notable additions include OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY, which allow transaction scripts to verify signatures against arbitrary data (not just transaction data), enabling oracle-based smart contracts and other advanced scripting patterns. The OP_REVERSEBYTES opcode, native introspection opcodes, and larger script and stack limits have further enhanced Bitcoin Cash's programmability.
Bitcoin Cash uses the same address format foundation as Bitcoin but adopted the CashAddr format in January 2018 to prevent confusion and cross-chain sending errors. CashAddr addresses begin with "bitcoincash:" as a prefix (often shortened to "q" or "p" for the hash portion) and use a different encoding scheme than Bitcoin's base58check format. This visual distinction makes it immediately clear whether an address belongs to Bitcoin or Bitcoin Cash, reducing the risk of users accidentally sending coins to the wrong chain.
The network operates on port 8333, the same default port as Bitcoin, though Bitcoin Cash nodes identify themselves with a different network magic number in the protocol handshake. This means that Bitcoin and Bitcoin Cash nodes will not accidentally connect to each other despite using the same port.
Technical Specifications
Bitcoin Cash partage l'architecture technique fondamentale de Bitcoin, incluant le mécanisme de consensus de preuve de travail SHA-256, le modèle de transactions UTXO, la courbe elliptique secp256k1 pour les signatures numériques et l'intervalle de bloc cible de dix minutes. Cependant, plusieurs modifications clés le différencient du protocole Bitcoin.
La différence la plus notable est la limite de taille de bloc. Bitcoin Cash a été lancé avec une limite de taille de bloc de 8 Mo et l'a ensuite augmentée à 32 Mo en mai 2018. Cette limite de 32 Mo fournit environ 32 fois la capacité de transactions de la taille de bloc effective de 1 Mo sans SegWit de Bitcoin (ou environ 8 fois la capacité de la limite effective de Bitcoin améliorée par SegWit d'environ 4 Mo). La taille de bloc plus grande est la pierre angulaire de la philosophie de mise à l'échelle on-chain de Bitcoin Cash, offrant un espace amplement suffisant pour la croissance des transactions sans la pression sur les frais qui apparaît lorsque les blocs sont constamment pleins.
Bitcoin Cash n'implémente pas SegWit. Au lieu de séparer les données de témoin des données de transaction comme le fait SegWit, Bitcoin Cash conserve intact le format de transaction original de Bitcoin. Toutes les données de transaction, y compris les signatures, sont stockées dans le bloc de manière traditionnelle. Cela simplifie le protocole et maintient la rétrocompatibilité avec les logiciels et infrastructures Bitcoin plus anciens.
Une amélioration significative du protocole dans Bitcoin Cash est l'algorithme SigHash amélioré, qui fut introduit au moment de la bifurcation. Le nouvel algorithme, basé sur le BIP 143 (développé à l'origine pour SegWit), corrige le problème de hachage quadratique qui existait dans le schéma original de vérification des signatures de Bitcoin. Dans le schéma original, le coût computationnel de la vérification de la signature d'une transaction croissait de manière quadratique avec le nombre d'entrées, créant un vecteur potentiel d'attaque par déni de service. Le nouvel algorithme SigHash rend le coût de vérification linéaire, permettant au réseau de traiter en toute sécurité des transactions plus importantes et plus complexes.
Bitcoin Cash prend en charge une taille maximale de transaction plus grande et un plus grand nombre d'opérations de signature (sigops) par bloc comparé à Bitcoin. La limite de sigops est proportionnelle à la taille du bloc, garantissant que le coût computationnel de la validation des blocs reste borné tout en permettant significativement plus de transactions par bloc.
Le système de scripts de Bitcoin Cash a été activement développé au-delà de l'approche comparativement conservatrice de Bitcoin. Bitcoin Cash a réactivé et introduit plusieurs opcodes qui étendent l'expressivité de son langage de scripts. Les ajouts notables incluent OP_CHECKDATASIG et OP_CHECKDATASIGVERIFY, qui permettent aux scripts de transaction de vérifier des signatures contre des données arbitraires (pas seulement des données de transaction), permettant des contrats intelligents basés sur des oracles et d'autres modèles avancés de scripting. L'opcode OP_REVERSEBYTES, les opcodes d'introspection natifs et les limites plus grandes de script et de pile ont encore amélioré la programmabilité de Bitcoin Cash.
Bitcoin Cash utilise la même base de format d'adresse que Bitcoin mais a adopté le format CashAddr en janvier 2018 pour prévenir la confusion et les erreurs d'envoi inter-chaînes. Les adresses CashAddr commencent par « bitcoincash: » comme préfixe (souvent abrégé en « q » ou « p » pour la portion du hash) et utilisent un schéma d'encodage différent du format base58check de Bitcoin. Cette distinction visuelle rend immédiatement clair si une adresse appartient à Bitcoin ou à Bitcoin Cash, réduisant le risque que les utilisateurs envoient accidentellement des jetons à la mauvaise chaîne.
Le réseau fonctionne sur le port 8333, le même port par défaut que Bitcoin, bien que les nœuds Bitcoin Cash s'identifient avec un numéro magique de réseau différent lors de la poignée de main du protocole. Cela signifie que les nœuds Bitcoin et Bitcoin Cash ne se connecteront pas accidentellement entre eux malgré l'utilisation du même port.
Transaction Throughput and Scalability
Transaction throughput and scalability are central to Bitcoin Cash's value proposition. The project's fundamental thesis is that peer-to-peer electronic cash must be able to process transactions quickly and cheaply to be viable for everyday use, and that on-chain scaling through larger blocks is the most reliable way to achieve this.
With a 32MB block-size/" class="glossary-link" data-slug="block-size" title="block size">block size limit and a ten-minute block interval, Bitcoin Cash has a theoretical maximum throughput of approximately 100 transactions per second, depending on the average transaction size. This represents a substantial increase over Bitcoin's theoretical maximum of approximately 7 transactions per second with 1MB blocks. In practice, the actual throughput depends on the mix of transaction types and sizes, but Bitcoin Cash's capacity is more than sufficient for its current transaction volume, with blocks typically well below the 32MB limit.
The abundance of available block space has a direct and measurable impact on transaction fees. When blocks are not full, there is no fee competition, and transactions can be confirmed with minimal fees. Bitcoin Cash's default minimum relay fee is 1 satoshi per byte (where 1 satoshi = 0.00000001 BCH), and most transactions are confirmed in the next block at or near this minimum. This makes Bitcoin Cash transactions cost fractions of a cent under normal conditions, compared to Bitcoin's fees which can range from dollars to tens of dollars during periods of congestion.
The Bitcoin Cash development community has conducted extensive research and testing on the limits of on-chain scaling. The Gigablock Testnet Initiative, conducted in 2017-2018, demonstrated that the Bitcoin protocol could handle blocks of 1GB or more with appropriate software optimizations and modern hardware. These tests identified several bottlenecks in the original codebase — including block propagation, transaction validation, and UTXO set management — and informed subsequent optimization efforts.
Several protocol and implementation improvements have been made to support larger blocks. Graphene, a block propagation protocol based on invertible Bloom lookup tables and Bloom filters, dramatically reduces the bandwidth required to propagate blocks by encoding only the difference between a block and the transactions a receiving node already has in its mempool. Canonical Transaction Ordering (CTOR), implemented in November 2018, requires transactions within a block to be ordered by their transaction ID. This seemingly minor change enables significant optimizations in block validation and propagation, as it allows for parallel validation of transactions and more efficient set reconciliation algorithms.
The UTXO commitment and parallel validation initiatives have further improved the network's ability to handle large blocks efficiently. By leveraging modern multi-core processors and solid-state storage, optimized node implementations can validate blocks containing tens of thousands of transactions within acceptable time frames.
Bitcoin Cash's scalability roadmap envisions further increases to the block size limit as technology and demand warrant. The project's developers have expressed a long-term goal of supporting global-scale payment volumes entirely on-chain, targeting throughput levels that would allow Bitcoin Cash to serve billions of daily transactions. While this goal is ambitious, the ongoing improvements in hardware capabilities, network bandwidth, and software optimization provide a credible path toward achieving it incrementally over time.
An important aspect of Bitcoin Cash's scaling approach is the concept of "zero-confirmation" transactions. For low-value payments, merchants can accept transactions immediately upon broadcast, before they are included in a block. Bitcoin Cash has implemented several measures to improve the reliability of zero-confirmation transactions, including the "first-seen" rule (where nodes relay only the first version of a transaction they see, making double-spend attempts more difficult) and double-spend notification protocols that alert merchants if a conflicting transaction is detected. These measures make Bitcoin Cash practical for point-of-sale transactions where waiting ten minutes for a block confirmation would be impractical.
Transaction Throughput and Scalability
Le débit de transactions et la scalabilité sont au cœur de la proposition de valeur de Bitcoin Cash. La thèse fondamentale du projet est que l'argent électronique pair-à-pair doit être capable de traiter des transactions rapidement et à moindre coût pour être viable dans un usage quotidien, et que la mise à l'échelle on-chain par des blocs plus grands est le moyen le plus fiable d'y parvenir.
Avec une limite de taille de bloc de 32 Mo et un intervalle de bloc de dix minutes, Bitcoin Cash a un débit maximal théorique d'environ 100 transactions par seconde, selon la taille moyenne des transactions. Cela représente une augmentation substantielle par rapport au maximum théorique de Bitcoin d'environ 7 transactions par seconde avec des blocs de 1 Mo. En pratique, le débit réel dépend du mélange de types et de tailles de transactions, mais la capacité de Bitcoin Cash est plus que suffisante pour son volume de transactions actuel, les blocs étant généralement bien en dessous de la limite de 32 Mo.
L'abondance d'espace de bloc disponible a un impact direct et mesurable sur les frais de transaction. Lorsque les blocs ne sont pas pleins, il n'y a pas de compétition sur les frais, et les transactions peuvent être confirmées avec des frais minimaux. Les frais de relais minimaux par défaut de Bitcoin Cash sont de 1 satoshi par octet (où 1 satoshi = 0,00000001 BCH), et la plupart des transactions sont confirmées dans le bloc suivant à ce minimum ou à un niveau proche. Cela rend les transactions Bitcoin Cash coûtant des fractions de centime dans des conditions normales, par rapport aux frais de Bitcoin qui peuvent aller de dollars à des dizaines de dollars pendant les périodes de congestion.
La communauté de développement de Bitcoin Cash a mené des recherches et des tests approfondis sur les limites de la mise à l'échelle on-chain. L'Initiative Gigablock Testnet, menée en 2017-2018, a démontré que le protocole Bitcoin pouvait gérer des blocs de 1 Go ou plus avec les optimisations logicielles appropriées et du matériel moderne. Ces tests ont identifié plusieurs goulets d'étranglement dans la base de code originale — incluant la propagation des blocs, la validation des transactions et la gestion de l'ensemble UTXO — et ont éclairé les efforts d'optimisation ultérieurs.
Plusieurs améliorations du protocole et de l'implémentation ont été réalisées pour supporter des blocs plus grands. Graphene, un protocole de propagation de blocs basé sur des tables de recherche de Bloom invertibles et des filtres de Bloom, réduit considérablement la bande passante nécessaire pour propager les blocs en encodant uniquement la différence entre un bloc et les transactions qu'un nœud receveur possède déjà dans son mempool. L'Ordonnancement Canonique des Transactions (CTOR), implémenté en novembre 2018, exige que les transactions dans un bloc soient ordonnées par leur identifiant de transaction. Ce changement apparemment mineur permet des optimisations significatives dans la validation et la propagation des blocs, car il autorise la validation parallèle des transactions et des algorithmes de réconciliation d'ensembles plus efficaces.
Les initiatives d'engagement UTXO et de validation parallèle ont encore amélioré la capacité du réseau à gérer efficacement de grands blocs. En tirant parti des processeurs multi-cœurs modernes et du stockage à état solide, les implémentations de nœuds optimisées peuvent valider des blocs contenant des dizaines de milliers de transactions dans des délais acceptables.
La feuille de route de scalabilité de Bitcoin Cash envisage des augmentations supplémentaires de la limite de taille de bloc à mesure que la technologie et la demande le justifient. Les développeurs du projet ont exprimé un objectif à long terme de supporter des volumes de paiement à l'échelle mondiale entièrement on-chain, visant des niveaux de débit qui permettraient à Bitcoin Cash de servir des milliards de transactions quotidiennes. Bien que cet objectif soit ambitieux, les améliorations continues des capacités matérielles, de la bande passante réseau et de l'optimisation logicielle fournissent une voie crédible pour y parvenir progressivement au fil du temps.
Un aspect important de l'approche de mise à l'échelle de Bitcoin Cash est le concept de transactions à « zéro confirmation ». Pour les paiements de faible valeur, les commerçants peuvent accepter les transactions immédiatement après leur diffusion, avant qu'elles ne soient incluses dans un bloc. Bitcoin Cash a implémenté plusieurs mesures pour améliorer la fiabilité des transactions à zéro confirmation, incluant la règle du « premier vu » (où les nœuds ne relaient que la première version d'une transaction qu'ils voient, rendant les tentatives de double dépense plus difficiles) et des protocoles de notification de double dépense qui alertent les commerçants si une transaction conflictuelle est détectée. Ces mesures rendent Bitcoin Cash pratique pour les transactions en point de vente où attendre dix minutes pour une confirmation de bloc serait irréalisable.
OP_RETURN and Data Applications
Bitcoin Cash supports the OP_RETURN opcode, which allows users to embed arbitrary data in the blockchain within a transaction output that is provably unspendable. This feature enables a range of data-centric applications built on top of the Bitcoin Cash blockchain, including token protocols, messaging systems, notarization services, and social media platforms.
The OP_RETURN data limit on Bitcoin Cash has been set at 220 bytes per output, significantly larger than Bitcoin's 80-byte limit. Additionally, Bitcoin Cash allows multiple OP_RETURN outputs in a single transaction, further expanding the amount of data that can be embedded in a single transaction. These generous limits, combined with low transaction fees, make Bitcoin Cash an economically viable platform for data applications that would be prohibitively expensive on more capacity-constrained chains.
The Simple Ledger Protocol (SLP) was one of the earliest and most widely adopted token systems built on Bitcoin Cash using OP_RETURN. SLP allowed users to create and transfer custom tokens on the Bitcoin Cash blockchain by encoding token metadata in OP_RETURN outputs. While SLP has since been largely superseded by the CashTokens protocol, it demonstrated the viability of building token economies on top of the UTXO model.
CashTokens, activated in May 2023, represents a more sophisticated approach to tokenization on Bitcoin Cash. Unlike SLP, which relied on OP_RETURN metadata that could be ignored by the base protocol, CashTokens is a consensus-level feature that integrates tokens directly into the UTXO model. Each UTXO can carry both a BCH value and an associated token, with token validity enforced by the consensus rules. CashTokens supports two types of tokens: fungible tokens (similar to ERC-20 tokens on Ethereum) and non-fungible tokens (NFTs). The consensus-level enforcement means that token transactions have the same security guarantees as native BCH transactions, eliminating the trust assumptions and indexing requirements of overlay protocols like SLP.
Memo.cash is a decentralized social media protocol built on Bitcoin Cash using OP_RETURN transactions. Users broadcast posts, follows, likes, and other social actions as Bitcoin Cash transactions with encoded OP_RETURN data. Because the data is stored on the blockchain, it is censorship-resistant and permanently archived. The low transaction costs on Bitcoin Cash make this economically feasible — each social media action costs a fraction of a cent.
Other data applications on Bitcoin Cash include document timestamping and notarization services, where the hash of a document is embedded in an OP_RETURN output to create a permanent, tamper-proof record of the document's existence at a specific point in time. Supply chain tracking, credential verification, and decentralized identity systems have also been built using Bitcoin Cash's data embedding capabilities.
The combination of large OP_RETURN capacity, low fees, and fast confirmation times positions Bitcoin Cash as a competitive platform for blockchain-based data applications. While purpose-built data blockchains exist, Bitcoin Cash offers the advantage of a well-established, highly secure, and widely supported network with a proven track record of continuous operation.
OP_RETURN and Data Applications
Bitcoin Cash prend en charge l'opcode OP_RETURN, qui permet aux utilisateurs d'intégrer des données arbitraires dans la blockchain au sein d'une sortie de transaction dont il est prouvable qu'elle ne peut être dépensée. Cette fonctionnalité permet une gamme d'applications centrées sur les données construites sur la blockchain Bitcoin Cash, incluant des protocoles de jetons, des systèmes de messagerie, des services de notarisation et des plateformes de médias sociaux.
La limite de données OP_RETURN sur Bitcoin Cash a été fixée à 220 octets par sortie, significativement plus que la limite de 80 octets de Bitcoin. De plus, Bitcoin Cash autorise plusieurs sorties OP_RETURN dans une seule transaction, étendant encore la quantité de données pouvant être intégrées dans une seule transaction. Ces limites généreuses, combinées à de faibles frais de transaction, font de Bitcoin Cash une plateforme économiquement viable pour des applications de données qui seraient prohibitivement coûteuses sur des chaînes plus contraintes en capacité.
Le Simple Ledger Protocol (SLP) fut l'un des systèmes de jetons les plus précoces et les plus largement adoptés construits sur Bitcoin Cash en utilisant OP_RETURN. SLP permettait aux utilisateurs de créer et de transférer des jetons personnalisés sur la blockchain Bitcoin Cash en encodant des métadonnées de jetons dans des sorties OP_RETURN. Bien que SLP ait été largement supplanté par le protocole CashTokens, il a démontré la viabilité de la construction d'économies de jetons sur le modèle UTXO.
CashTokens, activé en mai 2023, représente une approche plus sophistiquée de la tokenisation sur Bitcoin Cash. Contrairement à SLP, qui reposait sur des métadonnées OP_RETURN pouvant être ignorées par le protocole de base, CashTokens est une fonctionnalité au niveau du consensus qui intègre les jetons directement dans le modèle UTXO. Chaque UTXO peut porter à la fois une valeur en BCH et un jeton associé, la validité du jeton étant appliquée par les règles de consensus. CashTokens prend en charge deux types de jetons : les jetons fongibles (similaires aux jetons ERC-20 sur Ethereum) et les jetons non fongibles (NFTs). L'application au niveau du consensus signifie que les transactions de jetons ont les mêmes garanties de sécurité que les transactions natives en BCH, éliminant les hypothèses de confiance et les exigences d'indexation des protocoles superposés comme SLP.
Memo.cash est un protocole de médias sociaux décentralisé construit sur Bitcoin Cash en utilisant des transactions OP_RETURN. Les utilisateurs diffusent des publications, des suivis, des mentions « j'aime » et d'autres actions sociales sous forme de transactions Bitcoin Cash avec des données OP_RETURN encodées. Comme les données sont stockées sur la blockchain, elles sont résistantes à la censure et archivées de manière permanente. Les faibles coûts de transaction sur Bitcoin Cash rendent cela économiquement viable — chaque action de média social coûte une fraction de centime.
D'autres applications de données sur Bitcoin Cash incluent l'horodatage de documents et les services de notarisation, où le hash d'un document est intégré dans une sortie OP_RETURN pour créer un enregistrement permanent et inaltérable de l'existence du document à un moment précis. Le suivi de la chaîne d'approvisionnement, la vérification des accréditations et les systèmes d'identité décentralisée ont également été construits en utilisant les capacités d'intégration de données de Bitcoin Cash.
La combinaison d'une grande capacité OP_RETURN, de frais bas et de temps de confirmation rapides positionne Bitcoin Cash comme une plateforme compétitive pour les applications de données basées sur la blockchain. Bien que des blockchains dédiées aux données existent, Bitcoin Cash offre l'avantage d'un réseau bien établi, hautement sécurisé et largement soutenu avec un historique éprouvé d'opération continue.
Network Architecture
The Bitcoin Cash network operates on the same fundamental peer-to-peer architecture as Bitcoin, with nodes communicating via a gossip protocol to propagate transactions and blocks. Full nodes maintain a complete copy of the blockchain and independently validate all transactions and blocks according to the consensus rules. The network is permissionless, meaning that anyone can operate a node and participate in the network without authorization.
Multiple independent full node implementations exist for Bitcoin Cash, reflecting the project's commitment to decentralized development. Bitcoin Cash Node (BCHN) is the most widely used implementation and serves as the de facto reference client. Other implementations include Bitcoin Unlimited, BCHD (written in Go), and Knuth (a high-performance C++ implementation). The existence of multiple independent implementations reduces the risk of a single software bug causing a network-wide failure and ensures that no single development team has unilateral control over the protocol.
Mining on Bitcoin Cash uses the SHA-256 proof-of-work algorithm, identical to Bitcoin. This means that the same ASIC mining hardware can be used to mine either chain, and miners can switch between Bitcoin and Bitcoin Cash based on profitability. In practice, Bitcoin Cash's hash rate is a fraction of Bitcoin's, as the majority of SHA-256 mining power is directed at the more profitable Bitcoin chain. However, Bitcoin Cash's difficulty adjustment algorithm ensures that blocks are produced at the target ten-minute interval regardless of the absolute hash rate level.
The difficulty adjustment algorithm is one of Bitcoin Cash's most important protocol components. The original Bitcoin difficulty adjustment, which recalculates every 2016 blocks (approximately two weeks), was too slow to accommodate the rapid hash rate fluctuations that Bitcoin Cash experienced as miners switched between it and Bitcoin. After the problematic Emergency Difficulty Adjustment (EDA) period in 2017, Bitcoin Cash adopted a new algorithm in November 2017 that adjusted difficulty based on a 144-block moving window.
In November 2020, Bitcoin Cash upgraded to the ASERT (Absolutely Scheduled Exponentially Rising Targets) difficulty adjustment algorithm, also known as aserti3-2d. ASERT is a mathematically elegant algorithm that adjusts the difficulty target based on the difference between the actual time elapsed and the expected time since a reference block (the "anchor block"). If blocks are being produced faster than expected, the difficulty increases exponentially; if slower, it decreases exponentially. The "3-2d" designation refers to a half-life of approximately two days (specifically 288 blocks at the ten-minute target), meaning that a sustained doubling or halving of hash rate would result in a full difficulty adjustment within two days. ASERT has proven to be highly stable, producing consistent block intervals even under significant hash rate volatility.
Block propagation efficiency is critical for a network with large blocks. Bitcoin Cash has adopted several optimizations to ensure that large blocks can propagate across the network quickly. Compact Blocks (BIP 152), which allow nodes to reconstruct blocks from transaction IDs rather than full transaction data, dramatically reduce the bandwidth required for block propagation when nodes have overlapping mempools. The Graphene protocol provides even greater compression by using probabilistic data structures to achieve near-optimal block encoding. Xthinner is another compression protocol developed specifically for Bitcoin Cash that achieves approximately 99.6 percent compression for typical blocks.
The network's relay and mempool policies are designed to support reliable zero-confirmation transactions. Nodes follow a strict first-seen rule, accepting and relaying only the first version of a transaction they observe. If a second transaction attempting to spend the same inputs (a double-spend attempt) is detected, nodes will generate a double-spend proof and propagate it through the network, alerting merchants and other interested parties. This infrastructure provides a reasonable security level for accepting unconfirmed transactions for everyday, low-value payments.
Network Architecture
Le réseau Bitcoin Cash fonctionne sur la même architecture pair-à-pair fondamentale que Bitcoin, les nœuds communiquant via un protocole de propagation pour diffuser les transactions et les blocs. Les nœuds complets maintiennent une copie complète de la blockchain et valident indépendamment toutes les transactions et blocs conformément aux règles de consensus. Le réseau est sans permission, ce qui signifie que quiconque peut exploiter un nœud et participer au réseau sans autorisation.
Plusieurs implémentations indépendantes de nœuds complets existent pour Bitcoin Cash, reflétant l'engagement du projet envers le développement décentralisé. Bitcoin Cash Node (BCHN) est l'implémentation la plus largement utilisée et sert de client de référence de facto. D'autres implémentations incluent Bitcoin Unlimited, BCHD (écrit en Go) et Knuth (une implémentation haute performance en C++). L'existence de plusieurs implémentations indépendantes réduit le risque qu'un seul bug logiciel provoque une panne à l'échelle du réseau et garantit qu'aucune équipe de développement unique n'a un contrôle unilatéral sur le protocole.
Le minage sur Bitcoin Cash utilise l'algorithme de preuve de travail SHA-256, identique à celui de Bitcoin. Cela signifie que le même matériel de minage ASIC peut être utilisé pour miner l'une ou l'autre chaîne, et les mineurs peuvent alterner entre Bitcoin et Bitcoin Cash en fonction de la rentabilité. En pratique, le taux de hachage de Bitcoin Cash est une fraction de celui de Bitcoin, la majorité de la puissance de minage SHA-256 étant dirigée vers la chaîne Bitcoin plus rentable. Cependant, l'algorithme d'ajustement de difficulté de Bitcoin Cash garantit que les blocs sont produits à l'intervalle cible de dix minutes indépendamment du niveau absolu du taux de hachage.
L'algorithme d'ajustement de difficulté est l'un des composants de protocole les plus importants de Bitcoin Cash. L'ajustement de difficulté original de Bitcoin, qui recalcule tous les 2 016 blocs (environ deux semaines), était trop lent pour s'adapter aux fluctuations rapides du taux de hachage que Bitcoin Cash subissait lorsque les mineurs alternaient entre lui et Bitcoin. Après la période problématique d'Ajustement d'Urgence de la Difficulté (EDA) en 2017, Bitcoin Cash adopta un nouvel algorithme en novembre 2017 qui ajustait la difficulté sur une fenêtre mobile de 144 blocs.
En novembre 2020, Bitcoin Cash passa à l'algorithme d'ajustement de difficulté ASERT (Absolutely Scheduled Exponentially Rising Targets), également connu sous le nom d'aserti3-2d. ASERT est un algorithme mathématiquement élégant qui ajuste la cible de difficulté en fonction de la différence entre le temps réel écoulé et le temps attendu depuis un bloc de référence (le « bloc d'ancrage »). Si les blocs sont produits plus rapidement que prévu, la difficulté augmente exponentiellement ; si plus lentement, elle diminue exponentiellement. La désignation « 3-2d » fait référence à une demi-vie d'environ deux jours (spécifiquement 288 blocs à la cible de dix minutes), ce qui signifie qu'un doublement ou une réduction de moitié soutenu du taux de hachage entraînerait un ajustement complet de la difficulté dans les deux jours. ASERT s'est avéré hautement stable, produisant des intervalles de bloc cohérents même sous une volatilité significative du taux de hachage.
L'efficacité de la propagation des blocs est critique pour un réseau avec de grands blocs. Bitcoin Cash a adopté plusieurs optimisations pour s'assurer que les grands blocs puissent se propager rapidement à travers le réseau. Les Blocs Compacts (BIP 152), qui permettent aux nœuds de reconstruire des blocs à partir d'identifiants de transaction plutôt que de données de transaction complètes, réduisent considérablement la bande passante nécessaire à la propagation des blocs lorsque les nœuds ont des mempools qui se chevauchent. Le protocole Graphene fournit une compression encore plus grande en utilisant des structures de données probabilistes pour atteindre un encodage de bloc quasi optimal. Xthinner est un autre protocole de compression développé spécifiquement pour Bitcoin Cash qui atteint environ 99,6 pour cent de compression pour les blocs typiques.
Les politiques de relais et de mempool du réseau sont conçues pour supporter des transactions fiables à zéro confirmation. Les nœuds suivent une règle stricte du premier vu, acceptant et relayant uniquement la première version d'une transaction qu'ils observent. Si une seconde transaction tentant de dépenser les mêmes entrées (une tentative de double dépense) est détectée, les nœuds génèrent une preuve de double dépense et la propagent à travers le réseau, alertant les commerçants et autres parties intéressées. Cette infrastructure fournit un niveau de sécurité raisonnable pour accepter des transactions non confirmées pour les paiements quotidiens de faible valeur.
Smart Contract Capabilities
While Bitcoin Cash is primarily designed as a peer-to-peer electronic cash system, it has developed significant smart contract capabilities through extensions to its scripting language. Unlike Ethereum's account-based, Turing-complete smart contract model, Bitcoin Cash smart contracts operate within the UTXO model using a stack-based scripting language that is deliberately not Turing-complete. This design provides predictable execution costs and avoids the class of vulnerabilities associated with unbounded computation, while still enabling a surprisingly rich set of programmable financial instruments.
The Bitcoin Cash scripting language has been progressively enhanced through a series of protocol upgrades. In May 2018, several opcodes that had been disabled early in Bitcoin's history were re-enabled, including bitwise logic operators (OP_AND, OP_OR, OP_XOR), arithmetic operators for larger numbers, and string manipulation operations (OP_SPLIT, OP_CAT). These restored opcodes significantly expanded the expressiveness of Bitcoin Cash scripts.
The introduction of OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY in November 2018 was a particularly important advancement. These opcodes allow a transaction script to verify an ECDSA signature against arbitrary data, not just the transaction itself. This enables oracle-based contracts where an external data source signs a message attesting to some real-world condition (such as a price, weather event, or sports score), and the contract's execution depends on the content of that signed message. This capability opens the door to decentralized prediction markets, insurance contracts, and other financial instruments that depend on external data.
Native introspection opcodes, introduced in May 2022, allow transaction scripts to examine the properties of the transaction that contains them. Scripts can inspect the value, locking script, and token data of both inputs and outputs within the same transaction. This enables covenant-style contracts — scripts that restrict how coins can be spent in future transactions, not just who can spend them. Covenants enable powerful patterns such as vaults (time-locked spending restrictions for security), recurring payments, decentralized exchanges, and on-chain voting mechanisms.
CashScript is a high-level smart contract language for Bitcoin Cash, analogous to Solidity for Ethereum. CashScript allows developers to write contracts in a familiar, JavaScript-like syntax that is compiled down to Bitcoin Cash script bytecode. The language handles the complexity of UTXO-based contract design, including input/output introspection and signature verification, making it accessible to developers who may not be familiar with low-level stack-based programming. CashScript contracts have been used to build decentralized exchanges, escrow services, crowdfunding platforms, and other applications.
The CashTokens upgrade in May 2023 added another dimension to Bitcoin Cash's smart contract capabilities. By embedding fungible and non-fungible tokens directly into the UTXO model at the consensus level, CashTokens enables token-based contracts that are enforced by the network's consensus rules rather than overlay protocols. Non-fungible tokens (NFTs) in CashTokens carry a "commitment" field — arbitrary data attached to the token — that can be read and validated by smart contract scripts. This creates a mechanism for maintaining on-chain state across multiple transactions, a capability that was previously difficult to achieve in the UTXO model. Contracts can use NFTs as state carriers, updating the commitment data with each transaction to implement complex multi-step protocols.
The combination of introspection opcodes, CashTokens, and CashScript creates a smart contract platform that, while fundamentally different from Ethereum's model, is capable of implementing many of the same decentralized financial applications. Decentralized exchanges, automated market makers, lending protocols, and decentralized autonomous organizations have all been built or prototyped on Bitcoin Cash. The UTXO-based approach offers advantages in terms of parallelization (UTXOs can be validated independently), privacy (each UTXO is independent), and predictability (no global state to contend with), though it requires different design patterns than account-based systems.
Smart Contract Capabilities
Bien que Bitcoin Cash soit principalement conçu comme un système d'argent électronique pair-à-pair, il a développé des capacités significatives de contrats intelligents grâce à des extensions de son langage de script. Contrairement au modèle de contrats intelligents d'Ethereum, basé sur des comptes et Turing-complet, les contrats de Bitcoin Cash fonctionnent dans le modèle UTXO au moyen d'un langage de script à pile qui est délibérément non Turing-complet. Ce choix fournit des coûts d'exécution prévisibles et évite une classe de vulnérabilités liées au calcul non borné, tout en permettant néanmoins un ensemble étonnamment riche d'instruments financiers programmables.
Le langage de script de Bitcoin Cash a été renforcé progressivement à travers une série de mises à niveau de protocole. En mai 2018, plusieurs opcodes désactivés au début de l'histoire de Bitcoin ont été réactivés, notamment des opérateurs logiques bit à bit (OP_AND, OP_OR, OP_XOR), des opérateurs arithmétiques pour des nombres plus grands, et des opérations de manipulation de chaînes (OP_SPLIT, OP_CAT). Le retour de ces opcodes a considérablement augmenté l'expressivité des scripts Bitcoin Cash.
L'introduction de OP_CHECKDATASIG et OP_CHECKDATASIGVERIFY en novembre 2018 a constitué une avancée particulièrement importante. Ces opcodes permettent à un script de transaction de vérifier une signature ECDSA sur des données arbitraires, et pas uniquement sur la transaction elle-même. Cela rend possibles des contrats basés sur des oracles, où une source de données externe signe un message attestant d'une condition du monde réel (par exemple un prix, un événement météorologique ou un score sportif), et où l'exécution du contrat dépend du contenu de ce message signé. Cette capacité ouvre la voie à des marchés de prédiction décentralisés, des contrats d'assurance et d'autres instruments financiers dépendants de données externes.
Les opcodes d'introspection natifs, introduits en mai 2022, permettent aux scripts d'examiner les propriétés de la transaction qui les contient. Les scripts peuvent inspecter la valeur, le script de verrouillage et les données de jeton des entrées et des sorties au sein d'une même transaction. Cela rend possibles des contrats de type « covenant »: des scripts qui restreignent la manière dont des pièces pourront être dépensées dans des transactions futures, pas seulement qui peut les dépenser. Les covenants autorisent des modèles puissants comme des coffres (restrictions de dépense verrouillées dans le temps pour la sécurité), des paiements récurrents, des échanges décentralisés et des mécanismes de vote on-chain.
CashScript est un langage de contrat intelligent de haut niveau pour Bitcoin Cash, analogue à Solidity sur Ethereum. CashScript permet d'écrire des contrats dans une syntaxe familière de type JavaScript, qui est compilée en bytecode de script Bitcoin Cash. Le langage gère la complexité de la conception de contrats UTXO, notamment l'introspection des entrées/sorties et la vérification de signature, le rendant accessible à des développeurs qui ne maîtrisent pas la programmation bas niveau orientée pile. Des contrats CashScript ont servi à construire des échanges décentralisés, des services d'escrow, des plateformes de financement participatif et d'autres applications.
La mise à niveau CashTokens en mai 2023 a ajouté une dimension supplémentaire aux capacités de contrats intelligents de Bitcoin Cash. En intégrant des jetons fongibles et non fongibles directement dans le modèle UTXO au niveau du consensus, CashTokens permet des contrats basés sur des jetons qui sont appliqués par les règles de consensus du réseau plutôt que par des protocoles de surcouche. Les NFT dans CashTokens possèdent un champ « commitment »: des données arbitraires attachées au jeton, que les scripts de contrat intelligent peuvent lire et valider. Cela crée un mécanisme pour maintenir un état on-chain au fil de plusieurs transactions, ce qui était auparavant difficile à réaliser dans le modèle UTXO. Les contrats peuvent utiliser des NFT comme porteurs d'état, en mettant à jour les données de commitment à chaque transaction afin d'implémenter des protocoles complexes en plusieurs étapes.
La combinaison des opcodes d'introspection, de CashTokens et de CashScript forme une plateforme de contrats intelligents qui, bien que fondamentalement différente du modèle d'Ethereum, est capable de mettre en oeuvre bon nombre des mêmes applications financières décentralisées. Des échanges décentralisés, des teneurs de marché automatisés, des protocoles de prêt et des organisations autonomes décentralisées ont tous été construits ou prototypés sur Bitcoin Cash. L'approche basée sur UTXO offre des avantages en termes de parallélisation (les UTXO peuvent être validés indépendamment), de confidentialité (chaque UTXO est indépendant) et de prévisibilité (pas d'état global à gérer), mais elle exige des modèles de conception différents des systèmes basés sur des comptes.
Monetary Policy
Bitcoin Cash inherits Bitcoin's monetary policy in its entirety. The total supply of Bitcoin Cash is capped at 21 million coins, and the issuance schedule follows the same halving mechanism as Bitcoin. This shared monetary policy is a direct consequence of the fork: because Bitcoin Cash split from the Bitcoin blockchain, it began with the same issuance history and continues with the same future issuance rules.
The block-reward/" class="glossary-link" data-slug="block-reward" title="block reward">block reward started at 50 BCH per block (inherited from Bitcoin's genesis parameters) and halves every 210,000 blocks, approximately every four years. The first halving occurred in November 2012 (before the fork, so this is shared history), reducing the reward to 25 coins. The second halving in July 2016 reduced it to 12.5 coins. The third halving in April 2020, which occurred after the fork and thus was specific to the Bitcoin Cash chain, reduced the reward to 6.25 BCH. The fourth halving in April 2024 further reduced it to 3.125 BCH per block.
This halving schedule creates a disinflationary monetary policy in which the rate of new coin creation decreases over time, approaching zero asymptotically. The final Bitcoin Cash coin is expected to be mined around the year 2140. At that point, miner revenue will consist entirely of transaction fees.
The 21 million supply cap and halving schedule give Bitcoin Cash the same scarcity properties as Bitcoin. The circulating supply as of early 2026 is approximately 19.8 million BCH, representing over 94 percent of the total supply that will ever exist. The remaining coins will be distributed over more than a century of diminishing block rewards.
Bitcoin Cash's approach to the transition from block rewards to fee-based miner compensation differs from Bitcoin's strategy. Bitcoin's scaling philosophy, which constrains block space to maintain a fee market, implicitly relies on high per-transaction fees to compensate miners as block rewards diminish. Bitcoin Cash takes the opposite approach: by keeping fees low and blocks large, the network aims to generate sufficient total fee revenue through high transaction volume rather than high per-transaction fees. In this model, if each transaction pays a fee of one cent but the network processes millions of transactions per block, the aggregate fee revenue can still be substantial enough to incentivize mining.
This volume-based fee model requires that Bitcoin Cash achieves significantly higher transaction throughput than Bitcoin to provide equivalent miner incentives in the post-subsidy era. Proponents argue that this is achievable through continued on-chain scaling, as global payment demand is enormous and even a modest share of worldwide transactions would represent millions of payments per day. Critics counter that achieving this level of adoption is uncertain and that the low-fee model may create insufficient incentives during the transition period.
The shared monetary policy between Bitcoin and Bitcoin Cash means that the two chains are in direct competition for SHA-256 mining hash power. Miners allocate their resources to whichever chain is more profitable at any given time, and the difficulty adjustment algorithms on both chains accommodate this fluid allocation. In practice, Bitcoin Cash's share of the total SHA-256 hash rate has been proportional to its relative price, reflecting the rational economic behavior of profit-maximizing miners.
Monetary Policy
Bitcoin Cash hérite intégralement de la politique monétaire de Bitcoin. L'offre totale de Bitcoin Cash est plafonnée à 21 millions de pièces, et le calendrier d'émission suit le même mécanisme de halving que Bitcoin. Cette politique monétaire commune est une conséquence directe de la bifurcation: parce que Bitcoin Cash s'est séparé de la blockchain Bitcoin, il a démarré avec le même historique d'émission et continue d'appliquer les mêmes règles d'émission à l'avenir.
La récompense de bloc a commencé à 50 BCH par bloc (héritée des paramètres du bloc genesis de Bitcoin) et est divisée par deux tous les 210 000 blocs, soit environ tous les quatre ans. Le premier halving a eu lieu en novembre 2012 (avant la bifurcation, donc historique partagé), réduisant la récompense à 25 pièces. Le deuxième halving en juillet 2016 l'a réduite à 12,5 pièces. Le troisième halving en avril 2020, survenu après la bifurcation et donc spécifique à la chaîne Bitcoin Cash, l'a réduite à 6,25 BCH. Le quatrième halving en avril 2024 l'a encore réduite à 3,125 BCH par bloc.
Ce calendrier de halvings crée une politique monétaire désinflationniste où le rythme de création de nouvelles pièces diminue au fil du temps, en s'approchant asymptotiquement de zéro. La dernière pièce de Bitcoin Cash devrait être minée aux alentours de l'année 2140. À ce moment-là, les revenus des mineurs proviendront entièrement des frais de transaction.
Le plafond de 21 millions et le calendrier de halvings confèrent à Bitcoin Cash les mêmes propriétés de rareté que Bitcoin. L'offre en circulation au début de 2026 est d'environ 19,8 millions de BCH, soit plus de 94% de l'offre totale qui existera un jour. Les pièces restantes seront distribuées sur plus d'un siècle au travers de récompenses de bloc de plus en plus faibles.
L'approche de Bitcoin Cash concernant la transition des récompenses de bloc vers une rémunération des mineurs fondée sur les frais diffère de la stratégie de Bitcoin. La philosophie de mise à l'échelle de Bitcoin, qui contraint l'espace de bloc pour maintenir un marché des frais, repose implicitement sur des frais élevés par transaction afin de compenser les mineurs lorsque les récompenses diminuent. Bitcoin Cash prend l'approche inverse: en maintenant des frais bas et des blocs grands, le réseau vise à générer suffisamment de revenus de frais totaux grâce à un volume élevé de transactions plutôt qu'à des frais élevés par transaction. Dans ce modèle, si chaque transaction paie un centime mais que le réseau traite des millions de transactions par bloc, les revenus agrégés de frais peuvent tout de même être suffisamment importants pour inciter au minage.
Ce modèle fondé sur le volume exige que Bitcoin Cash atteigne un débit de transactions significativement plus élevé que Bitcoin pour fournir des incitations équivalentes aux mineurs à l'ère post-subvention. Les partisans soutiennent que cela est réalisable via la mise à l'échelle on-chain continue, car la demande mondiale en paiements est énorme et même une part modeste des transactions mondiales représenterait des millions de paiements par jour. Les critiques rétorquent que ce niveau d'adoption est incertain et que le modèle à faibles frais pourrait créer des incitations insuffisantes pendant la période de transition.
La politique monétaire partagée entre Bitcoin et Bitcoin Cash signifie que les deux chaînes sont en concurrence directe pour la puissance de hachage SHA-256. Les mineurs allouent leurs ressources à la chaîne la plus profitable à un moment donné, et les algorithmes d'ajustement de difficulté des deux chaînes s'adaptent à cette allocation fluide. En pratique, la part de Bitcoin Cash dans le taux de hachage total SHA-256 a été proportionnelle à son prix relatif, reflétant le comportement économique rationnel des mineurs cherchant à maximiser leur profit.
Conclusion
Bitcoin Cash represents a principled continuation of the original Bitcoin vision as peer-to-peer electronic cash. By increasing the block-size/" class="glossary-link" data-slug="block-size" title="block size">block size limit and pursuing on-chain scaling, Bitcoin Cash has maintained the low fees and fast transactions that characterized early Bitcoin, making it practical for the everyday payments and microtransactions that the original whitepaper envisioned.
The project's technical trajectory has been marked by thoughtful and consequential protocol improvements. The ASERT difficulty adjustment algorithm provides stable block production under volatile hash rate conditions. The enhanced scripting language, with restored and new opcodes, enables sophisticated smart contracts within the UTXO model's safety constraints. CashTokens brings consensus-enforced tokenization to the Bitcoin protocol for the first time. CashScript makes these capabilities accessible to a broad developer community. Together, these advances demonstrate that the UTXO model can support a rich ecosystem of decentralized applications while maintaining its fundamental simplicity and security properties.
The scaling debate that led to Bitcoin Cash's creation highlighted a fundamental tension in decentralized systems: the trade-off between on-chain capacity and the cost of operating full nodes. Bitcoin Cash has chosen to prioritize transaction capacity and user experience, arguing that the economic benefits of widespread adoption and usage outweigh the increased hardware requirements for node operators. This is an empirical question whose answer will unfold over the coming years and decades as both Bitcoin and Bitcoin Cash continue to evolve along their respective paths.
Bitcoin Cash's survival and continued development through multiple bear markets, contentious forks (notably the Bitcoin SV split in November 2018), and sustained community effort demonstrates the resilience of the project and the conviction of its participants. The network has processed hundreds of millions of transactions since the fork, maintained continuous operation, and attracted a global community of developers, merchants, and users who share the belief that peer-to-peer electronic cash is a technology worth building.
The long-term success of Bitcoin Cash depends on its ability to attract users and merchants who value low-fee, reliable transactions, and to scale its infrastructure to meet the demands of a global payment network. The technical foundations are sound, the roadmap is clear, and the community is committed. Whether Bitcoin Cash ultimately achieves its ambitious goal of serving as electronic cash for the world will be determined not by technical limitations but by the network effects, market dynamics, and adoption patterns that govern the evolution of all monetary systems.
Conclusion
Bitcoin Cash représente une continuation de principe de la vision originale de Bitcoin en tant qu'argent électronique pair-à-pair. En augmentant la limite de taille de bloc et en poursuivant la mise à l'échelle on-chain, Bitcoin Cash a conservé les faibles frais et les transactions rapides qui caractérisaient les débuts de Bitcoin, le rendant pratique pour les paiements quotidiens et les microtransactions que le whitepaper original envisageait.
La trajectoire technique du projet a été marquée par des améliorations de protocole réfléchies et conséquentes. L'algorithme d'ajustement de difficulté ASERT fournit une production de blocs stable malgré une volatilité du taux de hachage. Le langage de script amélioré, avec des opcodes restaurés et nouveaux, permet des contrats intelligents sophistiqués dans les contraintes de sécurité du modèle UTXO. CashTokens apporte la tokenisation appliquée par le consensus au protocole Bitcoin pour la première fois. CashScript rend ces capacités accessibles à une large communauté de développeurs. Ensemble, ces avancées démontrent que le modèle UTXO peut soutenir un écosystème riche d'applications décentralisées tout en conservant ses propriétés fondamentales de simplicité et de sécurité.
Le débat sur la mise à l'échelle qui a conduit à la création de Bitcoin Cash a mis en évidence une tension fondamentale des systèmes décentralisés: le compromis entre la capacité on-chain et le coût d'exploitation de nœuds complets. Bitcoin Cash a choisi de prioriser la capacité de transaction et l'expérience utilisateur, en affirmant que les bénéfices économiques d'une adoption et d'un usage généralisés l'emportent sur l'augmentation des exigences matérielles pour les opérateurs de nœuds. C'est une question empirique dont la réponse se précisera au cours des années et décennies à venir, à mesure que Bitcoin et Bitcoin Cash continueront d'évoluer selon leurs trajectoires respectives.
La survie et le développement continu de Bitcoin Cash à travers plusieurs marchés baissiers, des forks conflictuels (notamment la séparation Bitcoin SV en novembre 2018) et des efforts communautaires soutenus démontrent la résilience du projet et la conviction de ses participants. Le réseau a traité des centaines de millions de transactions depuis la bifurcation, a maintenu une opération continue, et a attiré une communauté mondiale de développeurs, de commerçants et d'utilisateurs qui partagent la croyance que l'argent électronique pair-à-pair est une technologie qui vaut la peine d'être construite.
Le succès à long terme de Bitcoin Cash dépend de sa capacité à attirer des utilisateurs et des commerçants qui valorisent des transactions fiables à faibles frais, et à faire évoluer son infrastructure pour répondre aux exigences d'un réseau de paiement mondial. Les fondations techniques sont solides, la feuille de route est claire et la communauté est engagée. La question de savoir si Bitcoin Cash atteindra finalement son objectif ambitieux de servir d'argent électronique pour le monde ne sera pas déterminée par des limitations techniques, mais par les effets de réseau, les dynamiques de marché et les schémas d'adoption qui gouvernent l'évolution de tous les systèmes monétaires.
Related Whitepapers
$DOGE
Dogecoin
Dogecoin: A Community-Driven Cryptocurrency
34 shared concepts · 2013
$ETH
Ethereum
Ethereum: A Next-Generation Smart Contract and Decentralized Application Platfo…
33 shared concepts · 2013
$SOL
Solana
Solana: A new architecture for a high performance blockchain
25 shared concepts · 2017
$USDT
Tether
Tether: Fiat currencies on the Bitcoin blockchain
24 shared concepts · 2016
$XRP
XRP
The Ripple Protocol Consensus Algorithm
21 shared concepts · 2014