Tragikomedia vol 2: Żeby otrzymać BTC z użyciem LN musisz być online. Nawet jeżeli nie wiesz, że masz je otrzymać

[devega]

Nie stanowi to problemu, bo przecież serwis akceptujący płatność musi i tak być online.

Niestety, ale stanowi, gdyż utrudnione będzie bezpośrednie przekazywanie środków pomiędzy 2 użytkownikami. W architekturze bez LN zaufana III strona nie jest potrzebna, tu (dla wygody) będzie powszechna. Czyli mamy kolejną instytucję a'la bank.

[rav3n_pl]

Tu też nie jest potrzebna w przypadku kanału pomiędzy dwiema stronami.

[devega]

@rav3n_pl,
Wyobrażam sobie sytuację, że Bitcoin staje się powszechnym sposobem płatności. A jednocześnie limit bloku nie ulega zmianie. Mamy więc 3 sposoby przesłania środków pomiędzy 2 użytkownikami:
1) Bez LN --> będzie mega drogi, tylko do b.dużych kwot
2) Z LN będąc online bez pośrednika --> dla większosci użytkowników będzie to kłopot
3) Z LN offline z pośrednikiem --> większosć użytkowników skorzysta z tego rozwiązania (kwestia wygody, świadomości, itp) --> mamy bank w erze blockchain.
Chyba, że coś pominąłem.

[garmont]

Rick Falkvinge rozbiera na czynniki pierwsze problem routingu w LN.
Zdaje się, że twórcy LN w ogóle to pominęli, albo wyobrażają to sobie jako coś w formie kilku grafów w formie gwiazdy, w którym wszystko będzie pośredniczone przez kilka węzłów centralnych w ramach kilku skoków...

[xnn]

@devega,
Jakby nie patrzeć cały ekosystem bitcoina jest zbudowany wokół pośredników. Klienty SPV, pośrednicy ecommerce jak bitpay, coinbase czy inpay... Giełdy (które jakby nie patrzeć są pośrednikami pomiędzy kupującymi a sprzedającymi). Jak dla mnie to naturalna kolej rzeczy, że pojawiają się pośrednicy, którzy ułatwiają pewne czynności. Ważne dla mnie jest natomiast to, że z łatwością będę w stanie zrezygnować z pośredników w LN gdy tylko będę tego chciał. Oczywiście nie mam tutaj na myśli pośredników przy routowaniu płatności

@garmont,
Jak dla mnie Rick nie odrobił kompletnie zadania domowego. Routing w LN przecież istnieje i działa. Powodów dla których wybrany został source routing jest natomiast kilka. Najważniejszy z nich to pełna kontrola nad pośrednikami przez nadawcę płatności - z oczywistych względów nie można tutaj zastosować podejścia znanego z BGP i oddania kontroli nad routingiem poszczególnym "nodom-routerom" bo te, mogłyby routować płatność przez chociażby stworzone przez siebie nody, które posiadają wysokie opłaty. Co więcej, jest kilka pomysłów jak usprawnić routing tyle, że nikt na obecną chwilę z "oficjalnych" devów nie podejmuje tematu bo są inne ważniejsze rzeczy do zrobienia. Jak dobrze pamiętam, Flare z 2016r uzyskał 80% skuteczność w znalezieniu odpowiedniej ścieżki w przeciągu 1/2 sek. A od 2016r pojawiło się kilka nowych pomysłów...

[rav3n_pl]

@garmont, smacznego: https://www.robtex.com/lightning/path/
Routing nie działa xD
Każdy węzeł ma listę kanałów i jest w stanie zrobić sobie graf ile i komu może wysłać. Takie proste.

[ShadowOfHarbringer]

@garmont, smacznego: https://www.robtex.com/lightning/path/
Routing nie działa xD

Nie, nie działa.

Rozsyłanie informacji o routingu od wszystkich do wszystkich, to nie jest "routing".

Routing to jest praktycznie największy problem akademicki do rozwiązania w informatyce od 60 lat. Podkreślam - do dzisiaj nie rozwiązany.

Jeżeli twórcy LN rozwiązaliby problem routingu, to Internet nie potrzebowałby centralizacji aby osiągnąć działający routing i można by przebudować internet tak aby był zdecentralizowany.

Jak widać nie wiesz tego, że routery BGP - podstawa dzisiejszego internetu działają z użyciem centralnych punktów sterowania i wymagają zaufania, hmm ?

Z Lightning Network jest jeszcze gorzej, bo oprócz problemu normalnego routingu, musisz rozwiązać problem płynności. LN to praktycznie antygrawitacja. Problem nie rozwiązany i który prawdopodobnie nie będzie rozwiązany przez najbliższe 20-30 lat.

