Atualização do Taproot: Usuários de Bitcoin se concentram no plano de ativação, data ainda a ser definida

Muitos dos stakeholders mais ativos do Bitcoin já definiram o método de ativação do Taproot, a maior atualização do software do Bitcoin em anos.

Em uma reunião pública no Internet Relay Chat (IRC) na terça-feira, desenvolvedores, mineradores, profissionais de negócios e entusiastas do Bitcoin discutiram os detalhes de como empacotar a atualização do Taproot em uma atualização — e como ativá-la depois que o código for enviado.

Os mais ativos dos cerca de 200 participantes do chat (a maioria, mas não todos, desenvolvedores) pareciam concordar com a Proposta de Melhoria do Bitcoin (BIP) que seria usada para ativar o Taproot. Para preparar o BIP para envio, eles também votaram para “mesclar” duas “pull requests” (PRs) no GitHub que descrevem as regras para a lógica de ativação do Taproot no código-fonte do Bitcoin quando chegar a hora de enviar a atualização.

Leia Mais: Como a atualização Taproot do Bitcoin melhorará a Tecnologia em toda a pilha de software do Bitcoin

Um destes, RP #1021, inclui uma medida para permitir que os usuários forcem a ativação da atualização caso os mineradores não a suportem, enquantoRP #1020 apenas “recomenda” essa força, mas não a habilita por padrão. Como a maioria dos participantes suporta o BIP 8 sem ativação forçada, como o líder da reunião e desenvolvedor do Bitcoin CORE Michael Folkson observou no chat, discussões posteriores apontarão uma data para começar a ativação – e discutirão ainda mais até que ponto um “dia de bandeira” para forçar a ativação é necessário.

Por que um dia de bandeira Taproot (provavelmente) T é necessário

Não que os mineradores que bloqueiam a atualização devam ser um problema para a Taproot, que tem cerca de 91% de suporte de mineradores,de acordo com uma pesquisa dirigido pelo vice-presidente da Poolin, Alejandro De La Torre.

A pesquisa fornece feedback crucial de mineradores para a organização descentralizada do Bitcoin, que não pode coordenar unilateralmente atualizações da maneira que um provedor de software centralizado pode. Atualizações como a Taproot exigem coordenação meticulosa entre mineradores, usuários de full-node (aqueles que executam o código-fonte aberto do Bitcoin) e outras partes interessadas para garantir que nada dê errado (como introduzir um bug ou dividir a rede Bitcoin em duas versões incompatíveis).

Como os mineradores não demonstraram resistência ao Taproot, a maioria dos participantes expressou preferência pelo BIP8 (falso), com o (falso) se referindo à exclusão de um “dia de sinalização” para forçar a ativação por meio de nós completos caso a atualização falhe devido à falta de ativação do minerador.

O BIP8, como atualmente concebido, daria aos mineradores de Bitcoin e operadores de full-node um ano para adotar a atualização, após o qual a atualização seria "bloqueada" com suporte suficiente. Em uma versão disso, BIP8 (falso), a atualização simplesmente falha sem suporte suficiente. Em outra, BIP8 (verdadeiro), um "dia de bandeira" forçaria os mineradores a sinalizar a atualização quando o prazo de ativação expirasse, caso não o fizessem antes.

Leia Mais: Todos os principais pools de mineração agora oferecem suporte ao Taproot, a maior atualização do Bitcoin em anos

Nota técnica: Existem algumas maneiras de atualizar o Bitcoin, a mais fácil é por meio da ativação do minerador, onde os pools de mineração atualizam e começam a minerar blocos sob as novas regras. Caso contrário, os operadores de nó podem atualizar e escolher rejeitar blocos de mineradores que não sinalizaram suporte para uma atualização. Este chamado “soft fork de ativação do usuário” (UASF), quasey usado para ativar o SegWit, forçaria os mineradores resistentes a adotar a nova atualização.

