Beszélgessünk még egy kicsit a Lightning Networkről…

Tudom sokatoknak már a könyökén jön ki az LN, de a jelek szerint mégis szükséges és érdemes is beszélni róla. Főleg, ha azzal szembesülök, hogy a blog egyik legrégebbi aktív követője is a sötétben tapogatózik. Ezek szerint messze nem végeztem még teljes munkát a LN evangelizációja kapcsán. Az alábbi (minap) született hozzászólás ösztönzött, hogy elkészüljön ez a post:

Lightning Network:
Jól értem, hogy igazából már működik, megy, használható?

Amit össze tudok rakni infót:
– Mainneten kint van, bárki futtathatja – ha van bátorsága
– Bátorság kell hozzá, mert nincs még agyontesztelve, így simán benyelheti a rajta levő pénzt
– Nem egy implementáció van, hanem három – ezt nem értem, hogyan lesz akkor “egy” LN. Vagy mindegy? Egymással kompatibilisek? Aztán mindenki azt használja, amelyik szimpatikusabb?
– Nincs “hivatalosa release date”, hiszen már kint van és szép lassan elkezd terjedni.

Izgalmas év lesz az idei (is).

Előbb gyorsan tisztáznám a félreértéseket:

  • A Lightning Network már nagyon régóta a mainneten volt teszt jelleggel és most is leginkább ilyen állapotban van kint, azonban senki és semmi nem tudja befolyásolni annak a terjedését, tehát nem meglepő hogy néhány lelkes pioneer már elkezdett rá éles szolgáltatásokat építeni.
  • A cikk írásának a pillanatában 48 aktív LN node található a mainneten, melyek között 76 csatorna létezik. Ezek összesített kapacitása 0.881 Bitcoint (kb 10k dollár jelenlegi árfolyamon)
  • Nem három implementáció létezik csak, hanem ennél sokkal több. Az implementációk alapja a LN whitepaperből készült specifikáció: Basis of Lightning Network (BOLT), mely egy 11 fejezetes részletes specifikáció, hogy miként kell LN implementációt készíteni.
  • A három leginkább elterjedt implementáció (lnd, c-lightning és a eclair) teljes mértékben interoperábilis, tehát ezek képesek egymással stabil kapcsolatokat létesíteni. A mainneten jelenleg mindhárom implementáció stabilan működik egymással.
  • A különböző implementációk oka nagyon egyszerű: független fejlesztőcsapatok kezdték el anno implementálni a saját LN elképzelésüket. Ez a fajta függetlenség a garancia arra, hogy nem egy centralizált maszlagot kapunk amit tetszőleges pillanatban tud bárki befolyásolni, hanem mindig megmarad a garancia arra, hogy az LN egy ugyanolyan független és érdek nélküli rendszer marad mint maga a Bitcoin.
  • Az LN underlying technológiái már régóta benne vannak a Bitcoin protokollban, a szükséges funkciók (HTLC, multisig wallet, stb.) már évek óta használt technológia, nagyon sok aktív payment channel létezett már eddig is. A technológiához szükséges utolsó mozaik maga a segwit protokoll volt. Most, hogy végre bekerült a hivatalos bitcoin core implementációba is a segwit támogatás, így teljesen logikus, hogy pillanatok alatt elkezd gyarapodni a mainnet LN hálózat.
  • Az LN olyan szinten van agyontesztelve, ahogy kb eddig semmi nem volt agyontesztelve a Bitcoin történelmében. Talán csak a SegWit tesztelése összemérhető az LN-nel. Mindkét technológia nagyon durván nyúl bele a settlement layerbe, így ezek tesztelése létszükséglet, hiszen itt szó szerint pénzzel játszunk.
  • Benyelni semmilyen pénzt nem tud az LN hálózat. A kockázat más rétű ennek kapcsán. A felek felépítik a csatornáikat, majd azokat karbantartják, de annak változásait nem küldik be a blokkláncra (onchain). A pénzbeli kockázat ezen offchain karbantartásban rejlik csak jelenleg. Ugyanaz a kockázat létezik jelenleg, mint amilyen kockázattal maga a Bitcoin rendelkezett 2009-ben. Akkor még senki nem bízott abban, hogy itt valóban nem tudnak coinok elkeveredni, avagy valóban nem lehet double-spendingelni. Voltak is bőven korai bakik, amikből akár anyagi károk is keletkeztek. Ugyanezen anyagi kockázat létezik az LN kapcsán is. Előbb pici szereplők fognak megjelenni az LN-en és árulják majd a filléres portékáikat, ahol nincs lényei nagy veszteség egy tech probléma miatt, majd ahogy bizonyít (és fejlődik a technológia) úgy fognak megjelenni az egyre nagyobb szereplők is.

Némi resource azoknak, akiket a leírásomon túl is érdekel mindez:

Most, hogy ezeken túl vagyunk egy régebbi adósságomat is törleszteném. Ígértem, hogy megosztom a néhány hete megtartott Lightning Network Unchained előadásom prezentációját és ha már megteszem, akkor hozzáfűznék némi magyarázatot is a slideokhoz:

Az ábrán a látható, hogy milyen módon lehet használni onchain (layer1) és offchain (layer2) a Bitcoin hálózatot. A cél az lenne, hogy Alice elküldjön 0.003 Bitcoint Bobnak. Ezt megteheti onchain (blokklánc művelettel), aminek a költsége 0.001 Bitcoint lesz és nagyjából 1 órát kell várniuk arra, hogy teljes mértékben teljesüljön is (confirmation – Miért fontos a ‘6-confirmation’?) Köszönhetően a Lightning Networknek immáron Alice ugyanezt az összeget elküldeni Bobnak a Lightning Networkön keresztül is, ennek várható költsége alig néhány satoshi lesz (0.000001 btc körül) és a felek között a művelet azonnal teljesül. Tehát Bob a 0.03 Bitcoin megérkeztének pillanatában már azt el is tudja költeni. Persze, ha létezne Alice és Bob között közvetlenül felépített payment channel, akkor még csak a Lightning Networkre sem lenne szükségük ehhez, de az LN abból a filozófiából épül fel, hogy csak nem építhetsz fel mindenkivel kapcsolatot, sokkal logikusabb, hogy véges számú fontosabb/nagyobb hubbal van csak fizetési csatornád. (payment channel)

