O Que é SegWit?

Introdução

SegWit, ou Segregated Witness (Testemunha Segregada), foi um dos upgrades mais importantes do protocolo Bitcoin, ativado em 2017. Entender SegWit é fundamental para compreender como Bitcoin evolui, como problemas técnicos são resolvidos, e como melhorias são implementadas sem quebrar compatibilidade. Este guia vai explicar o que é SegWit, como corrige maleabilidade, como permite blocos maiores, e seu impacto no Bitcoin.

Importante: Este é um guia de nível avançado. Assumimos conhecimento básico de transações Bitcoin, scripts, estrutura de blocos, e conceitos técnicos. Se você é iniciante, recomendamos primeiro entender o básico de Bitcoin antes de avançar para este conteúdo técnico sobre SegWit.

Ao final deste guia, você entenderá como SegWit funciona, como corrige maleabilidade de transações, como permite mais transações por bloco, e por que foi um upgrade fundamental para Bitcoin.

O Que É SegWit?

Conceito Básico

SegWit (Segregated Witness) é um upgrade do protocolo Bitcoin que separa dados de assinatura (witness) do corpo principal da transação.

Mudança fundamental:

Antes: Assinaturas ficavam dentro dos inputs da transação
Depois: Assinaturas (witness) são separadas e não contam no tamanho base
Resultado: Mais transações cabem por bloco, correção de maleabilidade

Características:

Soft fork (compatível com versões anteriores)
Não quebra transações antigas
Adiciona novos tipos de transações
Melhora segurança e eficiência

Ativação:

Proposto em BIP 141, 143, 144, 145
Ativado em agosto de 2017 (bloco 481,824)
Soft fork através de sinalização de mineradores

Por Que SegWit Foi Criado?

Problemas que SegWit resolve:

1. Maleabilidade de Transações:

Transações podiam ser alteradas sem invalidar assinatura
ID de transação podia mudar mesmo sendo válida
Problema para Lightning Network e outras aplicações

2. Limite de Tamanho de Bloco:

Bloco de 1 MB era limite rígido
Muitas transações não cabiam
Taxas altas em períodos de congestionamento

3. Otimização de Espaço:

Assinaturas ocupavam espaço significativo
Não precisavam estar no corpo principal
Separação permite otimização

Correção de Maleabilidade

O Que É Maleabilidade?

Maleabilidade de transação é capacidade de alterar ID de transação sem invalidar assinatura.

Problema:

Atacante podia alterar assinatura (serialização)
ID de transação mudava
Transação ainda era válida
Confusão e problemas para aplicações

Exemplo:

Você envia transação
ID é: abc123...
Alguém intercepta e modifica serialização
ID muda para: xyz789...
Transação ainda é válida
Você não sabe qual ID é correto

Como SegWit Corrige Maleabilidade?

Separação de Witness:

Antes (legacy):

Assinatura ficava no ScriptSig dentro do input
ScriptSig era parte do corpo da transação
Podia ser alterado sem invalidar transação
ID de transação era calculado incluindo assinatura

Depois (SegWit):

Assinatura (witness) é separada do corpo
ID de transação é calculado SEM witness
Witness não pode alterar ID de transação
ID é imutável após criação

Fórmula de TXID:

Antes (legacy):

TXID = SHA-256d(transação_completa_incluindo_assinaturas)

Depois (SegWit):

TXID = SHA-256d(transação_sem_witness)
Witness fica separado e não afeta TXID

Resultado:

✅ TXID é imutável
✅ Não pode ser alterado sem invalidar transação
✅ Maleabilidade corrigida
✅ Base para Lightning Network

Comparação: Antes vs Depois

Antes (legacy):

Transação:
  - Inputs:
      - ScriptSig (com assinatura) ← Parte do TXID
  - Outputs
  - Locktime

TXID = hash de tudo incluindo assinaturas
Problema: Assinatura pode ser alterada, TXID muda

Depois (SegWit):

Transação:
  - Inputs:
      - ScriptSig (vazio ou minimal)
  - Outputs
  - Locktime

