Um soft fork é uma transição coordenada do conjunto de validade V(antigo) para seu subconjunto V(novo). A ativação determina o bloco a partir do qual os nós completos atualizados impõem a restrição. A sinalização do minerador pode coordenar a prontidão, mas a validade é decidida por uma regra executada nos nós; design, implementação, implantação, ativação e adoção não são a mesma coisa.
Vamos marcar com V(old) todos os blocos aceitos pelas regras antes do upgrade. A mudança é um soft fork somente se V(novo) estiver dentro de V(antigo): o novo nó rejeitará a próxima classe de blocos, mas um bloco em conformidade com as novas regras também passará nas verificações antigas. O nome fala da compatibilidade das regras de validade, não do tamanho, segurança ou compatibilidade social da mudança. Aumentar o limite visível para um nó antigo ou permitir um gasto anteriormente inválido expande o pool e geralmente requer um hard fork. [Guia do desenvolvedor Bitcoin – Mudanças nas regras de consenso] [Bitcoin Optech – Ativação do soft fork]
Um nó completo antigo pode continuar a seguir a cadeia porque os mineradores atualizados criam rotineiramente blocos que ele reconhece. Mas não verifica a condição adicionada. Se uma ramificação com mais trabalho violar a nova regra, o nó antigo poderá aceitá-la, enquanto o nó atualizado a rejeitará. Quem precisar de uma nova garantia deverá atualizar seu próprio software de validação; a capacidade de uma carteira aceitar pagamentos, compatibilidade de formatos e validação de consenso total são coisas diferentes. [Guia do desenvolvedor Bitcoin – Mudanças nas regras de consenso] [BIP 341 – Implantação Taproot]
O Bitcoin criou subconjuntos usando diversas técnicas. O BIP66 proibiu as assinaturas DER não estritas que as regras antigas aceitavam. BIP65 e BIP112 adicionaram condições aos opcodes NOP que o antigo intérprete considerava uma ação bem-sucedida. SegWit e Taproot deram significado às versões reservadas do programa testemunha, que o antigo nó vê como qualquer um pode gastar. Ao mesmo tempo, o projeto deve evitar que o novo controle seja contornado; O SegWit, portanto, comprometeu os dados das testemunhas via coinbase e preservou as antigas regras básicas de bloqueio. [BIP 66 — Assinaturas DER estritas] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Segregated Witness] [BIP 341 — Implantação Taproot]
O código pode conter uma regra inativa muito antes de entrar em vigor na rede principal. A implementação BIP e verificada não são implantações, os parâmetros de implantação não são lock-in, o lock-in apenas planeja a aplicação futura e apenas o estado ACTIVE significa verificar o bloco fornecido. Cada nó calcula o estado dos ancestrais de seu próprio ramo. A reorganização na fronteira pode recalculá-la e software com parâmetros diferentes pode começar a impor regras incompatíveis. [BIP 9 — Bits de versão com tempo limite e atraso] [Bitcoin Core — versionbits.cpp]
O BIP9 atribui um nome, versão de bit, hora de início e tempo limite para a implantação. A variante mainnet original avalia períodos após 2.016 blocos: após pelo menos 1.916 blocos de sinalização, ou seja, 95%, passa de STARTED para LOCKED_IN, aguarda um período e fica ATIVO; caso contrário, pode acabar FALHA. A sequência completa é DEFINED, STARTED, LOCKED_IN, ACTIVE e FAILED. O estado de um bloco depende de seus ancestrais, não de sua própria nVersion, e a sinalização após o lock-in não altera mais o resultado. [BIP 9 — Bits de versão com timeout e atraso]
Versionbits indicam a prontidão do minerador e coordenam a transição; eles não concedem aos mineiros a propriedade permanente do consenso. O BIP8 utiliza alturas e com lockinontimeout pode forçar a sinalização na última janela. O BIP148, por outro lado, ordenou que os nós participantes rejeitassem blocos de sinalização não-SegWit; O BIP91 baixou o limite de mineração para se coordenar com esta pressão. A ativação obrigatória pode dividir a cadeia se os nós, a taxa de hash e a adoção econômica divergirem, portanto, mesmo o método de ativação é um compromisso de segurança. [BIP 8 — Bits de versão com lock-in por altura] [BIP 148 — Ativação obrigatória do SegWit] [BIP 91 — Limite reduzido SegWit MASF] [Bitcoin Optech — Ativação do soft fork]
P2SH sob BIP16 foi ativado em 2012 por sinalização coinbase e limite de tempo. O BIP34 usou a versão do bloco e o limite para altura obrigatória no coinbase. O mesmo procedimento inteiro executou DER estrito em BIP66 e CHECKLOCKTIMEVERIFY em BIP65, mas consumiu valores de versão e não pôde fazer implantações simultâneas. O BIP9, portanto, introduziu bits independentes. BIP68, BIP112 e BIP113 foram então ativados juntos como tempo de bloqueio relativo e CSV na altura 419.328 em 2016. [BIP 16 - Pay to Script Hash] [BIP 34 - Bloco v2, altura em coinbase] [BIP 65 - CHECKLOCKTIMEVERIFY] [BIP 66 - Assinaturas DER estritas] [BIP 112 - CHECKSEQUENCEVERIFY]
SegWit foi ativado em 481.824 em agosto de 2017. Um nó antigo vê uma transação sem dados de testemunha e considera a testemunha v0 como qualquer um pode gastar; testemunha de verificação atualizada, novo resumo de assinatura e regras anti-maleabilidade. O compromisso da Merkle de testemunhar os dados na saída da coinbase evita que um minerador altere ou omita dados sem detecção. O faturamento por peso aumentou a capacidade efetiva sem que o bloco subjacente visível para o nó antigo excedesse o antigo limite de um megabyte. [BIP 141 – Testemunha Segregada]
BIP341 e BIP342 testemunha programa versão 1 caminho-chave e gasto de caminho de script com assinaturas Schnorr e Tapscript. O nó antigo novamente trata o programa reservado como qualquer um pode gastar: o subconjunto é preservado, a validação completa não. A rede principal usou um BIP9 Speedy Trial modificado com um limite de 1.815 de 2.016 blocos, ou 90%, e uma altura mínima de ativação de 709.632. Taproot ativado nele em 14 de novembro de 2021; As regras do Taproot e como ativá-las são duas questões de auditoria distintas. [BIP 341 – Implantação Taproot] [BIP 342 – Tapscript] [Notas de versão do Bitcoin Core 0.21.1 – Implantação Taproot]
Quando o BIP66 foi ativado em julho de 2015, alguns mineradores sinalizaram a nova versão, mas não validaram suficientemente o bloco pai em que estavam minerando. Eles estenderam o bloco inválido e criaram uma ramificação inválida de seis blocos em 4 de julho; outro incidente mais curto ocorreu no dia seguinte. Os nós de validação atualizados rejeitaram ambas as ramificações. O número ou bit da versão é uma reivindicação do minerador, e não uma prova de que ele mesmo verificou o modelo, os pais e as transações. [BIP 66 – Assinaturas DER estritas] [Bitcoin.org – Alerta de bifurcação da cadeia BIP66 de julho de 2015]
No estado ACTIVE, os nós atualizados rejeitam o bloco ofensor, independentemente do compartilhamento da taxa de hash; a existência de uma divisão permanente depende do trabalho das sucursais e da sua utilização económica. A simples remoção da restrição reativaria os blocos inválidos de hoje e seria, portanto, um hard fork; parâmetros ou código podem ser substituídos por uma liberação coordenada antes da ativação. O operador verifica sua própria versão, getdeploymentinfo ou getblockchaininfo, parâmetros exatos, altura de ativação e logs. Nem o gráfico de sinalização nem o rótulo do explorador podem substituir a validação local. [Guia do desenvolvedor Bitcoin - mudanças nas regras de consenso] [Bitcoin Core - versionbits.cpp] [Notas de versão do Bitcoin Core 0.21.1 - implantação Taproot]
Para ter uma visão mais completa, leia este verbete junto com Regras de consenso, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. Também há referências a este verbete em Hard Fork, BIP (Bitcoin Improvement Proposal), Regras de consenso, Reorg.