Soft Fork

Imagine Anna e Pavel verificando o Bitcoin, cada um no próprio computador. Anna atualizou o software; Pavel ainda não. Surge uma mudança semelhante ao BIP66: assinaturas digitais, que comprovam a autorização para gastar determinados bitcoins, precisam seguir um formato definido com mais precisão. Algumas codificações antes aceitas deixam de ser permitidas. Um pagamento com uma assinatura válida no formato agora exigido passa por essa verificação nos dois computadores. Mas, se a assinatura usar uma codificação antes permitida e agora proibida, Anna a rejeita, enquanto Pavel ainda pode aceitá-la. Estamos supondo que o pagamento cumpra todas as outras regras. Essa diferença explica o Soft Fork: as novas regras proíbem casos adicionais sem permitir nada que as antigas proibissem. Enquanto os mineradores produzirem blocos que atendam às regras mais rigorosas, ambos poderão acompanhar a cadeia. Pavel, porém, não verifica a condição adicional por conta própria. Assim, um Soft Fork permite modificar o Bitcoin sem atualizar todos os nós ao mesmo tempo. Isso não faz o software antigo verificar tudo o que o novo verifica, nem cria uma segunda moeda por si só. [1] [6]

Um Full Node é um computador que verifica as regras do Bitcoin de forma independente. Ao escolher entre ramificações válidas, compara o trabalho acumulado comprovado pela mineração, não os votos de seus apoiadores. O full node antigo pode seguir a cadeia porque mineradores atualizados normalmente produzem blocos reconhecidos por ele. Porém, não verifica a condição adicional: pode aceitar uma ramificação com mais trabalho que viola a nova regra enquanto nós novos a rejeitam. Quem precisa da nova garantia deve atualizar seu software de verificação. Receber pagamentos, reconhecer formatos e validar todo o consenso são capacidades diferentes. [1] [12]

Um BIP é uma proposta técnica numerada. Publicá-la não altera a rede: é preciso desenvolver e verificar o software, e seus usuários decidem se vão utilizá-lo. Mainnet é a rede principal do Bitcoin, onde bitcoins reais são transferidos. A ativação determina quando os nós atualizados passam a exigir a nova regra nessa rede. Ter o código no programa, portanto, não significa que ele já seja usado para verificar blocos. Nos procedimentos descritos aqui, lock-in significa que a condição para uma ativação futura foi atendida; a regra ainda pode não estar em vigor. O nó passa a verificá-la no estado ACTIVE. Ele calcula esse estado a partir dos blocos anteriores de sua própria ramificação. Se uma reorganização mudar esse histórico perto do limite de ativação, o resultado também pode mudar. Dois programas com parâmetros de ativação diferentes podem, assim, aceitar blocos diferentes no mesmo momento. [2] [15]

O minerador constrói seu bloco sobre um bloco anterior, também chamado de bloco pai. Se não o verificar, pode desperdiçar trabalho em uma ramificação que outros nós rejeitarão. Em julho de 2015 alguns mineradores sinalizaram BIP66 sem validar adequadamente o bloco pai. Estenderam um bloco inválido e criaram uma ramificação inválida de seis blocos em 4 de julho; outra menor surgiu no dia seguinte. Nós atualizados rejeitaram ambas. Um bit ou versão é declaração do minerador, não uma prova de que ele verificou de forma independente o bloco preparado, seu antecessor e as transações incluídas. [6] [14]

Para saber quais regras seu nó realmente aplica, comece pela versão do software e pelas informações que ele próprio fornece. Conforme a versão, getdeploymentinfo e getblockchaininfo informam sobre as mudanças implantadas e a cadeia. Com a documentação dessa versão, a altura de ativação e os logs, ajudam a distinguir uma regra preparada de uma já ativa. Um explorador de blocos na web mostra a visão de outro serviço; não comprova o que seu computador verifica. O hashrate mede a capacidade computacional da mineração. Ele não dá aos mineradores autorização para contornar as regras do seu nó: no estado ACTIVE, um nó atualizado rejeita um bloco que viole a nova condição, mesmo que tenha o apoio da maioria da capacidade de mineração. A permanência de uma divisão também depende do trabalho acumulado pelas ramificações e de seu uso econômico. Simplesmente remover uma restrição ativa permitiria novamente blocos hoje inválidos e seria, portanto, um Hard Fork. Antes da ativação, uma versão coordenada do software pode alterar os parâmetros, mas essa mudança também não se instala sozinha nos nós de outras pessoas. [1] [15] [16]

V(antigo) reúne os blocos aceitos antes da atualização. Só existe Soft Fork quando V(novo) está dentro dele: o nó novo rejeita casos adicionais e todo bloco novo válido passa nas verificações antigas. O nome descreve compatibilidade de validade, não tamanho, segurança ou consenso social. Aumentar um limite visível ao nó antigo ou permitir um gasto antes inválido amplia o conjunto e normalmente exige Hard Fork. [1] [17]

Regras mais rigorosas também podem trazer uma nova função. O BIP66 definiu com rigor o formato DER de codificação das assinaturas. Os BIP65 e BIP112 acrescentaram condições temporais de gasto a certos comandos NOP, que antes não impunham nenhuma condição. O SegWit introduziu programas witness e dados de validação chamados witness, como as assinaturas. Mais tarde, o Taproot usou a versão reservada 1. Nós antigos não verificam as novas condições correspondentes. Anyone-can-spend descreve essa visão limitada, não uma forma de contornar nós atualizados e gastar moedas de outra pessoa. O SegWit também vincula criptograficamente os dados witness ao bloco por meio de um witness commitment. Esse vínculo fica na transação coinbase, a primeira transação com a recompensa do minerador, e preserva a compatibilidade com as antigas regras do bloco base. [6] [5] [7] [8] [12]

