Testnet

Anna quer aprender a receber e enviar bitcoin antes de usar seu dinheiro. Em uma aplicação compatível com Testnet, cria uma carteira de teste separada. Recebe fundos de um faucet, serviço que distribui pequenas quantidades de moedas de teste, e envia parte a Pavel na mesma rede. Assim conhece endereço, transação e espera por confirmação sem gastar BTC reais. É um exemplo ilustrativo, não um tutorial de uma aplicação específica: nem toda carteira oferece esse modo. Moedas de teste não são bitcoins gratuitos. Seu saldo não pode ser convertido por uma mudança de configuração nem transferido para mainnet, e um faucet indisponível não justifica comprá-las como investimento. [11]

Testnet não é uma conta de treinamento dentro da rede principal do Bitcoin. É outra cadeia de blocos, iniciada por seu próprio Genesis Block. Um bloco reúne transações no histórico compartilhado; o Genesis Block é o bloco inicial. A rede também tem seus UTXO, as saídas de transações ainda não gastas. Uma saída define um valor e as condições para gastá-lo, como uma assinatura necessária. Portanto, receber fundos em uma rede não cria saldo na outra. Os programas distinguem redes pelos parâmetros, como identificadores no início das mensagens e portas. Redes diferentes, porém, não precisam ter endereços visivelmente diferentes. Uma chave privada é um dado secreto usado pela carteira para criar uma assinatura que autoriza gastar os fundos correspondentes. Mesmo chaves privadas idênticas não unem os dois históricos numa carteira de saldo compartilhado. [12] [15]

Endereços começando por tb1 podem pertencer a Testnet3, Testnet4 ou Signet. Anna e Pavel combinam a rede exata e a verificam nas duas aplicações; dizer apenas “de teste” não basta. Anna usa novas chaves e uma cópia de segurança separada. Não insere a Seed Phrase (as palavras de recuperação) de uma carteira com fundos reais numa aplicação experimental. Mudar de modo não torna confiável um programa suspeito. Um faucet também precisa, no máximo, de um endereço público de recebimento, nunca de palavras de recuperação ou de uma chave privada. Separar arquivos de carteira, chaves e cópias reduz enganos e vínculos indesejados entre experiências e pagamentos pessoais. [12] [14]

Testnet público permite experiências com participantes desconhecidos e mineração aberta. Signet também é um ambiente de testes, mas exige, além de Proof of Work (o trabalho computacional necessário para encontrar um bloco válido), cumprir uma condição do bloco, normalmente uma assinatura criada com chaves autorizadas. Isso permite coordenar melhor a produção de blocos, embora não garanta operação ininterrupta. Regtest atende ao desenvolvedor que precisa controlar o experimento: ele opera seu ambiente e cria blocos sob demanda, por exemplo em testes automatizados. Se Anna apenas aprende a usar a carteira, também importa quais redes a aplicação aceita. Nenhuma dessas redes transforma suas moedas em bitcoin da mainnet. [10] [11] [16]

O pagamento experimental de Pavel pode passar rápido e com uma taxa pequena. Isso não permite deduzir quanto o mesmo procedimento custará na mainnet. O movimento, o poder de mineração e os incentivos dos participantes diferem. Um Testnet público pode ficar muito tempo sem bloco, sofrer uma falha de serviço ou uma reorganização: os nós, computadores que verificam as regras da rede, substituem um ramo recente do histórico por outro válido. Essas situações ajudam a encontrar erros, mas nem toda falha é intencional. Um teste bem-sucedido verificou certo comportamento em certas condições; sozinho, não comprova a guarda segura de chaves nem a resistência de um serviço com dinheiro real. [10] [2]

Guias antigos mencionam Testnet3, iniciado em 2011. Com o tempo surgiram problemas de distribuição de moedas e de regras de dificuldade da mineração. Os chamados block storms eram rajadas de blocos minerados muito rapidamente: a altura crescia de forma anormal, e o subsídio por novo bloco diminuía mais depressa do que o calendário sugeria. Também houve comércio de moedas de teste, embora devessem ser uma ferramenta acessível. Uma geração nova começa outro histórico; não reavalia os saldos antigos. Ao ler um guia, confira o número da rede, não apenas o nome Testnet. [1]

A proposta técnica BIP 94 descreve Testnet4, com suporte desde Bitcoin Core 28.0. Além de um novo Genesis Block, mudou o cálculo de dificuldade e as regras de horários dos blocos para limitar formas conhecidas de provocar block storms. Manteve uma exceção: fora o primeiro bloco de um período de dificuldade, um horário mais de 20 minutos posterior ao do bloco anterior exige dificuldade mínima. Isso não promete confirmar um pagamento em até 20 minutos. Testnet4 também aplica desde o início as mudanças de regras ativas na mainnet quando foi proposto, em maio de 2024. Essas melhorias não o tornam um modelo sem falhas da rede principal. [1] [9]

Em 17 de outubro de 2026, BIP 95 para Testnet5 tem status Draft, isto é, uma proposta em elaboração. Propõe retirar a exceção de dificuldade mínima, elevar esse mínimo e aplicar desde o primeiro bloco BIP 54, um conjunto de mudanças propostas nas regras de consenso. Ainda faltam dados definitivos do Genesis Block e um link para a implementação de referência. Portanto, esse documento não permite apresentar Testnet5 como uma rede Bitcoin Core normalmente implantada. Testar regras novas tampouco as ativa na mainnet. Numa leitura futura, verifique o estado da proposta e a documentação da versão usada, em vez de confiar no número maior do nome. [2]

Em Bitcoin Core, a opção testnet4 seleciona Testnet4; consulte a documentação de sua versão para a sintaxe exata. No arquivo de configuração, [test] indica Testnet3 e [testnet4] indica Testnet4. Os dados ficam em subdiretórios separados: testnet3, testnet4, signet ou regtest. Também é preciso conferir o programa em execução: getblockchaininfo informa o identificador da rede no campo chain. Verifique ainda o hash do Genesis Block, a sincronização e os nós conectados. Num Signet personalizado, o genesis compartilhado não basta; confira também sua condição específica de bloco. Um título de janela ou endereço parecido não substitui essas verificações. [8] [12] [13] [14] [10]

Anna primeiro confere se as duas carteiras usam a mesma rede. Depois experimenta receber e enviar, distinguindo pagamento enviado de pagamento confirmado. A restauração é testada apenas com uma cópia experimental separada. O desenvolvedor pode acrescentar reinício da aplicação, nó indisponível, reorganização ou rejeição da rede errada. Para taxas, pode testar RBF, substituição de uma transação não confirmada, e CPFP: uma transação filha com taxa maior incentiva incluir também sua antecessora não confirmada. O resultado deve registrar rede, versão do programa e comportamento realmente verificado. Testnet é um lugar útil para cometer erros que se quer evitar com dinheiro real; não prova que novas verificações sejam desnecessárias. [11] [9]