BCH2: Bitcoin Cash II

Resumo

A BCH2 (Bitcoin Cash II) é uma criptomoeda SHA-256 que junta o comprovado protocolo Bitcoin Cash a um modelo de distribuição justa, através de um fork 1:1 da BC2 (BitcoinII). Ao separar-se da BC2 na altura de bloco 53.200, a BCH2 herda todo o histórico de transações da BC2 e passa às regras de consenso da Bitcoin Cash — incluindo o algoritmo de ajuste de dificuldade ASERT (com uma meia-vida de 1 hora, resistente a ataques, no lançamento), blocos de 32 MB, endereçamento CashAddr e todo o conjunto de atualizações do protocolo BCH até à Atualização 11 (ABLA).

Enquanto a Bitcoin e os seus derivados são dominados por operações de mineração industriais, a BCH2 oferece um recomeço com níveis de dificuldade acessíveis. Sem pré-mineração, sem taxas de programador e com uma distribuição justa 1:1 aos detentores de BC2, a BCH2 representa um regresso ao espírito de mineração descentralizada que tornou a Bitcoin revolucionária.

1. Introdução

1.1 A visão original

Quando Satoshi Nakamoto lançou a Bitcoin em 2009, qualquer pessoa com um computador pessoal podia minerar blocos e ganhar recompensas. Essa acessibilidade era fundamental para a natureza descentralizada da Bitcoin: milhares de mineradores independentes a proteger a rede, cada um com uma hipótese justa.

1.2 A evolução da Bitcoin

À medida que a Bitcoin cresceu, os desacordos sobre escalabilidade e filosofia levaram a desenvolvimentos importantes:

• 2017: Bitcoin Cash (BCH) separou-se da Bitcoin no bloco 478.558, aumentando o tamanho de bloco para 8 MB (mais tarde 32 MB) para permitir mais transações e taxas mais baixas. A BCH tem melhorado continuamente: implementou o algoritmo de ajuste de dificuldade ASERT em 2020 e inúmeras melhorias do protocolo até 2025.
• 2025: BC2 (BitcoinII) foi lançada como uma implementação nova baseada no Bitcoin Core v27 com um bloco génese próprio, oferecendo uma cadeia limpa para experimentação e novos casos de uso.
• 2026: BCH2 (Bitcoin Cash II) separa-se da BC2 na altura 53.200, preservando todo o histórico da BC2 e adotando ao mesmo tempo as regras de consenso da Bitcoin Cash. Daí resulta uma combinação única: a distribuição inicial justa da BC2 com as melhorias de protocolo já testadas da BCH.

1.3 O problema hoje

A dificuldade da rede Bitcoin atingiu níveis astronómicos, tal como a BCH e a maioria dos derivados SHA-256. Isto cria vários problemas:

1. Domínio industrial — Só operações de grande escala, com eletricidade barata e compras de ASIC a granel, conseguem minerar com lucro nas cadeias principais.
2. Exclusão do mineiro doméstico — Quem minera sozinho com equipamentos pequenos tem uma probabilidade praticamente nula de encontrar um bloco em redes de dificuldade elevada.
3. Centralização em pools — Os mineradores são empurrados para pools, pagam taxas e têm de confiar nos operadores, o que reduz o caráter entre pares da criptomoeda.
4. Algoritmos de dificuldade herdados — As cadeias que usam o período de ajuste de 2016 blocos da Bitcoin podem sofrer uma variância extrema nos tempos de bloco quando o hashrate oscila.

1.4 A solução da BCH2

A BCH2 responde a estes problemas assim:

• Começar num nível de dificuldade acessível, herdado dos primeiros blocos da BC2
• Implementar o ASERT com uma meia-vida de 1 hora para uma recuperação rápida da dificuldade face a ataques de manipulação
• Oferecer blocos de 32 MB para a escalabilidade futura
• Usar o formato CashAddr para endereços fáceis de usar
• Manter 100% de compatibilidade com as melhorias do protocolo Bitcoin Cash
• Transição automática da meia-vida do ASERT de 1 hora para 2 dias no bloco 92.736 (cerca de 9 meses após o fork), sem hard fork

2. Porquê a BCH2

2.1 Princípios de lançamento justo

A BCH2 rejeita os modelos de token extrativos que marcaram os lançamentos recentes:

Sem pré-mineração: Todo o fornecimento de BCH2 no fork é distribuído pelos detentores de BC2 conforme o que tinham no bloco do fork. Não são criadas moedas para programadores, fundações ou pessoas próximas.

