164 / 691BOLT11

BOLT 11

Fatura assinada para um pagamento Lightning

BOLT 11 contém as condições de um pagamento Lightning específico. Uma fatura válida não garante uma rota utilizável nem um pagamento concluído.

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.

DOC · 001BOLT 11 — Invoice protocolEspecificação ↗DOC · 002BOLT 4 — Onion routingEspecificação ↗DOC · 003BOLT 9 — Assigned feature flagsEspecificação ↗DOC · 004Core Lightning — Payment resultDocumentação ↗
Fontes em primeiro lugar · Não é recomendação de investimento