Nodesignal-Buchclub - E166 - Mastering the Lightning Network - Routing (Kap. 8)

und können loslegen. Perfekt. Bevor wir in Inhalte einsteigen, natürlich wie immer der Hinweis, wir sind ein Value for Value Podcast. Falls euch Node Signal einen Mehrwert bietet, würde es uns sehr helfen, wenn ihr beim Hören von Node Signal uns ein paar Satz streamt Und oder uns einen Boost schickt. Mit den Boosts könnt ihr uns auch eine Nachricht schicken, die wir dann in unserem

regelmäßigen Value for Value Folgen besprechen. Würde uns sehr freuen, wenn ihr unsere Arbeit ein bisschen unterstützt. Macht es vor allem, wenn ihr denkt, dass es euch einen Mehrwert bietet.

Jo, wir reden heute über das Kapitel acht, bevor wir da einsteigen, Kapitel sieben, Zahlungskanäle.

Oberflächliche Überblick, den kriegen wir, glaub ich, trotzdem noch hin. Ja, wir haben über Zahlungskanäle an sich gesprochen, wie diese Onchain Erstellt werden, also wie diese Transaktionen, die dann online generiert werden, dann aufgesetzt werden, dass wir dieses dieses zwei von zwei Multi Stick bauen und da dann Diesen Zahlungskanal dann im Bitcoin Netzwerk verankern. Wir haben gelernt, dass es sehr, sehr wichtig ist, dass man zu jeder Zeit als Lightning quasi Kanalpartner

in der Lage sein muss, seine Funds auch wieder onchain zu bringen. Das heißt, da ist es besonders wichtig, dass man diese Commitmenttransaktion immer up to date ab, das ist halt insbesondere dazu wichtig, weil das ist halt diese Sanktionierungsmechanismus, dieses Fairnessprotokoll, was in Bitcoin Oder dafür implementiert worden ist, halt, wie ich's grade schon gesagt habe, jederzeit diese Funds dann wieder zu bringen.

Und Dieser Sanktionierungsmechanismus, den es da dann auch gibt, der dann wiederum dann halt bei betrügen dann im Zweifelsfall dann dazu führt, dass Dass man seine eigenen Einsätze, seine eigenen Funds verliert, führt im Endeffekt dazu, dass das Lightning Netzwerk Off Chain benutzt Werden kann und so prinzipiell alle Teilnehmer einen Anreiz haben, auch ihre Transaktionen nicht onchain zu setteln, sondern offchain zu halten und dadurch prinzipiell sich dann auch teuren Blockspace und Teurer

Transaktionsgebühren zu sparen, als wenn man das, wenn man dann halt jede Transaktion jetzt machen würde. Das ist soweit eigentlich das, was worum's dann im vorigen Kapitel ging.

Ja, worum geht's? Weiß nicht, wollen wir mal auf die Abbildung acht zwei gucken? Das ist quasi die die zweite Abbildung in diesem Kapitel.

Aber nur, damit ihr halt wisst, das ist halt trotzdem das erste richtige Bild in diesem Kapitel. Ja, los geht's.

Die Information rausgeben will, dass man ein übers Lightning Netzwerk Zahlungen senden kann, selbst wenn man keine direkte Verbindung zu einem zu seinem Ziel halt hat, ne. Also dass das Dass hier wirklich dann das Schöne daran ist, dass man dieses über mehrere Knoten oder Notes hinweg Zahlungen weiterleiten kann und nicht jetzt ich mit jedem, mit dem ich eine Zahlung austauschen möchte, dass ich zudem auch wirklich 'n Kanal haben muss. Das ist, glaube ich, hier die elementare Information.

ne. Also die Wegfindung ist erst mal Eigentlich das, was sich, dass ich mir erst mal eine Information über die Gesamttopologie oder über den Aufbau des Netzwerks verschaffen muss, dass es im Endeffekt die Wegfindung, dass ich halt weiß, Okay,

es gibt einen Pfad, der halt von Alice zu Bob, von Bob zu Chan und von Chan zu Dina geht. Das ist der Pfad und das Routing an sich Ist dann eigentlich das, was wir jetzt eigentlich heute besprechen wollen, das ist dann die Art und Weise, wie technisch dann die die Zahlung dann zwischen diesen Partnern dann propagiert wird und Im Idealfall dann die Diener erreicht, wenn die Alice ihre Zahlung versenden möchte oder sendet. Das bedeutet aber, dass dass die Wegfindung

Das eine ist aber das Routing, das andere. Also man es kann einmal es kann also es kann einen Weg geben, aber es heißt nicht zwangsläufig, dass dieser Weg in quasi Just in diesem Moment, wo wo ich diesen Weg auch benutzen möchte, auch verfügbar ist, Weil wir halt vielleicht keine Liquidität haben, weil halt vielleicht der Partner, der dazwischen, den ich für das Routing oder für die für die doch fürs Routing brauche, nicht zur Verfügung steht, weil er irgendwie seine Lightning Note offline gestellt Das sind halt so die die Sachen, wo die man hier dann unterscheiden muss, ne. Also der Pfad kann vorhanden sein, aber ich find halt einfach keine Route, weil halt die Straße gesperrt ist im im Zweifelsfall, ne. Also ne. Also da sone Allergologie zur, wenn ich von hier aus nach Berlin fahren will, kann ich das halt grundsätzlich dann halt machen, wenn ich von die a zwei nach Hannover nehm und von da aus Osten fahre, aber wenn die Autobahn da komplett kaputt ist, dann funktioniert da halt diese Route nicht, ne. Das mal so als Beispiel dann, um's mit dem Straßenverkehr zu vergriffen. Ja, gute Anatomie. Mhm. Jo.

Jo, und ich würde fast schon direkt in dieses Beispiel einsteigen wollen, das in diesem Kapitel beschrieben ist, weil ich find das eigentlich ganz Ja. Schön gelöst in diesem Kapitel. Das muss ich, vielleicht können wir das an dieser Stelle mal sagen, wir haben uns ja mit den letzten beiden Kapiteln sehr schwergetan. Dieses Kapitel fand ich wiederum sehr gut zu lesen.

Und es ist so strukturiert, dass, Ne, also es wird jetzt das Szenario war jetzt aufgemalt, das haben wir gerade besprochen und jetzt wird eine Analogie verwendet, halt zu etablieren, wie dieses Routing denn stattfinden könnte. Und zwar wird gesagt, Das bei, also 'n Beispiel gewählt und gesagt, okay, wir machen das am Beispiel. Es würden Goldmünzen