Sem taxa de programador: 100% das recompensas de bloco vão para os mineradores. O desenvolvimento é financiado pela comunidade e voluntário, não retirado das recompensas.

Sem ICO/IEO: A BCH2 não é vendida nem pré-atribuída. A distribuição faz-se pelo fork da BC2 e pela mineração contínua.

Base de código comprovada: A BCH2 assenta no BitcoinII Core v27.1, a mesma base que protege milhares de milhões em valor na Bitcoin e nos seus derivados.

2.2 Distribuição do fork aos detentores de BC2

Seguindo o precedente da Bitcoin Cash em 2017, a BCH2 reconhece os detentores de BC2 através de um fork 1:1:

• Todos os saldos da BC2 no bloco do fork são creditados como BCH2 (cerca de 2.660.000 moedas no fork)
• Quem controla as chaves privadas da BC2 controla automaticamente os BCH2 equivalentes
• Sem registo, reclamações ou KYC: basta importar as chaves numa carteira BCH2

Este modelo garante:

• Distribuição justa para quem apoiou a BC2
• Liquidez imediata desde o primeiro dia
• Sem concentração da oferta nas mãos dos desenvolvedores
• Interesses alinhados entre os primeiros apoiantes e o sucesso da rede

2.3 Devolver o acesso à mineração

A dificuldade da BCH2 no fork dá oportunidades realistas a mineradores pequenos:

• Mineiros de lotaria bem-vindos — Equipamentos como o Bitaxe, o Nerdminer e outros mineiros de baixo hashrate têm probabilidades reais de encontrar blocos.
• Mineração doméstica viável — Os ASIC de consumo podem competir pela recompensa completa de bloco.
• O retorno da mineração a solo — Cada mineiro pode minerar por conta própria, sem ter de entrar num pool.
• Crescimento natural — À medida que a adoção cresce, a dificuldade sobe organicamente com a rede.

3. Especificações técnicas

3.1 Parâmetros de consenso

3.2 Parâmetros do fork

3.3 Configuração de rede

3.4 Alturas de ativação antes do fork (histórico BC2)

Estas ativações ocorreram no histórico da BC2 e são preservadas na BCH2:

3.5 Ativações da BCH2 (após o fork)

Todas as atualizações do protocolo Bitcoin Cash ativam-se em simultâneo no bloco 53.201:

3.6 Funcionalidades desativadas (face a BTC/BC2)

As seguintes funcionalidades de BTC/BC2 ficam desativadas após o fork, em linha com o consenso BCH:

3.7 Algoritmo de ajuste de dificuldade ASERT

A BCH2 usa o ASERT (Absolutely Scheduled Exponentially Rising Targets), o algoritmo de ajuste de dificuldade adotado pela Bitcoin Cash em novembro de 2020 (atualização Axion). A BCH2 usa o aserti3-2d exatamente como implementado no BCHN v29.0.0, com um parâmetro de meia-vida alterado por segurança no lançamento.

Algoritmo central:

O ASERT calcula a dificuldade a partir do tempo decorrido desde um «bloco âncora» (para a BCH2, o bloco do fork), visando exatamente 10 minutos por bloco em média:

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

Em que:

• anchor_target = alvo de dificuldade no bloco âncora (bloco do fork)
• actual_time = tempo decorrido desde o bloco pai da âncora
• scheduled_time = tempo esperado, dado pela diferença de altura × 600 segundos
• halflife = constante de tempo que controla a velocidade do ajuste

Meia-vida ASERT: parâmetro crítico no lançamento:

Fundamentação da meia-vida de 1 hora:

Uma cadeia nova com hashrate limitado (~1 PH/s) é vulnerável a ataques de manipulação da dificuldade. Quem tenha muita potência pode minerar depressa para disparar a dificuldade e depois retirar a potência, deixando os mineradores honestos sem conseguir encontrar blocos com a dificuldade inflacionada. Com a meia-vida de 2 dias do BCHN, recuperar de um pico de 10× levaria cerca de 6,6 dias — a rede ficaria inutilizável quase uma semana, os mineradores sairiam para cadeias rentáveis e poderia desencadear-se uma espiral de morte.

Com a meia-vida de 1 hora da BCH2, o mesmo ataque resulta em apenas ~7 horas de blocos lentos antes de tudo voltar ao normal. Os mineradores podem esperar ou continuar a minerar, e o custo do atacante é desperdiçado.

