Roteamento onion

Cada pagamento Lightning viaja dentro de um pacote de tamanho fixo de 1.366 bytes, cujas camadas são descascadas uma de cada vez, de modo que um nó que encaminha conhece seu antecessor e seu sucessor, e nada mais. O pacote mantém o mesmo tamanho em cada salto, ocultando o comprimento da rota e a sua posição nela. Sua privacidade em relação a desconhecidos no meio do caminho é forte; em relação à carteira ou à corretora em cada extremidade, não é.

Como funciona

O roteamento onion criptografa a rota em camadas, uma por salto, envolvidas em ordem inversa, de modo que descascar a camada mais externa é a única operação que qualquer nó pode realizar.

O BOLT 4 chama a construção de Sphinx, ampliada com um payload por salto. Antes de o pagamento se mover, sua carteira conhece a chave pública de cada nó na rota e usa ECDH contra cada um para derivar um segredo compartilhado. Quatro chaves saem de cada segredo compartilhado: rho gera o fluxo de bytes que ofusca o pacote, mu calcula o HMAC de integridade, um autentica erros no caminho de volta, e pad semeia o preenchimento. Esse fluxo é ChaCha20 aplicado sobre zeros com um nonce zero de 96 bits, seguro aqui apenas porque nenhuma chave é jamais reutilizada.

O pacote tem quatro campos e um tamanho fixo: um byte de versão, atualmente 0x00, um ponto secp256k1 comprimido de 33 bytes atuando como chave efêmera, 1.300 bytes de payloads de salto e um HMAC de 32 bytes. Isso dá 1.366 bytes na rede, sem precisar de prefixo de comprimento.

A montagem ocorre de trás para frente. A região de 1.300 bytes começa como bytes aleatórios de um fluxo ChaCha20, e para cada salto, do último ao primeiro, ela é deslocada para a direita para abrir espaço, empurrando a extremidade mais distante para fora da borda e descartando-a. Para um payload menor que 253 bytes, o deslocamento é o comprimento desse payload mais 33: um byte de comprimento e 32 bytes de HMAC. Cada deslocamento é seguido por um XOR contra o fluxo rho do salto, que embaralha novamente as camadas anteriores.

O que um salto lê é uma lista curta de campos tipados: o tipo 2 é amt_to_forward em milisatoshis, o tipo 4 é outgoing_cltv_value, o timelock que ele deve colocar no HTLC que oferece em seguida, e o tipo 6 é short_channel_id, nomeando o canal a usar, embora um nó possa substituir por outro canal para o mesmo par. No lugar desse short channel id, o nó final recebe o tipo 8, carregando um segredo de pagamento de 32 bytes e o valor total.

Mais um passo mantém pacotes consecutivos não vinculáveis. Cada salto ajusta a chave efêmera por um fator de cegamento antes de passá-la adiante, de modo que a mesma onion parece bytes não relacionados em cada link que atravessa. O BOLT 4 é honesto sobre o limite: a ofuscação "does not preclude the possibility of packet association by an attacker via traffic analysis."

Por que isso importa quando você compra bitcoin

O roteamento onion protege você dos desconhecidos no meio de uma rota e de ninguém em nenhuma das extremidades dela, o que é a coisa mais mal interpretada sobre a privacidade na Lightning.

O primeiro salto geralmente é um serviço com o qual você já tem uma relação, e ele vê muito mais do que um encaminhador aleatório. Nossa análise da Phoenix cita o próprio FAQ da ACINQ sem suavizá-lo: "The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments." A Phoenix recebe nota 4,0 aqui e é genuinamente autocustodial, um nó real no celular por trás de uma frase de recuperação de 12 palavras. Custódia e privacidade são questões separadas, e ela responde bem a apenas uma delas.

A extremidade receptora não é melhor. A Strike é custodial enquanto os fundos ficam no aplicativo e exige verificação de identidade, de modo que um saque Lightning para sua própria carteira informa à Strike o valor, o momento e a fatura que pagou, não importa quantos saltos a onion atravessou. A Wallet of Satoshi carrega um status de cautela e uma nota 2,7 aqui em parte porque a empresa detém as chaves, e ela já retirou seu serviço Lightning custodial da União Europeia.

