Nodesignal-Buchclub - E209 - Mastering Lightning, Kap. 13: Framing und Erweiterbarkeit

*Intro* Jo, herzlich willkommen bei Nodesignal, deine Bitcoin-Frequenz in einer Folge, in der ich völlig verloren bin. Ich habe wirklich keinen Plan, was los ist, aber wir machen Buchclub und ich habe bei mir den Thorsten. Hi Thorsten. Hallo, ja. Guck mal, letzte Woche waren wir noch zu dritt, haben uns darüber beschwert, dass die anderen den Pfad nicht gefunden haben und jetzt sind wir nur zu zweit.

Na, aber das ist, müssen wir jetzt mal sagen, der Karlsruher wäre glaube ich sehr sehr gerne dabei gewesen, aber bei ihm sind die Familienangehörigen ein bisschen krank, der hat noch junge Kinder, das geht halt einfach dann nicht. Ob er sehr gerne dabei gewesen wäre, bei dem jetzt vor uns liegenden Thema, sei jetzt mal dahingestellt, aber das Argument, was du gebracht hast, ist glaube ich durchaus legitim.

Ja, absolut, dafür müssen wir Verständnis haben. Also ich gehe davon aus, dass der Karlsruher bei der nächsten Folge wieder dabei ist. So, Thorsten, wir sprechen heute über das Kapitel 13, Wireprotokoll, Framing und Erweiterbarkeit. Wollen wir vielleicht nochmal kurz zurückblicken, was wir bisher gemacht haben?

Ja, kann ich sehr gerne machen. Ich gebe dir ganz kurz die Blockzeit. Ich habe da schon fast damit gerechnet, dass du mich jetzt gleich fragen wirst, deswegen habe ich das schon mal vorbereitet. Es ist die 872818, die ich hier offen habe. Alles gut, sind wir synchron. Sehr gut, mit dem Blockhash, die letzten hinten Zeilen, A77CD9F. Warte, jetzt muss ich aber gerade nochmal den Block aufrufen und A77CD9F. Ja, genau, das habe ich auch gut, haben wir das auch erledigt, ein Traum.

Ja, rekapitulieren vom Kapitel, dass das das Schöne ist, wir haben es endlich mal geschafft, dass wir relativ zeitnah das darauf folgende Kapitel angefangen zu besprechen, wie wir das jetzt heute machen, weil wir nämlich genau vor einer Woche das Kapitel 12 besprochen haben und die Folge noch gar nicht veröffentlicht. Das ist so verrückt. Ja, worum ging es denn? Ich habe die Folge heute noch geschnitten, tatsächlich.

Wir haben über hier Wegfindung und Zustellung der Zahlungen gesprochen im letzten, oder? Ja, doch, du hast vollkommen recht. Lass uns gerne nochmal eine kurze Zusammenfassung machen. Ich habe da jetzt nichts vorbereitet, aber ich versuche das jetzt irgendwie aus dem Kopf zu kriegen. Wir haben überwiegend darüber gesprochen, was für, also es war eher quasi die Problemstellung eher aus theoretischer Informatik Natur, wie wir uns dem Thema genähert haben.

Also jetzt, wie wir auch gelernt haben, dass die Wegfindung selber keine Implementierung, also kein Bestandteil der Spezifikation von Lightning selber ist, sondern dass es jede Lightning Implementierung das im Endeffekt selber wählen kann und welche Strategie da verwendet wird, um halt eine gute Route zu finden.

Ich habe das jetzt absichtlich eine gute Route besprochen, weil es bei der Wegfindung selber, wenn wir ganz viele Knotenpunkte haben, eigentlich zu einem, meines Erachtens, je mehr Knotenpunkte dazukommen, zu einem NP schweren Problem führt. Was bedeutet, dass wir dieses, quasi keine perfekte Lösung für den perfekten Weg nicht in polynomer Zeit lösen können. Deswegen gibt es Heuristiken, die uns dabei helfen, dieses Problem in einem guten Weg zu lösen.

Also um es nochmal ein bisschen einfacher zu sagen, die Menge möglicher Lösungen ist so groß, dass es sehr lange Zeit dauern würde, die optimale Route zu finden und deswegen gehen wir hin und versuchen halt, eine möglichst gute Route zu finden. Das ist das Ziel und das macht es halt, weil es halt möglichst gut sein soll.

Dann kommen halt ein bisschen Wahrscheinlichkeiten ins Spiel, Abschätzungen, die deine Node irgendwie trifft, Annahmen, die sie trifft, mit der deine Node versucht, eine gute Route für eine Zahlung durch das Lightning Netzwerk zu finden. Ja, genau. Und Faktoren, die diese Algorithmen oder diese Heuristiken beeinflussen, sind auf der einen Seite natürlich Informationen, die öffentlich bekannt sind, wie zum Beispiel dann die Gebühren, die Kanalgrößen und all solche Sachen.

Aber es gibt super viele Informationen, die halt vom Lightning Netzwerk oder beziehungsweise von dem Gossip-Protokoll innerhalb des Lightning Netzwerks nicht propagiert werden an der Stelle, wie zum Beispiel dann wie viel Liquidität denn wirklich dann auch in einem Kanal auf welcher Seite jeweils liegt, damit wir, das heißt, wir können nicht wissen, ob wir das, was wir da jetzt wirklich dann über diesen Kanal schicken wollen, auch wirklich schicken können,

weil wir nicht wissen, ob die Liquidität auf der Seite, die wir ansprechen wollen, an der Stelle ausreicht. Und deswegen war so das Hauptmotto in diesem Kapitel aus dem letzten, ja, Versuch und Irrtum an der Stelle, deswegen wir über Versuch und Irrtum ausprobieren können, können wir denn HTLCs über diese Route schicken.

Und wenn wir HTLCs schicken können, dann ist das schon mal eine gute Information an der Stelle, aber auch Informationen, wenn wir eine Fehlermeldung zurückbekommen, dass die HTLCs nicht dadurch geschickt werden können, da können wir zumindest unseren Erwartungshorizont für diesen Kanal zu diesem in diesem bestimmten Zeitraum an der Stelle zumindest etwas einschränken

und realistischer einschätzen, dass wir aus einem 3-Millionen-Kanal, wir wollen eine 1-Millionen-Satoshi-Zahlung schicken, geht nicht, können wir zumindest sagen, okay, die Erwartungshaltung von diesem Kanal ist auf jeden Fall kleiner als eine Million Satoshi an der Stelle.

Deswegen ist dann auch selbst, wenn es nicht funktioniert, dann ist das, wo der Algorithmus oder der Optimizer, wie auch immer man das nennen mag, lernt auf jeden Fall dann an der Stelle schon wieder etwas mehr über den Zustand des aktiven, also des wirklichen Netzwerks mit den Informationen, die halt nicht öffentlich bekannt sind an der Stelle, die wir nur durch Ausprobieren, ja, auf die Art und Weise hinbekommen.

Genau, da haben wir noch so ein Beispiel durchgesprochen und ich glaube, das war es primär eigentlich so, die Kernessenz meines Erachtens von diesem Kapitel beim letzten Mal. Genau, so zwei Dinge, die bei mir hängen geblieben sind, war, also wir wissen, dass kleinere Zahlungen eine größere Wahrscheinlichkeit haben durchzukommen, also je größer die Zahlung ist, desto unwahrscheinlicher ist das.

Und das Zweite, was damit aber zusammenhängt, je mehr Hops eine Zahlung nehmen muss, also je mehr Kanäle sie benutzen muss, desto größer ist das Risiko, dass diese Zahlung scheitert. Also wir können halt, also so relativ pauschal ist das jetzt, können wir aber sagen, also es müssen kleinere Zahlungen sein und die sollten über möglichst wenige Hops gehen, damit wir eine erfolgreiche Zustellung an der Zahlung haben.