von Alice zu Dina geschickt werden, halt über Bob und Chan. So und daran wird jetzt erst mal erklärt, wie das funktioniert und was die Herausforderungen sind und wie man das geschickt lösen kann. Und wir werden dann, glaube ich, sehen, dass später, wenn es dann In die Implementierung geht, wie das dann halt bei Bitcoin im Lightning Netzwerk gelöst ist. Also wie's dann genau umgesetzt ist. Dieses Beispiel erinnert mich irgendwie wieder son bisschen an Rocket Bitcoin, wo er auch dann erst mal mit diesem ganz abstrakten Cookie Token Beispiel angefangen hat. Und dann wird es dann später dann zu echte echtem Bitcoin als Implementierung. Und son bisschen geht das jetzt ja auch so, dass das jetzt so Schritt für Schritt dann wieder aufgebaut wird,

Warum sollte Bob das machen zum Beispiel? Das war ja dann auch eine Schwierigkeit, die dann als Erstes aufkam. Warum warum sollte Bob jetzt sich die Mühe machen, das dann weiterzugeben oder vertrauensvoll sein? Genau. Und dann kam man schon schnell auf, ja, es muss 'n kleiner Obolus drin sein, deswegen werden nicht bloß diese zehn Goldmünzen gesendet, Sondern ich glaube, sie entscheidet sich dann zwölf zu senden und jeweils einen für die Mittelsmänner Ja. In diesem Kanal.

Mhm. Und das heißt, ne, der Bob könnte damit mit dem Geld abhauen oder einfach nicht weitergeben oder was auch immer. Sie kann ja nicht darauf vertrauen, dass sie's macht. Und jetzt sagt sie halt, okay, dann machen wir eine Bedingung. Und zwar, ich, Alice erstattet dir Bob zehn Geldmünzen, wenn Du mir nachweisen kannst, dass Du an Chan gezahlt hast. Und dieses gleiche Konstrukt Baut halt dann, ne, macht dann also diesen gleichen Vertrag,

konstruiert dann Bob auch mit Chan, dass er nämlich sagt, hey, Chan, Ich gebe dir zehn Goldmünzen, wenn Du mir nachweisen kannst, dass Du Geld an Diener geschickt hast.

Dass dass man sich da auf die Seite schon mal vertraglich an sich absichert, ne. Und dann zieht sich das halt durch die ganze Kette, wie Du's grade schon gesagt hast. Und dann Kommt der Punkt, den Carl so gerade schon angeführt hat, dass mit den, dass man den Anreiz halt hat, dass dass man quasi nicht betrügt, man halt dieses Fairnessprotokoll,

also einen Teil davon auch, ne, dass man halt 'n Anreiz schafft für die Teilnehmer in dieser in diesem Routing Ablauf so. Du das machst, dann kriegst Du sogar noch was dafür. Also Du kannst auch noch was behalten. Mhm. Und dann sieht die Sache natürlich schon wieder anders aus, wenn man da halt dann für seine, Ja, seine geleistete Arbeit oder sein sein sein Routing im Endeffekt dann entlohnt wird in irgendeiner Form.

Ja. Und das ist dann zumindest ja eigentlich schon mal der Physischer Schritt, der jetzt da komplett dann abgebildet ist, dass dann Alice zwölf Gordon an Bob bezahlt. Das sieht man jetzt auf Abbildung acht Punkt fünf. Wir springen jetzt ziemlich schnell, aber Ich glaube, das können wir durchaus bei dem bei dem Punkt jetzt machen. Bob zahlt elf Goldmünzen an an Chan und Chan zahlt die zehn Goldmünzen, die Alice Ursprünglich an Diener zahlen wollte dann an Diener und jeweils Bob und Can behalten eine von den von den Goldmünzen für sich, was dann die Routing Gebühr entspricht, die sie dann behalten können. Dann ist vielleicht noch wichtig der Punkt, den Jan Paul angesprochen hat, dazwischen, der würde mal wieder mit Quittung belegt. Also das ist vielleicht noch 'n wichtiges Wort, was wir dann noch öfter brauchen.

und genau. Und ja, jetzt wird's 'n bisschen moderner als die Goldmünzen, aber Wir Bitkomer wissen natürlich, damit was anzufangen. Sie bildet dann einen Hashtag von diesem Geheimnis, ne. Und das Geheimnis ist halt in der Regel eine ziemlich große Zahl und sie hascht das jetzt einmal mit zum Beispiel zweihundertsechsundfünfzig. Und diesen Hash gibt Dina an Alice.

So, und dann haben wir auf der einen Seite bei Dina ein Geheimnis Und bei Alice ein, der sich auflöst, ne. Also wenn ich das wenn ich das Geheimnis kenne, kann ich ja auch das den, bilden, das ist ein fester Algorithmus, der Schatz war mal sechsundfünfzig. Genau, so. Aber Alice kann jetzt noch nicht aus dem Hash

auf das Auf das Geheimnis schließen, ne. Das ist ja quasi Eigenschaft dieser Einwegfunk Wie heißt die? Ein Nicht nur Ist richtig, ist richtig. Einrichten richtig. Eigentlich, ich denke immer die Einbahnstraßenfunktion. Na ja, Kommt auch kommt wahrscheinlich auf dasselbe raus. Ja, ja. Genau, also sie kann aus dem aus dem Hash kann sie nicht auf das sogenannte pre Image, also auf das Geheimnis von Diener schließen.

Genau. Und wenn das etabliert ist, dann können wir halt versuchen, diesen Nachweis, der ja gefordert war, den zu bringen. Soweit klar?

Zeichenfolge, wie auch immer, Schmeißen die dann halt in der Hasch Funktion. Bei Bitcoin ist es sehr häufig die Chart zweihundertsechsundfünfzig, das heißt, wir bekommen dann zweihundertsechsundfünfzig bit langen Exadezimal String quasi da hinten raus. Also die wir können vorne quasi die komplette Amazon Datenbank reinschmeißen und wenn wir das alles hasschen, kommt trotzdem hinten nur eine zweihundertsechsundfünfzig

Folge hinten raus. Also die die die Inputgröße ist egal, aber hinten kommt halt immer eine gleich 'N Hexadezimalstream raus, der halt immer gleich lang ist. Genau. Und was das das Gute ist, man, es gibt halt, Stand jetzt, keine Möglichkeit von einem, Quasi von dem von dem Hash wieder zurück auf den Ursprung zu schließen, weil darauf basiert im Endeffekt unsere moderne Kryptografie und die Verschlüsselungsmethodik oder beziehungsweise

diese die Verfahren, dass das halt einfach nicht möglich ist. Genau.

