Liquidez Lightning

Anna e Pavel têm um canal com capacidade de 1.000.000 sat: um milhão de satoshis, as menores unidades na cadeia do Bitcoin. Imagina uma situação simplificada em que Anna possui 800.000 sat e Pavel 200.000 sat. Para facilitar a explicação, deixamos de lado reservas, taxas e pagamentos pendentes. Anna pode enviar dinheiro a Pavel a partir do seu lado; só pode receber dele a partir do lado dele. Pavel não consegue, portanto, enviar-lhe 300.000 sat por este canal, apesar da capacidade total de um milhão. O dinheiro não desapareceu. A sua distribuição é que não permite esse pagamento. [1] [3]

A liquidez de saída é a quantia utilizável para pagar a partir do teu lado. No exemplo, parte do saldo de Anna de 800.000 sat, mas o máximo real costuma ser menor devido a reservas, taxas e pagamentos pendentes. Quando Anna paga a alguém que não seja Pavel, o primeiro passo continua a passar por um dos seus canais. Um nó é o programa que gere os canais e processa os pagamentos Lightning. Os nós seguintes precisam dos próprios fundos para os passos posteriores. Bitcoin fora dos canais não aumenta automaticamente a sua liquidez de saída; a carteira precisa de uma forma adequada de transferir esse valor para Lightning. [1] [3]

A liquidez de entrada é a quantia que o outro participante te pode enviar. Se Anna abre um canal e quase todos os fundos lhe pertencem, está bem preparada para enviar, mas tem pouca margem para receber. Criar um novo pedido de pagamento não muda essa distribuição. Precisa de um canal em que a outra parte tenha saldo utilizável. Algumas carteiras tratam disso através de um prestador de serviços, escondendo a complexidade do utilizador, muitas vezes mediante uma taxa. A capacidade de entrada não é dinheiro adicional que Anna já possui: é a possibilidade de receber um pagamento futuro. [1] [3] [5]

Anna paga agora 100.000 sat a Pavel. No exemplo simplificado, os saldos passam a 700.000 sat para Anna e 300.000 sat para Pavel. A capacidade continua a ser de 1.000.000 sat. Anna pode enviar menos, mas receber mais de volta; para Pavel acontece o contrário. Se a carteira tem vários canais, mudam aqueles que o pagamento realmente utilizou. A direção é sempre importante. A liquidez indicada de manhã pode não representar o que será possível enviar à noite. [1] [3]

Um pagamento a um destinatário distante atravessa uma sequência de canais. Cada um precisa de liquidez utilizável suficiente na direção certa, incluindo os valores para taxas dos passos seguintes. Se um passo não puder transportar o pagamento, essa rota falha mesmo que os restantes canais tenham grande capacidade. A carteira pode tentar outra rota ou dividir o pagamento em partes, quando houver suporte. Isso não cria os fundos em falta. O valor não é a única condição: os prazos também importam. Um HTLC é um pagamento condicional que pode ser concluído demonstrando o conhecimento de um segredo específico. As regras associadas a CLTV definem prazos em blocos; os intervalos entre eles dão aos intermediários tempo para liquidar na cadeia do Bitcoin se o encaminhamento ficar bloqueado. [1] [2]

Um intermediário tem de conseguir receber por um canal e enviar o pagamento associado por outro. Uma soma elevada de saldos não chega. Se os fundos estiverem do seu lado do canal errado, podem não servir para a rota escolhida. Para receber, precisa de liquidez de entrada no primeiro canal; para encaminhar, de saída no segundo. As condições HTLC ligam estes passos: os pagamentos dependem do conhecimento de um segredo específico e de regras temporais. O intermediário não se limita a confiar na promessa de que o participante anterior lhe pagará mais tarde. [1] [3]

Pagamentos recebidos e enviados mudam naturalmente a liquidez. Quem gere vários canais também pode fazer reequilíbrio circular: enviar um pagamento por uma rota e recebê-lo de volta por outra para deslocar saldos entre os seus próprios canais. Um swap troca fundos na cadeia por fundos Lightning, ou ao contrário. Splicing permite alterar o financiamento de um canal compatível sem o habitual fecho e reabertura. Abrir outro canal é mais uma opção. Estes métodos diferem nas taxas, no tempo, nos registos deixados na cadeia, na confiança necessária e no risco de falha. Nenhum cria dinheiro novo; escolhe conforme precises de enviar, receber ou ambos. [1] [4]

Primeiro identifica se o problema é no envio ou na receção e verifica se a carteira e o outro nó estão online. No teu próprio nó, compara os saldos local e remoto de cada canal, reservas, pagamentos pendentes e taxas. Numa carteira gerida por um serviço, confirma o significado do valor disponível apresentado. Uma falha, por si só, não prova que houve perda de dinheiro: pode faltar liquidez num passo, existir um limite ou ocorrer uma interrupção temporária. Um pequeno pagamento de teste só verifica aquele valor naquele momento; não garante a passagem de todos os pagamentos seguintes. [1] [3] [4]

Os operadores precisam de distinguir vários limites. Uma saída de transação define um valor e as condições para o gastar. channel_reserve_satoshis designa fundos que devem permanecer em reserva. Parte pode estar comprometida em HTLC pendentes, pagamentos condicionais ainda não concluídos. Os limites seguintes aplicam-se aos HTLC oferecidos pelo outro participante. max_htlc_value_in_flight_msat limita o seu valor total e max_accepted_htlcs o seu número; msat é um milésimo de satoshi usado nos cálculos internos de Lightning. Conforme o tipo de canal, também se aplicam taxas da commitment transaction, a transação que permite fechá-lo, e possivelmente anchor outputs: saídas especiais que permitem acrescentar uma transação para aumentar a taxa de confirmação do conjunto. As regras Dust determinam quais as saídas demasiado pequenas para integrar essa transação. Calcula o máximo disponível para a implementação e o tipo de canal concretos, em vez de subtrair uma reserva universal. [1] [6]

BOLT #7 descreve os anúncios de canais e as regras de encaminhamento. Num canal anunciado, é possível encontrar na cadeia a saída de financiamento e a sua capacidade. Isso não revela a distribuição atual entre os participantes. O emissor escolhe rotas com informações próprias, resultados anteriores e tentativas de pagamento, não com uma lista pública completa de saldos em tempo real. Um explorador pode mostrar um canal grande sem confirmar que o teu valor consegue atravessá-lo agora na direção certa. [2]