Bitcoin Cash: Efectivo electrónico peer-to-peer para el mundo
Bitcoin Cash (BCH) 1 अगस्त, 2017 को Bitcoin से hard-fork हुआ। इसका अपना कोई whitepaper नहीं है — यहाँ प्रस्तुत दस्तावेज़ Satoshi Nakamoto का Bitcoin का मूल whitepaper है, जिसे Bitcoin Cash अपने peer-to-peer electronic cash vision की नींव के रूप में संदर्भित करता है।
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 es un sistema de efectivo electrónico peer-to-peer que se bifurcó de la cadena de bloques de Bitcoin el 1 de agosto de 2017. Creado en respuesta a las limitaciones de escalabilidad de Bitcoin, Bitcoin Cash aumentó el límite del tamaño de bloque para permitir un mayor rendimiento de transacciones y comisiones más bajas, restaurando la visión original de Bitcoin como un medio de intercambio práctico para las transacciones cotidianas. Con bloques de 32MB, un algoritmo de ajuste de dificultad adaptativo y un desarrollo continuo del protocolo, Bitcoin Cash aspira a escalar en cadena para servir como efectivo peer-to-peer global.
El proyecto Bitcoin Cash nació de un desacuerdo fundamental dentro de la comunidad de Bitcoin sobre cómo debería escalar la red para acomodar la creciente demanda. Mientras una facción abogaba por soluciones de escalado fuera de cadena como la Lightning Network construida sobre SegWit, otra facción argumentaba que aumentar el límite del tamaño de bloque era el enfoque más directo y probado para escalar. Cuando no se pudo alcanzar un consenso, el segundo grupo ejecutó una bifurcación dura, creando una nueva cadena que preservaba el historial de transacciones de Bitcoin mientras implementaba un límite de tamaño de bloque mayor y rechazaba SegWit. Este documento describe las especificaciones técnicas, la filosofía de diseño y la trayectoria de desarrollo 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
El libro blanco original de Bitcoin, publicado por Satoshi Nakamoto en 2008, describía "una versión puramente peer-to-peer de efectivo electrónico" que permitiría "enviar pagos en línea directamente de una parte a otra sin pasar por una institución financiera". Esta visión de Bitcoin como un medio de intercambio para transacciones cotidianas fue central para su adopción temprana y el crecimiento de su comunidad. Los primeros defensores de Bitcoin citaban frecuentemente las bajas comisiones de transacción y los pagos rápidos como ventajas clave sobre los sistemas financieros tradicionales.
Sin embargo, a medida que la popularidad de Bitcoin creció a mediados de la década de 2010, una restricción fundamental comenzó a limitar su utilidad como efectivo electrónico. El límite de tamaño de bloque de un megabyte, originalmente introducido como una medida temporal contra el spam, creó un techo artificial en el número de transacciones que la red podía procesar. A medida que la demanda de espacio en los bloques aumentaba, los usuarios se veían obligados a competir por la capacidad limitada ofreciendo comisiones de transacción más altas. A principios de 2017, la comisión mediana de las transacciones de Bitcoin había subido a varios dólares, haciendo que las transacciones de bajo valor fueran económicamente impracticables. Durante los períodos de máxima congestión, las comisiones podían superar los veinte dólares, y las transacciones podían permanecer sin confirmar durante horas o incluso días.
Esta situación representaba una desviación fundamental de la promesa original de Bitcoin. Un sistema diseñado para permitir pagos electrónicos peer-to-peer se estaba volviendo demasiado caro y demasiado lento para los casos de uso que fue creado para servir. Mientras Bitcoin se posicionaba cada vez más como "oro digital" — una reserva de valor en lugar de un medio de intercambio — muchos miembros de la comunidad y desarrolladores creían que esto representaba una traición a los principios fundacionales del proyecto.
Bitcoin Cash fue creado para resolver esta crisis adoptando el enfoque más directo para escalar: aumentar el límite del tamaño de bloque. Al permitir que más transacciones quepan en cada bloque, Bitcoin Cash buscó restaurar las comisiones bajas y las confirmaciones rápidas, haciendo que el efectivo electrónico peer-to-peer fuera práctico nuevamente. Los defensores del proyecto argumentaban que el escalado en cadena no solo era técnicamente factible, sino que era el enfoque que Satoshi Nakamoto había previsto originalmente, señalando comunicaciones tempranas en las que Nakamoto discutía la posibilidad de aumentar el límite del tamaño de bloque a medida que la red creciera.
La creación de Bitcoin Cash el 1 de agosto de 2017 fue uno de los eventos más significativos en la historia de las criptomonedas. Representó la primera gran división de cadena en la historia de Bitcoin impulsada por un genuino desacuerdo filosófico sobre la dirección futura del protocolo. La bifurcación demostró que en un sistema descentralizado, las disputas irresolubles pueden resolverse permitiendo que cada facción persiga su propia visión de forma independiente, con el mercado determinando finalmente el resultado.
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
El debate sobre la escalabilidad de Bitcoin fue una de las disputas más contenciosas y prolongadas en la historia del desarrollo de software de código abierto. En su esencia, el debate se centraba en una pregunta aparentemente simple: ¿cómo debería la red Bitcoin aumentar su capacidad de procesamiento de transacciones? Sin embargo, la respuesta a esta pregunta tocaba cuestiones fundamentales de gobernanza, descentralización, filosofía técnica y la propia identidad de Bitcoin.
El límite de tamaño de bloque de un megabyte de Bitcoin fue introducido por Satoshi Nakamoto en 2010 como una medida temporal para prevenir ataques de denegación de servicio en los que un adversario pudiera inundar la red con bloques sobredimensionados. En aquel momento, el uso real de los bloques estaba muy por debajo de este límite, y Nakamoto sugirió que el límite podría elevarse en el futuro mediante un simple cambio de código. Sin embargo, a medida que el uso de Bitcoin creció y los bloques comenzaron a llenarse, elevar el límite resultó ser mucho más contencioso de lo que nadie había anticipado.
Una facción, que llegó a asociarse con el equipo de desarrollo de Bitcoin Core, argumentaba que el tamaño de bloque debía mantenerse pequeño para preservar la descentralización. Su razonamiento era que bloques más grandes aumentarían los requisitos computacionales y de ancho de banda para ejecutar un nodo completo">nodo completo, pudiendo potencialmente excluir a los usuarios ordinarios y concentrar la operación de nodos entre entidades con muchos recursos. Propusieron un camino de escalado alternativo: SegWit, un cambio de protocolo que reestructuraba los datos de transacción para aumentar efectivamente la capacidad de transacciones del bloque sin elevar el límite de tamaño nominal, combinado con soluciones fuera de cadena como la Lightning Network que trasladarían la mayoría de las transacciones fuera de la cadena de bloques principal.
La facción opuesta, que incluía desarrolladores prominentes, mineros y empresas, argumentaba que elevar el límite del tamaño de bloque era la solución más simple, más probada y más urgente. Sostenían que el límite de un megabyte era una restricción arbitraria que nunca había sido concebida como una característica permanente del protocolo, y que los aumentos de comisiones y la congestión resultantes estaban alejando a los usuarios y comerciantes de Bitcoin. Eran escépticos respecto a la complejidad de SegWit y les preocupaba que la Lightning Network, que en ese momento era en gran parte teórica, pudiera no cumplir nunca sus promesas de transacciones baratas e instantáneas.
El debate se intensificó a través de una serie de propuestas y contrapropuestas. Bitcoin XT, propuesto por Mike Hearn y Gavin Andresen en 2015, buscaba aumentar el tamaño de bloque a 8MB. Bitcoin Classic propuso un aumento más modesto a 2MB. Bitcoin Unlimited propuso eliminar por completo el límite de tamaño de bloque, permitiendo a los mineros establecer sus propios límites a través de la dinámica del mercado. Cada propuesta generó un debate feroz y ninguna logró el consenso abrumador necesario para una bifurcación dura no contenciosa.
Se realizaron varios intentos de compromiso. El Acuerdo de Hong Kong (febrero de 2016) vio a los desarrolladores de Bitcoin Core y los mineros acordar desplegar SegWit seguido de una bifurcación dura a 2MB, pero el acuerdo se desmoronó cuando el componente de bifurcación dura no fue implementado. El Acuerdo de Nueva York (mayo de 2017), también conocido como SegWit2x, proponía activar SegWit inmediatamente seguido de una bifurcación dura a 2MB dentro de seis meses. Este acuerdo fue firmado por más de cincuenta empresas que representaban la mayoría del poder de hash de Bitcoin, pero fue fuertemente rechazado por el equipo de desarrollo de Bitcoin Core y una porción significativa de la comunidad de usuarios.
Cuando quedó claro que el compromiso era imposible, la facción de bloques grandes decidió actuar unilateralmente. El 1 de agosto de 2017, ejecutaron una bifurcación dura de la cadena de bloques de Bitcoin, creando Bitcoin Cash con un límite de tamaño de bloque inicial de 8MB. Esta no fue una decisión tomada a la ligera — requirió dividir la cadena de bloques, la red, la comunidad y la marca. Pero los defensores de Bitcoin Cash creían que era la única forma de preservar la visión original de Bitcoin como efectivo electrónico peer-to-peer.
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
La bifurcación dura de Bitcoin Cash se ejecutó el 1 de agosto de 2017, en la altura de bloque 478.558. En ese punto, la cadena de bloques de Bitcoin se dividió en dos cadenas separadas: la cadena original, que continuó como Bitcoin (BTC) con la activación de SegWit, y la nueva cadena, que se convirtió en Bitcoin Cash (BCH) con un límite de tamaño de bloque aumentado a 8MB.
La bifurcación fue técnicamente limpia y bien planificada. Cada dirección de Bitcoin que tenía un saldo en el momento de la bifurcación recibió un saldo idéntico en ambas cadenas. Si un usuario tenía 1 BTC antes de la bifurcación, tendría 1 BTC en la cadena de Bitcoin y 1 BCH en la cadena de Bitcoin Cash después de la bifurcación. Todo el historial de transacciones anterior al bloque 478.558 era compartido entre ambas cadenas.
Uno de los desafíos técnicos críticos de la bifurcación fue la implementación de la protección contra repetición. Sin protección contra repetición, una transacción transmitida en una cadena podría ser repetida en la otra cadena, causando potencialmente que los usuarios gastaran monedas involuntariamente en ambas cadenas. Bitcoin Cash implementó una fuerte protección contra repetición modificando el algoritmo de firma de transacciones. Específicamente, Bitcoin Cash introdujo una nueva bandera SigHash (SIGHASH_FORKID) que se incluye en el hash de la firma de cada transacción. Las transacciones firmadas con esta bandera son válidas en la cadena de Bitcoin Cash pero inválidas en la cadena de Bitcoin, y viceversa. Esto aseguró una separación limpia entre las dos redes desde el momento de la bifurcación.
El límite de tamaño de bloque inicial para Bitcoin Cash se estableció en 8MB, ocho veces mayor que el límite de 1MB de Bitcoin. Esto representó un aumento significativo en la capacidad de transacciones en cadena, permitiendo a Bitcoin Cash procesar sustancialmente más transacciones por bloque manteniendo comisiones bajas. El primer bloque de Bitcoin Cash después de la bifurcación fue minado por el pool de minería ViaBTC y tenía aproximadamente 1,9MB de tamaño, demostrando el beneficio práctico inmediato del tamaño de bloque más grande.
La bifurcación también eliminó SegWit, que había sido activado en la cadena de Bitcoin. Los desarrolladores de Bitcoin Cash rechazaron SegWit por varias razones: creían que introducía complejidad innecesaria en el protocolo, creaba un sistema de transacciones de dos niveles con diferentes estructuras de comisiones, y modificaba la estructura del bloque de maneras que argumentaban socavaban la simplicidad del modelo UTXO. Al elegir un aumento directo del tamaño de bloque, Bitcoin Cash mantuvo una arquitectura de protocolo más simple y tradicional al estilo de Bitcoin.
Después de la bifurcación, ambas cadenas tuvieron que lidiar con el desafío del ajuste de dificultad. Bitcoin Cash inicialmente usó la misma dificultad SHA-256 de la cadena de Bitcoin, pero con significativamente menos poder de hash dedicado a la minería. Para prevenir un escenario en el que los bloques se minaran extremadamente lento, Bitcoin Cash implementó un mecanismo de Ajuste de Dificultad de Emergencia (EDA) que disminuiría la dificultad en un 20 por ciento si se minaban menos de 6 bloques en un período de 12 horas. Si bien este mecanismo mantuvo exitosamente la cadena viva durante el período inicial crítico, resultó ser inestable, causando oscilaciones salvajes en los tiempos de producción de bloques y la tasa de hash a medida que los mineros alternaban entre Bitcoin y Bitcoin Cash según la rentabilidad. El EDA fue reemplazado en noviembre de 2017 por un algoritmo de ajuste de dificultad más estable basado en un promedio móvil de los 144 bloques anteriores.
La bifurcación fue recibida con considerable controversia en la comunidad de criptomonedas más amplia. Los críticos argumentaban que Bitcoin Cash era un intento ilegítimo de apropiarse de la marca Bitcoin, mientras que los defensores sostenían que era una continuación legítima de la hoja de ruta original de Bitcoin. Los exchanges y proveedores de servicios tuvieron que tomar decisiones rápidas sobre si apoyar la nueva cadena y cómo manejar la distribución de monedas bifurcadas a sus clientes. A pesar de la controversia, Bitcoin Cash se estableció rápidamente como una criptomoneda viable y activamente utilizada, logrando un volumen de negociación significativo y adopción por parte de comerciantes en los meses posteriores a la bifurcación.
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 comparte la arquitectura técnica fundamental de Bitcoin, incluyendo el mecanismo de consenso de prueba de trabajo SHA-256, el modelo de transacciones UTXO, la curva elíptica secp256k1 para firmas digitales y el intervalo objetivo de bloques de diez minutos. Sin embargo, varias modificaciones clave lo diferencian del protocolo de Bitcoin.
La diferencia más prominente es el límite de tamaño de bloque. Bitcoin Cash se lanzó con un límite de tamaño de bloque de 8MB y posteriormente lo aumentó a 32MB en mayo de 2018. Este límite de 32MB proporciona aproximadamente 32 veces la capacidad de transacciones del tamaño de bloque efectivo de 1MB sin SegWit de Bitcoin (o aproximadamente 8 veces la capacidad del límite efectivo de Bitcoin mejorado con SegWit de aproximadamente 4MB). El tamaño de bloque más grande es la piedra angular de la filosofía de escalado en cadena de Bitcoin Cash, proporcionando amplio espacio para el crecimiento de transacciones sin la presión de comisiones que surge cuando los bloques están consistentemente llenos.
Bitcoin Cash no implementa SegWit. En lugar de separar los datos de testigos de los datos de transacciones como hace SegWit, Bitcoin Cash mantiene intacto el formato de transacciones original de Bitcoin. Todos los datos de transacción, incluidas las firmas, se almacenan dentro del bloque de manera tradicional. Esto simplifica el protocolo y mantiene la compatibilidad retroactiva con el software e infraestructura de Bitcoin más antiguos.
Una mejora significativa del protocolo en Bitcoin Cash es el algoritmo SigHash mejorado, que fue introducido en el momento de la bifurcación. El nuevo algoritmo, basado en BIP 143 (que fue desarrollado originalmente para SegWit), corrige el problema de hash cuadrático que existía en el esquema original de verificación de firmas de Bitcoin. En el esquema original, el costo computacional de verificar la firma de una transacción crecía cuadráticamente con el número de entradas, creando un vector potencial de ataque de denegación de servicio. El nuevo algoritmo SigHash hace que el costo de verificación sea lineal, permitiendo que la red procese transacciones más grandes y complejas de manera segura.
Bitcoin Cash soporta un tamaño máximo de transacción más grande y un mayor número de operaciones de firma (sigops) por bloque comparado con Bitcoin. El límite de sigops se escala proporcionalmente con el tamaño del bloque, asegurando que el costo computacional de la validación del bloque permanezca acotado mientras permite significativamente más transacciones por bloque.
El sistema de scripts en Bitcoin Cash ha sido desarrollado activamente más allá del enfoque comparativamente conservador de Bitcoin. Bitcoin Cash ha reactivado e introducido varios opcodes que amplían la expresividad de su lenguaje de scripts. Adiciones notables incluyen OP_CHECKDATASIG y OP_CHECKDATASIGVERIFY, que permiten a los scripts de transacción verificar firmas contra datos arbitrarios (no solo datos de transacción), habilitando contratos inteligentes basados en oráculos y otros patrones avanzados de scripting. El opcode OP_REVERSEBYTES, los opcodes de introspección nativos y los límites más grandes de script y pila han mejorado aún más la programabilidad de Bitcoin Cash.
Bitcoin Cash utiliza la misma base de formato de dirección que Bitcoin pero adoptó el formato CashAddr en enero de 2018 para prevenir confusiones y errores de envío entre cadenas. Las direcciones CashAddr comienzan con "bitcoincash:" como prefijo (frecuentemente abreviado a "q" o "p" para la porción del hash) y utilizan un esquema de codificación diferente al formato base58check de Bitcoin. Esta distinción visual hace inmediatamente claro si una dirección pertenece a Bitcoin o Bitcoin Cash, reduciendo el riesgo de que los usuarios envíen accidentalmente monedas a la cadena incorrecta.
La red opera en el puerto 8333, el mismo puerto predeterminado que Bitcoin, aunque los nodos de Bitcoin Cash se identifican con un número mágico de red diferente en el handshake del protocolo. Esto significa que los nodos de Bitcoin y Bitcoin Cash no se conectarán accidentalmente entre sí a pesar de usar el mismo puerto.
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
El rendimiento de transacciones y la escalabilidad son centrales para la propuesta de valor de Bitcoin Cash. La tesis fundamental del proyecto es que el efectivo electrónico peer-to-peer debe ser capaz de procesar transacciones de manera rápida y económica para ser viable para el uso cotidiano, y que el escalado en cadena mediante bloques más grandes es la forma más confiable de lograrlo.
Con un límite de tamaño de bloque de 32MB y un intervalo de bloques de diez minutos, Bitcoin Cash tiene un rendimiento máximo teórico de aproximadamente 100 transacciones por segundo, dependiendo del tamaño promedio de la transacción. Esto representa un aumento sustancial sobre el máximo teórico de Bitcoin de aproximadamente 7 transacciones por segundo con bloques de 1MB. En la práctica, el rendimiento real depende de la combinación de tipos y tamaños de transacciones, pero la capacidad de Bitcoin Cash es más que suficiente para su volumen actual de transacciones, con bloques típicamente muy por debajo del límite de 32MB.
La abundancia de espacio disponible en los bloques tiene un impacto directo y medible en las comisiones de transacción. Cuando los bloques no están llenos, no hay competencia de comisiones, y las transacciones pueden confirmarse con comisiones mínimas. La comisión mínima de retransmisión predeterminada de Bitcoin Cash es de 1 satoshi por byte (donde 1 satoshi = 0,00000001 BCH), y la mayoría de las transacciones se confirman en el siguiente bloque a este mínimo o cerca de él. Esto hace que las transacciones de Bitcoin Cash cuesten fracciones de un centavo en condiciones normales, comparado con las comisiones de Bitcoin que pueden ir desde dólares hasta decenas de dólares durante períodos de congestión.
La comunidad de desarrollo de Bitcoin Cash ha llevado a cabo una extensa investigación y pruebas sobre los límites del escalado en cadena. La Iniciativa Gigablock Testnet, realizada en 2017-2018, demostró que el protocolo Bitcoin podía manejar bloques de 1GB o más con las optimizaciones de software apropiadas y hardware moderno. Estas pruebas identificaron varios cuellos de botella en la base de código original — incluyendo la propagación de bloques, la validación de transacciones y la gestión del conjunto UTXO — e informaron los esfuerzos de optimización posteriores.
Se han realizado varias mejoras de protocolo e implementación para soportar bloques más grandes. Graphene, un protocolo de propagación de bloques basado en tablas de búsqueda de Bloom invertibles y filtros de Bloom, reduce drásticamente el ancho de banda necesario para propagar bloques codificando solo la diferencia entre un bloque y las transacciones que un nodo receptor ya tiene en su mempool. El Ordenamiento Canónico de Transacciones (CTOR), implementado en noviembre de 2018, requiere que las transacciones dentro de un bloque se ordenen por su identificador de transacción. Este cambio aparentemente menor permite optimizaciones significativas en la validación y propagación de bloques, ya que permite la validación paralela de transacciones y algoritmos de reconciliación de conjuntos más eficientes.
Las iniciativas de compromiso UTXO y validación paralela han mejorado aún más la capacidad de la red para manejar bloques grandes de manera eficiente. Aprovechando los procesadores multinúcleo modernos y el almacenamiento de estado sólido, las implementaciones de nodos optimizadas pueden validar bloques que contienen decenas de miles de transacciones dentro de marcos de tiempo aceptables.
La hoja de ruta de escalabilidad de Bitcoin Cash prevé aumentos adicionales en el límite de tamaño de bloque a medida que la tecnología y la demanda lo justifiquen. Los desarrolladores del proyecto han expresado un objetivo a largo plazo de soportar volúmenes de pago a escala global completamente en cadena, apuntando a niveles de rendimiento que permitirían a Bitcoin Cash servir miles de millones de transacciones diarias. Si bien este objetivo es ambicioso, las mejoras continuas en las capacidades del hardware, el ancho de banda de red y la optimización de software proporcionan un camino creíble para lograrlo incrementalmente a lo largo del tiempo.
Un aspecto importante del enfoque de escalado de Bitcoin Cash es el concepto de transacciones de "cero confirmaciones". Para pagos de bajo valor, los comerciantes pueden aceptar transacciones inmediatamente después de su transmisión, antes de que sean incluidas en un bloque. Bitcoin Cash ha implementado varias medidas para mejorar la fiabilidad de las transacciones de cero confirmaciones, incluyendo la regla de "primera vista" (donde los nodos retransmiten solo la primera versión de una transacción que ven, haciendo más difíciles los intentos de doble gasto) y protocolos de notificación de doble gasto que alertan a los comerciantes si se detecta una transacción conflictiva. Estas medidas hacen que Bitcoin Cash sea práctico para transacciones en punto de venta donde esperar diez minutos para una confirmación de bloque sería impracticable.
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 soporta el opcode OP_RETURN, que permite a los usuarios incrustar datos arbitrarios en la cadena de bloques dentro de una salida de transacción que es demostrablemente imposible de gastar. Esta característica habilita una gama de aplicaciones centradas en datos construidas sobre la cadena de bloques de Bitcoin Cash, incluyendo protocolos de tokens, sistemas de mensajería, servicios de notarización y plataformas de redes sociales.
El límite de datos OP_RETURN en Bitcoin Cash se ha establecido en 220 bytes por salida, significativamente mayor que el límite de 80 bytes de Bitcoin. Adicionalmente, Bitcoin Cash permite múltiples salidas OP_RETURN en una sola transacción, ampliando aún más la cantidad de datos que pueden incrustarse en una sola transacción. Estos límites generosos, combinados con bajas comisiones de transacción, hacen de Bitcoin Cash una plataforma económicamente viable para aplicaciones de datos que serían prohibitivamente costosas en cadenas con mayor restricción de capacidad.
El Simple Ledger Protocol (SLP) fue uno de los sistemas de tokens más tempranos y ampliamente adoptados construidos sobre Bitcoin Cash usando OP_RETURN. SLP permitía a los usuarios crear y transferir tokens personalizados en la cadena de bloques de Bitcoin Cash codificando metadatos de tokens en salidas OP_RETURN. Aunque SLP ha sido en gran parte superado por el protocolo CashTokens, demostró la viabilidad de construir economías de tokens sobre el modelo UTXO.
CashTokens, activado en mayo de 2023, representa un enfoque más sofisticado para la tokenización en Bitcoin Cash. A diferencia de SLP, que dependía de metadatos OP_RETURN que podían ser ignorados por el protocolo base, CashTokens es una característica a nivel de consenso que integra tokens directamente en el modelo UTXO. Cada UTXO puede llevar tanto un valor en BCH como un token asociado, con la validez del token aplicada por las reglas de consenso. CashTokens soporta dos tipos de tokens: tokens fungibles (similares a los tokens ERC-20 en Ethereum) y tokens no fungibles (NFTs). La aplicación a nivel de consenso significa que las transacciones de tokens tienen las mismas garantías de seguridad que las transacciones nativas de BCH, eliminando las suposiciones de confianza y los requisitos de indexación de protocolos superpuestos como SLP.
Memo.cash es un protocolo de redes sociales descentralizado construido sobre Bitcoin Cash usando transacciones OP_RETURN. Los usuarios transmiten publicaciones, seguimientos, likes y otras acciones sociales como transacciones de Bitcoin Cash con datos OP_RETURN codificados. Dado que los datos se almacenan en la cadena de bloques, son resistentes a la censura y se archivan permanentemente. Los bajos costos de transacción en Bitcoin Cash hacen esto económicamente factible — cada acción de redes sociales cuesta una fracción de un centavo.
Otras aplicaciones de datos en Bitcoin Cash incluyen servicios de sellado temporal y notarización de documentos, donde el hash de un documento se incrusta en una salida OP_RETURN para crear un registro permanente e inalterable de la existencia del documento en un punto específico en el tiempo. El seguimiento de la cadena de suministro, la verificación de credenciales y los sistemas de identidad descentralizada también se han construido utilizando las capacidades de incrustación de datos de Bitcoin Cash.
La combinación de gran capacidad OP_RETURN, bajas comisiones y tiempos de confirmación rápidos posiciona a Bitcoin Cash como una plataforma competitiva para aplicaciones de datos basadas en blockchain. Aunque existen blockchains de datos especializadas, Bitcoin Cash ofrece la ventaja de una red bien establecida, altamente segura y ampliamente soportada con un historial probado de operación continua.
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
La red Bitcoin Cash opera sobre la misma arquitectura peer-to-peer fundamental que Bitcoin, con nodos comunicándose a través de un protocolo de chismorreo para propagar transacciones y bloques. Los nodos completos mantienen una copia completa de la cadena de bloques y validan independientemente todas las transacciones y bloques de acuerdo con las reglas de consenso. La red es sin permisos, lo que significa que cualquiera puede operar un nodo y participar en la red sin autorización.
Existen múltiples implementaciones independientes de nodos completos para Bitcoin Cash, reflejando el compromiso del proyecto con el desarrollo descentralizado. Bitcoin Cash Node (BCHN) es la implementación más ampliamente utilizada y sirve como el cliente de referencia de facto. Otras implementaciones incluyen Bitcoin Unlimited, BCHD (escrito en Go) y Knuth (una implementación de alto rendimiento en C++). La existencia de múltiples implementaciones independientes reduce el riesgo de que un solo error de software cause una falla en toda la red y asegura que ningún equipo de desarrollo individual tenga control unilateral sobre el protocolo.
La minería en Bitcoin Cash utiliza el algoritmo de prueba de trabajo SHA-256, idéntico al de Bitcoin. Esto significa que el mismo hardware de minería ASIC puede usarse para minar cualquiera de las dos cadenas, y los mineros pueden alternar entre Bitcoin y Bitcoin Cash basándose en la rentabilidad. En la práctica, la tasa de hash de Bitcoin Cash es una fracción de la de Bitcoin, ya que la mayoría del poder de minería SHA-256 se dirige a la cadena de Bitcoin, más rentable. Sin embargo, el algoritmo de ajuste de dificultad de Bitcoin Cash asegura que los bloques se produzcan en el intervalo objetivo de diez minutos independientemente del nivel absoluto de tasa de hash.
El algoritmo de ajuste de dificultad es uno de los componentes de protocolo más importantes de Bitcoin Cash. El ajuste de dificultad original de Bitcoin, que recalcula cada 2.016 bloques (aproximadamente cada dos semanas), era demasiado lento para acomodar las rápidas fluctuaciones de tasa de hash que Bitcoin Cash experimentaba cuando los mineros alternaban entre él y Bitcoin. Después del problemático período de Ajuste de Dificultad de Emergencia (EDA) en 2017, Bitcoin Cash adoptó un nuevo algoritmo en noviembre de 2017 que ajustaba la dificultad basándose en una ventana móvil de 144 bloques.
En noviembre de 2020, Bitcoin Cash se actualizó al algoritmo de ajuste de dificultad ASERT (Absolutely Scheduled Exponentially Rising Targets), también conocido como aserti3-2d. ASERT es un algoritmo matemáticamente elegante que ajusta el objetivo de dificultad basándose en la diferencia entre el tiempo real transcurrido y el tiempo esperado desde un bloque de referencia (el "bloque ancla"). Si los bloques se están produciendo más rápido de lo esperado, la dificultad aumenta exponencialmente; si más lento, disminuye exponencialmente. La designación "3-2d" se refiere a una vida media de aproximadamente dos días (específicamente 288 bloques al objetivo de diez minutos), lo que significa que una duplicación o reducción a la mitad sostenida de la tasa de hash resultaría en un ajuste completo de dificultad dentro de dos días. ASERT ha demostrado ser altamente estable, produciendo intervalos de bloque consistentes incluso bajo una volatilidad significativa de la tasa de hash.
La eficiencia en la propagación de bloques es crítica para una red con bloques grandes. Bitcoin Cash ha adoptado varias optimizaciones para asegurar que los bloques grandes puedan propagarse rápidamente por la red. Los Bloques Compactos (BIP 152), que permiten a los nodos reconstruir bloques a partir de identificadores de transacción en lugar de datos completos de transacciones, reducen drásticamente el ancho de banda necesario para la propagación de bloques cuando los nodos tienen mempools superpuestos. El protocolo Graphene proporciona una compresión aún mayor mediante el uso de estructuras de datos probabilísticas para lograr una codificación de bloques casi óptima. Xthinner es otro protocolo de compresión desarrollado específicamente para Bitcoin Cash que logra aproximadamente un 99,6 por ciento de compresión para bloques típicos.
Las políticas de retransmisión y mempool de la red están diseñadas para soportar transacciones de cero confirmaciones fiables. Los nodos siguen una regla estricta de primera vista, aceptando y retransmitiendo solo la primera versión de una transacción que observan. Si se detecta una segunda transacción que intenta gastar las mismas entradas (un intento de doble gasto), los nodos generarán una prueba de doble gasto y la propagarán por la red, alertando a los comerciantes y otras partes interesadas. Esta infraestructura proporciona un nivel de seguridad razonable para aceptar transacciones no confirmadas para pagos cotidianos de bajo valor.
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
Si bien Bitcoin Cash está diseñado principalmente como un sistema de efectivo electrónico peer-to-peer, ha desarrollado capacidades significativas de contratos inteligentes a través de extensiones a su lenguaje de scripts. A diferencia del modelo de contratos inteligentes basado en cuentas y Turing-completo de Ethereum, los contratos inteligentes de Bitcoin Cash operan dentro del modelo UTXO usando un lenguaje de scripts basado en pila que deliberadamente no es Turing-completo. Este diseño proporciona costos de ejecución predecibles y evita la clase de vulnerabilidades asociadas con la computación ilimitada, mientras permite un conjunto sorprendentemente rico de instrumentos financieros programables.
El lenguaje de scripts de Bitcoin Cash ha sido progresivamente mejorado a través de una serie de actualizaciones de protocolo. En mayo de 2018, varios opcodes que habían sido desactivados temprano en la historia de Bitcoin fueron reactivados, incluyendo operadores de lógica bit a bit (OP_AND, OP_OR, OP_XOR), operadores aritméticos para números más grandes y operaciones de manipulación de cadenas (OP_SPLIT, OP_CAT). Estos opcodes restaurados expandieron significativamente la expresividad de los scripts de Bitcoin Cash.
La introducción de OP_CHECKDATASIG y OP_CHECKDATASIGVERIFY en noviembre de 2018 fue un avance particularmente importante. Estos opcodes permiten que un script de transacción verifique una firma ECDSA contra datos arbitrarios, no solo la transacción misma. Esto habilita contratos basados en oráculos donde una fuente de datos externa firma un mensaje atestiguando alguna condición del mundo real (como un precio, evento climático o resultado deportivo), y la ejecución del contrato depende del contenido de ese mensaje firmado. Esta capacidad abre la puerta a mercados de predicción descentralizados, contratos de seguros y otros instrumentos financieros que dependen de datos externos.
Los opcodes de introspección nativos, introducidos en mayo de 2022, permiten a los scripts de transacción examinar las propiedades de la transacción que los contiene. Los scripts pueden inspeccionar el valor, el script de bloqueo y los datos de tokens tanto de entradas como de salidas dentro de la misma transacción. Esto habilita contratos de estilo covenant — scripts que restringen cómo las monedas pueden gastarse en transacciones futuras, no solo quién puede gastarlas. Los covenants habilitan patrones poderosos como bóvedas (restricciones de gasto con bloqueo temporal para seguridad), pagos recurrentes, exchanges descentralizados y mecanismos de votación en cadena.
CashScript es un lenguaje de contratos inteligentes de alto nivel para Bitcoin Cash, análogo a Solidity para Ethereum. CashScript permite a los desarrolladores escribir contratos en una sintaxis familiar, similar a JavaScript, que se compila a bytecode de scripts de Bitcoin Cash. El lenguaje maneja la complejidad del diseño de contratos basados en UTXO, incluyendo la introspección de entrada/salida y la verificación de firmas, haciéndolo accesible para desarrolladores que pueden no estar familiarizados con la programación de bajo nivel basada en pila. Los contratos CashScript se han utilizado para construir exchanges descentralizados, servicios de custodia, plataformas de crowdfunding y otras aplicaciones.
La actualización CashTokens en mayo de 2023 añadió otra dimensión a las capacidades de contratos inteligentes de Bitcoin Cash. Al incrustar tokens fungibles y no fungibles directamente en el modelo UTXO a nivel de consenso, CashTokens habilita contratos basados en tokens que son aplicados por las reglas de consenso de la red en lugar de protocolos superpuestos. Los tokens no fungibles (NFTs) en CashTokens llevan un campo de "compromiso" — datos arbitrarios adjuntos al token — que pueden ser leídos y validados por scripts de contratos inteligentes. Esto crea un mecanismo para mantener estado en cadena a través de múltiples transacciones, una capacidad que anteriormente era difícil de lograr en el modelo UTXO. Los contratos pueden usar NFTs como portadores de estado, actualizando los datos de compromiso con cada transacción para implementar protocolos complejos de múltiples pasos.
La combinación de opcodes de introspección, CashTokens y CashScript crea una plataforma de contratos inteligentes que, aunque fundamentalmente diferente del modelo de Ethereum, es capaz de implementar muchas de las mismas aplicaciones financieras descentralizadas. Exchanges descentralizados, creadores de mercado automatizados, protocolos de préstamo y organizaciones autónomas descentralizadas han sido construidos o prototipados en Bitcoin Cash. El enfoque basado en UTXO ofrece ventajas en términos de paralelización (los UTXOs pueden validarse independientemente), privacidad (cada UTXO es independiente) y predictibilidad (sin estado global con el que contender), aunque requiere patrones de diseño diferentes a los sistemas basados en cuentas.
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 hereda la política monetaria de Bitcoin en su totalidad. La oferta total de Bitcoin Cash está limitada a 21 millones de monedas, y el calendario de emisión sigue el mismo mecanismo de reducción a la mitad que Bitcoin. Esta política monetaria compartida es una consecuencia directa de la bifurcación: debido a que Bitcoin Cash se separó de la cadena de bloques de Bitcoin, comenzó con el mismo historial de emisión y continúa con las mismas reglas de emisión futuras.
La recompensa por bloque comenzó en 50 BCH por bloque (heredada de los parámetros de génesis de Bitcoin) y se reduce a la mitad cada 210.000 bloques, aproximadamente cada cuatro años. La primera reducción a la mitad ocurrió en noviembre de 2012 (antes de la bifurcación, por lo que es historia compartida), reduciendo la recompensa a 25 monedas. La segunda reducción a la mitad en julio de 2016 la redujo a 12,5 monedas. La tercera reducción a la mitad en abril de 2020, que ocurrió después de la bifurcación y por lo tanto fue específica de la cadena Bitcoin Cash, redujo la recompensa a 6,25 BCH. La cuarta reducción a la mitad en abril de 2024 la redujo aún más a 3,125 BCH por bloque.
Este calendario de reducción a la mitad crea una política monetaria desinflacionaria en la que la tasa de creación de nuevas monedas disminuye con el tiempo, acercándose a cero asintóticamente. Se espera que la última moneda de Bitcoin Cash se mine alrededor del año 2140. En ese momento, los ingresos de los mineros consistirán enteramente en comisiones de transacción.
El límite de oferta de 21 millones y el calendario de reducción a la mitad dan a Bitcoin Cash las mismas propiedades de escasez que Bitcoin. La oferta circulante a principios de 2026 es de aproximadamente 19,8 millones de BCH, representando más del 94 por ciento de la oferta total que existirá. Las monedas restantes se distribuirán durante más de un siglo de recompensas de bloque decrecientes.
El enfoque de Bitcoin Cash hacia la transición de recompensas de bloque a compensación de mineros basada en comisiones difiere de la estrategia de Bitcoin. La filosofía de escalado de Bitcoin, que restringe el espacio de bloque para mantener un mercado de comisiones, depende implícitamente de altas comisiones por transacción para compensar a los mineros a medida que las recompensas de bloque disminuyen. Bitcoin Cash adopta el enfoque opuesto: al mantener las comisiones bajas y los bloques grandes, la red busca generar ingresos totales por comisiones suficientes a través de un alto volumen de transacciones en lugar de altas comisiones por transacción. En este modelo, si cada transacción paga una comisión de un centavo pero la red procesa millones de transacciones por bloque, los ingresos agregados por comisiones pueden ser lo suficientemente sustanciales como para incentivar la minería.
Este modelo de comisiones basado en volumen requiere que Bitcoin Cash logre un rendimiento de transacciones significativamente mayor que el de Bitcoin para proporcionar incentivos equivalentes a los mineros en la era posterior a los subsidios. Los defensores argumentan que esto es alcanzable a través del escalado continuo en cadena, ya que la demanda global de pagos es enorme e incluso una participación modesta de las transacciones mundiales representaría millones de pagos diarios. Los críticos replican que lograr este nivel de adopción es incierto y que el modelo de bajas comisiones puede crear incentivos insuficientes durante el período de transición.
La política monetaria compartida entre Bitcoin y Bitcoin Cash significa que las dos cadenas compiten directamente por el poder de hash de minería SHA-256. Los mineros asignan sus recursos a la cadena que sea más rentable en cualquier momento dado, y los algoritmos de ajuste de dificultad de ambas cadenas acomodan esta asignación fluida. En la práctica, la participación de Bitcoin Cash en la tasa de hash total de SHA-256 ha sido proporcional a su precio relativo, reflejando el comportamiento económico racional de los mineros que maximizan sus beneficios.
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 representa una continuación basada en principios de la visión original de Bitcoin como efectivo electrónico peer-to-peer. Al aumentar el límite del tamaño de bloque y perseguir el escalado en cadena, Bitcoin Cash ha mantenido las bajas comisiones y las transacciones rápidas que caracterizaban al Bitcoin temprano, haciéndolo práctico para los pagos cotidianos y las microtransacciones que el libro blanco original visualizaba.
La trayectoria técnica del proyecto ha estado marcada por mejoras de protocolo reflexivas y trascendentes. El algoritmo de ajuste de dificultad ASERT proporciona una producción de bloques estable bajo condiciones volátiles de tasa de hash. El lenguaje de scripts mejorado, con opcodes restaurados y nuevos, permite contratos inteligentes sofisticados dentro de las restricciones de seguridad del modelo UTXO. CashTokens trae la tokenización aplicada a nivel de consenso al protocolo Bitcoin por primera vez. CashScript hace estas capacidades accesibles a una amplia comunidad de desarrolladores. En conjunto, estos avances demuestran que el modelo UTXO puede soportar un rico ecosistema de aplicaciones descentralizadas mientras mantiene sus propiedades fundamentales de simplicidad y seguridad.
El debate sobre escalabilidad que condujo a la creación de Bitcoin Cash destacó una tensión fundamental en los sistemas descentralizados: el equilibrio entre la capacidad en cadena y el costo de operar nodos completos. Bitcoin Cash ha elegido priorizar la capacidad de transacciones y la experiencia del usuario, argumentando que los beneficios económicos de una adopción y uso generalizados superan los mayores requisitos de hardware para los operadores de nodos. Esta es una cuestión empírica cuya respuesta se desenvolverá en los próximos años y décadas a medida que tanto Bitcoin como Bitcoin Cash continúen evolucionando por sus respectivos caminos.
La supervivencia y el desarrollo continuo de Bitcoin Cash a través de múltiples mercados bajistas, bifurcaciones contenciosas (notablemente la división de Bitcoin SV en noviembre de 2018) y el esfuerzo sostenido de la comunidad demuestran la resiliencia del proyecto y la convicción de sus participantes. La red ha procesado cientos de millones de transacciones desde la bifurcación, ha mantenido una operación continua y ha atraído una comunidad global de desarrolladores, comerciantes y usuarios que comparten la creencia de que el efectivo electrónico peer-to-peer es una tecnología que vale la pena construir.
El éxito a largo plazo de Bitcoin Cash depende de su capacidad para atraer usuarios y comerciantes que valoren las transacciones de bajas comisiones y fiables, y para escalar su infraestructura para satisfacer las demandas de una red de pagos global. Las bases técnicas son sólidas, la hoja de ruta es clara y la comunidad está comprometida. Si Bitcoin Cash alcanza finalmente su ambicioso objetivo de servir como efectivo electrónico para el mundo será determinado no por limitaciones técnicas sino por los efectos de red, las dinámicas de mercado y los patrones de adopción que gobiernan la evolución de todos los sistemas monetarios.
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