Nodesignal-Buchclub - E183 - Mastering Lightning, Kap. 10: Onion-Routing

Und wir haben einen Kanal zu Jan-Paul aufgemacht. Hallo. Hallo, grüße euch beide. Der Jan-Paul hat heute die ehrenwerte Aufgabe, uns die Block-Zeit zu nennen. Ja, das ist die 843463 laut meiner Node. Passt soweit? Perfekt. Hab ich auch. Passt. Copy-pasted ins Dokument. Sehr schön. Bevor wir starten, kurzer Werbeblocker, dass wir keine Werbung machen. Also, wir sind ein Value for Value Podcast und das bedeutet so viel wie, wir machen das hier in unserer Freizeit.

Wir machen das, um euch zu unterhalten, aber auch uns gemeinsam zu bilden. Und ja, wenn ihr uns unterstützen wollt, das hier weiter so fortzuführen, dann überlegt doch mal, ob ihr uns nicht mal ein Bier ausgebt oder eine Currywurst kauft, indem ihr uns ein paar Satz drüber beamt. Das könnt ihr mit diversen Value for Value Playern ziemlich elegant machen, indem ihr es einfach streamt beim Zuhören. Fountain wäre da vielleicht ein ganz guter Start.

Oder einfach mal auf unserer Website schauen, nach den diversen Möglichkeiten, uns irgendwie Satz zukommen zu lassen. Ja, und das soll es auch erst mal schon sein. Vielleicht am Ende noch mal eine kleine Erinnerung dazu. Und dann können wir ins Thema starten. Ich habe es schon gerade angeteasert. Wir wollen mit dem Kapitel 10 weitermachen. Aber bevor wir das tun, wollen wir noch mal ganz kurz versuchen, zusammenzufassen, was wir im letzten Kapitel gelernt haben. Thorsten, hast du eine Idee?

Ja, ich versuche das Ganze mal. Also das letzte Kapitel 9 ging um Zahlungsweiterleitung und Kanalbetrieb primär. Das war nicht so ein langes Kapitel, aber es hatte einige coole Sachen aus meiner Perspektive in sich, die dann auch die Kapitel davor noch mal besser zusammen oder zusammengebracht haben. Einige Sachen, die vorher noch so ein bisschen unklar waren, die danach aber besser geworden sind.

Also primär ging es im Endeffekt dazu, dass wir mit HTLCs, also mit Hashtag Log Contracts, glaube ich, Paul nickt, genau, was war das, die Abkürzung, jetzt in der Lage sind, diese zwischen Kanalpartnern eine Strecke aufzubauen.

Das heißt, wenn Alice zum Beispiel eine Transaktion zu Diana machen will oder Dina, hieß sie in unserem Beispiel, dann müssen wir, bevor die eigentliche Zahlung stattfindet, erstmal eine komplette Kette an HTLCs zwischen Alice zu Bob, Bob zu Can und Can zu Dina erstellt werden, bevor die eigentliche Zahlung dann erst durchgeführt werden kann.

Und mithilfe dieser HTLCs, was im Endeffekt eigentlich Bitcoin-Skripte sind, die wir auch die Wharf-Chain halten, sind wir so in der Lage, unsere Verträge oder die Verträge zwischen den Routing-Partnern, also es ging explizit in dem Kapitel auch um das Routing und nicht über die Wegfindung, weil Routing an sich ist die Zahlungsweiterleitung und Pathfinding, also die Wegfindung ist explizit, okay, wir schauen, geht da jetzt ein Weg lang oder da.

Und also das eine ist wirklich darum, dass es wirklich um die Weiterleitung der Zahlung geht, das andere ist dann eigentlich, okay, es kann viele Wege geben, aber bei der Zahlungsweiterleitung geht es explizit darum, dass die Zahlung halt durchgeführt wird und weniger darum, welche Möglichkeiten gibt es noch. Also wir bauen keine Topologie vom Lightning-Netzwerk auf, um zu schauen, welche Pfade sind effektiv verfügbar und solche Sachen.

Und da haben wir gelernt, wie wichtig es effektiv ist, bevor wir wirklich eine Zahlung durchführen können, dass diese Commitment-Transaktionen, von denen wir auch in den vorigen Kapiteln schon ein paar Mal gesprochen haben, dass die signifikant sind, dass wir die immer erst zuerst erstellen zwischen unseren Routing-Partnern und erst wenn diese Commitment-Transaktionen aufgebaut sind, dann können wir wirklich erst diese HTLCs aktivieren, weil diese Commitment-Transaktionen

ist immer unsere Fallback, unsere Sicherungsleine, damit wir immer zu jeder Zeit den Kanalzustand auch wieder on-chain bringen zu können. Ich hatte es gerade eben schon mal gesagt, HTLCs sind Bitcoin-Skripte, die zwar oft chainen im Lightning-Netzwerk funktionieren, aber gleichzeitig so gehandhabt werden können, dass wir diese HTLCs auch als on-chain-Transaktionen veröffentlichen können und so dann auch im Hauptnetzwerk funktional bleiben.

Also dass wir da halt nicht in die Situation kommen, dass irgendein Kanalpartner so einen temporären Zustand halt haben kann, wo er seine Funds in Gefahr bringt.

Und das ist im Endeffekt ja dann auch immer beim Lightning-Netzwerk der Anreiz, dass wir jederzeit on-chain gehen können, aber aufgrund von Block-Zeiten und auch von eventuell von niedrigen Gebühren haben wir im System, im Lightning-System einen Anreiz, nicht on-chain zu gehen, sondern das Ganze oft chain abzuhandeln und so effektive auch schneller Zahlungen dann leisten zu können, weil wir halt auf die Block-Zeit nicht warten müssen.

Und darum ging es primär, dass wir da einmal so eine Zahlung durchgeroutet haben, wie das sich dann aufbaut und wie dann sich dieser HTLC dann auch bis zu DIN-e erschreckt und dann auch wieder zurück abgewickelt wird, also dass die Information effektiv dann auch ankommt, okay, die Zahlung ist durchgeroutet. Aber ich habe jetzt schon ziemlich lange gesprochen.

Ich glaube, wer da mehr drüber hören will, der sollte in das vorige Kapitel noch mal reinhören, weil da haben wir es dann versucht, im Detail noch mal durchzugehen. Aber soviel zum Kapitel 9 dann. Sehr gut. Dankeschön. Beeindruckend. Ja, ich bin auch erstaunt, wie viel da noch da ist bei dir. Genau. Und du hattest schon einen Punkt erwähnt, und zwar, dass wir uns nicht diese Wegfindung angucken.

Und so, wie ich das jetzt gesehen habe, ist im nächsten Kapitel auch immer noch die Annahme, dass der Weg bekannt ist, weil wir gehen da später im Buch noch darauf ein, wie die Wegfindung stattfindet. Das heißt, auch im Kapitel 10, das Onion Routing, wird angenommen, dass wir den Weg kennen, beziehungsweise es wird einfach der bestehende Weg, den wir in den letzten Kapiteln besprochen hatten, weiterverwendet. Und ja, Onion Routing, was ist denn das?

Was ist denn, Onion steht für Zwiebel, das weiß ich schon. Jan-Paul, hast du eine Anmerkung, wieso Zwiebel und was es damit auf sich hat? Also ich muss gestehen, dass mir bis heute irgendwie diese Zwiebel-Metapher nicht so ganz einleuchtet, aber so sei es nun mal. Die Idee ist, glaube ich, dass du quasi im Kern, also du willst eine Nachricht verschicken, so rum. Und diese Nachricht ist der sogenannte Onion, die Zwiebel.

Und drumherum haben wir halt Schichten, die eben diese Nachricht, die wir verschicken wollen, verpackt. Und zwar, um sie auf dem Weg zum Empfänger dieser Onion oder der Nachricht, die ich verschicken möchte, also die Nachricht selber nicht preiszugeben, aber dennoch Informationen darüber mitzugeben an die Knoten auf dem Weg dieser Nachricht, wohin sie denn diese Nachricht schicken sollen.

Genau, und das steht quasi in den Schalen, in den Schichten um diese Zwiebel-Nachricht drumherum, also um die Kern-Nachricht drumherum steckt das drin. Oder steht das drauf. Vielleicht als Ergänzung ist es das so, dass jede Schale im Endeffekt die Informationen für den Step in der Routing-Reihenfolge, also gehen wir mal wieder von dem Beispiel aus, wir haben vier involvierte Parteien, es gibt Alice und es gibt Dina und dazwischen gibt es noch Bob und Chan.

Und um bei dem Beispiel zu bleiben, für Dina ist der Kern der Zwiebel bestimmt, weil da wirklich die geheime Nachricht, die halt auch nur Dina lesen soll und die anderen beiden, die dazwischen sind, also Bob und Chan, sind aber insofern relevant, weil sie dazu da genutzt werden, um die Nachricht weiterzuleiten.

Und in dem Schalenteil, der dann bei Bob und Chan jeweils ankommt, stehen aber die Informationen drin, die sie wiederum brauchen, um zu wissen, okay, ich habe die Information von meinem Vorgänger bekommen, ich habe die Vorgängerinformation, weil ich ja weiß, wer mein Vorgänger war, aber gleichzeitig steht dann in meinem Schalenteil, der für mich bestimmt ist, auch drin, wo ich es auch weiterhin weiterleiten soll.

Und bei Chan auf der Seite ist das halt entsprechend dann genau das Gleiche, dass er halt die Information von Bob bekommt und in seinem Teil steht halt drin, okay, ich muss es an Dina weiterleiten. Aber selbst Chan weiß halt nicht, dass Dina die letzte Empfängerin ist, also dass Dina die wahre Empfängerin für ihn ist, gibt es halt immer nur einen Hop nach ihm. Aber ob das der letzte Hop ist, ist ihm halt nicht bekannt.

Also diese Information ist quasi so weit isoliert, dass immer nur die relevanten Informationen in diesen Schalen enthalten sind und mehr dann halt nicht. Das vielleicht noch als Ergänzung. Also genau, das wäre jetzt nochmal eine Frage. Also ich meine, wir wissen ja auf dem Weg, welche Beträge gesendet werden. Das lässt sich ja nicht verschleiern. Aber für die Knoten auf dem Weg zwischen den, also wir bleiben bei dem Beispiel einfach.

Wollen wir jetzt schon die Beträge einführen, weil grundsätzlich gerade ging es jetzt ja erst mal um die Nachricht an sich. Mir ging es nur um folgendes, also warum verwenden wir das Onion Routing? Also die Beträge, die sind ja klar, oder es ist relativ klar, welcher Betrag versendet wird, zumindest ungefähr, oder?

Aber es ist nicht klar, wer der finale Empfänger ist und es ist nicht klar, wie viele Hops der Empfänger noch entfernt ist, beziehungsweise vor wie vielen Hops diese Nachricht abgesendet wurde. Das ist das, was wir mit dem Onion Routing verschleiern können, oder? Ja, schon.