Wobei ich wahrscheinlich sagen würde, dass kleine Zahlungen immer natürlich auch in Relation zu der genutzten Kanalgröße an der Stelle halt stehen. Wenn wir nur durch Kanäle routen, die irgendwie einen Bitcoin groß sind, dann ist natürlich eine Million Satoshi in Relation zu einem Bitcoin-Kanal, den es glaube ich mittlerweile durchaus auch gibt, es gibt auch Kanäle, die weitaus größer als einen Bitcoin sind, durchaus jetzt nicht viel.

Aber klar, wenn wir von dem Beispiel sind, wir haben einen Kanal, der irgendwie nur 500.000 Satz groß ist und wir wollen 400.000 da durchschicken, dann ist die Wahrscheinlichkeit, dass das funktioniert, ist aus meiner Perspektive sehr, sehr, sehr gering.

Weil wenn eine sehr geringe, ja quasi, also der Erwartungshorizont ist einfach super klein an der Stelle, weil halt die Möglichkeiten, dass die Liquidität schon ein bisschen auf der anderen Seite liegt, schon fast alles eigentlich schon diese Zahlung gar nicht erst erlauben wird an der Stelle. Ja. Hattest du in deiner Zusammenfassung auch das Thema Multipartzahlung drin?

Das war ja auch noch ein, also das war ja quasi der Abschluss, dass man halt, also es gibt halt eine Möglichkeit, eine Zahlung in mehrere kleine Zahlungen aufzuteilen und dann versucht man die übers Netzwerk zu schicken und wiederholt das so lange, also auch in dieser Versuchsun- und Irrtumsschleife im Grunde, bis halt die gesamte Zahlung durch ist.

Die Idee ist halt, also das Beispiel in dem Buch war, glaube ich, die schicken da eine Zahlung, also teilen sie auf in über 160 Teile, davon gehen dann irgendwie, ja, weil, keine Ahnung, oder lass es irgendwie 100 sein, ist doch egal, also die teilen die halt auf in mehrere kleine Teile, davon gehen, sagen wir mal, fünf nicht durch, dann werden diese fünf nochmal in kleinere Häppchen geschnitten und nochmal versucht, das durchzuschicken und wenn dann wieder was zurückkommt,

dann wird es nochmal aufgeteilt und durchgeschickt. Also genau, ich mache jetzt hier eine Schleife, könnte man ewig so weitermachen. Genau, der Vorteil ist halt, dass man, also dass man halt kleinere HTLCs versucht, also kleiner im Sinne von geringere Beträge in diesen HTLCs, durch das Netzwerk zu schicken.

Genau, was wir gerade auch gesagt hatten, dass die Wahrscheinlichkeit von kleineren Beträgen größer ist, dass die erfolgreich zugestellt oder geroutet werden können, deswegen teilen wir hier sie entsprechend auch in kleinere Pakete auf, was dann die Wahrscheinlichkeit der einzelnen Pakete erhöht, dass sie zugestellt werden. Genau, und damit ist es ja mal René und hier Stefan, glaube ich, gelungen, ich glaube, über 0,3 Bitcoin über das Lightning-Netzwerk zu verschicken.

Genau, und das war vor drei Jahren, meine ich, 2021, also ist schon eine Zeit her, wo ja wahrscheinlich die Infrastruktur und auch die Kanäle vielleicht noch ein bisschen kleiner waren als heutzutage.

Weil wir ja auch, was ein bisschen unser Vergleich, der im Kapitel war, war ja irgendwie, es gibt so und so viele Nodes, so und so viel Kapazität und so weiter, und was wir gesehen haben, es gibt weniger öffentliche Nodes, aber die Kapazität im Lightning-Netzwerk ist trotzdem größer geworden an der Stelle. Was ja dazu führt, dass wir eigentlich weniger größere Player bekommen haben, jetzt im Vergleich zu dem, als das Buch geschrieben wurde.

Ja, ich bin, glaube ich, zu müde, um jetzt diese Schlussfolgerung nachzuvollziehen.

Nein, also wir haben weniger, dadurch, dass wir einen Rückgang von 30 oder 40 Prozent der Nodes, also der öffentlichen Nodes an der Stelle, was wir ja darauf zurückgeführt haben, dass wahrscheinlich immer mehr Leute quasi unannounced Channels und damit auch unannounced Nodes benutzen, die halt nicht öffentlich sind oder nicht Teil des öffentlichen Graphen sind, aber die Kapazität hat sich trotzdem irgendwie verdoppelt oder so,

was im Vergleich zu 2021, was ja dazu führt, dass wir weniger Nodes haben, aber diese Nodes selber haben wahrscheinlich, sind einfach größer oder sind mehr kapitalisiert an der Stelle und erlauben dadurch auch größere Zahlungen oder ja, um quasi entsprechend dann diese Zahlungen dadurch zu schicken durchs Netzwerk. Das wäre jetzt meine Schlussfolgerung an der Stelle. Klingt plausibel. Gut. Wie sieht es aus? Auf ins Kapitel, ich habe keine Ahnung.

Auf ins Kapitel, ich habe keine Ahnung. Den vorigen Titel haben wir jetzt schon festgelegt, das hatten wir gerade am Anfang schon festgestellt. Jan-Paul hat keine Ahnung und ich habe gerade das Kapitel auch einmal gelesen und finde es interessant, aber interessant mit einem entsprechenden Unterton. Also was möchtest du mit dem Unterton andeuten? Also Disclaimer vorweg, es gibt hier Kapitel in diesem Unterkapitel, wo ich mir so denke, ja das ist nett, aber who the fuck cares?

Also warum sollte mich das interessieren? Also dass irgendwie wieder irgendwelche Bits beschrieben werden. Also ich habe jetzt ein Dokument geschrieben, wie wir das bei Nodesignal ja immer machen, da werde ich mich auch daran orientieren und ich habe das auf die für mich interessantesten Punkte, habe ich dieses Kapitel zusammen gedampft.

Deswegen, ihr werdet jetzt bestimmt manche Teile in diesem Kapitel erwarten, die wir aber einfach nicht besprechen, weil das bringt nichts darüber zu reden, welche Datentypen es da gibt. Also es ist vollkommen uninteressant, um das irgendwie hier in so einem öffentlichen Kontext zu besprechen. Also ganz ehrlich, was bringt mir das? Ich weiß nicht, ob es hier um den öffentlichen Kontext geht.

Also für mich geht es primär darum, das Buch zu lesen gemeinsam und etwas über das Lightning-Netzwerk zu lernen. Genau, aber für dich ist es ja wahrscheinlich egal, ob jetzt die Channel-ID ein 32-Byte-langer Byte-String ist oder ein 64-Byte-langer Byte-String. Was interessiert dich das in diesem Moment? Ich kann das nicht beurteilen. Also meine Hoffnung wäre, dass ich diese Information für später nochmal brauche.

Dass mir das quasi dann klar wird, ah, deswegen haben wir damals diese Unterscheidung im Kapitel 13 gehabt. Aber ich lehne mich da hier sehr weit aus dem Fenster, weil ich wirklich, ich gebe es jetzt hier öffentlich zu, ich habe nach nicht mal der Hälfte des Kapitels, das zum Glück sehr kurz ist, habe ich leider aufgeben müssen, weil es mich komplett abgehängt hat. Ich wusste überhaupt nicht mehr, worum es ging.

Also mir fehlt ja völlig der Zusammenhang, wo wir uns jetzt gerade befinden in dem ganzen Lightning-Netzwerk. Deswegen wäre es wahrscheinlich gut gewesen, wenn du das Kapitel zu Ende gelesen hättest, weil zum Ende hin wäre es durchaus nochmal interessant geworden. Deswegen sind auch die meisten Sachen, die ich geschrieben habe, auch eher so im hinteren Teil des Kapitels zu finden, wie du schon gesagt hast, was aber doch relativ kurz ist.

