O que é a linguagem de script do Bitcoin?

O Bitcoin Script é a linguagem de programação que controla todas as transações na rede Bitcoin. Trata-se de uma linguagem simples, baseada em pilha, que define as condições exatas sob as quais os bitcoins podem ser gastos, e todos os nós completos da rede a executam sempre que uma transação é validada. Sem ela, o Bitcoin seria um livro-razão de números, sem nenhum mecanismo para determinar quem é o proprietário de cada valor.

A maioria dos usuários nunca vê a linguagem de script do Bitcoin diretamente. Suas carteiras lidam com isso de forma invisível. Mas toda vez que você envia ou recebe BTC, dois pequenos programas são executados simultaneamente em milhares de computadores, verificando se as condições de gasto foram atendidas. Entender como isso funciona explica muito sobre por que o Bitcoin é estruturado dessa forma e o que ele pode ou não fazer em comparação com plataformas como o Ethereum.

Este artigo aborda o funcionamento do Bitcoin Script, apresenta os principais tipos de transações que ele possibilita, explica a atualização Taproot que modernizou a camada de script em 2021 e analisa a situação atual do debate sobre o opcode “covenant” em junho de 2026.

Gerencie seus Bitcoins com segurança por meio da custódia própria Aplicativo Bitcoin.com Wallet.

Pontos principais

• O Bitcoin Script é uma linguagem de programação baseada em pilha, integrada ao protocolo Bitcoin, que define as condições sob as quais qualquer saída de bitcoin pode ser gasta.
• Toda transação de Bitcoin inclui dois scripts: um script de bloqueio (ScriptPubKey), definido pelo destinatário, e um script de desbloqueio (ScriptSig), fornecido pelo remetente. Ambos devem ser executados com sucesso para que a transação seja válida.
• O Bitcoin Script não é, intencionalmente, Turing-completo. Ele não possui loops, não mantém estado persistente entre as execuções e impõe limites rígidos ao tamanho dos scripts. Isso garante que todos os scripts sejam executados até o fim, o que constitui um recurso de segurança, e não uma limitação.
• A linguagem de script evoluiu por meio de cinco formatos principais: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) e Taproot (P2TR), cada um ampliando as possibilidades e, ao mesmo tempo, mantendo a compatibilidade com versões anteriores.
• A atualização Taproot (novembro de 2021) introduziu as assinaturas Schnorr, caminhos de gastos baseados em MAST para garantir a privacidade e o Tapscript, uma linguagem de script atualizada com um mecanismo integrado para facilitar futuras atualizações.
• Entre os casos de uso reais desenvolvidos com o Bitcoin Script estão carteiras com assinaturas múltiplas, transações com bloqueio temporal, Contratos com Bloqueio Temporal de Hash (a base da Lightning), serviços de custódia e Contratos de Registro Discreto.
• Ao contrário dos contratos inteligentes do Ethereum, o Bitcoin Script não mantém estado: cada script é executado de forma totalmente isolada, sem ter conhecimento de nenhuma outra transação. Essa é uma escolha arquitetônica deliberada.
• A área mais ativa do desenvolvimento do Bitcoin Script em 2026 é a dos opcodes de covenant, especialmente o OP_CTV (BIP-119) e o OP_CAT (BIP-347), que permitiriam que os scripts definissem como uma transação de gasto deve ser. Nenhum dos dois foi ativado na mainnet até o momento.

O que é o Bitcoin Script?

O Bitcoin Script é uma linguagem de script baseada em pilha e sem estado, integrada ao protocolo Bitcoin. Cada saída de transação na rede Bitcoin contém um script de bloqueio (chamado ScriptPubKey) que especifica as condições para o gasto dos fundos. Qualquer pessoa que queira gastar esses fundos deve fornecer um script de desbloqueio (chamado ScriptSig ou, em transações SegWit e Taproot, os dados de testemunha) que satisfaça essas condições.