Aber ich glaube, der finale Betrag kann nur quasi gemutmaßt werden, weil wenn ich so ein Mittel, weil wenn ich halt irgendeiner von denen bin, die halt inmitten der Kette halt irgendwo bin, also ich habe nur einige vor mir und einige nach mir, kann ich ja nur so grob abschätzen, was vielleicht so die Gebühren im Netzwerk sind, was vielleicht die Weiterleitungsgebühr sein könnte.

Oder ich könnte halt ja mutmaßen, okay, das ist vielleicht dann in Summe ein glatter Betrag plus halt einen relativ kleinen Betrag. In unserem Beispiel gehen wir immer von 50.000 Satoshi aus und plus dann irgendwie 100 Satoshi Routinggebühren, die dann oder 200 Satoshi für jetzt zwei Steps jeweils. Und vielleicht ist es im Endeffekt dann das. Aber ich glaube, die Information an sich, was jetzt wirklich der Zahlungs… Wobei, okay, vergiss, was ich gesagt habe. Ich korrigiere.

Ich glaube, der Gesamtbetrag steht nämlich sogar wirklich in der Nachricht drin. Also da ist glaube ich, total Sats steht da glaube ich sogar wirklich dann an der Stelle dann drin. Also es passt. Naja, total Sats. Wir sind schon ganz schön weit hinten in dem Kapitel. Ich dachte eigentlich… Wir sind nur vier Seiten weiter. Okay, ich dachte hier, ich bin so ein bisschen in dem Dokument von dir und ich dachte, okay, Onion Routing, was ist denn das?

Schälen einer Zwiebel und wir gucken mal kurz, was dieses Briefmodell angeht. Ja, auf jeden Fall macht Sinn. Sorry. Also so rum. Wir verwenden Onion Routing. Das tun wir, um etwas irgendwie geheim zu halten. Die Frage für mich war, was genau können wir geheim halten? Und ich glaube, wir können geheim halten, wer der finale Empfänger der Nachricht ist.

Wer der Versender der Nachricht ist und wie viele Hops irgendwie noch vor dem Hop jetzt, vor dem Vermittler der Nachricht liegen und wie viele danach. Das alles ist quasi durch das Onion Routing, also wird verborgen. Meine These dann, wenn du das jetzt gerade so aufführst, wird es mir klarer, dann ist es eigentlich auch egal, ob ich weiß, wie viel Geld gerade, also ich weiß natürlich, wie viel Gesamtsumme gerade noch bewegt wird.

Und wenn ich eh nicht weiß, wer der Empfänger ist und wer der Sender ist, dann kann ich auch mit der Information nicht viel anfangen, ob ich jetzt einen Bitcoin dadurch bewege oder ob ich jetzt 50.000 Satoshi dadurch bewege. Es kann mich neugieriger machen, aber im Endeffekt, wenn es wasserdicht ist, dann kann ich mit der Information nicht viel mehr anfangen, außer dass ich weiß, okay, ich muss jetzt so viel Liquidität haben. Ich kriege meinen Anteil an Fees.

Aber wie gesagt, ich hoffe, das kommt in dem Kapitel ein bisschen später mit ein bisschen Details, dass wir da reingehen können. Das wäre so eine Sache, wo wir vielleicht wirklich mal gucken, ob wir das ergründen können. Was genau sieht man wann? Aber ich weiß nicht, sollen wir dieses Briefumschlag Beispiel versuchen mal nochmal wiederzugeben? Kann es jemand gut wiedergeben? Weil ich habe, glaube ich, ich habe schon irgendwie da auch schon meine erste Karriere im Kopf gehabt.

Dann mache ich mal einen ersten Aufschlag. Also wir haben das Beispiel, das wir auch schon in den vorherigen Kapiteln haben. Alice möchte einen Betrag an Dina schicken und das macht sie über Bob und Chan. Das heißt also Alice schickt über Bob und Chan die Nachricht an Dina. So und jetzt gibt es hier ein anschauliches Beispiel dieses Online Routings, nämlich anhand von ineinander verschachtelten Briefen.

So das heißt, das fängt damit an, dass wir einen ersten geheimen Brief haben, also die geheime Nachricht an Dina und der steckt in einem Briefumschlag. Da steht dann auch drauf, das ist für Dina. So und diese geheime Nachricht, die in dem Briefumschlag mit der Bezeichnung für Dina steckt, die stecken wir wiederum in einen Briefumschlag, auf dem nur draufsteht "für Chan".

So da haben wir halt quasi im Kern die Nachricht, dann den Briefumschlag, wo drauf steht "für Dina", dann den Briefumschlag, wo drauf steht "für Chan". Und dieses verschachtelte Geheimnis wird nun in einen weiteren Briefumschlag gesteckt, in einem Briefumschlag, in dem drin steht "für Bob". So dass wir halt drei Briefe ineinander gesteckt haben mit einer geheimen Nachricht in dem letzten Brief. So das ist quasi das, was wir konstruieren.

Und das wird dann so aufgelöst, dass wenn Alice die Nachricht an Bob schickt, dann steht da oben drauf "Hey hier Bob, hier ist eine Nachricht für dich", da steht nämlich drauf "für Bob". Und dann kann Bob das auspacken, sieht "ach guck mal, da ist eine Nachricht für Chan drin", die gibt er an Chan weiter und Chan macht den Brief auf und sieht "ach da ist eine Nachricht für Dina drin" und dann gibt er halt diese Nachricht an Dina weiter. Und Dina als Empfängerin kann dann den Brief final öffnen.

Die Visualisierung davon und wie du es gerade erklärst, macht mir nochmal eine Sache klar, die dann auch später nochmal deutlich angesprochen wird. Und zwar, dass Alice als Erste, die ja weiß, an wen es geht und weiß, an wen sie es schon mal weitergibt, dass sie das ja eigentlich gar nicht, jetzt mal um bei dem Bildlichen zu bleiben, sie müsste es gar nicht in den Briefumschlag packen, sie könnte es einfach Bob geben und sagen "hier, mach mal weiter".

Also sie könnte sich diesen ersten Brief, also den äußersten Briefumschlag für Bob sparen, aber ganz praktisch, dass das jetzt hier eben mit drin ist, weil ja später auch nochmal deutlich gemacht wird, dass sonst Bob auch wüsste, dass es von Alice kommt, also dass sie die Erste ist, die das alles verpackt hat.

Das heißt, sie muss es genauso verpacken wie alle anderen Briefe, weil sonst fällt ja Bob schon auf "ja, hier war ja gar nicht, woher wusstest du, dass ich das jetzt kriege", so nach dem Motto. Das wird nochmal relevant, ich hoffe, ich verwirre jetzt nicht noch mehr mit dieser, mit meiner Erkenntnis oder dem Versuch, das über Bord zu fassen. Nee, war super, das fand ich cool, also das würde ich ganz gerne nochmal für mich wiederholen, damit auch ich das doch gelernt habe.

Du sagst, dass der erste Briefumschlag, wo oben drauf "für Bob" steht, das macht Alice so, damit Bob nicht irgendwie daraus schließen kann, dass er der erste Empfänger dieser Nachricht ist, sondern so sieht es halt für ihn, sehen alle diese on-end gerouteten Nachrichten für ihn alle gleich aus. Da steht halt ein Sender drauf, nee, weiß nicht, ob es ein Sender drauf steht, aber er weiß ja, von welchem Sender er das bekommt und sieht dann, an wen er es weitergeben soll.

Genau, also könnte das auch jemand sein, der es durchroutet. Vielleicht noch eine kurze Ergänzung, ich weiß nicht, ob wir da auch noch vielleicht nochmal das mal erläutern wollen. Also man sieht jetzt hier schon, dass beim Onion Routing oder auch beim Tor, also generell bei dem ganzen Verfahren hier, dass der, das ist ein sogenanntes Quell-basiertes Routing, das bedeutet, dass der Sender den Pfad festlegt.

Das unterscheidet sich insbesondere, also wir wissen, also wir haben es gerade schon erläutert, dass in diesen Zwischenschritten halt nicht bekannt ist, wer jetzt effektiv der Empfänger ist. Das heißt, diese Informationen sind halt immer nur quasi für meinen Nachfolger und meinen Vorgänger, mehr weiß ich halt nicht, hatte ich gerade eben schon mal erzählt und das hätten wir jetzt schon ein paar mal gesagt.

Im Gegensatz dazu gibt es dann jetzt das Routing, wie es zum Beispiel von Datenpaketen jetzt im ganz normalen klassischen TCIP, also im Endeffekt im Internet stattfindet. Da weiß jedes Paket automatisch, wer ist der Sender und Empfänger.

Das heißt, jeder Step, wo es dann halt dann von quasi von mir zu Hause zu meinem Router, von meinem Router zu meinem Internetprovider und da dann halt die Schritte, die wir dann auf der Welt machen, um effektiv dann irgendwie eine Anfrage dann nach, weiß ich nicht, in den USA, wo dann halt irgendein Server steht, zu stellen. Das geht ja auch über mehrere Steps und nicht dann in der Direktverbindung.

Und diese Pakete haben halt jederzeit die Information, von wo sie kommen, also von welcher IP-Adresse und wo sie halt hingehören. Das heißt, da haben wir keine Privatsphäre in irgendeiner Form, weil jeder, der dieses Paket in die Hand bekommt, weiß eigentlich, woher es kommt, quasi ganz ursprünglich und wo es auch final hin soll, um da halt diese Route.

Und das ist halt der signifikante Unterschied, dass wir jetzt hier so ein sogenanntes Quell-basiertes Routing im Tor-Netzwerk oder im Onion, als Onion-Routing halt haben, dass da halt festgelegt wird, der Sender definiert den Weg. Sehr gut, danke. Ich habe nämlich an der Stelle auch ein bisschen Schwierigkeiten gehabt, den Unterschied zu verstehen, auch wenn es eigentlich klar ist, wie es mit dem IP-Netzwerk funktioniert. Aber das hat nochmal geholfen, den Unterschied nochmal rauszustellen.

Danke. Ich habe gerade festgestellt, es gibt in dem Buch ein kleines Kästchen, in dem das Quellbasiertes Routing erklärt wird. Das habe ich komplett überlesen, weil es halt durch diesen Kasten eingerückt ist. Da habe ich gesagt, okay, das kann jetzt nicht so wichtig sein, ich muss jetzt weitermachen. Und habe mich die ganze Zeit, während Thorsten das gefragt hat, gefragt, wo stand das denn nochmal?

Ich habe es gesehen, aber ich habe es nicht wiedergefunden, bis ich jetzt irgendwie zufällig auf diesen Kasten drauf geschaut habe. Sehr gut. Ja, es ist, glaube ich, nochmal wichtig, dass man das nochmal herausstellt, dass wir hier dann wirklich diesen Privatsphäre-Aspekt im Vordergrund haben und dass da deswegen dieser Ansatz vom Routing einfach gewählt wird, bei diesem Prinzip.

Genau, vielleicht können wir an dieser Stelle auch nochmal sagen, dass das Kapitel 10 Onion Routing ein sehr langes Kapitel ist. Es hat mehr als 30 Seiten und es ist sehr anspruchsvoll gewesen. Wir drei haben jetzt gestern und heute darüber gejammert, wie schwierig das doch ist und dass es uns so schwerfällt, das Ganze zu lesen. Also, liebe Zuhörer, wenn wir uns hier komplett vertun sollten, bitte korrigiert uns. Wir haben uns Mühe gegeben, aber es ist sehr, sehr anspruchsvoll.