Análise do compromisso:

A meia-vida de 1 hora é adequada à fase de lançamento da BCH2, com hashrate limitado. A maior volatilidade é um preço aceitável pela resistência a ataques.

Configuração da âncora ASERT:

4. Formato de endereço

4.1 Especificação CashAddr

A BCH2 usa o formato CashAddr desenvolvido pela Bitcoin Cash, que oferece:

• Um prefixo legível que identifica a rede
• Deteção de erros através de uma soma de verificação de código BCH
• Codificação indiferente a maiúsculas, mais fácil de escrever
• Clara diferenciação face aos endereços da Bitcoin/BC2

4.2 Exemplos de endereços

P2PKH (Pay to Public Key Hash):

bitcoincashii:qz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcr7hxlmnj

P2SH (Pay to Script Hash):

bitcoincashii:pz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcfnk4xmwy

4.3 Indicadores de tipo de endereço

5. Parâmetros de transação

5.1 Especificações de transação

5.2 Proteção contra repetição

As assinaturas incluem o fork ID na pré-imagem do sighash, impedindo a repetição de transações entre cadeias. As transações BCH2 assinadas após o bloco 53.200 são inválidas na BC2, e as da BC2 são inválidas na BCH2.

5.3 Proteção contra gasto duplo (DSProof)

A BCH2 integra o DSProof (prova de gasto duplo), um mecanismo ao nível do protocolo para detetar em tempo real tentativas de gasto duplo em transações não confirmadas. Criado originalmente para a Bitcoin Cash, o DSProof reforça a segurança sem confirmações para comerciantes e processadores de pagamento.

Quando um nó deteta transações em conflito a gastar a mesma entrada, constrói e difunde uma mensagem DSProof pela rede. Comerciantes e carteiras atentos a estes alertas podem sinalizar transações suspeitas em segundos, sem esperar pela confirmação em bloco.

Isto torna mais seguro o comércio sem confirmações — um caso de uso central do dinheiro eletrónico entre pares.

5.4 Migração de UTXO SegWit (witness via scriptSig)

A BC2 herdou o SegWit da Bitcoin, pelo que o conjunto de UTXO no bloco do fork contém moedas bloqueadas em saídas SegWit (P2WPKH, P2WSH, P2TR e variantes encapsuladas em P2SH). Como a BCH2 remove as regras de consenso do SegWit, esses UTXO ficariam normalmente por gastar após o fork.

A BCH2 resolve isto com witness via scriptSig — um mecanismo de migração que permite gastar os UTXO SegWit existentes colocando os dados de assinatura no campo scriptSig tradicional em vez do campo witness.

Processo de verificação:

• P2WPKH (v0, 20 bytes): Espera [assinatura, chave pública] em scriptSig. O nó constrói um script P2PKH implícito e verifica contra ele.
• P2WSH (v0, 32 bytes): Espera [...argumentos, script] em scriptSig. O nó verifica se SHA256(script) corresponde ao hash da saída.
• P2TR (v1, 32 bytes): Espera [assinatura Schnorr] em scriptSig, apenas para gasto pela via da chave.
• Encapsulado em P2SH: o script de resgate é incluído em scriptSig, juntamente com os dados de assinatura.

Segurança:

• A mesma segurança criptográfica do SegWit: continuam a exigir-se assinaturas válidas
• O SIGHASH_FORKID é exigido em todas as assinaturas após o fork (proteção contra repetição)
• O gasto pela via de script do Taproot não é suportado — apenas a via da chave. Quem use scripts Taproot complexos deve mover as suas moedas antes do fork.

Importante: este mecanismo só se aplica aos UTXO SegWit que existiam no bloco do fork ou antes. Após o fork não é possível criar novas saídas SegWit — o consenso da BCH2 rejeita-as.

Algoritmo de sighash:

Na BCH2, os UTXO SegWit são gastos com o algoritmo de sighash do BIP143 e SIGHASH_FORKID (0x41):

sighash = SHA256(SHA256(
    nVersion ||
    hashPrevouts ||
    hashSequence ||
    outpoint ||
    scriptCode ||      // P2PKH script for pubkeyhash
    value ||           // 8-byte little-endian satoshis
    nSequence ||
    hashOutputs ||
    nLockTime ||
    hashType           // SIGHASH_ALL | SIGHASH_FORKID (0x41)
))