A linguagem tem sua estrutura inspirada no Forth, uma linguagem de programação minimalista baseada em pilha, desenvolvida na década de 1960. Assim como o Forth, o Bitcoin Script é lido da esquerda para a direita, opera em uma estrutura de dados chamada pilha e utiliza a Notação Polonesa Inversa (RPN), na qual os operadores vêm após os operandos, em vez de precedê-los. Ele executa uma instrução por vez, não possui loops e não mantém memória persistente entre as execuções.

Esse último ponto é o que a maioria das pessoas percebe primeiro ao aprender sobre o Bitcoin Script do ponto de vista do protocolo: a linguagem não é, intencionalmente, Turing-completa. Uma linguagem Turing-completa pode realizar qualquer cálculo, desde que haja tempo e recursos suficientes. O Bitcoin Script, por definição, não pode fazer isso, e as razões por trás dessa escolha são de grande importância para o funcionamento da rede.

Como funciona o Bitcoin Script: o modelo de pilha

Para entender como o Bitcoin Script funciona, é preciso entender o que é uma pilha. Uma pilha é uma estrutura de dados que opera segundo o princípio “Último a Entrar, Primeiro a Sair” (LIFO). Imagine uma pilha de pratos: só é possível adicionar ou retirar itens pelo topo. No Bitcoin Script, os dados são inseridos na pilha e os opcodes (códigos de operação) manipulam o que estiver no topo.

Quando um nó do Bitcoin valida uma transação, ele executa dois scripts em sequência:

1. O script de desbloqueio (ScriptSig ou testemunha) fornecidos pela pessoa que está gastando as moedas. Isso insere dados na pilha, geralmente uma assinatura digital e uma chave pública.
2. O script de bloqueio (ScriptPubKey) associada à saída que está sendo gasta. Ela contém códigos de operação que atuam sobre os dados da pilha e verificam se as condições de gasto foram atendidas.

Se o script for executado sem erros e deixar um valor diferente de zero (TRUE) na pilha ao final, a transação é válida. Se falhar ou deixar FALSE, a transação é rejeitada pelo nó e nunca chega a ser incluída em um bloco.

Essa execução é totalmente sem estado. O script não tem conhecimento de nenhuma transação anterior, não tem noção dos saldos atuais e não mantém nenhuma memória após o término de sua execução. Cada script é executado do zero, de forma isolada, todas as vezes.

Passo a passo: uma transação P2PKH padrão

Pay-to-Public-Key-Hash (P2PKH) é o tipo original de transação do Bitcoin, em uso desde 2009. Os endereços P2PKH começam com “1”. Veja a seguir como o ScriptPubKey e o ScriptSig se apresentam na prática:

Script de desbloqueio (ScriptSig):

<assinatura> <chave pública>

Script de bloqueio (ScriptPubKey):

OP_DUP OP_HASH160 <hash da chave pública> OP_EQUALVERIFY OP_CHECKSIG

Quando o nó concatena e executa ambos ao mesmo tempo, as operações da pilha ocorrem passo a passo:

• A assinatura e a chave pública do ScriptSig são inseridas na pilha
• OP_DUP duplica a chave pública no topo da pilha
• OP_HASH160 calcula o hash da duplicata (SHA-256 seguido de RIPEMD-160), produzindo um hash de 20 bytes
• O hash da chave pública do script de bloqueio é inserido na pilha
• OP_EQUALVERIFY verifica se os dois hashes coincidem. Caso contrário, a execução é interrompida e a transação falha.
• OP_CHECKSIG verifica se a assinatura é válida para a chave pública

Se todas as etapas forem aprovadas, a pilha termina com TRUE e os fundos são liberados. Todo o processo leva milissegundos e é executado da mesma forma em todos os nós da rede.

Explicação sobre os opcodes do Bitcoin

Os opcodes do Bitcoin são os comandos individuais que compõem um script. Cada um deles ocupa um único byte, o que resulta em 256 slots de opcode possíveis. Desses, cerca de 80 estão ativos atualmente na mainnet. Os demais estão reservados, desativados ou atribuídos ao mecanismo de compatibilidade futura OP_SUCCESS, introduzido com o Tapscript.

