BOLT 11 é o padrão de fatura Lightning assinada e codificada em Bech32. Contém payment hash, informações do destinatário e condições de pagamento; é um pedido, não uma prova de pagamento realizado.
Bech32 usa uma soma de verificação contra erros de transcrição; não é criptografia. A assinatura ECDSA sobre secp256k1 protege o conteúdo e o vincula à chave do destinatário, não a uma pessoa verificada. Diferentemente dos endereços Bech32, BOLT 11 não tem limite de 90 caracteres. O QR pode usar maiúsculas; misturar maiúsculas e minúsculas é inválido. [BOLT 11 — Invoice protocol]
lnbc indica mainnet, lntb testnet, lntbs signet e lnbcrt regtest. O valor é em BTC com multiplicador m, u, n ou p. Com p, o último dígito deve ser 0 para representar msat inteiros; 1000 msat equivalem a um satoshi. Sem valor, o pagador o informa; não significa pagamento zero. [BOLT 11 — Invoice protocol]
O campo p contém o payment hash: SHA256 do payment preimage. O campo s contém payment_secret, exigido pelo destinatário na parte final do pagamento roteado. O secret não é o preimage nem a seed da carteira. BOLT 11 atual exige ambos os campos; ler o secret da fatura não comprova pagamento. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
A fatura contém exatamente uma alternativa: texto d ou hash h de uma descrição externa. Para h, a carteira deve verificar o SHA256 da descrição recebida; o hash sozinho não explica a compra. A assinatura vincula conteúdo e chave, sem comprovar promessas comerciais. O texto decodificado deve ser exibido com segurança como dados. [BOLT 11 — Invoice protocol]
Timestamp mais x determina a expiração; sem x, o prazo padrão é de 3600 segundos. O campo c é min_final_cltv_expiry_delta do último HTLC em blocos, não outro prazo em segundos; se ausente, aplicam-se pelo menos 18 blocos. A expiração não reverte um pagamento concluído. [BOLT 11 — Invoice protocol]
O campo 9 indica funções obrigatórias e opcionais. Um bit par desconhecido exige rejeição; um ímpar desconhecido é ignorado. As dependências conhecidas devem ser satisfeitas. Basic MPP só pode ser usado quando basic_mpp é oferecido. Dividir o pagamento não cria várias faturas independentes. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
O campo r adiciona routing hints para chegar ao destinatário; pode expor chaves de nós, identificadores de canais e parâmetros de taxas. Não comprova liquidez atual. O campo opcional f pode oferecer um endereço on-chain, outro método com taxas e confirmações próprias. A fatura não é um contato privado nem reutilizável indefinidamente. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Após enviar, diferencie pendente de concluído. Guarde a fatura e o preimage correspondente como evidências de liquidação, não apenas uma captura do QR. Se perder a resposta, confira primeiro o estado na carteira. Uma nova fatura ou outra forma de pagamento pode gerar outro pagamento; o formato sozinho não oferece proteção universal contra repetição. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. Também há referências a este verbete em Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.