A assinatura é colocada em scriptSig e não em witness: scriptSig: <signature> <pubkey>, witness: (vazio)

Tipos de endereço suportados na migração:

5.5 Processo de resgate da distribuição do fork

A BCH2 distribui 1:1 todos os saldos da BC2 na altura do fork, 53.200. O processo de reclamação suporta todos os tipos de endereço através de uma interface de carteira unificada.

Derivação e varrimento:

A carteira deriva os endereços de uma frase mnemónica BIP39 usando caminhos de derivação padrão:

São varridas tanto a cadeia de endereços externa (receção) como a interna (troco), para localizar todos os UTXO elegíveis para o fork.

Proteção contra abusos:

Para impedir reclamar duas vezes manipulando o tipo de endereço, a carteira verifica a origem do saldo:

isFromForkDistribution = (BC2_balance > 0)

Se existe saldo em BCH2 mas o saldo correspondente na BC2 é zero, os fundos chegaram depois do fork e são sinalizados como alheios à distribuição do fork. Isto impede o seguinte vetor de ataque:

1. Reclamar BCH2 num endereço SegWit
2. Mover os fundos originais da BC2 para um endereço legacy
3. Tentar reclamar de novo no endereço legacy

A carteira mostra avisos adequados que distinguem os depósitos posteriores ao fork dos saldos da distribuição.

6. Capacidades de script (após o fork)

A BCH2 suporta o conjunto completo de instruções de script da BCH:

7. Parâmetros de segurança da cadeia

8. Transição da meia-vida ASERT

8.1 Transição automática

A meia-vida do ASERT na BCH2 passa automaticamente de 1 hora para 2 dias numa altura de bloco predeterminada. Não é necessário qualquer hard fork.

8.2 Mecanismo de transição

A meia-vida é determinada pela altura de bloco:

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

O bloco 92.736 corresponde à época 46, cerca de 9,15 meses após o fork no bloco 53.200. Os parâmetros da âncora ASERT mantêm-se inalterados — muda apenas a constante de meia-vida.

8.3 Fundamentação

Uma altura de transição fixa evita um hard fork coordenado e os critérios subjetivos que o acompanhariam. Aos 9 meses após o lançamento, a rede já terá tido tempo para firmar um hashrate estável e diversidade de mineradores. A transição está inscrita nas regras de consenso desde o início, pelo que todos os nós concordam na mudança sem coordenação adicional.

9. Mineração

9.1 Calendário de recompensas de bloco

A BCH2 segue o calendário de emissão original da Bitcoin:

9.2 Pool de mineração

O Forge Pool fornece a infraestrutura de mineração da BCH2 com uma arquitetura distribuída pelo mundo:

Dados de ligação:

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

Funcionalidades:

• Uma única morada de ligação — Ligue-se a um só endereço, com encaminhamento automático para o proxy regional mais próximo
• Rede global de proxies — Ligações de baixa latência a partir de qualquer local
• Controlos por interface web — Mude o modo de mineração (a solo/em pool) e os ajustes de dificuldade sem reconfigurar o equipamento
• Pagamento a solo — Minere a solo e receba a recompensa completa do bloco diretamente na sua carteira
• Suporte a vardiff — Ajuste automático da dificuldade conforme o seu hashrate
• Pagamento PPLNS — Distribuição justa da recompensa conforme os shares contribuídos
• Pagamento mínimo: 5 BCH2
• Taxa do pool: 1% (0,5% na mineração a solo)

9.3 Mineração solo

A dificuldade acessível da BCH2 torna viável a mineração a solo. Configure o seu equipamento para ligar diretamente ao seu nó BCH2:

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

10. Infraestrutura

10.1 Rede global de nós

A BCH2 opera nós semente em vários continentes:

10.2 Serviços

10.3 Compatibilidade de carteiras

A BCH2 é compatível com a infraestrutura de carteiras da Bitcoin Cash:

• Derivação HD padrão BIP32/39/44
• Codificação de endereços CashAddr (prefixo: bitcoincashii:)
• Formato de transação padrão (com SIGHASH_FORKID)
• Caminho de derivação próprio da BCH2: m/44'/145'/0'/0/x
• O formato legacy (1xxx) mantém-se válido por compatibilidade de exibição

Formato de endereço:

bitcoincashii:qp63uahgrxged4z5jswyt5dn5v3lzsem6cy74rqsfs

10.4 Integração do protocolo Electrum