ne, aufzeigt Kennt. Und das Ja. Genau, das kennt und das passt natürlich zum zu dem, den den Alice hat, Ne. Ja. Ne, und das ist quasi der Nachweis so und das das funktioniert in der ganzen Kette. Das heißt, dieses Geheimnis, dass Bob jetzt der Alice gezeigt hat, das hat er vorher von Chun bekommen, weil er mit Can den gleichen Vertrag hatte, wenn Du diesen Nachweis lieferst, ne, dann zahle ich dir elf Geldmünzen, so. Und Can wiederum hat das Geheimnis von Dina direkt bekommen, genau, Genau, also weil er, ne, gesagt hat, okay, kannst Du mir das Geheimnis sagen? Er vergleich das. Okay, das passt jetzt mit diesem, den ich habe. Also zahle ich, schon, ne, die zehn Goldmünzen an an Diener.

ist, ihr Geheimnis bildet, daraus diesen Hesh bildet. Und dieser Hash, diese Information geht zuerst an Alice über einen anderen Kanal, also jetzt dann im Zweifelsfall über 'n Browser, über per Mail, per Messenger, wie auch immer. Und mit dadurch, dass sie ja dann den den Hash hat, der des des der der Ziel Hash ist, der im Endeffekt dann diese gesamte Transaktion dann halt durch Durchfließt oder oder verwendet wird, kann sie im im

Zweifelsfall den ersten Vertrag mit Bob aufsetzen, weil sie ja dann festlegen kann, Du musst mir einen musst mir das Geheimnis zu diesem Hash geben. Und mit dieser Information geht Bob dann an zu Chan und Chan hat ja dann auch dann von Alice dann dieses den Hash bekommen Und kann darum wieder den Vertrag auf aufsetzen. Und dann geht der Can

zu Dina selber und sagt, hier, wenn Du mir dein Geheimnis gibst von deinem Hesh, Dann oder von von ja, das Geheimnis zu deinem Hash, dann geht die Zahlung im Endeffekt dann dann ihren Weg, ne. Und wenn diese Runde einmal komplett gemacht ist, Dann kann ja prinzipiell dann das, sind dann die Bedingungen in dem Sinne dann erfüllt, dass dann Dina loslegen kann und ihr Geheimnis veröffentlichen kann.

genau, Bob, Bob und Chan müssen jeweils über diese Höhe dieser dieser also diese mindestens diese zehn Goldmünzen ja oder In dem Fall werden sogar elf und genau elf. Elf. Nee. Nee. Elf und zehn. Elf und zehn verfügen, damit sie überhaupt Teil dieser Route sein kann. Hätten Sie die nämlich nicht, Dann könnten Sie nämlich das dieses Konstrukt gar nicht darstellen, weil

Ja, absolut. Nämlich dann jetzt der nächste wichtige Punkt, der dann bei Abbildung acht Punkt sechs reinkommt. Das ist dann die weitere Ergänzung wieder noch 'n bisschen mehr zu unserer Implementierung im Lightning Netzwerk, dass wir da, dass diese Gelder nämlich bei einem Treuhandder hinterlegt werden müssen. Das heißt, die Gelder In der Zeit, wo diese Transaktion stattfindet, gesperrt, also stehen dann halt nicht für andere Zahlungen zur Verfügung.

Und das dann vielleicht auch noch mal 'n relevanter relevanter Punkt, dass die dann halt da eingelegt werden müssen bei dem Treuhänder. Also dieser Treuhänder ist ja sinnbildlich jetzt erst mal, dann Steht ja für die für die Contracts, die nachher noch kommen. Aber an der Stelle ist es ja jemand, der vertrauenswürdig ist, aber darüber entscheiden kann, ist das, was da passiert ist,

erst mal ausschließt, nur damit man jetzt dieses Beispiel erst mal akzeptieren und verstehen kann. Und dann wird auch schon der Hinweis gegeben, wir kommen gleich da drauf,

Chanel wiederum bekommt nur Zweiundzwanzig Stunden Zeit, das Geheimnis vorzulegen und Dina bekommt zwanzig Stunden Zeit, das Geheimnis vorzulegen. Ja, sehr gut. Genau. Kannst Du erklären, warum? Ja, also ich glaub ein ein wichtiger Punkt ist, wenn es keine Zeitbegrenzung gibt, dann könnte Bob ja hingehen und sagen, So, ja klar, also ne, ich könnte jetzt ne diese Zahlung zwar veranlassen, aber Du hast mir ja nur eine Gebühr von einer Goldmünze gegeben. Ich hätte aber gerne drei Goldmünzen,

ne. Also dass er quasi Dadurch, dass Alice darauf angewiesen ist auf die Kooperation von Bob, ne, dass er ihr nämlich das Geheimnis vorlegt, erst dann kann sie quasi die Zahlung vollziehen. Und so hat halt Bob ein ein Druckmittel gegen gegen Alice. Er kann sich quasi ihrpressen und sagen so, ja, ist mir doch egal. Wir haben vielleicht nur eine Goldmünze vereinbart, aber ich hätte jetzt gerne zwei Goldmünzen.

Und das zu verhindern, glaube ich, ist ein Aspekt, warum man diese zeitliche Begrenzung einbaut, ne. Weil Und der also der Trick dabei ist, wenn diese Zeit abgelaufen ist, dann schlägt die ganze Zahlung ja fehl. Und das ist halt auch noch mal son wichtiger Aspekt Jetzt hier bei der Begutachtung von Zahlungen, ne, es gibt halt nur zwei Zustände.

Entweder die Zahlung findet statt, sie erfolgt oder sie schlägt halt komplett fehl. Das wird halt sichergestellt, ne, dass dadurch, dass wir halt eine zeitliche Begrenzung haben dieser quasi einzelnen Zahlungen zwischen Alice Bob, Chan und Dina.

dann niedriger ist und dann, je weiter wir wieder zu Alice zurückkommen, desto höher wird dieser Wert. Also Alice hat prinzipiell den Den längsten Zeitraum und Bob hat dann halt 'n bisschen Kürzeren und Chant noch 'n bisschen Kürzeren und das war's, ne? Hat Dina? Nee, Dina hat Doch Dina hat auch Ja Dina zahlt ja im Endeffekt an Chan, deswegen Es gibt ja eigentlich nur drei Nee, Dina zahlt an Dina, aber Dina hat Verträge. Nee, Can zahlt an Dina, aber Dina Gibt's also drei Verträge?