Na gut, dann versuche ich das quasi mit einem Auge, das Buch zu lesen und mit dem anderen Auge gucke ich zu dir rüber auf den Bildschirm und wir unterhalten uns darüber. Ja, das ist richtig. Also, wie gesagt, ich habe das auch schon einmal gelesen und auch in vielen Fällen, wo ich mir dachte, also das ist ja vollkommen unrelevant, das müssen wir hier nicht besprechen. Deswegen habe ich es auch quasi immer nur so quer gelesen, aber das sollte vollkommen reichen.

Aber worum geht es hier wirklich? Wir sprechen heute über das Kapitel Wire, ja, Wire, Wireprotokoll, ne, Wire. Ja, doch, Wireprotokoll. Genau, Wireprotokoll, Framing und Erweiterbarkeit. Was bedeutet hier an der Stelle, ja, Framing, beziehungsweise das Wireprotokoll ist im Endeffekt das Protokoll, worüber das Lightning-Netzwerk auf dem Transportlayer zwischen zwei Nodes die Kommunikation herstellt. Das ist das, worum es hier quasi thematisch geht.

Deswegen finde ich auch immer diesen Topologie-Baukasten, der dann immer am Anfang von jedem Kapitel ist, dann dargestellt, eigentlich ganz, ganz wild, ganz interessant, weil man da halt wirklich so sieht, okay, das ist so dieses, wir sind ja auf der Messaging-Schicht unterwegs, die ist da links daneben ja so dargestellt, also das ist im Endeffekt die, ja, auf der Protokoll-Ebene, wie halt kommuniziert wird unter den Nodes.

Und darum soll es ja heute an der Stelle gehen und inwieweit dieses Protokoll, was da genutzt wird, erweitertbar werden kann. Also wo wir so ein bisschen auch wieder an das Thema reingehen, das ist das, was gleich noch kommen wird, wie kriegen wir so Vorwärts- und Rückwärtskompatibilität hergestellt?

Wir kennen das aus dem Bitcoin-Hauptnetzwerk, da ist ein bekanntes Verfahren die Soft Forks, die aber auf Basis des Konsensus natürlich super kompliziert und beziehungsweise super viel Vorlaufzeit brauchen, weil man entsprechenden Konsens finden muss unter den Teilnehmern und erst wenn wir da einen nahezu 95% oder größeren Prozenteinteil aller Teilnehmer im Netzwerk irgendwo signalisieren, jo, wir haben da Bock drauf, dann wird das ja erst durchgeführt.

Diese Problematik haben wir vielleicht als kleine Preview vorweg, im Lightning-Netzwerk tatsächlich nicht, weil wir da keinen Konsens in dem Sinne halt haben. Aber deswegen das Wireframing ist vielleicht, und damit fängt das Kapitel an, ist die Art und Weise wie diese Datenpakete, die da verschickt werden, kodiert werden und wie dann entsprechend auch das Protokoll die Datenpakete definiert.

Und wenn wir das zu unserem Kanalpartner schicken, wir zum Beispiel, ich schicke dir eine Nachricht, damit du auch weißt, okay, du benutzt auch dieses Wire-Protokoll, wie du das dann entsprechend wieder dekodieren kannst und die Informationen daraus auch extrahieren kannst und für dich noch nutzen kannst, wenn ich dir eine Information mitteile an der Stelle. Okay, also ich versuche nochmal gerade wiederzugeben, was ich meine verstanden zu haben.

Es geht tatsächlich darum, was die Nodes miteinander kommunizieren. Wie? Wie? Nicht das, was ist das über Onion und das Gossip-Protokoll, das hatten wir ja in den vergangenen Kapiteln. Jetzt geht es wirklich darum, wie werden diese Informationen auf der technischen Ebene zwischen den Peers verteilt? Also wie werden die Bytes kodiert, die diese Informationen des Gossip-Protokolls beinhalten?

Genau, okay, vielleicht bringe ich nochmal gerade meinen Gedanken zu Ende und dann können wir nochmal kurz darüber sprechen, ob es jetzt das Was oder das Wie ist, über das wir hier sprechen.

Ich habe das jetzt so verstanden, also wenn ich jetzt eine bestimmte Nachricht in das Lightning-Netzwerk schicke, zum Beispiel, wenn ich jetzt irgendwie einen neuen Kanal announce, das hatten wir ja jetzt gerade, bei dem Aufbau des Lightning-Netzwerk-Topologie, kündige ich unter anderem an, hey, ich habe hier einen neuen Kanal aufgemacht zum Beispiel, da gibt es dieses Channel-Update. Channel-Announcement und Channel-Update, das sind beide zwei Nachrichten.

Ja, genau, also mach mir das Channel-Announcement, genau. Also ich habe hier einen Kanal eröffnet und den möchte ich jetzt gerade dem Lightning-Netzwerk ankündigen. Dann reicht es ja, also muss ich ja irgendwie zu verstehen geben, meinen Partnern, mit denen ich kommuniziere, also denen ich diese Nachricht zukommen lasse, dass sie auch überhaupt verstehen, was kommt denn da jetzt eigentlich.

Und das mache ich, indem ich, also quasi, also Nachrichten sind ja immer im Byte-Format und ich reserviere mir quasi die ersten beiden Bytes, wenn ich das richtig verstanden habe, um meinem Kommunikationspartner mitzuteilen, hey, hier kommt jetzt ein Channel-Announcement oder hier kommt jetzt ein, was weiß ich, ein Channel-Update oder keine Ahnung, was wir noch so an Nachrichten im Netzwerk untereinander, miteinander austauschen. Ist das so richtig wiedergegeben?

Ja, genau. Also im Endeffekt, es geht um die Kodierung, wie diese Informationen, also wie die Informationen kodiert werden und dann auf den Transportweg geschickt werden und auf der anderen Seite wieder entsprechend dekodiert werden kann. Dass das definiert ist, damit die jeweiligen Kommunikationspartner wissen, welche Information kann ich wo erwarten.

Okay, weil ich hab ganz am Anfang des Kapitels in dem Abschnitt Wireframing, da geht es doch darum, wir nehmen an, dass die Verschlüsselungsschicht bereits verarbeitet wurde, also bereits dekodiert ist und dass die zu sendenden Bytes noch nicht verschlüsselt sind, also noch nicht kodiert sind. Das heißt, wir sind doch hier auf dem, wo sind wir denn? Also das ist doch quasi der Inhalt der Nachricht, den wir uns jetzt anschauen, oder?

Ja, genau. Also ich glaube, hier wird jetzt davon angenommen, dass es nicht verschlüsselt ist, weil es es halt einfacher macht, weil man den Verschlüsselungslayer da außen vorlässt. Was ich interessant finde, dass quasi die Variante der Transportverschlüsselung beim Lightning-Protokoll eine erweiterte Variante des Noise-Protokolls ist. Das fände ich übrigens sehr gut. Deswegen habe ich das extra markiert, dass wir hier auf jeden Fall sehr viel Noise haben. Offensichtlich.

Ja, ich habe es auch gelesen, aber ja. Aber da stand doch, glaube ich, irgendwas mit dabei, dass das später noch erläutert wird. Genau, nächstes Kapitel, da geht es, glaube ich, dann weiter. Okay, genau. Also deswegen habe ich das so ein bisschen nach hinten geschoben. Das Noise-Protokoll wird uns auf jeden Fall noch ein bisschen begleiten. Aber ich glaube, dann habe ich das so einigermaßen verstanden, oder? Da sind wir uns doch so ein bisschen einig.

Es geht darum, was die Nodes miteinander kommunizieren. Und zwar, na ja, du hast ja recht, wie, nicht doch wie, was? Ja, also was und wie. Also hier geht es erst mal um das Wie und dann halt auch im zweiten Zuge dann halt, wie das Was, also wie das Was kodiert wird. Also es geht darum, dass Nachrichten ausgetauscht werden, also in welchem Format. Wie dieser Byte. Du schickst doch quasi irgendwelche Bytes durch die Gegend, oder nicht? Ja, richtig, genau.

