Expiração da fatura

Toda fatura Lightning carrega um prazo, e a contagem regressiva começa no momento em que a fatura foi assinada, não no momento em que ela chegou até você. Sem o campo x, o padrão é 3600 segundos, uma hora. Assim, uma fatura que ficou a maior parte dessa hora em uma conversa de chat pode falhar minutos depois de chegar até você, sem nenhuma razão visível.

Como funciona

A expiração da fatura viaja como campo etiquetado do tipo 6, escrito com a letra x, carregando uma contagem de segundos em big-endian.

Uma string BOLT11 começa com um carimbo de data e hora de 35 bits que conta os segundos desde 1º de janeiro de 1970 UTC, depois os campos etiquetados e por fim uma assinatura. A expiração é um desses campos e é relativa: o prazo é aquele carimbo de data e hora mais a expiração, então nada na fatura indica um horário legível. O BOLT11 orienta o pagador a não tentar um pagamento depois de passada essa soma, e orienta o beneficiário a não aceitar nenhum também.

As duas instruções são um SHOULD e não um MUST, então uma fatura expirada não está criptograficamente morta. O hash de pagamento ainda funciona; o que impede o pagamento é a política nas duas pontas, e não um bloqueio. Sua carteira se recusa a tentar, e um nó que tenha descartado a preimagem não conseguiria liquidar de qualquer forma.

O valor é empacotado em grupos de cinco bits e deve usar o comprimento mais curto que caiba, sem grupos de zeros à esquerda. Os próprios exemplos da especificação mostram a faixa: 60 segundos ocupam dois grupos, escritos pu, e 604800 segundos ocupam quatro, escritos jw5q. Um codificador que preenche o campo não é apenas desleixado: os leitores são instruídos a tratar como inválida uma fatura com um campo x, c ou 9 não mínimo.

Ninguém pode prorrogar uma fatura depois de emitida. A assinatura cobre o prefixo legível por humanos e toda a parte de dados, então editar um caractere da expiração a quebra. Um comerciante que queira lhe dar mais tempo precisa emitir uma nova solicitação e assiná-la de novo.

O padrão de uma hora não foi escolhido ao acaso: a justificativa da especificação diz que ele deixa tempo para pagar on-chain em vez disso, por meio do endereço alternativo que o campo f pode carregar.

Onde você vê isso

A expiração da fatura aparece como o anel de contagem regressiva em torno de um código QR, como uma linha rotulada expiry em qualquer decodificador e como a recusa que uma carteira dá quando você cola algo vencido.

Os vetores de teste da especificação mostram os dois extremos da faixa. Uma fatura de 2500 micro-bitcoin descrita como 1 cup coffee define a expiração em 60 segundos, porque fixa um preço de três dólares no balcão. Uma fatura da Blockstream Store, de 88,85 USD em mercadorias incluindo um Ledger Nano S, define a expiração em 604800 segundos, sete dias, porque uma confirmação de pedido é uma fatura a pagar e não um balcão.

Onde a fatura é criada decide quem escolheu o número. A Phoenix, que este site analisa, roda um nó Lightning real no celular em vez de uma conta em um servidor, então a expiração em uma solicitação de recebimento é configuração do próprio nó dela. Com um aplicativo que guarda seus fundos, o número vem do operador, e decodificar uma de suas faturas costuma ser a única forma de conhecê-lo.

Expiração da fatura vs delta de expiração CLTV

A expiração da fatura e o delta de expiração CLTV são dois relógios de um pagamento Lightning, e correm em unidades diferentes sobre metades diferentes do problema.

A expiração da fatura é em segundos de relógio contados desde o carimbo de data e hora da fatura, e decide se o pagamento pode sequer ser tentado. Um delta de expiração CLTV é medido em blocos, e o campo c da mesma fatura carrega o mínimo do destinatário para o salto final, que o pagador deve tratar como pelo menos 18 blocos quando o campo está ausente. Um diz se você deve começar; o outro diz por quanto tempo seu dinheiro pode ficar preso em um HTLC depois de você ter começado.