Az ábrán jól látható, hogy mivel Alice és Bob között nincs direkt fizetési csatorna, ezért az utalás Carol->Dave és Eve-n keresztül route-olódik.

Belenézve a csatornákba jól látható az, hogy az egyes nodeok között milyen fizetési csatornák léteznek. Ezek a csatornák egy-egy korábban létesített onchain (blokkláncon végrehajtott) tranzakció eredményei, melyből látható, hogy például Alice és Carol között egy egyoldalú csatorna található, melynek megnyitásakor Alice 0.1 BTC-t rakott be a csatornába, Carol pedig nullát. Tehát ezen a csatornán a kezdetben csak Alice tud pénzt küldeni.

Ugyanígy felsorolva látható minden csomópont között a csatornák kezdeti állapota is. Fontos megjegyezni, hogy a single way csatorna nem azt jelenti, hogy azon egész idő alatt csak az egyik fél küldhet pénzt. Vegyünk ehhez egy egyszerű példát:

  • Alice és Carol között létezik az alapértelmezett csatorna, amit Alice 0.1 BTC-jével nyitottak meg a felek úgy, hogy Carol nem adott bele semmit. Ekkor a csatornában Alicenek van 0.1 BTC-je, Carolnak pedig 0 BTC-je.
  • Alice elküld Bobnak (Carolon keresztül) 0.003BTC-t. A sikeres routing után az Alice-Carol közötti csatorna állapota: Alice: 0.097BTC, Carol: 0.003BTC).
  • Majd egy későbbi pillanatban Eve úgy dönt, hogy szeretne küldeni Alicenek 0.001BTC-t és ehhez az Eve->Dave->Carol->Alice útvonalat választja. A sikeres küldés esetén az Alice-Carol fizetési csatorna egyenlege: Alice: 0.098BTC, Carol: 0.002BTC.

Mi történne abban az esetben, ha Eve nem 0.001BTC-t akart volna küldeni, hanem mondjuk 0.003BTC? Ebben az esetben az Eve->Dave->Carol->Alice útvonal nem tudott volna működni, hiszen az Alice-Carol fizetési csatornán Alice irányába csak 0.003 BTC  likviditás létezik, így a fizetési megbízás nem teljesíthető. De amennyiben létezik a hálózaton keresztül egy másik oldal útvonal, ahol van elégséges likviditás, akkor ez minden gond nélkül teljesülhetett volna. (lásd ábrát, ahol Eve és Alice között több más útvonal is létezik)

Gyakran előkerül a Lightning Network kapcsán a centralizáció kérdése, mely szerint az LN a nagy bankok által pénzelt vállalkozás és egyetlen célja a kontroll és a centralizáció. Egy gráfban leképződő hálózatban, ahol bármely csomópont tud kapcsolódni bármely csomóponthoz és ezen kapcsolódás permissionless, ott mégis milyen elv vezethet a centralizációhoz? Jól látható már ezen a pici ábrán is, hogy Alice és Bob között számtalan útvonal található. Csak a felcímkézett nodeokat elnézve öt különböző útvonal azonosítható.

A Lightning Network hálózat valójában véges számú node között fenntartott fizetési csatornák hálózata, ahol a felek úgy továbbítják az utalásokat, hogy ezzel pont-pont módon a saját fizetési csatornáik egyenlegét aktualizálják. Tehát akkor, amikor Alice utal pénzt Bobnak és ehhez az Alice->Carol->Dave->Eve->Bob útvonalat választja, akkor – sikeres továbbítás esetén – mind az öt szereplő között létező fizetési csatorna állapota frissül az utalt összeggel.

Az előzőekben kifejtettek jól látható a fentebbi ábrán is.  Itt Alice és Carol között már egy újabb csatorna látható, amiben mindkét félnek van likviditása. A csatorna teljes kapacitása 1,000,000 satoshi (0.01 BTC). A két oldal egyenlege: Alice: 50404 sat, Carol: 931496. Látható, hogy történt is már tranzakció a csatornán, hiszen az összesen 245 alkalommal frissült és 0 sat küldése mellett 404 sat érkezett rajta. Látszik továbbá, hogy a csatorna későbbi zárolása várhatóan 18,100 sat mining fee-be fog kerülni (0.000181 BTC), melynek az onchain weightje 724 byte lesz. Persze mivel a csatorna bőven likvid a két fél között, így nem kizárt, hogy mire letárják azt, addig Alice boldogan fog akár több bitcoinnyi mikrotranzakciót is végrehajtani rajta. (amihez persze kell az, hogy Alice kapjon is a csatornán keresztül bitcoint, hiszen annak totál kapacitása 0.01 BTC.)

