BIP 110

Imagine dois operadores de nós a receber o mesmo bloco. Um aceita-o segundo as regras existentes; o outro rejeita-o devido a uma nova restrição. BIP 110 chegava a esse ponto: alteraria a validade dos blocos, não apenas a disposição de retransmitir uma transação ou mantê-la no mempool, a sala de espera local dos pagamentos não confirmados. Na verificação de 2026-10-23, a especificação na versão 1.0.1 tinha o estado Closed, ou seja, encerrada. Um número BIP ou um programa publicado não certifica a adoção pela rede. O registo preserva o documento e a sua história; não muda à distância as regras dos nós. [1] [2]

Cada nova saída tem um scriptPubKey, o script que define as condições para gastar os fundos depois. O projeto permitia no máximo 34 bytes, ou 83 bytes se começasse com OP_RETURN, uma instrução que torna a saída comprovadamente impossível de gastar. Conta-se o script inteiro. Outro limite, de 256 bytes, aplicava-se aos dados individuais de OP_PUSHDATA* e aos argumentos no witness, as informações que acompanham a verificação de um gasto. A inserção do redeemScript, o script revelado das condições, no scriptSig de BIP16 é uma exceção. Os witness scripts e Tapleaf scripts não são, por si, esses argumentos, mas as suas instruções de inserção de dados continuam limitadas. São limites sobre partes concretas, não sobre o tamanho total da transação ou de todo o witness. [1]

A proposta também atingia Taproot, uma forma de expressar condições de gasto. Proibia gastar versões não definidas de witness ou Tapleaf, mas não criar essas saídas. Excluía o annex, um campo adicional, e control blocks acima de 257 bytes, provas demasiado longas de que um script pertence à estrutura comprometida. Tapscript não poderia conter OP_SUCCESS* nem em código não executado, nem executar OP_IF ou OP_NOTIF, independentemente do resultado da condição. Como referência técnica, os formatos definidos incluem P2WPKH, P2WSH, P2TR com versão Tapleaf 0xc0 e P2A com programa 0x4e73, este último apenas com uma pilha witness vazia. São nomes precisos de formatos, não campos que um utilizador comum precise de preencher na carteira. [1]

Um UTXO é uma saída ainda não gasta: um montante concreto com condições de utilização. O projeto isenta as entradas que gastam UTXO confirmados antes da ativação. Isso não dá liberdade às novas saídas da mesma transação. Uma assinatura preparada antecipadamente também não protege uma saída criada apenas durante o período ativo. Para certas construções Taproot pré-assinadas, a especificação admite fundos bloqueados ou perdidos se as restrições invalidarem os caminhos previstos e não restar uma alternativa utilizável. Isto levanta questões para Miniscript, uma ferramenta de construção de condições de gasto, e BitVM, construções para verificar cálculos. Não se pode, portanto, prometer que só o conteúdo não monetário seria afetado. [1] [3]

Um mineiro pode colocar um sinal de apoio no bloco: neste caso, o bit 4 e um limiar de 1109 em 2016 blocos, cerca de 55 por cento. Mas o projeto ia além do sinal voluntário. Se o limiar não fosse atingido antes, exigia sinalização nas alturas 961632–963647, depois LOCKED_IN a partir de 963648 e ACTIVE a partir de 965664, desde que essa cadeia chegasse até lá. A altura é a posição do bloco na cadeia. LOCKED_IN fixa a transição; ACTIVE aplica efetivamente as restrições de dados. O cliente já rejeitaria blocos sem sinal durante a fase obrigatória, pelo que os nós poderiam separar-se antes dos limites de dados. Estes durariam 52416 blocos após a ativação real e depois passariam a EXPIRED, deixando de ser aplicados; não se trata de um ano exato de calendário. [1] [4]

Os defensores queriam reduzir os custos dos nós, a pressão sobre o conjunto UTXO e o conteúdo indesejado, dando prioridade aos pagamentos. Isso explica a intenção, mas não demonstra resultados. Os críticos apontaram efeitos sobre scripts úteis, futuras extensões e o risco de divisão da rede. Os dados também podem ser repartidos: na discussão inicial, Peter Todd mostrou uma transação que continha dessa forma toda a proposta de então. Nem a especificação promete eliminar a esteganografia, isto é, esconder informação dentro de outros dados. Tornar o armazenamento mais caro e impedi-lo por completo são resultados diferentes. Da mesma forma, o receio de responsabilidade legal pelo conteúdo não estabelece, por si só, uma obrigação jurídica concreta. [1] [3]

O registo do PR 2247 descreve uma divisão em 2026-08-08, à altura 961632. A cadeia principal continha um bloco sem o sinal exigido, enquanto OCEAN minerou uma alternativa com sinal. Em 2026-08-09, Murch informou que o ramo minoritário produzira apenas 2 blocos e parara, enquanto o principal avançara mais de 100 blocos. Esse relato deve ser lido com a data e o autor: não é uma reprodução independente do blockchain realizada para este artigo, nem uma descrição do estado atual do ramo minoritário. Também mostra por que uma divisão causada pela sinalização não equivale a chegar a ACTIVE e iniciar as restrições de dados. [5] [6]

O documento passou por Complete, uma especificação concluída, e terminou em Closed. O PR 2245 de encerramento foi integrado em 2026-08-10; o histórico da especificação indica 2026-08-09. As datas correspondem a registos diferentes, não a outra ativação. A versão do cliente v0.4.1 documenta EXPIRED e vbrequired, o campo do modelo de bloco que indica o bit obrigatório de sinalização. A existência desse cliente não significa adoção em Bitcoin Core. Há também test vectors, transações de exemplo com resultados esperados, e testes funcionais. Este artigo não os executa nem verifica a cadeia minoritária atual. Explica a proposta e o seu percurso documentado, sem apresentar um documento histórico como as regras comuns atuais da rede. [7] [1] [4]