Portanto, não leia o roteamento onion como uma forma de contornar a conformidade. Ele não muda qual seção de legalidade de um guia do país se aplica a você, não oculta uma compra da corretora que a vendeu e não oferece nada quando o operador da sua carteira é uma das extremidades. O que ele compra ainda vale a pena: um nó de roteamento do qual você nunca ouviu falar não pode construir um grafo de quem paga a quem, não pode dizer se você é o remetente ou outro salto e não pode distinguir uma rota curta de uma longa.

Pagando uma fatura da Strike através de dois nós dos quais você nunca ouviu falar

Pagar uma fatura da Strike pela Lightning mostra o que cada nó de uma rota aprende e não aprende.

Suponha que sua carteira escolha um caminho de quatro nós: seu próprio par, dois nós de roteamento públicos e depois a Strike. O pacote é construído a partir da Strike de trás para frente. O payload da Strike recebe o valor final e o segredo de pagamento. Cada payload intermediário recebe um amt_to_forward que ainda contém as taxas de todos os nós a jusante, um outgoing_cltv_value reduzido pelo delta anunciado desse nó e o short_channel_id do link a usar.

O segundo nó de roteamento lê exatamente um payload. Ele aprende que o nó anterior entregou um HTLC e que deve oferecer um ligeiramente menor adiante. Ele não aprende que a Strike está no fim, não aprende que você está no início e não pode dizer se o caminho tem quatro ou oito saltos, porque a região que ele repassa são os mesmos 1.300 bytes que recebeu.

Se esse nó não tiver liquidez para o encaminhamento, ele constrói um pacote de retorno: um HMAC sob sua chave um, um código de falha, preenchimento escolhido para que a mensagem de falha mais o preenchimento atinja pelo menos 256 bytes, e o resultado combinado por XOR com um fluxo de uma chave ammag. Cada salto no caminho de volta o ofusca novamente. Sua carteira desembrulha as camadas e então continua descriptografando até que o loop tenha rodado 27 vezes, a rota mais longa que o formato de payload TLV permite, de modo que o nó que falhou não possa descobrir sua posição cronometrando uma tentativa repetida. Nós mais novos também anexam dados de atribuição: HMACs truncados a 4 bytes, 210 deles para uma rota dimensionada no máximo de 20 saltos, e tempos de retenção em unidades de 100 milissegundos.

Roteamento onion vs caminho cego

O roteamento onion oculta a rota dos nós que transportam um pagamento, enquanto um caminho cego oculta a cauda da rota de quem paga.

O roteamento onion simples exige que o remetente conheça a chave pública real de cada nó, porque os segredos compartilhados vêm de ECDH contra essas chaves. O cegamento de rota inverte isso para o último trecho: o destinatário constrói uma cadeia de ids de nós ajustados, transformando Bob em Bob linha e Carol em Carol linha no próprio exemplo do BOLT 4, e então entrega ao remetente um ponto de introdução mais um blob criptografado por salto. O remetente envolve uma onion em torno de blobs que não consegue ler. Os dois se compõem em vez de competir: o BOLT 4 exige que toda mensagem onion use cegamento de rota, e uma mensagem onion usa a mesma forma de pacote que uma onion de pagamento.

Roteamento onion vs HTLC

O roteamento onion carrega as instruções e o HTLC carrega o dinheiro, e um pagamento Lightning precisa dos dois porque cada um verifica o outro.

A onion diz a um salto para onde encaminhar e quanto. O HTLC é o pagamento condicional realmente oferecido no canal. Como a região de payload é coberta por um HMAC de todo o pacote que somente o remetente e esse salto podem produzir, um nó compara o HTLC que lhe foi oferecido com o amt_to_forward e o outgoing_cltv_value escritos para ele e falha quando eles discordam, o que pega um nó a montante cortando silenciosamente o valor. Eles também se separam: uma mensagem onion, tipo 513, é a mesma construção sem carregar dinheiro, e nenhum erro jamais retorna de um salto intermediário por causa dela.