Genau. Es gibt, genau, es gibt zwischen Dina und Can, Can und Bob Bob und Alice. Es gibt drei Verträge. Genau. Also da In dem Beispiel ist, glaub ich, ja vierundzwanzig Stunden bei Alice und Bob. Bob zu Chan zweiundzwanzig Stunden und Can zu Dina

Der, der zuerst die Portionen auf die Teller verteilt, das gleich zu verteilen, weil er ja am Ende das nicht kontrollieren kann, was sein Geschwisterkind macht bei Teller Zuordnung und sagt dann okay, dann mach ich lieber in beide Teller gleich viel und es kommt raus, dass beide gleich viel auf dem Teller haben. Danke für die Erinnerung.

Genau und jetzt hier bei dem Thema Routing, so wie ich das jetzt verstehe, bei dem Thema Routing durch Zahlungskanäle geht es darum, haben drei Anforderungen oder drei Eigenschaften, die, ne, dieses Protokoll erfüllen muss und das ist einmal, dass es ein vertrauensvoller Betrieb ist.

Das heißt, ich muss nie irgendwie einer meiner Gegenparteien, also Alice muss nicht Bob vertrauen und Bob muss nicht Chan vertrauen, sondern wir, Es reicht uns, dass wir das Protokoll kennen und somit ein Vertrauen in das Protokoll aufbauen können. Das ist mit vertrauensfreiem Betrieb Gemeint. Dann das Thema, dass die Zahlungen atomar sind. Und atomar heißt halt, ne, sie sind entweder vollständig ausgeführt Oder schlagen halt komplett viel. Und das Dritte war

Multi Hopp. Ach so genau. Das soll halt, ne, die Sicherheit dieses Fairnessprotokoll soll sich von Ende zu Ende, also von Ellis bis zu Dina erstrecken erstrecken. Es soll halt irgendwie an keiner Stelle irgendwo 'n Risiko begeben, ne. Wir wollen halt immer auf der ganzen Route wollen wir sicher sein, dass die Route auch

dann daran drauf angesetzt sind, wie jetzt halt bei 'ner direkten Zahlung zwischen zwei Pears. Mhm. Gut, dann kommen wir zu Nee, kommen wir da schon zu den HTLCs?

weil sie einfach kostengünstiger ist als die Off Chain Transaktion. Das heißt, Also eine Off Chain Transaktion ist zum Beispiel die Zahlung von Bob an Chan ist hier damit gemeint, ne. Das ist eine dieser Off Chain Transaktionen. Es ist nicht die Gesamttransaktion von Alice zu Diener gemeint, sondern Unter anderem, ne, diese Teiltransaktionen

von Bob an Chan in dem Routing von Alice und Dina. Genau, das war mir noch mal wichtig, das aber Ja, macht ja auch Sinn, weil zwischen Alice und Dina keine Kanäle bestehen und dementsprechend haben sie auch keine

Hashtag time lockt Contracts, ne?

Und auf der anderen Seite steht, heutzutage ist dieses Fairnessprotokoll in HTC TLCs implementiert. Mhm. Ja. Also für mich der Treuhand, der prinzipiell sind diese HTLCs, weil da die Skripte drin sind, die im Endeffekt dann diese dieses Fairnessprotokoll Steuer. Der Unterschied ist für mich,

die Münzen an Bob. Und das muss auch so sein in dem Beispiel der Goldmünzen, weil Bob nicht darauf vertrauen kann, Dass Alice ihm tatsächlich die zwölf Goldmünzen gibt. Er kann erst darauf vertrauen, wenn er sagt, ich hab einen Treuhänder, bei dem das hinterlegt ist und dem halt vertraue dem, von dem ich ausgehen kann, dass er mir diese zwölf Goldmünzen dann gibt, die in dem Vertrag vereinbart sind.

Und hier bei den Gibt es keinen Treuhänder, denn die Geldflüsse finden quasi, die finden koordiniert statt nach eben deinem Fairnessprotokoll. Es ist nicht so, dass ich erst Geld, also dass Alice jetzt erst irgendwie Geld irgendwo deponieren muss, bevor

Bob ihr quasi den Nachweis liefert, hey, ich hab die Zahlung geleistet, also kann ich mir jetzt hier das Geld Da holen, wo Du's deponiert hast. Das passiert halt nicht. Das Geld ist immer bei bei Alice, bis halt quasi der der das Der HTLC erfüllt ist.

Also die also das es ist ja definitiv so, dass die SATS während eine Transaktion quasi ausgeführt wird, also diese Normalerweise dauert sone Transaktion ja 'n paar Sekunden, aber es kann nur durchaus sein, dass da zwischendurch dann halt irgendwelche Routing Probleme oder so was gibt. Das sind diese HTLCs definitiv gesperrt. Hab ich bei uns bei der Notsignal lighting Not schon 'n paarmal gesehen, dass dann einfach dieses Satz nicht zur Verfügung stehen.

Ja, ja, absolut, ja. Also genau, der sagt der Spargel. Das als Trauerhändler zu fungieren oder sage, ich hab hier ein Protokoll implementiert, indem ich für eine kurze Zeit auf Also in dem Protokoll quasi die die Satz Locke. Das so ist es ja wahrscheinlich, ne. Die sind Genau. Diese fünfzigtausend Satz, also das ist das Beispiel hier in dem Buch, es werden fünfzigtausend Satz geschickt. Diesen fünfzigtausend Satz kann ich in der Zeit, in dieser, in der dieses Fairnessprotokoll

reingebracht hast. Ich hab mich echt getraut zu fragen. Genau. Ich hab mich echt nicht getraut zu fragen, ehrlich gesagt, weil ich dachte, springen wir dann zu sehr, aber es hat mich echt son bisschen gewurmt, auch als ich dann durchgelesen hatte und hinten weiter war, dass ich nie so richtig gecheckt hab, an welcher Stelle erklärt wurde, Wieso ich auch wieder

gehen kann an jeder Stelle. Aber ich glaub, an dem Punkt hatte ich mir noch mal 'n Fragezeichen gemacht und ich würd die Frage dann stellen, wenn wir da hinkommen. Lass uns gerne da weitermachen zu mit dieser Grafik. Ich wollt dich nicht zu sehr rausbringen, Thorsten. Also acht acht. Alice erhält einen Zahlungshash von Dina. Richtig, genau. Das haben wir ja teilweise ja eben sogar schon 'n bisschen erklärt, ne, dass halt dann dieser