Mivel az LN-en a felek közötti PONTOS egyenleget csak a konkrét felek ismerik, ezért nagyon kritikussá válik a bizalom kérdése. A korábbi példánál maradva Alice küldött Bobnak 0.03 BTC-t Carolon keresztül. Ilyenkor az Alice és a Carol közötti egyenleg módosult 0.03BTC-vel, tehát az onchain állapothoz képest Alicenek valójában már 0.03BTC-vel kevesebb pénze van csak, ám erről a tényről csak Alice és Carol tud (plusz közvetetten persze még Dave, Eve és Bob is). Mi a garancia arra, hogy Alice később nem fogja letagadni ezt a tranzakciót a csatorna zárásakor?

  • Amikor Alice pénzt utal Bobnak Carolon keresztül. Akkor Alice és Carol elkészít egy véglegesnek szánt tranzakciót, amiben mindketten elismerik, hogy Alicenek immáron 0.03-BTC-vel kevesebb pénze van, Carolnak pedig pont ugyanennyivel több pénze van. Ez egy véglegesnek szánt tranzakció, amit később bármelyik fél be tud küldeni onchain a blokkláncba, ezzel véglegesítve és lezárva a felek közötti fizetési csatornát és elszámolva annak záró egyenlegét.

Adja magát a kérdés, hogy mi történik akkor, ha Alice a Bobnak küldött 0.03BTC mellett később küld Gracenek is 0.01BTC-t, amihez persze alá is írja az aktualizáló tranzakciót Carollal, DE ahelyett, hogy a záráskor ezen utolsó tranzakciót küldené a blokkláncba, ő inkább a korábbi állapotot küldi be, ahol neki még 0.01BTC-vel több pénze volt. Vajon hogyan védekezik ez ellen a Lightning Network?

Egy payment channel csak akkor zárható le instant, ha annak végső egyenlegéről a felek egy végső lezáró trazankcióval (channel close tx) megegyeznek. Ezen channel close transactiont követően (miután aláírásra került az mindkét fél részéről), már NEM lehet updatelni annak egyenlegét. Azt bármelyik fél beküldheti a blokklánba, ami a 6-confirmationt követően már szabadon hozzáférhető egyenleg lesz mindkét fél részére. Ha valamelyik fél nem hajlandó együttműködni a lezáráshoz, akkor bármelyik fél kezdeményezheti a “forced payment channel close” folyamatot, amihez elégséges beküldeni az utolsó commitment transactiont. Azonban ilyenkor a fizetési csatorna bezárásra rákerül egy time lock (mainneten 1 hét), amely idő alatt a következő scenariok lehetségesek:

  • A fizetési csatorna partner továbbra sem együttműködő, ezért az 1 hét elteltével a beküldött commitment transactionnek megfelelő egyenleggel kerül lezárásra a csatorna
  • A partner mégis együttműködővé válik, és hajlandó aláírni a channel close transactiont. Ilyenkor azonnali settlement történik a 6-confirmation után.
  • A partner észreveszi, hogy az egyoldalú lezárás történt és ráadásul egy korábbi commitment tx került beküldésre, tehát csalás esete forog fenn.

Ilyen csalás esetén sincs persze semmi gond, hiszen a partner kezében ott van az utolsó valid commitment tx, mely tartalmaz egy “revokeHash” klauzulát. A revokeHash lényege, hogy amikor a felek aláírják a legfrissebb (utolsó) commitment tranzakciót, akkor ezzel invalidálják a korábbi commitment tranzakciók hashét is, így bár tény, hogy a commitment tranzakciók CSAK a fizetési csatorna partnerek között léteznek, ám mégsem lehet csalni az egyenleggel, mivel a csalás ténye technológiailag kivédésre kerül a korábbi (már nem érvényes) commitment tx-ek invalidálásával. Tehát a fenti esetnél maradva, ha Alice egyoldalúan megpróbálja lezárni az Alice-Carol közötti csatornát, ráadásul egy korábbi commitment tx-szel, akkor Carolnak egy hete van arra, hogy beküldje a valódi utolsó commitment tx-et, amivel egyrészt invalidálja Alice csalási próbálkozását, másrészt pedig egyértelmű bizonyítékot szolgáltat arról, hogy Alice megpróbált csalni. A blokklánc nem felejt… Ezt követően Alice minden bizonnyal elbúcsúzhat az egész Lightning Networktől…

Szintén érdekes kérdés lehet, hogy mi a helyzet a köztes szereplők bizalmával? Maradva az Alice->Carol->Dave->Eve->Bob útvonalnál: mi a helyzet akkor, ha Dave “elnyeli” az utalást, vagy mondjuk Eve megpróbálja azt ellopni:

  • Dave elnyeli a pénzt: Ez olyankor lehetséges, ha Daven keresztül már felépül a folyamat, David eljut az utalás, azonban Dave szoftver hiba, vagy hálózati gubanc miatt már nem tudja tovább küldeni azt Evenek. Ilyenkor szegény Alice pénzt “beragad” Davenél. Itt szintén a HTLC timelock funkciója lép be. Ha Dave nem tudja a tranzakciót adott időn belül tovább küldeni, akkor a tranzakció invalidálódik az összes köztes szereplőnél, tehát Alice visszakapja a sikertelenül elküldött 0.03BTC-jét, amit egy másik útvonalon keresztül el tud küldeni Bobnak.
  • Eve megpróbálja ellopni a pénzt: Amikor Alice úgy dönt, hogy küldeni akar Bobnak 0.03BTC-t és ehhez a trustless LN networköt akarja használni, akkor készít előbb egy shared secretet, amit megoszt Bobbal, ezt a megosztott titkot csak Alice és Bob ismeri. Alice a tranzakciójánál ráhasheli arra ezt a bizonyos shared secretet is, aminek hatására annak értékéhez ténylegesen csak Bob fog tudni hozzáférni. Tehát ha Eve úgy dönt, hogy ő bizony nem küldi tovább a 0.03BTC-t Bob felé, hanem az utolsó Dave->Eve közötti commitment tx segítségével beküldi azt a blockchainbe, ezzel ellopva Alice 0.03BTC-jét, akkor bizony szinte azonnal invalidálódik is a tranzakció, hiszen Eve nem ismeri az Alice és a Bob közötti shared secretet, mivel azt vele senki nem osztotta meg. Így szegény Eve nem csak a 0.03BTC-t bukja, de az addig virágzóan működő payment hub üzletét is, hiszen ezt követően lesheti, hogy ki fog vele újabb fizetési csatornákat felépíteni.

