Oferta BOLT12

Uma oferta é uma solicitação de pagamento que sobrevive ao próprio pagamento, então um único código impresso serve para todos os clientes. As ofertas não carregam assinatura nem soma de verificação, e seus campos ocupam os tipos TLV 2 a 22, deliberadamente curtos o bastante para a câmera de um celular de entrada. Se você recebe bitcoin, essa é a diferença entre um código que você imprime uma vez e a fatura que ele emite, que expira 7200 segundos depois.

Como funciona

Uma oferta BOLT12 é uma sequência de registros tipo-comprimento-valor escrita com o prefixo legível por humanos lno, um separador 1, e depois caracteres no estilo bech32 que carregam esses registros em ordem.

Não há uma soma de verificação de seis caracteres no final. A especificação a dispensa com o argumento de que os códigos QR carregam suas próprias somas de verificação, e que uma oferta corrompida produz uma string que não pode ser interpretada, em vez de um pagamento perdido. Ofertas longas podem ser divididas com um sinal de mais, opcionalmente seguido de espaço em branco, para que sobrevivam ao serem coladas em um campo de texto com limite de caracteres, e quem lê deve remover o sinal de mais e o espaço em branco antes de decodificar. Quem escreve deve usar tudo em minúsculas ou tudo em maiúsculas, e convém escolher maiúsculas para códigos QR.

Os próprios campos são numerados. offer_chains é 2, offer_metadata é 4, offer_currency é 6, offer_amount é 8, offer_description é 10, offer_features é 12, offer_absolute_expiry é 14, offer_paths é 16, offer_issuer é 18, offer_quantity_max é 20 e offer_issuer_id é 22. Quem escreve deve permanecer dentro dos tipos 1 a 79, com um segundo intervalo de 1000000000 a 1999999999 reservado para experimentos. Nada nessa lista é uma assinatura, e isso é deliberado: assinar aumentaria a string sem nenhum benefício, porque todo campo que não é de assinatura é copiado na solicitação que vem a seguir, então uma oferta adulterada simplesmente não produz nenhuma fatura.

Pagar exige então mais duas mensagens. Sua carteira envia um invoice_request, prefixo lnr, por uma mensagem onion, copiando todos os campos da oferta, inclusive os que não entende, e assina o resultado com uma assinatura BIP340 sobre uma raiz de Merkle. O emissor responde com uma fatura assinada. A construção de Merkle emparelha a folha de cada campo com uma folha de nonce, e é isso que permite a um pagador revelar depois um campo de uma fatura em disputa sem expor os campos vizinhos, algo que uma assinatura BOLT11 sobre a string inteira não consegue fazer.

Duas dessas três mensagens funcionam no sentido inverso para reembolsos e caixas eletrônicos. Um comerciante publica um invoice_request indicando um valor que quer enviar, você responde com uma fatura, e o comerciante confirma o invoice_node_id antes de pagar.

Por que isso importa quando você compra bitcoin

Uma oferta muda a forma como você publica um meio de receber pagamentos, e não muda nada no que custa receber.

Tome como exemplo a análise da Phoenix neste site. A ACINQ publica uma tabela de taxas em vez de deixar você descobri-la: enviar pela Lightning custa 0,4% mais 4 satoshis, receber é gratuito quando você já tem liquidez de entrada, e receber quando a carteira precisa ir on-chain para abrir espaço custa 1% mais taxas de mineração, com um canal novo a 1.000 satoshis. Entregar uma oferta em vez de uma fatura não altera nenhum desses números. Remove a etapa em que você emite um código novo por pagador, não a etapa em que alguém paga pela liquidez.

O ganho de privacidade é real, mas limitado. Um endereço Lightning encaminha cada solicitação de fatura por um servidor web no domínio de outra pessoa, e esse operador vê os valores e o momento. Uma oferta encaminha a solicitação pela Lightning como uma mensagem onion, e offer_paths permite que um nó cujos canais são todos privados continue acessível sem publicar nenhum id de nó. O que isso não lhe dá é privacidade em relação ao seu próprio provedor: nossa análise da Phoenix cita o FAQ da ACINQ, que diz com todas as letras que conhece o destino final e o valor dos pagamentos.

