168 / 691INBOUND

Inbound Liquidity

Liquidez de entrada nos canais Lightning

Inbound Liquidity descreve o espaço para receber através dos pares dos canais. Não é o seu saldo nem garante a passagem de um pagamento específico.

Inbound Liquidity é a capacidade de um nó Lightning receber pelos lados remotos dos seus canais. A base é o remote balance do par, mas reservas, pagamentos pendentes, regras do canal e uma rota disponível limitam o recebimento utilizável.

O remote balance pertence ao par e representa espaço potencial de recebimento; o local balance é o seu lado. Receber um pagamento desloca valor do lado remoto para o local. Comprar capacidade de receber não é, portanto, uma oferta de bitcoins nem receita já obtida. [Lightning Labs — Managing liquidity]

Num canal simplificado de 1000000 sat com local balance de 800000 sat e remote balance de 200000 sat, o espaço bruto de recebimento é 200000 sat, não um milhão. O exemplo omite reservas, taxas e HTLC pendentes. Financiar sozinho sem transferência inicial dá sobretudo espaço de saída; confirmar a abertura não inverte a direção. [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]

BOLT 2 limita a adição de HTLC através de reservas, valores mínimos, número de HTLC simultâneos e valor total pendente. Pagamentos em curso podem prender fundos temporariamente. Verifique o valor disponível e os limites de cada canal; não subtraia uma reserva universal da soma de todos os saldos. [BOLT 2 — Channel management]

BOLT 7 publica parâmetros direcionais channel_update, como taxas e htlc_maximum_msat, não um saldo atual garantido de toda a rota. Um par desligado ou um estrangulamento anterior podem impedir o pagamento. A soma dos saldos remotos não garante receber esse valor de um remetente específico. [BOLT 7 — Routing gossip]

Um pagamento Lightning de saída reduz o local balance e aumenta o remote balance dos canais usados. Loop Out transfere valor Lightning para uma saída on-chain e pode libertar espaço de entrada; Loop In repõe fundos de saída. Não se criam bitcoins: considere custos de encaminhamento, swap e on-chain, bem como o resultado da operação. [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]

Um par pode financiar um canal para si; no Lightning Pool, um bid compra liquidez por tempo limitado e um ask oferece-a. A duração é expressa em blocos. Pagar o prémio e outras taxas não torna todo o saldo remoto sua propriedade nem assegura disponibilidade permanente após o fim do acordo. [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]

Circular rebalancing envia por um dos seus canais e recebe por outro através da rede. O canal de saída ganha espaço de entrada e o recetor consome-o. O reequilíbrio não cria capital e custa taxas de encaminhamento; exige uma rota utilizável e não resolve sozinho um nó sem fundos em todos os lados remotos. [Lightning Labs — Managing liquidity]

Receber receitas converte continuamente saldos remotos em locais e pode esgotar o espaço para novos recebimentos. Acompanhe canais utilizáveis, pagamentos pendentes, custos de reposição e valores esperados. Uma tentativa falhada pode não ser visível no nó recetor; uma fatura emitida ou uma leitura antiga de capacidade não confirma o pagamento. [Lightning Labs — Merchant liquidity]

Para ter uma visão mais completa, leia este verbete junto com Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. Também há referências a este verbete em Liquidez Lightning, Lightning Routing, Lightning Address, Submarine Swap.

DOC · 001Lightning Labs — Managing liquidityDocumentação ↗DOC · 002BOLT 2 — Channel managementEspecificação ↗DOC · 003BOLT 7 — Routing gossipEspecificação ↗DOC · 004Lightning Loop — Direction and channel balancesDocumentação ↗DOC · 005Lightning Pool — Orders and leasesDocumentação ↗DOC · 006Lightning Labs — Merchant liquidityDocumentação ↗
Fontes em primeiro lugar · Não é recomendação de investimento