Segurança e Privacidade

Riscos reais ao usar carteiras, canais e nós Lightning

Lightning Network

A Lightning melhora a experiência de pagamentos pequenos, mas não remove responsabilidade. Ela troca um problema simples de entender, uma transação on-chain esperando confirmação, por um sistema com canais, estados off-chain, liquidez, invoices, roteamento e serviços auxiliares.

Segurança e privacidade dependem do modo como você usa a rede: carteira custodial, carteira autocustodial assistida ou nó próprio têm riscos diferentes.

Conteúdo

Modelo mental

Não existe "segurança Lightning" como uma coisa só. Existem três perguntas separadas:

Três perguntas de segurança
Pergunta O que está em jogo
Quem controla os fundos? Custodiante, carteira autocustodial ou nó próprio.
Quem observa a blockchain? Sua carteira, seu nó, um servidor remoto ou uma watchtower.
Quem aprende metadados? Custodiante, peers diretos, hops intermediários, recebedor, provedores de liquidez e observadores on-chain.

Para valores pequenos, um pouco de confiança pode ser aceitável. Para valores maiores, você precisa entender exatamente onde confia, o que consegue recuperar e o que pode vazar.

Resumo de ameaças na Lightning: estado antigo de canal, jamming, corrida de tempo em fechamento e dependência da blockchain.
Segurança Lightning depende de protocolo, operação e escolhas de carteira.
Descrição longa do diagrama

O diagrama organiza ameaças comuns em quatro grupos. O primeiro é publicar estado antigo de canal, mitigado por revogação e vigilância on-chain. O segundo é indisponibilidade ou jamming, que prende liquidez e HTLCs. O terceiro é corrida de tempo quando um canal fecha unilateralmente. O quarto é dependência de uma visão correta da blockchain.

Custódia

O maior divisor de risco é custódia.

Riscos por modelo de carteira
Modelo Risco principal Boa prática
Custodial O serviço controla fundos, pagamentos, conta e dados. Use só valores pequenos e entenda que "saldo no app" é crédito contra o custodiante.
Autocustódia assistida Você controla chaves, mas depende de provedores para liquidez, backup, servidor ou canal. Leia documentação de recuperação, taxas, privacidade e dependências do provedor.
Nó próprio Você controla canais e dados, mas assume uptime, backup, liquidez e monitoramento. Comece pequeno, teste recuperação e use uma visão confiável da blockchain.

Custodial pode ser útil para testar a experiência, mas não deve ser confundido com autocustódia. Se o serviço pode congelar, perder ou censurar seu saldo, você não está controlando bitcoin diretamente.

Canais e estados antigos

Um canal Lightning é uma sequência de estados. Cada estado diz como a funding output seria dividida se o canal fechasse naquele momento. Quando um estado novo substitui o anterior, o estado antigo é revogado.

Publicar estado antigo é uma tentativa de fechar o canal com saldo desatualizado. O protocolo pune isso com dados de revogação: a contraparte pode gastar a saída do trapaceiro dentro da janela de reação.

A versão curta "quem trapaceia perde tudo" ajuda como intuição, mas não conte com ela como explicação completa. Na prática, há prazos, mempool, taxas, HTLCs, dust e regras de fechamento. O ponto para iniciantes é: alguém precisa observar a blockchain para reagir a tempo.

Watchtowers

Uma watchtower é um serviço que ajuda a vigiar a blockchain por você. Se a contraparte publica um estado antigo enquanto você está offline, a watchtower pode transmitir a resposta necessária.

Watchtower monitorando a blockchain e reagindo se uma contraparte publica um estado antigo de canal enquanto o usuário está offline.
Watchtower ajuda com vigilância on-chain; ela não é backup de carteira.
Descrição longa do diagrama

O diagrama mostra um usuário offline, uma contraparte tentando publicar uma commitment transaction antiga e uma watchtower observando a blockchain. A watchtower detecta a tentativa e envia uma transação de resposta dentro do período em que ainda é possível punir o estado revogado.

