Segurança e Privacidade a fundo

Ameaças, mitigações e vazamentos reais em canais, roteamento e gossip

Lightning · Técnico

A Lightning reduz a exposição on-chain de pagamentos, mas troca simplicidade por um conjunto novo de riscos: estados revogáveis, janelas de tempo, liquidez presa, falhas de roteamento, metadados de gossip, observação de rede e inferência por tentativas. Segurança aqui não é uma propriedade única; é uma composição de mecanismos em várias camadas.

As fontes primárias desta página são a BOLT 2 para operação de canais, a BOLT 3 para transações e scripts, a BOLT 4 para onion routing e falhas, a BOLT 5 para tratamento on-chain, a BOLT 7 para gossip, a BOLT 8 para transporte e a BOLT 11 para invoices.

Esta página é técnica e defensiva. Ela não ensina a atacar peers. O objetivo é entender superfície de risco, limites reais e mitigações para operar e implementar com menos surpresa.

Conteúdo

Modelo de ameaça

Antes de falar em mitigação, defina o que você está protegendo. Um usuário de carteira móvel, um roteador público com muitos canais e um comerciante recebendo invoices repetidas não têm o mesmo risco.

para analisar uma ameaça Lightning:

1. identificar o ativo:
   - fundos no canal
   - liquidez
   - privacidade da rota
   - disponibilidade
   - reputação do node id
2. identificar o adversário:
   - contraparte do canal
   - hop intermediário
   - pagador
   - recebedor
   - observador on-chain
   - observador de rede
3. mapear o mecanismo:
   - revogação e penalty
   - CLTV/CSV
   - onion routing
   - gossip assinado
   - transporte Noise
   - políticas locais
4. listar o vazamento residual:
   - timing
   - valor
   - IP ou conexão
   - funding output
   - falhas e retries
5. decidir mitigação operacional

Essa lista força uma separação importante: segurança de fundos, disponibilidade de liquidez e privacidade são problemas diferentes. Um mecanismo pode melhorar um e piorar outro. Por exemplo, canal público melhora roteabilidade, mas aumenta exposição no gossip. Probing melhora chance de entrega, mas vaza informação de liquidez.

Matriz de ameaças

A tabela abaixo liga ameaças a mecanismos reais do protocolo. Nem toda mitigação é puramente normativa; algumas são política local de implementação.

Ameaça, adversário, mecanismo e risco residual
Ameaça Adversário típico Mitigação principal Fonte Risco residual
Estado revogado contraparte do canal Revogação, to_self_delay, penalty path e monitoramento on-chain. BOLT 3, BOLT 5 Você precisa detectar a transação antes da janela expirar.
Fechamento unilateral em mempool cara contraparte ausente, congestionamento ou pinning Anchor outputs, CPFP/RBF quando aplicável e política de fee bump. BOLT 3, BOLT 5 Taxas extremas e pinning ainda podem atrasar resolução.
Eclipse do nó Bitcoin atacante de rede Bitcoin Nó Bitcoin próprio, conexões diversas, monitoramento de blocos e cuidado com reorgs. BOLT 5 Se o nó só vê uma cadeia falsa, pode reagir tarde.
Channel jamming pagador ou roteador malicioso max_accepted_htlcs, limites de valor em voo, CLTV, reputação e propostas de custo por tentativa. BOLT 2, BOLT 4 O protocolo base ainda tem superfície de DoS por HTLCs presos.
Probing de liquidez origem tentando mapear canais Onion failures limitados, payment_secret, políticas de retry e privacidade operacional. BOLT 4, BOLT 11 Hops intermediários ainda podem ter liquidez inferida por tentativas.
Gossip falso ou antigo peer tentando poluir o grafo Assinaturas, chain_hash, SCID, funding output, timestamps e poda local. BOLT 7 Visões locais podem ficar desatualizadas ou divergentes.
Inspeção de tráfego peer-to-peer observador de rede ou peer direto Transporte Noise autenticado e cifrado. BOLT 8 Metadados de IP, timing, volume e conexões ainda podem vazar.
Resumo de ameaças da Lightning e mitigações: estado revogado, jamming, corrida de tempo em fechamento e eclipse.
A segurança da Lightning depende de protocolo, políticas locais e operação on-chain.
Descrição longa do diagrama

