Hozzáadva: 2022. Szeptember 21.
A bitcoin protokoll segítségével az egész világ teljes pénzügyi tranzakciós volumenjét le lehetne kezelni, anélkül hogy egy harmadik fél segítségét igénybe vennénk. Ehhez nincs szükség többre mint egy gyors internetkapcsolattal rendelkező számítógépre. Ebben a munkában egy decentralizált rendszer kerül bemutatásra. Ez a rendszer tulajdonképp egy hálózat, amely mikrofizetéseket bonyolít le fizetési (vagy tranzakciós) csatornák formájában. A csatornákon történő fizetések a blokklánc érintése nélkül mennek végbe. Abban az esetben amikor a bitcoin tranzakciók egy újféle sighash aláírással hitelesítődnek, amely megoldja a hamisíthatósági problémákat akkor a pénzek átutalását meg lehet oldani egymásban nem megbízó felek között is szerződések segítségével ezeken a csatornákon keresztül. Nem protokoll követő magatartás esetén a szerződésekben foglaltakat végre lehet hajtani a tranzakciók blokkláncra történő publikálásával és ezek időbélyegek csökkentése mellett kerülhetnek fel a láncra.
A bitcoin blokklánca kiváló megoldás lehet elosztott főkönyv alkalmazásokban, viszont sajnos a közeljövőben nem várhatjuk tőle, hogy mint közvetítő médium szerepel majd a világ kereskedelmében.
A blokklánc egy pletykáló protokoll, ami azt jelenti hogy minden állapotváltozást minden alkalommal kommunikálni kell a hálózat összes résztvevőjével. A hálózatban ezen pletykáló protokoll segítségével jön létre konszenzus, így tudnak a felhasználók egyenlegei szinkronban maradni. Ha tehát azt feltételezzük, hogy a hálózat minden egyes résztvevőjének tudnia kell minden egyes újonnan létrejövő tranzakcióról, akkor megérthetjük hogy ilyen formában a rendszer nem lesz elegendően gyors ahhoz hogy nagy kereskedelmi volumeneket közvetítsen. Mindezek mellett olyan módon kellene az összes tranzakciót kezelni, hogy azzal közben ne sértsük a decentralizációs tulajdonságot valamint a hálózat biztonsági paramétereit.
A Visa rendszere a 2013-as munkaszüneti időszakban 47.000 tranzakciót volt képes lekezelni egy másodperc alatt. Jelenleg a Visa-nál több száz millió tranzakciót dolgoznak fel egy nap alatt. A bitcoin azonban egy másodperc alatt 7 tranzakciót képes kezelni és a jelenlegi blokkméret 1 Mb-ban van korlátozva. Ha feltételezzük, hogy egy bitcoin tranzakciós üzenet hossza 300 byte továbbá feltesszük azt is, hogy a láncra kikerülhetnek korlátlan méretű blokkok is, valamint szeretnénk elérni a Visa 47.000 per másodperces tranzakciós sebességét, akkor 8 Gb-ot kapnánk egy bitcoin blokkra és ez minden 10 percben meg kellene hogy jelenjen a láncon. Egy év alatt ez megközelítőleg 400 Tb-os blokklánc növekedést okozna.
Érthető tehát, hogy olyan kapacitás növekedést, mint amilyet a Visa produkált a bitcoin napjainkban nem fog elérni. Nincs jelenleg egy olyan otthoni számítógép, amely képes lenne ennyi adatot tárolni és kommunikálni.
Ha a bitcoin-nak valamilyen oknál fogva mégis sikerülne megközelíteni a Visa tranzakciós sebességét, akkor a hálózat valószínűleg összeomlana vagy nagyon nagy mértékben centralizálódna a hálózati csomópontok valamint a bányászok eloszlása, hiszen csak azok tudnák üzemeltetni, akiknek lenne rá pénze. Az ilyen jellegű centralizáció teljes mértékben tönkre tenné azt a decentralizációs alapelvet, amely a bitcoin-t olyan biztonságossá teszi. Ez a szinte minden egyes egyén számára adott lehetőség arra, hogy ellenőrizze a főkönyvet. Az esetlegesen megnövekedett blokkméret következtében kevesebben lennének tehát azok, akik tudnák ellenőrizni a láncot és a bitcoin bányászata is még jobban centralizálódna. Ha hatalmas blokkméretek, mondjuk 8 Gb minden 10 percben azt eredményeznék, hogy csak néhány nagyon tehetős szereplő tudná ellenőrizni azok hitelességét. Ennek következtében a kisebb szereplők csak a nagy szereplőkön keresztül tudnák elérni a bitcoin blokkláncot. A néhány nagy szereplő minden bizonnyal szociológiai csapda lenne, hiszen a nagy szereplők valószínűleg figyelmen kívül hagynák a kis szereplők érdekeit (fő ügynök probléma) és elkezdenének a kis szereplők által beszolgáltatott felhasználói díjakból élni, garantálván ezzel a lánc hitelességét. Szélsőséges esetekben az is megtörténhet, hogy a kicsi szereplőknek el kellene küldeni a digitális vagyontárgyaikat a megbízhatónak vélt centralizált szereplőkhöz és ezzel egyidejűleg le is kellene mondaniuk azok tulajdonjogáról. Ilyen megoldások léteznek a mai nap is, de tudjuk, hogy ez nagyon kiszolgáltatottá teszi a felhasználókat. A feltétele annak, hogy ez ne történhessen meg tulajdonképp az, hogy biztosítjuk, hogy a blokkok egy egyszerű otthoni számítógép és egy gyors internetkapcsolat segítségével ellenőrizhetők. Azzal, hogy biztosítjuk a blokkok olcsó ellenőrizhetőségét esélyt adunk a bitcoin hálózat résztvevőinek, többek között a bányászoknak arra, hogy megakadályozzák a nagy centralizált szereplők kialakulását és így alacsony tranzakciós díjakat is lehet biztosítani.
Fel lehet ugyan tenni, hogy a Moore törvény a végtelenségig igaz lesz és néhány éven belül megjelennek olyan számítógépek, amelyek segítségével problémamentesen lehet ellenőrizni több gigabyteos blokkokat, de ez egyáltalán nem biztos. Ha tehát több, mint 47.000 tranzakciót szeretnénk egy másodperc alatt megkövetelni a bitcoin blokklánctól, akkor a tranzakciók egy jelentős részét le kell venni a láncról. Még jobb lenne az is, ha a bitcoin hálózata korlátlan mennyiségű tranzakciót tudna kezelni nagyon alacsony tranzakciós díjak mellett mert ezzel mikrofizetéseket lehetne eszközölni. Ezek a mikrofizetések egymás mellett haladhatnának és bármekkora összeget lehetne velük tranzaktálni. Ezen mikrofizetések segítségével kevesebb bizalmat kellene a rendszerbe fektetni, szét lehetne választani szolgáltatásokat, tovább sok szolgáltatást erőforrás alapúvá lehetne tenni (például a megabyte alapú netes szolgáltatások). Az ilyen jellegű mikrofizetések megvalósításához a blokkláncra publikálódó tranzakciók számát radikálisan le kellene csökkenteni. Kis méretekben meg lehet oldani skálázhatósági problémákat, de a hálózat biztosan nem tudna kezelni nagy mennyiségű mikrofizetést és nem lenne képes globális kereskedelmi volumenek feldolgozására sem. Ha szeretnénk garantálni a bitcoin sikerét, akkor egy nagyobb mértékű elterjedés esetében is meg kellene tartanunk a decentralizációból fakadó előnyöket. Ha ma el szeretnénk hinni, hogy a bitcoin működni fog holnap is, akkor a blokkméret és az abból adódó centralizációs problémákat meg kell oldani, hiszen a jelen állapotban a nagyobb blokkméretek csak centralizált, bizalmat igénylő szereplők bevonásával elképzelhetők, ez pedig emelné a tranzakciós díjakat is.
“Vajon adott-e ki hangot az a fa, amely egy olyan erdőben dőlt ki ahol nincs senki?”
A fenti idézet a nem megfigyelt események fontosságát érzékelteti. Ha senki nem hallotta kidőlni a fát, akkor teljesen mindegy hogy adott-e ki hangot vagy nem.
A blokkláncokkal is hasonló a helyzet. Ha van két fél, akik minden nap küldenek egymás közt pénzeket, de ezek csak őket érdeklik, akkor nem feltétlenül kell kikürtölni a hálózatba a tranzakciókat. Ehelyett elegendő lehet minimális mennyiségű tranzakciót felvinni a láncra. Az által hogy csökkentjük a láncra publikált tranzakciók számát és csak egy későbbi időpontban tesszük fel az egyenlegeket egyeztető tranzakciót a láncra helyet takaríthatunk meg és így nem lesz szükség megbízható harmadik félre sem a tranzakciók lebonyolítására sem. A tulajdonképp bizalmat nem igénylő struktúrát a globális konszenzusba helyezett időzárakkal lehet megvalósítani. Ma a legáltalánosabb megoldás, amit a mikrofizetések problémájára adnak az az, hogy egy harmadik (bizalmat igénylő) fél elvállalja a digitális vagyontárgyak nyilván tartását és ő fele a folyamatos egyenleg frissítért. Az ilyen jellegű harmadik felek beépülése felesleges bizalmat vár el a rendszertől és így megnőnek a tranzakciós költségek is, hiszen a harmadik felet el kell tartani. Ehelyett ha az előbb felvázol mikrofizetések ötletét alkalmazzuk, akkor a bitcoin hálózatot akár milliós darabszámú másodpercenkénti fizetésekre is alkalmassá lehet tenni, mindezt úgy hogy a lánc ellenőrzést egy egyszerű modern számítógéppel továbbra is el lehet végezni. Ha a fizetéseket ezeken a fizetési csatornákon keresztül küldjük, akkor lehetőség nyílik nagyobb összegek átutalására is egy teljesen decentralizált környezetben. Ezek alatt a csatornák alatt nem egy bizalmat igénylő hálózatot kell érteni, amit a bitcoin hálózata felett alakítottak ki. A tranzakciók valós bitcoin tranzakciók. A mikrofizetési csatornákban a felhasználók folyamatosan tudják frissíteni egyenlegeiket és elkülönítik hogy milyen információ jut ki a láncra attól, amiket egymás között kommunikálnak, végezetül pedig az egyenlegek rendezéséhez egyetlen tranzakciót küldenek ki a láncra. Így a pénzügyi kapcsolat bizalom nélkül létrejöhet a két fél között és azt a felek egy későbbi időpontban tudják lezárni. Ezzel ki lehet kerülni a harmadik fél fizetésképtelenné válásából adódó kockázatokat. A mikrofizetési csatornák valós bitcoinokat használnak a tranzakciókban viszont a tranzakciókat oly módon nem publikálják, hogy közben az ideiglenes egyenlegeik a láncon a nekik megfelelő módon változnak. A mikrofizetési csatornák nem egy, a bitcoin hálózata felé épülő réteget jelentenek, a csatornákban valós bitcoinok közlekednek és azok a láncot nem érintő módon cserélnek gazdát.
Tegyük fel megint a régi kérdésünket. Van-e hangja a kidőlő fának abban az erdőben, amelyben éppen nem tartózkodik senki? Ha mind a két fél azt mondja, hogy a fa délután 2:45-kor dőlt ki, akkor az valóban akkor dőlt ki. Vagyis ilyen tekintetben a felek megegyeznek. Hasonló a helyzet a mikrofizetési csatornákkal. Ha eldöntöttük, hogy a csatornában A-nak 0.07 BTC-je, B-nek 0.03 BTC-je van, akkor ez lesz a valós egyenleg. Kriptográfia nélkül azonban itt egy érdekes problémába ütközünk. Ha az egyik fél ellentmond és szerinte nem annyi az egyenleg, mint amit a másik mond, akkor az ellentmondás feloldhatatlan lesz. Kriptográfiai aláírások nélkül a blokklánc nem fogja tudni kinek mikor van igaza. Ha például A egyenlege 0.05 BTC B egyenlege pedig 0.05 BTC, majd egy tranzakció miatt A egyenlege 0.07-re B egyenlege pedig 0.03-ra módosul, akkor a hálózatnak el kell dönteni, hogy melyik egyenleg párok az aktuálisak. A blokkláncok erre az elosztott főkönyv megoldást használják, amely tulajdonképp az idő múlását regisztrálja. Jó lenne viszont egy olyan rendszert létrehozni, amely nem használja folyamatosan ezt az időbélyegző rendszert, mert így a fent említett skálázódási problémába ütközünk. A megoldás tehát abban keresendő, hogy a felek például aláírhatnak egy tranzakciót, de azt nem feltétlenül kell publikálniuk a láncra. A és B például berakhat egy 2-2 multisig címre pénzeket (erről a címről csak a két fél aláírásával lehet költeni) és megegyezhetnek egy aktuális egyenlegben. A és B továbbá a 2-2 multisig címről egy 0.05 BTC-nyi pénzvisszafizetési tranzakciót is létrehozhat és ezt viszont nem kell a láncra publikálni. Vagyis ezt a visszagördítő tranzakciót bármikor ki lehet publikálni a láncra és így nyugodalma lesz mind a két félnek, hiszen 0.05 BTC-t bármikor vissza tud venni ha valami balul sülne el. Amíg a visszagördítő tranzakció nincs kipublikálva a láncra, addig a közös egyenleget bármikor frissíthetik. A frissítés például úgy történhet, hogy a 2-2 multisig címről 0.07 BTC elköltését engedélyzenek A-nak és 0.03 BTC elköltését engedélyezik B-nek. Ha nem jól tervezzük meg a rendszert, akkor nehéz lesz eldönteni, hogy melyik aránypárra adott engedély az aktuális (0.05 BTC - 0.05 BTC vagy 0.07 BTC - 0.03 BTC). Az időbélyegekből és a dátumokból adott feltételek kialakítása azonban nem annyira bonyolult mint a tranzakciók időbeli rendezése a bitcoin blokkláncban. A mikrofizetési csatornák kialakítása során csupán két állapotra lesz szükségünk. A jelenlegi egyenlegekre és egy bármely már nem használt egyenlegre. Aktuális helyes egyenleg csak egy létezhet, már nem használt viszont sok is lehet. Ebből következően tehát létre lehet hozni egy olyan bitcoin szkriptet, amely érvénytelenné teszi a régi tranzakciókat és érvényessé teszi az újat. Az érvénytelenné tételt egy bitcoin kimeneti szkripttel és a hozzá kapcsolódó további tranzakciók segítségével lehet megoldani. A tranzakciók kötelezik az egyik felet arra, hogy az minden digitális vagyontárgyát átadja a csatorna másik oldalán lévő félnek. Az átadás mintegy büntetés történik és ez az eddig tranzakciókat érvénytelenné teszi. Az érvénytelenné tevés a csatornában konszenzus mechanizmusokon keresztül történik és ha a felek meg tudnak egyezni a főkönyv állapotán és képesek új állapotokat létrehozni, akkor az aktuális egyenleg mindig rendesen kerül frissítésre. Ez az egyenleg csak akkor tükröződik a láncon, amikor is valamelyik fél nem ért egyet a másikkal. Az ötlet tehát nem egy felső rétegben rejlik, hanem egy olyan kiegészítse ez a jelenlegi bitcoin hálózatnak, amely nem publikálja folyamatosan az állapotváltozásokat, de ettől függetlenül a végső zárása az állapotoknak a lánc segítségével történik egy későbbi időpontban, későbbi tranzakciók segítségével.
Egy csatorna tehát csak két fél között képes pénzügyi kapcsolatot kialakítani. Ha tehát azt várjuk el, hogy minden fél mindenkivel alakítson ki csatornát, akkor megint a skálázódási problémába ütközünk. Ezt csak úgy lehet feloldani ha bevezetjük a fizetési csatornák hálózatátnak koncepcióját.
Ha tehát feltételezünk egy fizetési csatorna hálózatot, amely a bitcoin blokkláncra épül és a felhasználók ebben a gráfban egy fizetési csatornával szerepelnek, akkor közel végtelen mennyiségű tranzakciót tudunk lebonyolítani a rendszerben. Idő előtti csatornazárás csak akkor történik ha protokolltól eltérő magatartást tapasztal valamelyik fél.
A bitcoin tranzakciókat ki tudjuk egészíteni időzárakkal és hashzárakkal. Így a csatorna két oldalán álló fél nem fogja tudni lenyúlni a pénzeket és a bitcoinokat ki lehet cserélni anélkül hogy a pénzeink eltűnése miatt kellene aggódnunk. Ha pedig az időzárakat lépcsősen állítjuk be, akkor a pénzeket több közbenjárón keresztül is átküldhetjük anélkül hogy azok eltűnnének.
A mikrofizetési csatornák tulajdonképp elhalasztják a tranzakciós állapotváltozások publikálását egy későbbi időpontra. A felek közötti szerződések úgy jönnek létre, hogy a felekre felelősséget ruháznak a tranzakciók publikálásával kapcsolatban, amelyeknek egy bizonyos dátum előtt vagy után kell megtörténniük.
Ha a blokkláncra mint egy decentralizált időbélyegző rendszerként tekintünk, akkor az órákat fel tudjuk használni a decentralizált konszenzus megvalósítására és ezzel ellenőrizhetjük az adatok helyességét valamint követhetjük a helyes állapotokat is hogy ezzel rendezhessük az eseményeket.
Bitcoin tranzakciós szkriptek segítségével komplex szerződéses logikákat tudunk létrehozni akkor ha rendelkezésre állnak olyan időkeretek amelyekben bizonyos állapotokat publikálhatunk majd azokat később érvényteleníthetjük. A Hub-and-Spoke mikrofizetési hálózat is valami hasonlót próbált meg létrehozni.
Ha viszont meg szeretnénk valósítani a kétirányú mikrofizetési csatornákat (Lightning Network, LN), akkor az A függelékben leírt alakíthatósági soft-forkot implementálni kell. Így lehetne csak szinte teljesen végtelen skálázhatóságot biztosítani úgy, hogy közben ne kelljen tartani a hálózati csomópontok kiesésétől. Több mikrofizetési csatornát egymásba fűzvén létre lehet hozni tranzakciós utakat a hálózati gráfban. Az utakat a BGP módszer alapján lehet irányítani és így a a küldő kijelölhet utakat a fogadó irányába. A kimeneti szkriptek el vannak látva egy hash értékkel. Ezt a fogadó generálja. A hash értékek bemenetét szolgáltatva a fogadóval szemben álló felhasználónak van lehetőségek bitcoinok lehívására.
Ha valaki a rendszer felhasználójává szeretne válni, akkor egy másik felhasználóval mikrofizetési csatornát kell nyitnia. Első lépésként egy a csatornát megtöltő tranzakciót kell inicializálni és ennek segítségével tudja vagy az egyik vagy mind a két fél feltölteni BTC-vel a csatornát. A kimenete ennek a feltöltő tranzakciónak egy 2-2 multisig szkript, amely tartalmazza a csatorna nyitó feleket, ők lesznek A és B. A felek az erre a feltöltő tranzakcióra vonatkozó aláírásaikat nem cserélik ki, csak akkor ha el szeretnék költeni a 2-2 kimenetet és ezzel közben az eredeti összegeket visszautalják a csatorna feltöltését elvégzőknek. Azzal, hogy nem írják alá a tranzakciót lehetőség nyílik arra, hogy olyan tranzakcióból költsenek, amely még nem is létezik. Ha A és B a kicserélik a feltöltő tranzakcióra vonatkozó aláírásaikat úgy hogy közben nem tudnak költeni ebből a kimenetből a betöltött bitcoinok örökre beragadhatnak ha a két fél nem működik közre (elképzelhetők olyan túszejtési helyzetek is, amelyek során az egyik fél zsarolja a másikat, hogy csak akkor adja vissza a digitális vagyontárgyait ha az fizet neki valamilyen váltságdíjat). A és B kicseréli a bemeneteit, amik a betöltő tranzakciókhoz tartoznak hiszen így fogják tudni, hogy mennyi lesz a csatorna teljes értéke, továbbá kicserélnek egy kulcsot is. Ezt lehet majd a későbbiekben az aláírás során használni. Ezen kulcs segítségével lehet majd aktiválni a betöltő tranzakció kimenetét, viszont a betöltő tranzakció kimenetének elköltéséhez szükség lesz A és B kulcsára is.
Az LN egy SIGHASH NOINPUT-nak nevezett tranzakciót használ és ezzel tud költeni a 2-2 betöltő tranzakció kimenetéből. Erre azért van szükség mert olyan tranzakcióból kell majd költeni, amelyre az aláírások még nem lettek kicserélve. A SIGHASH NOINPUT támogatás egy soft-fork keretében lesz implementálva és így lehet majd olyan tranzakciókból költeni, amelyek még nem lettek aláírva a felek által. Azért van szükség a soft-forkra, mert a tranzakciókat jelen állapotban alá kell írni és csak úgy kapunk tranzakciós ID-t a láncról a sighash flagek változása nélkül.
Ha nincs a láncban SIGHASH NOINPUT támogatás, akkor nem lehet bitcoin tranzakciós kimeneteket elkölteni anélkül, hogy azokat szétterjesztették volna a hálózatban. Olyan ez mintha a való életben nem lehetne szerződéseket írni, csak úgy ha előtte fizettünk volna a szerződő félnek. Az A függelékben erről még részletesen lesz szó.
A SIGHASH NOINPUT használata nélkül a tranzakciót nem lehet elkölteni ha a rá érvényes aláírásokat nem cserélik ki a felek mivel a betöltő tranzakció megköveteli a tranzakciós ID létezését az aláírás mellett, amikor a következő bemenetet létre szeretnénk hozni. A tranzakciós ID része a szülő (betöltő tranzakció) aláírása emiatt tehát a feleknek ki kellene cserélni az aláírásokat ahhoz hogy a következő tranzakciót el tudják költeni. Ha viszont ez megtörténik, akkor aki épp birtokában van a teljes aláírásnak az a már aláírt betöltő tranzakciót be tudja küldeni a hálózatba még azelőtt hogy a következő tranzakciót egyáltalán létrehozták volna. A SIGHASH NOINPUT soft-fort ezt úgy küszöböli ki, hogy lehetővé teszi a költekezést a következő tranzakcióból anélkül, hogy a bemenetet aláírták volna.
A SIGHASH NOINPUT tranzakciók a következő módon haladnak:
1. A betöltő (szülő) tranzakció létrehozása
2. A gyerek tranzakció létrehozása ( szerződéses tranzakció és az összes ebből történő költekezés)
3. A gyerek tranzakció aláírása
4. A gyerek tranzakcióra vonatkozó aláírások kicserélése
5. A szülő tranzakció aláírása
6. A szülő tranzakcióra vonatkozó aláírások kicserélése
7. A szülő tranzakció beküldése a hálózatba
A szülő tranzakció beküldése előtt a 6-os és 7-es lépéseket végre kell hajtani. A 6. lépésig egyik fél sem adta még meg a betöltő tranzakcióra vonatkozó aláírását. Továbbá ha bármelyik fél a 6. lépés során eltérne a protokolltól a szülő tranzakciót el lehet költeni és így abból lesz végül szülő tranzakció vagy a szülő tranzakcióval dupla költést lehet megpróbálni és ez teljesen érvénytelenné teszi így majd az utat.
Miután a betöltő tranzakció létrejött (de nem lett még aláírva és kiküldve) a felek aláírnak és kicserélnek egy kezdeti elköteleződéses tranzakciót. Ez a tranzakció a 2-2 multisig tranzakció (szülő) kimenetét költi el, de ekkor még csak a betöltő tranzakciót küldik ki a láncra. Mivel ez a tranzakció kikerült a láncra és a kimenet egy 2-2 multisig tranzakció, amely mind a két fél beleegyezését igényli, az elköteleződéses tranzakció képes az aktuális egyenleget tükrözni. Ha a felek csak egy 2-2 aláírt elköteleződéses tranzakciót cserélnek ki egymás között, akkor azok később, amikor a betöltő tranzakció publikálásra kerül biztosak lehetnek abban, hogy vissza tudják majd szerezni a pénzüket gond esetén. Amíg nem szeretnék lezárni az egyenlegeket egyik fél sem publikálja az elköteleződéses tranzakciót. Amikor le szeretnék zárni saját egyenlegüket, csak egyszerűen kiküldik ezt a tranzakciót a láncra. Az elköteleződéses tranzakció publikálás után az aktuális egyenlegnek megfelelő kriptovalutát kiküldi a megfelelő felhasználóknak. Egy egyszerű (és rossz) megvalósítás egy olyan tranzakciós üzenetet hozhat létre, amely egy 2-2 költést hoz létre egy tranzakcióból és ez két kimenettel tér vissza, ami minden aktuális egyenleget visszaad a feleknek. Ezzel az egyik fél minden valutáját visszakapná és így hozna létre egy elköteleződéses tranzakciót. Vegyünk a megértéshez egy egyszerű példát. Tegyük fel, hogy A és B megegyezik egy betöltő tranzakcióban, amelynek során egy 2-2 kimenet jön létre 1.0 BTC értékkel. Mind a két fél 0.5 BTC-vel tölti fel a csatornát. Ezek után létrehoznak egy elköteleződéses tranzakciót, amely A-t és B-t is 0.5 BTC-vel látja el. Először a felek aláírják az elköteleződéses tranzakciót és az ehhez tartozó kulcsaikat ki is cserélik, biztosítván ezzel egymásnak a lehetőséget arra, hogy az elköteleződéses tranzakciót bármikor ki lehessen publikálni a láncra, attól függően, hogy a betöltő tranzakció mikor kerül ki a láncra. Ekkor a betöltő tranzakcióra vonatkozó aláírásokat ki is lehet cserélni, hiszen bármelyik fél képes visszaszerezni a pénzét ha publikálja az elköteleződéses tranzakciót. Az ilyen jellegű megvalósítás viszont nem működőképes ha az aktuális egyenleget szeretnénk frissíteni. Ha ezt is szeretnénk garantálni, akkor az elköteleződéses tranzakció kimeneti értékeit is frissíteni kellene. A betöltő tranzakció, mint tudjuk már kiküldésre került és be is épült a blokkláncba. A felek megegyezhetnek egy új elköteleződéses tranzakcióban és az erre való aláírásukat ki is cserélhetik. Ekkor viszont bármely elköteleződéses tranzakciót ki lehet publikálni. A betöltő tranzakció kimenetét viszont csak egyszer lehet elkölteni, így tehát csak az egyik elköteleződéses tranzakció lesz elfogadva a láncban. Ha például A és B úgy dönt, hogy mostantól az egyenlegek legyenek 0.4 BTC és 0.6 BTC és erre vonatkozóan csinálnak egy új elköteleződéses tranzakciót, akkor bármely elköteleződéses tranzakciót ki lehet publikálni a láncra. A 0.5 BTC - 0.5 BTC és a 0.4 BTC - 0.6 BTC párra vonatkozót is. Más szóval nem lehet kikényszeríteni egyik félből sem, hogy melyik elköteleződéses tranzakciót publikálja majd, hiszen mind a két fél rendelkezik egy-egy helyes aláírással mind a két üzenetre vonatkozóan. Nyilván bármely felhasználó azt az egyenleg párt leíró tranzakciót fogja majd megpróbálni publikálni, amelyik végeredményben nagyobb egyenleget eredményez majd számára. A sakk-matt helyzetet végül úgy zárul, hogy a csatornát azonnal lezárják és az egyik felhasználó meglopja a másikat. Így tehát megbízhatóan működő mikrofizetési csatornát nem lehet létrehozni.
Mivel bármikor meg lehet egyezni egy új egyenleg párban a csatornában és az ebből következő elköteleződéses tranzakciókat bármikor ki lehet publikálni fontos lesz meggátolni, hogy a régi érvényesnek már nem tartott elköteleződéses tranzakciók kikerüljenek a láncra. A bitcoin blokklánca nyilvánvalóan nem alkalmas arra, hogy több ezer tranzakciót kitöröljünk belőle. Így tehát más jellegű megoldásra van szükség. A folytonos törlés helyett hűség alapú rendszert érdemes létrehozni. Ha hűek vagyunk ahhoz ami mellett elköteleződtünk, akkor a protokoll az előírt működés szerint halad tovább és a tranzakciók folytatják útjukat a csatornában. Ha nem, akkor a protokoll megbüntet, vagyis a csatornában lévő összes pénzt elveszik tőlünk. A fizetési csatornában a főszabály az, hogy a felek csak a legújabb (az aktuális egyenleget hűen tükröző) tranzakciót publikálják. Ha ennél régebbi tranzakciót próbál valaki beküldeni, akkor azt a protokoll úgy értelmezi, hogy a fél megszegte a szabályokat és a csatorna teljes tartalma átutalásra kerül a másik fél számára. Erre csak úgy van lehetőség ha a másik fél be tudja mószerolni a csalót és emelett egy kriptográfiai bizonyítékot is fel tud mutatni. Ehhez szigorúan meg kell tudni különböztetni hogy ki és mikor küldte be az adott elköteleződéses tranzakciót, amihez az kell, hogy az adott fél identitása egy időbélyeggel szerepeljen az elköteleződéses tranzakció publikálása során. A tranzakciót mind a két félnek alá kell írnia és azt valamelyik fél fogja kiküldeni a láncra. A felek olyan elköteleződéses tranzakciót tartanak maguknál, amit a másik aláírt és ezt tudják kiküldeni a láncra. Az LN-ben az elköltő tranzakciók a betöltő és az elköteleződéses tranzakciókból félig vannak aláírva. Egy elköteleződéses tranzakciót ír alá A, majd odaadja B-nek és fordítva. Mind a két tranzakció ugyanazt a betöltő tranzakciós kimenetet költi el, a tartalmuk viszont eltérhet és csak az egyik variánst lehet kipublikálni a láncra, mivel mind a két tranzakció ugyanazt a tranzakciós kimenetet költi el. A felek, miután megkapták a másik féltől az aktuális egyenleget reprezentáló tranzakciót és azt kiegészítették a saját aláírásukkal publikálhatják azt. A tranzakciót a lánc végül el fogja fogadni és a betöltő tranzakció 2-2 kimenetét fogják elkölteni. Ehhez fog kelleni A és B aláírása is. Igen ám, de még ezzel a trükkel is csak hibáztatni tudják egymást a felek, viszont a bitcoin blokklánca nem ad lehetőséget a csaló megbüntetésére. B-nek meg kell bíznia A-ban, hogy az nem fogja a régi egyenleget tükröző tranzakciót publikálni. Ha ez mégis megtörténik, akkor lesz a kezében egy A által félig aláírt kriptográfiai bizonyíték, de ettől még nem jut a pénzéhez.
Ha egy blokkláncon való szerződés feltételeit be szeretnénk tartatni a felekkel, akkor olyan elköteleződést tükröző tranzakciókat kell megvalósítani, amely visszavonható. Ezt úgy tudjuk elérni, ha rögzítjük, hogy mikor ért be egy tranzakció a lánca és a tranzakció életkorából számítunk egy feltételt arra vonatkozóan, hogy meddig tekintünk érvényesnek egy tranzakciót.
Egy Mark Freidenbach által előterjesztett soft-forkban már szerepel a kikövetelhető sorszámozás ötlete. Ebben a szülő tranzakcióktól kezdve a rákövetkező blokkok számából ki lehet számolni egy csökkenő sorszámot. Ebből az ötletből kiindulva meg lehet valósítani egy olyan primitív logikát, ami az elköltő szkriptekbe időzárakat képes tenni. Továbbá az OP CHECKSEQUENCEVERIFY és az OP RELATIVECHECKLOCKTIMEVERIFY opkódok további funkciók implementálását is lehetővé teszik és ezek segítségével rögtönzött megoldásokat lehet adni a tranzakció megmásíthatóság problémájára, mindaddig amíg nem találnak ki egy örökérvényű megoldást.
Összegezve tehát elmondhatjuk, hogy a bitcoin-t eredetileg úgy tervezték, hogy a sorszámokból következő feltételeket csak a mempool-ban (még meg nem erősített tranzakciók halmaza) lehetett biztosítani. Eredetileg tehát a mempool-ban ki lehetett cserélni a régi tranzakciókat ha szimplán felülírtuk a sorszámot. A DoS jellegű kockázatok miatt a tranzakciók felcserélési feltételeiket a protokoll figyelmen kívül hagyja. Úgy tűnik tehát, hogy a sorszámok eredeti célja tehát a publikálásra még nem került tranzakciók felcserélés volt, ezt azonban nem lehet megkövetelni a lánctól, hiszen semmi garancia nincs arra, hogy a magasabb sorszámú tranzakció valóban be is fog kerülni a láncba. Így tehát a legfrissebb tranzakciók előtérbe helyezését csak a láncon kívül lehet megoldani.
Egy visszavonható tranzakció egy egyedi kimenetet költ el és a tranzakcióban egy egyedi kimeneti szkript szerepel. A szülő kimenete két visszafizetési utat tartalmaz. Az egyiket azonnal végre lehet hajtani, a másikat pedig csak akkor, ha a gyerek tranzakció tartalmaz legalább valamennyi megerősített blokkot (ergo eltelt valamennyi idő). Ezt úgy lehet megvalósítani, hogy ha a gyerek tranzakciótól megköveteljük, hogy a szülőhöz képest a sorszáma valamennyivel nagyobb legyen. Valójában itt arról van szó, hogy a csak akkor engedjük meg elkölteni a tranzakciót, ha a beérkezett blokkok száma a kimenet és a visszatérítő tranzakció között egy bizonyos értéket meghalad. Egy tranzakciót vissza lehet tehát vonni ezzel a módszerrel. Ehhez a tranzakciós sorszámok és a blokkok sorszáma között kell feltételeket felállítani. Csak akkor engedjük meg tehát a tranzakciós kimenetek elköltését ha a szülő blokk már egy bizonyos mélységet elért a blokkláncban. Ez egy olyan struktúrát fog eredményezni, amelyben a szülő tranzakció az adott bemenettel egy betétet reprezentál és arról árulkodik, hogy még nem lett visszavonva. Ezek után lesz egy időablak, amelynek során ezt a tényt lehet cáfolni, azzal ha valaki ezalatt publikál egy, a tranzakciós kimenetet elköltő tranzakciót.
Ha például egy 1000-es időbeni eltolással szeretnénk létrehozni egy visszavonható tranzakciót, annak a kimeneti tranzakciója továbbra is egy 2-2 multisig jellegű tranzakció lenne. A bitcoin szkriptnyelvének segítségével ezt a következő módon lehet leírni:
2 A1 B1 2 OP CHECKMULTISIG
Viszont a gyerek tranzakció, ami ezt elköltené már tartalmazna egy 1000 értékre állított nSequence mezőt. Ezt a tranzakciót mind a két félnek el kell fogadnia, így tehát a felek az aláírásuk részeként az nSequence = 1000 adatot is csatolni fogják a tranzakcióhoz. Ha a felek szeretnék, akkor hozthatnak még létre tranzakciókat, akár az nSequence mező beállítása nélkül. Az így létrejövő tranzakciós szerkezetet nevezzük Visszavonható Sorszámozott Öregedő Szerződésnek (Revocable Sequence Maturity Contract, vagy RSMC angolul). Az RSMC két lehetséges utat fog kijelölni a szerződéses feltételeknek megfelelően. A szerződés feltételei a következők lesznek:
1. Mind a két fél kriptovalutát kell hogy küldjön a szerződésre, amely megszabja a beküldött valuták elköltésének módját
2. A felek megegyezhetnek abban is, hogy valutát küldenek egy szerződés irányába és ekkor továbbá egy várakozási idősávot is beállítanak (mint a fenti például az 1000-re állított mező). Ez lesz a visszavonható kimeneti egyenleg.
3. Vagy az egyik vagy a másik, vagy mindkét fél dönthet úgy, hogy a kifizetésért felelős tranzakciót egy bizonyos jövőbeni dátumig nem publikálja. Bármely félnek lehetősége lesz hozzájutni valutájához miután az időzár lejárt.
4. Ha egyik fél sem szándékozik visszavenni a befizetett kriptovalutáját és egy rákövetkező tranzakciós üzenetben megeegyznek arról, hogy új visszafizető tranzakciót hoznak létre, akkor az eddigi feltételeket leíró visszafizető tranzakciós üzenetet felül lehet írni. Az új feltételekkel publikált szerződés éles lesz, amint az kikerül a láncra.
5. Ha a szerződés kikerült a láncra és az új feltételeket még nem aktiválta egyik fél sem, akkor valamelyik fél felelőssége lesz a régi feltételek felülírása az új tranzakciós üzenet kipublikálásával.
Az félig előírt gyerek tranzakciót élesíteni lehet akkor ha a szülő tranzakció bekerült a láncba és az ahhoz tartozó blokkra 1000 új blokk épült. Ezt a feltételt a gyerek tranzakció nSequence mezőjével lehet megkövetelni, azaz csak ekkor engedjük meg elkölteni a kimenetet. Ha a felek meg szeretnék semmisíteni ezt a gyerek tranzakciót, akkor nincs más dolguk minthogy publikálnak egy új gyerek tranzakciót és az nSequence mezőt MAX_INT értékre állítják. Ezt a protokoll úgy fogja értelmezni, hogy azt bármikor el lehet majd költeni.
Ha félig aláírt gyerek tranzakciót felül lehet írni egy új gyerek tranzakcióval, mindaddig amíg a szülőre 1000 blokk nem épült rá. A valóságban A és B monitorozzák a láncot és detektálják ha számukra nem elfogadható elköteleződéses tranzakció kerülne publikálásra. Ha ez megtörténik, akkor bármelyik fél azonnal publikálhat egy ezt felülíró tranzakciót és elkölthetik a kimenetet. Ha a visszatérító tranzakciós kimenetet szeretnék elkölteni (ami ugyan abból költene mint a következő), akkor 1000 blokkot kellene várniuk. Így tehát ha mind a két fél figyeli a láncot, a visszatérítő tranzakció sosem tud élesedni a láncon ha legalább az egyik fél a következő tranzakciót preferálja. Ezzel a tranzakciós mechanizmussal bárki létre tud hozni tranzakciókat és azokat nem kell feltétlenül publikálnia, továbbá létre tudunk hozni olyan motiváló tényezőket, amelyek meggátolják a felhasználókat bizonyos (a protokoll helyes működésének ellentmondó) tranzakciók publikálásában. Így a tranzakciók jelentős részét a láncon kívül lehet lebonyolítani.
A mempool tranzakciókkal való elárasztása biztonsági rést jelenthet a LN számára. Ezt oly módon kell akadályozni, hogy egy potenciális támadót elbátortalanítson, azaz több vesztesége keletkezzen, mint profitja ha véletlenül nem sikerül a támadás. Greg Maxwell a reddit-en egyszer már megosztotta ötletét ezzel a problémával kapcsolatban. Szerinte az elárasztott mempool problémáját úgy lehetne orvosolni, hogy a blokkokat meg kellene jelölni aszerint, hogy épp torlódás van-e a mempool-ban vagy nincs. Ha a mempool-ban nagyon sok tranzakció várakozik, akkor a sorozatszámot nem kellene növelni. Ha egy DoS támadás során elárasztják a mempool-t, akkor blokkok ugyan kerülnek a láncba, viszont ahhoz mivel a mempool tele van, kicsi lesz az esélye annak, hogy egy új tranzakciót fel tudnak venni a node-ok és az valószínűleg még sokáig nem fog aktivizálódni. A blokkok száma a módosítás nélkül viszont folyamatosan növelné az nSequence mező összehasonlítandó értékét és bizonyos szerencsétlen esetekben a támadó le tudna lépni a befizetett valutával ha sikerül neki idő előtt lezárnia a fizetési csatornát. A döntést a bitcoin bányászokra lehetne bízni. Ha például a mempool mérete egy bizonyos küszöbérték felett van, akkor a mezőt automatikusan 1-re lehetne állítani és ez a blokk akkor nem számítana az nSequence mezőre adott feltétel vizsgálata során. A döntés, miszerint egy bányász az adott blokkot feltorlódottnak ítéli teljes mértékben rá lenne bízva. Ha feltételezzük, hogy a bányászok nem alkotnak 51% feletti koalíciót a protokoll átverése céljából, akkor a legtöbben az alapértelmezett beállításokat használnák és ez nem okozna biztonsági rést.
Ha például a gyerek és a szülő tranzakció között megkövetelünk 10 blokkot, de közben van egy blokk, amit az adott bányász úgy értékelt, hogy a bányászat közben a mempool el volt árasztva, akkor nem 10, hanem 11 blokkot kell várni ahhoz hogy a gyereket el lehessen költeni. A timestop bitet be lehetne kapcsolni ilyen esetekben. Ha a mempool-ban megszűnik a torlódás, akkor ki lehetne azt kapcsolni és ekkor számolódna tovább a relatív blokk magasság. Ezzel lehetne elég időt és blokk helyet biztosítani minden az LN számára fontos tranzakció számára és a rendszert szisztematikusan támadó rosszindulatú felhasználókat el lehetne lehetetleníteni. A timestop mezőt az SPV (Simple Payment Verification) kliensek miatt inkább a 80 byteos blokk fejlécbe kellene rakni és nem a coinbase részbe. Erre két jó hely is kínálkozik. Az egyik a blokk idő, a másik pedig a blokk verzió. Az ASIC bányászok a blokk idő utolsó bitjét entrópia forrásként használják, így ez nem biztos hogy jó ötlet. A timestop mezőt a bitcoin konszenzus szabályainak megváltoztatásával is be lehetne vezetni, ez azonban egy kevésbé rugalmas megoldás lenne. Ha viszont a timestop beállítására értelmes szabályokat tudnánk létrehozni, akkor a konszenzus mechanizmuson nem kellene változtatni. Ha a blokk verzióba tennénk bele, akkor a láncot kijelölő azonosítót (chain ID) is ennek megfelelően kellene állítani (pl. bitcoin mutáns altcoinok).
Abban az esetben ha valamelyik félnek a kezében van egy kriptográfiai bizonyíték arra, hogy a másik csalt és továbbá a tranzakciók visszavonható módon vannak megvalósítva el lehet dönteni, hogy ki nem tartja be a szerződésben foglaltakat és ezt a felet meg lehet büntetni. Az új elköteleződéses tranzakciót azért hozzák létre elvileg a felek, hogy az eddigi tranzakciókat megsemmisétsék és hogy új egyenlegben állapodjanak meg. A régi tranzakciókat úgy lehet érvénytelenné tenni ha a kimenetet RSMC-nek állítjuk be. Ha az új tranzakciót mind a két fél aláírta és azt kicserélték egymás között és ha esetleg valamelyik fél ennél régebbi tranzakciót próbálna meg publikálni, akkor a csatorna teljes tartalma átutalásra kerül a másik fél részére. A protokollnak ellentmondó tranzakciót detektálható, hiszen lesz egy másik tranzakció, amelynek a végső egyenlege ezzel megegyezik és a kifizetés az adott fél részére egy RSMC-vel van ellátva. Szóval lesz két elköteleződéses tranzakció, egy szülő tranzakcióval, amelynek egy 2-2 kimenete van. Ezen két gyerek tranzakció közül csak egy juthat be a blokkláncba és a csatornában tartozkodó felek az birtokolják a két variáns közül az egyiket. A-nál van a C1a tranzakciós üzenet, B-nél a C1b tranzakciós üzenet. Ha valaki beküldi ezt az üzenetet a node-oknak, akkor ezzel azt jelzi, hogy szeretné lezárni a csatornát. Az elköteleződéses tranzakció első két kimenete tartalmazza a két fél végleges egyenlegét.
Ha például A publikálja a C1a tranzakciót, akkor annak a kimenetét D1a fogja tudni elkölteni és ez B-nek küld BTC-t és ugyan ez igaz fordítva is C1b-re vonatkozóan. D1a és D1b és azonnal aktiválható és amit C1a vagy C1b publikálásra került róluk a pénz felvehető.
Az együttműködő felek megegyeznek abban, hogy csak a náluk lévő legaktuálisabb egyenleg rendező (elköteleződéses tranzakciót) publikálják. Elfogadják tehát, hogy az aktuális egyenleget ez reprezentálja és konszenzusban vannak abban, miszerint ez a tranzakció fogja kifizetni a partnert megillető valutákat. Annak a helyességéről viszont, hogy a legaktuálisabb egyenleget rendező tranzakció mennyit fog kifizetni annak, aki azt publikálta nem tudunk semmit mondani. A blokkláncot ellenőrző felhasználók nem tudják, hogy valóban ez-e a legfrissebb egyenleg rendező tranzakciós üzenet. Ha viszont valaki szándékosan egy régebbi tranzakciós üzenettel próbálkozik, akkor a protokoll megbünteti, mégpedig úgy, hogy a csatorna teljes tartalmát átutalja a másik félnek. Mivel a saját magát illető átutalás időzár (RSMC) alatt van, várnia kell mire hozzájut saját pénzéhez. A jelen példában 1000 blokknak kellene ráépülni, míg fel tudja venni a pénzét. Ha viszont a legújabb egyenleg rendező tranzakciót publikálják, akkor utána nem fog következni új tranzakció, így tehát a fél egy bizonyos blokkszám után hozzá fog jutni a pénzéhez. Ismert továbbá az is, hogy ki publikálta az egyenleg rendező tranzakciót, mivel a rá vonatkozó kifizetés RSMC alatt áll, így tehát a jövőben ezt a tranzakciót bármely fél vissza tudja majd vonni.
A feleknek megvan a lehetőségük a csatornában lévő BTC-k kiutalására. Az RSMC azonban azon fél számára, aki a tranzakciót publikálta időzárat állít be. A másik fél viszont azonnal felveheti a pénzét. Ha például A és B 1 BTC-vel tölti fel a csatornát és A hozzá szeretne jutni a 0.5 BTC-jéhez, akkor publikálja az egyenleg rendező tranzakciót. Ekkor B azonnal felveheti a 0.5 BTC-jét, A-nak viszont 1000 blokkot kell várnia. Ha A elfogadja, hogy B a helyes egyenleg záró tranzakciót publikálta, akkor számára a csatorna bezárult. Az 1000 blokkos zárra azért van szükség, mert a felhasználónak ezzel azt tudja ezen idő alatt bizonyítani, hogy a végső tranzakciót nem vonta vissza. 1000 blokk beérkezése után a visszavonásra van lehetőség. Ha egy fél mégis úgy dönt és nem várja meg az 1000 blokk beérkezését és publikál egy új tranzakciót, akkor az 1000 blokkig nem aktivizálódik. Ezek után pedig ha a kimenetet még nem költötték el a blokklánc ezt fogja aktív tranzakciós üzenetnek tekinteni.
A csatornában bármely félnek lehetősége van az egyenleget lezárni és hasonló módon bármikor frissíthetik azt és ezzel a régi egyenlegeket érvénytelenítik. Tegyük fel például, hogy A és B szeretnék frissíteni az egyenlegeiket, amik eddig 0.5 BTC - 0.5 BTC-ben voltak rögzítve 0.4 BTC - 0.6 BTC-re. Ha ebben megegyeznek, akkor új egyenleg rendező tranzakciókat hoznak létre és az ezekre vonatkozó aláírásaikat kicserélik valamint a régi tranzakciókat érvénytelenné teszik. Az érvénytelenítés úgy történik, hogy a felek felváltva aláírnak egy olyan büntető tranzakciós üzenetet is, amely a csatorna teljes tartalmát átutalja az ő részükre abban az esetben ha a másik fél, a protokollnak ellentmondó módon a régebbi egyenleg rendező üzenetet próbálná meg kipublikálni. Abban az esetben ha mind a két fél aláírta a büntető tranzakciót, akkor azt mondhatjuk, hogy a két fél konszenzusba került az új egyenlegekre vonatkozóan. Az új egyenleg a kettőjük között akkor jön tehát létre ha megegyeztek abban, hogy ha esetleg a régit próbálnák meg publikálni a blokkláncra, akkor a csatorna teljes tartalmát elvesztik és az átutalásra kerül a másik fél számára. Ez a büntető mechanizmus lesz tehát az, amely eltántorítja a feleket attól, hogy annak ellenére, hogy már megegyeztek egy új egyenleg párban mégis a régi párt leíró tranzakciós üzenetet publikálják. Más szóval, ezzel a mechanizmussal lehet kikényszeríteni a felekből azt, hogy az új egyenleg párt elfogadják és ne próbálják meg átverni a másikat.
Amint aláírásra került a büntető tranzakció, a feleknek érdekében áll minden régi egyenleg párról szól tranzakciós üzenetet kitörölni, hiszen ha véletlenül ezek közül publikálnának egyet, akkor elvesztenék a csatorna teljes tartalmát.
Ha például az egyik fél véletlenül, vagy szándékosan egy régi tranzakciós üzenetet próbál meg publikálni a hálózatba, akkor a másik félnek (a jelen példában) van 1000 blokknyi ideje arra hogy kiürítse a csatornát. Ezt a protokoll úgy értelmezi, hogy az adott fél csalni próbált, a másik fél pedig érvényesítve jogát a csatorna teljes tartalmát átutalhatja magának. Az új egyenleg párt leíró tranzakció akkor kerül aktivizálásra ha mind a két fél aláírta azt a tranzakciós üzenetet is, amely kiüríti a csatornát ha a blokkláncon megjelenik egy régebbi egyenleg rendező tranzakció. A bitcoin konszenzus mechanizmusa időrendi sorrendbe tudja állítani a blokkokat és így lehet a LN protokoll szabályait kikényszeríteni a felekből.
Az egyik félnek azonban az előre beállított időzár lejárta után nincs lehetősége kiüríteni a csatornát. Ha ő egy új egyenleg párról tud, de közben (mondjuk 1000 blokk után) aktivizálódik a régi egyenleg pár, mert a másik fél azt publikálta ki, akkor a fél nem tud mit tenni. A blokklánc 1000 blokk beérkezés után úgy dönt, hogy a vitára adott időperiódus lezárult. Ezért fontos lehát a blokklánc folyamatos monitorozása. A monitorozási feladatot ki lehet szervezni egy harmadik félnek. Minden egyes egyenleg pár frissítés után oda lehet adni a harmadik félnek a büntető tranzakciós üzenetet. A harmadik fél csak akkor tudja lezárni a csatornát ha a másik fél megpróbál csalni, így tehát normális esetben nem gyakorol irányítást a csatorna felett.
A csatornának alkalmasnak kell lennie arra, hogy abban visszavonható (felülírható) egyenleg rendező tranzakciókat hozzanak létre a felek biztonságos módon, úgy hogy közben a protokollnak nem megfelelő magatartás el legyen lehetetlenítve.
Először is el kell dönteni, hogy melyik publikus kulcs lesz használva az aláírás során. A SIGHASH_NOINPUT üzenetnek meg kell adni egy egyedi publikus kulcsot minden egyes új tranzakciós üzenet (RSMC vagy HTLC eset) létrehozása során. Jelöljük P-vel a publikus kulcsokat és K-val a hozzá tartozó privát kulcsokat.
Az első egyenleg pár rendező tranzakciós üzenet létrehozása során A és B megegyeznek egy multisig tranzakciós kimenetben, amely a betöltő tranzakcióra vonatkozik. Ezen tranzakciós üzenet aláírásához szükség lesz A és B kulcsára is. Az üzenetbe 1 BTC-t helyeznek el 0.5 BTC és 0.5 BTC arányban. Ez egy egyszerű PayToScriptHash tranzakció kimenete lesz majd és ennek elköltéséhez kell majd A és B aláírása is. Ezen a ponton azonban ezt a kimenetet még nem teszik elkölthetővé és az ehhez az üzenethez tartozó kulcsaikat nem használják egyéb más üzenetek aláírására.
Szerző: LB
Figyelem: A bejegyzésben található információk tartalmazhatnak hibát. A szerző az abból eredő károkért nem vállal felelősséget!