Dass Bob zwölf Goldmünzen bekommt, wenn er Quasi den das Secret zu dem Hash liefern kann, den Alice von Dina bekommen hat, ne. Und das Gleiche macht dann auch Bob mit Chan und Chan mit Dina direkt. Das ist jetzt dann erst mal der Weg und genau. Wir haben jetzt hier dann als als Information haben wir jetzt das Zahlungs preimage. Das ist jetzt in dem Fall Diese Zeichenkette DINer Secret, glaube ich, oder wie das zum Beispiel hier benutzt wird und der hätte Ist einfach eine große Zahl, ne? Genau. In dem haben wir ja jetzt große Zahlen, dann genau. Genau. Beispiel hier ist es

so wie 'n kurzer, wie rum, ne? Also das noch mal vielleicht noch mal das Beispiel noch mal zu verdeutlichen, dieser dieser Zeitpunkt, wenn Dina das Den Hash schickt, ist der Moment, wo die Alice

bei Dina eine Invoice oder eine Lightning Zahlung anfordert. Und In dieser Lightning Zahlung ist dann wahrscheinlich dann auch in irgendeiner Form, das kommt, glaub ich, jetzt auch noch 'n späteren Kathiopital, hatt ich gesehen, ist dann halt verschlüsselt auch dieser Hashtag dann halt drinnen von diesem Secret. Und den der wird dann dafür benutzt, dann diese Zahlung halt aufzubauen und wahrscheinlich auch noch Routinginformationen

sind da vielleicht auch noch irgendwo drin und und solche Sachen dann. Genau. Das ist dann einmal dann der Austausch von dieser Hesh Information.

außerhalb des Bitcoin- und Lightning Protokolles stattfinden kann, ne. Kannst Du dir per E-Mail austauschen, über eine Webseite austauschen. Das hat erst mal mit Lightning gar nix zu tun, ne. Das ist nur also ja, gar nix zu tun, aber ja. Also wie Die beiden da sich untereinander diese Rechnung und den Zahlungshash austauschen, das ist hier nicht Teil der Kommunikation oder des Rootings, so.

da an dieser Art und Weise dann dieses Beispiel nach und nach dann aufzubauen. Das macht, glaub ich, mehr Sinn als jetzt dann, wenn ich da im Detail dann sich diese Ich muss auch sagen, der der Teil danach hat mir mehr geholfen,

Das einmal gesehen zu haben. Ja, okay. Also ich das ist trotzdem wichtig, das mal zu sehen, wie das aussieht. Genau. Das ist im Endeffekt ja Bitcoin Skript dann, wie dann auch Transaktionen im Off-Chain, nee, On-Chain, auch dann implementiert sind und da  dann ja, die Skripte dann dafür sorgen, dass man seine UTXO's ausgeben kann oder nicht und das Gleiche findet dann offensichtlich

Übergangslos, sag ich jetzt mal, zwischen Off-Chain und On-Chain wandern kann, weil die Logik

Also ich glaub ich glaub, es ist besser, wir gehen jetzt noch mal das das Thema noch mal durcheinander, dann wird das, glaube ich, klarer, wenn man dann jetzt noch wirklich mal kennt, wie der Dieser Timelock da dann greift.

durchlaufen offchain? Und ich glaube, es funktioniert genauso wie onchain diese onchain, nee, es funktioniert halt eben über diese Skripte, über diese On Chain Skripte. Und das ist wichtig, in meinen Augen zumindest, dass man sich darüber im Klaren ist, okay, Wenn jetzt, ne, also jetzt in dem Beispiel von diesem Zahlungs pre Image und Hashtag Verifikation, wie läuft das ab? Ja, also ich bekomme, Ne, ich ich lege das Secret auf den Stack, dann kommt ObShart zweihundertsechsundfünfzig,

ne, also damit wird das Secret quasi gehascht und dann hab ich zweimal, nämlich den Hashtag des Secrets und den Hashtag, den ich vorher hatte, liegt aufm Stack und dann kommt Ob Equal. Nämlich der Vergleich, sind die beiden gleich? Und wenn die beiden gleich sind, so, dann ist diese Bedingung erfüllt. Richtig. Und das ist dann Läuft das läuft so im Protokoll läuft das auch so ab, ne?

Bob liefert im Endeffekt das Secret, legt das das Secret auf den auf den Stack, hasht es, Hat den Hasch, den er ja vorher von Alice bekommen hat, den sie ja haben will. Und wenn der halt mit dem übereinstimmt, das was er grade gebildet hat, dann ist alles tutti. Dann kann die Zahlung auch ausgeführt werden. Dann ist die Bedingung erfüllt, dass der HTLC ausgeführt werden kann und Bob auch seine Zahlung bekommen dann von Elles.

konstruiere. Du Ihre. So und der erste Bestandteil ist halt, dass ich den Hashtag bekomme. Ich hab also den Zahnarzt bekommen. So. Und Genau, genau. Alice Sagt jetzt, Bob, pass mal auf, wenn Du mir das Geheimnis lieferst und ne, dass der, also die die Charts mal sechsundfünfzig Funktion das auflöst, also da so, dass Ob Equal einen WA zurückgibt, ne, das ist quasi der der Hash, den ich den Alice an Bob gibt.

Und jetzt kennt Bob ja das Zahlungshas. Das hat er jetzt grade von Alice bekommen. Diesen Zahlungshas kann er nehmen und das Gleiche mit Chan wiederholen Und sagt, wenn Du mir das Secret gibst, das mit ObShart zweihundertsechsundfünfzig diesen Zahlungshash ergibt,

Dann ist es fein, dann hast Du diese Bedingung erfüllt. Darum geht's jetzt erst mal. Wie geht dieser Zahlungshash, den Diener an Alice geschickt hat, wie geht er durchs Netzwerk? Und das wird passiert halt, In den in dem halt dieses Konstrukt, diese, ne, das was hier in genau, was hier unten steht, ne, also Secret, ob Shar zweihundertsechsundfünfzig, hash, ob equal, was da beschrieben ist. Das ist quasi Bestandteil des Bitcoin Skriptes, der mitgenommen wird über die Route.

dann dieser, dann erst von Alice Bob geht und dann von Bob zu Can und dann von Can zu zu Dina wieder. Und alle implementieren im Endeffekt diesen Spezifischen Hecht, den Diener irgendwann mal aus ihrem Secret generiert hat und der ist quasi relevant für diese komplette Also das ist das ist eigentlich der der zentrale Ankerpunkt für alle, ist dieser Hasch. Und den haben ja dann dann dann alle im Zweifelsfall dann dann zur Verfügung.