O diagrama organiza quatro classes de ameaça. Estado revogado é mitigado por revogação, penalty e watchtower. Channel jamming é mitigado por limites de HTLC, reputação e custos de tentativa. Corrida de tempo em fechamento depende de CLTV, anchors e fee bump. Eclipse depende de conexão confiável com a blockchain e diversidade de peers Bitcoin.

Segurança on-chain

Um canal Lightning é off-chain enquanto tudo coopera. A garantia de segurança vem do fato de que qualquer lado pode cair de volta para a blockchain. Por isso, a segurança do canal depende de transações Bitcoin, Script, locktime, sequence/CSV, taxas e observação da blockchain.

A BOLT 5 descreve três finais para um canal: fechamento cooperativo, fechamento unilateral e fechamento com transação revogada. A diferença operacional é enorme.

Cenários on-chain de encerramento
Caso Risco Resposta esperada
Mutual close Baixo conflito; revela encerramento e outputs finais. Usar fee adequada, scripts corretos em shutdown e esperar confirmação.
Unilateral close to_local atrasado, HTLCs podem exigir segunda etapa e fee bump. Monitorar outputs, resolver HTLCs, usar anchors/CPFP quando disponível.
Revoked close Contraparte tenta publicar commitment antiga favorável a ela. Detectar gasto da funding output, usar dados de revogação e transmitir penalty transaction.
Reorg Uma resolução aparentemente confirmada pode desaparecer. Continuar monitorando até outputs ficarem irrevogavelmente resolvidos.

O ponto crítico é que um nó com fundos em risco precisa monitorar outputs até estarem resolvidos. Se a contraparte publica uma commitment antiga, a defesa só funciona se você detectar a transação e gastar o caminho de revogação dentro do tempo. Watchtowers existem para delegar essa vigilância quando o usuário está offline.

Backup não é watchtower. Backup ajuda recuperar dados operacionais; watchtower observa a cadeia e reage a uma publicação maliciosa. Restaurar estado antigo sem entender o modelo da implementação pode ser perigoso.

Linha do tempo de resolução on-chain (BOLT 5)

Os cenários da tabela escondem uma questão de tempo, e é aí que o risco residual realmente mora. A BOLT 5 é explícita sobre quando um output está seguro e sobre corridas que podem custar fundos. Esta seção sintetiza esses prazos; ela não reescreve os mecanismos, apenas mostra quando eles terminam.

Quando um output está de fato resolvido. A BOLT 5 só considera um output irrevogavelmente resolvido quando a transação que o gasta está a pelo menos 100 blocos de profundidade na cadeia de maior trabalho — margem propositalmente muito maior que qualquer fork conhecido. Até lá, o nó precisa continuar monitorando e estar pronto para resolver o mesmo output mais de uma vez se houver reorg. Por isso "confirmou" não é o fim: só profundidade suficiente encerra a vigilância. É esse número que a linha "Reorg" da tabela acima pressupõe.

A segunda etapa do HTLC tem seu próprio atraso. Num fechamento unilateral, resolver um HTLC não é um passo só. Você publica a HTLC-timeout (para um HTLC ofertado que expirou) ou a HTLC-success (para um HTLC recebido cuja preimage você tem) e, depois disso, ainda precisa esperar o atraso CSV do to_self_delay — o mesmo que trava o seu to_local — antes de gastar a saída dessa segunda transação. São dois relógios em série, e a contraparte tem acesso imediato aos fundos dela enquanto você espera os seus.

A corrida que perde dinheiro. O caso perigoso é um HTLC que você encaminhou: recebeu de um lado e ofertou para o outro. Se o HTLC ofertado (a jusante) precisar ser resolvido on-chain, a BOLT 5 obriga a agir antes que o HTLC a montante expire. Se você aprende a preimage on-chain, tem de cumprir (fulfill) o HTLC de entrada imediatamente; se o HTLC ofertado expira sem preimage, você só pode falhar (fail) o de entrada depois que a resolução atingir profundidade razoável. É essa janela — publicar, esperar o CSV, confirmar — que o cltv_expiry_delta de cada hop existe para cobrir. Delta curto demais e a segunda etapa não termina a tempo: você paga a jusante sem conseguir cobrar a montante.