Wir wissen nicht, ob wir alles verstanden haben. Also, ich zumindest weiß es nicht. Doch, ich weiß es, dass ich es nicht habe.

Ja, statt jetzt ist es ja noch relativ high-level, aber das finde ich ist ja auch vollkommen in Ordnung, dass wir jetzt versuchen, wir gucken mal, wie weit wir rein, unten runter gehen oder dass wir an irgendeiner Stelle sagen, okay, wir drei wissen einfach alle nicht, wie es hundertprozentig funktioniert und bevor wir halt irgendwie in den Müll labern, dass wir dann eher vielleicht von unserer Eifer sagen, okay, wir gehen wieder auf eine höhere

Flughöhe und gehen dann halt, dann überspringen da manche Kapitel. Statt jetzt wissen wir auch noch nicht, ob wir komplett durchkommen bei dem Kapitel oder wir sagen dann an irgendeiner Stelle, okay, wir teilen das Kapitel oder wir gehen halt so in die Flughöhe hoch, dass wir dann halt trotzdem durchkommen und sagen, okay, das passt so für uns. Also, an dieser Stelle wissen wir noch nicht, was jetzt in den nächsten 20, 30, 40 Minuten, wie viel auch immer passieren wird. Also, seid gespannt.

Gut, dann, jetzt haben wir gerade ja eigentlich so ein sehr theoretisches Konstrukt oder wie es grundsätzlich funktioniert, aber es ist, es beschreibt nicht das, wie es in Bitcoin oder im Lightning-Netzwerk funktioniert, weil da arbeiten wir, hat mich eben im Recap noch mal erzählt, ja primär mit HTLCs und diese HTLCs müssen ja zwischen den einzelnen Peers weitergeleitet werden oder geroutet werden, damit sie im Endeffekt ja dann beim, wenn

wir jetzt das Beispiel von der Zahlung wieder, von diesen 50.000 Satz, die Alice an Dina schicken möchte, müssen diese HTLCs ja irgendwie dann auch zu Dina durchpropagiert werden und das gucken wir uns jetzt im Onion Routing, also wie da wird das Onion Routing für verwendet für diese Propagation von den HTLCs und das schauen wir uns jetzt dann mal ein bisschen genauer an, würde ich mal sagen.

Wollen wir vielleicht die grundlegenden Begriffe einmal erklären, also mit ausgehender Not und… Genau, wir haben einige Begrifflichkeiten, wobei ich mich gar nicht so genau daran erinnern kann, ob die jetzt im Weite des Kapitels so relevant sind oder ich habe sie einfach übersprungen oder überlesen in irgendeiner Form, aber grundsätzlich haben wir im Endeffekt ja eine Origin, also eine quasi eine sendende, also eine Starting-Node, das ist jetzt in

dem Fall die Lightning-Node von der Alice, weil die im Endeffekt ja diejenige ist, hatten wir gerade beim Quell-basierten Routing, diejenige ist, die die Zahlung initiiert oder die die Zahlung effektiv dann halt ausführen will. Dann haben wir die Final-Node oder Destination-Node, ne, wie heißt sie hier?

Doch, Finale-Node, genau, also im Endeffekt dann jetzt in dem Fall diejenige, die die Zahlung erhält, also da ist dann das Routing vorbei und dann gibt es dazwischen, wir hatten es gerade eben schon mal gesagt, die einzelnen Hops und deswegen, glaube ich, wird das auch Hop-Load genannt, Hop-Nodes, ja, oder einfach nur als Hop.

Hop. Genau, das sind der Effekt, der jetzt in dem Fall dann Bob und Chan, die die Zahlung dann oder den HTLC dann empfangen und dann jeweils an den Nachfolger dann oder an die Nachfolgerin, im konkreten Fall von Chan und Dina dann weiterleiten sollen.

Und je nach Rolle, sagen wir jetzt mal, gibt es natürlich auch Unterscheidungen dann in den Informationen, die dann da zwischen der, also zwischen den, also in den HTLCs dann halt auch gesendet werden, weil zum Beispiel das Dina braucht in ihrem HTLC, also sie braucht kein HTLC mehr irgendwie zu konstruieren, der dann weitergeleitet wird, weil sie ja die finale Empfängerin in dem Fall dann ist.

Und dementsprechend haben wir schon so ein bisschen unterschiedliche Daten dann eben in den HTLCs drin, aber was, glaube ich, wichtig ist, da versuchen wir gleich dann nochmal weiter reinzugehen, ist, dass es trotzdem für jeden Teilnehmer in dieser Route trotzdem immer gleich aussieht, also die Daten werden dann nachher quasi wieder aufgefüllt, also die Gesamtheit der Daten ist trotzdem immer gleich groß, dass man so halt jetzt trotzdem

nicht ausschließen, nicht darauf schließen kann, wo man sich jetzt halt in der Kette befindet und das ist gleich vielleicht dann auch nochmal relevant. Ja, du hast jetzt schon die Begrifflichkeiten genannt, dann wird hier im nächsten Absatz nochmal kurz erklärt, dass wir uns in Kapitel 11 dann der Wegfindung widmen. Ich glaube, ich habe tatsächlich erst in 12. Ah, in 12 sogar, okay. Wobei hier steht 11. Das wir in Kapitel 11 sehen werden, ja, ich habe aber auch 12 in Erinnerung.

Ja, genau, steht auch in 12, steht auch wirklich die Wegfindung dann, also ist vielleicht auch ein kleiner Fehler. Okay, wer weiß, vielleicht gibt es da so eine Vorinfo dann. Also wir sind jetzt gerade an dem Zeitpunkt, dass Alice jetzt erstmal den Pfad auswählt, das heißt, sie schaut sich jetzt quasi das Netzwerk an, das sie vor sich hat und sagt, okay, wenn ich eine Nachricht an Dina schicken will, dann mache ich das am besten über Bob und Can.

Okay. Und es ist nur die Feststellung, Status Quo ist, mit dem, was wir bisher wissen, ohne das Online-Routing, dass wir auch diese Informationen, Short-Channel-ID, CLTV-Expiry-Date und die Fees kennen. Genau, das ist die Information, die über das Gossip-Protokoll kommt, aber das kommt dann erst in dem nächsten, beziehungsweise übernächsten Kapitel, wie diese Informationen weiterverteilt werden.

Aber wir gehen jetzt erstmal von dem Stand aus, dass es nur diesen einen Pfad gibt und für diesen einen Pfad hat Alice diese Informationen bekommen und dadurch weiß sie dann auch, welche Routinggebühren sie dann ansetzen muss, weil sie weiß, okay, auf den Channels wollen Bob und Can jeweils fürs Weiterleiten so und so viele Gebühren haben. Ich denke, also, ja. Ich habe versucht, den Unterschied zu finden zum letzten Kapitel, aber da fehlt mir die Erinnerung. Ab wann wird es denn was anderes?

Also, wo kommt jetzt eine neue Information hinzu? Genau. Sagt mal, wo im Buch bitte auch. Ach so, das wäre dann bei mir ist das dann, also Seite 264. Da gibt es die Überschrift "Alice konstruiert die Nutzdaten" und sie, als erstes die finalen Node-Nutzdaten für Diener. Genau, um nochmal eben das Beispiel von eben nochmal vielleicht hervorzuführen, wenn wir bei diesem Beispiel von diesem Briefumschlag sind, das macht es, glaube ich, ziemlich einfach, das nachzuvollziehen.

Wir müssen erst die innerste Nachricht quasi konstruieren, beschreiben, wie auch immer, weil wenn wir die äußeren Briefumschläge dann halt beschreiben und da quasi die innerste Nachricht da schon reingepackt haben, kommen wir in die innerste ja nicht mehr dran. Deswegen müssen wir quasi von innen nach außen die Nachricht aufbauen und wenn es dann versendet wird, wird es natürlich von außen entsprechend dann nach innen aufgeschält, um da halt beim finalen Empfänger heranzukommen.

Das ist vielleicht dann um das Bild nochmal ein bisschen. Das ist gut, dass du es nochmal wiederholst. Ja, macht auf jeden Fall Sinn. Genau, spätestens jetzt wird es kompliziert und jetzt müssen wir, glaube ich, mal ein bisschen gucken, wie tief wir jetzt dann wirklich ja reingehen und woraus jetzt diese Nutzdaten dann, also was da effektiv jetzt für Diener dann drin steht.

Genau, wir haben, vielleicht können wir das auch mal durchgehen, wir haben den "Amt to forward", also "Amt to forward", das ist effektiv ja der Betrag, der an Diener geht. Genau, also beziehungsweise der, der weitergeleitet werden soll dann.

Bei Diener ist es in dem Sinne nicht so relevant, weil der weiterzuleitende Betrag der gleiche Betrag ist, wie das letzte Feld in den Nutzdaten, das ist dieses "Total Emsat", das ist effektiv genau der gleiche Betrag und das bedeutet auf der einen Seite, glaube ich, also kann es durchaus sein, dass es keine Routingebühren gibt mehr, also oder dass wir schon am letzten Hop angekommen sind.

Es steht irgendwo, ich weiß nicht mehr genau, ich finde es leider gerade nicht, aber ich meine mich zu erinnern, dass dieses "Total Emsat" kann größer sein, wenn es nur eine Teilzahlung ist. Also wenn das steht gleich im ersten, genau, "Amt to forward" auf Seite, ganz unten auf Seite 264.

Die Höhe der Zahlung in Millisatoshi ist dies ein Teil einer Multipartzahlung, dann ist der Betrag kleiner als die Gesamtsumme, andernfalls handelt es sich um eine einzelne vollständige Zahlung und der Wert entspricht dem Rechnungsbetrag, dem "Total Emsat" Wert. Genau. Ja, genau. Also das kann der Unterschied sein, aber du hast recht, Thorsten, in diesem Fall ist natürlich "Amt to forward" gleich dem "Total Emsat", weil es die finale Nachricht quasi an Diener ist.

Das würde ich nicht mal sagen, weil was ist denn in dem ganz konkreten Fall, wenn wir trotzdem weiterhin diese drei Hops haben, also quasi das gleiche Konstrukt, aber keiner von den Leuten nimmt Transaktionsgebühren, dann ist ja in jedem Fall "Amt to forward" 50.000 und der "Total Emsat" ist auch 50.000.

Also es beschreibt nicht, dass es der letzte Empfänger ist, es beschreibt nur, dass wir in dem Moment keine Routinggebühren haben, sondern dass der, also wir wissen, dass der Zahlungsbetrag auch der Routingbetrag ist. Also wir routen ja quasi immer 50.000 darüber, 50.000 darüber, 50.000 darüber, weil wir keine Routinggebühren haben. Aber es gibt uns nicht die Information, dass wir im letzten Schritt angekommen sind. Das ist nur in unserem Beispiel hier, weil wir Routinggebühren haben.