Genau, und jetzt geht es, also das ist das Was. Das sind quasi, da sind irgendwelche Bytes. Abgesehen von der Kodierung, Dekodierung. Wir tun mal so, als würde es alles unverschlüsselt im Netzwerk hin und her geschickt werden. Aber das ist ja das, worum es hier primär eigentlich geht. Dass wir wissen, okay, dieser Byte-Stream, der da halt kommt, ist 32 Byte zum Beispiel lang und entspricht dem und dem. Zum Beispiel der Channel-ID oder sonst was halt.

Ich hatte gedacht, dass ich, bevor ich quasi diesen String schicke, der die Channel-ID enthält und maximal irgendwie 32 Byte lang, sagen wir mal, so wie das hier definiert ist, dass ich doch vorher einmal mitteilen muss, du, hier kommt eine Channel-ID. Ja, absolut, klar. Du musst natürlich, genau, das ist ja, glaube ich, genau das, was da definiert wird, dass du halt einfach immer so ein, du musst ja irgendwie dem PI auch mitteilen, welche Information da jetzt halt kommt. Ja, ja, ja, okay.

Genau, damit er das auch zuordnen kann, richtig. Das ist natürlich auch Teil dann davon, absolut. Ja, ja, okay, ja. Ja. Ja. Punkt. Punkt, gut, machen wir einen Punkt, gehen wir weiter. Genau, jetzt würde, was da auf Seite, 333 kommt mit diesen ganzen Type-Kodierungen und so weiter. Das würde ich jetzt alles erstmal im größten Teil skippen, weil das könnt ihr euch selber durchlesen. Das ist jetzt nicht besonders spannend.

Aber was ich interessant finde, das ist das Einzige, was ich mir auf dieser Seite markiert habe, ist, ich weiß nicht, ob wir das schon mal genannt haben, aber ich finde, das ist zum Beispiel ein Unterschied auch zum Bitcoin-Hauptnetzwerk, dass wir im Lightning-Netzwerk Milli-Satoshi schicken können. Ja. Und Milli-Satoshi sind im Endeffekt quasi 1000 Milli-Satoshi sind ein Satoshi. Das heißt, wir haben noch eine weitere Untereinheit, die wir im Bitcoin-Hauptnetzwerk nämlich nicht haben.

Das heißt, wir könnten theoretisch noch viel kleinere Zahlungen schicken. Warte mal, wie ist denn das? Wir schicken ja tatsächlich nur Zahlungen im ganzen Satoshi. Das Einzige, was in Milli-Satoshi ausgedrückt werden kann, sind gegebenenfalls Gebühren. Ja, wollte ich auch so sagen. Genau, das ist wieder das Thema, was wir beim letzten Mal hatten, die Parts per Million.

Und dadurch, dass wir da ja durch diese Parts per Million dann relativ schnell in sehr, sehr kleine Zahlen nachher vielleicht dann kommen, werden natürlich diese Fees dann auch in diesen Milli-Satoshi-Bereich dann angegeben. Wenn du irgendwie 1300 Milli-Satoshi als Fees bekommst, was bekommst du denn da wirklich? Du bekommst ja so gesehen dann an der Stelle, ja, da bekommst du 1,3 Satoshi wahrscheinlich dann. Bekommst du wirklich 1,3 Satoshi? Die hängen sich dann auf?

Das würde ich jetzt erwarten, dass die Lightning-Node die so verwalten kann, dass du dann, wenn du, sag ich mal, 4 mal 1,25 bekommst, dass du dann 5 Satoshi hast. Würde ich jetzt erwarten. Ich glaube nicht, dass das, weil das macht ja keinen Sinn, wenn das dann eh abgerundet wird oder aufgerundet wird, dann, wenn es aufgerundet wird, wird es ja auch nicht funktionieren, weil dann würden wir ja mehr Satoshi schaffen, als es eigentlich gibt. Das stimmt.

Deswegen müssen wir eigentlich ja knallhart die auch genauso annehmen, wie sie geschickt werden. Ja, oder sie werden abgerundet, ne? Das kann ja auch sein. Du drückst zwar die Gebühr aus mit, sagen wir mal, was ist ein einfaches Beispiel, also mit 1,4 Parts per Million, ne? Und dann, wenn es irgendwie 3 Satoshis sind, dann hast du halt, weiß nicht, nochmal 1,2 an Gebühren drauf. Dann wird abgerundet aus 1 Satoshi Gebühr. Ja, aber das kann nicht durchs Sein.

Das ist ja die Frage, wie die Nodes das verwalten, ne? Also spätestens ja, wenn man ja dann on-chain geht mit seinem Lightning-Kanal, spätestens da wird ja gerundet. Also ich habe aber noch nicht, also in keiner Node-Implementierung, die ich bis jetzt benutzt habe, die Frage, ob die Oberflächen das entsprechend so darstellen. Also genau, auch in keiner Oberfläche habe ich jemals gesehen, dass mir ungerade Satoshi-Beträge angezeigt wurden.

Dass mir irgendwie angezeigt wurde, ich hätte da 1,3 Satoshi statt 1 Satoshi. Vielleicht wird es auch einfach nur gerundet. Also kann auch sein. Aber immer nur nach unten. Anders geht es ja nicht. Genau, muss ja dann. Anders geht es dann nicht. Weil würden wir, wie gesagt, dann würden wir ja mehr Satoshi schaffen, als es eigentlich gibt, wenn wir nach oben aufrunden würden zumindest. Das wäre natürlich eine schöne Frage, die wir dann auch mal dem René stellen könnten.

Falls das jetzt nicht im weiteren Verlauf des Buches noch geklärt werden sollte, dann wäre das doch mal eine Frage, die wir ihm mal stellen können, wie das denn das Verhältnis ist, da von Melissa Satoshi und der Anzeige oder der Beträge, die ich überhaupt in meinen Wallets, Lightning-Wallets angezeigt bekomme, die ja immer ganz zahlig sind. Ja, gut. Ja, das wäre jetzt das, was ich jetzt da auf der Seite mehr angeregt hatte. Aber finde ich halt eine spannende Diskussion.

Dann kamen wieder nur so ein paar Kapitel, die ich dann eher überflogen habe.

Und jetzt war für mich dann eher wichtig, dass wir jetzt zu diesem Thema kommen, Vorwärts- und Rückwärtskompatibilität. Weil das ist ja auch einer der Hauptpunkte, die jetzt hier in diesem Kapitel angeführt werden. Und da wird Protobufs für benutzt, was auch immer das ist. Das Nachrichten-Serialisierungsformat, das zuerst bei Google eingesetzt wurde und sehr beliebt geworden ist. Und eine abgeendete Variante verwenden wir jetzt im Lightning-Netzwerk.

Das habe ich mir hier irgendwie auch notiert gehabt. Ja, genau. Aber was ist Protobuf jetzt? Also Nachrichtenserialisierungsformat. Das heißt, da gibt es bereits quasi eine, wie eine Art Library. Ja, was heißt denn Serialisierung? Serialisierung heißt, da ist ja im Endeffekt die Kodierung, Dekodierung.

Also du serialisierst es ja im Endeffekt an der Stelle, dass du aus diesen Bytes dann so einen Byte-Stream machst, den du wirklich dann auch auf die Netzwerkschicht schicken kannst und das wirklich dann auch dann wirklich auf der untersten Ebene versenden kannst. Und da wird das ja dann... So erinnerst du dich daran, wie das OSI-Schichten-Modell funktioniert? Irgendwann hatten wir da schon mal drüber gesprochen. Wir hatten ja im Rahmen von Grokking Bitcoin glaube ich mal drüber gesprochen.