LN to jest tak potworne bajkopisarstwo, że nie wiadomo czy się śmiać czy płakać. Niezrozumiałe dla mnie jest dlaczego inteligentni ludzie dają się nabierać na takie sranie w banie.

[xnn]

Nie, nie działa. Rozsyłanie informacji o routingu od wszystkich do wszystkich, to nie jest "routing".

Możesz zaklinać rzeczywistość, ale source routing (path forwarding) to też algorytm routowania: https://en.wikipedia.org/wiki/Category: ... algorithms. W przypadku LN rzeczywiście routing nie działa perfekcyjnie tzn. nie za każdym razem oprogramowanie wybierze za pierwszym podejściem najbardziej optymalną ścieżkę... tyle, że to perfekcyjne podejście nie jest wcale potrzebne by sieć funkcjonowała. Bitcoin czy Bitcoin Cash też nie działa w sposób perfekcyjny jednak nie przeszkadza im to funkcjonować.

[ShadowOfHarbringer]

Nie, nie działa. Rozsyłanie informacji o routingu od wszystkich do wszystkich, to nie jest "routing".

Możesz zaklinać rzeczywistość, ale source routing (path forwarding) to też algorytm routowania

Nikt nie zaklina rzeczywistości, tylko jakiś żółty użytkownik wpadł do tego tematu, nie jest w kontekście i wyskakuje nagle z jakimś zaklinaniem czegoś.

Cały czas rozmawiamy o zdecentralizowanym routingu, a nie byle jakim routingu. Wynika to z kontekstu dyskusji, który Ty oczywiście olałeś bo tak Ci było wygodnie.

Bez zdecentralizowanego routingu, LN może istnieć tylko i wyłącznie jako zabaweczka dla banków.

: https://en.wikipedia.org/wiki/Category: ... algorithms. W przypadku LN rzeczywiście routing nie działa perfekcyjnie tzn. nie za każdym razem oprogramowanie wybierze za pierwszym podejściem najbardziej optymalną ścieżkę... tyle, że to perfekcyjne podejście nie jest wcale potrzebne by sieć funkcjonowała.

Niestety, perfekcyjne działanie routingu jest koniecznym warunkiem aby sieć LN była zdecentralizowana.

Co oczywiście nie jest możliwe do osiągnięcia, dlatego właśnie Satoshi Nakamoto zamiast szukać rozwiązania zdecentralizowanego routingu, co jest prawdopodobnie nierozwiązywalne w prosty sposób (jak antygrawitacja), zrobił system gdzie wszystko rozsyła się do wszystkich i zdecentralizował system używając innej sztuczki - Proof Of Work.

Dzięki Proof Of Work oraz miningu, nie ma potrzeby szukania żadnej ścieżki i rozwiązywania problemu routingu, bo każdy node w sieci zna pełną historię transakcji. Jeżeli ktoś spróbuje oszukać i np. przechwycić komunikację w drodze, nie ma to znaczenia, bo Proof Of Work obroni system przed atakiem.

[janku66]

Cały czas rozmawiamy o zdecentralizowanym routingu, a nie byle jakim routingu

Jaka sieć, taki routing.

[xnn]

@ShadowOfHarbringer,

perfekcyjne działanie routingu jest koniecznym warunkiem aby sieć LN była zdecentralizowana.

Dlaczego?

//edycja, usunalem nieprecyzyjny fragment o routingi/

[rav3n_pl]

Zdecentralizowany routing nie może działać, bo nadawca nie znałby ostatecznej opłaty transakcyjnej.
Nadawca wybiera trasę, dołącza wymaganą przez węzły pośredniczące opłatę i wysyła zapakowany komnuikat do pierwszego hopa. Pierwszy węzeł rozpakowuje swoją część, widzi komu ją przekazać i przekazuje. I tak dalej aż do odbiorcy.
Odbiorca potwierdza otrzymanie kasy i kaskadowo węzły pośredniczące przekazują i rozgłaszają nowy stan kanałów pośredniczących.
Każdy wie tylko o swoim kawałku (od kogo dostał i komu wysłał).

[janku66]

bo nadawca nie znałby ostatecznej opłaty transakcyjnej

Dlaczego? Skoro routing jest określony, to wiemy jakie opłaty pobierane są przez poszczególne huby?

Nadawca wybiera trasę

Chyba bardzo w domyśle, to nadawca wybiera? Nie dzieje się to przez jakiś program automatycznie?

Odbiorca potwierdza otrzymanie kasy i kaskadowo węzły pośredniczące przekazują i rozgłaszają nowy stan kanałów pośredniczących

Co się dzieje gdy w trakcie przebiegu transakcji coś się wydarzy? Czyli np dwa huby pobrały swoje fee, a trzeci nagle zrobił się offline? Wtedy trzeba wybrać nowy routing, a i tym samym ponownie przeliczyć fee i odebrać opłaty Hubom co już ją pobrały, czy się mylę?

