Soft fork

Toda atualização que o bitcoin realmente implantou funciona assim. Tornar as regras mais estritas significa que um nó antigo ainda aceita os blocos novos, porque eles não infringem nenhuma das regras que ele conhece. As soft forks entre abril de 2012 e novembro de 2021 deram ao bitcoin endereços de hash de script, timelocks, SegWit e Taproot, e nenhuma delas deixou uma carteira presa.

Como funciona

Uma soft fork reduz o conjunto de blocos válidos, de modo que tudo o que a rede atualizada produz já era legal segundo o livro de regras anterior.

O truque que torna isso possível é que a linguagem de script do bitcoin deixou portas abertas de propósito. Dez opcodes foram definidos como operações nulas que têm sucesso sem fazer nada, e saídas de um tipo que ninguém havia definido ainda eram tratadas como gastáveis por qualquer um que conseguisse satisfazê-las. Uma soft fork atravessa uma dessas portas: ela pega algo que os nós antigos deixam passar e atribui a isso uma exigência real. OP_NOP2 virou OP_CHECKLOCKTIMEVERIFY em dezembro de 2015 e OP_NOP3 virou OP_CHECKSEQUENCEVERIFY em julho de 2016, e para um nó de 2014 ambos ainda são operações nulas em um script que ainda é válido.

A consequência é uma divisão de quem faz o quê. Os nós não atualizados continuam verificando todas as regras que conhecem e permanecem na mesma cadeia que todos os outros. Os nós atualizados verificam mais. Os mineradores são o grupo que de fato precisa se mover, porque um minerador que não atualizou pode montar um bloco que os nós atualizados rejeitam, perder a recompensa e arrastar quem o segue para um ramo condenado.

É por isso que a ativação é a parte difícil, e não o código. Se a maior parte do poder de hash faz cumprir a nova regra, os blocos que a infringem ficam órfãos e o endurecimento se mantém. Se não faz, a rede se divide ao longo de uma linha de falha que a soft fork foi projetada para evitar. O bitcoin já tentou várias formas de estabelecer essa maioria: uma contagem de supermaioria das versões de bloco, o esquema de bits de versão do BIP-9, as opções de timeout do BIP-8 e a janela de três meses do Speedy Trial usada para o Taproot.

Uma soft fork também pode ser desfeita de um modo que uma hard fork não pode. Como a nova regra é uma restrição que o software antigo nunca exigiu, abandoná-la devolve todos a uma cadeia que todas as versões ainda consideram válida.

Por que isso importa quando você compra bitcoin

A manchete honesta é que as soft forks são a razão pela qual as atualizações do bitcoin nunca custaram nada aos detentores comuns.

Não há migração, nem prazo final, nem anúncio que você possa perder. Bitcoins que estão em um endereço P2PKH criado em 2013 são gastáveis hoje pela mesma chave com o mesmo software, e toda soft fork desde então teve o cuidado de manter isso assim. Compare com qualquer outra plataforma financeira que você use, e essa é a propriedade mais subestimada do sistema.

O que você nota é o atraso, e ele aparece nas bordas. O protocolo ativa um novo tipo de saída; as carteiras levam um ano para torná-lo padrão; as corretoras levam mais tempo para permitir que você saque para ele; algumas nunca permitem. Entre as corretoras que este site analisa, o suporte para envio a endereços bech32 já é rotina, enquanto o suporte para destinos Taproot bech32m ainda é irregular, o que representa um atraso de quatro anos em uma mudança que era lei de consenso desde o primeiro dia. Essa lacuna, e não o protocolo, é o que decide se você pode de fato usar um novo recurso.

A regra prática que decorre disso é simples. Mantenha um endereço de um tipo mais antigo disponível para plataformas que não se atualizaram, e verifique a tela de saque antes de supor que um formato funciona. Um endereço de saque rejeitado é incômodo; um chamado ao suporte sobre um que foi aceito e depois falhou é pior.

Pay to script hash, a soft fork que tornou a multiassinatura utilizável

O P2SH é a soft fork mais antiga que vale a pena estudar, porque mostra o padrão em miniatura.

Antes de abril de 2012, pagar para um arranjo multiassinatura significava que o pagador tinha que colocar o script inteiro na saída em que depositava os fundos. Isso tornava o remetente responsável pela política de segurança de outra pessoa, produzia saídas enormes e tornava impossível um endereço impresso ou falado. O BIP-16 substituiu tudo isso por um hash de 20 bytes do script, envolto em um endereço que começa com o dígito 3.

Para um nó que roda as regras antigas, o script de saída é uma comparação de hash que tem sucesso quando quem gasta envia dados correspondentes. Para um nó que roda as regras novas, esses dados enviados são então executados como um script e eles mesmos precisam ser satisfeitos. A nova regra é estritamente mais forte, então os nós antigos aceitam todo gasto novo válido, que é a definição de uma soft fork.

A ativação foi confusa de um modo que se repetiu desde então. Uma proposta concorrente, o BIP-17, dividiu a opinião dos desenvolvedores; o prazo escorregou de 1º de fevereiro para 1º de abril de 2012; e os mineradores sinalizaram apoio escrevendo a string "/P2SH/" nos blocos que mineravam. Quase todo endereço existente que começa com 3, incluindo os que as corretoras entregam para depósitos, descende daquela discussão.

Soft fork vs BIP

Um BIP é um documento; uma soft fork é uma regra que os nós fazem cumprir. O BIP-341 é um arquivo de texto em um repositório do GitHub que qualquer um poderia ter escrito, enquanto o Taproot é o que se tornou lei de consenso no bloco 709.632, em 14 de novembro de 2021. A distinção importa porque a maioria dos BIPs nunca é ativada, entre eles o BIP-17 e as propostas de covenant, e porque uma única soft fork muitas vezes abrange vários documentos ao mesmo tempo, como o SegWit fez com o BIP-141, o BIP-143, o BIP-144 e o BIP-147. Dizer um número de BIP quando você quer dizer uma regra ativada é inofensivo em uma conversa e enganoso quando você tenta descobrir o que seu nó de fato faz cumprir.