Ja, genau. Und wir haben ja auf der Elektronenebene, wo dann wirklich die Daten übertragen werden, dann über das Netzwerkkabel oder halt über die Welt hinweg, da müssen die Daten ja dann irgendwann serialisiert werden, dass wir die auf diese Leitung schicken können und erst dann die darübergeordneten Schichten dekodieren diese Informationen ja wieder, die uns das dann wieder in Byte darstellen und dann können wir aus diesen Byte-Informationen da wieder die Information interpretieren,

die dann da drin steht. Und das ist wahrscheinlich das, was ProtoBufs-Format hier macht. Du hast jetzt davon gesprochen, dass wir da die Daten streamen. Ich hatte jetzt irgendwie... Also während ich... Also jetzt, wo ich drüber nachdenke, hatte ich glaube ich jetzt in dem Buch hier... Also streamen ist wahrscheinlich das falsche Wort, aber du weißt, was ich meine. Ja, aber also das wäre jetzt aber tatsächlich meine Frage.

Also werden da tatsächlich Daten gestreamt oder schickst du in sich geschlossene Pakete? Ja, ja. Jetzt geschrieben wird da glaube ich nichts an der Stelle. Das Netzwerk... Aber das ist glaube ich jetzt auch nicht so der Fokus an der Stelle. Nein, nein, nein, absolut nicht. Ich wollte nur gerade, ob ich da irgendwie eine falsche Vorstellung habe, weil du von streamen gesprochen hast. Also ja, okay. Also wir gehen eher davon aus, dass das in sich geschlossene, abgeschlossene Datenpakete sind.

Und wir müssen uns jetzt halt darüber einig werden, wie dieses... Also die reinen Daten, wie die jetzt wieder übersetzt werden für deine Node verständliche Daten. Genau. Du gehst ja dann in dem Software-Stack dann nach oben. Und auch erst auf einer bestimmten Ebene kann ja wirklich dann da verarbeitet werden, okay, das ist eine Channel ID, die dann mir dir das und das jetzt sagt. An der Stelle. Aber die reinen Daten selber sind ja dann, ja, binäre Informationen im Endeffekt.

Eins sind nur Nullen. Das ist das, was Maschinen auf der untersten Ebene verarbeiten können. Und das muss ja dann auch irgendwo dann seri... Das ist wahrscheinlich dann an der Stelle das, was mit Serialisierung gemeint ist. Aber der Fokus oder das, worum es hier eigentlich geht, ist, dass dieses Proto-Buff-Format benutzt wird, um die Vorwärts- und Rückwärtskompatibilität in diesem Protokoll sicherzustellen.

Was bedeutet, dass die, wenn wir Ergänzungen haben, wird eine Rückwärtskompatibilität, also durch dieses, im Endeffekt, haben wir da keine Probleme durch die Ergänzung von diesem Proto-Buff-Format, weil ältere Clients neue Neuerungen quasi nicht beeinträchtigen. Das ist das Ziel, wie wir solche Änderungen bauen müssen.

Und nach vorne gerichtet entsprechend müssen die Vorwärtskompatibilität sichergestellt sein, dass ältere Clients, die diese neuen Features auch nicht kennen, diese Daten einfach ignorieren können. Das ist einfach. Wobei ich, als mir das aufgeschrieben habe, auch nicht so genau den Unterschied verstanden habe, was das bedeutet. Auf der einen Seite beeinträchtigen wir die nicht, aber auf der anderen Seite sollen die anderen die ignorieren. Im Endeffekt ist beides eigentlich so das Gleiche.

Ich kann es dir jetzt ehrlich gesagt auch gerade nicht sagen. Okay, anyway. Ja, aber also rückwärts- und vorwärtskompatibel soll es sein. Und das ist jetzt mein Verständnis. Protobuf ist tatsächlich so ein, wie hieß es, Nachrichtenserialisierungsformat. Das es halt erlaubt, Änderungen vorzunehmen, die sowohl vorwärts- als auch rückwärtskompatibel sind.

Genau, weil das ist wichtig, damit das Netzwerk halt bei irgendwelchen Feature-Updates weiterhin untereinander so weit wie möglich kompatibel bleibt.

Beim, das hat man gerade eben schon gesagt, beim Bitcoin-Hauptnetzwerk haben wir ja dann diese bekannten Vorgehen wie den Softwalk, der auch vorwärts- und rückwärtskompatibel ist, wo halt dann auch immer sichergestellt werden muss, dass ältere Bitcoin-Fullnodes, neuere Format, also von neuen, jetzt zum Beispiel, wenn man eine Legacy-Node hat und dann kommt an der Stelle SegWit, dass dann jetzt eine SegWit-Transaktion von einer Legacy-Node, dass die die nicht irgendwie zu Crashen bringt oder so,

dass die die Daten dann an der Stelle einfach ignoriert und trotzdem einfach weiterlaufen kann an der Stelle, aber trotzdem immer noch in der Lage ist, diesen gesamten Block zu validieren und den ursprünglichen Konsens dann an der Stelle dann für sie fein an der Stelle ist. Ja, aber diese Konsens-Anpassungen, die haben wir im Lightning-Netzwerk nicht.

Deswegen ist das Lightning-Netzwerk, wenn so neue Funktionen auf der Protokoll-Ebene gemacht werden können, sind sie, kann man die viel schneller umsetzen, weil wir da nicht so diese Konsensabhängigkeit an der Stelle haben. Okay, aber ist das, verstehe ich das jetzt so, dass aufgrund dieser Verwendung von einer Art von Protobuf es möglich ist, Änderungen im Lightning-Netzwerk einfach so vorzunehmen?

Naja, also du musst ja mal überlegen, also wo findet denn die Konsensbildung statt im Hauptnetzwerk? Ja. Wir haben ja gelernt, HTLCs sind ja nichts anderes als Bitcoin-Skript. Also unveröffentliche Transaktionen im Grunde. Richtig, genau. Das heißt, der Konsens, den wir ja weiter im Bitcoin-Netzwerk haben, findet ja auch im Hauptnetzwerk statt.

Das heißt, das Lightning-Netzwerk abstrahiert im Endeffekt ja diese, quasi diesen Konsens aufs Hauptnetzwerk und geht einfach davon aus, dass der Konsens da eingehalten wird, weil sonst würde Lightning ja nicht funktionieren. Du, das habe ich schon verstanden, das war gar nicht meine Frage. Vielleicht versuche ich es dir nochmal anders zu stellen.

Ist es so, weil wir diese Variante des Protobufs-Nachrichtenformates verwenden, ist es einfacher, Änderungen in Lightning zu implementieren, also Änderungen, die den Bitcoin-Konsens nicht betreffen, geht ja auch gar nicht, darf es ja gar nicht, aber die also einfacher zu implementieren oder auch auszurollen, weil halt auch Clients, die noch nicht auf dieser Änderung sind, also dieses Update des Lightning-Protokolls, noch nicht verstehen, dass das dann möglich ist?

Genau. Also ich glaube, um es einfach zu halten, dieses Protobuf-Format ist in seinem Aufbau und seiner Struktur so flexibel, dass man damit relativ einfach Anpassungen und Vorwärts- und Rückwärtskompatibilität dadurch sicherstellen kann. Ich glaube, das ist einfach das, wovon wir jetzt ausgehen können. Das ist einfach eine Information, die wir jetzt vielleicht einfach in die nächste Stelle hinnehmen, ohne da jetzt weiter reinzugehen.

Aber dadurch ist das Lightning-Netzwerk sehr flexibel, weil es halt diesen flexiblen Kern an der Stelle hat, der dafür verwendet wird, um Erweiterungen einzubauen. Und da halt ältere Clients nicht beeinträchtigt werden in ihrer Funktionalität, wenn neue Sachen kommen sollten. So, dieses Type-Length-Value-Format kann man sich auch gerne durchlesen. Würde ich jetzt auch mal skippen, finde ich auch nicht besonders spannend. Das ist ähnlich wie dieses Big Size Integer-Codierung.