Não confunda funções:

Backups

Backup Lightning não é sempre igual a backup on-chain. Em Bitcoin comum, uma seed pode recuperar chaves e procurar UTXOs na blockchain. Em Lightning, o estado dos canais também importa.

Riscos comuns:

Antes de colocar valor relevante em Lightning, aprenda o processo de recuperação da carteira específica que você usa. Não use frases-semente, backups, macaroons, senhas ou chaves reais em ferramentas públicas ou sites de teste.

Risco on-chain

A Lightning fica fora da blockchain enquanto os canais cooperam. Mas abrir e fechar canal continua sendo Bitcoin on-chain.

Onde a blockchain ainda importa
Situação Risco prático
Abrir canal Paga taxa on-chain e depende de confirmação da funding transaction.
Fechar cooperativamente Normalmente é mais simples, mas ainda precisa taxa e confirmação.
Fechar unilateralmente Pode exigir espera, segunda etapa, resolução de HTLCs e fee bump.
Mempool congestionada Taxas altas podem atrasar abertura, fechamento ou reação urgente.

Por isso é útil entender transações, taxas, mempool, locktime e sequence.

Disponibilidade e liquidez

Nem todo risco é roubo. Alguns riscos são de disponibilidade: pagamento falha, canal fica sem liquidez na direção certa, nó fica offline, HTLCs ficam presos por um tempo, ou uma rota não consegue entregar o valor.

Problemas comuns:

Para usuário comum, isso aparece como "pagamento falhou". Para operador de nó, aparece como necessidade de monitorar canais, peers, rebalanceamento, taxas, uptime e falhas.

Privacidade na prática

A Lightning reduz exposição on-chain porque pagamentos cotidianos não viram uma transação pública cada um. Mas isso não significa anonimato.

Camadas de privacidade na Lightning: blockchain, gossip, peers diretos, hops intermediários, pagador e recebedor.
Cada observador vê uma parte diferente: blockchain, gossip, peer direto, hop ou ponta do pagamento.
Descrição longa do diagrama

O diagrama mostra várias camadas de observação. A blockchain revela abertura e fechamento de canais. O gossip revela canais públicos e políticas. Peers diretos veem conexão, canal e timing. Hops intermediários veem entrada, saída, valor encaminhado e CLTV local. Pagador e recebedor conhecem mais detalhes do pagamento, mas não necessariamente a rota completa.

O roteamento onion limita o que cada intermediário aprende. Um hop não recebe a rota inteira em texto aberto. Mesmo assim, timing, valores, peers diretos, rotas curtas e tentativas repetidas podem vazar pistas.

Quem pode ver o quê

Visibilidade típica por participante
Observador Pode aprender
Custodiante Saldo, pagamentos, recebimentos, horários, conta e dados internos do serviço.
Observador on-chain Abertura e fechamento de canais, valores on-chain, scripts e timing de transações.
Grafo público Canais anunciados, capacidade inicial, node ids, políticas de taxa e CLTV.
Peer direto Que você está conectado, mensagens do canal compartilhado, timing e mudanças naquele canal.
Hop intermediário Peer anterior, próximo peer, valor encaminhado, taxa e prazo CLTV local.
Recebedor Invoice, valor final, timing, preimage revelada e metadados de aplicação.
Provedor de Lightning Address Consultas ao endereço, tentativa de gerar invoice e metadados do domínio/servidor.

Canal privado reduz exposição no gossip, mas não cria invisibilidade perfeita. Routing hints em invoices, peers diretos, probing e padrões de uso ainda podem revelar partes da topologia.

Hábitos prudentes

Resumo

Mapa de dependências conceituais

Antes de ler esta página

Depois desta página

Referências técnicas

Esta página resume riscos para iniciantes. Os detalhes completos estão em:

Com isso, a trilha iniciante fica completa. A próxima etapa natural é revisar a página principal da seção Lightning e ligar melhor os caminhos para iniciantes, técnico e ferramentas.