Rusty Russell

Os grandes projetos começam muitas vezes discretamente. A retrospetiva da Blockstream de 9 de junho de 2026 recorda o primeiro commit de Russell, de 26 de maio de 2015: uma pequena ferramenta para criar uma mensagem de abertura de canal. Um commit regista uma alteração no histórico do código. A experiência inicial cresceu até se tornar Core Lightning; Russell contribuiu para o programa, os testes e a formação de outros programadores. O artigo descreve ainda a sua saída após onze anos. Não anuncia o fim de todas as contribuições futuras nem transforma uma liderança passada em autoridade permanente sobre a rede. [1]

Imagine um café e um cliente com programas diferentes. Pagar não deve depender de escolherem o mesmo fornecedor. Precisam de regras comuns para as mensagens e o seu significado. As especificações BOLT descrevem essa comunicação em Lightning. Russell coordenou o seu desenvolvimento coletivo e apoiou a interoperabilidade, a capacidade de implementações diferentes trabalharem juntas. O repositório público aceita propostas e comentários. Nem um colaborador importante consegue impor sozinho uma alteração a todos os nós: as regras têm de passar para o software real e para a sua utilização. [1] [2]

Dois programas podem interpretar o mesmo parágrafo de maneiras diferentes. O lnprototest de Russell fornece ferramentas em Python para escrever cenários e testar respostas a mensagens do protocolo. O README, documento introdutório do projeto, distingue um executor simulado dos testes contra uma implementação real. A simulação ajuda a preparar o teste, mas o seu êxito não prova o comportamento de um nó verdadeiro. Importa saber o que foi realmente executado e que situações foram abrangidas. Mesmo uma série de testes bem-sucedidos não é uma auditoria de todos os defeitos possíveis. [3]

Com BOLT 12, o café pode publicar uma oferta reutilizável, por exemplo num código QR. A carteira do cliente envia uma invoice_request com base nessa oferta e recebe uma fatura específica: um pedido com os dados daquele pagamento. Só depois se paga. A oferta pode ser usada repetidamente enquanto os clientes recebem faturas individuais. Isso não transforma uma fatura já usada num pedido novo a cada compra. Separar oferta, pedido e fatura facilita o pagamento sem confundir operações distintas. [4]

Core Lightning mostra essa separação. O comando fetchinvoice contacta o emissor da oferta e obtém uma fatura. O campo changes pode indicar diferenças face à oferta, como o montante ou a descrição. Uma resposta bem-sucedida não envia dinheiro. É como receber a conta do café: primeiro verifica-se o que pagar e quanto. A carteira precisa de processar as condições recebidas e iniciar o pagamento separadamente. Terminar a obtenção de um pedido não equivale a concluir o seu pagamento. [5]

A documentação de pay distingue complete, pending e failed: concluído, pendente e falhado. Pendente não significa pago. Distingue também amount_msat, o montante recebido pelo destinatário, de amount_sent_msat, o total enviado com taxas. msat significa millisatoshi, um milésimo de satoshi. O cliente pode, por isso, gastar uma taxa além do que o café recebe. A documentação já identifica pay como obsoleto e descreve a transição para xpay. Aqui explicam-se estados e montantes, não se recomenda instalar uma versão específica; os resultados devem ser interpretados segundo o programa utilizado. [6]

Quando o café devolve dinheiro, não faz o pagamento original andar para trás. BOLT 12 descreve também o fluxo inverso: o comerciante anuncia o montante a enviar, o cliente fornece uma fatura e o comerciante verifica invoice_node_id, o identificador do nó a pagar. Segue-se um novo pagamento ao cliente. Isto não anula a transferência original nem cria automaticamente um direito ao reembolso. O protocolo oferece um modo de o executar; as partes têm de acordar separadamente o motivo e as condições. [4]

Num litígio, é útil saber o que uma prova realmente demonstra. BOLT 12 explica que o preimage, o valor secreto correspondente ao hash no pedido de pagamento, pode demonstrar que uma fatura foi paga. Depois de divulgado, porém, outra pessoa também o pode apresentar; por si só, não identifica quem enviou o dinheiro. Uma chave incluída no pedido permite provar quem solicitou a fatura, sem verificar automaticamente a sua identidade civil. Fatura paga, controlo de uma chave e identidade do cliente são informações distintas. [4]