Daraus lässt sich das ableiten, aber das ist nicht jetzt quasi, das ist jetzt… Ja, aber wenn du auf zum Beispiel die Nachricht, Abbildung 10/11 schaust, dann siehst du Chance Nutzdaten und da ist kein "Total Emsat" Amount dabei, sondern Chance Nutzdaten enthalten nur den "Amt to forward". Insofern, also Diener als letzte in dieser, ja in diesem Online-Routing bekommt sowohl den "Amt to forward" als auch die "Total Emsat" als Nutzdaten mitgeschickt. Spannend.

Okay, das heißt, diese "Total Emsat" ist effektiv dein Delicato dafür, dass das der Empfänger ist. Oder die Empfänger. Das ist wieder Teilempfänger oder der Empfänger ist, genau. Genau, also der Empfänger muss auf jeden Fall jetzt, so ist es im… Ich nehme jetzt einfach mal hin, also die Nutzdaten für Diener am Ende enthalten sowohl den "Amt to forward" als auch den "Total Emsat". Genau, ja.

Und daraus, daraus weiß dann effektiv, gut, das weiß Diener ja sowieso, weil sie die Rechnung auch generiert hat in unserem Beispiel, aber so weiß sie dann für sich auch selber, dass sie die Empfängerin der Zahlung ist. Gut, dann haben wir noch diesen "Outgoing CLTV Value". Das ist dieser "Contract Lock Time", was auch immer.

Effektiv hatten wir beim letzten Mal ein paar Mal darüber gesprochen, dass diese "Lock Times" für diese Contracts relevant sind, wenn wir die HTLC-Strecke aufbauen wollen und wenn da halt was nicht so funktioniert, wie es eigentlich sein sollte. Das heißt, wenn es irgendwelche Fehler gibt, wenn die Transaktion rückabgewickelt, wenn halt irgendeine Node während des Routingsvorgangs offline geht und die HTLCs aber trotzdem noch existieren.

Also, dass wir da dann durch diese versetzte, das war ja diese versetzte "Lock Time", also dass quasi je näher man an der finalen Node dran ist, desto kürzer ist diese "Lock Time". Also die "Lock Time" von Can an Dina ist kürzer als die von Bob zu Can und kürzer als die von Alice zu Bob. Ja, genau so war es richtig.

Genau, damit wir da halt, wenn das halt rückabgewickelt wird, jederzeit dann die Leute genug Zeit haben, die halt im Ende der Transaktion, also im Endbereich der Transaktion Zeit haben, ihre Funds dann irgendwie zu claimen, weil sie halt eine kürzere Blockzeit oder eine kürzere Sperre haben als mein oder als der Vorgänger. Ich überlege gerade, was tatsächlich passiert, wenn die "Lock Time" abläuft. Ist da nicht insgesamt der HTLC ungültig? Ja, der verfällt ja theoretisch.

Also, den ich näher… Also, man könnte ihn ja dann, also wir gehen ja immer von dem Fall aus, wenn der HTLC natürlich ausläuft, dann wird er quasi rückabgewickelt, aber man muss ja immer in der Situation sein, wenn halt irgendwas schiefläuft, dass wir on-chain zurückgehen können.

Und das ist ja, glaube ich, signifikant, dann eher der Unterschied, wenn die "Lock Time", dass wir quasi das UTXO, was ja dann aus diesem HTLC effektiv rauskommt, weil ein HTLC ist ja effektiv nichts anderes als ein TIEF, wo halt ein UTXO, also so ein Output dann halt gelockt wird, den man dann halt nicht benutzen kann. Und wenn die "Lock Time" ausläuft, kann ich diesen Output ja dann für was anderes benutzen, weil er dann ja befreit wird dann dadurch, aus diesem Script dann.

Aber gehört nochmal ins letzte Kapitel rein, da haben wir noch im Detail darüber gesprochen, aber das ist auf jeden Fall jetzt hier dann diese Blockzeit oder diese "Lock Time", die hier definiert wird, mit dieser expliziten Blockhöhe, die dann da festgelegt wird, bis wohin dann das HTLC an der Stelle gesperrt ist. Jo. Genau. Dann haben wir noch das "Payment Secret", ne? Das ist im Grunde, das müsste ja der Hash des Secrets sein, das DINA generiert hat, quasi. Ja, hätte ich auch so verstanden.

Genau, also das, was mir quasi aufgelöst werden muss, wo ich quasi das Secret liefern muss, um den gültigen Hash dazu zu berechnen oder den Hash dazu zu berechnen und zu überprüfen, dass es sich um denselben Hash handelt, damit die Zahlung tatsächlich dann auch durchgeführt wird. Ja. Ich habe es ein bisschen kompliziert ausgedrückt, aber ja, so ungefähr. Ja.

Und in der Beschreibung hier wird jetzt von diesem "Probing" gesprochen. Da hat es mich schon so ein bisschen abgehangen. Habt ihr das verstanden? Also was genau wird verhindert, weil nur der Wert für den letzten Empfänger verschlüsselt wird? Können die anderen Nodes, die dazwischen liegen, nicht dieses "Probing" durchführen? Sagt euch das? Also da hat es mich ein bisschen abgehangen.

Ich glaube, "Probing" ist doch im Endeffekt so was, dass man halt als, also ich glaube, ich weiß nicht, ob ich es beschreiben kann, aber so im Endeffekt, dass man halt, dass sie halt dann diese anderen Nodes versuchen würden, ja effektiv dieses HTLC für sich zu beanspruchen, weil sie diese Information ja theoretisch vorher bekommen. Ja. Und dass man da halt dann irgendwie versucht, das für sich dann abzugreifen.

Also ich glaube, so sinngemäß, das ist nicht korrekt erklärt, aber so verstehe ich das. Ich glaube, ich kenne diesen Begriff irgendwo, das wird da glaube ich später irgendwo nochmal, nochmal am Ende auch noch bei Problemen nochmal erläutert, glaube ich, relativ am Ende des Kapitels meine ich. Also ich kenne den Probing-Begriff ein bisschen anders.

Es ist mehr darum, um das Netzwerk so ein bisschen zu sondieren, also um herauszufinden, was für Informationen ich herausbekommen kann über das Lightning-Netzwerk. Das habe ich immer unter "Probing" verstanden. Ja, ja, richtig, genau. Aber es kann sein, dass es hier anders gemeint ist.

Um zu gucken, wie dann, ja, wie ist die Liquidität und sowas herauszufinden, ist diese Route, ist Routing da möglich, wie viel Liquidität liegt da, weil wir wissen es ja beim Lightning-Netzwerk nicht, wie die Liquiditätsverteilung ist. Das wissen wir effektiv ja erst später. Aber ja, genau, das ist effektiv ja das, was dann in den Nutzdaten dann für DIN da drin steht und das wird dann entsprechend ja dann, was war das hier mit, im TLV-Format wird das dann das Ganze serialisiert.

Das heißt, wir haben dann halt einen Hexadezimal-String, der dann da quasi drin steht. So verstehe ich es. Ja, so habe ich es jetzt auch verstanden. Genau, dieses TLV-Format wird auch später nochmal erklärt, steht jetzt hier auf Seite 335, was ja dann irgendwie erst das nächste Kapitel sein sollte. Ja, genau.

Dann kommen wir ja zu den Nutzdaten von Chan, weil der ja der quasi der vorletzte Hop oder der ja doch der letzte Hop eigentlich ist vor DIN-er als Empfängerin und hat mir gerade eben schon mal gesagt, da haben wir jetzt keine Informationen mehr darüber, was der Total-Sat-Amount ist, weil diese Information gibt es nur für DIN-er.

Er beschreibt vielleicht oder beantwortet vielleicht auch nochmal eben so ein bisschen die Frage, dass wir als Hop-Node nicht wissen, was der Gesamtbetrag einfach ist, weil wir diese Information nicht bekommen. Wir können es quasi vielleicht irgendwie ableiten, aber wir wissen es nicht hundertprozentig.

Und das ist vielleicht dann an der Stelle dann die Information, dass das Feld einfach gar nicht gepflegt ist und haben wir noch die Log-Time wieder, diesen CLTV und ja die Channel-ID, in welcher Richtung das halt geroutet werden soll. Was bedeutet ja, das ist ja dann der Channel zwischen Chan und DIN-er, der dann da bei Chan mit angegeben wird.

Das ist interessant, also weil die DIN-er Nutzdaten enthalten das Payment-Secret und Total-Amt-Sat, genau die beiden Dinge, während Chans Nutzdaten diese beiden Dinge, also Payment-Secret und Total-Amt-Sat nicht haben, also den Gesamtbetrag und das Payment-Geheimnis nicht enthalten, sondern dafür halt die Short-Channel-ID. Aber genauso wie DIN-er Nutzdaten halt den Amount-to-Forward und den CLTV-Wert. Ja, richtig.

Genau, das heißt, da haben wir dann die Differenzierung dann da zwischen den Informationen, die dann da weitergegeben wird und bei Bob sieht es effektiv ja genauso aus. Der hat eine höhere Log-Time, hat mir gerade eben schon mal gesagt, die ist 20 Blöcke länger als bei Chan und er hat den höheren Forward-Betrag, also da haben wir die 100 Zatz mehr, die dann Bob dann bzw. die Chan ja dann nachher bekommt.

Chan bekommt ja diese 100 Zatz und er leitet nur noch 50.000 weiter, das heißt, bei ihm bleiben dann 100 Zatz als Routing-Gebühren und bei zwischen Alice und Bob ist das entsprechend ja genauso. In unserem Beispiel war es ja so, dass für 50.200 Zatz quasi als Gesamtbetrag von Alice gesendet wird und 100 landet bei Bob, 100 bei Chan und effektiv 50 landen dann ja dann bei DIN-er als Empfängerin. Und dann ist das Gesamtkonstrukt quasi, die Daten sind dann aufbereitet.

Und jetzt wird es richtig tricky. Bis dahin war es ganz einfach. Ich weiß nicht, also jetzt geht es um das Thema Schlüsselgenerierung, da muss ich ehrlich sagen, da hat es mich, ja, also da hat es mich rausgenommen. Das habe ich nicht verstanden. Ich habe es auch ehrlich gesagt nicht mehr so intensiv gelesen. Ich sehe daran, dass ich mich auch wenig angestrichen habe in diesem Kapitel.

Ja, das hat mich, als ich das gelesen habe, so ein bisschen an die Art, also an Grocking Bitcoin erinnert, als wir uns das Thema angeguckt haben, wie der öffentliche Schlüssel aus dem Private Key bei Bitcoin Keys abgeleitet wird. Das wird ja auch über diese Multiplikation von der Elliptic Curve gemacht. Das klang zumindest für mich ähnlich, als würde da ein ähnliches Verfahren benutzt werden.

Wir multiplizieren ja irgendwie unseren Private Key mit irgendeiner zufällig gewählten Zahl dann oder so was in der Richtung. Aber eine Division von dem quasi ist ja dann trotzdem nicht mehr möglich, weil wir da halt dann auf unserem Graf dann halt woanders landen würden oder auf unserer Kurve und nicht mehr da, wo wir halt, das ist quasi so ein Einweg dann, weil wir das Secret einfach nicht kennen oder die Zahl, die benutzt wurde, um die Multiplikation mit dem Private Key machen zu können.