Os códigos de operação se enquadram em várias categorias:

• Códigos de operação de inserção de dados inserir valores como chaves públicas, assinaturas e hashes na pilha
• Códigos de operação aritméticos realizar operações de adição, subtração e comparação. Vale ressaltar que a multiplicação e a divisão estão desativadas.
• Códigos de operação criptográficos incluem OP_SHA256, OP_HASH160 e OP_SHA1 para cálculo de hash, e OP_CHECKSIG para verificação de assinatura
• Opcodes de controle de fluxo ativar lógica condicional: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Códigos de operação para manipulação da pilha incluem OP_DUP (duplicar o item do topo), OP_DROP (remover o item do topo) e OP_SWAP (trocar os dois itens do topo)

Vários códigos de operação (opcodes) foram desativados por Satoshi Nakamoto em 2010, após a descoberta de vulnerabilidades em suas implementações originais. Entre eles estão o OP_CAT (concatenar dois itens da pilha), o OP_MUL (multiplicar) e o OP_DIV (dividir). A ausência desses códigos teve consequências duradouras para o que o Bitcoin Script é capaz de expressar, e várias das propostas de atualização do Bitcoin mais debatidas em 2026 envolvem a questão de se alguns deles devem ser reativados.

Para consultar a referência completa de códigos de operação, incluindo valores hexadecimais e descrições, a Página do script do Bitcoin Wiki é a fonte oficial.

Por que a não completude de Turing é uma vantagem

A explicação comum é que o Bitcoin Script não possui loops, portanto, garante-se que os scripts sejam encerrados, o que protege a rede contra a execução infinita. Isso é correto, mas não aborda o ponto na íntegra.

O argumento mais profundo diz respeito à superfície de ataque. Uma linguagem Turing-completa pode expressar cálculos arbitrários. Essa expressividade é também o espaço onde os bugs se alojam. A Solidity, da Ethereum, já gerou algumas das vulnerabilidades de software mais caras da história. O ataque ao DAO em 2016 explorou uma falha de reentrância em um contrato inteligente e causou prejuízos de cerca de US$ 60 milhões aos preços da época, levando, por fim, a um polêmico hard fork da rede Ethereum. O ecossistema mais amplo de DeFi viu centenas de milhões de dólares serem desviados por meio de explorações de contratos inteligentes ao longo de vários anos.

O Bitcoin Script torna esse tipo de ataque estruturalmente impossível. Não é possível escrever um script de Bitcoin que chame outros scripts, entre em um loop até que uma condição mude ou armazene o estado entre transações. Cada script é um programa delimitado, que termina e pode ser inspecionado. O tamanho máximo do script é de 10.000 bytes. O número máximo de opcodes que não sejam “push” por script é 201. Um validador sempre pode calcular o custo de execução no pior cenário antes de executar o script.

Para uma rede que detém centenas de bilhões de dólares em valor, essa previsibilidade vale mais do que a flexibilidade à qual se abre mão. O Ethereum resolve o problema da computação ilimitada por meio de limites de gás, cobrando dos usuários por cada código de operação executado e interrompendo scripts que esgotam o orçamento. Isso funciona, mas traz sua própria complexidade e modos de falha. O Bitcoin contorna o problema por completo, por meio de seu próprio design.

Dito isso, “não ser Turing-completo” não significa “não ser capaz de lidar com lógica complexa”. O Bitcoin Script suporta requisitos de gastos multipartidários, condições baseadas em tempo, revelação de pré-imagens de hash e combinações de todos esses elementos. A Lightning Network, que processa milhões de pagamentos por dia, é construída inteiramente com base em primitivas do Bitcoin Script.

Tipos de script: a evolução do P2PKH para o Taproot

A camada de scripts do Bitcoin evoluiu significativamente desde 2009, com cada atualização introduzindo um novo formato de transação, mantendo-se, ao mesmo tempo, compatível com todas as versões anteriores.

P2PK (Pay-to-Public-Key, 2009)

