Bitcoin Cash: Dinheiro eletrônico peer-to-peer para o mundo
Bitcoin Cash (BCH) แยกออกจาก Bitcoin เมื่อวันที่ 1 สิงหาคม 2017 โดยไม่มี whitepaper ของตัวเอง เอกสารที่นำเสนอที่นี่คือ whitepaper ต้นฉบับของ Bitcoin โดย Satoshi Nakamoto ซึ่ง Bitcoin Cash อ้างอิงเป็นรากฐานของวิสัยทัศน์เงินสดอิเล็กทรอนิกส์แบบ peer-to-peer
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
O Bitcoin Cash é um sistema de dinheiro eletrônico peer-to-peer que se bifurcou da blockchain do Bitcoin em 1 de agosto de 2017. Criado em resposta às limitações de escalabilidade do Bitcoin, o Bitcoin Cash aumentou o limite do tamanho de bloco para permitir maior throughput de transações e taxas mais baixas, restaurando a visão original do Bitcoin como um meio de troca prático para transações cotidianas. Com blocos de 32MB, um algoritmo de ajuste de dificuldade adaptativo e desenvolvimento contínuo do protocolo, o Bitcoin Cash visa escalar on-chain para servir como dinheiro peer-to-peer global.
O projeto Bitcoin Cash nasceu de uma divergência fundamental dentro da comunidade Bitcoin sobre como a rede deveria escalar para acomodar a crescente demanda. Enquanto uma facção defendia soluções de escalabilidade off-chain, como a Lightning Network construída sobre o SegWit, outra facção argumentava que aumentar o limite do tamanho de bloco era a abordagem mais direta e comprovada para escalar. Quando o consenso não pôde ser alcançado, o segundo grupo executou um hard fork, criando uma nova cadeia que preservou o histórico de transações do Bitcoin enquanto implementava um limite de tamanho de bloco maior e rejeitava o SegWit. Este documento descreve as especificações técnicas, a filosofia de design e a trajetória de desenvolvimento do 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
O whitepaper original do Bitcoin, publicado por Satoshi Nakamoto em 2008, descrevia "uma versão puramente peer-to-peer de dinheiro eletrônico" que permitiria "pagamentos online serem enviados diretamente de uma parte para outra sem passar por uma instituição financeira". Essa visão do Bitcoin como um meio de troca para transações cotidianas foi central para sua adoção inicial e crescimento da comunidade. Os primeiros defensores do Bitcoin citavam frequentemente as baixas taxas de transação e pagamentos rápidos como vantagens-chave sobre os sistemas financeiros tradicionais.
No entanto, à medida que a popularidade do Bitcoin cresceu em meados da década de 2010, uma restrição fundamental começou a limitar sua utilidade como dinheiro eletrônico. O limite de tamanho de bloco de um megabyte, originalmente introduzido como uma medida temporária anti-spam, criou um teto artificial no número de transações que a rede podia processar. À medida que a demanda por espaço nos blocos aumentava, os usuários eram forçados a competir pela capacidade limitada oferecendo taxas de transação mais altas. No início de 2017, a taxa mediana de transação do Bitcoin havia subido para vários dólares, tornando transações de pequeno valor economicamente impraticáveis. Durante períodos de pico de congestionamento, as taxas podiam exceder vinte dólares, e transações podiam permanecer não confirmadas por horas ou até dias.
Essa situação representava um desvio fundamental da promessa original do Bitcoin. Um sistema projetado para permitir pagamentos eletrônicos peer-to-peer estava se tornando muito caro e muito lento para os próprios casos de uso que foi criado para servir. Enquanto o Bitcoin era cada vez mais posicionado como "ouro digital" — uma reserva de valor em vez de um meio de troca — muitos membros da comunidade e desenvolvedores acreditavam que isso representava uma traição aos princípios fundadores do projeto.
O Bitcoin Cash foi criado para resolver essa crise adotando a abordagem mais direta para escalar: aumentar o limite do tamanho de bloco. Ao permitir que mais transações coubessem em cada bloco, o Bitcoin Cash buscou restaurar taxas baixas e confirmações rápidas, tornando o dinheiro eletrônico peer-to-peer prático novamente. Os defensores do projeto argumentavam que o escalamento on-chain não era apenas tecnicamente viável, mas era a abordagem que Satoshi Nakamoto havia originalmente previsto, apontando para comunicações iniciais nas quais Nakamoto discutiu aumentar o limite do tamanho de bloco à medida que a rede crescesse.
A criação do Bitcoin Cash em 1 de agosto de 2017 foi um dos eventos mais significativos na história das criptomoedas. Representou a primeira grande divisão de cadeia na história do Bitcoin impulsionada por uma genuína divergência filosófica sobre a direção futura do protocolo. O fork demonstrou que em um sistema descentralizado, disputas irresolvíveis podem ser resolvidas permitindo que cada facção persiga sua própria visão independentemente, com o mercado determinando finalmente o 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
O debate sobre escalabilidade do Bitcoin foi uma das disputas mais contenciosas e prolongadas na história do desenvolvimento de software de código aberto. Em sua essência, o debate centrava-se em uma pergunta aparentemente simples: como a rede Bitcoin deveria aumentar sua capacidade de processamento de transações? A resposta a essa pergunta, no entanto, tocava em questões fundamentais de governança, descentralização, filosofia técnica e a própria identidade do Bitcoin.
O limite de tamanho de bloco de um megabyte do Bitcoin foi introduzido por Satoshi Nakamoto em 2010 como uma medida temporária para prevenir ataques de negação de serviço nos quais um adversário pudesse inundar a rede com blocos superdimensionados. Na época, o uso real dos blocos estava muito abaixo desse limite, e Nakamoto sugeriu que o limite poderia ser elevado no futuro através de uma simples mudança de código. No entanto, à medida que o uso do Bitcoin cresceu e os blocos começaram a encher, elevar o limite provou ser muito mais contencioso do que qualquer um havia antecipado.
Uma facção, que veio a ser associada com a equipe de desenvolvimento do Bitcoin Core, argumentava que o tamanho do bloco deveria permanecer pequeno para preservar a descentralização. Seu raciocínio era que blocos maiores aumentariam os requisitos computacionais e de largura de banda para executar um nó completo">nó completo, potencialmente excluindo usuários comuns e concentrando a operação de nós entre entidades bem financiadas. Eles propuseram um caminho alternativo de escalabilidade: SegWit, uma mudança de protocolo que reestruturava os dados de transação para efetivamente aumentar a capacidade de transações do bloco sem elevar o limite de tamanho nominal, combinado com soluções off-chain como a Lightning Network que moveriam a maioria das transações para fora da blockchain principal.
A facção oposta, que incluía desenvolvedores proeminentes, mineradores e empresas, argumentava que elevar o limite do tamanho de bloco era a solução mais simples, mais comprovada e mais urgente. Eles sustentavam que o limite de um megabyte era uma restrição arbitrária que nunca havia sido planejada como uma característica permanente do protocolo, e que os aumentos de taxas e congestionamento resultantes estavam afastando usuários e comerciantes do Bitcoin. Eles eram céticos quanto à complexidade do SegWit e preocupados que a Lightning Network, que era ainda amplamente teórica na época, pudesse nunca cumprir suas promessas de transações baratas e instantâneas.
O debate escalou através de uma série de propostas e contrapropostas. O Bitcoin XT, proposto por Mike Hearn e Gavin Andresen em 2015, buscava aumentar o tamanho de bloco para 8MB. O Bitcoin Classic propôs um aumento mais modesto para 2MB. O Bitcoin Unlimited propôs remover o limite de tamanho de bloco inteiramente, permitindo que mineradores definissem seus próprios limites através da dinâmica de mercado. Cada proposta gerou debate feroz e nenhuma alcançou o consenso esmagador necessário para um hard fork não contencioso.
Várias tentativas de compromisso foram feitas. O Acordo de Hong Kong (fevereiro de 2016) viu desenvolvedores do Bitcoin Core e mineradores concordarem em implantar o SegWit seguido de um hard fork para 2MB, mas o acordo desmoronou quando o componente de hard fork não foi perseguido. O Acordo de Nova York (maio de 2017), também conhecido como SegWit2x, propôs ativar o SegWit imediatamente seguido de um hard fork para 2MB dentro de seis meses. Esse acordo foi assinado por mais de cinquenta empresas representando a maioria do poder de hash do Bitcoin, mas foi fortemente combatido pela equipe de desenvolvimento do Bitcoin Core e uma porção significativa da comunidade de usuários.
Quando ficou claro que o compromisso era impossível, a facção de blocos grandes decidiu agir unilateralmente. Em 1 de agosto de 2017, executaram um hard fork da blockchain do Bitcoin, criando o Bitcoin Cash com um limite de tamanho de bloco inicial de 8MB. Esta não foi uma decisão tomada de ânimo leve — exigiu dividir a blockchain, a rede, a comunidade e a marca. Mas os defensores do Bitcoin Cash acreditavam que era a única forma de preservar a visão original do Bitcoin como dinheiro eletrô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
O hard fork do Bitcoin Cash foi executado em 1 de agosto de 2017, na altura de bloco 478.558. Nesse ponto, a blockchain do Bitcoin se dividiu em duas cadeias separadas: a cadeia original, que continuou como Bitcoin (BTC) com a ativação do SegWit, e a nova cadeia, que se tornou Bitcoin Cash (BCH) com um limite de tamanho de bloco aumentado para 8MB.
O fork foi tecnicamente limpo e bem planejado. Cada endereço Bitcoin que possuía saldo no momento do fork recebeu um saldo idêntico em ambas as cadeias. Se um usuário possuía 1 BTC antes do fork, teria 1 BTC na cadeia Bitcoin e 1 BCH na cadeia Bitcoin Cash após o fork. Todo o histórico de transações anterior ao bloco 478.558 era compartilhado entre ambas as cadeias.
Um dos desafios técnicos críticos do fork foi a implementação de proteção contra replay. Na ausência de proteção contra replay, uma transação transmitida em uma cadeia poderia ser reproduzida na outra cadeia, potencialmente fazendo com que os usuários gastassem moedas involuntariamente em ambas as cadeias. O Bitcoin Cash implementou forte proteção contra replay modificando o algoritmo de assinatura de transações. Especificamente, o Bitcoin Cash introduziu uma nova flag SigHash (SIGHASH_FORKID) que é incluída no hash de cada assinatura de transação. Transações assinadas com esta flag são válidas na cadeia Bitcoin Cash mas inválidas na cadeia Bitcoin, e vice-versa. Isso garantiu uma separação limpa entre as duas redes desde o momento do fork.
O limite de tamanho de bloco inicial para o Bitcoin Cash foi definido em 8MB, oito vezes maior que o limite de 1MB do Bitcoin. Isso representou um aumento significativo na capacidade de transações on-chain, permitindo ao Bitcoin Cash processar substancialmente mais transações por bloco mantendo taxas baixas. O primeiro bloco do Bitcoin Cash após o fork foi minerado pelo pool de mineração ViaBTC e tinha aproximadamente 1,9MB de tamanho, demonstrando o benefício prático imediato do tamanho de bloco maior.
O fork também removeu o SegWit, que havia sido ativado na cadeia Bitcoin. Os desenvolvedores do Bitcoin Cash rejeitaram o SegWit por várias razões: acreditavam que introduzia complexidade desnecessária ao protocolo, criava um sistema de transações de dois níveis com diferentes estruturas de taxas e modificava a estrutura do bloco de maneiras que argumentavam minar a simplicidade do modelo UTXO. Ao escolher um aumento direto do tamanho de bloco, o Bitcoin Cash manteve uma arquitetura de protocolo mais simples e mais tradicional no estilo Bitcoin.
Após o fork, ambas as cadeias tiveram que lidar com o desafio do ajuste de dificuldade. O Bitcoin Cash inicialmente usou a mesma dificuldade SHA-256 da cadeia Bitcoin, mas com significativamente menos poder de hash dedicado à mineração. Para prevenir um cenário em que blocos fossem minerados extremamente devagar, o Bitcoin Cash implementou um mecanismo de Ajuste de Dificuldade de Emergência (EDA) que diminuiria a dificuldade em 20 por cento se menos de 6 blocos fossem minerados em um período de 12 horas. Embora esse mecanismo tenha mantido a cadeia viva com sucesso durante o período inicial crítico, provou ser instável, causando oscilações violentas nos tempos de produção de blocos e taxa de hash à medida que mineradores alternavam entre Bitcoin e Bitcoin Cash com base na rentabilidade. O EDA foi substituído em novembro de 2017 por um algoritmo de ajuste de dificuldade mais estável baseado em uma média móvel dos 144 blocos anteriores.
O fork foi recebido com considerável controvérsia na comunidade de criptomoedas mais ampla. Críticos argumentavam que o Bitcoin Cash era uma tentativa ilegítima de se apropriar da marca Bitcoin, enquanto apoiadores sustentavam que era uma continuação legítima do roteiro original do Bitcoin. Exchanges e provedores de serviços tiveram que tomar decisões rápidas sobre se apoiariam a nova cadeia e como lidariam com a distribuição de moedas bifurcadas para seus clientes. Apesar da controvérsia, o Bitcoin Cash rapidamente se estabeleceu como uma criptomoeda viável e ativamente utilizada, alcançando volume de negociação significativo e adoção por comerciantes nos meses seguintes ao fork.
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
O Bitcoin Cash compartilha a arquitetura técnica fundamental do Bitcoin, incluindo o mecanismo de consenso de prova de trabalho SHA-256, o modelo de transações UTXO, a curva elíptica secp256k1 para assinaturas digitais e o intervalo de bloco alvo de dez minutos. No entanto, várias modificações importantes o diferenciam do protocolo Bitcoin.
A diferença mais proeminente é o limite de tamanho de bloco. O Bitcoin Cash foi lançado com um limite de tamanho de bloco de 8MB e subsequentemente o aumentou para 32MB em maio de 2018. Esse limite de 32MB fornece aproximadamente 32 vezes a capacidade de transações do tamanho de bloco efetivo de 1MB sem SegWit do Bitcoin (ou aproximadamente 8 vezes a capacidade do limite efetivo do Bitcoin aprimorado com SegWit de aproximadamente 4MB). O tamanho de bloco maior é a pedra angular da filosofia de escalabilidade on-chain do Bitcoin Cash, fornecendo amplo espaço para o crescimento de transações sem a pressão de taxas que surge quando os blocos estão consistentemente cheios.
O Bitcoin Cash não implementa SegWit. Em vez de separar dados de testemunho dos dados de transação como o SegWit faz, o Bitcoin Cash mantém o formato de transação original do Bitcoin intacto. Todos os dados de transação, incluindo assinaturas, são armazenados dentro do bloco da maneira tradicional. Isso simplifica o protocolo e mantém a compatibilidade retroativa com software e infraestrutura mais antigos do Bitcoin.
Uma melhoria significativa do protocolo no Bitcoin Cash é o algoritmo SigHash aprimorado, que foi introduzido no momento do fork. O novo algoritmo, baseado no BIP 143 (que foi originalmente desenvolvido para o SegWit), corrige o problema de hashing quadrático que existia no esquema original de verificação de assinaturas do Bitcoin. No esquema original, o custo computacional de verificar a assinatura de uma transação crescia quadraticamente com o número de entradas, criando um vetor potencial de ataque de negação de serviço. O novo algoritmo SigHash torna o custo de verificação linear, permitindo que a rede processe com segurança transações maiores e mais complexas.
O Bitcoin Cash suporta um tamanho máximo de transação maior e um maior número de operações de assinatura (sigops) por bloco comparado ao Bitcoin. O limite de sigops é escalado proporcionalmente com o tamanho do bloco, garantindo que o custo computacional da validação do bloco permaneça limitado enquanto ainda permite significativamente mais transações por bloco.
O sistema de scripting no Bitcoin Cash foi ativamente desenvolvido além da abordagem comparativamente conservadora do Bitcoin. O Bitcoin Cash reativou e introduziu vários opcodes que expandem a expressividade de sua linguagem de scripting. Adições notáveis incluem OP_CHECKDATASIG e OP_CHECKDATASIGVERIFY, que permitem que scripts de transação verifiquem assinaturas contra dados arbitrários (não apenas dados de transação), habilitando contratos inteligentes baseados em oráculos e outros padrões avançados de scripting. O opcode OP_REVERSEBYTES, opcodes de introspecção nativos e limites maiores de script e pilha aprimoraram ainda mais a programabilidade do Bitcoin Cash.
O Bitcoin Cash usa a mesma base de formato de endereço que o Bitcoin, mas adotou o formato CashAddr em janeiro de 2018 para prevenir confusão e erros de envio entre cadeias. Endereços CashAddr começam com "bitcoincash:" como prefixo (frequentemente abreviado para "q" ou "p" para a porção do hash) e usam um esquema de codificação diferente do formato base58check do Bitcoin. Essa distinção visual torna imediatamente claro se um endereço pertence ao Bitcoin ou ao Bitcoin Cash, reduzindo o risco de usuários enviarem acidentalmente moedas para a cadeia errada.
A rede opera na porta 8333, a mesma porta padrão do Bitcoin, embora os nós do Bitcoin Cash se identifiquem com um número mágico de rede diferente no handshake do protocolo. Isso significa que os nós do Bitcoin e do Bitcoin Cash não se conectarão acidentalmente entre si apesar de usarem a mesma porta.
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
O throughput de transações e a escalabilidade são centrais para a proposta de valor do Bitcoin Cash. A tese fundamental do projeto é que o dinheiro eletrônico peer-to-peer deve ser capaz de processar transações de forma rápida e barata para ser viável para uso cotidiano, e que o escalamento on-chain através de blocos maiores é a maneira mais confiável de alcançar isso.
Com um limite de tamanho de bloco de 32MB e um intervalo de blocos de dez minutos, o Bitcoin Cash tem um throughput máximo teórico de aproximadamente 100 transações por segundo, dependendo do tamanho médio da transação. Isso representa um aumento substancial sobre o máximo teórico do Bitcoin de aproximadamente 7 transações por segundo com blocos de 1MB. Na prática, o throughput real depende da combinação de tipos e tamanhos de transações, mas a capacidade do Bitcoin Cash é mais que suficiente para seu volume atual de transações, com blocos tipicamente bem abaixo do limite de 32MB.
A abundância de espaço disponível nos blocos tem um impacto direto e mensurável nas taxas de transação. Quando os blocos não estão cheios, não há competição por taxas, e transações podem ser confirmadas com taxas mínimas. A taxa mínima de retransmissão padrão do Bitcoin Cash é de 1 satoshi por byte (onde 1 satoshi = 0,00000001 BCH), e a maioria das transações é confirmada no próximo bloco nesse mínimo ou próximo dele. Isso faz com que as transações do Bitcoin Cash custem frações de um centavo em condições normais, comparado com as taxas do Bitcoin que podem variar de dólares a dezenas de dólares durante períodos de congestionamento.
A comunidade de desenvolvimento do Bitcoin Cash conduziu extensa pesquisa e testes sobre os limites do escalamento on-chain. A Iniciativa Gigablock Testnet, conduzida em 2017-2018, demonstrou que o protocolo Bitcoin podia lidar com blocos de 1GB ou mais com otimizações de software apropriadas e hardware moderno. Esses testes identificaram vários gargalos na base de código original — incluindo propagação de blocos, validação de transações e gerenciamento do conjunto UTXO — e informaram esforços de otimização subsequentes.
Várias melhorias de protocolo e implementação foram feitas para suportar blocos maiores. O Graphene, um protocolo de propagação de blocos baseado em tabelas de busca de Bloom invertíveis e filtros de Bloom, reduz dramaticamente a largura de banda necessária para propagar blocos codificando apenas a diferença entre um bloco e as transações que um nó receptor já tem em seu mempool. O Ordenamento Canônico de Transações (CTOR), implementado em novembro de 2018, requer que transações dentro de um bloco sejam ordenadas por seu ID de transação. Essa mudança aparentemente menor permite otimizações significativas na validação e propagação de blocos, pois permite a validação paralela de transações e algoritmos de reconciliação de conjuntos mais eficientes.
As iniciativas de compromisso UTXO e validação paralela melhoraram ainda mais a capacidade da rede de lidar com blocos grandes de forma eficiente. Aproveitando processadores modernos multi-core e armazenamento de estado sólido, implementações de nós otimizadas podem validar blocos contendo dezenas de milhares de transações dentro de prazos aceitáveis.
O roteiro de escalabilidade do Bitcoin Cash prevê aumentos adicionais no limite de tamanho de bloco conforme tecnologia e demanda justifiquem. Os desenvolvedores do projeto expressaram um objetivo de longo prazo de suportar volumes de pagamento em escala global inteiramente on-chain, visando níveis de throughput que permitiriam ao Bitcoin Cash servir bilhões de transações diárias. Embora esse objetivo seja ambicioso, as melhorias contínuas nas capacidades de hardware, largura de banda de rede e otimização de software fornecem um caminho credível para alcançá-lo incrementalmente ao longo do tempo.
Um aspecto importante da abordagem de escalamento do Bitcoin Cash é o conceito de transações de "zero confirmação". Para pagamentos de baixo valor, comerciantes podem aceitar transações imediatamente após a transmissão, antes de serem incluídas em um bloco. O Bitcoin Cash implementou várias medidas para melhorar a confiabilidade das transações de zero confirmação, incluindo a regra do "primeiro visto" (onde nós retransmitem apenas a primeira versão de uma transação que veem, tornando tentativas de gasto duplo mais difíceis) e protocolos de notificação de gasto duplo que alertam comerciantes se uma transação conflitante for detectada. Essas medidas tornam o Bitcoin Cash prático para transações em ponto de venda onde esperar dez minutos por uma confirmação de bloco seria impraticável.
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
O Bitcoin Cash suporta o opcode OP_RETURN, que permite aos usuários incorporar dados arbitrários na blockchain dentro de uma saída de transação que é comprovadamente impossível de gastar. Esse recurso possibilita uma variedade de aplicações centradas em dados construídas sobre a blockchain do Bitcoin Cash, incluindo protocolos de tokens, sistemas de mensagens, serviços de notarização e plataformas de mídia social.
O limite de dados OP_RETURN no Bitcoin Cash foi definido em 220 bytes por saída, significativamente maior que o limite de 80 bytes do Bitcoin. Além disso, o Bitcoin Cash permite múltiplas saídas OP_RETURN em uma única transação, expandindo ainda mais a quantidade de dados que pode ser incorporada em uma única transação. Esses limites generosos, combinados com baixas taxas de transação, tornam o Bitcoin Cash uma plataforma economicamente viável para aplicações de dados que seriam proibitivamente caras em cadeias com maior restrição de capacidade.
O Simple Ledger Protocol (SLP) foi um dos sistemas de tokens mais antigos e amplamente adotados construídos no Bitcoin Cash usando OP_RETURN. O SLP permitia aos usuários criar e transferir tokens personalizados na blockchain do Bitcoin Cash codificando metadados de tokens em saídas OP_RETURN. Embora o SLP tenha sido amplamente substituído pelo protocolo CashTokens, ele demonstrou a viabilidade de construir economias de tokens sobre o modelo UTXO.
O CashTokens, ativado em maio de 2023, representa uma abordagem mais sofisticada para tokenização no Bitcoin Cash. Diferentemente do SLP, que dependia de metadados OP_RETURN que podiam ser ignorados pelo protocolo base, o CashTokens é um recurso de nível de consenso que integra tokens diretamente no modelo UTXO. Cada UTXO pode carregar tanto um valor em BCH quanto um token associado, com a validade do token aplicada pelas regras de consenso. O CashTokens suporta dois tipos de tokens: tokens fungíveis (similares aos tokens ERC-20 no Ethereum) e tokens não fungíveis (NFTs). A aplicação no nível de consenso significa que transações de tokens têm as mesmas garantias de segurança que transações nativas de BCH, eliminando as suposições de confiança e requisitos de indexação de protocolos de sobreposição como o SLP.
O Memo.cash é um protocolo de mídia social descentralizado construído no Bitcoin Cash usando transações OP_RETURN. Usuários transmitem postagens, seguimentos, curtidas e outras ações sociais como transações Bitcoin Cash com dados OP_RETURN codificados. Como os dados são armazenados na blockchain, eles são resistentes à censura e permanentemente arquivados. Os baixos custos de transação no Bitcoin Cash tornam isso economicamente viável — cada ação de mídia social custa uma fração de centavo.
Outras aplicações de dados no Bitcoin Cash incluem serviços de carimbo de data e notarização de documentos, onde o hash de um documento é incorporado em uma saída OP_RETURN para criar um registro permanente e à prova de adulteração da existência do documento em um ponto específico no tempo. Rastreamento de cadeia de suprimentos, verificação de credenciais e sistemas de identidade descentralizada também foram construídos usando as capacidades de incorporação de dados do Bitcoin Cash.
A combinação de grande capacidade OP_RETURN, baixas taxas e tempos de confirmação rápidos posiciona o Bitcoin Cash como uma plataforma competitiva para aplicações de dados baseadas em blockchain. Embora existam blockchains de dados especializadas, o Bitcoin Cash oferece a vantagem de uma rede bem estabelecida, altamente segura e amplamente suportada com um histórico comprovado de operação contínua.
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
A rede Bitcoin Cash opera na mesma arquitetura peer-to-peer fundamental do Bitcoin, com nós se comunicando via um protocolo de gossip para propagar transações e blocos. Nós completos mantêm uma cópia completa da blockchain e validam independentemente todas as transações e blocos de acordo com as regras de consenso. A rede é sem permissão, significando que qualquer pessoa pode operar um nó e participar da rede sem autorização.
Existem múltiplas implementações independentes de nós completos para o Bitcoin Cash, refletindo o compromisso do projeto com o desenvolvimento descentralizado. O Bitcoin Cash Node (BCHN) é a implementação mais amplamente utilizada e serve como o cliente de referência de facto. Outras implementações incluem Bitcoin Unlimited, BCHD (escrito em Go) e Knuth (uma implementação de alto desempenho em C++). A existência de múltiplas implementações independentes reduz o risco de um único bug de software causar uma falha em toda a rede e garante que nenhuma equipe de desenvolvimento individual tenha controle unilateral sobre o protocolo.
A mineração no Bitcoin Cash usa o algoritmo de prova de trabalho SHA-256, idêntico ao do Bitcoin. Isso significa que o mesmo hardware de mineração ASIC pode ser usado para minerar qualquer uma das cadeias, e mineradores podem alternar entre Bitcoin e Bitcoin Cash com base na rentabilidade. Na prática, a taxa de hash do Bitcoin Cash é uma fração da do Bitcoin, já que a maioria do poder de mineração SHA-256 é direcionada à cadeia Bitcoin mais lucrativa. No entanto, o algoritmo de ajuste de dificuldade do Bitcoin Cash garante que blocos sejam produzidos no intervalo alvo de dez minutos independentemente do nível absoluto de taxa de hash.
O algoritmo de ajuste de dificuldade é um dos componentes de protocolo mais importantes do Bitcoin Cash. O ajuste de dificuldade original do Bitcoin, que recalcula a cada 2.016 blocos (aproximadamente duas semanas), era muito lento para acomodar as rápidas flutuações de taxa de hash que o Bitcoin Cash experimentava quando mineradores alternavam entre ele e o Bitcoin. Após o problemático período de Ajuste de Dificuldade de Emergência (EDA) em 2017, o Bitcoin Cash adotou um novo algoritmo em novembro de 2017 que ajustava a dificuldade com base em uma janela móvel de 144 blocos.
Em novembro de 2020, o Bitcoin Cash foi atualizado para o algoritmo de ajuste de dificuldade ASERT (Absolutely Scheduled Exponentially Rising Targets), também conhecido como aserti3-2d. O ASERT é um algoritmo matematicamente elegante que ajusta o alvo de dificuldade com base na diferença entre o tempo real decorrido e o tempo esperado desde um bloco de referência (o "bloco âncora"). Se blocos estão sendo produzidos mais rápido que o esperado, a dificuldade aumenta exponencialmente; se mais devagar, diminui exponencialmente. A designação "3-2d" refere-se a uma meia-vida de aproximadamente dois dias (especificamente 288 blocos no alvo de dez minutos), significando que uma duplicação ou redução pela metade sustentada da taxa de hash resultaria em um ajuste completo de dificuldade dentro de dois dias. O ASERT provou ser altamente estável, produzindo intervalos de bloco consistentes mesmo sob significativa volatilidade de taxa de hash.
A eficiência na propagação de blocos é crítica para uma rede com blocos grandes. O Bitcoin Cash adotou várias otimizações para garantir que blocos grandes possam se propagar rapidamente pela rede. Blocos Compactos (BIP 152), que permitem que nós reconstruam blocos a partir de IDs de transação em vez de dados completos de transações, reduzem dramaticamente a largura de banda necessária para propagação de blocos quando nós têm mempools sobrepostos. O protocolo Graphene fornece compressão ainda maior usando estruturas de dados probabilísticas para alcançar codificação de blocos quase ótima. O Xthinner é outro protocolo de compressão desenvolvido especificamente para o Bitcoin Cash que alcança aproximadamente 99,6 por cento de compressão para blocos típicos.
As políticas de retransmissão e mempool da rede são projetadas para suportar transações de zero confirmação confiáveis. Nós seguem uma regra estrita de primeiro visto, aceitando e retransmitindo apenas a primeira versão de uma transação que observam. Se uma segunda transação tentando gastar as mesmas entradas (uma tentativa de gasto duplo) for detectada, nós gerarão uma prova de gasto duplo e a propagarão pela rede, alertando comerciantes e outras partes interessadas. Essa infraestrutura fornece um nível de segurança razoável para aceitar transações não confirmadas para pagamentos cotidianos de baixo 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
Embora o Bitcoin Cash seja projetado principalmente como um sistema de dinheiro eletrônico peer-to-peer, ele desenvolveu capacidades significativas de contratos inteligentes através de extensões à sua linguagem de scripting. Diferentemente do modelo de contratos inteligentes baseado em contas e Turing-completo do Ethereum, os contratos inteligentes do Bitcoin Cash operam dentro do modelo UTXO usando uma linguagem de scripting baseada em pilha que deliberadamente não é Turing-completa. Esse design fornece custos de execução previsíveis e evita a classe de vulnerabilidades associadas à computação ilimitada, enquanto ainda permite um conjunto surpreendentemente rico de instrumentos financeiros programáveis.
A linguagem de scripting do Bitcoin Cash foi progressivamente aprimorada através de uma série de atualizações de protocolo. Em maio de 2018, vários opcodes que haviam sido desativados no início da história do Bitcoin foram reativados, incluindo operadores de lógica bit a bit (OP_AND, OP_OR, OP_XOR), operadores aritméticos para números maiores e operações de manipulação de strings (OP_SPLIT, OP_CAT). Esses opcodes restaurados expandiram significativamente a expressividade dos scripts do Bitcoin Cash.
A introdução de OP_CHECKDATASIG e OP_CHECKDATASIGVERIFY em novembro de 2018 foi um avanço particularmente importante. Esses opcodes permitem que um script de transação verifique uma assinatura ECDSA contra dados arbitrários, não apenas a transação em si. Isso habilita contratos baseados em oráculos onde uma fonte de dados externa assina uma mensagem atestando alguma condição do mundo real (como um preço, evento climático ou resultado esportivo), e a execução do contrato depende do conteúdo dessa mensagem assinada. Essa capacidade abre a porta para mercados de previsão descentralizados, contratos de seguro e outros instrumentos financeiros que dependem de dados externos.
Os opcodes de introspecção nativos, introduzidos em maio de 2022, permitem que scripts de transação examinem as propriedades da transação que os contém. Scripts podem inspecionar o valor, script de bloqueio e dados de token tanto de entradas quanto de saídas dentro da mesma transação. Isso habilita contratos no estilo covenant — scripts que restringem como moedas podem ser gastas em transações futuras, não apenas quem pode gastá-las. Covenants habilitam padrões poderosos como cofres (restrições de gasto com bloqueio temporal para segurança), pagamentos recorrentes, exchanges descentralizados e mecanismos de votação on-chain.
O CashScript é uma linguagem de contratos inteligentes de alto nível para o Bitcoin Cash, análoga ao Solidity para o Ethereum. O CashScript permite que desenvolvedores escrevam contratos em uma sintaxe familiar, semelhante ao JavaScript, que é compilada para bytecode de script do Bitcoin Cash. A linguagem lida com a complexidade do design de contratos baseados em UTXO, incluindo introspecção de entrada/saída e verificação de assinatura, tornando-o acessível a desenvolvedores que podem não estar familiarizados com programação de baixo nível baseada em pilha. Contratos CashScript foram usados para construir exchanges descentralizados, serviços de custódia, plataformas de financiamento coletivo e outras aplicações.
A atualização CashTokens em maio de 2023 adicionou outra dimensão às capacidades de contratos inteligentes do Bitcoin Cash. Ao incorporar tokens fungíveis e não fungíveis diretamente no modelo UTXO no nível de consenso, o CashTokens habilita contratos baseados em tokens que são aplicados pelas regras de consenso da rede em vez de protocolos de sobreposição. Os tokens não fungíveis (NFTs) no CashTokens carregam um campo de "compromisso" — dados arbitrários anexados ao token — que podem ser lidos e validados por scripts de contratos inteligentes. Isso cria um mecanismo para manter estado on-chain através de múltiplas transações, uma capacidade que anteriormente era difícil de alcançar no modelo UTXO. Contratos podem usar NFTs como portadores de estado, atualizando os dados de compromisso a cada transação para implementar protocolos complexos de múltiplos passos.
A combinação de opcodes de introspecção, CashTokens e CashScript cria uma plataforma de contratos inteligentes que, embora fundamentalmente diferente do modelo do Ethereum, é capaz de implementar muitas das mesmas aplicações financeiras descentralizadas. Exchanges descentralizados, criadores de mercado automatizados, protocolos de empréstimo e organizações autônomas descentralizadas foram todos construídos ou prototipados no Bitcoin Cash. A abordagem baseada em UTXO oferece vantagens em termos de paralelização (UTXOs podem ser validados independentemente), privacidade (cada UTXO é independente) e previsibilidade (sem estado global para disputar), embora requeira padrões de design diferentes dos sistemas baseados em contas.
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
O Bitcoin Cash herda a política monetária do Bitcoin em sua totalidade. A oferta total de Bitcoin Cash é limitada a 21 milhões de moedas, e o cronograma de emissão segue o mesmo mecanismo de halving do Bitcoin. Essa política monetária compartilhada é uma consequência direta do fork: como o Bitcoin Cash se separou da blockchain do Bitcoin, começou com o mesmo histórico de emissão e continua com as mesmas regras de emissão futuras.
A recompensa por bloco começou em 50 BCH por bloco (herdada dos parâmetros de gênese do Bitcoin) e é reduzida pela metade a cada 210.000 blocos, aproximadamente a cada quatro anos. O primeiro halving ocorreu em novembro de 2012 (antes do fork, portanto é história compartilhada), reduzindo a recompensa para 25 moedas. O segundo halving em julho de 2016 a reduziu para 12,5 moedas. O terceiro halving em abril de 2020, que ocorreu após o fork e portanto foi específico da cadeia Bitcoin Cash, reduziu a recompensa para 6,25 BCH. O quarto halving em abril de 2024 a reduziu ainda mais para 3,125 BCH por bloco.
Esse cronograma de halving cria uma política monetária desinflacionária na qual a taxa de criação de novas moedas diminui ao longo do tempo, aproximando-se de zero assintoticamente. A última moeda de Bitcoin Cash deve ser minerada por volta do ano 2140. Nesse ponto, a receita dos mineradores consistirá inteiramente em taxas de transação.
O limite de oferta de 21 milhões e o cronograma de halving dão ao Bitcoin Cash as mesmas propriedades de escassez do Bitcoin. A oferta circulante no início de 2026 é de aproximadamente 19,8 milhões de BCH, representando mais de 94 por cento da oferta total que existirá. As moedas restantes serão distribuídas ao longo de mais de um século de recompensas de bloco decrescentes.
A abordagem do Bitcoin Cash para a transição de recompensas de bloco para compensação de mineradores baseada em taxas difere da estratégia do Bitcoin. A filosofia de escalabilidade do Bitcoin, que restringe o espaço de bloco para manter um mercado de taxas, depende implicitamente de altas taxas por transação para compensar mineradores à medida que as recompensas de bloco diminuem. O Bitcoin Cash adota a abordagem oposta: ao manter taxas baixas e blocos grandes, a rede visa gerar receita total de taxas suficiente através de alto volume de transações em vez de altas taxas por transação. Neste modelo, se cada transação paga uma taxa de um centavo mas a rede processa milhões de transações por bloco, a receita agregada de taxas pode ser suficientemente substancial para incentivar a mineração.
Esse modelo de taxas baseado em volume requer que o Bitcoin Cash alcance um throughput de transações significativamente maior que o do Bitcoin para fornecer incentivos equivalentes aos mineradores na era pós-subsídio. Defensores argumentam que isso é alcançável através do escalamento contínuo on-chain, já que a demanda global de pagamentos é enorme e mesmo uma participação modesta nas transações mundiais representaria milhões de pagamentos por dia. Críticos contra-argumentam que alcançar esse nível de adoção é incerto e que o modelo de baixas taxas pode criar incentivos insuficientes durante o período de transição.
A política monetária compartilhada entre Bitcoin e Bitcoin Cash significa que as duas cadeias estão em competição direta pelo poder de hash de mineração SHA-256. Mineradores alocam seus recursos para a cadeia que for mais lucrativa em qualquer momento dado, e os algoritmos de ajuste de dificuldade em ambas as cadeias acomodam essa alocação fluida. Na prática, a participação do Bitcoin Cash na taxa de hash total SHA-256 tem sido proporcional ao seu preço relativo, refletindo o comportamento econômico racional de mineradores que maximizam lucros.
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
O Bitcoin Cash representa uma continuação baseada em princípios da visão original do Bitcoin como dinheiro eletrônico peer-to-peer. Ao aumentar o limite do tamanho de bloco e buscar o escalamento on-chain, o Bitcoin Cash manteve as baixas taxas e transações rápidas que caracterizavam o Bitcoin inicial, tornando práticos os pagamentos cotidianos e microtransações que o whitepaper original imaginava.
A trajetória técnica do projeto tem sido marcada por melhorias de protocolo ponderadas e consequentes. O algoritmo de ajuste de dificuldade ASERT fornece produção de blocos estável sob condições voláteis de taxa de hash. A linguagem de scripting aprimorada, com opcodes restaurados e novos, permite contratos inteligentes sofisticados dentro das restrições de segurança do modelo UTXO. O CashTokens traz tokenização aplicada no nível de consenso ao protocolo Bitcoin pela primeira vez. O CashScript torna essas capacidades acessíveis a uma ampla comunidade de desenvolvedores. Juntos, esses avanços demonstram que o modelo UTXO pode suportar um rico ecossistema de aplicações descentralizadas mantendo suas propriedades fundamentais de simplicidade e segurança.
O debate sobre escalabilidade que levou à criação do Bitcoin Cash destacou uma tensão fundamental em sistemas descentralizados: o equilíbrio entre capacidade on-chain e o custo de operar nós completos. O Bitcoin Cash escolheu priorizar a capacidade de transações e a experiência do usuário, argumentando que os benefícios econômicos da adoção e uso generalizados superam os requisitos aumentados de hardware para operadores de nós. Esta é uma questão empírica cuja resposta se desdobrará ao longo dos próximos anos e décadas à medida que tanto Bitcoin quanto Bitcoin Cash continuam a evoluir em seus respectivos caminhos.
A sobrevivência e o desenvolvimento contínuo do Bitcoin Cash através de múltiplos mercados baixistas, forks contenciosos (notavelmente a divisão do Bitcoin SV em novembro de 2018) e esforço sustentado da comunidade demonstram a resiliência do projeto e a convicção de seus participantes. A rede processou centenas de milhões de transações desde o fork, manteve operação contínua e atraiu uma comunidade global de desenvolvedores, comerciantes e usuários que compartilham a crença de que dinheiro eletrônico peer-to-peer é uma tecnologia que vale a pena construir.
O sucesso a longo prazo do Bitcoin Cash depende de sua capacidade de atrair usuários e comerciantes que valorizem transações de baixas taxas e confiáveis, e de escalar sua infraestrutura para atender às demandas de uma rede de pagamentos global. As bases técnicas são sólidas, o roteiro é claro e a comunidade é comprometida. Se o Bitcoin Cash alcançará finalmente seu ambicioso objetivo de servir como dinheiro eletrônico para o mundo será determinado não por limitações técnicas, mas pelos efeitos de rede, dinâmicas de mercado e padrões de adoção que governam a evolução de todos os sistemas monetários.
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