Mostro 0.20 adia pagamentos e publica a saúde do nó

Por que o anúncio não bastava

A documentação de saúde descreve uma falha operacional de 14 de outubro. LND parou de acompanhar a cadeia, pagamentos de saída falharam e novas negociações ainda podiam ser abertas. O evento informativo habitual continuou aparecendo, portanto sua presença não revelava o problema nos pagamentos.

A lição é mais específica que uma afirmação geral de segurança. Anunciar configurações ou responder a um relay não equivale a concluir o caminho de pagamento. A versão 0.20.0 separa essas questões em vez de usar uma como prova da outra.

Esperar antes de responsabilizar o comprador

O PR #1065 adiciona um monitor de LND que consulta a cada 15 segundos. Após 60 segundos contínuos de LND sem sincronia ou sem resposta, pagamentos de saída aguardam, em vez de consumir repetidamente as tentativas do comprador. A inicialização também verifica o backend antes de começar as tarefas de pagamento.

A manutenção automática tem outro limite. Por padrão, 600 segundos de dessincronização informada interrompem novas ordens e sua aceitação. A recuperação exige 300 segundos de sincronia estável antes que o daemon remova sua própria manutenção automática. Uma decisão de manutenção separada do operador não é removida automaticamente.

Falta de resposta não é igual a falta de sincronia. Um backend que não responde produz uma verificação unknown, não prova de dessincronização da cadeia. Pagamentos ainda podem ser adiados sem que essa condição, sozinha, ative a manutenção automática. Essas diferenças impedem que um único rótulo verde ou vermelho represente vários estados.

Um relatório separado para observadores

O PR #1066 introduz eventos de saúde endereçáveis kind 38389. O intervalo normal de publicação é de 60 segundos, com relatórios antecipados quando estados relevantes mudam. Tags públicas descrevem verificações de sincronia de LND, pagamentos, relays e banco de dados, além de um estado geral.

Métricas operacionais detalhadas podem ser criptografadas com NIP-44 para uma chave pública de monitoramento configurada. Sem essa configuração, o conteúdo detalhado fica vazio. O evento não transforma todas as métricas internas em um painel público.

A validade temporal faz parte do projeto. Os relatórios incluem informações de sequência e expiração. Sem um relatório utilizável, sua ausência não pode ser tratada como ok. Clientes existentes que não entendem o novo evento não ganham monitoramento apenas porque o daemon foi atualizado.

O que os controles não demonstram

A documentação da versão alerta que o nó informa o que seu próprio backend sabe. Um backend atrasado pode não reconhecer sua visão desatualizada. Comparar a altura de bloco anunciada com uma referência independente continua útil; um relatório assinado identifica o autor, não garante a verdade de cada afirmação operacional.

A versão oferece binários para download, código-fonte e arquivos de manifesto assinados. Sua presença comprova disponibilidade, não instalação bem-sucedida em um nó específico. Os PRs descrevem cobertura automatizada e uma verificação local em modo Cashu, mas também apontam lacunas nos testes manuais de Lightning. Esta revisão documental não executou um nó de negociação nem enviou pagamentos.

Para quem desenvolve ferramentas, a descoberta útil é a interface: distinguir anúncios de identidade e configuração da saúde operacional recente, preservar unknown como estado real e não transformar uma falha do backend no esgotamento das tentativas do comprador.