Und Erst wenn der ja bei Dina angekommen ist wieder, dann weiß Dina, okay, die Route wurde aufgebaut. Es gibt quasi eine Route, die gefunden werde. Also es gibt eine Route von Der Person, der ich die Rechnung geschickt habe, in dem Fall war's Alice und dann kann Dina theoretisch die Route, das Secret veröffentlichen in dem Fall, was sie ja dann gebildet hat Und somit dann auch die Zahlungen dann wieder wieder dann über Can zu Bob zu Alice dann auflösen, da dann halt dann diese Zahlungen dann wieder Ja, im Endeffekt effektiv auszuführen. Ist das klar, Call so? Oder? Welche Stelle, also wirklich im Skript jetzt,

es gibt einen quasi einen zentralen Bestandteil in dieser Bitcoin in dieser In diesen Bitcoin Transaktionen, in diesen Off Chain Transaktionen, die zwischen Alice und Bob, Bob und Chan, Chan und Dina erstellt werden. Und dieses Kernelement ist eben 'n Hash Zu diesem Zahlungshas und der Vergleich. Das ist, mehr ist das nicht, das ist das Kernstück davon. Diese diese quasi drei Informationen, also ein zwei Operatoren und Zahlungheld, das ist das, was durchgegeben wird. Ist das klar?

Ja, das ist klar. Genau. Ach so, vielleicht wird's so klarer. Alice formuliert die Bedingung, wann sie an Bob zahlt und zwar, wenn Bob Dieners Geheimnis Auf

also liefern kann, Ja. Dass sich mit dem Zahlungs, also mit dem Zahlungs, mit dem Zahlungs, gleich ist. Mhm. Also Alice formuliert eine Bedingung an Bob. Ich zahle dich, wenn Du mir das Secret lieferst, das halt auf diesen Zahlungsherr. Das ist ja genau das, was wir eben in dem in dem einfachen Beispiel hatten, das ist diese Quittung. Wenn Bob die Quittung liefern kann, die im Endeffekt dann jetzt in der Form von diesem

SATs, glaub ich, die Ja, hundert SATs pro Person. Von Edistan. Mhm. Vielleicht hier auch noch mal das Beispiel in dem Beispiel, jetzt wird Edles fünfzigtausend SATs schicken Und jeweils hundert SATs sind Route, die Transaktions- oder Routinggebühren, die Bob beziehungsweise Can dann jeweils bekommen. Genau. Und dann wären wir eigentlich an der Stelle, dass Diener dann ihr Secret veröffentlicht und dann Richtung Can propagiert oder ihm die Information weitergibt. Hier, das ist mein Secret.

Auf der Basis kannst Du jetzt dein deine Zahlung, weil Can hat ja mit Dina einen Vertrag, wo drinsteht, Dina liefert mir zu dem diesem Hash das Secret. Dadurch, dass Dina das Secret ja gebildet hat, kann sie das natürlich auch sehr, sehr einfach liefern und Dina hat natürlich auch ein Interesse daran, das Secret liefern, weil sie will die fünfzigtausend SATs haben, die sie die

Chan Diener in ihrem Vertrag versprochen hat. Deswegen hat sie 'n Interesse daran, das freizugeben? Also macht sie das? Und wenn sie das macht, wird die Zahlung zwischen Can und Dina theoretisch freigegeben oder wird dann wird dann freigegeben. Dann geht's ja weiter. Dann hat Can das Secret und kann wiederum sich die fünfzigtausend Einhundert Satz von Bob holen, weil er jetzt ja dann auch Bob Bob gegenüber beweisen kann. Hallo hier, ich hab jetzt das Secret von Dina bekommen.

Bitte gib die fünfzigtausendeinhundert Satz frei. Und dann nach Bob, genau das Gleiche, weil er ja auch wieder das Secret bekommen hat von Can. Zu Alice, bitte gib mir die fünfzigtausendzweihundert Satz frei, die Du mir versprochen hast, wenn ich dieses Secret liefer und Voilà. Wenn alle das liefern können, dann ist im Idealzustand die Zahlung erfolgreich, weil alle zu jedem Zeitpunkt dann die Das Secret da liefern können und dann ist die Kette eigentlich komplett.

Dann hat in dem Sinne dann auch dann die Diener ihre fünfzigtausend SATs von Alice bekommen Und Alice hat effektiv fünfzigtausendzweihundert SATZ bezahlt, wo dann halt diese zweihundert Satoshi Ruding Gebühren mit drin waren. Ich glaub, hier ist nur wichtig zu verstehen, dass

Plus die Richtig, genau. Gebühren, die auf die sie sich geeinigt haben. Aber das ist, also die die die Bereitschaft von Chan Er wächst dadurch, dass er weiß, dass er von Bob quasi denselben Vertrag plus x plus ein kleines 'n kleinen Obolus von Bob bekommt. Das ist hier, glaub ich, noch mal wichtig zu sagen, weil er darauf vertrauen kann, dass das Fairnessprotokoll

auch noch find ich wichtig, was hier dann als Also ich würd jetzt zu den zu der Signaturbindung gehen, wenn das für euch okay ist. Ja. Okay, perfekt. Ja, genau. Das Problem ist jetzt in der jetzigen Situation, die wir jetzt vorher hatten, war, dass wenn Chan ja theoretisch den Das Secret von Dina bekommt, könnt ihr theoretisch auch den HTLC von Bob

und von Alice einlösen oder beziehungsweise oder Dina könnte theoretisch den Den die HTLCs von allen dreien einlösen dann, ne, und müsste das gar nicht veröffentlichen, ne. Also es ist jeder, weil Dina ja prinzipiell die Person ist, die diesen Diese Information halt immer hat und die anderen haben sie halt noch nicht. Aber sie könnte theoretisch, wenn es keine Signaturbindung geben würde, alle drei HTLCs für sich claimen. Ob das jetzt Sinn macht, sei jetzt mal dahingestellt, aber Oh.

dann funktionieren könnte. Offchain landen die Transaktionen ja dann trotzdem bei den

verändern. Aber onchain könnt ich mir vorstellen, dass Diener dann alle drei HTLCs off onchain zetteln könnte und prinzipiell dadurch dann für die anderen Teilnehmer Transaktionsgebühren auslösen könnte. Also die würden trotzdem auf Adressen von den jeweiligen Leuten landen, aber Ach so, das ist das Aber sie könnte trotzdem dadurch in Anführungszeichen Force

Quasi sinngemäß sind es ja dann Force Closse, weil die Kanäle dann geschlossen werden, weil wir ja onshaper setteln. Würden wir da, könnte sie da durch Force Closse Auslösen. Das wäre mal die, so könnte das, was ich mir vorstellen könnte, was dann passiert. Ah, okay, ja.

haben, aber wenn es nicht so wäre, dann, Das ist die Frage, die Jan Paul sich gestellt hat. Ach so, weil das nicht Ich verstehe, weil weil diese Information,