A blockchain (onchain, layer1) fizetési szolgáltatások nagyon körülményesek. Ha kiraksz a honlapodra egy bitcoin address-t, akkor honnan fogod tudni, hogy arra pontosan ki utalt? Ugye csak annyi látszik,hogy mi a forrás address és mennyi az összeg, de pl nem tudhatod, hogy a beküldött 0.001BTC-ből ő most egy kék pulcsit akart venni, vagy egy doboz kávékapszulát. Ezt a problémát hivatott megoldani pl. a HD wallet (BIP32/BIP39), ami lehetővé teszi, hogy egy fixen létező 12 vagy 24 szavas seed segítségével generálj instant egy bitcoin addresst, amit ezt követően egy konkrét vásárlásnál tudsz megadni mint fogadó címet, így már biztos lehetsz abban, hogy az oda érkező pénzt ki küldte és mit is rendelt tőled.

Persze ehhez vagy az kell, hogy a privát kulcsodhoz tartozó seed online elérhető legyen, vagy pedig offline kell legenerálnod több ezer/tízezer address-t, függően az üzleted nagyságától. Mindez nagyon bonyolult és időigényes, ráadásul bonyolultabb üzlet esetén a nyomon követhetőség is komoly gondokat okozhat. Éppen ezért a legtöbb ilyen üzlet már valamilyen payment providert használ (pl. BTCpay, Bitpay, CoPay, stb.) akik nyilván borsos költségek mellett átvállalják ennek az ügymenetét.

Ezen a folyamaton a Lightning Network egy huszárvágással egyszerűsít. Amikor LN-en akarsz utalni, akkor nem egy fix címre utalsz, hanem egy invoice-t (számlát) egyenlítesz ki. Az invoiceokat az LN node tudja generálni, amely invoice tartalmazza a payment channelt, amihez az tartozik. Emellett tartalmazza az összeget és tartalmaz egy tetszőlegesen használható memo/description mezőt, amibe azt írhatsz amit csak akarsz. Minden invoicenak egyedi azonosítója van, így azt könnyedén össze tudod kötni a konkrét vásárlással.

A fenti ábrán három lnd művelet eredménye látható (pirossal megjelölt parancsok), ezek:

  • addinvoice: egy új számlakérő generálása, megadott paraméterekkel.
  • decodepayreq: egy legenerált számlakérő (invoice), visszafejtése elemi paraméterekre.
  • payinvoice: egy számla kifizetése. Látható, hogy a számlát nem direktben, hanem 2 hoppon keresztül fizette ki a rendszer.

Ennyire “egyszerű” a Lightning Network 🙂

