Pular para o conteúdo
buybitcoinsmart

Glossário / Lightning e camada 2

Keysend

O que é o keysend?
O keysend envia um pagamento Lightning sem fatura: o pagador gera a pré-imagem de 32 bytes, calcula seu hash para obter o hash de pagamento e envia o segredo dentro da cebola.

O keysend inverte o fluxo normal da Lightning, no qual o destinatário escolhe um segredo e publica seu hash em uma fatura. O segredo do remetente viaja no registro TLV personalizado 5482373484, um número par, que o BOLT 1 faz um nó que não conhece keysend rejeitar em vez de ignorar. Você pode pagar para a chave pública de um nó, sem nada mais, sem ida e volta, e abre mão do recibo criptográfico que uma fatura teria deixado.

Como funciona

O keysend se apoia na metade mais rígida de uma regra do BOLT 1: um leitor descarta um registro TLV desconhecido de tipo ímpar e segue adiante, mas deve fazer todo o fluxo falhar diante de um par desconhecido.

Os identificadores de tipo abaixo de 2^16 estão reservados para os BOLTs e tudo a partir de 2^16 fica livre para registros personalizados, e o BOLT 1 diz para escolher um número ímpar quando nós comuns devem ignorar os dados e um par quando devem rejeitá-los. O bLIP-3 registra que 5482373484 foi escolhido ao acaso pela implementação original do lnd, e ele termina em quatro, então o keysend ficou do lado que rejeita. É por isso que ele precisa de um bit de recurso: nós dispostos anunciam 54/55, chamado keysend, que depende de var_onion_optin, e o bLIP-3 diz que os remetentes devem procurá-lo em vez de enviar às cegas e ver o pagamento falhar.

A tarefa do remetente, descrita no bLIP-3, é curta. Gerar um valor aleatório de 32 bytes criptograficamente seguro, colocá-lo naquele registro e definir o payment_hash no update_add_htlc como seu SHA-256. Nunca reutilize uma pré-imagem, e nunca reutilize a de uma fatura que você já pagou. O pacote é ofuscado em cada salto, de modo que um salto recupera apenas o endereço do próximo e ninguém no meio vê o registro. O nó final calcula o hash do valor que encontra, verifica-o contra o hash que foi solicitado a aceitar e liquida.

A recusa é deliberadamente silenciosa. O BOLT 4 tem uma resposta literal para uma carga útil que um nó não entendeu, PERM|22 invalid_onion_payload, que pode até nomear o tipo TLV causador. O bLIP-3 pede que os destinatários retornem PERM|15 incorrect_or_unknown_payment_details em vez disso, de modo que um keysend recusado é indistinguível de um hash de pagamento que o nó nunca emitiu.

Onde você o vê

O keysend é a infraestrutura por trás dos boosts de podcast.

O bLIP-10 define um segundo registro, de tipo 7629169, originalmente escolhido pela Breez, que carrega um bloco JSON simples anexado ao pagamento keysend: o título do podcast, o episódio, ts para a posição de reprodução em segundos, action definido como boost ou stream, e um message opcional, que é o que forma um boostagram. O streaming por minuto define seconds_back como 60. Esse registro é ímpar, e é por isso que o bLIP-10 dispensa a compatibilidade com versões anteriores: um apresentador que ignora os metadados ainda fica com os sats. Ele existe porque um keysend sozinho não diz nada ao destinatário, então um aplicativo precisa nomear o programa por conta própria.

A mesma lacuna mantém o keysend fora do caminho de compra. Um saque de corretora ou entrega uma fatura a você ou pede uma, porque a plataforma precisa vincular o pagamento à sua conta, e a palavra não aparece em nenhum dos 63 registros de corretoras nem nas 41 análises de carteiras deste site. O bLIP-3 expõe a contrapartida com honestidade: ele espera que o keysend dê lugar a um pagamento espontâneo melhor projetado, citando as ofertas e o AMP, e lista o que você perde nesse meio-tempo, a prova de pagamento e qualquer controle do beneficiário sobre a expiração CLTV final.

Keysend vs endereço Lightning

O keysend e um endereço Lightning permitem que você pague alguém que nunca lhe entregou uma fatura, e apenas um dos dois realmente dispensa a fatura. Digitar user@example.com faz sua carteira realizar uma consulta HTTPS que retorna uma fatura BOLT11 nova, então o destinatário ainda escolheu a pré-imagem e você fica com um recibo respaldado pela assinatura dele. O keysend não precisa de nenhuma solicitação web nem de nenhum servidor, apenas da chave pública de 33 bytes do nó e de uma rota até ele, e não deixa nada para você provar depois, porque o segredo foi seu desde o início. Se você um dia precisar mostrar que pagou, opte pela fatura.

Não confundir com

Perguntas frequentes

O keysend faz parte da especificação da Lightning?

Não, o keysend está no bLIP-3, uma proposta de melhoria da Lightning criada em 8 de dezembro de 2021 para documentar o que as implementações já haviam lançado. Ele não precisou de nenhuma mudança nos BOLTs porque os identificadores de tipo TLV a partir de 2^16 ficam livres para registros personalizados, mas o tipo 5482373484 do keysend é par, então o BOLT 1 faz um nó que não o aceita rejeitar a carga útil em vez de ignorá-la.

Um pagamento keysend prova que eu paguei?

Não, porque a pré-imagem foi gerada por você e não pelo destinatário, e não há nenhuma assinatura de fatura vinculando o pagamento a ele. O bLIP-3 inclui a perda da prova de pagamento entre as principais desvantagens do keysend, então use uma fatura sempre que o recibo for importante.

Por que meu pagamento keysend falhou?

Na maioria dos casos, porque o destino não aceita keysend, e isso não é possível saber pelo erro. Um nó que recusa pagamentos espontâneos retorna PERM|15 incorrect_or_unknown_payment_details, a mesma falha de uma pré-imagem errada ou de um hash de pagamento que o nó nunca emitiu, e é por isso que o bLIP-3 orienta enviar somente para nós que anunciam o bit de recurso keysend, registrado como 54/55 no bLIP-2.

Leia a seguir

Termos relacionados

Mais em Lightning e camada 2

Ler esta página em inglês