Also das ist so ein bisschen vielleicht nochmal, vielleicht auch nochmal der Verweis dann auf die Folge von Grocking Bitcoin. Ich weiß nicht, inwieweit wir da auch im Detail reingegangen sind, wie diese Elliptic Curve Ableitung funktioniert, wie wir das gemacht haben. Aber es klingt für mich hier so, als würde es ja hier ähnlich sein. Genau. Und jetzt ist Jan-Paul auch wieder weg. Der hat heute echt Spaß, glaube ich, mit seinen… Wenn es kompliziert wird.

Immer wenn es kompliziert wird, macht er den Wack-Poel-Wahn. Bei der Schlüsselgenerierung aber noch ganz kurz vielleicht vorweg. Am Anfang des Kapitels wird ja nochmal gesagt, dass Alice jede Schicht der Onion verschlüsseln kann, sodass der jeweilige Empfänger sie lesen kann. Also das bedeutet, für jeden Hop dieser Transaktion oder dieser Onion kann Alice potenziell eine andere Verschlüsselung wählen und macht das auch, sodass immer nur der jeweilige Hop sehen kann, was für ihn relevant ist.

Also wir haben ja gerade gesagt, was relevant ist. Also was jetzt Bob zum Beispiel sieht, dass er es weiterleiten muss und an wen und welche Summe. Und Jan wiederum hat aber einen ganz anderen Schlüssel und kann auch nur seinen Brief öffnen. Also selbst wenn er den anderen schon hätte, könnte er den nicht lesen, den, der schon an Bob ging. Ich glaube, das ist nochmal wichtig und das erklärt oder beantwortet so ein bisschen eine Frage, die wir im vorletzten Kapitel, glaube ich, hatten.

Und zwar ging es darum, ob die letzte Empfängerin, also Dina, ob sie, wenn sie die Nachricht bekommen hat vom Inhalt des geheimen Briefs jetzt, um bei den Briefen zu bleiben, ob sie nicht auch dann einfach die anderen Transaktionen auslösen kann, die dazwischen waren, weil sie nicht den anderen irgendwie Gebühren aufzuprobieren im Netzwerk oder ob es irgendeine Möglichkeit gäbe, da was zu tun. Und ich glaube, das ist die Antwort darauf.

Ich glaube, selbst Dina hätte keine Möglichkeit, die Nachrichten zu entschlüsseln, die dazwischen verwendet wurden. Was jetzt für mich gerade die Frage öffnet, weiß Dina vielleicht am Ende über wie viele Hops sie die Nachricht bekommen hat? Sie weiß ja genau, von wem sie die Nachricht, also von wem das Geld dann kam, die Satoshis kam, dass Alice das gesendet hat. Das weiß ja Dina. Also sie weiß ja schon am meisten über die ganze Transaktion. Weiß sie auch, wie viele Hops dazwischen lagen?

Das bin ich mir nicht sicher. Aber ist das relevant für Dina? Ich weiß es nicht, ob es wirklich relevant ist. Rein theoretisch schon, wenn ich jetzt mit Lightning irgendwo etwas bezahle an irgendeiner öffentlichen Stelle vielleicht und die arbeiten mit Channel Illustris zusammen oder auf, keine Ahnung, ich kaufe bei Ledger ein Hardware Wallet und irgendwer hat Zugriff auf diese Daten.

Wer da jetzt mit Lightning irgendwas bezahlt, dann könnten die vielleicht sehen, wie meine Kanäle zu Ledger sind oder es nur so als ein Beispiel. Das wäre ja auch dieses Probing dann, um einfach mehr Informationen über den Sender des Geldes rauszufinden. Also ich glaube oder würde mir daraus schließen, dass das nicht möglich ist, weil das eben alles teilverschlüsselt ist. Ja, mag sein. Aber vielleicht entweder man kommt hier noch drauf oder wir kommen später im Buch noch drauf.

Wäre am Ende so eine Frage. Genau. Aber vielleicht nochmal, um das mit den Schlüssen so ein bisschen zu erläutern. Wir haben halt, wir benutzen halt die öffentlichen Schlüssel von Alice in dem Fall, wenn sie an Bob was sendet und auch dann, also durch diese Verwendung der jeweiligen öffentlichen Schlüssel der Teilnehmer innerhalb der Routingkette werden, wird jeweils dieses Secret für was da generiert wird, auch wieder über diese Elliptic Curve von Daffy Hellman.

Hatten wir übrigens, oder hatte Jan-Paul mit René und mit Jeff über das Buch, das Genesis Book von Aaron von Würdem gesprochen. Da ging es nämlich auch um Daffy Hellman, weil die ja auch relevante Forschungsarbeit für, die Vorarbeit für Bitcoin geleistet haben. Also vielleicht auch nochmal der Verweis auf das Buch, wenn euch das nochmal interessiert. So ein bisschen die Geschichte auch dahinter. Also da wird dann auch Daffy Hellman auch erwähnt. Die ja, die theoretischen Grundlagen für die.

In den 90er, 1970ern übrigens. Genau. Das Kapitel öffnet auch damit so ein bisschen als Hommage mit, ja, wir bauen hier auf bestehende Information oder Verschlüsselungstechnik von vor 50 Jahren. Ja, genau. Die haben die, ich glaube es waren die theoretischen Grundlagen. Daffy Hellman haben nie, glaube ich, was implementiert, sondern sie haben, glaube ich, die Grundlagen über dieses Public, Private und Public Key-Verfahren gemacht. Und die Implementierung danach wäre, glaube ich, erst an RSA.

Das war, glaube ich, dann die wirkliche Implementierung, die aber dann auf der Basis, glaube ich, erst später passiert ist. Ich weiß nicht, Jan-Paul, ist das richtig? Erinnere ich mich richtig? Weißt du das noch, ob das so war? Ja, so, ich glaube, so ungefähr war das. Genau. Also die Idee kommt quasi, oder der, nicht nur die Idee, sondern auch der theoretische Beweis oder mathematische Beweis kommt von Daffy Hellman und eine eigentliche Implementierung ist dann tatsächlich RSA.

Das war die erste Implementierung. Ja, genau. Okay, gut, dann war es dann doch so. Daffy Hellman Key Exchange. Richtig, genau. Aber so viel dann quasi nur ein bisschen den theoretischen Hintergrund davon.

Und das wird da halt sich jetzt dann bei dieser Generierung zu Nutze gemacht, dass wir, dass jeder von den Routing-Partnern natürlich auch einen öffentlichen Schnüssel hat und der wird verwendet, um quasi für die Kommunikation oder für dieses Onion-Paket oder diesen Onion-Teil dann halt eine quasi eine eigene separierte Verschlüsselung aufzubauen, die dann jeweils dann nur der jeweilige Hauptmann entschlüsseln kann.

Und daraus werden dann vier unterschiedliche Schlüssel hier generiert, wo ich jetzt nicht unbedingt weiter darauf eingehen möchte, die halt dann dafür verwendet werden, um diese Integrität und um diesen ganzen Kram, dieses quasi dieses, diesen Teil der Schale von unserer Onion sicher zu machen. Und da wird halt effektiv jetzt dann diese Elliptic Curve von Daffy Hellman dann verwendet, um diese Multiplikation, wie ich es gerade eben schon mal gesagt habe, dann zu verwenden.

Aber lasst uns da gerne mal ein bisschen weitergehen, weil ich glaube, wir verzetteln uns sonst ein bisschen. Aber also ich fand es tatsächlich echt sehr interessant und gut erklärt im Buch, dass ich mir ein Gefühl gegeben habe, okay, ich habe es grob auf einer sehr hohen Fugenebene verstanden, wie es funktioniert oder was das Ziel ist im Grunde genommen.

Vielleicht kann ich das noch sagen, also dass zwei Parteien sozusagen ein Geheimnis errechnen können über eben diese elliptische Kurve, über die Punkte, indem sie nur eine Information des jeweils anderen kennen, können sie sich beide ein Geheimnis errechnen und müssen das nicht über einen anderen Weg noch teilen oder müssen es nicht noch mal irgendwie publizieren, um eben ihre Nachrichten zu entschlüsseln. Ja, genau.

Diese Kombination darauf, dass ich ja meinen privaten Schlüssel habe und ich habe jetzt aber deinen öffentlichen, genauso weißt du deinen privaten Schlüssel und kennst meinen öffentlichen und mit dieser Konstellation können wir dieses Shared Secret, was hier relevant ist, jeweils unabhängig voneinander berechnen, ohne dass wir irgendwelche Informationen davon weitergeben müssen.

Und auf der Basis haben wir dann unsere sichere Kommunikation vielleicht an der Stelle dann oder dass wir dann sicherstellen können, dass diese Information nur an diesen Hop dann auch wirklich dann weitergehen kann. Gut, wollen wir noch mal jetzt zu dem Punkt übergehen, mit diesen Onion-Schichten verpacken, wo wir jetzt zu dem Thema kommen, dass diese Onions immer gleich groß sind, also dass die immer eine bestimmte Größe haben. Also das finde ich auch nochmal relevant.

Das haben wir ja vorhin schon mal angeteasert und das ist, glaube ich, auch ein echt wichtiger Punkt. Genau, das ist jetzt dann im Endeffekt dieser Switch oder diese Abstraktion dann von dem Beispiel, was wir eben haben. Wir haben unseren Brief und wir sind inmitten, also wir sind vielleicht Bob oder Can und dieser Brief, wir wissen ja nicht, wie viele Briefe da noch drin sind und wir wissen auch nicht, wie viele Briefe vorher da waren.

Und dass diese Onion von den Daten her immer gleich groß ist, effektiv im Endeffekt dann, dass wir das auf technischer Sicht so darstellen, dass wir aus dieser Information nicht ableiten können, wie viele noch nach uns folgen, weil die quasi die Nachricht, die wir erhalten, bei jedem gleich groß ist, unabhängig davon, wie viele sinnvolle Informationen da drin sind.

Das wissen wir halt nicht, aber es kann trotzdem dann nicht daraus herausgefunden werden, wie viele kommen noch nach mir oder ist vielleicht eben nicht echt der letzte Hop, leitet das dann Dina weiter und dann ist es Feierabend oder kommen danach noch 15 oder glaube ich bis zum Maximum von 20 Hops, ist glaube ich das Maximum, was da an einer Stelle war, dass man glaube ich 20 Hops machen kann und dann mehr passen in diese Nutzdaten von diesen

1300 Byte, die wir da insgesamt haben, glaube ich nicht rein. Ja genau, jeder Hop sieht sich selbst als den ersten von 20 Hops, so ist es aufgebaut. Und man sieht ja schon in dem Beispiel, in diesem abstrakteren Beispiel, das hast du glaube ich gerade schon erwähnt, dass Dinas Nutzdaten ja anders sind.

Also sie hat ja Total M-SAT drin, sie hat das Payment Secret drin und da kann man ja schon auch ohne jetzt Informatik studiert zu haben, davon ausgehen, dass es einfach, wer schon mal zwei Bilder gespeichert hat, der sieht, dass die einfach immer unterschiedlich groß sind und um eben dieses, auch wieder wahrscheinlich Probing oder einfach nur herauszufinden, wie du sagst, dass man der Vorletzte ist, was ja schon echt ein entscheidendes Risiko sein kann für den Empfänger.

