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 pagina e tecnica e defensiva. Ela nao ensina a atacar peers. O objetivo e entender superficie de risco, limites reais e mitigacoes para operar e implementar com menos surpresa.

Conteúdo

Modelo de ameaça

Antes de falar em mitigacao, defina o que voce esta protegendo. Um usuario de carteira movel, um roteador publico com muitos canais e um comerciante recebendo invoices repetidas nao tem o mesmo risco.

para analisar uma ameaca Lightning:

1. identificar o ativo:
   - fundos no canal
   - liquidez
   - privacidade da rota
   - disponibilidade
   - reputacao do node id
2. identificar o adversario:
   - contraparte do canal
   - hop intermediario
   - pagador
   - recebedor
   - observador on-chain
   - observador de rede
3. mapear o mecanismo:
   - revogacao e penalty
   - CLTV/CSV
   - onion routing
   - gossip assinado
   - transporte Noise
   - politicas locais
4. listar o vazamento residual:
   - timing
   - valor
   - IP ou conexao
   - funding output
   - falhas e retries
5. decidir mitigacao operacional

Essa lista força uma separacao importante: seguranca de fundos, disponibilidade de liquidez e privacidade sao problemas diferentes. Um mecanismo pode melhorar um e piorar outro. Por exemplo, canal publico melhora roteabilidade, mas aumenta exposicao no gossip. Probing melhora chance de entrega, mas vaza informacao de liquidez.

Matriz de ameaças

A tabela abaixo liga ameacas a mecanismos reais do protocolo. Nem toda mitigacao e puramente normativa; algumas sao politica local de implementacao.

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 Revogacao, to_self_delay, penalty path e monitoramento on-chain. BOLT 3, BOLT 5 Voce precisa detectar a transacao antes da janela expirar.
Fechamento unilateral em mempool cara contraparte ausente, congestionamento ou pinning Anchor outputs, CPFP/RBF quando aplicavel e politica de fee bump. BOLT 3, BOLT 5 Taxas extremas e pinning ainda podem atrasar resolucao.
Eclipse do no Bitcoin atacante de rede Bitcoin No Bitcoin proprio, conexoes diversas, monitoramento de blocos e cuidado com reorgs. BOLT 5 Se o no so ve uma cadeia falsa, pode reagir tarde.
Channel jamming pagador ou roteador malicioso max_accepted_htlcs, limites de valor em voo, CLTV, reputacao e propostas de custo por tentativa. BOLT 2, BOLT 4 O protocolo base ainda tem superficie de DoS por HTLCs presos.
Probing de liquidez origem tentando mapear canais Onion failures limitados, payment_secret, politicas de retry e privacidade operacional. BOLT 4, BOLT 11 Hops intermediarios 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 Visoes locais podem ficar desatualizadas ou divergentes.
Inspecao de trafego peer-to-peer observador de rede ou peer direto Transporte Noise autenticado e cifrado. BOLT 8 Metadados de IP, timing, volume e conexoes ainda podem vazar.
Resumo de ameaças da Lightning e mitigacoes: estado revogado, jamming, corrida de tempo em fechamento e eclipse.
A seguranca da Lightning depende de protocolo, politicas locais e operacao on-chain.
Descricao longa do diagrama

O diagrama organiza quatro classes de ameaca. Estado revogado e mitigado por revogacao, penalty e watchtower. Channel jamming e mitigado por limites de HTLC, reputacao e custos de tentativa. Corrida de tempo em fechamento depende de CLTV, anchors e fee bump. Eclipse depende de conexao confiavel com a blockchain e diversidade de peers Bitcoin.

Segurança on-chain

Um canal Lightning e off-chain enquanto tudo coopera. A garantia de seguranca vem do fato de que qualquer lado pode cair de volta para a blockchain. Por isso, a seguranca do canal depende de transacoes Bitcoin, Script, locktime, sequence/CSV, taxas e observacao da blockchain.

A BOLT 5 descreve tres finais para um canal: fechamento cooperativo, fechamento unilateral e fechamento com transacao revogada. A diferenca operacional e 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 confirmacao.
Unilateral close to_local atrasado, HTLCs podem exigir segunda etapa e fee bump. Monitorar outputs, resolver HTLCs, usar anchors/CPFP quando disponivel.
Revoked close Contraparte tenta publicar commitment antiga favoravel a ela. Detectar gasto da funding output, usar dados de revogacao e transmitir penalty transaction.
Reorg Uma resolucao aparentemente confirmada pode desaparecer. Continuar monitorando ate outputs ficarem irrevogavelmente resolvidos.

O ponto critico e que um no com fundos em risco precisa monitorar outputs ate estarem resolvidos. Se a contraparte publica uma commitment antiga, a defesa so funciona se voce detectar a transacao e gastar o caminho de revogacao dentro do tempo. Watchtowers existem para delegar essa vigilancia quando o usuario esta offline.

Backup nao e watchtower. Backup ajuda recuperar dados operacionais; watchtower observa a cadeia e reage a uma publicacao maliciosa. Restaurar estado antigo sem entender o modelo da implementacao pode ser perigoso.

Disponibilidade e jamming

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

A Lightning tem limites que reduzem a superficie, mas nao eliminam o problema no protocolo base:

Vetores de jamming e controles relacionados
Vetor Como funciona Controle
HTLC slots Um canal aceita numero limitado de HTLCs simultaneos. max_accepted_htlcs, politicas locais e reputacao.
Valor em voo HTLCs prendem liquidez ate 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 problematicos em fechamento on-chain. dust_limit_satoshis, max_dust_htlc_exposure_msat e politicas de valor minimo.

Mitigacoes como reputacao, custo por tentativa, reservas e scoring sao em grande parte politicas de implementacao ou propostas em evolucao. Nao apresente como regra universal dos BOLTs. A base normativa define campos e limites; a politica de aceitar, penalizar ou precificar tentativas depende do node.

Camadas de privacidade

A Lightning melhora privacidade em relacao a pagamentos on-chain simples porque pagamentos intermediarios normalmente nao viram transacoes publicas. Mas "fora da cadeia" nao significa "invisivel". Cada observador enxerga uma fatia diferente.

Camadas de observacao na Lightning: blockchain, gossip, peers diretos, hops intermediarios e pontas do pagamento.
Privacidade depende de quem observa: blockchain, gossip, peers, hops ou pontas.
Descricao longa do diagrama

O diagrama mostra varias camadas de visibilidade. Na base, um observador on-chain ve abertura e fechamento de canais. Na camada de gossip, a rede publica ve canais anunciados e politicas. Na camada de roteamento, cada hop ve apenas vizinhos e parametros locais do HTLC. Nas pontas, pagador e recebedor conhecem mais detalhes do pagamento, mas nao necessariamente a mesma informacao.

Quem vê o quê em um pagamento Lightning
Observador Consegue ver Nao deveria ver Cuidado
Observador on-chain Funding transactions, force closes, mutual closes, anchors, HTLC transactions e padroes de gasto. Pagamentos off-chain bem-sucedidos que nao fecham canal. Abertura e fechamento ainda podem ligar capacidade, tempo e scripts.
Rede de gossip channel_announcement, channel_update, node_announcement, capacidade publica inicial e politicas. 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 so encaminha. O peer sabe muito sobre os canais que divide com voce.
Hop intermediario Canal de entrada, canal de saida, valor recebido, valor encaminhado e CLTV de entrada/saida. Origem real, destino real, tamanho total da rota e posicao exata. Timing, valores incomuns e colusao entre hops reduzem privacidade.
Primeiro hop O peer anterior que enviou o HTLC e o proximo canal. Se o peer anterior e origem real ou outro roteador. Em pagamentos de carteira comum, o primeiro hop frequentemente e um canal direto do pagador.
Ultimo hop Que esta 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 classica, 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 tambem habilitam probing.

O roteamento onion limita a visao de cada hop, mas nao elimina correlacao por timing, valores incomuns, rotas curtas ou colusao entre hops. O transporte criptografado protege cada conexao peer-to-peer, mas nao esconde que dois peers estao conectados.

Probing e inferência

Probing usa tentativas de pagamento para aprender sobre liquidez ou topologia. Ele existe porque a busca de caminho nao conhece saldos remotos. Falhas onion ajudam carteiras a tentar rotas melhores, mas tambem podem revelar informacao 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 nao basta para fazer o recebedor aceitar o payload final. Ainda assim, isso nao impede inferencia sobre hops intermediarios, porque o atacante pode observar onde a tentativa falha antes de chegar ao destino.

MPP tambem muda a superficie. Dividir pagamento em partes menores pode melhorar entrega e reduzir dependencia de um unico canal, mas aumenta tentativas, timing e possibilidade de correlacao 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 esta conectado a voce, e um observador de rede ainda pode inferir padroes por metadados.

Gossip e o oposto: e publico por design. A BOLT 7 usa assinaturas, chain_hash, short_channel_id, funding output e timestamps para evitar anuncios falsos baratos e updates antigos sobrescrevendo informacao nova. Isso protege a integridade do grafo, mas expõe:

Canais privados reduzem exposicao no grafo publico, mas nao sao invisibilidade perfeita. Routing hints em invoices, probing, peers diretos e padroes de recebimento podem revelar partes da topologia.

Modelos probabilísticos

Uma cadeia de Markov pode ser util para estudar privacidade de roteamento: estados como nos, transicoes como canais e pesos como uma combinacao de fee, CLTV, capacidade anunciada, score de sucesso e randomizacao. Isso ajuda a estimar distribuicao de caminhos e chance de um adversario observar trechos.

modelo analitico, nao protocolo:

estados = nos publicos do grafo
transicoes = canais candidatos entre nos
peso da transicao =
  f(fee, CLTV, capacidade anunciada, score de sucesso, aleatoriedade)

perguntas que o modelo ajuda a fazer:
- quais caminhos aparecem com mais frequencia?
- quanto um no central aumenta chance de observacao?
- como randomizacao muda distribuicao de rotas?
- quantos hops controlados pelo atacante bastam para correlacionar tentativas?

Mas isso e modelo analitico, nao parte obrigatoria da Lightning. Nenhum BOLT exige cadeia de Markov para pathfinding ou privacidade. Use esse tipo de modelo para raciocinar sobre probabilidades, centralizacao e correlacao, nao para descrever uma mensagem ou regra de protocolo.

Práticas operacionais

A seguranca pratica de um no Lightning depende tanto do protocolo quanto da operacao diaria.

Práticas defensivas para operar um nó
Prática Por que importa
Rodar no Bitcoin confiavel O no Lightning precisa ver funding spends, force closes, reorgs e confirmacoes reais.
Manter o no online ou usar watchtower Revogacao so protege se alguem reagir dentro do to_self_delay.
Planejar fee bump Fechamentos unilaterais e HTLC transactions competem por espaco em bloco.
Separar liquidez publica e privada Canais publicos ajudam roteamento; canais privados reduzem exposicao no gossip, mas nao eliminam inferencia.
Limitar retries e probing ativo Tentativas agressivas vazam informacao, geram carga e podem prejudicar peers.
Tratar backups com cuidado Backup ajuda recuperacao operacional, mas estado antigo pode ser perigoso; siga o modelo da implementacao.

Para usuarios de carteira, a escolha custodial, non-custodial e self-hosted tambem muda o modelo de ameaca. Custodial desloca risco para o custodiante. Non-custodial movel reduz controle operacional. Self-hosted aumenta soberania, mas exige disponibilidade, backup correto e vigilancia 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

Para fechar a trilha técnica, siga para a referência das mensagens que aparecem por baixo dessas propriedades de segurança.