BOLT 12 é um protocolo de negociação de pagamentos Lightning com offer, invoice_request e invoice. A oferta é reutilizável, mas cada pagamento tem condições próprias e resultado a verificar.
O destinatário publica offer; o pagador envia invoice_request e recebe uma nova invoice. Só então pode pagar. A oferta serve a várias pessoas ou pagamentos repetidos. Obter uma fatura, por exemplo com fetchinvoice, não a paga; um QR publicado não autoriza débitos permanentes. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 armazena campos como TLV. Ofertas textuais usam lno e pedidos lnr; o alfabeto lembra Bech32, mas sem checksum final. A offer em si não é assinada. Assinaturas Schnorr BIP340 nos pedidos e faturas verificam a raiz Merkle dos campos, não a identidade do comerciante. [BOLT 12 — Negotiation protocol]
A carteira compara os campos copiados de invoice_request com invoice, valor, cadeia e assinatura. invoice_node_id deve corresponder a offer_issuer_id ou ao blinded_node_id final adequado. Uma assinatura válida de terceiro não basta. A estrutura Merkle permite provas seletivas de campos, não alterar arbitrariamente condições assinadas. [BOLT 12 — Negotiation protocol]
A invoice_amount de Bitcoin está em msat; 1000 msat são um satoshi. offer_currency permite outra moeda segundo ISO 4217; USD usa centavos, por exemplo. Quantidade e conversão na emissão afetam o preço. Se invreq_amount estiver definido, a fatura deve corresponder; caso contrário, verifica-se a faixa autorizada. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths leva o pedido; invoice_paths leva o pagamento. A invoice atual deve conter blinded paths e invoice_blindedpay correspondente, mesmo em caminho direto ao destinatário. O cegamento limita a exposição da topologia sem garantir anonimato completo, disponibilidade ou liquidez. Pedir a fatura não exige um servidor de pagamento HTTPS comum. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry limita a oferta. invoice_created_at com invoice_relative_expiry limita a fatura específica; sem o segundo campo, valem 7200 segundos. Uma oferta reutilizável não torna suas faturas eternas. Bits pares obrigatórios desconhecidos são rejeitados; ímpares desconhecidos são ignorados. [BOLT 12 — Negotiation protocol]
Em um reembolso, quem deseja enviar dinheiro pode publicar invoice_request sem offer. O destinatário responde com sua invoice; o pagador deve verificar o recebedor pretendido, fora do protocolo se necessário. É um novo pagamento, não o cancelamento do anterior. Escanear o pedido não prova direito nem autoriza pagamento. [BOLT 12 — Negotiation protocol]
Guarde invoice, estado do pagamento e preimage correspondente. O preimage comprova a liquidação da fatura, mas sozinho não identifica a pessoa pagadora. Se perder a resposta, confira o estado antes de pagar novamente. Suportar ofertas não significa suportar toda extensão ou recorrência automática; verifique recebimento, envio e autorização do aplicativo separadamente. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Para ter uma visão mais completa, leia este verbete junto com BOLT 11, Lightning Network, Lightning Routing, Privacidade no Bitcoin, Satoshi, LNURL. Também há referências a este verbete em BOLT 11, LNURL.