[ShadowOfHarbringer]

Zdecentralizowany routing nie może działać

[youtube][/youtube]

Dyskusja jak dla mnie zakończona.

[janku66]

Dyskusja jak dla mnie zakończona.

Raven sam podał nam w dłoń mizerykordie.

[xnn]

Dlaczego? Skoro routing jest określony, to wiemy jakie opłaty pobierane są przez poszczególne huby?

Zgadza się, tak jest w przypadku source routingu.

Chyba bardzo w domyśle, to nadawca wybiera? Nie dzieje się to przez jakiś program automatycznie?

Zgadza się. Chodzi o to, że masz swobodę w wyborze trasy do odbiorcy płatności. W przypadku zdecentralizowanego routingu (typu właśnie BGP) nie miałbyś takiej swobody, nie znałbyś opłat transakcyjnych, nie wiedziałbyś czy np. dany router specjalnie kieruje Twoją płatność przez swoje nody z wysokimi opłatami czy też specjalnie failuje płatność z wyłącznie znanych jemu powodów.

Co się dzieje gdy w trakcie przebiegu transakcji coś się wydarzy? Czyli np dwa huby pobrały swoje fee, a trzeci nagle zrobił się offline? Wtedy trzeba wybrać nowy routing, a i tym samym ponownie przeliczyć fee i odebrać opłaty Hubom co już ją pobrały, czy się mylę?

Gdy coś się złego wydarzy - odbiorca nie otrzymuje monet a nody pośredniczące opłaty za pośrednictwo. Nadawca oczywiście nic nie traci. Opłaty pobierane są w momencie końcowego przetwarzania płatności. Klient wysyłając płatność (próbując ją routować) wie jakich fee się spodziewać i na podstawie tej wiedzy, oraz wiedzy na temat pojemności kanałów wybiera ścieżkę. Tutaj wypadałoby nadmienić, że znana jest wyłącznie zablokowana ilość monet po obu stronach kanału co utrudnia wyszukiwanie trasy (nie mamy pełnej wiedzy na temat płynności) ale zwiększa poziom prywatności zapobiegając prostej analizie sieci poprzez analizę stanów kanałów.

[rav3n_pl]

@vjankuv, Dopóki odbiorca nie potwierdzi otrzymania nic się nie stało.
Jeżeli któryś węzeł pośredniczący się opóźnia (brak potwierdzenia w określonym czasie) wybierana jest inna droga.
Mając "pod ręką" graf połączeń można bez problemu zrobić kilka ścieżek (w zależności od ilości hopów i połączeń węzłów).
Pobaw się https://www.robtex.com/lightning/path/ żeby znaleźć węzły z jednym połączeniem do sieci, zazwyczaj jest i tak więcej niż jedna ścieżka.

[wrip]

Czy w LN istnieje jakaś kolejka transakcji? Jeśli mamy stały zbiór użytkowników i połączeń między nimi i jeśli trzeba obliczyć trasę z punktu A do punktu B to nie da się obliczać jednocześnie kilku różnych tras, bo z każdym obliczeniem każdej trasy zmieniają się salda użytkowników.

Jeszcze gdyby to był faktycznie scentralizowany system to mógłby on analizować, że aktualne transakcje nie kolidują ze sobą, tzn nie mają wspólnych punktów, wtedy faktycznie można robić wiele tras jednocześnie, ale jeśli ma to być zdecentralizowane, gdzie nikt nie wie nic poza tym co do niego przychodzi i co z niego wychodzi, to ja nie mam pojęcia jak to jest rozwiązane.

Więc musi istnieć kolejkowanie transakcji, gdy realizowana płatność wymaga więcej niż 2 stron tj.: z A do C przez B, bo w przypadku prostym czyli: A do B nie ma problemu.
Jak więc w ogóle to może być wydajne? Ile w ogóle czasu zajmuje obliczenie trasy i zrealizowanie transakcji? A jeśli jedna transakcja się opóźnia, bo są jakieś zakłócenia sieci, ktoś traci połączenie albo ma wysoki ping, albo trzeba wybrać nową trasę itd, to przecież jedna transakcja może przeciągnąć się do kilku sekund nawet.

[rav3n_pl]

Kolejki raczej nie ma.
Węzeł na bieżąco zbiera informacje o stanach kanałów i jak dostanie rozkaz "zrób transakcję" to szuka ścieżki wg swojej wiedzy.
Przeszukanie grafu to ułamek sekundy, faktycznie długie pingi mogą być przeszkodą.
Jak jest fail to ponawia inną drogą.

[wrip]

@rav3n_pl, ale jeśli 2 transakcje wykorzystują te same węzły no to nie ma szans, musi być kolejka.