“Completamente anedótico, mas eu não viqualquer [ênfase deles] oposição ao Taproot,” disse um willcl_ark no chat, referindo-se à necessidade ou não de um dia de bandeira. “Acho que usar o menor denominador comum de parâmetros de ativação (falso) parece ser a escolha sensata para evitar quaisquer divisões de cadeia propositais ou acidentais no caso de os mineradores T sinalizarem.”

Qual é o problema?

Outros ainda, como o prolífico desenvolvedor do Bitcoin CORE Luke Dashjr, não estão convencidos de que a inclusão de um dia de bandeira seja desnecessária. Na verdade, é uma questão de princípio demonstrar que os operadores de nós decidem o software, não os mineradores.

“T importa”, ele disse no chat em referência ao suporte ao minerador. “Os mineradores não decidem mudanças de protocolo”, ele continuou, insinuando que são os operadores de nó que decidem, escolhendo qual software executar. Além disso, ele defendeu que o BIP8 (falso) “deixa os mineradores decidirem” o destino da atualização. Quando chegar a hora, ele disse mais tarde no chat, ele configurará seu nó para executar a versão BIP8 (verdadeiro) que rejeita blocos não Taproot dos mineradores.

“O BIP8 com [ativação] obrigatória não é uma demonstração desnecessária de força”, disse hsjoberg, reiterando a crença de Dashjr de que a escolha do usuário de um UASF é um controle e equilíbrio necessários sobre a apatia dos mineradores.

Leia Mais: UASF revisitado: a revolta dos usuários do Bitcoin deixará um legado duradouro?

Ainda assim, uma demonstração de força poderia introduzir riscos desnecessários e estabelecer um precedente indesejado para futuras deliberações de atualizações, especialmente quando os mineradores não deram aos usuários nenhuma razão para serem combativos, assim são os argumentos a favor do BIP8 (falso).

“[BIP8 false] é mais seguro que [true], então vale a pena fazer [false] primeiro, já que sabemos que o poder de hash já é ~90% pró-Taproot”, disse o desenvolvedor do Bitcoin CORE e CoinSwap, Chris Belcher.

Outros, como Suredbits e o desenvolvedor do Bitcoin CORE, Ben Carman, apontaram que você poderia configurar a atualização mais tarde na ativação para incluir o dia da bandeira caso os mineradores não sinalizem, "tornando mais seguro e fácil para os usuários aplicarem o UASF".

No final da reunião, os participantes concordaram em mesclar pull requests no GitHub para uma rota de ativação não forçada (PR #1020) e uma rota de ativação forçada (PR #1021). Com ambas as regras no GitHub do Bitcoin Core, as regras para uma ativação forçada poderiam ser usadas somente se necessário.

Mais deliberação

O cenário de divisão de cadeia que willcl_ark descreveu é basicamente o bicho-papão que todos querem evitar aqui. O medo é que o BIP8 (true) exija 100% do hashrate para sinalizar a atualização após o término do prazo de ativação do Taproot. Portanto, se usuários suficientes seguirem esse caminho ao mesmo tempo em que outros usam o BIP8 (false) para ativação não forçada (que requer apenas 95% do hashrate), as duas versões de código diferentes podem criar dois históricos incompatíveis do livro-razão de transações do Bitcoin.

É por isso que, se a sinalização forçada tiver que acontecer, é melhor fazê-lo por meio do PR #1021 de AJ Townes, que "torna mais seguro para a opção UASF, que é o cenário mais 'perigoso'", escreveu Carman no chat.

Por enquanto, parece que os envolvidos nas discussões são a favor do BIP8 (falso) com a adição de um UASF por meio do PR #1021, se necessário, mas mais discussões são necessárias para definir o cronograma exato do período de ativação inicial (ou quanto tempo os usuários têm para atualizar após a atualização entrar no ar), bem como qual data de ativação definir.

Esses “e se” e “quando” serão discutidos, entre outros assuntos, em uma reunião em 16 de fevereiro.