angeboten. Wir wissen nicht, ob's richtig ist, dass dann halt damit quasi sie So Forst Closes erzwingen könnte, ne, weil sie halt dann drei On Chain Transaktionen veröffentlichen könnte. Mhm. Vielleicht ist das so, aber das unter Vorbehalt, also. Lass uns doch vielleicht jetzt an dieser Stelle doch mal schauen, okay, wie stellen wir denn sicher, dass so was nicht passieren kann? Und da kommt jetzt das Thema Signaturbehinderung.

Genau. Also ich fand's nicht so kompliziert. Also Bob muss jetzt nicht nur das Geheimnis vorlegen, sondern auch eine Signatur zu seinem öffentlichen Schlüssel. Das kann er ja machen. Also er kann ja eine eine gültige Signatur liefern und die kann ich ja anhand des öffentlichen Schlüssels, den Bob aus seinem Private Key Erstellt hat, dann auch überprüfen.

liefern und damit dann abgeglichen werden kann, dass derjenige, der diesen HTLC in dem Fall von Ellis dann claimed auch wirklich auch Bob ist. Na, also das packt dann Alice dann mit mit dann in den in den Vertrag mit rein, also mit in den HTLC und dann kann Bob dann in Kombination mit dem Secret, der er von Dina bekommen hat, Plus seinem aus seinem privaten Schlüssel gebildeten öffentlichen Schlüssel, dann den

hat er jetzt je Claim. In dem Sinne dann sich die fünftausendzweihundert Satz auszahlen lassen.

den Hash herum gebaut wird, ne. Also Seht ihr das? In der Mitte ist ja dieses ObShard zweihundertsechsundfünfzig und dann ob Equal und das ist jetzt nicht nur ob Equal, sondern ob Equal verify. Und drumherum findest Du noch Bob Signatur, Bobs öffentlichen Schlüssel und Ob Jaxick.

Also ne, diese Bedingung, das ist das Einzige, worauf ich hinauswill, diese Bedingung wird quasi In diesen, den wir vorher durchs Netzwerk propagiert haben, noch mit, also nicht vorher, sondern zu dem, den wir durchs Netzwerk propagieren,

Da bauen wir drum herum noch diesen die Signaturbindung, wie das hier heißt. Also ne, die Forderung, dass eine gültige Signatur Passend zu Bobs öffentlichem Schlüssel mit eingebaut werden muss als Bedingung. Ja. Find ich gut. Was ich noch wichtig fand, jetzt seh ich's grade, an welcher Stelle das war Dem Frettchen hier in der Mitte,

geändert wurde und dass damit dieser Stack nicht Tour oder false zurückgibt am Ende, sondern die gesamte das gesamte Skript schlägt fehl, wenn eine Bedingung nicht erfüllt ist an dieser Stelle. Das glaube ich noch mal 'n ganz wichtiger Punkt, also ob man das jetzt durchgeht oder nicht, aber ich hatte mich immer gewundert, warum das wichtig ist, aber das ist ja diese atomare Sinn, dass dass diese gesamte Transaktion, alles, dieses gesamte Skript dann abgebrochen wird für alle. Also das

Alles dieses gesamte Skript

Wenn's Falsch ergibt, also wenn der Hash des vermeintlichen Secrets und der Zahlungshash nicht übereinstimmt, dann wird er an der Stelle einfach abgebrochen. In dem Fall, dass halt Der Hasch Vergleich positiv ausgeht, also wahr ergibt, ne. Diese beiden Hasches sind gleich. Dann sind halt auf dem Stack noch zwei Dinge übrig, nämlich einmal Bob Signatur und Ob's öffentlicher Schlüssel und dann kommt noch der Operator Operator Ob Checksick

und der prüft halt nur, also der prüft halt, ob die Signatur zum öffentlichen Schlüssel passt Und gibt dann halt wahr oder falsch zurück. Ja, und dann kann Bob das claimen. Genau. Und das ist funktioniert, ne. Also das ist jetzt die Vertragskonstruktion zwischen Alice und Bob. Und natürlich gibt's Das das Äquivalent dazu zwischen Bob und Chan und Chan und Dina. So konstruieren wir das halt. Yes. Und

Ja, genau. Dann kam eine ein ein Abschnitt, der mich etwas überrascht hat an dieser Stelle. Den hätte ich später erwartet, aber Es geht das Thema Hashtag Optimierung.

Ja,

Genau. Schonenden Arbeitens, ne. Weil wir haben ja einen kürzeren, also weniger bite, die dann der herrscht darstellen kann, Ist prinzipiell ja dann auch dann die Möglichkeit, diesen Hashtag zu finden, also das Preimage zu dem Hashtag zu finden, wahrscheinlicher als bei einem längeren Hashtag, ne, weil wir prinzipiell

Genau, aber durch die Sendung. Durch das Doppelte, ne, erst Staats neunzehnhundertsechsundfünfzig und dann noch herrschen neunzehnhundertsechzig haben wir halt, also sind wir relativ sicher, dass das Pre Image Nicht gefunden werden kann und das Ergebnis ist, dass es halt optimiert ist, weil halt der Hasch nur zwanzig Byte lang ist und damit quasi kostensparender ist in einer

so klein wie möglich zu halten, dass einfach mehr Transaktionen oder mehr Speicher dann in einem Block dann aufgenommen werden können oder mehr mehr Transaktionen besser gesagt, die kleine einfach sind. Genau. Und noch 'n zweiter Punkt ist hier unter Hash Optimierung drin. Und das hatten wir auch in dem in der Folge mit Merge einmal ganz kurz

wo die ob Codes gematcht sind, ne. Das heißt also, Zum Beispiel hat der Ob Code ob Equal verify hat, ne, hat den Wert achtundachtzig, sodass Du halt in der Transaktion Dann sehen kannst, wenn da achtundachtzig steht, dann ist das, dann übersetzt sich das in ob Equal verify. Und das Bitcoin Skript weiß halt, okay, ich muss also an dieser Stelle den Operator Equal Verify ausführen und macht dann halt die vorgesehene

Operation. Genau und dadurch, dass es halt, ne, diese Obcodes sind halt immer nur ein Byte, Ne, zum Beispiel achtundachtzig und sind deswegen relativ, also nicht relativ, sondern sind halt sehr platzsparend. So, und dann hast Du halt, Ja, hast Du dir halt, weiß nicht, ob Du sie jetzt unter Optimierung warst, aber da wird einfach dargestellt, okay, das ist halt recht kurz diese Operatoren, die Obcodes