Also man nimmt mal an, dass Dina jetzt irgendwie zwei Bitcoin empfängt und ich der Letzte bin, der einen Kanal zu ihr hat, ich weiß, wo sie wohnt und dann sehe, was ich da hinleite und dann wird es ganz interessant für mich. Ja, um das alles zu verschlüsseln, wird eben, so wird es jetzt hier erklärt, eine feste Länge festgelegt und diese mit einem, hier nennen sie es Trick, sichergestellt. Also es wird eine feste Größe, mehr oder weniger.

Und wir haben Nutzdaten und diese Nutzdaten werden dann halt immer bis zu der Größe von 1300 Byte aufgefüllt. Wir generieren dann einfach Müll, sage ich jetzt mal, also Daten, die halt keine Aussagekraft haben, die aber nicht so aussehen, als wären sie Müll. Das ist, glaube ich, auch noch relevant.

Das kommt auch noch mal ein bisschen später, aber ich glaube, dass wir auch nicht so im Detail reingehen, aber das ist halt auch noch signifikant, dass man nicht von außen erkennen kann, dass da nur Müll ist. Also wir können die Nutzdaten nicht von den aufgefüllten Mülldaten unterscheiden. Das sieht quasi, vom Blick von außen sieht es alles quasi ähnlich oder gleich aus. Wir wissen halt nicht, wie viel da jetzt effektiv drin ist und wie viel nicht. Ja, genau.

Ich glaube, das war schon eine Flughöhe tief genug oder haben wir noch was vergessen zu diesem Aspekt? Genau, kann man vielleicht noch mal sagen, was da noch neben den Nutzdaten noch drin sind. Es gibt dann noch so ein Versionsbyte ganz am Anfang. Das ist quasi aktuell, glaube ich, jetzt immer Version 0.

Das heißt, wenn wir mal von diesem Onion Routing Version 1, 2, 3, also quasi eine neuere Version haben, kann man darüber dann effektiv dem System mitteilen, wir benutzen jetzt eine neuere Version von dem Routing, was vielleicht dann ist, dass Felder anders groß sein können oder dass wir vielleicht, also genau so ist es ja meistens, dass wir nicht genau wissen, das erste ist ein Byte, das andere sind dann 33.

Vielleicht ist der öffentliche Schlüssel dann in der Version 1 einfach 64 Byte groß, kann ja sein, keine Ahnung.

Also wer weiß, wenn man da einfach ein Protokollupgrade dann halt hat, dass man darüber dann die Versionen von einander unterscheiden kann, haben wir ja bei Bitcoin in den Skripten ja durchaus auch das Pay-to, also zwischen Segwit und Taproot meine ich, war es ja auch, dass wir da ja glaube ich auch einen Unterschied in den Versionen, also in der Segwit-Version glaube ich haben, ich weiß nicht, war es so, Jan-Paul? Weiß das jemand? Ich weiß es nicht. Ich weiß es nicht.

So war es aber meine ich irgendwie, dass das eine ja Version 0 und das andere Version 1 glaube ich war oder? Klingt auf jeden Fall plausibel. Ja, genau. Dann haben wir nochmal vielleicht ganz kurz dann noch 33 Byte der öffentliche Schlüssel, das ist dann der, was hier als öffentlicher Session-Schlüssel bezeichnet wird, den hier Alice generiert.

Das ist quasi, damit Alice ihren öffentlichen Schlüssel als Senderin nicht preisgibt, also den öffentlichen Schlüssel von ihrer Lightning-Node preisgibt, wird für jede Transaktion ein eigener Session-Schlüssel generiert, der von ihrem öffentlichen Node-Schlüssel abgeleitet ist, aber keine Rückschlüsse dazu für die Hops dazwischen erlaubt, von wem denn die Zahlung irgendwie kommt. Also das weiß effektiv dann nur die Empfängerin, wo es dann herkommt, aber nicht dann die Hops dazwischen.

Und am Ende haben wir dann noch eine 32-Bit-Prüfsumme, wo wahrscheinlich dann ja manche Fehler dann einfach abgefragt werden, ist die Länge korrekt und passt das, was da drinsteht, irgendwie inhaltlich zusammen. Aber ich glaube, da wird gar nicht so viel zugeschrieben zu dieser Prüfsumme. Obwohl, doch, da wird einiges zugeschrieben. Aber jetzt wird es halt super kompliziert und da ist halt die Frage, ob wir da so jetzt reingehen wollen. Nein, machen wir nicht.

Gut. Dann … Nee, ich glaube, das wird dann zu … Also … Wir sind jetzt auch schon weit fortgeschritten in der Zeit. Ja, aber was, glaube ich, wichtig ist, dass wir natürlich im Laufe, also dieses Onion ist ein String, der wird von Alice losgeschickt und in diesem String, also in diesem kompletten Byte-Stream, der 1300 Byte plus halt die Daten, die davor und danach halt kommen, also die reinen Nutzdaten, die enthalten bei Alice ja schon die Informationen für das komplette Routing.

Also wir haben keinen symbolischen Briefumschlag, der halt irgendwie das voneinander kapselt, sondern in diesem Byte-String, der von Alice losgeschickt wird, ist schon die komplette Routing-Information von Alice zu Bob, von Bob zu Chan und von Chan zu Dina schon verschlüsselt. Nur an diese Informationen in diesem Byte-String, der halt für Außenstehende komplett wirr aussieht, kommt man halt nur mit den Informationen, die die jeweiligen Hops halt haben, indem sie ihre Schlüssel generieren können.

Genau, es gibt ein Shared-Secret zwischen Alice und Bob und, wenn ich es jetzt richtig verstehe, wird dann auch ein Shared-Secret zwischen Alice und Chan generiert. Korrekt, ja, genau. Oder so rum ist das. Genau, so ist das, richtig. Weil nur so kann dann Chan, wenn er das Onion-Paket von Bob bekommt, weiß er dann, okay, also nur so kann er quasi entschlüsseln, was dann im Weiteren drinsteht, richtig? Richtig, ja, genau. In diesen Onion-Nutzdaten.

Genau, und deswegen war es mir wichtig, das gerade nochmal zu sagen, dass Alice quasi schon die kompletten Routing-Informationen mit ihrer Nachricht losschickt, dass alle die gleiche Nachricht in Anführungszeichen bekommen.

Das stimmt nicht, weil Bob zum Beispiel nach seiner Verarbeitung seinen alten Teil wegschmeißt und neue Bullshit-Daten, sage ich jetzt mal, also er entfernt die Routing-Informationen für sich, nachdem er das alles extrahiert und entschlüsselt hat, und fügt dann quasi den Teil, der vorher ja zu ihm zugewiesen war, entfernt er und fügt dann neue Mülldaten hinzu, dass wir trotzdem wieder auf die Länge von 1300 Byte Nutzdaten kommen.

Und das macht dann Chan entsprechend genauso, dass er auch die Entschlüsselung macht, aber dann, nachdem er die Sachen dann da raus extrahiert und seine Daten entfernt hat, fügt er auch wieder neue Mülldaten hinzu, um das wieder aufzufüllen. Also das machen alle Hops, machen das dann trotzdem weiterhin, damit auch zwischen den Hops selber die Privatsphäre gewährleistet ist, dass da auch nicht erkannt werden kann, was ist jetzt, also wo steht man jetzt im Laufe der Kette.

Ich bin mir gerade nicht ganz sicher, weil wir jetzt die ganze Zeit darüber gesprochen haben, also wie jetzt Bob als erster Empfänger dieser Online-Nachricht das quasi für sich entpackt, aber wird hier in dem Kapitel nicht gerade beschrieben, wie Alice die Daten verpackt. Darum geht es doch im ersten Schritt, oder? Ja, genau. Genau, es geht doch gar nicht ums Entpacken dieser Daten.

Ja, aber das ist halt die Frage, wie tief wir da jetzt reingehen wollen, deswegen habe ich das jetzt versucht so auf… Ja, also ich glaube, das ist ganz schwierig, das aufzulösen. Also im Grunde, so wie ich das jetzt verstehe, also wir wissen, das soll 1300 Byte, soll diese Onion-Nutzdaten lang sein. Die fülle ich jetzt erstmal mit beliebigen Daten auf, so dass ich halt 1300 Byte von beliebigen, irgendwelchen Fülldaten heißt das hier, dass ich die habe.

So, das erste, was ich dann tue, ist dann Dinas Hop-Nutzdaten einfügen. Das hatten wir ja ganz zu Anfang gesprochen. Das ist der Forward Amount, Total Amount, Lock Time, das Payment Secret und… ach, das HMAC, H-A-M-A-C oder was auch immer, das kommt da mit rein. So, das packt sie rein und sie schneidet dann quasi, also Alice schneidet in dieser Nachricht an Dina alles ab, was halt über 1300 Byte Onion-Nutzdaten hinausgeht. Das schneidet sie einfach ab.

So, dann hat sie quasi den ersten Teil des Strings befüllt. Und dann wiederholt sie den Prozess, ja, indem sie jetzt noch die Daten von, was ist das dann, Bob's… nee, Chuns-Nutzdaten muss sie dann erstmal verpacken. Sieht dann noch mit rein. Genau, also das heißt dann… Stimmt, sie schneidet hinten immer wieder dann so weit ab, dass sie quasi, also sie fügt vorne neue Daten ran und hinten schneidet sie von den Mülldaten immer was weg, dass sie trotzdem wieder auf die 1300 Byte dann kommt.

Ja, genau, das ist richtig. Das ist das Prinzip, ne? Genau, so funktioniert das. Und so wird quasi nacheinander diese Nachricht aufgebaut und dann sieht man auch, also dadurch, dass wir zuerst Dinas Nutzdaten gebaut haben und danach Chuns-Daten und dann Bob's-Daten dran packen, so rücken halt die Daten von Dina immer weiter nach hinten in dieser 1300 Byte Onion, richtig? Ja, würde ich auch so sehen. Genau, ja, so sieht das dann aus. Die werden immer vorne dran gehangen, die vorderen Bob's-Daten.

Die zusätzlichen Nutzdaten, genau. Und durch das Abschneiden des jeweils folgenden rutschen dann… Die Mülldaten werden theoretisch immer weniger, ne? Also quasi… Ja, die werden von hinten wieder aufgefüllt dann sozusagen, weil die eigentliche Information… Wir sind jetzt gerade erst beim Verpacken, ne? Also das Auffüllen, finde ich, also da bin ich eben schon ziemlich weit vorgesprungen, das Auffüllen war wieder beim… quasi beim Roten selber. Beim Senden der Onion.

Genau, beim Senden der Onion, ne? Also jetzt ging es erstmal darum, im ersten Schritt bauen wir jetzt, also baut Alice dieses gesamte Onion-Nachricht auf. Das haben wir jetzt, glaube ich, verstanden, ne? Ja. Also wir haben hier eine String, 1300 Byte und da drin sind Dinas Nutzdaten, Chans Nutzdaten und Bob's Nutzdaten drin enthalten. Genau.

