Christian Decker

Szukając prac Deckera, trafimy na konto cdecker i nazwę Snyke. Podczas sprawdzania w październiku 2026 roku jego publiczny profil wskazywał również Blockstream. Pomaga to połączyć autora z kodem i propozycjami, ale sam krótki opis nie potwierdza aktualnego stanowiska. W otwartej sieci liczy się problem, który propozycja rozwiązuje, oraz wyniki jej oceny. Nazwisko ani pracodawca nie dają prawa do zmiany zasad wszystkim pozostałym. [1]

Nowy blok rozchodzi się etapami: jeden komputer przekazuje go kolejnym, a transmisja trwa. Christian Decker i Roger Wattenhofer zmierzyli ten proces w badaniu z 2013 roku. Analizowali propagację transakcji i bloków oraz związek opóźnień z chwilowymi rozgałęzieniami łańcucha, gdy części sieci pracują na różnych nowych blokach. Te historyczne pomiary wyjaśniają praktyczne działanie sieci. Nie opisują jej dzisiejszej szybkości, bo od tego czasu zmieniły się programy i metody przesyłania danych. [2]

W kanale płatniczym uczestnicy na bieżąco uzgadniają, jaka część wspólnie zablokowanych środków należy do każdego z nich. Co jeśli przy zamykaniu ktoś użyje starszej, korzystniejszej dla siebie umowy? Autorzy propozycji eltoo — Decker, Rusty Russell i Olaoluwa Osuntokun — opisują możliwość zastosowania nowszego stanu przed końcowym rozliczeniem. To jak zastąpienie nieaktualnego rozrachunku ostatnim uzgodnieniem. Jest to proponowany mechanizm, a nie funkcja obecna automatycznie w każdym dzisiejszym kanale Lightning. [3]

Sama możliwość poprawienia starego stanu nie wystarczy. W eltoo transakcja korygująca musi zostać potwierdzona, zanim stary stan będzie można rozliczyć. Czas na reakcję daje OP_CSV: określone wydanie środków staje się możliwe dopiero po wymaganym okresie od potwierdzenia danego wyjścia. Dlatego łańcuch musi obserwować użytkownik lub upoważniona usługa. Propozycja zmienia sposób postępowania ze starymi stanami, ale nie czyni bezpiecznym pozostawania offline przez nieograniczony czas. [3]

Zastosowanie nowego uzgodnienia wobec różnych starszych stanów wymaga odpowiednich zasad podpisu. BIP 118 autorstwa Deckera i Anthony’ego Townsa proponuje SIGHASH_ANYPREVOUT. Przy sprawdzaniu w październiku 2026 roku dokument miał status Draft, czyli projektu. Opisuje zmianę konsensusu przez soft fork: zmianę zasad, według których węzły sprawdzają Bitcoin. Publikacja ani poparcie programistów nie dowodzą aktywacji. Propozycja, napisanie kodu i przyjęcie przez sieć to osobne etapy. [4]

Zwykle podpis wiąże się również z konkretnym wcześniejszym wyjściem transakcji, które wydajemy: kwotą wraz z warunkami jej wydania. BIP 118 rozluźnia to powiązanie w wybranym trybie. Podpisaną transakcję można wtedy powiązać z innym zgodnym wyjściem, co pomaga zastąpić stary stan kanału. Nie pozwala to wydawać dowolnych cudzych pieniędzy. Szersze możliwości ponownego użycia podpisu wymagają jednak ostrożnego projektu. Zależnie od trybu znaczenie mają też powiązania z kwotą i warunkami wydania. [4]

Prowadzenie własnego węzła Lightning wymaga bieżącej obsługi. Blockstream ogłosił publiczne uruchomienie Greenlight 12 października 2023 roku, przedstawiając Deckera jako kierownika projektu. Zadania rozdzielono: użytkownik przechowuje klucze prywatne, a usługodawca obsługuje infrastrukturę węzła. Klucz prywatny pozwala autoryzować wydanie środków; jego posiadanie nie jest tym samym co prowadzenie serwera. Taki model nie gwarantuje nieprzerwanej dostępności ani niezmiennych warunków handlowych. Te kwestie trzeba oceniać osobno. [5]

Core Lightning to program służący do prowadzenia węzła Lightning. Wtyczki rozszerzają go według potrzeb operatora, a reckless pomaga je instalować i uruchamiać. To inna zmiana niż nowe zasady podpisu w Bitcoinie. Samo zainstalowanie wtyczki nie dodaje BIP 118 do reguł całej sieci. Praca Deckera łączy badania, propozycje protokołu i praktyczne narzędzia, ale każda z tych dziedzin ma własną drogę od pomysłu do zastosowania. [6]