Auch eine tolle Information, interessiert uns aber an der Stelle auch nicht. Was ich viel spannender finde, sind diese Feature-Bits. Und das erklärt dann vielleicht auch noch so ein bisschen, wie neue Features ins Lightning-Netzwerk eingeführt werden und wie die Abstimmung zwischen Nodes auf der Ebene, wie man quasi so einen Feature-Abgleich macht. Deswegen würde ich da gerne noch mal ein bisschen reingehen. Ja, hau rein. Das ist tatsächlich jetzt ...

Jetzt kommen wir in den Teil, den ich nicht mehr verstanden habe. Ich habe bei Big Size Integer-Codierung aufgehört, weil ich es vorher schon nicht verstanden habe. Das zeigt einfach nur an, wie innerhalb der Codierung angezeigt wird, wie groß ist diese Zahl, die da jetzt kommt. Also das ist alles nett, da ist ein ... Aber ist, glaube ich, jetzt auch ... Naja, hat jetzt nicht so einen Höhenwert. Weniger relevant. Was spannender sind, sind diese Feature-Bits.

Diese Feature-Bits geben im Endeffekt an, ein bestimmtes Feature zum Beispiel wird neu eingeführt und über dieses Feature-Bit kann an ... Die sind Teil der Node-Announcement und der Channel-Announcement-Nachricht. Die hatten wir ja schon mal in den vorigen Kapiteln. Und da werden diese Features dann mitgegeben, diese Feature-Bits.

Und diese Feature-Bits können im Endeffekt anzeigen, dass das Feature, worum es hier gerade geht, für die Kommunikation mit einem anderen Peer optional ist oder ob es quasi zwingend erforderlich ist. Und durch diese Anzeige von diesen zwei unterschiedlichen Möglichkeiten, da gibt es auch so eine schöne Tabelle hier auf der Seite 338, die nennt sich das hier Feature-Bit-Kompatibilitäts-Matrix. Und das heißt, wir haben ja optional erforderlich und unbekannt.

Unbekannt ist dann einfach, dass wir dieses Feature-Bit nicht lesen können. Wir hatten ja gesagt, wir sind vorwärtskompatibel, rückwärtskompatibel, was auch immer. Beides. Auf jeden Fall, genau. Wir sind beides an der Stelle. Deswegen, wenn da ein Feature-Bit kommt, also eine Feature Nummer 23 zum Beispiel, die kennen wir aber nicht.

Also die kennt mein Client nicht, aber der Client, der mit dieser Feature Nummer 23 zu mir kommt und mit mir eine Verbindung aufbauen will und angezeigt wird, dieses Feature ist aber optional. Und dann ist das für mich vollkommen fein. Da können wir eine Verbindung trotzdem aufbauen, weil ich dieses Feature zwar nicht kenne, aber du kennst es. Und dann ist das trotzdem fein. Also wir können trotzdem untereinander kommunizieren. Also machen wir es einfach.

Wir beide haben jeweils eine Node, kommunizieren jetzt miteinander und dann sag ich dir zum Beispiel, ich habe hier ein Feature, das ist erforderlich für mich. Genau. Und dann musst du gucken, okay, kenne ich dieses Feature, unterstütze ich das, tue ich das nicht, dann können wir keinen Kanal miteinander betreiben. Also kein Kanal ist das eine, genau. Ich glaube, die Kommunikation zwischen uns funktioniert schon gar nicht.

Wir können nicht über das Gossip-Protokoll an der Stelle miteinander kommunizieren, weil unsere Nodes untereinander dann an der Stelle halt nicht miteinander kompatibel sind, weil die Features entsprechend hier dann einen harten Cut an der Stelle halt machen. Und über diese Feature-Bits wird das dann entsprechend angezeigt. Okay, also pass auf, wenn ich es richtig verstanden habe.

Wenn ich eine neue Node im Netzwerk bin und sage, hallo, hier bin ich, ich möchte mich mal mit anderen Nodes verbinden, dann sagt meine Node, meine Node sagt dann, ich unterstütze Feature A, B, C, D, E und F. Die halt diesen Status, diesen Bit-Status erforderlich oder optional haben. Genau, okay, die haben noch eine zusätzliche Qualifikation. Genau, also A erforderlich, B optional, C erforderlich, D optional.

Das ist, glaube ich, eine wichtige Information an der Stelle, dass wir eine Liste von Features haben, dass wir nicht nur einen Bit hier haben, sondern wir haben ganz viele. Und was da auch wieder der Vorteil ist, es kann erweitert werden. Vielleicht ist es dann eine fortlaufende Liste an Features. Keine Ahnung, wie diese Features jetzt aufgebaut werden, aber es gibt auf jeden Fall jetzt ein neues Feature, was dann 121 ist. Das ist jetzt ganz fresh.

Und das können du die neueste LND-Implementierung, die gestern veröffentlicht wurde. Und alle anderen Clients kennen das noch nicht. Aber es ist als optional definiert, deswegen ist es tangiert. Es sind im Endeffekt alle anderen Clients nicht. Wir können trotzdem weiter miteinander quatschen, so wie es vorher halt auch war. Genau, aber wenn ich auch eine Node wäre, dann wäre es so, juhu, ich habe einen gefunden, der auch ... Dann können wir dieses Feature nutzen.

Genau, was auch immer das dann sein mag. Sehr abstrakt jetzt, aber ich glaube, ich habe es kapiert. Und so können dann die Nodes untereinander dann ihren Feature-Abgleich einfach machen. Ich glaube, und dafür ist das halt sehr wichtig. Und man hat den Vorteil, es ist halt auch sehr flexibel und einfach erweiterbar an der Stelle, weil wir halt einfach so easy dann halt diese Feature-Nummern dann weitergeben, also quasi erweitern können.

Dann wissen wir einfach, sind wir kompatibel untereinander oder nicht. Ja, nice. Klingt gut. Ja, richtig. Genau, das hatten wir gesagt, dass die Node-Announcement, Channel-Announcement und in den Init-Nachrichten auch sind diese Feature-Bits enthalten. In welchen? In den Init-Nachrichten? Was waren denn nochmal Init-Nachrichten? Vielleicht bei der Initialisierung. Ich meine, das wird es ja wahrscheinlich sein, aber ich weiß nicht, wann diese Nachricht gesendet wird.

Kann ich mich auch nicht daran erinnern. Also, ja. Es steht da jetzt, wir nehmen das jetzt mal hin. Also in Node-Announcement, Channel-Announcement und in den Init-Nachrichten, da werden Feature-Bits mitgeliefert. Genau. Und das ist natürlich auch so für dann wahrscheinlich relevant, wenn wir dann einen bestimmten Zahlungstyp oder hier HTLC, so wird es hier genannt, über eine bestimmte Route routen wollen.

Und dieses Feature, was wir benutzen wollen, müssen wir natürlich auch mit allen Nodes, die die Kanäle auf dieser Strecke haben, überprüfen, ob diese Nodes das dann überhaupt unterstützen. Und da sind wir wahrscheinlich noch bei einer weiteren Einschränkung, die jetzt dann unseren verfügbaren, unsere mögliche Route oder unsere Wegfindung auch noch weiter einschränken oder als Kriterium beeinflussen können. Das hatten wir ja in der letzten... Ist das so?

Ich würde jetzt erwarten, mir fällt gerade ein gutes, passendes Beispiel dazu an. Ich glaube, diese Taro Assets, das wird ja auch im Lightning-Protokoll irgendwie transferiert. Und wenn wir keine Node haben, die dieses Feature von diesen komischen Assets da verschicken kann, können wir wahrscheinlich über diese Nodes diese Information nicht verschicken. Ob es jetzt wirklich so ist, weiß ich nicht.

Aber wir haben doch jetzt gerade gelernt, dass wir eben diese Variante des Protobufs benutzen, wo wir halt den Teil, den wir nicht verstehen, ignorieren können. Und trotzdem können wir das noch weiterleiten.