As consultas de saldo e de UTXO usam métodos baseados em scripthash, para suportar qualquer tipo de endereço:

scripthash = REVERSE(SHA256(scriptPubKey))

11. Tokenomia

11.1 Distribuição do fornecimento no fork

11.2 Distribuição contínua

Todos os BCH2 novos entram em circulação exclusivamente pela mineração:

• Recompensa por bloco: 50 BCH2
• Parte dos mineradores: 100%
• Taxa de desenvolvimento: 0%
• Método de distribuição: apenas prova de trabalho

11.3 Calendário de fornecimento

12. Governação

12.1 Desenvolvimento descentralizado

A BCH2 funciona sem autoridade central:

• Sem fundação: nenhuma entidade jurídica controla a BCH2
• Sem ditador benevolente: nenhuma pessoa tem autoridade especial sobre o protocolo
• Código aberto: todo o código é auditável publicamente sob licença MIT
• Financiado pela comunidade: o desenvolvimento sustenta-se em contribuições voluntárias

12.2 Atualizações do protocolo

As alterações às regras de consenso da BCH2 exigem:

1. Proposta: especificação pública das alterações propostas
2. Revisão: análise pela comunidade e pelos desenvolvedores
3. Implementação: desenvolvimento do código e testes
4. Sinalização: medição do apoio de mineradores e operadores de nós
5. Ativação: atualização coordenada numa altura ou hora determinada

12.3 Alinhamento com a Bitcoin Cash

A BCH2 pretende manter-se compatível com as melhorias do protocolo Bitcoin Cash:

• DAA ASERT (implementado)
• Blocos de 32 MB (implementado)
• Introspeção nativa (implementado)
• As futuras atualizações da BCH são avaliadas para adoção

13. Roteiro

Fase 1: lançamento ✓

• Fork a partir da BC2 na altura de bloco designada
• Ajuste de dificuldade ASERT ativo
• Tamanho de bloco de 32 MB ativado
• Endereçamento CashAddr (bitcoincashii:)
• Rede global de nós em funcionamento
• Pool de mineração (Forge Pool) em funcionamento
• Software de nó completo publicado

Fase 2: adoção

• Carteiras de computador (fork do Electron Cash)
• Carteiras móveis (Android, iOS)
• Carteira web
• Melhorias no explorador de blocos
• Mais pools de mineração
• Listagens em casas de câmbio

Fase 3: ecossistema

• Ferramentas de pagamento para comerciantes
• Suporte a carteiras físicas (Ledger, Trezor)
• Implementação de privacidade CashFusion
• Integração de CashTokens
• SDK e documentação para desenvolvedores

Fase 4: crescimento

• Alinhamento contínuo com o protocolo BCH
• Melhorias de privacidade
• Desenvolvimento do ecossistema de tokens e NFT
• Continuar a descentralizar a infraestrutura
• Desenvolvimento de funcionalidades conduzido pela comunidade

14. Considerações de segurança

14.1 Segurança do SHA-256

A BCH2 usa o mesmo algoritmo de prova de trabalho SHA-256 que protege a Bitcoin desde 2009:

• Sem pressupostos criptográficos novos
• Compatível com milhares de milhões de dólares em equipamento de mineração
• Mais de 15 anos de validação de segurança no mundo real

14.2 Proteção contra repetição

A BCH2 implementa a proteção contra repetição através do SIGHASH_FORKID:

• As transações assinadas para a BCH2 são inválidas na BC2
• As transações assinadas para a BC2 são inválidas na BCH2
• Ninguém pode gastar por acidente na cadeia errada

14.3 Estado da auditoria de código

A BCH2 baseia-se em:

• BitcoinII Core v27.1 (baseado no Bitcoin Core, amplamente auditado)
• As alterações de protocolo da Bitcoin Cash (testadas na prática desde 2017)
• A implementação do CashAddr (código padrão da BCH)
• A implementação do ASERT (em uso na BCH desde 2020)

15. Conclusão

A BCH2 une as melhorias de protocolo já testadas da Bitcoin Cash a um modelo de distribuição justo. Ao separar-se da BC2 na altura 53.200, a BCH2 oferece:

Para quem detém BC2:

• Distribuição automática de BCH2 a 1:1 no fork
• Nada a fazer: as mesmas chaves funcionam em ambas as cadeias
• O valor do investimento em BC2 mantém-se

Para os mineradores:

• Níveis de dificuldade acessíveis
• ASERT com meia-vida de 1 hora, que garante uma recuperação rápida de ataques à dificuldade
• Normalização prevista da meia-vida para 2 dias quando o hashrate estabilizar
• 100% das recompensas de bloco (sem taxa de desenvolvimento)

Para os utilizadores:

• Blocos de 32 MB para escalar
• Taxas baixas graças ao espaço de bloco
• CashAddr para endereços fáceis de usar
• Confirmações rápidas graças a tempos de bloco regulares
• Todas as capacidades de script da BCH, incluindo covenants e introspeção

Para o ecossistema:

• Sem pré-mineração nem atribuições a pessoas de dentro
• Governação pela comunidade
• Desenvolvimento em código aberto
• Compatibilidade com o protocolo Bitcoin Cash
• Um caminho claro para o alinhamento total com os parâmetros do BCHN

A BCH2 é a criptomoeda tal como foi pensada: aberta, acessível, justa e verdadeiramente descentralizada.

16. Referências

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

17. Apêndice A: guia rápido

Correr um nó completo

Transferência:

https://bch2.org/downloads/

Configuração (~/.bitcoincashII/bitcoincashII.conf):

server=1
daemon=1
listen=1
port=8339
rpcport=8342
rpcuser=your_username
rpcpassword=your_secure_password

# Seed nodes
addnode=144.202.73.66:8339
addnode=108.61.190.83:8339
addnode=64.176.215.202:8339
addnode=139.180.132.24:8339

Arranque:

bitcoincashIId -daemon

Mineração

Mineração em pool:

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

Mineração a solo:

Configure o seu ASIC para ligar à porta RPC do seu nó local.

Resgatar a distribuição do fork da BC2

Se detinha BC2 no bloco 53.200:

1. Exporte as suas chaves privadas da BC2 (formato WIF)
2. Importe-as numa carteira BCH2
3. O seu saldo em BCH2 é igual ao seu saldo em BC2 no fork

18. Apêndice B: comparação técnica

Resumo BCH2 vs BCHN

19. Apêndice C: perguntas frequentes

A BCH2 é um fork da Bitcoin Cash?

A BCH2 é um fork da BC2 (BitcoinII) na altura 53.200 que adota as regras de consenso da Bitcoin Cash. Preserva o histórico da cadeia da BC2 e incorpora as melhorias de protocolo da BCH.

Preciso de fazer alguma coisa para receber a minha BCH2?

Não. Se controlava as chaves privadas da BC2 no bloco 53.200, pelo próprio fork detém automaticamente a mesma quantia em BCH2. Basta importar as suas chaves numa carteira BCH2.

Porquê fazer fork da BC2 em vez da BCH diretamente?

A BC2 teve uma distribuição justa desde o seu bloco génese e uma mineração acessível. Ao fazer fork da BC2 e passar às regras da BCH, a BCH2 une distribuição justa a melhorias de protocolo já testadas.

O SegWit é suportado?

Após o fork não é possível criar novas saídas SegWit. No entanto, os UTXO SegWit já existentes do histórico da BC2 (P2WPKH, P2WSH, P2TR e variantes encapsuladas em P2SH) podem ser gastos através do mecanismo «witness via scriptSig» da BCH2, que passa os dados de assinatura do campo witness para o scriptSig tradicional. O gasto Taproot pela via da chave é suportado; pela via de script não — quem use scripts Taproot complexos deve mover as suas moedas antes do fork. O RBF também está desativado.

Que carteira devo usar?

Qualquer carteira que suporte o formato CashAddr pode ser adaptada à BCH2. As carteiras oficiais serão publicadas a partir do código do Electron Cash.

Como minero BCH2?

Ligue qualquer ASIC SHA-256 a pool.bch2.org:3333 ou minere a solo contra o seu próprio nó.

Porque é que a meia-vida ASERT difere da BCH?

A BCH2 arranca com uma meia-vida ASERT de 1 hora (contra os 2 dias da BCH) para se proteger de ataques de manipulação da dificuldade que poderiam paralisar uma cadeia nova com hashrate limitado. A meia-vida passa automaticamente a 2 dias no bloco 92.736 (cerca de 9 meses após o fork), sem hard fork.

Quando acontece o fork?

O fork ocorre na altura 53.200 da BC2, com lançamento previsto por volta de 7-9 de março de 2026. Quem detenha BC2 deve garantir que controla as suas chaves privadas antes dessa data.