Und vielleicht noch eine wichtige Information, einfach der Vollständigkeit halber, wenn wir irgendwie das Maximum an Hops haben, dann haben wir wahrscheinlich gar keine Mülldaten mehr in diesen 1300 Byte drin, sondern das sind komplett… Alle Informationen, die da drin sind, sind quasi fürs Routing irrelevant, weil wir den maximalen Bereich fürs Routing ausgefüllt haben und alle unsere, sag ich mal, Schrott-Auffülldaten hinten abgeschnitten haben dann im letzten Schritt.

Ja. Gut. Dann, Hops-Nutzdaten haben wir. Ja, ich glaube, dann senden wir die Onion, oder? Genau. Vielleicht nochmal ganz kurz, dieses HMAC, was du gerade eben sagtest, das ist, glaube ich, die Prüfsumme. Das ist dieser, das ist ein Algorithmus oder diese Art der Prüfsumme, also die Art und Weise, wie das überprüft wird, so wie ich es jetzt gerade verstehe. Also das ist dann… Ja, ja, ja, okay.

Weil ich gerade eben gesagt habe, es gibt keine Informationen dazu, wie diese Prüfsumme funktioniert, aber das ist genau scheinbar dieser HMAC-Prüfalgorithmus, der dann wahrscheinlich die Integrität von den Daten dann halt überprüft, ob das alles dann so weit passt. Ja, genau, also da gibt es auf Seite 276 gibt es da einen längeren Absatzabschnitt, Absatzabschnitt dazu.

Genau, also nur zwei Dinge, also du hast, wie gesagt, das ist irgendwie eine Prüfsumme, eine Sicherheitsprüfsumme, um halt irgendwie sicherzustellen, dass die Daten irgendwie nicht korrumpiert sind. Dann steht aber noch drin, dass das Ganze auch Replay-Schutz und Replay-Erkennung dient. Ich glaube, da ging es darum, dass wenn einmal dieses Onion irgendwie durchgeroutet wurde, dann kann man das nicht ein zweites Mal machen. Das verhindert, glaube ich, dieses HMAC auch, oder?

So habe ich das zumindest grobe Erinnerungen. Ja, steht auch hier so, ich kann es aber noch nicht zusammenfassen. Also ich sehe, dass hier explizit steht, dass das dafür sorgt, dass es nicht möglich ist. Ich glaube, lass uns das dabei belassen, sonst kamen wir wirklich zu tief rein. Genau, ich glaube auch, das macht jetzt keinen Sinn. Genau, lass uns doch lieber in den Schritt gehen, dass die Onion jetzt versendet wird. Ja, da wäre ich jetzt auch, Seite 280 quasi, Onion senden.

Und dann haben wir dann auch wieder dieses Update-End-At-HTLC, das ist das, was wir im vorigen Kapitel auch schon hatten. Das Ganze wird jetzt dann mit diesem 1366-Byte-langen, also das waren jetzt effektiv ja die 1300 plus unsere Overhead-Daten, die wir jeweils links und rechts haben, also unseren Byte-String. Und der wird dann in diese Nachricht reingebracht. Und da sind wir jetzt effektiv in der Situation, dass wir die Routing und die Onions dann über diese Nachricht dann verschicken.

Und dann geht das Ganze natürlich von Alice an Bob. Und Bob quasi extrahiert dann die Onion-Informationen mit den Informationen, die er hat für sich, damit er halt dann daraus herausfindet, okay, passt das alles für mich? Und dann kann er mit den Informationen auch den HTLC aufbauen, was für ihn dann auch dann wieder die Informationen gibt. Okay, ich muss jetzt einen HTLC in Richtung Chan erstellen, der mir dann halt sagt, bitte 50100 Satoshi und so weiter.

Also das sind wir wieder bei dem eigentlich bei dem Ablauf, den wir jetzt im vorigen Kapitel eigentlich haben. Deswegen ist das, finde ich, jetzt gar nicht mehr so relevant.

Aber das, was vielleicht noch wichtig ist, das, was ich eben schon mal erzählt habe, dass er die Information, die für ihn bestimmt war, also Bob jetzt in dem Fall rausschmeißt und die wiederum mit neuen Müll- oder Auffülldaten auffüllt, damit wir wieder auf die Gesamtlänge von diesen 1366 Byte kommen, die darum wieder dann als Add and Update, ein Add HTLC Richtung Chan weitergegeben werden kann, damit er auch dann eine Nachricht bekommt, die genauso groß

ist wie die, wie Bob die auch von Alice bekommen hat. Genau, ich glaube, wie das im Detail im Einzelnen funktioniert, müssen wir, glaube ich, nicht durchgehen, weil das geht jetzt hier los.

Er überprüft die Onion, generiert Füllbytes, dann entschleiert er seine HOP-Nutzdaten extra hier den äußeren HMAC für den nächsten HOP, entfernt seine Nutzdaten, verschiebt die Onion-Daten nach links und konstruiert das neue Onion-Paket und verifiziert die HTLC-Details, bevor er dann das Update Add HTLC an Chan weiter sendet. Also sind schon einige Schritte noch weiter, tiefer gehend als das, was wir jetzt bis hierhin besprochen haben.

Genau, aber dann wiederholt sich das effektiv natürlich beim Chan genauso wie der macht genau das Gleiche, kann man überspringen.

Und wenn Dina dann ihre Nutzdaten empfängt, dann muss sie das effektiv ja, weil sie den Payment-Hash auch schon hat, so steht es jetzt hier zumindest geschrieben, weiß sie, dass die Zahlung für sie ist und muss diesen ganzen Kram eigentlich gar nicht mehr machen, weil sie muss kein HTLC, irgendwie ein anderes weiter aufbauen, weil sie ja die letzte Instanz effektiv halt hier ist. Beziehungsweise sie löst dann das Update, füllt HTLC aus.

Genau, und dann läuft es ja wieder zurück, dass wir da dann wieder die Bestätigung in Richtung Alice haben und dann werden die HTLCs aufgelöst und die Kanalkapazitäten werden aktualisiert und die Commitment-Transaktionen werden entsprechend dann aufgelöst oder neu quasi auf den letzten Stand gebracht und dann ist das Routing idealerweise dann durch.

Ja, ich glaube mir ist jetzt gerade so richtig erstmal klar geworden, dass gar nicht das, also das Geld fließt gar nicht, sondern es ist tatsächlich nur ein Update der Kanalzustände zwischen den Kanalpartnern. Genau. Das ist das, was passiert. Ja, ja, ja.

Also irgendwie diese wirre Vorstellung, also man hat so ein bisschen die Vorstellung naiverweise, dass man, also Alice schickt einen Betrag an Bob und dann an Bob an Can und Can an Dina, so ist das gar nicht, es wird nicht irgendwie ein Betrag genommen und irgendwie so ein String von Sats, also ein String genommen, wo Sats drin stehen und das wird dann rumgeschoben, sondern es werden tatsächlich nur die Kanäle aktualisiert.

Nachdem man sich ausgetauscht hat über die ganzen, also nachdem man sich über diese HTLCs darüber ausgetauscht hat, ob denn alles korrekt ist, also gibt es am Ende jemanden, der das Secret kennt zu dem Payment-Hash und kann das Ganze wieder auflösen?

Ich glaube, du hast gerade, vielleicht ist das meine Erklärung, warum du gerade so eine Vorstellung ursprünglich davon hattest, weil du dich gerade viel mit Cash-Show beschäftigst und da geben wir ja wirklich einen Token effektiv dann per Chat zum Beispiel halt weiter klar. Bin ich natürlich der Sender, der diesen Token generiert hat und jetzt dir, Jan-Paul, dir zuschicke, ich schicke dir wirklich einen Token-Stream zu dir.

Also da wird ja wirklich in Anführungszeichen ein tokenisiertes Geld von mir zu dir gegeben. Also da haben wir ja wirklich ein Bewegen von Geld, aber bei Lightning ist es, wie du es gerade beschrieben hast, wirklich ja nur, die Empfängerin hat einen Kanal und auf ihrer Seite landen dann halt ein paar mehr Satoshi auf ihrer Seite, die sie dann mit Chan halt einfach hat.

Aber Alice effektiv sendet ja nicht ihren Anteil an Dina, sondern sie übergibt ja nur ihren Teil des Kanalguthabens dann an Bobs Seite. Also es fließt effektiv ja nicht das Geld von, also es fließt schon, aber halt nur so auf Basis dieser Kanalzustände. Also nur abstrahierter Weise, ne. Genau, also abstrahierter Weise kann man sich das so vorstellen, als würde Geld fließen, aber was am Ende passiert, ist tatsächlich für Alice, also dass sich nur ihr Kanalzustand zu Bob ändert.

Zu Gunsten dann zu Bob verändert. Zu Gunsten von Bob ändert, genau und so weiter in der Kette. Genau, aber es ist nicht so, dass das irgendwie fließen würde. Das hast du gut erklärt mit dem, mit so einem Token, den man irgendwie weitergeben würde. So ist es tatsächlich nicht. Ja. Das passt wieder zu der Analogie, die ich am Anfang versucht habe zu bringen mit den Bierdeckeln. So wurde es mir irgendwann mal erklärt, dass jeder nur seine Bilanz updatet. Ja. Oder weniger.

Richtig. Oder so ein Röhrchen ist auch immer ein gutes Beispiel. Wir haben so ein Rohr, das ist dann der Kanal und einer pustet halt ein Röhrchen rein, also eine Kugel rein und dann verteilen sich die Kugeln dann jeweils auf der linken oder auf der rechten Seite, aber dann effektiv bewegen sich die Kugeln nicht, um unserem Beispiel zu bleiben, in die anderen Kanäle, sondern sie landen nur auf, die verteilen sich nur auf einer jeweiligen Seite. Ah, ja, ja. Das ist ein gutes Beispiel. Ja, genau.

Du kannst dir vorstellen quasi, dass in dem Kanal zwischen Alice und Bob sind rote Kugeln, im Kanal zwischen Bob und Chan sind blaue Kugeln. Die mischen sich. Alice schiebt eine rote Kugel rüber zu Bob und Bob schiebt dann eine blaue Kugel rüber zu Chan. So funktioniert das. Ja, genau. So ist es ja effektiv dann. Das ist gut.

Gut, sollen wir doch den kurzen Abschluss machen, was passiert, wenn es irgendwie, also es gibt auch, es können, wir sind ja jetzt immer von dem Fall ausgegangen, dass Fehler passen, also dass keine Fehler passieren, dass alles gut durchläuft und wenn Fehler passieren, dann hatten wir das beim letzten Mal ja so, dass die HTLCs ja dann zurück abgewickelt werden, also da läuft die Information ja dann wieder ab einer bestimmten Stelle

dann wieder zurück und um nochmal aufs letzte Kapitel zu verweisen, dann werden die Commitment-Transaktionen ja wieder quasi auf den Zustand hergestellt, wie sie vorher waren, das heißt, diese, wenn das HTLC jetzt in dem Fall, wenn ein Fehler passiert ist, zurückgerollt wird, hat diese Transaktion effektiv ja nicht stattgefunden, das heißt, wir sind auf dem Level der Commitment-Transaktion wieder vor der eigentlichen Transaktion.

