LNURL

Imagine que a Ana lê um código para apoiar um autor, outro para resgatar um vale e um terceiro para entrar num site. Usa o telemóvel da mesma forma, mas autoriza uma ação diferente em cada caso. LNURL distingue essas tarefas: payRequest para pagar, withdrawRequest para levantar fundos e login para iniciar sessão. Os documentos LUD descrevem os procedimentos. São convenções opcionais entre aplicações, não alterações às regras do Bitcoin. Uma carteira que suporta um procedimento não tem necessariamente de suportar os restantes. [1] [7]

Em payRequest, o serviço devolve uma descrição e um intervalo de valores permitidos. A Ana verifica o domínio — o nome do serviço no endereço web —, lê a descrição e escolhe a contribuição. Depois de aceitar as condições, a carteira pede uma fatura Lightning BOLT 11 específica e confirma o valor antes de pagar. Usa o endereço callback, os limites minSendable e maxSendable e a descrição metadata; envia o valor em amount e recebe a fatura em pr. Os valores usam msat, milésimos de satoshi: 1000 msat = 1 sat. Outras pessoas podem usar o mesmo QR público, mas lê-lo não confirma um pagamento. [3]

Em withdrawRequest, o sentido inverte-se. A Ana pretende levantar um saldo do serviço, não pagar-lhe. A sua carteira cria então uma fatura de recebimento que o serviço deve pagar. Este fornece o identificador k1, o endereço callback e os limites minWithdrawable e maxWithdrawable em msat; após autorização, a carteira envia a fatura em pr. A resposta OK significa que o serviço aceitou o pedido, não que a Ana já recebeu dinheiro. A carteira continua à espera da entrada do pagamento. O código de levantamento pode funcionar como um vale para quem o possuir; não o publique como se fosse um contacto normal para receber pagamentos. [4]

Noutro site, a Ana escolhe LNURL-auth. A carteira mostra o domínio e a finalidade do pedido com o tag login. Com autorização, assina um desafio de uso único, k1, com a chave privada específica desse domínio, linkingPrivKey. Envia ao serviço a assinatura e a chave pública correspondente, linkingKey, que permite verificar a assinatura. Não entrega a chave privada. O serviço pode reconhecer o titular quando regressa, mas essa verificação não revela, por si só, a sua identidade real. A carteira não envia ao serviço o seed, o valor secreto inicial a partir do qual se derivam as chaves, nem a Seed Phrase, as palavras de recuperação. Tecnicamente, utiliza uma assinatura ECDSA sobre secp256k1. O campo action pode indicar registo, início de sessão, associação de conta ou outra autorização. Vale a pena ler a confirmação completa: assinar esse desafio não é, por si só, um pagamento em Bitcoin. [5]

O pedido, a resposta do serviço e a transferência efetiva são passos diferentes. Se a Ana perder a ligação, verifica primeiro o pagamento original na carteira. Uma nova tentativa com outra fatura pode originar outro pagamento. O procedimento opcional LUD-21 acrescenta um endereço verify para consultar uma fatura concreta: settled true indica liquidação comunicada, enquanto settled false indica que ainda não foi liquidada. OK não basta. A resposta pode incluir um preimage, o valor secreto original associado ao pagamento. A carteira calcula o seu hash, um valor de verificação, e compara-o com o hash de pagamento da fatura correta. Não basta receber um valor secreto qualquer: tem de corresponder precisamente a esse pagamento. Consultar o resultado não garante disponibilidade do serviço nem liquidez de entrada, isto é, capacidade de encaminhar dinheiro para a carteira destinatária. [6] [3] [4]

HTTPS protege a comunicação entre carteira e serviço, não contra o próprio serviço. Este pode observar pedidos, horários e utilizações repetidas. Para o acesso, também conta o domínio completo: mudar o subdomínio pode gerar outra linkingKey e fazer o site reconhecer um utilizador diferente. Mudar de carteira também não garante recuperar o mesmo acesso, pois as aplicações derivam chaves de formas distintas. Antes de uma mudança importante, confirme como recuperar essa conta específica. LNURL não define quem detém as chaves dos bitcoins; isso depende da carteira e do serviço. [2] [5]

O procedimento básico LUD-01 representa um URL HTTPS ou onion em Bech32. Trata-se de codificação, não de encriptação do endereço nem de uma fatura BOLT 11. A carteira lê o tag diretamente no link ou faz um pedido web GET para obter dados e identifica a operação numa resposta JSON. Este formato dá nomes e estrutura aos dados para a aplicação os interpretar. A imagem QR não comprova, portanto, a identidade do destinatário. Importam o conteúdo do link e o domínio, a ação e as condições apresentados em seguida. [2]

No pagamento, metadata é uma cadeia de texto que contém um array JSON. Tem de incluir uma descrição text/plain; os outros tipos são opcionais. A carteira deve mostrar a descrição com o domínio e o valor para a pessoa compreender o que autoriza. O LNURL básico interpreta o corpo JSON da resposta, não apenas o código de estado HTTP. Um servidor acessível não significa necessariamente um pedido bem-sucedido: a resposta pode conter ERROR. Da mesma forma, uma fatura recebida em pr ainda não está paga. A aplicação não deve resumir estas informações diferentes a uma única marca verde. [2] [3]