168 / 691INBOUND

Inbound Liquidity

Płynność przychodząca w kanałach Lightning

Inbound Liquidity opisuje miejsce na odbiór przez partnerów kanałów. Nie jest Twoim saldem ani gwarancją przejścia konkretnej płatności.

Inbound Liquidity to zdolność węzła Lightning do odbioru przez zdalne strony jego kanałów. Podstawą jest remote balance partnera, ale rezerwy, płatności w toku, zasady kanału i dostępna trasa ograniczają użyteczny odbiór.

Remote balance należy do partnera i stanowi potencjalne miejsce na odbiór; local balance to Twoja strona. Przyjęcie płatności przesuwa wartość ze strony zdalnej na lokalną. Zakup zdolności odbioru nie jest więc darem bitcoinów ani już uzyskanym przychodem. [Lightning Labs — Managing liquidity]

W uproszczonym kanale o 1000000 sat z local balance 800000 sat i remote balance 200000 sat miejsce brutto na odbiór wynosi 200000 sat, a nie milion. Przykład pomija rezerwy, opłaty i oczekujące HTLC. Samodzielne finansowanie bez początkowego transferu daje głównie miejsce na wysyłanie; potwierdzenie otwarcia nie odwraca kierunku. [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]

BOLT 2 ogranicza dodawanie HTLC rezerwami, minimalnymi kwotami, liczbą jednoczesnych HTLC i ich łączną niezakończoną wartością. Płatności w toku mogą czasowo wiązać środki. Sprawdzaj dostępne kwoty i limity każdego kanału; nie odejmuj jednej uniwersalnej rezerwy od sumy wszystkich sald. [BOLT 2 — Channel management]

BOLT 7 publikuje kierunkowe parametry channel_update, takie jak opłaty i htlc_maximum_msat, a nie gwarantowane bieżące saldo całej trasy. Niedostępny partner lub wcześniejsze wąskie gardło może zatrzymać płatność. Suma zdalnych sald nie gwarantuje więc przyjęcia takiej kwoty od konkretnego nadawcy. [BOLT 7 — Routing gossip]

Wychodząca płatność Lightning zmniejsza local balance i zwiększa remote balance użytych kanałów. Loop Out przenosi wartość Lightning na wyjście on-chain i może zwolnić miejsce na odbiór; Loop In uzupełnia środki do wysyłania. Bitcoiny nie powstają: uwzględnij koszty routingu, swapu i on-chain oraz wynik operacji. [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]

Partner może sfinansować kanał do Ciebie; na Lightning Pool bid kupuje płynność na określony czas, a ask ją oferuje. Okres wynajmu wyraża się w blokach. Zapłata premii i innych opłat nie przenosi całego zdalnego salda na Twoją własność ani nie zapewnia stałej dostępności po zakończeniu umowy. [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]

Circular rebalancing wysyła przez jeden własny kanał, a odbiera przez inny za pośrednictwem sieci. Kanał wysyłający zyskuje miejsce na odbiór, a odbierający je zużywa. Równoważenie nie tworzy kapitału i kosztuje opłaty routingowe; wymaga użytecznej trasy i samo nie rozwiązuje braku środków po wszystkich zdalnych stronach węzła. [Lightning Labs — Managing liquidity]

Przyjmowanie przychodów stale zamienia salda zdalne w lokalne i może wyczerpać miejsce na dalszy odbiór. Obserwuj użyteczne kanały, płatności w toku, koszty uzupełniania i spodziewane kwoty. Nieudana próba może być niewidoczna na węźle odbiorcy; wystawiona faktura ani stary odczyt pojemności nie potwierdzają zapłaty. [Lightning Labs — Merchant liquidity]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. Do tego hasła prowadzą również odsyłacze z Płynność Lightning, Lightning Routing, Lightning Address, Submarine Swap.

DOC · 001Lightning Labs — Managing liquidityDokumentacja ↗DOC · 002BOLT 2 — Channel managementSpecyfikacja ↗DOC · 003BOLT 7 — Routing gossipSpecyfikacja ↗DOC · 004Lightning Loop — Direction and channel balancesDokumentacja ↗DOC · 005Lightning Pool — Orders and leasesDokumentacja ↗DOC · 006Lightning Labs — Merchant liquidityDokumentacja ↗
Najpierw źródła · To nie jest porada inwestycyjna