Mit „off-chain, więc prywatny” Lightning: co badania akademickie ujawniły w 2026 r.

Przyjęte założenie i jego problem

„Lightning Network jest prywatny, bo transakcje są off-chain.” Ta fraza, powtarzana od 2018 r. w niemal wszystkich popularnych prezentacjach Bitcoin, jest technicznie prawdziwa, ale semantycznie myląca. Prawdziwa: tak, płatności między otwarciem a zamknięciem kanału nie dotykają blockchainu Bitcoin. Myląca: nie, brak zapisu on-chain nie wystarcza, by zapewnić prywatność w znaczeniu, w jakim się ją zwykle rozumie.

Badania akademickie z lat 2024-2026, w szczególności artykuł ScienceDirect „Timechain-level modeling and analysis of the Bitcoin Lightning Network”, studium uniwersyteckie przytoczone przez gncrypto na temat „Lightning Network economically irrational and has privacy shortcomings” oraz kilka pokrewnych publikacji, cierpliwie rozebrały, dlaczego to proste przeczucie nie wytrzymuje krytyki.

Sześć strukturalnych wycieków

1. Publiczny graf

BOLT 7, protokół gossip, rozsyła do węzłów sieci kanały ogłoszone wraz z ich pojemnością, parami i politykami routingu. Ta informacja jest publiczna z założenia i indeksowana w czasie rzeczywistym przez komercyjne crawlery. Ogłoszony kanał nie ma prywatności w sensie topologicznym.

2. Invoices BOLT 11

Standardowa invoice Lightning (BOLT 11) koduje w swoim rozwlekłym tekście: node ID odbiorcy, dokładną kwotę, payment hash, wygaśnięcie, opis. Odkodowanie invoice opublikowanej na stronie e-commerce, na Twitterze, w emailu to już uzyskanie znacznej części metadanych płatności.

3. Payment hashes w tranzycie

Każdy pośredni węzeł routujący HTLC widzi payment hash i następną destynację. Onion routing ogranicza zasięg, każdy węzeł widzi tylko od kogo i do kogo routuje, ale nie eliminuje korelacji. Atakujący kontrolujący wiele węzłów może zrekonstruować ścieżkę przez timing analysis i hash matching.

4. Channel announces i closes

Otwarcie i zamknięcie kanału to zwykłe transakcje on-chain. Choć nowsze formaty SegWit (Taproot, Schnorr) sprawiają, że channel funding transactions są nierozróżnialne od klasycznego płatności single-sig, wzorce użycia pozostają identyfikowalne: timing, symetryczne kwoty, co-spending.

5. Heurystyki płacącego / płaconego

Artykuł ScienceDirect formalizuje kilka heurystyk pozwalających obserwatorowi zaproponować hipotezę o pochodzeniu i przeznaczeniu płatności, nawet bez bezpośredniej kontroli nad węzłami pośrednimi. Na przykład: jeśli węzeł A ma malejącą pojemność wychodzącą o N satoshi w tej samej sekundzie, w której węzeł B ma rosnącą pojemność przychodzącą o N satoshi (modulo fees), A→B to racjonalna hipoteza. Te heurystyki nie są dowodami, ale działają z dokładnością 60-80% dla płatności średniej wielkości.

6. Usługi custodial

Wallet of Satoshi, Strike, Cash App i wszystkie portfele custodial widzą całość płatności swoich użytkowników i zachowują logi. Ten wyciek jest masowy i nie może być załatany przez ulepszenia protokołowe: to architektura custodial eksponuje, nie sam LN.

Trwające ulepszenia protokołowe

BOLT 12, offers

Wdrażany na LND v0.18 i CLN na początku 2026 r., BOLT 12 wprowadza nowy format trwałej invoice. Zamiast udostępniać unikalną invoice na płatność (która ujawnia node ID odbiorcy), odbiorca publikuje offer, trwałe odniesienie. Płacący, łącząc się z tym offer, otrzymuje route blinded, która kończy się u odbiorcy bez ujawniania jego node ID. To najbardziej znacząca strukturalna poprawa od lat.

Blinded paths

Pokrewny mechanizm BOLT 12: odbiorca może opublikować blinded path opisujący, jak do niego dotrzeć przez sekwencję węzłów pośrednich, bez widoczności tożsamości końcowej. Płacący komponuje routing używając zaślepionego końca ścieżki. Tak więc ani pochodzenie, ani przeznaczenie nie ujawniają sobie wzajemnie pełnego node ID.

Payment-point endpoint privacy

Nowsza praca (IETF / LND v0.19) bada użycie punktów kryptograficznych zamiast payment hashes dla płatności LN. Celem jest złamanie heurystyk opartych na hash matching między węzłami pośrednimi. To wciąż eksperymentalne w maju 2026 r.

Rzetelna praktyka w 2026 r.

Dla użytkownika chcącego płacić w LN z rozsądną prywatnością w 2026 r., suma tego, co działa, daje:

• Obowiązkowy wallet self-hosted, Phoenix, Blixt, Zeus z backendem LND/CLN self-hosted. Żadnego custodial.
• Węzeł działający w całości za Tor, jeden endpoint .onion eksponowany.
• Kanały prywatne domyślnie, bez announce chyba że musisz być publicznie routowalny.
• BOLT 12 offers do otrzymywania płatności bez publikowania swojego node ID.
• Wielokrotne ścieżki rebalance przez swap services i atomic swaps, gdy to możliwe.
• Świadoma akceptacja, że przeciwko dobrze wyposażonemu atakującemu komercyjnemu (Chainalysis, Elliptic) prywatność nie będzie absolutna; i że nigdy nie pretendowała do tego przeciwko atakującemu state-level.

Właściwe ujęcie

Lightning Network nie jest narzędziem prywatności w takim sensie, w jakim jest nim Monero. Jest narzędziem skalowalności z oknem prywatności proceduralnej, które zamyka się, gdy operator dokonuje wyborów domyślnych. Gdy ten artykuł mówi, że mit „off-chain, więc prywatny” nie wytrzymuje, nie jest po to, by zniechęcać do używania LN, ale by skalibrować oczekiwania. Dobrze skonfigurowany węzeł LN wciąż jest znacznie lepszy pod kątem prywatności niż karta bankowa, niż Stripe checkout, niż scentralizowana giełda. Po prostu nie jest równoważny Monero i nie będzie, dopóki trwające ulepszenia protokołowe nie osiągną pełnej dojrzałości wdrożeniowej.