Alább pedig az előadáson készült videofelvétel. A videó hangminőségéért mindenkitől elnézést kérünk, egyelőre még szűkösek a Blokklánc Műhely adta lehetőségek, de ezen is folyamatosan fejleszt a csapat! A ma esti előadáson már sokkal jobb minőségű képi és hanganyag fog várhatóan készülni. (és én is megpróbálok némileg összeszedettebb lenni 🙂

Ui: Mire a cikket befejezetem a LN mainnet a bitcoin hálózaton már 49 nodera (+1) 78 csatornára (+2) bővül, melyek összes kapacitása már 0.982 Bitcoin… Mindezt alig 2 óra alatt…

 

Bookmark the permalink.

52 Comments

  1. Nicehashről Coinbasere azonnal utalódik a BTC, költségmentesen. Lehet LN -t használnak?

    • nem, ott a coinbase belso rendszere adja hozza az accountodhoz ez erteket, ahogy pl a valtoknal is kapsz btc-t ha eladsz valamit

  2. Jól értem, hogy az LN hálózaton végrehajtott tranzakciót végrehajtják a bitcoin hálózaton is?

    “Amikor Alice pénzt utal Bobnak Carolon keresztül. Akkor Alice és Carol elkészít egy véglegesnek szánt tranzakciót, amiben mindketten elismerik, hogy Alicenek immáron 0.03-BTC-vel kevesebb pénze van, Carolnak pedig pont ugyanennyivel több pénze van. Ez egy véglegesnek szánt tranzakció, amit később bármelyik fél be tud küldeni onchain a blokkláncba, ezzel véglegesítve és lezárva a felek közötti fizetési csatornát és elszámolva annak záró egyenlegét.”

    Ameddig nincs beküldve az offchain elszámolás az onchain hálózatra, addig az onchain hálózaton elkölthetem mégegyszer a bitcoinom?
    Hogyan van az biztosítva, hogy ne tudjak párhuzamosan garázdálkodni a bitcoinjaimmal onchain és offchain?
    És hogyan nem lesz szűk keresztmetszet az onchain hálózat az offchainnek, ha beküldik oda az utóbbi tranzakcióit?

    Előre is köszönöm a válaszokat!

    • A lightning networkbe való csatlakozáskor, ugymond letétbe helyezel valamennyi bitcoint. Ez bekerül a blokláncba is. Utána LN-en keresztül csak annyival rendelkezel tehát azt nem tudod onchain elkölteni.

      • Köszönöm!
        Szóval amikor az LN-be letétet rakok, akkor onchain egy másik address-re kerül a letétemnek megfelelő bitcoin, aminek a titkos kulcsa felett már nem diszponálok, hanem azt már az LN kezeli?
        Tehát az LN-be letétet rakni a bitcoin hálózaton való utalás költségével jár, és onnan “kilépni” mondjuk a LN egyenlegemmel, amit 76 adásvétellel gyűjtöttem, még költségesebb, hiszen akkor akár 76 tranzakció hajtódik végre onchain?

        Nem tartom kizárnak hogy hülyeségeket kérdezek, csak szeretnék egy kicsit tisztábban látni.

  3. Nekem a payment hub üzemeltetés része nem világos. Alkalamasint kifejtenéd?
    “Eve nem csak a 0.03BTC-t bukja, de az addig virágzóan működő payment hub üzletét is” A néhány sat-os utalási díjakból lesz “virágzóan működő payment hub” vagy pontosan miből?
    Arra emlékszem, valamelyik LN leírásban olvastam, hogy nagyon durva rendelkezésre állást kell biztosítani (öt 9-es talán vagy ilyesmi) különben a hálózat büntet, így otthon upc-re dugva a node-ot nem biztos, hogy megéri üzemeltetni. Vagy rosszul emlékszem? Egy kis raspberry node-n még el is gondolkodtam 🙂

  4. “Alice és Carol között létezik az alapértelmezett csatorna, amit Alice 0.1 BTC-jével nyitottak meg a felek úgy, hogy Carol nem adott bele semmit. Ekkor a csatornában Alicenek van 0.1 BTC-je, Carolnak pedig 0 BTC-je.”

    Én úgy tudtam, hogy ilyen esetekben Alice nem tud Carol-on keresztül küldeni 0.003 BTC-t senkinek, mert első lépésben Carol “kölcsön” kéne adjon 0.003 BTC-t Dave-nek, és csak utána kapná azt meg Alice-től. De mivel Carol-nak 0 BTC-je van, így az ő nem tud “kölcsön adni” route-ja nem használható.

    • turossztrapacska

      Carolnak 0 BTC-je van az Aliceszel közösen létrehozott csatornában (multisig walletben), de ettől függetlenül Carolnak lehet Dave-vel egy MÁSIK csatornája amin Carol egyenlege nem 0 (0,003 vagy annál több). Carol “routerként” működik és az Alice-Carol “hálózatot” köti össze a Carol-Dave “hálózattal”

      • Persze, lehet, de ha nincs, akkor megértésem szerint ő egyáltalán nem tud router-ként működni.
        Kicsit továbbgondolva: ha van is mondjuk 0,003 BTC-je a Dave-vel kialakított csatornán, akkor sem tudna ennél többet route-olni Alice-től.

        Tehát ha Alice Bob-nak akar küldeni pénzt, akkor csak olyan láncokat választhat ki ahol minden node-nak van legalább annyi pénze, amennyit Alice küldeni akar?

        • turossztrapacska

          Ebben az esetben másik útvonalat kell keresni. Hasonlóan a TCP/IP-hez itt is a legszűkebb keresztmetszet a limit, de bármilyen irányban kiépülhet a hálózat.

          • Akkor lesz baj, ha a node-ok csak költik a pénzt és nem töltik újra, ezáltal egyre kevesebb lesz a választható útvonal.

  5. Köszönöm. Egy lépéssel ismét közelebb kerültem a megértéséhez.
    Nagyon komoly, alapos leírás.

  6. Ezt többször kell majd átolvasnom. Videódat megnéznem.
    Rendkívül hasznos, részletes cikk.
    Nagyon komoly munka van az írásaidban.

    Tegnap este 10k USD alatt volt a hálózaton a Bitcoin mennyiség.
    Most már 11 600. Persze közben emelkedett az árfolyam is, de nem ennyivel.
    52 node, 82 csatorna.
    Szépen kúszik felfelé.

    Esetleg van olyan oldal, ami a segwit elterjedtséghez hasonlóan ezt is mutatni fogja?

  7. Köszönet az írásért, na meg a videóért. Még elég sok minden nem világos, de majd még párszor elolvasom 🙂

  8. Sziasztok!Valóban kiváló írás!
    Mely fejlesztéseket találjátok a legígéretesebbnek,amik megreformálhatják a digitális pénzek piacát?
    Illetve mit gondoltok a decentralizált tőzsdék potenciáljáról,ha széleskörben elterjed az LN?(ZRX pl.)

  9. Szuper.

    Köszönjük.

    Jó összefoglaló.

  10. Köszi.
    Igen, nagyon kell ez a technológiai ködoszlatás.

    “az LN abból a filozófiából épül fel, hogy csak nem építhetsz fel mindenkivel kapcsolatot, sokkal logikusabb, hogy véges számú fontosabb/nagyobb hubbal van csak fizetési csatornád. (payment channel)”

    Azthiszem nekem a fenti mondatból jött át a lényeg, bár a cikkben lévő példából ez nem jön le elég egyértelműen, mert abból (nekem) úgytűnik elsőre, hogy szerencsém van, hiszen az adott magánszemélyek pont kiépítettek egymás között egy-egy kapcsolatot és így megvan a szükséges routing útvonal.

    De a valóságban inkább ha jól értem, és mondjuk vásárloni akarok az Amazonról, az eBay-ről, és egy ausztrál kiskereskedőtől kengurubőr kabátot akkor:

    1. Először is LN képesnek kell lennem, vagyis minimum egy felépített payment channel tagja kell legyek.

    2. Célszerűen ezt a kapcsolatot egy nagyobb HUB felé lenne jó megnyitni.
    Pl. Ha kapcsolatot létesítek mondjuk a BudapestHUB_01-el akinek közvetlen kapcsolata van az Amazon és az eBay felé akkor ez máris kipipálva. A kabátomat pedig azért tudom kifizetni, mert a BudapestHUB_01-nek kapcsolata van SydneyHUB_02-vel akinek pedig kapcsolata van AucklandHUB_01 felé és az ausztrál kersekedő ide csatlakozik, tehát megvan az útvonal.

    A nagymamának meg már az is elegendő ha hozzám csatlakozik, mert így már összes többi útvonal elérhető az ő számára is.

    Jól értem a fentieket?

    3. Olyan kérdésem lenne még, hogy akkor most mi is legszűkebb keresztmetszet a Lightning Network-ön? Túl terhelődhet valahogyan?
    4. Mennyi ideig ragadhat benn a pénzem? (Dave-nél 😉 ) Van erre vmi alapértelmezés?
    5. Van a protokolban olyan metódus ami a legolcsóbb útvonalat keresi?
    6. Alpértelmezés szerint csak végpont vagyok, vagy egyből HUB is?
    7a. A LN belül érkező pénzt onChain is eltudom költeni? (vagy csak ha lezártam a saját channel-emet?)
    7b. Tehát commitment tx beküldésekor mindig csak az adott 2db fél közötti egyenleg kerül be a blokkláncba?
    8. Milyen szempotok alapján illene lezárni egy channelt egy HUB-nak?
    9. Hány csatornát lehet fenntartani egyidejűleg? Létezik vmi technikai limit egyáltalán?

    Köszi a válaszokat előre is.

    • “A nagymamának meg már az is elegendő ha hozzám csatlakozik, mert így már összes többi útvonal elérhető az ő számára is.”

      Az útvonalak igen, de nagymamád csak annyi pénzt fog tudni küldeni rajtad keresztül, amennyid van neked. Ha többet szeretne, más útvonalat kell válasszon.

      • Nem feltetlen. Ugyna nem hangzott el de szamomra ugy logikus hogy a legjobb chanellel megy vegig a maximalis osszeg amit tudsz de akar tobb csatornat is igenybe vehetsz es midnegxik azvutalasod egy része tortenik de a vegen mind megérkezik a cimzetthez

  11. Centralizációhoz vezet, mert a többség igyekszik azokhoz a node-okhoz kapcsolódni, amelyek a legtöbb csatornát nyitották, amelyekhez a legtöbb ügyfél csatlakozik. Ennek alapvetően anyagi oka lesz, mert a node-ok pénzt kérnek a szolgáltatásért, ezért dupla node-os útvonal – dupla költség. Az ügyfeleknek érdekük lesz egyetlen node-on keresztül kapcsolódni a többiekhez. Az a node, amelyik korábban kezdi el gyűjteni az ügyfeleket (nyitni a csatornákat) később behozhatatlan előnyte tesz szert, nem szólva arról, hogy a node-nyitáshoz jelentős bitcoin tőke szükséges.

    • Először én is erre jutottam, de ha jobban belegondolok, akkor a kedvenc sarki pékségem ahol minden reggel megveszem a baguette-emet, üzemeltet egy saját node-ot, akkor lehet jobban járok, ha egy egyszeri tx fee-vel nyitok egy payment channelt és lekötöm a várható havi költésemet. Innentől már csak akkor fizetek egy újabb minimális tranzakciós díjat, amikor lezárom a channelt. Lehet, hogy ez a két fee olcsóbb, mint a havi 30 node fee akár csak egyetlen hubon keresztül. Ugyanezt megtehetem a kedvenc benzinkutamnél is és mindenhol ahol tervezehető havi sok részletben fizetendő kiadásom van. Az összes többi fizetes meg mehet egy nagyobb hub-on keresztül. Még szebb ha a “városom” (-ban valaki) üzemeltet egy hub-ot ahova a környékbeli boltosok be vannak ‘csatornázva’. Így van egy rövid útvonalam a helyi kereskedőkhöz és ‘egy másik a világ felé’. Azt viszont én is úgy látom, hogy aki elsőként kezd bele az, a tranzakciós díjakból tényleg komoly előnyre tesz szert.

  12. Ha fut egy bányagépem 0-24-ben, azon érdemes lehet futatnom egy LN node-ot? A kérdés, hogy mekkora erőforrásigénye van, csak mert az Internet kapcsolat nem gond, elég széles és stabil is, de a cpu csak egy g4400-as pentium, amiből 15-20%-ot a bányászat leköt. Ha nem termel semmilyen bevételt, az ügy érdekében akkor is szívesen áldozok rá egy kis erőforrást, ha már úgy is megy a gép. Egy step-by-step is sokat segítene Windowsra. Egyet találtam, de az testnetes.

    • Volt itt szó valami olyanról, hogy olyan mértékű rendelkezésre állás kell majd LN node üzemeltetéshez, amit az íróasztal alatt zümmögő régi PC nem fog tudni hozni. Deeplinkem nincs.

  13. Szuper leírás.Lenyűgöző!

  14. Nagyon jó előadás, gratulálok. Kb. így működik a trustlines (https://trustlines.network/) is, csak ott nincsenek BTC-vel lefedezve a csatornák, e helyett az emberek bizalom alapon kvázi hiteleznek egymásnak. Így teljesen bizalom alapú, közösségi hitelpénzrendszer alakítható ki, ami tényleg bankok, spekuláció és minden hasonlótól mentes.

  15. Hű ezt a mondatot nehéz megemészteni:
    “Amikor Alice pénzt utal Bobnak Carolon keresztül. Akkor Alice és Carol elkészít egy véglegesnek szánt tranzakciót, amiben mindketten elismerik, hogy Alicenek immáron 0.03-BTC-vel kevesebb pénze van, Carolnak pedig pont ugyanennyivel több pénze van.”

    Ha Alice a nevezett összeget Bobnak küldi, akkor miért Carolnak van 0.03 BTC-vel több pénze?

    Valahogy úgyvan ez, hogy a LN útvonal első közvetelen payment channel-je Alice és Carol között volt nyitva és mivel lezárták a hiányzó összeg csak Carolnál lehet?

    De akkor hogyan lesz onchain Bob-nál a pénz, pláne, ha az egész útvonalból ő lép ki először és le szeretné zárni a közte és Eve közötti csatornát? Carolnál meg a többieknél ott marad a 0.03 BTC? Nyilván nem, de nem világos, hogy miért nem.

  16. “Hyundai Pay announced they’re adding Bitcoin Gold support to their hardware wallet and platform this month.” ez azt jelenti hogy valaki akar ilyen tipusu gépkocsit venni BTG vel is fizethet?

  17. A raidennetwork működése mennyiben tér el az LN-től ? Elkebzelheto lehetne a ketto kozott barmilyen kompatibilitas ?

    • Lehet nem játszottál Mortal Kombattal? Csak mert, ha igen, akkor minden bizonnyal azért találhatsz némi összefüggést “Raiden” és a villámok között 🙂 Félretéve a poént. A Raiden(Ethereum) és a Lightning Network (Bitcoin, Litecoin, Monero, stb.) teljesen testvér implementációja ugyanannak a second layer payment channel routing technológiának. A Raiden ugye annyival több/másabb, hogy nem csak payment channelként tud funkcionálni, hanem ERC20 tokeneket is tud szállítani, meg offchain dappokat futtatni. De ezt leszámítva a két protokoll egyébként interoperábilis.

      • Köszönöm a választ, tehát ha jol értem a jovoben elkepzelheto, hogy kifizetek valamit BTC-ben egy ETH-os cimre es konverzio tortenik. Csak ki és mi foglya meghatarozni az atvaltasi arat (hivatalos jegyzes ugye nincs) ? Errol majd a fogado fel dont mennyiben valtja a kuldott BTC-met ? Kapcsolatot hogyan tudnek folvenni veled, lenne még néhány kérdésem az egész technologiat illetoen? ÉS természetesen játszottam MK-val bar a függoseg vagy a rajongas hatarat nem igen erem el 🙂

        • Egy tőzsdén ki vagy mi határozza meg az átváltási árfolyamot? Nyilván a kereslet és a kínálat. Nincs ez másként a dencentralizált (atomic-swap) környezetben sem. Meg tudod hirdetni, hogy mit mire váltanál és milyen árfolyamon. Ebből folyamatosan képződik egy virtuális orderbook a hagyományos tőzsdékhez hasonlóan, majd végrehajtódnak a matchingek, ha vannak azonos ellenajánlatok.
          A Raiden kapcsán eléggé felületes a tudásom én inkább az LN-nel és az lnd-re épülő atomic swappel foglalkozom, mindettől függetlenül amiben tudok segítek. Keress meg direktben a contact email címen és megbeszéljük.

  18. Nekem az jött ki, hogy ha mondjuk átlag havonta akarunk elszámolni a blockchain-en, és a blockchain a jelenlegi percenkénti 3 tranzakciót tudja, akkor a rendszer kapacitása LN-kel: 3*60*60*24*30/2, azaz kb. 4 millió végfelhasználó. – Ez még mindig kevés. Vagy rosszul számolok?

    • Ha azzal az ideologizált jövőképpel számolunk, hogy minden tranzakció offchain megy és onchain már csak channel mgmt történik (ami teljesen kizárt, hiszen az LN nem alkalmas bármire, akkor ez azt is jelentené, hogy minden tranzakció segwit protokollal történné. Ebbben az esetben a másodpercenkénti tranzakciószám akár a 20-30-as is el tudná érni. Ez persze még így is csak max 40 millióra emelné a felhasználói limitet, ami hogy sok vagy kevés… ez majd idővel kiderül.

  19. Viszont, ha pl Alice utal Bobnak, akkor nem szükséges hogy a köztes szereplőknek legyen likviditása elvileg. Ugye Alice elutalja Carolnak, neki annyival több lesz. Utána azt tovabbküldi Davenek, ő Evenek és ő Bobnak, tehát ez csak egyfajta direkt limitácio?

    • Ez nem így van. Az Alice-Carol és a Carol-Dave közötti csatorna két külön csatorna. Attól, hogy Alice elutalja a pénzt Carolnak, attól ez csak az Alice-Carol csatorna likviditását (balanceszát) érinti, de ettől ha a Carol-Dave csatorna üres Carol irányából még nem fog tudni routeolódni az utalás. Minden csatorna önálló és független az adott node egyéb csatornáitól, aminek a maximális kapacitása a megnyitáskori coin mennyiség és az aktuális egyenleg mindig attól függ, hogy a két fél korábban mennyit utalt oda/vissza azon.

    • Hali! Nekem sem volt világos elsőre. Mondok egy másik példát ami szerintem könnyebben emészthető mint a ‘routolódás’ kifejezés.

      Képzeld el úgy, (a fenti példából kiindulva) hogy Carolnak mint köztes szereplőnek két zsebe van. Van egy Alcie oldalán, és van egy Dave oldalán. Az Alice felőli zsebe tök üres, a Dave felőli zsebében viszont van 0,75 BTC.
      A Lightning Network-ön van egy ökölszabály: Senki sem tehet át semmit az egyik zsebéből a másikba!
      Tehát amikor Alice pénzt akar küldeni Carolon keresztül, akkor így diskurálnak:
      Alice: Carol, tudom, hogy az én oldalamon lévő zsebed üres, de a Dave felőli zsebedben van legalább 0,03 BTC?
      Carol: Igen, van.
      Alice: Figyu, akkor én beteszek az én oldalamon levő zsebedbe 0,03BTC-t.
      Légyszi küld már tovább Dave-nek a másik zsebedből ugyanezt az összeget, azzal a meghagyással, hogy ezt majd neki is tovább kéne küldenie Bob-nak.
      Carol: Oké Alice. Látom betetted a pénzt a zsebembe. Akkor ha beteszel még némi fee-t is, a másik zsebemből már küldöm is Davnek ugyanezt az összeget.

      Tehát Carolnak végül ugyanannyi pénze marad, ill. csak a fee-vel lett gazdagabb.
      Viszont most már az Alice felőli zsebében is van pénz, 0,03 BTC. A Dave felőli zsebében pedig 0,72 BTC.

      Lényegében tehát nem konkrétan Alice pénze jut el Bobhoz (mint ahogy az onchain Bitcoin sem megy sehova) hanem a tőle jövő megbízásnak tesznek eleget a köztes szereplők.

  20. Amit viszont még nem értek, az a shared secret. Azt egy külön csatornán(email pl.) kell egyeztetniük?

    • Nézzük a legegyszerűbb példát:

      Kiállítok most neked egy invoicet:
      lncli addinvoice –memo “variance test” –value 100
      {
      “r_hash”: “5f0053a157e35ba1d0da10487f9f2c92d1b84db698b4662177b09c3ac93c302f”,
      “pay_req”: “lnbc1u1pd8gr37pp5tuq98g2hudd6r5x6zpy8l8evjtgmsndknz6xvgthkzwr4jfuxqhsdq4weshy6tpde3k2gr5v4ehgcqzysnhkqkynlasunq9eu6093dgwdnw23rcwm48zd7a4g4zxzf2w5mpqh7m7zchxf3nf8d98tnnmeck2yv3upg6vrq6cg4wft952zjmm0wuspy4ms3n”
      }

      Nézzünk bele ebbe az invoiceba:
      lncli decodepayreq lnbc1u1pd8gr37pp5tuq98g2hudd6r5x6zpy8l8evjtgmsndknz6xvgthkzwr4jfuxqhsdq4weshy6tpde3k2gr5v4ehgcqzysnhkqkynlasunq9eu6093dgwdnw23rcwm48zd7a4g4zxzf2w5mpqh7m7zchxf3nf8d98tnnmeck2yv3upg6vrq6cg4wft952zjmm0wuspy4ms3n
      {
      “destination”: “033abe908878ac00c1e916face972331b3a6e3ba4e587c95efec3c76e3ee339c82”,
      “payment_hash”: “5f0053a157e35ba1d0da10487f9f2c92d1b84db698b4662177b09c3ac93c302f”,
      “num_satoshis”: “100”,
      “timestamp”: “1517555262”,
      “expiry”: “3600”,
      “description”: “variance test”,
      “description_hash”: “”,
      “fallback_addr”: “”,
      “cltv_expiry”: “144”
      }

      Láthatod már az invoicenál is és a decodenál is a r_hash/payment_hash értéket. Na ez az az bizonyos hash, amit ismerni kell ahhoz, hogy hozzá lehessen férni az adott pénzmennyiséghez. Az invoicet csak a kiállító és a fogadó fél ismeri. Az invoice-t kaphatod emailben, egy webfelületen vagy integrált payment API-n keresztül. Az invoicet viszont nem ismerheti a Lightning Network többi szereplője, hiszen az invoice-t NEM az LN-en keresztül kaptad meg, hanem egy tetszőleges egyéb csatornán keresztül.

      Ennyi a “trükk”

  21. Így már teljesen világos, köszi.
    Akkor ez egyben azt is jelenti, hogy egy tranzakciós kapcsolat mindig eseti, és egy fizetési >kérésselküldeni< a gyereknek, hanem azt neki kell kérnie. (technológiai szempontból)

    Még egy dolog:

    A Brave böngésző az egyik update után a (Payment settings-nél) felajánlott 10 BAT-et szabad felhasználásra. Mivel ha nem olvasnám a variance.hu-t lövésem nem lenne mi az a BAT ezért szeretném neked felajánlani. A kérdés igazából az, hogy vajon el jut-e hozzád? Azért érdekes a dolog, mert pl. a coinmarketcap.com-nál ott van már egy kis szimbólum, hogy: verified publisher. Biztos megtudod oldani, hogy a variance.hu is verifikálva legyen, és akkor repülhet a denevér.

    • Huhh, köszönöm a felajánlást. A hétvégén meglátom miként tudok csatlakozni a BAT networkbe. Bár őszintén szólva nem véletlen, hogy idén már egyetlen cikkben sem láttok hírdetést. (már hogy az újakban). Mivel főállásban is kiléptem a crypto piacra, így kevésbé tartanám hitelesnek, ha továbbra is hírdetésekkel tömném tele a cikkeket. Mindettől függetlenül a szakmai kiváncsiság okán biztosan meg fogom csinálni a BAT regisztrációt.

  22. Upsz. Nem tudom miért ilyen hiányosan ment el a posztom első fele?!
    (Ill. sejtem a WordPress megpróbálta értelmezni a kacsacsőrőket amit kiemelésnek szántam)

    Így kerek:
    Akkor ez egyben azt is jelenti, hogy egy tranzakciós kapcsolat mindig eseti, és egy fizetési kéréssel kell kezdődnie?
    Tehát nem lehet egy fix megbízhatósági kapcsolatot kiépíteni két fél között, ha jól értem.
    Vagy másképpen: nem tudok pénzt küldeni a gyereknek, hanem azt neki kell kérnie. (technológiai szempontból)

    • Igen, jó látod. A Lightning network payment channel, ahol minden utalást egy invoice előz meg. Ez egyben a történet nagyszerűsége is, hiszen az invoice ezáltal teljes anonimitást is biztosít. A routing során a hubok csak azt tudják, hogy éppen merre kellene továbbítani az utalást, de pl azt nem tudják, hogy honnan jött. Az LN-en keresztül nincs lehetőség arra, hogy fixen eltárolj addresseket, amikre időnként küldözgetsz kisebb mennyiségeket. Ehhez minden esetben invoice kell.

  23. Ha jól értem akkor BAT nem csak a reklámokért jár, hanem támogatásként is fel lehet ajánlani.

    https://brave.com/faq-payments/#for-publishers

    • Nahh, akkor definitely itt az ideje, hogy updateljem a tavaly nyári információimat a BAT kapcsán. Köszi! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *