Lightning Watchtower

Anna e Pavel têm um canal de pagamento: os fundos ficam bloqueados em conjunto no Bitcoin, e os pagamentos Lightning mudam sua distribuição. Pavel paga Anna, ambos concordam com os novos saldos e revogam o estado anterior. Depois, Anna perde a conexão. Se Pavel publicasse o estado antigo, poderia tentar recuperar dinheiro que já gastou. Anna pode recorrer a um Lightning Watchtower para essa situação. Seu nó envia antes dados criptografados para proteger estados revogados. Quando o serviço reconhece a transação correspondente na cadeia, pode transmitir uma transação de recuperação sem que Anna esteja online. Ele não faz pagamentos por ela nem conserta a conexão de seu nó. [1] [8]

Cada divisão acordada dos fundos tem uma commitment transaction: uma transação assinada que permite fechar o canal na cadeia do Bitcoin. Durante uma atualização, os participantes trocam informações que permitem penalizar a publicação do estado anterior, agora revogado. É esse modelo de canal com penalidade que descrevemos aqui. Se Pavel usar o estado atual válido, poderá fechar o canal unilateralmente mesmo com Anna offline. O Watchtower não deve impedir esse fechamento. Ele reage a um estado revogado específico, publicado de propósito ou por engano a partir de um backup antigo. O que importa é a revogação, não a idade da transação. [1] [8]

Uma Seed Phrase é um backup em forma de palavras que permite recuperar as chaves privadas necessárias para assinar pagamentos. LND é um dos programas usados para operar um nó Lightning. Anna não entrega ao serviço sua Seed Phrase nem as chaves privadas da carteira inteira. Ela fornece dados e assinaturas limitados a uma intervenção específica; no LND, esse pacote se chama JusticeKit. A transação de recuperação, chamada justice transaction, devolve os fundos protegidos segundo condições preparadas previamente. Isso não dá ao Watchtower liberdade para gastar outras moedas de Anna. No modelo sem remuneração para o serviço, a taxa da transação Bitcoin é descontada do valor protegido. O código também prevê tipos com recompensa para a torre, mas isso, por si só, não demonstra que um operador específico ofereça um serviço pago. [3] [4] [5]

Para ajudar, o Watchtower precisa realmente receber os dados necessários. Não basta informar seu endereço nas configurações ou ver uma tarefa na fila de envio. O cliente, a parte do nó de Anna que se comunica com a torre, precisa receber confirmações de recebimento das atualizações. A conexão pode falhar, um acordo de armazenamento chamado session pode esgotar sua capacidade, ou um backup pode ser rejeitado. Anna precisa acompanhar também as atualizações não entregues e os erros. Mesmo dados aceitos não garantem sucesso: a torre deve continuar seguindo a cadeia correta e conseguir que sua reação seja confirmada em um bloco a tempo. [6] [8]

Se Anna perder o dispositivo, não vai restaurá-lo a partir do Watchtower. O serviço vigia o uso indevido de estados revogados; não restaura sua carteira nem resolve o roubo de chaves. O LND usa Static Channel Backup (SCB) para recuperar canais. Junto com o seed da carteira, ele ajuda a recuperar fundos fechando canais, e não a retomar exatamente do ponto em que o nó parou. SCB não é uma cópia de cada atualização nem o pacote criptografado enviado à torre. Iniciar um banco channel.db antigo sem o procedimento correto de recuperação é especialmente perigoso: o nó pode publicar seu próprio estado revogado. Siga a documentação de backup da carteira e da versão que você usa. [7]

Uma saída de transação define um valor e as condições para gastá-lo. A proteção funciona porque quem publica seu estado do canal não pode gastar imediatamente sua saída com atraso. No BOLT 3, essa saída se chama to_local e o prazo de espera, to_self_delay. CSV é a regra que mede esse atraso em blocos desde a confirmação da saída. A outra parte pode usar o caminho de penalidade sem essa espera se tiver a chave de revogação correta. Assim, o Watchtower ganha uma vantagem de tempo para agir. Depois do prazo, o caminho de penalidade não desaparece, mas a outra parte também pode gastar os fundos. O resultado depende de qual dos gastos conflitantes será confirmado validamente. Apenas transmitir a transação de recuperação não basta, e um número de blocos não equivale a um número exato de horas. [1] [9]

Antes de escolher o serviço, verifique o que ele realmente protege. HTLCs são pagamentos condicionais que podem continuar pendentes no canal; monitorar saldos não comprova que esses pagamentos estão cobertos. Dust significa aqui uma saída pequena demais para ser incluída naquela transação. O backupTask verificado no LND v0.21.3-beta prepara as saídas to_local e to_remote existentes e não dust do commitment revogado. Não inclui proteção geral de todas as saídas HTLC; a documentação correspondente apresenta essa proteção como uma extensão futura. Bitcoin Script é a linguagem que expressa as condições para gastar uma saída. Poder gastar uma saída pelo caminho de penalização não significa que uma torre específica tenha recebido os dados necessários ou consiga executar essa proteção. [3] [5]

O pacote criptografado não exige que a torre leia continuamente todos os saldos de Anna. Ela busca uma correspondência com um identificador curto e usa informações da transação reconhecida para descriptografar os dados. A seguir está uma referência técnica para uma versão específica do LND; txid é o identificador da transação e blob é um pacote de dados. No LND v0.21.3-beta, BreachHint corresponde aos primeiros 16 bytes do SHA-256 do txid binário. BreachKey resulta do SHA-256 da concatenação do mesmo txid binário duas vezes seguidas. Não são os primeiros 16 caracteres do txid apresentado nem simplesmente a sua primeira metade. O cliente cifra o JusticeKit; conhecendo a transação correspondente, é possível derivar a chave e decifrar os dados. [2] [3]

Operar uma torre para outras pessoas e proteger seus próprios canais são tarefas diferentes. Essas configurações são para operadores LND; RPC é a interface pela qual o programa recebe comandos. O LND separa watchtower.active para o servidor de wtclient.active para o cliente. Ativar apenas o servidor não configura backups dos próprios canais em outra torre. lncli tower info mostra pubkey, listeners e uris do servidor; lncli wtclient add registra uma torre para o cliente. A chave pública da torre é diferente da chave do nó Lightning. Verifique a rede, a acessibilidade do endereço e o suporte RPC na compilação utilizada. [5]

A intervenção precisa pagar por espaço em um bloco do Bitcoin. O satoshi é a menor unidade do bitcoin. O byte virtual mede o tamanho da transação considerando os diferentes pesos de suas partes. A taxa é expressa em satoshis por byte virtual da transação, não em porcentagem do dinheiro protegido. No LND v0.21.3-beta, o campo sweep_sat_per_vbyte da política e da sessão indica a taxa em sat/vB. A taxa reduz o valor devolvido. backupTask pode rejeitar um estado com valor muito baixo ou parâmetros de sessão inadequados; nem toda tarefa preparada pode ser usada como backup. Uma alteração posterior das configurações não prova a alteração de transações já assinadas, e uma taxa insuficiente pode atrasar a intervenção. [3] [6]

Se a primeira torre falhar, uma segunda só poderá ajudar se também tiver recebido os dados necessários. A independência envolve também conexão e operador, não apenas nomes diferentes de serviço. Várias torres independentes e vigilância própria podem limitar o impacto de uma falha isolada. Verifique, porém, que atualizações concretas cada torre aceitou; vários endereços registrados não provam, por si só, a replicação de todos os estados. Máquinas, redes e localizações separadas reduzem falhas comuns. Blobs criptografados e conexões autenticadas limitam a visibilidade dos saldos, mas não eliminam metadados, a visibilidade da frequência das atualizações nem o risco de correlação. [5] [8]

Na verificação, diferencie uma atualização enviada de uma efetivamente recebida. Estes comandos e campos são uma referência mais detalhada para administradores LND; confirmar o recebimento de um backup não é confirmar uma transação em um bloco. Utilize lncli wtclient towers, lncli wtclient tower, lncli wtclient stats e lncli wtclient policy. No LND v0.21.3-beta, distinga num_backups de num_pending_backups; o segundo campo designa backups aguardando confirmação de recebimento pela torre. num_failed_backups na resposta stats conta backups que falharam e não tiveram o recebimento confirmado. As estatísticas abrangem o período desde a inicialização do cliente. active_session_candidate indica um candidato para sessões, não uma prova de proteção completa. [6]

A configuração correta é o começo. Um teste deve cobrir o caminho completo, desde reconhecer um estado revogado até recuperar os fundos protegidos; não faça esse experimento com seu dinheiro real. Verifique a versão concreta do cliente e da torre, o tipo de canal e de sessão suportado, a atualidade dos dados, as taxas e a sincronização com a cadeia. Teste a reação em um ambiente de teste isolado; um fechamento unilateral comum (force close) não prova uma intervenção contra um estado revogado. O resultado é demonstrado pela publicação do estado revogado (breach), pela justice transaction construída e pelas suas saídas confirmadas. Uma demonstração bem-sucedida não garante disponibilidade futura nem a eliminação de todos os riscos do Lightning. [1] [3] [6]