Witness (separado):
  - Assinaturas dos inputs

TXID = hash de transação SEM witness
Solução: TXID não muda mesmo se witness mudar

Por Que Maleabilidade Era Problema?

Problemas práticos:

1. Lightning Network:

Precisa de TXID estável para funcionar
Maleabilidade quebrava contratos Lightning
SegWit resolve problema fundamental

2. Aplicações:

Aplicações que rastreiam transações
Confusão sobre qual TXID é válido
Problemas de reconciliação

3. Segurança:

Atacante podia criar confusão
Negação de serviço potencial
Redução de confiança

Blocos Maiores: Mais Transações

Como SegWit Permite Mais Transações?

Conceito de Weight Units (WU):

Antes (legacy):

Tamanho máximo: 1 MB (1.000.000 bytes)
Cada byte conta igual
Limite rígido e pequeno

Depois (SegWit):

Limite: 4 milhões de Weight Units (WU)
Dados base: 1 WU por byte
Witness data: 1 WU por 4 bytes
Limite efetivo: ~4 MB para witness + 1 MB base = ~4 MB total

Fórmula simplificada:

Tamanho_Base + (Tamanho_Witness / 4) ≤ 4.000.000 WU

O que isso significa:

Witness data "custa menos" no limite
Mais witness pode ser incluído
Mais transações cabem por bloco
Limite efetivo aumenta

Comparação Prática

Antes (legacy - bloco 1 MB):

Bloco típico:
- Tamanho: 1.000.000 bytes
- Transações médias: ~2.000 transações
- Taxas altas quando congestionado
- Limite rígido

Depois (SegWit - bloco 4 MWU):

Bloco típico com SegWit:
- Weight: ~4.000.000 WU
- Tamanho equivalente: ~1.3-2 MB (dependendo de mix)
- Transações médias: ~3.000-4.000 transações
- Mais capacidade, taxas menores
- Limite flexível baseado em weight

Aumento de capacidade:

Aproximadamente 2-3x mais transações
Depende da porcentagem de transações SegWit
Quanto mais SegWit, maior capacidade

Exemplos de Cálculo

Exemplo 1: Transação Legacy:

Tamanho base: 250 bytes
Witness: 0 bytes (não tem, é legacy)
Weight = 250 × 4 = 1000 WU

Contribui 250 bytes para limite de 4 MWU

Exemplo 2: Transação SegWit P2WPKH:

Tamanho base: 100 bytes
Witness: 108 bytes
Weight = 100 × 4 + 108 = 400 + 108 = 508 WU

Mas ocupa apenas ~150 bytes efetivos no limite!

Vantagem SegWit:

Transação SegWit ocupa menos espaço no limite
Permite mais transações por bloco
Mais eficiente

Limite de Bloco Efetivo

Cálculo simplificado:

Se bloco tem apenas transações legacy:

Limite: 1 MB (como antes)
Nenhuma melhoria

Se bloco tem apenas transações SegWit:

Limite: ~4 MB (witness separado)
Máxima eficiência

Bloco real (mix):

Geralmente ~1.5-2.5 MB efetivos
Depende de porcentagem de SegWit
Melhoria significativa mesmo com mix

Fórmula aproximada:

Tamanho_Efetivo ≈ 1 MB + (Porcentagem_SegWit × 3 MB)

Exemplo: Se 50% transações são SegWit:

Tamanho_Efetivo ≈ 1 + (0.5 × 3) = 2.5 MB

Impacto do SegWit

Impacto Técnico

1. Correção de Maleabilidade:

✅ TXID imutável
✅ Base para Lightning Network
✅ Melhor para aplicações

2. Capacidade Aumentada:

✅ ~2-3x mais transações por bloco
✅ Taxas menores em períodos normais
✅ Melhor throughput

3. Preparação para Upgrades:

✅ Base para Taproot
✅ Permite novos tipos de scripts
✅ Flexibilidade para futuro

Impacto Econômico

1. Taxas:

Taxas médias caíram após SegWit
Mais transações por bloco = menos competição
Economia para usuários

2. Throughput:

Rede processa mais transações
Menos congestionamento
Melhor experiência

3. Adoção:

Adoção gradual ao longo dos anos
Maioria das transações agora usa SegWit
Suporte amplo de carteiras

Impacto na Rede

1. Segurança:

Maleabilidade corrigida
Base mais sólida
Preparação para upgrades

2. Escalabilidade:

Capacidade aumentada
Preparação para crescimento
Melhor para adoção

3. Desenvolvimento:

Permite Lightning Network
Permite outros upgrades
Base para inovação

Tipos de Transações SegWit

P2WPKH (Pay to Witness Public Key Hash)

Estrutura:

Antes (P2PKH legacy):

ScriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: <signature> <publicKey>

Depois (P2WPKH SegWit):

ScriptPubKey: OP_0 <20 bytes: witnessPubKeyHash>
ScriptSig: (vazio)
Witness: <signature> <publicKey>

Vantagens:

Witness separado
TXID imutável
Menor tamanho no limite
Taxas menores

P2WSH (Pay to Witness Script Hash)

Estrutura:

Antes (P2SH legacy):

ScriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
ScriptSig: <redeemScript> <signatures...>

Depois (P2WSH SegWit):

ScriptPubKey: OP_0 <32 bytes: witnessScriptHash>
ScriptSig: (vazio)
Witness: <redeemScript> <signatures...>

Vantagens:

Scripts complexos com witness separado
Multisig mais eficiente
TXID imutável

P2SH-Wrapped SegWit

Compatibilidade:

Estrutura:

ScriptPubKey: OP_HASH160 <hash_do_witness_script> OP_EQUAL (P2SH normal)
ScriptSig: <witness_script>
Witness: <signatures...>

Vantagem:

Endereços começam com "3" (compatíveis com P2SH)
Funciona em carteiras antigas
Transição gradual

Native SegWit (Bech32)

Endereços Bech32:

Começam com "bc1"
Formato mais eficiente
Melhor detecção de erros
Suporte direto a SegWit

Exemplo:

Legacy: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
P2SH: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Native SegWit: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Comparação: Antes vs Depois

Estrutura de Transação

Antes (Legacy):

Transação Legacy:
├── Version
├── Inputs:
│   └── ScriptSig (com assinatura) ← Parte do TXID
├── Outputs:
│   └── ScriptPubKey
└── Locktime

Tamanho: Todos bytes contam igual
Limite: 1 MB rígido
TXID: Calculado com assinaturas (maleável)

Depois (SegWit):

Transação SegWit:
├── Version
├── Marker (0x00)
├── Flag (0x01)
├── Inputs:
│   └── ScriptSig (vazio ou minimal)
├── Outputs:
│   └── ScriptPubKey (OP_0 <hash>)
└── Locktime

Witness (separado):
└── Witness para cada input
    └── Assinaturas

Tamanho: Weight Units (WU)
Limite: 4 MWU (~2-4 MB efetivo)
TXID: Calculado SEM witness (imutável)

Impacto no Tamanho

Comparação de tamanho:

Transação P2PKH:

Legacy:

Tamanho total: ~250 bytes
Todos bytes contam: 250 bytes no limite

SegWit P2WPKH:

Tamanho base: ~100 bytes
Witness: ~108 bytes
Weight: 100×4 + 108 = 508 WU
Equivalente a: ~127 bytes no limite de 4 MWU
Redução: ~50% no limite!

Transação Multisig 2-of-3:

Legacy:

Tamanho total: ~340 bytes
Todos bytes contam: 340 bytes

SegWit P2WSH:

Tamanho base: ~100 bytes
Witness: ~280 bytes
Weight: 100×4 + 280 = 680 WU
Equivalente a: ~170 bytes no limite
Redução: ~50% no limite!

Impacto no Bloco

Bloco Legacy (1 MB):

Tamanho: exatamente 1.000.000 bytes
Transações: ~2.000 transações típicas
Capacidade: limitada e rígida

Bloco SegWit (4 MWU):

Weight: até 4.000.000 WU
Tamanho equivalente: ~1.5-2.5 MB (depende do mix)
Transações: ~3.000-4.000 transações típicas
Capacidade: aumentada e flexível