Weil ich glaube, so wie ich das jetzt interpretiere, das würde ja bedeuten, wenn du jetzt ein neues Feature, wie zum Beispiel Bolt 12 auf einmal benutzen würdest, dann könntest du ja mit fast gar keinem mehr im Lightning-Netzwerk kommunizieren, weil gerade am Anfang nur sehr wenige dieses Bolt 12 Feature kennen. Also du kannst es zwar announcen, also ich glaube, dass es so ist, dass du sagst, hey, das ist bei mir irgendwie optional, ist Bolt 12 verfügbar.

Aber du kannst trotzdem noch mit den anderen Nodes im Netzwerk kommunizieren. Weil sonst würden wir ja quasi mit jedem neuen Feature, das wir auf den Markt bringen, würden wir ja erst mal das Lightning-Netzwerk stark beeinträchtigen. Weil es immer einen Punkt gibt, wo halt die ersten Nutzer dieses Features nicht mehr daran teilnehmen können, am Lightning-Netzwerk.

Das macht doch Sinn. Wahrscheinlich ist das auch so in der Onion dann dekodiert, dass wir an der Stelle sowieso diese wirklichen reinen Feature-Informationen, dass die nur beim Empfänger wirklich relevant sind an der Stelle. Ich meine auch sogar tatsächlich, jetzt wo du es gerade sagst, dass das mit diesen Taro Assets, die es da gibt, dass die nur beim Sender und Empfänger quasi vorhanden sein müssen, damit die die interpretieren können.

Aber auf der Onion, auf der Route selber, die können es einfach weiterleiten, weil es einfach ein Datenpaket ist, was die weiterschicken. Das macht ja mehr Sinn. Du hast vollkommen recht. Cool. Dann habe ich hier noch irgendwas. Bla bla bla. Softworks haben wir jetzt gerade schon ein paar Mal besprochen.

Und genau, was interessant ist, was hier auch als Beispiel angeführt ist, da bin ich sogar auch tatsächlich schon fast beim Ende, bei diesen Ende-zu-Ende-Upgrades, das habe ich mir da nochmal explizit rausgezogen, dass diese Multipart-Zahlungen tatsächlich, die wir eben besprochen haben, beziehungsweise im vorigen Kapitel, was ja da auch von René Pickardt an der Stelle stark gepusht wurde vor drei Jahren, oder generell viel von ihm untersucht wird,

ist, dass das auch über so ein neues Feature-Bit eingeführt wurde vor ein paar Jahren und auch so unter den Nodes direkt, dass die Nodes untereinander signalisieren können, aha, okay, ich kann Multipart-Zahlungen verarbeiten, weil das erklärt vielleicht jetzt auch wieder dann das, was wir uns letzte Woche gefragt haben, als wir gesagt haben, was macht denn, wenn wir irgendwie eine Zahlung auf zehn HTLCs, also in zehn Teilzahlungen, aufteilen, die empfangene Node

muss ja auch das verarbeiten können und wissen können, okay, ich habe einen Gesamtbetrag von einer Million Satoshi, ich kriege jetzt zehn Hunderttausender-Zahlungen, wenn ich jetzt erst mal nur acht bekomme und dann erst in der zweiten Iteration dann nochmal vielleicht viermal 50 Satoshi, um auf die eine Million zu kommen, dass dann die Lightning Node als Empfänger auch sagen kann, erst wenn ich diese, jetzt in dem Fall, dann sind es ja dann zwölf Zahlungen dann, also acht, acht Hunderttausend

und dann die vier Fünfzigtausende, erst wenn ich die erhalten habe, dann schicke ich das HTLC approved dann, oder wie auch hier, HTLC acknowledge, das war das, glaube ich, na, auf jeden Fall diese Bestätigung an, dass der, nee, HTLC fulfillment, fulfill HTLC, auf jeden Fall diese fulfill HTLC. Ich weiß noch mal einen Schritt davor, war das nicht so, dass du erst quasi bei dieser Routenfindung, dass du quasi erst die ganze Route aufbaust mit dem, also mit dem Secret, dass du weiterschickst?

Ja, genau, richtig, und ja erst, wenn ja dann, wahrscheinlich wird dann das Secret aufgeteilt, um das Preimage dann zu haben, und damit wird ja dann bewiesen, dass der Sender das Image an der Stelle dann überhaupt hat, und wenn er das dann an der Stelle dann durchgeroutet hat, kann ja dann auch der Empfänger sagen, jo, das Secret ist genau das, was ich auch erwartet habe, jetzt kann ich die hier HTLC fulfill machen, und dann werden die HTLCs ja dann nach hinten, wieder rückwärts dann abgewickelt

und aufgelöst und entsprechend der Sender bestätigt damit ja dann, der Empfänger bestätigt die Zahlung, so. Das ist ja im Endeffekt der Hintergrund davon. Und um nochmal auf die Multipartzahlung jetzt zurückzukommen, und das ist jetzt wahrscheinlich auch genau dann das, was dann was dann halt notwendig ist, damit diese Zahlung überhaupt verarbeitet werden kann, damit wird wissen, okay, ich kriege hier nicht nur ein HTLC, sondern kriege jetzt hier halt N HTLCs, die halt beliebig groß sein können.

Also die Art und Weise, wie diese mehreren HTLCs untereinander in Verbindung stehen, das muss ich ja interpretieren können. Und das ist wahrscheinlich an der Stelle dann das, was dann über das Feature-Bit ausgehandelt wird, beziehungsweise dann signalisiert, dass sich das überhaupt kann.

Genau, wobei halt, also jetzt habe ich verstanden, die Ende-zu-Ende-Upgrades heißt, also auf der ganzen Route müssen nur Sender und Empfänger das Feature-Bit Multipart-Payments verstehen, alle anderen Hops auf der Route, denen ist es egal, die leiten ja einfach nur HTLCs weiter.

Genau, das ist es nämlich an der Stelle, weil für die dazwischen ist es wirklich, ist es ja, okay, ich kriege jetzt hier ein Hunderttausender HTLC, okay, fein, leite ich weiter, kein Problem, hier kriege ich noch ein Hunderter HTLC, okay, leite ich weiter, scheißegal. Wir wissen ja nicht, dass die im Zusammenhang zueinander stehen, weil sie ja auch nur den Vorigen und den Nachhärigen quasi Hop an der Stelle kennen.

Davor und danach kennen sie ja nichts mehr, deswegen haben sie ja keine weiteren Informationen darüber. Das macht auf jeden Fall Sinn. Ja, okay. Ja.

Ein weiteres Beispiel ist die Key-Send-Funktion, die es gibt, um die Hauptzahlung direkt an einen Pupp-Key wie einer LN-Node zu schicken. Warum ist das ein, warum ist das ein Beispiel für... Das wurde da in dem Buch auch noch als zweites Beispiel genannt und das Key-Send ist zum Beispiel auch das tatsächlich, es ist ein sehr, sehr, sehr gutes Beispiel, weil wir nämlich ja ein Value-for-Value-Podcast sind und ihr uns substreamen könnt und diese substreaming-Funktion wird tatsächlich über Key-Send

realisiert. Nur durch das Key-Send-Feature auf den Lightning-Nodes könnt ihr uns substreamen, weil ihr nämlich über den, über das, was dann im Podcast-Index drin steht, im Podcast- Index, beziehungsweise in unserem RSS-Feed von unserem Podcast, steht unser Lightning-Public-Key drin, der der Empfänger ist und mit dieser Public-Key- Information können die die Lightning-Wallets, die zum Beispiel jetzt im Fountain drin sind, einen entsprechenden Invoice bei unserem Public-Key