O formato original, utilizado nas primeiras transações de Bitcoin, incluindo o pagamento de Satoshi a Hal Finney no bloco 170. Os fundos eram vinculados diretamente a uma chave pública completa, em vez de ao seu hash. Hoje em dia, esse formato raramente é usado em novas transações, pois expõe a chave pública na cadeia de blocos antes do gasto, o que é considerado uma postura de segurança mais fraca do que aplicar o hash à chave primeiro.

P2PKH (Pay-to-Public-Key-Hash, 2009)

O formato padrão há mais de uma década. O P2PKH vincula os fundos a um hash da chave pública, em vez da própria chave, mantendo a chave pública privada até o momento do gasto, gerando um endereço mais curto de 20 bytes e servindo de base para todos os endereços que começam com “1”. De acordo com dados on-chain da Unchained (abril de 2026), os endereços P2PKH detêm atualmente aproximadamente 43% do estoque de bitcoins minerados.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Introduzido por meio de um soft fork em 1º de abril de 2012, o P2SH transferiu o ônus dos scripts de gasto complexos do remetente para o destinatário. Em vez de incorporar um script de bloqueio completo na saída, as saídas P2SH se comprometem com um hash de 20 bytes de um “script de resgate”. O script completo só é revelado quando as moedas são gastas. Isso tornou a multisig prática para usuários comuns: uma configuração multisig 2 de 3 não exigia mais que todas as três chaves públicas estivessem visíveis para o remetente no momento do pagamento. Os endereços P2SH começam com “3”.

Para uma explicação detalhada de como funciona a validação do P2SH no nível do protocolo, Guia de transações do developer.bitcoin.org explica passo a passo o mecanismo do script “redeem”.

P2WPKH e P2WSH (SegWit nativo, 2017, BIP 141)

O Segregated Witness, ativado em agosto de 2017 no bloco 481.824, transferiu os dados de assinatura para fora do corpo principal da transação, para uma estrutura de testemunha separada. Os dados da testemunha recebem um desconto de 75% no peso, tornando as transações SegWit significativamente mais baratas. Uma transação P2WPKH padrão com uma entrada e duas saídas pesa aproximadamente 141 bytes virtuais, em comparação com 226 vbytes para a transação P2PKH equivalente, de acordo com Análise dos tipos de endereços de Bitcoin feita pela Spark a partir de março de 2026. O SegWit também corrigiu a maleabilidade das transações, o que era um pré-requisito para a Lightning Network. Os endereços nativos do SegWit começam com “bc1q.”

P2TR (Pay-to-Taproot, 2021, BIPs 340/341/342)

O Taproot foi ativado em novembro de 2021, no bloco 709.632, e é a atualização mais significativa da camada de scripts do Bitcoin desde o SegWit. Ele introduziu as assinaturas Schnorr, um novo tipo de saída com suporte a MAST e o Tapscript como uma linguagem de script atualizada. Os endereços Taproot começam com “bc1p.”

Taproot e Tapscript: como a linguagem de script do Bitcoin mudou em 2021

O Taproot não é uma única alteração. Trata-se de três Propostas de Melhoria do Bitcoin (BIPs) elaboradas em conjunto e ativadas simultaneamente.

BIP 340: Assinaturas Schnorr

O Bitcoin utilizava originalmente o ECDSA (Algoritmo de Assinatura Digital de Curva Elíptica). Satoshi o escolheu, em parte, porque as assinaturas Schnorr estavam protegidas por patente na época. Essa patente expirou em 2008, e o Taproot finalmente incorporou as assinaturas Schnorr ao protocolo.

As assinaturas Schnorr são menores, com 64 bytes, em comparação com os 71 a 73 bytes do ECDSA. Mais importante ainda, elas suportam a agregação de chaves por meio de um esquema chamado MuSig2. A agregação de chaves permite que vários signatários combinem suas chaves e assinaturas individuais em uma única chave e assinatura agregadas, que são indistinguíveis na cadeia de blocos de um pagamento comum com assinatura única. Uma carteira com assinatura múltipla 2 de 3 que realiza transações por meio do caminho de chave cooperativo do Taproot parece idêntica a um pagamento padrão na blockchain. Isso representa um ganho real de privacidade para qualquer pessoa que mantenha bitcoins em um arranjo complexo de custódia.