Melhoria: 2-3x mais capacidade dependendo de adoção de SegWit

Impacto nas Taxas

Antes (Legacy apenas):

Limite rígido de 1 MB
Congestionamento frequente
Taxas altas em picos
~2.000 transações por bloco

Depois (com SegWit):

Limite flexível até ~4 MB
Menos congestionamento
Taxas mais baixas
~3.000-4.000 transações por bloco

Resultado prático:

Taxas médias caíram após SegWit
Mais transações processadas
Melhor experiência para usuários

Soft Fork: Compatibilidade

Por Que Soft Fork?

Soft fork:

Compatível com versões anteriores
Nodes antigos ainda funcionam
Não quebra rede existente
Ativação gradual

Como funciona:

Nodes antigos veem transações SegWit como "qualquer um pode gastar"
Nodes novos validam corretamente
Rede funciona com mix de nodes
Transição gradual possível

Ativação do SegWit

Processo de ativação:

1. Proposta (BIPs):

BIP 141: Definição de SegWit
BIP 143: Validação de witness
BIP 144: Rede e serialização
BIP 145: getblocktemplate

2. Implementação:

Código desenvolvido em Bitcoin Core
Testes extensivos
Revisão pela comunidade

3. Sinalização:

Mineradores sinalizam suporte
Bloco especial marca ativação
Ativa quando maioria sinaliza

4. Ativação:

Bloco 481,824 (agosto 2017)
SegWit ativo a partir deste bloco
Novas transações SegWit possíveis

Compatibilidade

Coexistência:

Transações Legacy:

Continuam funcionando
Nodes antigos ainda validam
Sem mudanças necessárias
Podem coexistir indefinidamente

Transações SegWit:

Novas funcionalidades
Nodes novos validam corretamente
Nodes antigos não validam, mas aceitam
Coexistência possível

Resultado:

✅ Sem quebra de compatibilidade
✅ Transição gradual
✅ Adoção opcional
✅ Rede continua funcionando

Adoção e Status Atual

Taxa de Adoção

Evolução:

2017 (ativação): ~0% de transações SegWit
2018: ~30% de transações
2019: ~50% de transações
2020-2024: ~70-90% de transações
Tendência: Adoção crescente ao longo do tempo

Por que adoção gradual?:

Carteiras precisam atualizar
Usuários precisam migrar
Compatibilidade com legacy permite transição lenta
Processo natural de adoção

Benefícios da Adoção

Para usuários:

Taxas menores
Transações mais rápidas (menos congestionamento)
Melhor experiência
Preparação para Lightning Network

Para rede:

Mais capacidade
Menos congestionamento
Base para upgrades futuros
Maior escalabilidade

Para desenvolvedores:

Maleabilidade corrigida
Base para Lightning Network
Novos tipos de scripts possíveis
Maior flexibilidade

SegWit e Lightning Network

Relação com Lightning

Dependência:

Lightning Network requer SegWit
Maleabilidade corrigida é fundamental
TXID imutável é necessário
Base técnica essencial

Por que necessário?:

Lightning usa contratos que dependem de TXID
Maleabilidade quebraria contratos
SegWit corrige problema fundamental
Permite Lightning funcionar corretamente

Resultado:

SegWit preparou terreno para Lightning
Lightning Network possível após SegWit
Upgrade em conjunto cria mais valor
Ecossistema mais robusto

Limitações e Considerações

Limitações do SegWit

1. Adoção Gradual:

Não todos usam SegWit imediatamente
Benefícios aumentam com adoção
Processo leva tempo

2. Compatibilidade com Legacy:

Carteiras antigas não suportam
Migração necessária
Pode confundir usuários

3. Limite Ainda Existe:

Não remove limite completamente
Apenas aumenta capacidade
Não resolve todos problemas de escalabilidade

Considerações

1. Não É Solução Completa:

SegWit aumenta capacidade, não resolve tudo
Outras soluções ainda necessárias (Lightning, etc.)
Parte de conjunto de melhorias

