BOLT 12

Imagine uma cafeteria que quer deixar um só código no balcão para contribuições voluntárias. Pagar repetidamente a mesma fatura BOLT 11 comum causaria problemas. BOLT 12 publica uma offer no lugar dela. A carteira do cliente envia uma invoice_request para pedir sua própria fatura e o destinatário responde com uma invoice nova. Só então ela pode ser paga. Um QR impresso atende várias pessoas sem que todas usem a mesma fatura. Obtê-la, por exemplo com fetchinvoice, ainda não envia dinheiro. A oferta também não autoriza a cafeteria a debitar outros pagamentos da carteira alheia. [1] [3] [4]

A oferta pode apresentar o preço em bitcoin ou em outra moeda. O campo offer_currency usa códigos ISO 4217; um valor em USD, por exemplo, é expresso em centavos. A quantidade e a conversão de moeda podem entrar no cálculo ao emitir a fatura. O invoice_amount final em bitcoin, porém, está em millisatoshi, milésimos de satoshi: 1000 msat = 1 sat. Antes de pagar, a pessoa precisa conhecer esse valor e a tarifa, não apenas o preço na placa. Se o pedido especifica uma invreq_amount exata, a fatura deve coincidir. Caso contrário, a carteira verifica a faixa autorizada e deve pedir nova aprovação fora dela. A conversão não deve virar consentimento invisível para qualquer preço. [1] [3]

O código impresso pode continuar no balcão, mas a própria oferta pode vencer em offer_absolute_expiry. Cada fatura também tem sua criação invoice_created_at e seu prazo invoice_relative_expiry. Sem esse prazo, o padrão é 7200 segundos, ou duas horas. Uma fatura antiga não é, portanto, um contato permanentemente válido. As carteiras também precisam entender as funções obrigatórias declaradas nas mensagens. Um bit par desconhecido indica uma função necessária e provoca rejeição; um ímpar desconhecido é opcional e pode ser ignorado. Trata-se de compatibilidade segura, não de um obstáculo a contornar alterando o código à mão. [1]

Depois de pagar, guarde a fatura e o resultado da carteira. A evidência de liquidação inclui o preimage, um valor secreto obtido quando o pagamento é concluído. A carteira calcula seu hash, um valor de verificação, e o compara com o hash de pagamento da fatura. Junto com a fatura, isso permite demonstrar que ela foi paga, mas não identifica por si só a pessoa que pagou. Se o aplicativo desconectar ou perder a resposta, consulte o estado do pagamento anterior antes de tentar novamente; uma fatura nova pode gerar outro pagamento. Examine promessas de pagamentos recorrentes com o mesmo cuidado. Suportar BOLT 12 não significa suportar todas as extensões nem autorizar débitos automáticos. Confira separadamente se a carteira recebe pagamentos por ofertas, paga ofertas de terceiros e quais permissões você deu ao aplicativo conectado. [1] [3]

Pedir a fatura e transferir fundos usam a rede para fins diferentes. offer_paths leva a mensagem do pedido, enquanto invoice_paths fornece rotas de pagamento. BOLT 12 usa blinded paths, rotas que ocultam parte das informações de conexão ao destinatário. Expor menos da estrutura da rede ajuda a privacidade, mas não promete anonimato completo. Uma rota oculta também não garante destinatário disponível nem liquidez, isto é, dinheiro suficiente nos lados necessários dos canais. Tecnicamente, uma invoice atual deve conter essas rotas e os parâmetros invoice_blindedpay correspondentes, mesmo quando leva diretamente ao destinatário. Pedir a fatura não exige um servidor de pagamentos HTTPS convencional. [1] [2]

Quando o comerciante quer devolver dinheiro, a negociação muda de direção. Quem pretende pagar pode publicar uma invoice_request sem offer anterior. O cliente, agora destinatário, responde com sua própria invoice para o comerciante pagar. Isso não apaga nem desfaz o pagamento original: é um novo pagamento no sentido oposto. O comerciante precisa verificar se a fatura pertence ao destinatário correto, às vezes conversando fora do protocolo. Escanear o pedido não prova direito ao reembolso nem aprova a transferência. O processo técnico facilita a comunicação, mas não decide quem deve receber o dinheiro. [1]

BOLT 12 guarda dados como TLV: cada campo informa tipo, comprimento e valor. Uma oferta textual começa com lno, um pedido com lnr. O conjunto de caracteres lembra Bech32, mas não traz sua soma de verificação final. Isso sozinho não diz quem pode receber dinheiro. A offer não é assinada. As assinaturas digitais BIP340 Schnorr autenticam a fatura e o pedido habitual feito em resposta a uma oferta. Um pedido independente publicado sem oferta, por exemplo para um reembolso, não contém assinatura. A assinatura está vinculada à raiz de uma estrutura de Merkle: um valor de verificação calculado a partir do conjunto dos campos relevantes. É possível provar campos selecionados sem revelar sempre todos os detalhes. Isso não permite alterar condições assinadas nem prova a identidade civil do comerciante. [1]

A carteira deve confirmar que recebeu uma resposta ao seu pedido, não apenas qualquer fatura corretamente assinada. Compara os campos copiados de invoice_request com invoice, além de rede, valor e assinatura. A chave pública invoice_node_id deve corresponder a offer_issuer_id; quando a oferta usa a rota oculta correspondente sem esse identificador, verifica-se seu blinded_node_id final. É como conferir se a conta é da sua mesa, não só se o carimbo é autêntico. A estrutura de Merkle permite provas seletivas, mas não dispensa a carteira de verificar todas as condições necessárias ao pagamento. Uma fatura válida de outra pessoa não se torna a correta só porque a assinatura passou. [1]