O aviso prático é sobre colar. Um campo de saque em uma corretora pede uma fatura Lightning, e uma string lno1 não é uma. A Strike, um dos 63 registros de corretoras aqui, é nativa da Lightning e não acrescenta taxa própria nas transferências para mais de 100 países, e esse é exatamente o tipo de fluxo em que dois formatos se confundem. Nenhuma das 41 análises de carteiras nem dos 63 registros de corretoras neste site documenta atualmente o suporte a ofertas como recurso, então trate isso como algo a confirmar nas notas de versão da sua própria carteira, em vez de supor.

A oferta de uma barraca de chapéus e a fatura em que ela se transforma

Uma barraca que vende chapéus por 25 dólares escreve uma oferta com offer_currency definido como USD e offer_amount definido como 2500.

Essa é a regra da especificação para uma moeda diferente de bitcoin: um código ISO 4217 de três letras, e um valor na unidade da moeda ajustado pelo expoente ISO 4217, que no caso do dólar significa centavos. Definir offer_amount torna offer_description obrigatório, porque um pagador que está sendo cobrado por algo específico precisa saber o que era. Se restarem três chapéus, offer_quantity_max é 3, e se a barraca não tiver limite fixo, é 0. Um valor de 1 é explicitamente permitido, por estranho que pareça, para que um sistema de estoque nunca precise de um caso especial para o último item. offer_issuer poderia dizer hats@example.com Hat Stall, já que a especificação pede primeiro um domínio e qualquer texto amigável depois de um espaço.

Sua carteira lê isso, cota 25 dólares para você e envia um invoice_request carregando invreq_quantity de 2 para dois chapéus, um invreq_payer_id e, opcionalmente, um invreq_payer_note. De volta vem uma fatura com um hash de pagamento, um carimbo de data e hora de criação, pelo menos uma rota cega e uma cotação de taxa por caminho cobrindo taxa base, taxa proporcional, delta de CLTV e o menor e o maior HTLC que ela vai carregar. Duas regras protegem você aqui. Sua carteira deve rejeitar a fatura se algum campo nos intervalos 0 a 159 não corresponder ao que ela enviou, e deve avisar você se o valor em milissatoshis diferir de forma significativa da estimativa em dólares que a oferta deu. A menos que o emissor defina invoice_relative_expiry, a fatura deve ser rejeitada 7200 segundos depois de ter sido criada.

Oferta BOLT12 vs fatura BOLT11

Uma oferta BOLT12 é uma solicitação de uma solicitação de pagamento; uma fatura BOLT11 é a solicitação de pagamento.

O texto do BOLT12 abre com oito reclamações sobre seu antecessor, e as que um pagador sente são estas. Uma fatura BOLT11 é assinada como um todo, então provar um campo significa revelar todos eles. Seus valores legíveis por humanos, no julgamento da especificação, se mostraram problemáticos: o multiplicador p era muitas vezes mal tratado, e é mais difícil contar em picobitcoin do que em satoshis. Seu payment_secret só impedia o teste enquanto a fatura permanecia privada entre pagador e recebedor, o que uma fatura publicada não é. E, nas palavras da própria especificação, as faturas devem ser dadas por usuário e são ativamente perigosas se duas tentativas de pagamento forem feitas para o mesmo usuário. Uma oferta responde às quatro por não ser uma fatura.

Oferta BOLT12 vs endereço Lightning

Uma oferta BOLT12 é uma string autônoma; um endereço Lightning é um nome que o servidor de outra pessoa resolve para você.

Os dois são reutilizáveis, e por isso são confundidos. O endereço depende de um domínio, de um certificado e de um operador que mantenha o serviço funcionando, e para de funcionar no dia em que qualquer um dos três falhar. A oferta depende de que os dois nós falem mensagens onion e de nada mais, o que é uma superfície de falha menor, embora você tenha que confirmar que sua própria carteira aceita isso em vez de supor. O endereço ganha no quesito de poder ser dito em voz alta. Uma string lno1 longa é um código QR, não algo que se dita para um microfone.