BIP 341: Pay-to-Taproot e MAST

O P2TR apresenta um novo tipo de saída com duas rotas de gastos:

• A caminho-chave realizar a transação utilizando uma assinatura de Schnorr, empregada quando todas as partes concordam e desejam a opção mais simples e econômica
• A caminho do script utilizar o MAST (Árvore de Sintaxe Abstrata Merkelizada, que é a implementação desse conceito no Taproot)

O MAST permite que uma única saída se vincule a uma árvore de múltiplos scripts de gasto por meio de uma raiz de Merkle. Ao realizar um gasto, apenas a condição específica efetivamente utilizada é revelada na cadeia. Todos os outros caminhos de gasto possíveis na árvore permanecem permanentemente ocultos. Para um usuário que configurou uma política de gastos complexa, digamos: “Posso gastar normalmente, ou dois dos três curadores podem gastar após seis meses, ou uma chave de recuperação pode gastar após dois anos”, apenas o caminho que é efetivamente executado aparece na blockchain.

Em 2024, a participação do Taproot nas transações de Bitcoin havia crescido para cerca de 42%, impulsionada em grande parte pela atividade de inscrição de Ordinals e BRC-20, de acordo com dados da Glassnode citados pela Spark em março de 2026. Desde então, essa participação tem oscilado de acordo com as condições do mercado, mas a infraestrutura já é padrão nas principais carteiras e corretoras. Página temática sobre Taproot da Bitcoin Optech acompanha o desenvolvimento contínuo do protocolo em torno do Taproot.

BIP 342: Tapscript

Tapscript é a linguagem de script atualizada utilizada para transações com script-path no Taproot. Ela compartilha a maioria dos códigos de operação com o Bitcoin Script tradicional, mas apresenta várias alterações significativas:

• OP_CHECKMULTISIG e OP_CHECKMULTISIGVERIFY estão obsoletas. O antigo código de operação multisig apresentava uma peculiaridade que exigia a inserção de um elemento fictício na pilha como solução alternativa. O Tapscript remove essa peculiaridade e a substitui por OP_CHECKSIGADD, que verifica as assinaturas Schnorr uma a uma e acumula uma contagem. Os esquemas de assinatura múltipla com limite tornam-se mais simples e mais baratos de executar.
• Os limites de tamanho dos scripts por folha do MAST foram removidos. Os scripts individuais dentro de um ramo do Taproot podem ter tamanho ilimitado.
• Códigos de operação OP_SUCCESS são a mudança mais voltada para o futuro. No Script legado, encontrar um opcode indefinido faz com que o script falhe. No Tapscript, os opcodes no intervalo OP_SUCCESS fazem com que o script seja executado com sucesso incondicionalmente. Futuros soft forks poderão atribuir um comportamento real a esses códigos de operação, adicionando restrições sobre quando eles serão bem-sucedidos, sem exigir uma nova versão do script ou um ciclo completo de reimplantação em todo o ecossistema. Novos recursos podem ser adicionados à camada de script do Bitcoin de forma mais limpa do que em qualquer momento anterior na história do protocolo.

Miniscript

Juntamente com o Tapscript, um projeto relacionado chamado Miniscript tem se tornado cada vez mais relevante para os desenvolvedores. O Miniscript é uma forma estruturada de escrever um subconjunto do Bitcoin Script que é analisável, combinável e assinável de maneira genérica. Enquanto o Script bruto exige construção manual e é difícil de auditar, os scripts do Miniscript podem ter sua correção verificada automaticamente e ser combinados em políticas maiores. Ele não amplia as capacidades do Script, mas torna o que ele já faz significativamente mais acessível aos desenvolvedores que criam carteiras e ferramentas de custódia.

O que o Bitcoin Script possibilita: casos de uso na vida real

Os seguintes tipos de transação estão ativos hoje na rede principal do Bitcoin, todos baseados em primitivas do Bitcoin Script:

Carteiras com assinatura múltipla (multisig) exigem M de N chaves privadas para autorizar uma transação de saque. O departamento financeiro de uma empresa pode exigir 3 de 5 aprovações para qualquer saque. Um casal pode usar 2 de 2 para poupanças conjuntas. Com o Taproot e a agregação de chaves Schnorr, os gastos multassinatura cooperativos agora são, na cadeia, indistinguíveis das transações padrão de assinatura única.

Transações com bloqueio de tempo Utilize OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, ou CLTV) e OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, ou CSV) para impedir que os fundos sejam movimentados antes de uma determinada altura de bloco ou tempo decorrido. Entre as aplicações estão o planejamento sucessório, cronogramas de aquisição de tokens por funcionários, mecanismos de poupança compulsória e transações com penalidades utilizadas nos canais da Lightning Network.

Contratos com Bloqueio de Tempo por Hash (HTLCs) combinar uma exigência de pré-imagem de hash com um bloqueio temporal. A condição de gasto funciona assim: revele a pré-imagem desse hash antes dessa altura de bloco, ou os fundos retornam ao remetente. Os HTLCs são a primitiva central da Lightning Network, permitindo o roteamento de pagamentos sem necessidade de confiança por meio de cadeias de canais entre partes que não têm relação direta.

Depósito em garantia Esses mecanismos bloqueiam os fundos em um script P2SH ou Taproot, exigindo o consentimento de várias partes antes da liberação, geralmente com um árbitro independente detentor de uma chave de desempate.

Contratos de Registro Discreto (DLCs) utilizar assinaturas do adaptador Schnorr baseadas em oráculo para possibilitar contratos financeiros liquidados com base em dados do mundo real, como feeds de preços ou resultados de eventos, sem que o oráculo precise assumir a custódia de quaisquer fundos. Os DLCs estão em operação na mainnet do Bitcoin e são utilizados para produtos de opções e futuros liquidados em Bitcoin.

Script do Bitcoin x Contratos Inteligentes do Ethereum

Tanto o Bitcoin Script quanto o Solidity do Ethereum definem as condições sob as quais os fundos podem ser movimentados, mas representam escolhas arquitetônicas fundamentalmente diferentes. Vale a pena fazer essa comparação diretamente, pois as diferenças explicam muito sobre as escolhas que cada rede fez.

A principal diferença está na capacidade de manter estado. Os contratos do Ethereum armazenam e modificam dados que persistem entre transações, tornando possíveis protocolos de empréstimo, exchanges descentralizadas, governança na cadeia e padrões de tokens. O Bitcoin Script não possui equivalente. Cada script é executado isoladamente, sem ter conhecimento de nenhuma outra transação.

Essa é uma escolha arquitetônica deliberada, não uma lacuna a ser preenchida. A camada de scripts do Bitcoin foi projetada para uma função específica: garantir o cumprimento das condições para o gasto de bitcoins, de forma previsível e segura, em grande escala. Para essa função, a ausência de estado é um ponto forte. A superfície de ataque é menor, a execução é determinística entre milhões de validadores independentes e não há nenhuma categoria de exploração de contratos inteligentes no nível do protocolo, pois não existem contratos com estado nesse nível.

Os projetos que buscam maior programabilidade sobre a rede Bitcoin a implementam em camadas. A Lightning Network lida com pagamentos. Os protocolos DLC lidam com contratos financeiros referenciados a dados externos. Sistemas de Camada 2, como o Ark e a Liquid Network, atendem a diferentes perfis de escalabilidade. Nada disso requer a modificação do modelo de script da camada base.

O debate sobre o Covenant: o que poderia mudar no Script do Bitcoin

A evolução do Bitcoin Script sempre foi lenta e conservadora. A área de desenvolvimento mais ativa no momento é a dos opcodes de covenant, que são propostas que permitiriam a um script restringir não apenas quem pode gastar uma saída, mas também como a transação resultante deve ser. Trata-se de uma expansão significativa do poder de expressão do Script.

As principais propostas em junho de 2026 são:

• OP_CTV (BIP-119, CheckTemplateVerify), de autoria de Jeremy Rubin, adiciona um único código de operação (opcode) que vincula um UTXO a um modelo de gasto específico e predeterminado, incluindo a versão da transação, o locktime, a contagem de entradas, as sequências, a contagem de saídas e as saídas. Por padrão, ela não é recursiva, é considerada a proposta mais conservadora entre as principais e tem como alvo principal cofres, controle de congestionamento e certas melhorias na Lightning Network. Em abril de 2026, a OP_CTV tinha parâmetros concretos de implantação em discussão, especificando uma janela de sinalização do Speedy Trial, mas ainda não alcançou o amplo consenso da comunidade necessário para sua ativação, de acordo com Análise dos termos do contrato da BlockEden de abril de 2026.
• OP_CAT (BIP-347), proposta por Ethan Heilman e Armin Sabouri, reativaria um código de operação que Satoshi desativou em 2010. O OP_CAT concatena dois itens da pilha, o que é simples na descrição, mas tem amplas implicações. Quando combinado com assinaturas Schnorr, ele permite uma introspecção de transações semelhante à dos “covenants”. Na rede de testes Signet do Bitcoin, o OP_CAT gerou um número significativamente maior de transações de desenvolvedores do que o APO ou o CTV, de acordo com a análise on-chain da sCrypt realizada no final de 2024. O OP_CAT já está ativo na Liquid Network e no Fractal Bitcoin, sem que tenham sido atribuídas a ele quaisquer explorações de vulnerabilidades. O BIP-347 possui um número de proposta oficial e pesquisas ativas por trás dele, mas sua ativação na mainnet requer um consenso da comunidade que ainda não existe.
• LNHANCE reúne OP_CTV com OP_CHECKSIGFROMSTACK (CSFS) e OP_INTERNALKEY, visando melhorias específicas na construção de canais da Lightning Network, incluindo aberturas de canais não interativas e um gerenciamento mais eficiente de canais com múltiplas partes.

Nenhuma dessas propostas havia sido ativada na rede principal do Bitcoin até junho de 2026. As divergências técnicas entre elas são, em grande parte, superáveis. O problema mais complexo é a mecânica de ativação. O processo de soft fork do Bitcoin exige um amplo consenso, e o debate sobre o pacto carrega uma tensão residual de atualizações controversas anteriores. O que fica claro no debate é que a camada de scripts do Bitcoin tem um espaço significativo para crescer dentro de sua estrutura conservadora. A questão que está sendo discutida é a sequência de implementação e o acordo da comunidade, e não se a linguagem de scripts tem futuro.

Conclusão

O Bitcoin Script é a infraestrutura invisível por trás de todas as transações na rede. A maioria dos usuários nunca entra em contato direto com ela. As carteiras criam scripts válidos, os assinam e os transmitem sem nunca expor os mecanismos por trás disso. Mas cada pagamento, cada canal Lightning, cada plano com bloqueio de tempo e cada cofre multisig passa pela mesma linguagem de script do Bitcoin baseada em pilha que foi lançada junto com o protocolo em 2009.

A camada de scripts cresceu consideravelmente desde então, com o P2SH tornando viáveis transações complexas, o SegWit reduzindo as taxas e possibilitando a rede Lightning, e o Taproot trazendo as assinaturas Schnorr, a privacidade baseada em MAST e o design de opcodes compatível com versões futuras do Tapscript. As propostas de covenant atualmente em discussão representam o próximo capítulo em potencial. Se alguma delas será ativada, e em que prazo, permanece uma questão genuinamente em aberto até meados de 2026.

Para entender o Script, não é preciso ser desenvolvedor. É preciso, sim, reconhecer que o conservadorismo do Bitcoin — suas limitações deliberadas, o ritmo lento de atualizações e a não completude de Turing — não constitui uma deficiência. As propriedades que tornam o Bitcoin Script previsível são as mesmas que mantêm a camada de consenso intacta há dezesseis anos.