Se você já abriu uma carteira de Bitcoin e foi solicitado a escolher entre um endereço “Legacy”, “SegWit” ou “Native SegWit” sem nenhuma explicação sobre o que cada um deles significa, essa escolha remonta a uma única atualização realizada em 2017.
SegWit, abreviação de Testemunha segregada, é uma atualização do protocolo Bitcoin ativada em agosto de 2017 que transfere os dados da assinatura digital da estrutura principal da transação para um campo separado chamado “witness”. Essa única mudança arquitetônica reduziu as taxas de transação, corrigiu uma vulnerabilidade de segurança que já existia há anos, conhecida como “maleabilidade de transações”, e criou as condições técnicas para a existência da Lightning Network e do Taproot.
Este artigo aborda o que o SegWit realmente faz, como funciona o sistema de peso de bloco, o que os diferentes tipos de endereço significam para suas taxas e a acirrada batalha política que quase dividiu a rede Bitcoin antes mesmo de sua ativação.
Gerencie seu Bitcoin com o Aplicativo Bitcoin.com Wallet.
Pontos principais
- O SegWit (Segregated Witness) é uma atualização do protocolo Bitcoin ativada em 24 de agosto de 2017, formalmente especificada como BIP 141 e proposta por Pieter Wuille, Eric Lombrozo e Johnson Lau em dezembro de 2015.
- Isso separa os dados da assinatura digital (a “testemunha”) do corpo principal da transação, corrigindo uma vulnerabilidade de segurança chamada maleabilidade da transação e reduzindo o tamanho de cada transação.
- A capacidade do bloco é medida em unidades de peso (WU), e não em bytes. Os dados de testemunha custam 1 WU por byte, contra 4 WU por byte para outros dados, o que confere às transações SegWit um desconto de 75% no tamanho da assinatura.
- O SegWit nativo (endereços bc1q) reduz o tamanho de uma transação padrão de ~226 vbytes para ~141 vbytes, diminuindo as taxas em cerca de 38% em comparação com os endereços tradicionais.
- A garantia de TXID fixo do SegWit foi a pré-condição técnica para a Rede Lightning. Sem ela, os canais de pagamento não poderiam ser criados com segurança.
- Seu sistema de controle de versão de scripts possibilitou a implementação do Taproot (SegWit V1, ativado em 2021) e oferece uma estrutura para futuras atualizações do Bitcoin sem a necessidade de hard forks.
- Em 2026, aproximadamente 85% das transações de Bitcoin utilizam o SegWit. Trata-se do padrão da rede, e não de um novo recurso.
O que é o SegWit?
O SegWit, ou Segregated Witness, é uma alteração no formato das transações do Bitcoin que separa as assinaturas digitais — a prova criptográfica de que você tem o direito de gastar uma moeda — dos dados principais da transação e as armazena em uma estrutura separada chamada “witness”. Isso torna cada transação menor, permite que mais transações sejam incluídas em cada bloco e elimina uma vulnerabilidade que tornava impossível construir canais de pagamento com segurança sobre a rede Bitcoin.
O nome pode ser explicado de forma simples: “segregated” significa “separado”, e “witness” é o termo criptográfico para os dados de assinatura que comprovam a validade de uma transação. A “witness” responde à pergunta “o proprietário legítimo autorizou isso?”, enquanto o restante dos dados da transação responde “para onde vão os fundos e qual é o valor?”.
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.A atualização foi formalmente definida como a Proposta de Melhoria do Bitcoin 141 (BIP 141) e proposto pelos desenvolvedores do Bitcoin Core Pieter Wuille, Eric Lombrozo e Johnson Lau na conferência Scaling Bitcoin, em dezembro de 2015. Ele foi ativado na rede principal do Bitcoin em 24 de agosto de 2017, no bloco 481.824, como um soft fork, o que significa que era compatível com versões anteriores. Os nós que não haviam sido atualizados ainda podiam validar os dados básicos da transação; os nós atualizados tinham acesso à visão completa, incluindo a testemunha.
Em 2026, aproximadamente 85% de todas as transações de Bitcoin utilizam o SegWit. Não se trata mais de um recurso novo, mas sim do padrão.
Os problemas que o SegWit foi criado para resolver
O SegWit resolveu duas questões distintas que vinham limitando o Bitcoin há anos.
Maleabilidade de transações
Toda transação de Bitcoin possui um identificador único chamado TXID, um hash gerado a partir dos dados da transação. Antes do SegWit, esse hash era calculado com base em toda a transação, incluindo a assinatura.
O problema é o seguinte: uma assinatura criptográfica não pode assinar a si mesma. Isso deixava uma pequena brecha em que qualquer pessoa que retransmitisse sua transação pela rede poderia modificar ligeiramente a assinatura de forma a mantê-la matematicamente válida, mas gerando um TXID diferente. Os fundos ainda eram enviados para o endereço correto e a transação ainda era processada, mas o identificador havia mudado.
Isso não parece ser catastrófico para um simples pagamento. Para protocolos que encadeiam várias transações não confirmadas, porém, é fatal. A Lightning Network, que funciona criando uma série de compromissos de pagamento fora da cadeia que fazem referência a IDs de transações anteriores, não pode operar com segurança se qualquer um desses IDs puder ser alterado antes de serem confirmados. Um TXID mutável significa que a cadeia se rompe, e os fundos podem ficar retidos ou serem roubados.
A maleabilidade das transações também causou prejuízos reais antes de ser corrigida. A corretora Mt. Gox citou esse problema como um fator que contribuiu para seu colapso em 2014, embora os historiadores debatam até que ponto isso foi a causa principal ou apenas uma desculpa para uma má gestão mais profunda.
O SegWit resolveu esse problema removendo completamente as assinaturas do cálculo do TXID. Agora, o identificador é calculado apenas a partir dos campos básicos da transação. Alterar a assinatura não altera mais a identidade da transação.
Bloqueie o congestionamento e o aumento das taxas
Em 2016 e no início de 2017, o Bitcoin processava cerca de 7 transações por segundo. Durante picos de demanda, o acúmulo de transações chegava a dezenas de milhares e as taxas subiam para US$ 50 ou mais por uma transferência padrão. O problema era estrutural: os blocos do Bitcoin tinham um limite de 1 MB, e as assinaturas representavam cerca de 65% do tamanho das transações.
A solução óbvia, que consistia em aumentar o limite do tamanho do bloco, exigia um hard fork, o que significava que todos os nós precisariam se atualizar ou ficariam em uma cadeia incompatível. Os hard forks são de alto risco e controversos. O SegWit encontrou uma maneira de contornar totalmente essa restrição.
Como funciona o SegWit
Separação dos dados das testemunhas
Em uma transação Bitcoin tradicional, cada entrada inclui um campo ScriptSig contendo a assinatura e a chave pública do remetente. Em uma transação SegWit, o campo ScriptSig é deixado em branco para as entradas SegWit. A assinatura e a chave pública são transferidas para um novo campo de testemunha, anexado ao final da transação.
Dois bytes adicionais, um marcador (0x00) e um sinalizador (0x01), indicam aos nós compatíveis com SegWit que os dados de testemunha vêm a seguir. Os nós anteriores ao SegWit simplesmente veem um ScriptSig vazio e processam a transação como válida de acordo com a interpretação mais antiga de que “qualquer um pode gastar”, mantendo a compatibilidade com versões anteriores.
O peso do bloco substitui o tamanho do bloco
O SegWit substituiu o limite de tamanho de bloco de 1 MB por uma nova métrica: o peso do bloco, com um limite máximo de 4 milhões de unidades de peso (WU).
O detalhe fundamental está na forma como os bytes são contados:
- Cada byte de dados de transações sem testemunha custa 4 unidades de peso
- Cada byte de dados de testemunha custa apenas 1 unidade de peso
Como as assinaturas são grandes e agora ficam na seção de testemunhas, elas ocupam um quarto do espaço que ocupavam anteriormente em termos de capacidade do bloco. É assim que o SegWit aumentou o tamanho efetivo do bloco para cerca de 1,7 a 2 MB na prática, sem alterar a regra de 1 MB imposta pelos nós antigos. Para um bloco teoricamente totalmente SegWit, o máximo é de 4 MB, embora isso nunca ocorra na prática, pois cada bloco também contém dados que não são de testemunha.
Bytes virtuais (vBytes): a unidade que você vê nas carteiras
Para manter as taxas de comissão comparáveis às das transações tradicionais, o SegWit introduziu os bytes virtuais (vbytes): unidades de peso divididas por 4. Nas transações tradicionais, bytes e vbytes são idênticos. Nas transações SegWit, os vbytes são menores porque os dados de testemunha descontados reduzem esse número.
As taxas da carteira são expressas em satoshis por vbyte (sat/vB). Uma transação SegWit com menos vbytes paga menos em taxas, mantendo a mesma taxa de sat/vB. Esse é o mecanismo por trás da economia nas taxas que você observa ao usar um endereço bc1q em vez de um endereço 1...
Tipos de endereços SegWit: qual você deve usar?
O SegWit introduziu novos formatos de endereço juntamente com suas mudanças técnicas. O tipo de endereço determina como sua carteira codifica as condições de gasto, o que afeta suas taxas, sua compatibilidade com outras carteiras e a forma como suas transações aparecem na cadeia de blocos.
Comparação entre tipos de endereço
| Tipo de endereço | Prefixo | Codificação | Tamanho típico do Tx (1 entrada, 2 saídas) | Economia de taxas x Sistema antigo | Suporte para carteiras |
|---|---|---|---|---|---|
| Legado (P2PKH) | 1... | Base58 | ~226 vbytes | Linha de base | Universal |
| SegWit aninhado (P2SH-P2WPKH) | 3... | Base58 | ~167 vbytes | ~26% | Muito amplo |
| SegWit nativo (P2WPKH) | bc1q... 42 caracteres | Bech32 | ~141 vbytes | ~38% | Todas as carteiras modernas |
| Multisig nativo do SegWit (P2WSH) | bc1q... 62 caracteres | Bech32 | Varia | ~32%+ | Todas as carteiras modernas |
| Taproot (P2TR) | bc1p... 62 caracteres | Bech32m | ~154 vbytes | ~32% | A maioria das carteiras modernas |
Dados sobre o tamanho das transações: Referência de tamanho de transações de Bitcoin da Spark.money, 2026. A economia nas taxas é aproximada e varia de acordo com as condições do mempool.
Legado (P2PKH, prefixo 1...) É o formato original de 2009. A assinatura permanece dentro do corpo principal da transação, onde tem peso total. Não há economia nas taxas. Ainda é universalmente compatível, o que é a única razão para usá-lo hoje em dia, caso você esteja lidando com softwares muito antigos que não aceitam nenhum outro formato.
SegWit aninhado (P2SH-P2WPKH, prefixo 3...) encaixa um script SegWit dentro de um envelope P2SH mais antigo. Quando o SegWit foi ativado em 2017, nem todas as carteiras e plataformas de câmbio adicionaram imediatamente o suporte ao novo formato bc1. O SegWit aninhado serviu como ponte de compatibilidade: você obtém uma economia parcial nas taxas, e os remetentes que usam softwares mais antigos ainda podem efetuar pagamentos a você. Até 2026, esse formato existe principalmente como uma opção alternativa. O 3... O prefixo é compartilhado com endereços P2SH que não são SegWit, o que significa que não é possível saber, apenas pelo endereço, se se trata de uma transação SegWit.
SegWit nativo (P2WPKH, prefixo bc1q..., 42 caracteres) é a escolha certa para a maioria dos usuários. Ela utiliza a codificação Bech32, que é toda em letras minúsculas, possui melhor detecção de erros do que a Base58 e elimina caracteres que se parecem (sem O maiúsculo, zero, I maiúsculo ou l minúsculo). Uma transação P2WPKH padrão com 1 entrada e 2 saídas ocupa cerca de 141 vbytes, o que representa uma redução de aproximadamente 38% em relação à transação legada equivalente. Todas as carteiras e exchanges ativas oferecem suporte a esse padrão a partir de 2026.
Multisig nativo do SegWit (P2WSH, prefixo bc1q..., 62 caracteres) é a variante script-hash, usada para carteiras com assinatura múltipla e condições complexas de gasto. O endereço mais longo reflete um hash SHA-256 de 32 bytes, em vez do hash de 20 bytes usado pelo P2WPKH. Se você estiver utilizando uma configuração de multisig 2 de 3, o P2WSH é a maneira nativa do SegWit de fazer isso.
Taproot (P2TR, prefixo bc1p..., 62 caracteres) é a versão 1 do SegWit, ativada em 2021. Ela utiliza assinaturas Schnorr em vez de ECDSA, o que permite que múltiplas assinaturas sejam agregadas em uma única, tornando as transações com assinatura múltipla indistinguíveis das transações com assinatura única na cadeia. Ela oferece as taxas mais baixas para gastos com assinatura única e a melhor privacidade. Use-a quando tiver confirmado que seus destinatários e suas carteiras suportam endereços bc1p.
Recomendação rápida
Para a maioria das pessoas: use o SegWit nativo (bc1q). Ele é compatível com praticamente todas as carteiras e plataformas de câmbio ativas, proporciona uma economia de cerca de 38% nas taxas em comparação com o sistema antigo e não apresenta risco de incompatibilidade em 2026 (Para desenvolvedores que estejam integrando o SegWit ao software de carteira, consulte o Guia de desenvolvimento da carteira Bitcoin Core.).
Se sua carteira oferece o Taproot (bc1p) e você estiver realizando transações com assinatura única com destinatários cujas carteiras suportam essa funcionalidade, isso proporciona taxas ligeiramente mais baixas e maior privacidade.
O SegWit aninhado (3...) é uma opção alternativa de compatibilidade. Não há problema nisso, mas não há mais motivo para usá-lo como padrão.
A Guerra do Tamanho do Bloco: Por que o SegWit foi tão polêmico
Os argumentos técnicos a favor do SegWit eram claros. O caminho para sua ativação, porém, não era.
De 2015 a 2017, o Bitcoin se viu envolvido em uma das disputas de governança mais polêmicas de sua história. No fundo, a questão era simples: como uma rede descentralizada deveria atualizar suas próprias regras quando diferentes facções têm interesses conflitantes?
O impasse na mineração
De acordo com o processo padrão de atualização do BIP9, um soft fork exigia que 95% dos mineradores manifestassem apoio em um prazo de duas semanas. No início de 2017, o SegWit já estava pronto para ser ativado há meses, mas continuava abaixo desse limite.
A oposição mais significativa veio das grandes empresas de mineração, especialmente da Bitmain, que na época controlava uma parcela substancial do hashrate do Bitcoin. O motivo ficou claro posteriormente: a Bitmain utilizava uma técnica patenteada chamada ASICBoost, uma otimização que conferia ao seu hardware de mineração uma vantagem significativa em termos de eficiência. O SegWit era estruturalmente incompatível com o ASICBoost oculto. Bloquear o SegWit protegia essa vantagem.
BIP 148 e o UASF
Em março de 2017, um desenvolvedor anônimo que usava o pseudônimo Shaolinfry publicou o BIP 148: um soft fork ativado pelo usuário (UASF). Em vez de aguardar o sinal dos mineradores, o BIP 148 propôs que os nós econômicos — ou seja, corretoras, processadores de pagamentos e empresas que utilizam o software Bitcoin — simplesmente começassem a rejeitar qualquer bloco que não sinalizasse suporte ao SegWit a partir de 1º de agosto de 2017.
A lógica era simples: os mineradores produzem blocos, mas esses só têm valor se a rede os aceitar. Se uma maioria econômica suficiente operasse nós BIP 148, os mineradores teriam que ativar o SegWit ou ver seus blocos serem descartados. O risco era igualmente claro: se a adoção fosse insuficiente, haveria uma divisão da cadeia, com duas versões incompatíveis do Bitcoin operando em paralelo.
A campanha do UASF foi popular e barulhenta. Surgiram crachás de conferências. As discussões no Twitter se intensificaram. A frase “execute seu próprio nó” ganhou um novo sentido de urgência.
O Acordo de Nova York e o Bitcoin Cash
Diante do prazo final do UASF, mais de 50 grandes empresas do setor de Bitcoin se reuniram em Nova York em maio de 2017 e assinaram o que ficou conhecido como o Acordo de Nova York. Elas concordaram em ativar o SegWit, mas também em realizar, em seguida, um hard fork para dobrar o tamanho do bloco para 2 MB (isso ficou conhecido como SegWit2x).
O acordo não satisfez plenamente nenhum dos dois lados. Os desenvolvedores que se opunham a blocos maiores viram o SegWit2x como um hard fork dissimulado com o qual não haviam concordado. Os mineradores e as empresas que queriam blocos maiores ainda não estavam conseguindo o que desejavam originalmente.
Em 1º de agosto de 2017, uma facção que defendia um aumento puro do tamanho do bloco, sem o SegWit, realizou um fork do Bitcoin para criar o Bitcoin Cash (BCH), com um limite inicial de 8 MB por bloco. O SegWit foi ativado no Bitcoin em 24 de agosto de 2017. A bifurcação (hard fork) SegWit2x foi abandonada em novembro de 2017, depois que seus organizadores concluíram que não havia consenso suficiente.
O que foi acordado
O resultado foi significativo para além dos detalhes técnicos. O UASF havia funcionado: foram os nós econômicos, e não os mineradores, que determinaram quais regras de consenso seriam aplicadas. Isso é agora frequentemente citado como uma demonstração de que a governança do Bitcoin recai, em última instância, sobre aqueles que executam e utilizam o software, e não sobre aqueles que produzem blocos. O dia 1º de agosto é conhecido por parte da comunidade como o Dia da Independência do Bitcoin.
O que o SegWit tornou possível
A Lightning Network
A Lightning Network foi projetada antes mesmo da existência do SegWit. Seus criadores sabiam que ela não poderia ser implantada com segurança até que a maleabilidade das transações fosse corrigida, pois os canais de pagamento dependem de cadeias de transações não confirmadas que se referenciam mutuamente por meio do TXID. A garantia de TXID fixo do SegWit tornou esses canais seguros.
A Lightning Network foi lançada na rede principal do Bitcoin no início de 2018, cerca de seis meses após a ativação do SegWit. Até o primeiro trimestre de 2025, ela já havia processado mais de 100 milhões de transações. Sem o SegWit, nenhuma dessas infraestruturas existiria.
Taproot e controle de versão de scripts
O SegWit introduziu o controle de versão do script no formato de transação do Bitcoin. O programa “witness” começa com um byte de versão: o SegWit V0 abrange os esquemas P2WPKH e P2WSH. Qualquer atualização futura que defina um novo número de versão passa a ter suas próprias regras, sem entrar em conflito com as existentes e sem exigir outra disputa acirrada sobre a atualização.
O SegWit V1 é o Taproot, ativado em novembro de 2021. Ele trouxe as assinaturas Schnorr, a estrutura MAST (Merkelized Abstract Syntax Trees) para condições complexas de gasto e melhorias de privacidade que fazem com que as carteiras multisig pareçam idênticas às transações single-sig na cadeia. Todos os recursos técnicos introduzidos pelo Taproot se basearam na arquitetura de versionamento criada pelo SegWit.
Ordinais e inscrições
A mesma estrutura de dados de testemunho introduzida pelo SegWit e ampliada pelo Taproot tornou tecnicamente viável incorporar dados arbitrários — imagens, texto, código — diretamente nas transações de Bitcoin. Esse é o mecanismo por trás do protocolo Ordinals e das inscrições no Bitcoin, o que impulsionou um aumento no uso de dados na cadeia e elevou a adoção do Taproot para aproximadamente 42% das transações em 2024. À medida que a atividade de inscrições diminuiu, o uso do Taproot estabilizou-se em cerca de 20% das transações no final de 2025, enquanto o SegWit V0 continua sendo o formato dominante, com cerca de 85%.
SegWit no contexto: cronograma de atualizações do Bitcoin
| Ano | Evento |
|---|---|
| 2015 | Pieter Wuille apresenta o conceito do SegWit na conferência Scaling Bitcoin |
| 2016 | O BIP 141 foi publicado formalmente; a adesão dos mineradores estagnou abaixo do limite de 95% |
| Março de 2017 | BIP 148 (UASF), publicado por Shaolinfry |
| Maio de 2017 | Acordo de Nova York assinado por mais de 50 empresas |
| 1º de agosto de 2017 | O Bitcoin Cash é um fork do Bitcoin |
| 24 de agosto de 2017 | O SegWit é ativado na rede Bitcoin no bloco 481.824 |
| Novembro de 2017 | O hard fork do SegWit2x foi abandonado |
| Janeiro de 2018 | A Lightning Network é lançada na rede principal |
| Novembro de 2021 | O Taproot é ativado, com base no sistema de versões do SegWit |
| 2023-2024 | Os ordinais e as inscrições utilizam o espaço de testemunha do SegWit/Taproot |
| 2026 | Aproximadamente 85% das transações de Bitcoin utilizam o SegWit |
Adoção atual
A adoção do SegWit cresceu de forma constante após a ativação, atingindo 30% das transações nos primeiros meses e, em seguida, ultrapassando a marca de 50% nos dois anos seguintes, à medida que carteiras e corretoras atualizavam seus softwares.
Em 2026, aproximadamente 85% das transações de Bitcoin utilizavam o SegWit (fonte: Estatísticas da Rede Bitcoin da Spark.money, CoinGecko). Os 15% restantes são transações antigas provenientes de carteiras e serviços que ainda não foram atualizados. A adoção do Taproot (P2TR, SegWit V1) atingiu um pico de cerca de 42% das transações em 2024, impulsionada em grande parte pela atividade de inscrição de Ordinals, antes de se estabilizar em torno de 20% no final de 2025, à medida que o volume de inscrições diminuiu.
A curva de adoção reflete o que ocorreu com o próprio SegWit: os novos formatos de endereço levam de um a três anos para alcançar a adoção generalizada, à medida que carteiras de hardware, corretoras e processadores de pagamentos atualizam seus softwares. O suporte ao Taproot continua a se expandir nas implementações das carteiras.
SegWit x Legado: Resumo das diferenças
| Destaque | Versão antiga (pré-SegWit) | SegWit |
|---|---|---|
| Local para assinatura | Dentro do ScriptSig (corpo principal da transação) | Campo separado para testemunhas |
| Métrica do tamanho do bloco | Tamanho em bytes (limite de 1 MB) | Unidades de peso (limite de 4 milhões de WU) |
| Cálculo do TXID | Inclui dados de assinatura | Exclui dados de testemunhas |
| Maleabilidade de transações | Possível | Corrigido |
| Tamanho típico de um transmissor com 1 entrada e 2 saídas | ~226 vbytes | ~141 vbytes (P2WPKH) |
| Economia nas taxas | Linha de base | cerca de 38% menor (P2WPKH em comparação com P2PKH) |
| Suporte à Lightning Network | Inseguro | Obrigatório; habilita canais de pagamento |
| Prefixo de endereço | 1... | bc1q... (nativo) ou 3... (aninhado) |
| Codificação | Base58 | Bech32 |
Conclusão
O SegWit é a atualização do protocolo que separou os dados de assinatura do Bitcoin dos dados de transação, corrigiu uma falha de segurança que existia desde 2009, reduziu as taxas de transação em cerca de um terço e forneceu a base arquitetônica para a Lightning Network, o Taproot e tudo o que foi desenvolvido a partir deles desde então.
Desde 2026, é o padrão de transações do Bitcoin, processando a grande maioria das atividades na cadeia. Os formatos de endereço que ele introduziu, especialmente o SegWit nativo (bc1q), são os que a maioria dos usuários deveria estar usando por padrão atualmente. A batalha política em torno de sua ativação continua sendo um dos capítulos mais instrutivos da história da governança do Bitcoin: uma demonstração de que, em uma rede descentralizada, o consenso não é algo que os mineradores concedem, mas sim algo que os usuários afirmam.