Pinning e a defesa contra ele. O pinning que a matriz cita como risco residual é justamente um adversário prendendo suas transações de resolução na mempool para estourar esses prazos. A BOLT 5 recomenda um security_delay (na ordem de 18 blocos antes da expiração) e, ao atingi-lo, separar cada output revogado em sua própria penalty transaction em vez de uma transação em lote — assim uma delas travada não arrasta as outras junto. É a mesma lógica dos anchor outputs e do fee bump por CPFP: garantir que a transação certa entre em bloco na hora certa.

Esta seção é sobre tempo, não sobre construção. A derivação da chave de revogação e a própria penalty transaction são de Canais de Pagamento (BOLT 3); o ciclo do HTLC off-chain é de Operação de Canais. Aqui o ponto é: quando um output está seguro e quais corridas precisam terminar antes de um prazo.

Disponibilidade e jamming

Nem todo ataque tenta roubar fundos. Alguns tentam tornar canais menos úteis. Channel jamming prende slots de HTLC ou liquidez em voo, degradando a capacidade de rotear pagamentos.

A Lightning tem limites que reduzem a superfície, mas não eliminam o problema no protocolo base:

Vetores de jamming e controles relacionados
Vetor Como funciona Controle
HTLC slots Um canal aceita número limitado de HTLCs simultâneos. max_accepted_htlcs, políticas locais e reputação.
Valor em voo HTLCs prendem liquidez até cumprir, falhar ou expirar. max_htlc_value_in_flight_msat, limites por peer e custo de oportunidade no score.
CLTV longo Timeouts longos prendem liquidez por mais tempo. Limitar expiries aceitos, escolher rotas com custo de tempo e falhar cedo quando inseguro.
Dust exposure Muitos HTLCs pequenos podem ser problemáticos em fechamento on-chain. dust_limit_satoshis, max_dust_htlc_exposure_msat e políticas de valor mínimo.

Mitigações como reputação, custo por tentativa, reservas e scoring são em grande parte políticas de implementação ou propostas em evolução. Não apresente como regra universal dos BOLTs. A base normativa define campos e limites; a política de aceitar, penalizar ou precificar tentativas depende do node.

Camadas de privacidade

A Lightning melhora privacidade em relação a pagamentos on-chain simples porque pagamentos intermediários normalmente não viram transações públicas. Mas "fora da cadeia" não significa "invisível". Cada observador enxerga uma fatia diferente.

Camadas de observação na Lightning: blockchain, gossip, peers diretos, hops intermediários e pontas do pagamento.
Privacidade depende de quem observa: blockchain, gossip, peers, hops ou pontas.
Descrição longa do diagrama

O diagrama mostra várias camadas de visibilidade. Na base, um observador on-chain vê abertura e fechamento de canais. Na camada de gossip, a rede pública vê canais anunciados e políticas. Na camada de roteamento, cada hop vê apenas vizinhos e parâmetros locais do HTLC. Nas pontas, pagador e recebedor conhecem mais detalhes do pagamento, mas não necessariamente a mesma informação.

Quem vê o quê em um pagamento Lightning
Observador Consegue ver Não deveria ver Cuidado
Observador on-chain Funding transactions, force closes, mutual closes, anchors, HTLC transactions e padrões de gasto. Pagamentos off-chain bem-sucedidos que não fecham canal. Abertura e fechamento ainda podem ligar capacidade, tempo e scripts.
Rede de gossip channel_announcement, channel_update, node_announcement, capacidade pública inicial e políticas. Saldo local/remoto atual de cada canal. Routing hints, probing e comportamento podem revelar partes privadas.
Peer direto Node id conectado, IP/circuito de rede, mensagens de canal daquele peer e timing. Rota onion completa de pagamentos que ele só encaminha. O peer sabe muito sobre os canais que divide com você.
Hop intermediário Canal de entrada, canal de saída, valor recebido, valor encaminhado e CLTV de entrada/saída. Origem real, destino real, tamanho total da rota e posição exata. Timing, valores incomuns e colusão entre hops reduzem privacidade.
Primeiro hop O peer anterior que enviou o HTLC e o próximo canal. Se o peer anterior é origem real ou outro roteador. Em pagamentos de carteira comum, o primeiro hop frequentemente é um canal direto do pagador.
Último hop Que está entregando ao destino e o valor final. Origem real. Pode correlacionar tentativas repetidas e metadados da invoice.
Recebedor Valor recebido, invoice usada, payment_secret, metadata se existir e timing de chegada. Rota completa clássica, salvo dados fora do protocolo. BOLT 11 normalmente revela o node id do recebedor ao pagador.
Pagador Invoice, rota escolhida, fees, CLTVs, falhas onion e retries. Saldos reais de canais de terceiros. Falhas ajudam retry, mas também habilitam probing.