Um bit tem valor 0 ou 1. Em nVersion, o campo de versão do cabeçalho do bloco, determinados bits podem indicar a preparação do minerador. BIP9 atribui a cada implantação um nome, um bit específico, um horário de início e um prazo final. O procedimento original da mainnet avalia períodos de 2016 blocos. Se pelo menos 1916 blocos sinalizarem durante STARTED, ou seja, 95 %, o período seguinte passa a LOCKED_IN. Depois de mais um período de espera, chega ACTIVE. Se a condição não for atendida antes do prazo, o procedimento pode terminar em FAILED. O estado inicial, antes do começo, se chama DEFINED. Cada nó calcula essa sequência a partir dos blocos anteriores. Portanto, o nVersion do próprio bloco não decide se a nova regra se aplica a ele. Os sinais ajudam a coordenar a transição; não são uma votação sobre a validade de cada bloco. Depois do lock-in, sinais posteriores já não alteram o resultado desse procedimento. [2]

Versionbits permite aos mineradores sinalizar que estão preparados, mas não alterar as regras dos outros nós. BIP8 usa alturas de bloco em vez de limites temporais. Se lockinontimeout estiver em true e ainda não houver lock-in, o último período pode entrar em MUST_SIGNAL, com sinalização obrigatória. BIP148 exigia que os nós participantes rejeitassem blocos que não sinalizavam SegWit; BIP91 usou um limiar de sinalização dos mineradores mais baixo para coordenar essa transição. Se a aplicação das regras, o hashrate e a aceitação econômica divergirem, a cadeia pode se dividir. Por isso, escolher como ativar a mudança exige avaliar os benefícios e riscos para a segurança. [11] [9] [10] [17]

P2SH (BIP16) permite enviar fundos para o hash de um script, um programa com as condições para gastá-los mais tarde. Em sua introdução, em 2012, sinais nas transações coinbase ajudaram a avaliar a preparação dos mineradores. As novas verificações, porém, passaram a valer a partir de um limite definido para o horário dos blocos; sinalizar não substituía verificar. Coinbase é a primeira transação do bloco e contém a remuneração do minerador. Mudanças posteriores usaram a versão do bloco e limites de sinalização. BIP34 tornou obrigatório registrar na coinbase a altura do bloco, sua posição na cadeia. BIP66 tornou mais rigoroso o formato DER das assinaturas, e BIP65 introduziu CHECKLOCKTIMEVERIFY para exigir um horário ou uma altura mínimos antes do gasto. Aumentar repetidamente o número da versão dificultava implantar mudanças independentes em paralelo. Por isso, BIP9 introduziu bits separados. Em 2016, BIP68, BIP112 e BIP113 foram ativados juntos na altura 419328, mas tratam de condições temporais diferentes. BIP68 introduz uma espera relativa à confirmação da saída que será gasta. BIP112 permite exigir essa espera no script por meio de CHECKSEQUENCEVERIFY, ou CSV. BIP113 muda, por sua vez, a referência de um bloqueio temporal absoluto: usa Median Time Past, a mediana dos horários dos 11 blocos anteriores, em vez do horário do bloco em avaliação. A ativação conjunta não significa que as três propostas introduzam o mesmo bloqueio relativo. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit foi ativado na altura 481824 em agosto de 2017. Ele separou os dados de verificação witness, como assinaturas, da parte da transação usada para calcular seu identificador txid. Por que isso importa? Na codificação anterior, alguém podia modificar a representação de uma assinatura e, com isso, o identificador da transação, sem alterar o destinatário nem o valor pago. Essa possibilidade se chama maleabilidade. Alterar apenas os dados witness não muda o txid; essa solução, porém, não corrige entradas que continuam usando o formato antigo. Um nó antigo vê a transação sem witness e considera um programa witness v0 como anyone-can-spend. Um nó atualizado verifica também o witness e o digest da assinatura, a impressão digital dos dados assinados. O witness commitment armazenado em uma saída coinbase vincula criptograficamente os dados witness ao bloco, permitindo que uma verificação completa detecte mudanças ou omissões. Weight, o peso dos dados no cálculo da capacidade do bloco, ampliou a capacidade efetiva. O bloco base visto pelos nós antigos continuou dentro do limite original de um megabyte. [8]

Key-path permite gastar com uma assinatura para a chave da saída; script-path exige cumprir condições de um script revelado. Schnorr é um esquema de assinatura, e Tapscript é a linguagem desses scripts. BIP341 e BIP342 definem gastos por key-path e script-path, com assinaturas Schnorr e Tapscript, para saídas SegWit nativas com um programa witness de versão 1 de 32 bytes. O nó antigo vê anyone-can-spend: há compatibilidade, não validação completa. Speedy Trial usou uma versão modificada de BIP9, com limite de 1815/2016 (90%) e altura mínima de 709632. Taproot foi ativado nessa altura em 14 de novembro de 2021. Regras e mecanismo de ativação precisam de análises separadas. [12] [13] [16]