Lightning Address

LUD-16 usa username e domínio, mas limita o nome a a-z minúsculas, algarismos 0-9 e -_.; o sinal de mais só é permitido se o serviço suportar etiquetas. A sintaxe normal de e-mail é mais ampla. Uma caixa de correio não garante uma Lightning Address, e o mesmo nome não autentica a pessoa destinatária. [Lightning Address — LUD-16] [Lightning Address — Project overview]

A carteira usa GET no caminho /.well-known/lnurlp/username do domínio, através de HTTPS ou HTTP num serviço onion. A resposta é um payRequest segundo LUD-06. Importam o domínio real e o respetivo serviço; a parte antes da arroba não é a chave pública de um nó. [Lightning Address — LUD-16]

A resposta fornece callback, metadata e os limites minSendable/maxSendable. O pagador escolhe amount em msat; 1000 msat equivalem a um satoshi. O callback devolve uma fatura em pr e a carteira verifica a correspondência do valor antes de pagar. Consultar o endereço ou receber uma fatura ainda não é liquidação. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

A LUD-16 mais recente permite opcionalmente @domínio como abreviatura de _@domínio, com um caminho terminado em /_. Nem o serviço nem a carteira têm de o suportar. Um +tag suportado é enviado no caminho; o serviço pode utilizá-lo como metadata text/tag. Uma etiqueta não é uma nova chave Bitcoin nem proteção automática da privacidade. [Lightning Address — LUD-16]

LUD-16 exige text/identifier ou text/email em metadata; text/email destina-se a um endereço de e-mail real. O text/plain de LNURL-pay continua também a ser obrigatório. Compare o nome e a descrição apresentados com o domínio e o destinatário pretendido. A declaração do serviço não verifica de forma independente a identidade de uma pessoa. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

O serviço pode emitir faturas da sua carteira ou utilizar um servidor de ponte ligado a um nó. Por isso, o formato não implica custódia nem autocustódia. A ponte precisa das permissões necessárias à sua função, não automaticamente de controlo ilimitado sobre a carteira. Quem controla o endpoint pode influenciar a fatura recebida pelo pagador. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

Uma carteira pode pagar a uma Lightning Address sem fornecer aos utilizadores um endereço próprio. Receber exige um serviço web funcional, emissão de faturas e capacidade de aceitar o pagamento. O nome legível não cria liquidez de entrada por si só. Consultas repetidas podem revelar ao fornecedor o destinatário e os horários. [Lightning Address — Implementation guide]

Um domínio próprio permite redirecionar o endpoint para outro servidor; o BTCPay descreve, por exemplo, HTTP 301. Num domínio alheio, manter o nome depende do fornecedor. A seed não restaura o controlo DNS, certificados ou associações de contas. Após mudar de serviço, verifique novamente a consulta, a fatura de destino e o recebimento; não presuma que os contactos antigos se atualizam automaticamente. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]