O roteamento onion limita a visão de cada hop, mas não elimina correlação por timing, valores incomuns, rotas curtas ou colusão entre hops. O transporte criptografado protege cada conexão peer-to-peer, mas não esconde que dois peers estão conectados.

Probing e inferência

Probing usa tentativas de pagamento para aprender sobre liquidez ou topologia. Ele existe porque a busca de caminho não conhece saldos remotos. Falhas onion ajudam carteiras a tentar rotas melhores, mas também podem revelar informação para quem tenta medir a rede.

O payment_secret de BOLT 11 reduz uma classe de tentativas contra o destino: conhecer apenas o payment_hash não basta para fazer o recebedor aceitar o payload final. Ainda assim, isso não impede inferência sobre hops intermediários, porque o atacante pode observar onde a tentativa falha antes de chegar ao destino.

MPP também muda a superfície. Dividir pagamento em partes menores pode melhorar entrega e reduzir dependência de um único canal, mas aumenta tentativas, timing e possibilidade de correlação entre partes. Privacidade e confiabilidade precisam ser equilibradas.

Transporte e gossip

A BOLT 8 autentica e cifra o link entre peers. Isso impede que um observador leia mensagens wire ou altere bytes sem quebrar MACs. Mas o peer remoto ainda sabe que está conectado a você, e um observador de rede ainda pode inferir padrões por metadados.

Gossip é o oposto: é público por design. A BOLT 7 usa assinaturas, chain_hash, short_channel_id, funding output e timestamps para evitar anúncios falsos baratos e updates antigos sobrescrevendo informação nova. Isso protege a integridade do grafo, mas expõe:

Canais privados reduzem exposição no grafo público, mas não são invisibilidade perfeita. Routing hints em invoices, probing, peers diretos e padrões de recebimento podem revelar partes da topologia.

Modelos probabilísticos

Uma cadeia de Markov pode ser útil para estudar privacidade de roteamento: estados como nós, transições como canais e pesos como uma combinação de fee, CLTV, capacidade anunciada, score de sucesso e randomização. Isso ajuda a estimar distribuição de caminhos e chance de um adversário observar trechos.

modelo analítico, não protocolo:

estados = nós públicos do grafo
transições = canais candidatos entre nós
peso da transição =
  f(fee, CLTV, capacidade anunciada, score de sucesso, aleatoriedade)

perguntas que o modelo ajuda a fazer:
- quais caminhos aparecem com mais frequência?
- quanto um nó central aumenta chance de observação?
- como randomização muda distribuição de rotas?
- quantos hops controlados pelo atacante bastam para correlacionar tentativas?

Mas isso é modelo analítico, não parte obrigatória da Lightning. Nenhum BOLT exige cadeia de Markov para pathfinding ou privacidade. Use esse tipo de modelo para raciocinar sobre probabilidades, centralização e correlação, não para descrever uma mensagem ou regra de protocolo.

Práticas operacionais

A segurança prática de um nó Lightning depende tanto do protocolo quanto da operação diária.

Práticas defensivas para operar um nó
Prática Por que importa
Rodar nó Bitcoin confiável O nó Lightning precisa ver funding spends, force closes, reorgs e confirmações reais.
Manter o nó online ou usar watchtower Revogação só protege se alguém reagir dentro do to_self_delay.
Planejar fee bump Fechamentos unilaterais e HTLC transactions competem por espaço em bloco.
Separar liquidez pública e privada Canais públicos ajudam roteamento; canais privados reduzem exposição no gossip, mas não eliminam inferência.
Limitar retries e probing ativo Tentativas agressivas vazam informação, geram carga e podem prejudicar peers.
Tratar backups com cuidado Backup ajuda recuperação operacional, mas estado antigo pode ser perigoso; siga o modelo da implementação.

Para usuários de carteira, a escolha custodial, non-custodial e self-hosted também muda o modelo de ameaça. Custodial desloca risco para o custodiante. Non-custodial móvel reduz controle operacional. Self-hosted aumenta soberania, mas exige disponibilidade, backup correto e vigilância on-chain.

Armadilhas comuns

Resumo

Mapa de dependências conceituais

Antes de ler esta página

Depois desta página

Referências técnicas usadas