Lightning Address

Anna quer receber contribuições para seu podcast. Em vez de enviar uma nova fatura longa a cada ouvinte, publica uma Lightning Address. O exemplo anna@example.com é fácil de lembrar: antes da arroba está o destinatário no serviço; depois, o domínio que responde à carteira. A semelhança com e-mail é intencional, mas o dinheiro não viaja por e-mail. Um endereço de e-mail existente não é automaticamente uma Lightning Address, e o nome sozinho não comprova a quem pertence. Confira com o criador que você quer apoiar. [1] [6]

O ouvinte informa o nome em uma carteira compatível. Ela consulta no serviço a descrição e o intervalo de valores permitido. Depois que o usuário confere domínio, descrição e valor escolhido, a carteira solicita uma fatura BOLT 11 específica e verifica seu valor antes de pagar. Obter a fatura ainda não é pagar. Esse processo se chama LNURL-pay. O serviço fornece um callback, o endereço para solicitar a fatura, metadata com a descrição e os limites minSendable e maxSendable. amount é informado em msat, milésimos de satoshi: 1000 msat = 1 sat. A fatura chega no campo pr. [2] [3]

Anna pode usar um serviço que administra sua carteira ou conectar o nome ao próprio nó Lightning, o programa que processa seus pagamentos. O endereço não revela a diferença. Um endpoint web, o ponto onde o servidor responde à carteira, pode usar um servidor intermediário para pedir uma fatura ao nó dela. Esse intermediário não é necessariamente custodiante: depende da configuração e das permissões. Ainda assim, o controle das respostas importa; quem puder substituí-las pode apresentar outra fatura ao pagador. Ter domínio próprio não garante self-custody, ou seja, controle das próprias chaves. [3] [4]

Uma carteira pode enviar para uma Lightning Address sem fornecer ao usuário um endereço próprio para receber. Receber também exige serviço web disponível, emissão da fatura e capacidade de aceitar o pagamento na Lightning Network. Os pagamentos passam por canais: conexões entre participantes nas quais muda a divisão dos fundos entre os dois lados. Isso inclui Inbound Liquidity: fundos do outro lado dos canais que podem passar ao destinatário durante um pagamento. Um nome fácil não cria essa liquidez. Se o endereço carrega, mas o pagamento falha, o nome pode não ser o problema. Separe resposta do site, fatura obtida e recebimento confirmado do dinheiro. [3] [5]

Com domínio próprio, você pode mudar o servidor que atende aos pagamentos e manter o nome conhecido pelos ouvintes. A documentação do BTCPay mostra um redirecionamento do endpoint por HTTP 301: a solicitação web vai para outro lugar, sem movimentar moedas. Em um domínio de terceiros, talvez você não tenha esse controle. A Seed Phrase, as palavras de recuperação da carteira, não garante por si só que você recupere o acesso à conta no serviço. Ela também não guarda o acesso à administração do domínio nem as configurações do DNS, sistema que indica para onde o domínio aponta. Após a mudança, confira a fatura correta e um pagamento de teste efetivamente recebido, não só se o endereço abre. Contatos antigos não descobrem um novo nome automaticamente. [5] [3]

LUD-16 descreve como transformar o nome em uma requisição GET, um pedido de dados. A carteira consulta o domínio no caminho /.well-known/lnurlp/username, substituindo username pelo nome do usuário. Na web comum, usa HTTPS; em um domínio onion, HTTP. A resposta payRequest segue o procedimento LUD-06. HTTPS protege a conexão contra alterações no caminho, mas não comprova a honestidade do próprio serviço. Ele processa as consultas e sabe para qual destinatário emite a fatura; o nome legível, sozinho, não acrescenta anonimato. [1] [2]

LUD-16 permite no nome letras minúsculas a-z, dígitos 0-9 e -_.; o e-mail comum aceita mais caracteres. A abreviação opcional @domain aponta para o destinatário padrão _@domain no caminho /.well-known/lnurlp/_, mas a carteira ou o serviço podem não aceitá-la. O complemento +tag também não é universal. Um serviço compatível pode distinguir a finalidade da contribuição e informá-la como text/tag. Isso não é uma nova chave privada nem uma garantia de privacidade. No dia a dia, copie o nome exato publicado pelo destinatário. [1]

Metadados são informações complementares trocadas entre carteira e serviço no formato estruturado JSON. No LNURL-pay, incluem text/plain, uma breve descrição do pagamento. LUD-16 acrescenta text/identifier para associar o pagamento ao nome, ou text/email quando esse nome corresponde a um e-mail real. Assim, a carteira consegue mostrar a que o pagamento se refere. Continuam sendo informações fornecidas pelo serviço, não uma verificação independente da identidade civil de Anna. Conferir o endereço original, o domínio e o valor continua fazendo parte de pagar com cuidado. [1] [2]