Wir sind also im Commitment, sag ich mal, ja, Index wieder auf dem Stand von vorher. Ich weiß nicht, ob man das versteht, aber das ist das, was ich gerade im Kopf irgendwie habe. Ich überlege gerade, ist das tatsächlich so? Also im Grunde verspreche ich doch, wenn ich jetzt einen HTLC annehme, also ich bin jetzt Bob und bekomme von Alice die Nachricht. Ja, ja, genau, mir geht es jetzt von der Verwendung zurück abgewickelt wird, während der Transaktion der HTLC nicht erfolgreich ist.

Genau, aber die Frage ist jetzt, also genau, also die Frage ist jetzt, wird quasi der, was passiert, also HTLC, der läuft einfach ab oder nicht und damit ist quasi der alte Kanalzustand wieder hergestellt. Irgendwie so funktioniert das, es ist nicht so, dass da, also die Frage, die sich mir gerade stellte, ist, wird ein quasi ein neues Commitment erzeugt oder wird tatsächlich auf das alte Commitment zurückgegangen? Da war ich mir gerade nicht ganz sicher.

Ich glaube aber, wenn das HTLC abläuft, dann bist du ja immer noch in dem letzten Committent-Zustand, Kanalzustand. Genau, also so wäre es jetzt auch. Also ich glaube, da wird kein neuer erzeugt, weil der Kanalzustand ja einfach so ist, wie er vorher war. Ich glaube auch, ja, ja, ja. Gut, wollen wir das mit dem Key Send hier noch machen oder sollen wir das einfach überspringen? Weil das ist, glaube ich, dann auch nochmal irgendwie ein bisschen komplizierter gewesen.

Also es gibt ja Möglichkeiten, dass man ohne eine Rechnung direkt Zahlungen an Lightning Nodes schicken kann. Das ist zum Beispiel auch das, wenn ihr jetzt hier an Nodesignal, was per Lightning hier während unseres Podcasts hören und zwar streamt oder uns einen Boost schickt, das findet auch effektiv über Key Send statt.

Das ist ein Workaround, dass wir euch keine Invoice, also keine Rechnung generieren müssen, sondern ihr schickt mehr oder weniger ein Secret von euch aus direkt an uns und mit den Informationen, die wir dann zu euch bekommen.

Also ihr initiiert effektiv eine Zahlung und auf die Art und Weise können wir dann mit der Information, also mit diesem Secret, was ihr generiert habt, können wir überprüfen, okay, da ist wirklich eine Zahlung stattgefunden und auf die Art und Weise, um das mal so grob zu erklären, sind wir da dann fein, dass die Zahlung bei uns angekommen ist. Also das haben wir auf die Art und Weise. Wir selber müssen kein Secret generieren, sondern das passiert dann rein auf Senderweise.

Also das ist dann auch nochmal der Vorteil von Key Send. Das ist ein Feature, was man explizit in Lightning Node aktivieren muss. Das ist, glaube ich, nie standardmäßig an, also zumindest nicht bei LND meine ich. Und ja, damit wird zum Beispiel so etwas wie jetzt dann Sud-Streaming für Podcasts zum Beispiel ermöglicht, wie wir es jetzt hier auch bei Notsignalen nutzen. Ich glaube, das reicht als Zusammenfassung.

Wäre auch eine Frage gewesen, ob das wirklich der Fall ist, bei dem, wie wir es jetzt hier gerade nutzen. Ja, das ist es wirklich. Also das macht sich Key Send zu Nutze, die Sachen, die da im RSS-Feed drinstehen. Genau. Gut. Dann gibt es eigentlich nur noch das Fazit, oder? Also ich weiß nicht. Ja, das Fazit ist, es ist kompliziert. Ja, genau. Das Fazit ist, wir haben es geschafft. Genau, erst mal das. Vielleicht hier nochmal der Aufruf an unsere Zuhörerinnen und unsere Zuhörer.

Gebt uns gerne mal Feedback, ob das, selbst wenn wir das so high-level versuchen für euch zu erklären, euch irgendwie einen Mehrwert bietet. Also gebt uns da gerne Feedback, kommt zu uns in die Gruppe, diskutiert mit uns. Wenn ihr Bock habt, schickt uns gerne einen Boost, wo ihr das beschreibt. Also es gibt ja die unterschiedlichen Möglichkeiten, Twitter, Nostr, wir sind ja überall zu finden. Und lasst uns da gerne mal in den Austausch gehen, ob das euch was bringt.

Weil wenn wir das auf diesem für uns verhältnismäßigen high-level und nicht so wirklich im Detail halt machen, dann kommen wir da auch wahrscheinlich in Zukunft auch gut durch das Buch jetzt durch. Und wir haben nicht die ganze Zeit ein schlechtes Gewissen, dass wir halt super viele Informationen außen vor lassen. Ich glaube, das Thema ist so kompliziert, dass man das rein auf der Audiospur sowieso super schwierig rüberbringt.

Aber wenn man es halt dann versucht, irgendwie zu abstrahieren, wie wir es jetzt versucht haben, dann geht es vielleicht in irgendeiner Form. Ich glaube, deshalb ist es umso spannender von den Leuten, die sich es jetzt bis zum Ende angehört haben. Also wenn ihr euch durchgekämpft habt oder vielleicht selber das Buch lest, reicht euch das? Hilft euch das? Oder sagt ihr, ihr hört es sowieso? Auch schön, auch ein cooles Feedback.

Ja, und wer durch Zufall jetzt auf die Folge gestoßen ist und sich die ganze Zeit gewundert hat, was der Quatsch soll, der kann uns vielleicht auch mal sagen, lass das. Oder habe ich am Anfang gar nicht erwähnt. Also für die Leute, die irgendwie jetzt einfach mal reinhören, weil sie uns irgendwie neu entdeckt haben, müsste man am Anfang vielleicht noch mal ganz kurz sagen, was ist das hier, was machen wir hier? Aber andererseits, ich meine, der Titel, der sagt es ja schon sehr deutlich.

Wir haben im Buchclub auch eigentlich immer in den Show-Nodes super viel drinstehen, worum es da wirklich geht und was der Rest davon ist. Also man erkennt ja schon, dass wir das Kapitel für Kapitel lesen und die, die das bis jetzt angehört haben, also bis zu dieser Stelle, die wissen das wahrscheinlich eh schon. Also ja, wir besprechen das komplette Buch unabhängig davon.

Wir wollen es jetzt einfach mal vollständig haben, so wie wir das Gorking Bitcoin im letzten Jahr oder im vorletzten Jahr auch fertig abgeschlossen haben. Werden wir das auch bei Lightning hier, also Mastering the Lightning Network, werden wir es auch abschließen, dass wir zumindest für uns das Gefühl haben, okay, wir haben das Buch komplett gelesen, wie viel wir davon verstanden und verinnerlicht haben, das ist was anderes, aber wir wollen das Buch trotzdem.

Das ist unser eigener Anspruch, dass wir das jetzt durchziehen und auch euch jetzt… Was haben wir noch? Regelmäßig vier Kapitel, meine ich. Also so von der Stärke des Buchs, wenn ich die Seiten zusammennehme, würde ich schätzen, dass wir noch ein Drittel haben. Ja, 100 Seiten, glaube ich. Aber da kommt auch nochmal, ich glaube, da kommt nochmal richtig… Da kommt ja noch ein Anhang, ne? Da ist noch ein ziemlich dicker Anhang dabei. Also wir haben jetzt noch… Glaub ich auch.

Ich sehe, wir haben noch knapp 100 Seiten. Also bis zu 400 Seiten, also 450 oder sowas und ich glaube bis 300, 100 Seiten noch, ja, super, genau. Also das heißt, es kommen jetzt noch drei, vier Folgen oder sowas und dann nach der und dann sollten wir wahrscheinlich dann durch sein. Müssen wir mal gucken. Was haben wir jetzt, Kapitel 10? Ja, wir haben jetzt noch Kapitel 11, 12, 13, 14, 15, 16, 17 kommen noch. Also wir haben noch ein paar Kapitel vor uns. Ah ja, okay.

Aber… Genau, die sind dann aber vielleicht nicht ganz so lang, ne? Ja. Richtig. Ja, ja, ich sehe schon, Kapitel 13 sind nur 10 Seiten. Also ich glaube, das wird jetzt alles besser werden. Ja. Gut, ja. Ich wiederhole gerne nochmal, dass das hier, also der Buchclub nicht dazu da ist, um euch Lightning zu erklären, sondern ihr dürft uns oder müsst uns dabei zuhören, wie wir versuchen, uns das ganze Thema zu erschließen und zu erarbeiten.

Also es ist primär für uns, um irgendwie die Verpflichtung zu haben, das durchzuarbeiten. Genau. Aber gleichzeitig auch vielleicht, ne, dass die Gedankengänge, die wir vielleicht in dem Moment haben, vielleicht für den einen oder anderen oder die einen oder andere dann in dem Moment hilfreich ist, dann so, ah, okay, die Analogie hat mir jetzt echt geholfen, um das nochmal im Gesamtkontext zu verstehen. So lese ich es mir heute oft, muss ich sagen.

Ja. Ich habe übrigens zufällig auf der Zitadelle zwei Leute getroffen, die tatsächlich unseren Buchclub zu Grocking Bitcoin quasi als Sekundärquelle gehört haben, während sie das Buch gelesen haben. Sehr gut. Oh, schön. Vielleicht passiert das ja mit Mastering Lightning auch noch. Ja, das vergisst man auch immer, ne? Das ist so ein zeitloses Medium.

Das kann gut sein, dass sich jemand das Buch irgendwann schnappt und sagt, ich mache das jetzt, weil ich habe Bock, da irgendwie einen Master darüber zu schreiben. Und denen hilft das bestimmt, dass man einfach mal hier so ein paar stotternden Freaks zuhört, die sich das versuchen zu ergründen. Ja. Ja, aber wie du sagst, es gibt einfach andere Perspektiven auf das, was man da liest. Und teilweise ist es ja auch mal sehr trocken. Cool. Also mir hat es wieder geholfen.

Ich finde es jedes Mal im Nachhinein merke ich, wie wertvoll das ist, dass wir darüber diskutieren. Und ich bin sehr optimistisch, wenn ich sehe, dass die nächsten Kapitel einfach nicht so lang sind. Ja, vielleicht auch noch mal. Da kann man es vielleicht auch mal wieder zweimal lesen. Das macht ja auch schon was, wenn man einfach wieder sich tiefer reindenken kann und nicht versucht, irgendwie alles aufzusaugen wie ein Schwamm. Ja, habt ihr noch was? Focus on the Signal. Not on the noise.

Tschüss. Ja, dann Focus on the Signal und so. Bis demnächst. In zwei Wochen haben wir den nächsten Aufnahmetermin. Also, wir hören uns. Bis dahin. Tschüsschen. Ciao. Not Signal. Focus on the Signal. Not on the noise. Not Signal. Focus on the Signal. Not on the noise.