Timelogs. Das ist dann auch das Letzte, was dann noch in den HTLCs noch fehlt. Das hatten wir eigentlich eben schon größtenteils besprochen. Auch in dem Anfangsbeispiel war es ja durchaus auch so, dass Diese HTLCs so aufgebaut werden oder diese Timelogs so aufgebaut werden, dass je näher wir zum Empfänger kommen, sind die Timelogs, Die im Fall von, wenn irgend eine Not, da wenn irgend 'n Zahlungsteilnehmer irgendwie ausscheiden sollte, offline gehen sollte, dass dann diese HTLCs

wieder geunlockt werden Und der ursprüngliche Zustand vor der Transaktion, prinzipiell im Zahlungskanal, aber auch dann die On Chain Transaktionen, die dann gebildet werden, wieder so auf den Ursprungszustand

oder wiederhergestellt werden, wie's halt vorher war. Und dafür sorgt dann dieser Time Contract. Wenn halt eine bestimmte Blockhöhe erreicht worden ist, dann kann diese HTLCs Bis wieder aufgelöst werden und dann ja, ist der HTLC prinzipiell auch wieder entsperrt und kann dann von Bob oder von den jeweiligen Teilnehmer dann wieder im Fall der Fälle, wenn der Kanal dann ja nicht mehr weiter betrieben werden sollte, dann halt online gebracht werden und dann Die Funds oder die Einlagen von den

noch nicht erreicht ist. Also die quasi die Die Blockhöhe in dem HTLC muss kleiner sein als die aktuelle als die aktuelle Blockhöhe. Und damit ist ja dieser Timelock geschaltet, ne? Also und sobald die Blockhöhe größer ist, Dieses HTLC bricht dann halt einfach ab und dann passiert nichts. Richtig. So, das ist der eine Teil. Was mir noch nicht ganz klar ist, ich glaub, da kommen wir auch später, kommt noch 'n späteren Kapitel, dass, also dann werden diese HTLCs,

die werden irgendwie aufgelöst, oder? Die müssen ja irgendwie, Die bleiben ja nicht bestehen. Also ich behalte ja nicht irgendwie 'n HTLC, der abgelaufen ist, behalte ich ja nicht auf meiner Lightning Node. Genau, der wird ja dann dadurch, wenn ja dann Timelock dann abgelaufen ist, das ist im Endeffekt ja dann der die die Information für den HTLC. Okay, die es ist quasi nichts passiert.

Sich wieder in den Zustand zurückbewegt oder beziehungsweise in dem Kanalzustand bleibt, wie er vor dem HTLC war, ne. Und das andere ist dann entsprechend natürlich dann auch, wir haben ja gesagt, Wir lösen von Dina Richtung Alice auf, aber wenn zwischen Bob und Chan zum Beispiel 'n Problem entsteht und Bob nicht in der Lage ist, das zu claimen,

Dann wird im Endeffekt von da aus ja dann der läuft der läuft ja dann irgendwann dann in den Timelock rein und dann Wird die Transaktion ja wieder zurück abgewickelt, weil Bob ja dann niemals das Image von oder das Preimage für Ellis liefern kann, damit er an seine fünfzigtausendzweihundert

SATZ kommen kann. Und wenn das halt der Fall ist, weil er ja dann den Timelock reinläuft und den nicht liefern kann, Dann sind wahrscheinlich ja auch noch die anderen Timelogs entsprechend dann, dass sie beziehungsweise die anderen HTLCs werden dann halt auch rückabgewickelt. Ich struggle grad son bisschen. Ich ich ich ich ich tu mich auch schwer, das jetzt nachzuvollziehen.

Warum, dass wenn wenn wir son Break in der Mitte haben, warum dann halt die Die quasi die Parteien, die näher am Empfänger sind, in dem Fall Shann und Dina, warum die dann ihre HTC jetzt auch wieder rückabwickeln müssten. Also das verstehe ich auch nicht so richtig. Weißt Du, was ich meine? Ja, ja, genau. Also quasi es hat es hat eine Zahlung von Canandina

Genau. Weil weil ja die Zahlung nicht stattgefunden hat. Vielleicht das noch in 'nem späteren Kapitel. Ist eine gute Frage, denk ich. Ist hier nicht richtig beschrieben, glaub ich. Oder also vielleicht hab ich's auch übersehen, aber ich hab's nicht Nicht rausgelesen.

Und da kommt eben dieser Timelock, ob drop und so weiter. Worauf ich eigentlich nur hinauswill, ist, dass Zwischen diesen beiden Zeilen, die wir hier jetzt in diesem Kapitel besprochen haben, ja noch 'n paar mehr Informationen stehen. Und vielleicht ist darin auch noch mal eine Lösung implementiert, halt dieses Problem, das Du grade aufgemacht hast, das abzufangen.

wieder in den ursprünglichen Zustand Also schieb's wieder an die an die Note zurück, da wo's halt herkommt oder so. Ne, also das ist jetzt in dem Fall dann die, wobei, warte mal, Andy remote Node. Ja, bei remote Node heißt's ja, also Bob an Alice oder nicht? Bob an Alice ist self und Alice ist remote. Genau, dass Alice dann Ihre Zahlung wiederbekommt, was ja durchaus sinnvoll ist dann in dem Fall der Konstrukt, ne. Dass Alice bekommt Ihre Zahlung wieder. Aber das erklärt immer noch nicht genau, Weil wir ja dann in den anderen HTLCs ja theoretisch in den Success reingefallen sind. Genau, also da müsste quasi die Aktualisierung des Kanalzustandes müsste rückabgewickelt werden. Genau. Das ist noch eine offene Frage. Vielleicht

Zwei ein oder zwei HTLCs erfolgreich waren und der andere dann halt auf irgendwelchen Gründen offline geht und in den Timelog live, wie werden die quasi zuvor erfolgreichen HTLCs da trotzdem wieder rückabgewickelt, Damit diese Zahlung niemals stattgefunden hat. Wenn ihr uns das erklären könnt,

qualifiziert ihr euch auch wieder für die Teilnahme bei einem nächsten Buchklub, Wenn ihr dann weißt, dann Ich seh schon eine Runde im nächsten Buchclub. Wie bitte? Ich seh schon eine Runde, der hört sich das hoffentlich an und dann sagt er, jetzt ich mal hin. Ihr Bisher hat er sich noch nicht gemeldet. Wir haben hier schon so häufig nach Hilfe gerufen.

Genau. Aber ansonsten glaub ich, sind wir dann sogar durch mit dem Kapitel. Dann ist es jetzt auch wieder länger geworden als gedacht.