2. Adoção É Importante:

Benefícios dependem de adoção
Mais adoção = mais benefícios
Incentivos para migrar

3. Base para Futuro:

SegWit prepara para upgrades futuros
Taproot depende de SegWit
Fundação para inovação

Comparação com Outras Soluções

SegWit vs Aumento Direto de Bloco

Aumento direto (hard fork):

Mudaria tamanho máximo diretamente
Requereria hard fork
Mais simples conceitualmente
Mas mais divisivo

SegWit (soft fork):

Aumenta capacidade através de weight
Soft fork (compatível)
Mais complexo, mas seguro
Adoção gradual possível

Vantagem SegWit:

✅ Soft fork (sem divisão)
✅ Corrige maleabilidade
✅ Preparação para futuro
✅ Mais seguro e estável

SegWit vs Taproot

SegWit (2017):

Separa witness
Corrige maleabilidade
Aumenta capacidade
Base para upgrades

Taproot (2021):

Usa SegWit como base
Melhora privacidade
Assinaturas Schnorr
Upgrade complementar

Relação:

SegWit prepara terreno para Taproot
Taproot depende de SegWit
Ambos trabalham juntos
Evolução incremental

Perguntas Frequentes

SegWit aumenta tamanho de bloco?

Tecnicamente não aumenta limite de 1 MB diretamente. Mas permite mais transações através de weight units. Limite efetivo pode ser ~2-4 MB dependendo de mix de transações.

Todas transações precisam usar SegWit?

Não. Transações legacy continuam funcionando. SegWit é opcional. Mas usar SegWit traz benefícios (taxas menores, etc.).

SegWit quebra compatibilidade?

Não. SegWit é soft fork. Transações legacy continuam funcionando. Nodes antigos ainda validam. Compatibilidade total mantida.

Como saber se endereço é SegWit?

Native SegWit (Bech32): começa com "bc1" P2SH-wrapped SegWit: começa com "3" (igual P2SH normal, precisa verificar) Legacy: começa com "1"

SegWit resolve problemas de escalabilidade?

Parcialmente. Aumenta capacidade ~2-3x. Mas não resolve todos problemas. Lightning Network e outras soluções complementam.

Por que nem todos usam SegWit?

Adoção leva tempo. Carteiras precisam atualizar. Usuários precisam migrar. Compatibilidade com legacy permite transição lenta. Processo natural.

Conclusão

SegWit foi upgrade fundamental que corrigiu maleabilidade de transações, aumentou capacidade da rede, e preparou terreno para upgrades futuros como Lightning Network e Taproot. Entender SegWit é entender como Bitcoin evolui de forma compatível e segura.

Os pontos principais que você precisa entender são:

SegWit separa witness do corpo - Assinaturas ficam separadas, não contam no limite base
Corrige maleabilidade - TXID é imutável, base para Lightning Network
Aumenta capacidade - ~2-3x mais transações através de weight units
Soft fork compatível - Não quebra transações antigas, adoção gradual
Preparação para futuro - Base para Taproot e outros upgrades
Impacto significativo - Taxas menores, mais capacidade, melhor experiência

SegWit demonstrou como Bitcoin pode evoluir através de soft forks cuidadosos. Sem quebrar compatibilidade, SegWit trouxe melhorias significativas que beneficiam toda a rede. É exemplo de como upgrades podem ser implementados de forma segura e gradual.

A correção de maleabilidade foi particularmente importante. Permitiu Lightning Network funcionar corretamente, abrindo porta para pagamentos instantâneos e de baixo custo. Sem SegWit, Lightning não seria possível de forma segura.

O aumento de capacidade também foi significativo. Mesmo que não seja solução completa para escalabilidade, aumentou capacidade da rede ~2-3x, reduzindo congestionamento e taxas. Preparou terreno para crescimento futuro.

Se você quer entender como Bitcoin evolui, como upgrades são implementados, ou como problemas técnicos são resolvidos, entender SegWit é essencial. É upgrade fundamental que demonstrou como Bitcoin pode melhorar mantendo compatibilidade e segurança.