anfragen und auf die Art und Weise uns dann eine Anmeldung direkt schicken, ohne dass wir vorher ein Invoice generieren müssen von unserer Seite aus. Und das ist zum Beispiel das, was jetzt per Key-Send realisiert wird an der Stelle und deswegen ist, wenn ihr da hier einen Mehrwert draus zieht, könnt ihr uns darüber sehr schön ein paar Satz zukommen lassen. Sehr gut. Thorsten, das hast du echt wunderbar, mit dem letzten Beispiel noch den Value-for-Value- Aufruf untergebracht.

Als wäre es geplant gewesen. Sind wir durch, oder? Ich habe noch das, was mir gestern oder vorgestern so spontan eingefallen ist, wo wir auch beim Thema Satz-Streamen sind. Ich weiß nicht mehr genau, was ich genau gesagt habe, dass Satz-Streaming einen Incentive schafft, dass man aufmerksamer bei unserem Podcast zuhört. Also das ist

auch sehr, sehr wichtig. Also wir haben hier, wir schaffen, oder ihr schafft selber durch den, dadurch, dass ihr Satz-Streaming aktiviert, für euch selber einen Anreiz, dass ihr aufmerksamer bei unserem Podcast zuhört, weil ihr ja im Anführungszeichen Geld dafür bereitstellt, dass wir hier einen Passsatz kriegen genau und ja. Bezahlt, ja.

Ich zögere so beim Begriff Zahlung, weil wir ja keine Rechnung geschrieben haben, sondern ihr werft halt Geld rein in diese virtuelle Kiste, die wir da aufgestellt haben, wo ihr Geld reinschmeißen könnt. Thorsten, heb den Finger. Wir erstellen ja keine Rechnung, hast du gerade gesagt. Auf technischer Ebene erstellen wir ja keine Rechnung, indem wir eine Leitlinie in Wasser stellen. Warte mal, ich habe doch jetzt hier gerade gelesen, also

KeySend. Eine frühere Implementierung spontaner Zahlungen namens KeySend funktioniert, indem das Pre-Image einer Zahlung einfach in das verschlüsselte Onion eingefügt wird. Beim Empfang entschlüsselt das Ziel, das Pre-Image und nutzt es dann, um die Zahlung abzuwickeln. Okay, warte mal, also KeySend, das Pre-Image einer Zahlung wird in das verschlüsselte Onion eingefügt. Das Pre-Image, was ist denn das Pre-Image nochmal? Das Pre-Image ist doch das, was der Empfänger eigentlich erstellt.

Genau, eigentlich ist es ja so, als wir als empfangene Node schicken das Pre- Ne, wir schicken das verschlüsselte Pre-Image Genau, und dann kann quasi der Sender, kann dann die Zahlung konstruieren. Dadurch, dass mir jetzt aber der Sender bereits das Pre-Image einer Zahlung bereits, warum schickt mir denn jetzt der Sender das Pre-Image einer Zahlung? Das verstehe ich nicht. Der Sender schickt mir das Pre-Image einer Zahlung. Wir bekommen das Pre-Image doch vom Empfänger zugestellt.

Er stellt ein Invoice und da ist ja das Pre-Image drin. Und erst wenn er das Pre-Image innerhalb der Onion erhalten hat, kann er sicher sein, dass über die Route das Pre-Image, was ja der Empfänger generiert hat, über die HTLC-Route vom Sender zu ihm zugestellt wurde und erst wenn er das Pre-Image, was er ja selber generiert hat, wieder in seinem HTLC, der zu ihm geroutet wurde, wiederfindet, kann er ja sagen, okay, die Zahlung ist angekommen.

Das ist ja der normale Weg, wie ein HTLC oder beziehungsweise eine Zahlung im Lightning-Netzwerk konstruiert wird. Also nur nochmal für Doofe, ich hatte das so im Kopf behalten, ich meine, wir lesen das Buch ja jetzt auch schon seit anderthalb Jahren, länger als anderthalb Jahre, oder? Ja, schon. Okay, wir sind schon lange dran. Bald zwei. Bald zwei.

Wir sind bald fertig. Aber jetzt nochmal, also das, was bei mir hängen geblieben ist, das Pre-Image ist doch quasi das Geheimnis, dass ich als Empfänger der Zahlung generiere. Ein Hash dieses Pre-Images schicke ich an den Sender, oder? So war das doch. Und der Sender kann dann damit quasi die HTLCs bauen, indem er den Hash reinpackt und so wird das quasi, so wird das, der Hash des Pre-Images propagiert

auf der ganzen Route. Und wenn der Hash des Pre-Images bei mir angekommen ist, kann ich sagen, hey, ich hab hier das Pre-Image, das deckt sich mit dem Hash des Pre-Images und so kann dann quasi die Zahlung rückwärts abgewickelt werden, weil er immer quasi, wir machen das einfach, wir haben noch einen Hop zwischen uns, du bist der Sender, ich bin der Empfänger, ich sage jetzt dem Empfänger, also pass auf, hier ist das Pre-, ich als Empfänger

sage jetzt der Node, die zwischen uns liegt, hier ist das Pre-Image, also kannst du die Zahlung quasi durchführen, diese mittlere Node, die nimmt das Pre-Image, gibt es dir und sagt, hey, hier ist das Pre-Image zu dem Hash, den du mir geschickt hast, also bitte zahl mich. Oder war das nicht so?

Ich glaube tatsächlich, also das mit dem Hash ist auf jeden Fall richtig, da meine ich mich auch wieder daran zu erinnern und scheinbar ist hier der Unterschied, dass wir hier beim Key Send direkt das Pre-Image verschicken und nicht einen Hash. Genau, aber der Sender schickt dir das Pre-Image. Der Sender schickt ein Pre-Image mit. Genau.

Vielleicht ist das dann an der Stelle genau andersrum, dass wir halt als Sender, wenn wir als Sender in dem Sinne ja das Geheimnis direkt mitschicken und der Empfänger selber kann das dann auf der Basis dann "abrufen", in Anführungszeichen. Also irgendwie so, also so versteht sich das irgendwie, dass wir, ja. Anyway, das sind hier drei Sätze, in denen das beschrieben ist. Wir können es nicht genauer erklären, wie das jetzt an der Stelle genau

funktioniert. Vielleicht kommt das nochmal separat. Ich bezweifle es, weil es ja jetzt eher was Nischiges ist, glaube ich. Deswegen, ja. Gehen wir mal davon aus, dass es auf jeden Fall anders funktioniert als eine normale, normales HTLC Routing, wie wir es sonst halt machen. Top. Gut. Da ist ja fast nichts drin in dem Kapitel, trotzdem 50 Minuten.

Ja, also, ich bin dir auf jeden Fall super dankbar, dass du das so aufgearbeitet hast, weil ich, ich muss jetzt auch gestehen, ich hatte mir eigentlich mehr Zeit zum Lesen des Kapitels heute eingeplant und habe es jetzt in der halben Stunde vor der Aufnahme überhaupt erst geschafft, in das Buch reinzuschauen und bin dann ziemlich schnell frustriert, gescheitert und hab gesagt, guck mal, keine Ahnung, lass uns einfach mal loslegen.

Das ist doch gut, Jan-Paul, dafür kannst du jetzt auf der letzten Seite mal das Fazit vorlesen, weil ich finde, das fasst es sehr gut zusammen, das, was wir jetzt quasi in sehr vielen Worten besprochen haben und dann haben wir da auf jeden Fall einen guten, guten, ja, Strich unter dem gesamten Thema und können dann mit freudiger Erwartung dann auf das 14. Kapitel dann in der nächsten Folge gehen. Bitteschön. Gut.

Fazit. Lightnings Wire-Protokoll ist unglaublich flexibel und erlaubt schnelle Innovationen und Interoperabilität ohne strengen Konsens. Das ist einer der Gründe dafür, dass sich das Lightning-Netzwerk so schnell entwickelt und für viele Entwickler attraktiv ist, die Bitcoins Entwicklungsstil als zu konservativ und langsam empfinden. Sehr gut. Focus on the signal. Not on the noise. Danke, Jan-Paul. Mach's gut. [Musik]