Nodesignal-Talk - E235 - libbitcoinkernel API

Herzlich willkommen bei Node-Signal, deine Bitcoin-Frequenz. Heute mit dem Thorsten. Hallo Thorsten. Hola. Hola. Ja, und mit mir, dem Jan-Paul. Und wir haben heute ein sehr, sehr spannendes Thema, sehr interessantes Thema, ein auch sehr technisches Thema, wie wir gleich lernen werden. Vielleicht mal ganz kurz zur Motivation.

Wir hatten vor zwei, drei Wochen in unserem Fireside-Chat, als wir, also die Nodesignal-Crew zusammensaß und mal so eine lockere Aufnahme gemacht hat, unter anderem das Thema OP Return aufgegriffen gehabt und da kam die Fragestellung auf, was ist denn eigentlich, was hat es mit diesen ganzen verschiedenen Bitcoin-Implementierungen? Neben Bitcoin Core ist da ja bekanntermaßen jetzt Bitcoin Nutz auch unterwegs. Was hat es eigentlich mit diesen verschiedenen Bitcoin-Implementierungen

auf sich? Wir haben darüber kurz mit dem Merch gesprochen und der Merch hat uns vorgeschlagen, dass wir doch mal einen neuen Gast einladen können. Der ist auch gleich der Einladung gefällt und es freut mich sehr heute The Charlatan begrüßen zu dürfen. Hallo. Hi, freut mich sehr. Hallo. Sehr schön. Vielleicht mal ganz kurz The Charlatan, du arbeitest an dem Projekt Bitcoin Kernel Library oder LibBitcoin Kernel.

Wir besprechen das gleich im Detail, was das denn eigentlich ist, dieses LibBitcoin Kernel. Vielleicht kannst du so ein bisschen was über dich erzählen, was auch immer du von dir gerne preisgeben möchtest. Wo du vielleicht herkommst, wie bist du bis zu diesem Projekt heute hierher gekommen? Ja, das kann ich gerne machen. Ich bin schon lange Bitcoiner. Das fing bei mir im Abiturjahr 2013 an.

Und ich bin über Bitcoin in die Programmierung gekommen und habe dann 2018 zum ersten Mal an Bitcoin Core gearbeitet. Und ein paar Jahre später hat dann ein anderer Entwickler, der Carl Dong, das Bitcoin Kernel-Projekt ins Leben gerufen. Und ich hatte das damals erst so am Rande verfolgt, fand es aber sehr interessant.

Und als er dann im Zuge dessen, dass er eine eigene VPN-Firma jetzt gegründet hat, Obscura VPN, hatte er das Projekt an mich weitergegeben und ich arbeite jetzt seit gut zweieinhalb Jahren Vollzeit daran. Ja super, danke. Dann auf jeden Fall schon mal Danke für die Einführung.

Da bist du auf jeden Fall ja schon sehr lange im Thema dabei und auch cool, dass du halt durch das Thema Bitcoin zur Entwicklung gekommen bist oder generell halt, dass wir jetzt auch mal wirklich jemanden als Entwickler dann auch mal hier im Podcast haben. Aber ganz wichtig ist, was wir in jedem Podcast halt machen, ist, dass wir die Blockzeit erstmal ab miteinander abstimmen. Hast du die zur Verfügung? Kannst du uns die nennen? Die letzte, die ich abgelesen habe, ist 899.800.

Oh, da sind wir schon zwei Blöcke weiter. Die kamen, aber jetzt auch innerhalb der letzten vier Minuten kamen zwei neue Blöcke rein. Ah Mist. *lachen* Ja, aber das passt glaube ich. Macht ja nichts. Also wir haben uns aber jetzt gefunden. 899802 ist die Blockzeit. Das passt. Genau. Dann können wir jetzt auch wieder weitermachen.

Vielleicht, es ist natürlich immer gut zu wissen, oder beziehungsweise es sollte den meisten da draußen klar sein, dass Leute, die irgendwie an Projekten rund um Bitcoin Core arbeiten, also im Open Source Bereich arbeiten, natürlich immer irgendwie finanziert werden müssen. nun mal keine Company namens Bitcoin AG, die irgendwie Angestellte bezahlen könnte. Vielleicht könntest du einmal kurz erzählen, wie deine Arbeit an dem LitBitcoin-Projekt finanziert wird.

Ja, die ersten paar Jahre, an denen ich am Bitcoin Core gearbeitet habe, habe ich das einfach freiwillig gemacht. Ich glaube, ich muss nicht weiter erklären, wieso das Projekt eine extreme Faszination ausstrahlen kann. Ich bin sehr dankbar dafür, dass es Leute gibt, die mich dafür finanzieren. Und zurzeit kann ich das über Entwickler-Grants machen, die Organisationen an Open Source Entwickler, die mich ausstellen. Und in meinem Fall ist das Spiral.

Die haben ein ziemlich großes Grant-Programm, das glaube ich mittlerweile 30 oder 40 Open Source Entwickler entweder Vollzeit oder Teilzeit unterstützt. Und zum anderen ist das das MIT Digital Currency Initiative, das mich zur anderen Hälfte auch unterstützt. Und ja, zusammen erlaubt es mir halt, Vollzeit an diesem Projekt zu arbeiten, was sehr cool ist.

Ich glaube, um das vielleicht nochmal so, du hast es ja gerade auch schon angedeutet, dass man gerade so als Open-Source-Entwickler wahrscheinlich in vielen Fällen das eher aus Überzeugung macht und nicht jetzt irgendwie um dem großen Geld Ich denke, dass man in der freien Wirtschaft wahrscheinlich wesentlich mehr Geld verdienen würde, wenn man da in adäquaten Positionen ist. Und vielleicht auch noch mal als kleine...

Falls du das bestätigen kannst, man muss ja immer erst in Vorleistung gehen, bis dann irgendwann so ein Unternehmen wie Spiral oder jetzt hier das MIT kommt und sagt, okay, wir geben jemandem wie dem Sharlatan mal einen Grant. Weil der halt erst mal was geliefert hat an der Stelle und nicht jetzt irgendwie, okay, ich hab hier eine Idee oder ich möchte das gerne machen, aber ich habe noch nichts abgeliefert und ok, jetzt hier kriegst du erstmal für zwei Jahre eine Finanzierung.

Ich denke, es wird eher ersteres sein, oder? Ja, ich kenne eigentlich keine anderen Bitcoin-Core-Entwickler, die einfach aus dem Nichts vollfinanziert auf dem Projekt aufgetaucht sind. Das gibt es eigentlich nicht, nein.

Gut, dann sind wir ja eigentlich schon beim Anfang dieses Themas. Wir sprachen jetzt immer von Bitcoin Core. Jetzt ist ja im Rahmen dieser OP-Return-Debatte, die ja einige Wellen geschlagen hat. Wir wollen das hier nicht weiter ausrollen. Ich glaube, das ist nicht heute Thema. Aber im Rahmen dieser Debatte rund um OP-Return gab es ja immer wieder den Ruf danach, statt Bitcoin Core eben Bitcoin Nots laufen zu lassen.

Ich würde ganz gerne zum Anfang einmal darüber sprechen, was es denn eigentlich mit diesen alternativen Implementierungen des Bitcoin-Protokolls auf sich hat. Oder vielleicht auch nochmal auseinanderzunehmen, was sind denn verschiedene Implementierungen oder verschiedene Clients von Bitcoin? TheCharlatan, vielleicht kannst du uns da so ein bisschen mal einführen in das Thema. Warum gibt es überhaupt diese alternativen Implementierungen, jetzt sowas wie Bitcoin Core, Nods?

Wenn ich richtig informiert bin, gibt es ja noch LitBitcoin und BitcoinD. Was hat es denn eigentlich damit auf sich? Ja, es hat eigentlich schon mittlerweile eine ziemlich lange Tradition, dass man nebst Bitcoin das ja aus dem ursprünglichen Client, der Satoshi veröffentlicht hat, ähm, ja, weitergeführt wurde. Und du hast es eben schon richtig angedeutet, heutzutage sind so die größeren paar Implementierungen sind natürlich Bitcoin Core, Bitcoin Not, LibBitcoin und BTCD.

Und die alle haben, sagen wir mal, unterschiedliche Argumentationen dafür, was sie jetzt als Alternative genau an den Tisch bringen. Und man muss auch unterscheiden, es gibt zum einen, gibt es Neuimplementierung, die entweder in anderen Programmiersprachen oder von Grund auf neu geschrieben werden. Also keinen Code mit dem ursprünglichen Satoshi-Client teilen.

Und dann gibt es alternative Implementierungen, die den Code von Bitcoin Core weitestgehend wiederverwenden, aber einige kleinere bis größere Veränderungen daran machen. Und das wäre eher die Kategorie Bitcoin-Nods. Genau. betreffen diese, die das dann, diese Neuimplementierung, also die das komplett neu geschrieben haben, die jetzt nicht das...

Da werden wir wahrscheinlich heute im Laufe des Abends auch noch drauf eingehen, weil das, glaub ich, ein zentraler Punkt ist von dem Projekt, wo du dran arbeitest, dass die auch diesen kompletten, das was halt das Relevanteste von Bitcoin eigentlich ist, diesen Konsensmechanismus und all diese Regeln, die wir in diesem Konsens irgendwo verankert haben, haben die dann auch quasi eins zu eins nachgebaut erinnere mich, dass Merck mal gesagt hat, dass dieser Konsensmechanismus super schwierig,

irgendwie wirklich eindeutig zu definieren ist an der Stelle. [HL] Genau, die müssen dann auch eins zu eins nachgebaut werden. Und das ist oft so, dass diese eins zu eins Nachbau nicht unbedingt immer, sagen wir mal, intuitiven Regeln folgt, sondern man muss wirklich, sagen wir mal, die ursprünglichen Bugs, die in der ursprünglichen Satoshi-Implementierung drin waren, dann natürlich auch Bug für Bug, wie man das ausdrückt, neu implementieren. Und das kann tricky sein.

Also, da läuft man manchmal in Probleme rein, wo man halt irgendein RAM-Problem nicht genau berücksichtigt, und dann können sich Fehler einschleichen, und haben sich in der Vergangenheit in diesen alternativen Implementierungen auch schon eingeschlichen, die im schlimmsten Fall dazu führen, dass die alternativen Implementierungen einen Hard-Fork machen, also einen Block, der valide ist, nicht akzeptieren. Das war nochmal wichtig, den letzten Satz.

Wir hatten jetzt irgendwie darüber gesprochen, da muss jetzt irgendwie der Konsens nachgebaut werden. Was heißt es denn eigentlich, den Konsens nachzubauen?

Es geht darum, dass alle Implementierungen, beziehungsweise alle Nodes, die dem Bitcoin-Netzwerk anhängen und folgen, dass sie weiterhin auf derselben Kette weiter aufbauen, sodass es halt nicht vorkommt, dass einer der verschiedenen Implementierungen von Bitcoin Core einen eigentlich gültigen Block, die Frage ist natürlich nach nach wessen Regeln ist er jetzt gültig, nicht mehr anerkennen würden.

Darum geht es im Grunde. Und der Block, also da sind, das heißt die Transaktionen darin müssen gültig sein, müssen von allen anerkannt werden. Was gibt es noch für Konsensregeln für den Block? Genau, der Proof of Work muss gültig sein. Die Timestamps müssen richtig gesetzt sein. Und der Merkel-Baum, oder die Merkel-Wurzel, die aus dem Merkel-Baum von allen Transaktionen, die in dem Block drin sind, kalkuliert wird, der muss natürlich auch stimmen. Genau.

Also das heißt, wir können gerne auch die englischen Begriffe verwenden. Also der Merkle-Root, das ist ja das, was im Block irgendwie mitgegeben wird. Und das ist, ja, wie sagt man, die Merkle-Ableitung, wie auch immer. Wenn ich es richtig verstehe, geht es ja darum, ich paare immer zwei Transaktionen und bilde daraus ganz vereinfacht gesagt einen Hash. Und aus diesen Hashes bilde ich dann wieder Paare mit den nächstgelegenen Transaktionen.

Und so baue ich ja eben diesen Baum auf, bis ich alle Transaktionen aufsummiert habe und dann den finalen Hash habe. Das ist dieser Merkle Root, richtig? Genau. Okay, das heißt, dass die Bitcoin-Transaktionen in den Blöcken auch die gleiche Reihenfolge haben müssen. Muss ja so sein, sonst kann ja nicht der selbe Hash-By rauskommen. Ja. Ja, okay. Okay, genau. Und das ist die eigentliche Kernherausforderung. Also wenn wir jetzt über alternative Implementierung sprechen müssen.

Wir wollen sicherstellen, dass solche Clients wie zum Beispiel mit Bitcoin Nots oder LibBitcoin, dass die auch einem gültigen Block zustimmen. Also dass sie den auch an ihre Blockchain dranhängen und die Kette somit weiterbauen. Genau. Genau. Und alternativ auch nicht einen ungültigen Block als gültig annehmen. Okay. Genau.

Okay, was mir noch nicht ganz klar ist, was ist denn die Motivation von Leuten, die jetzt sagen, hey, wir wollen nicht Bitcoin Core benutzen, sondern wir wollen eine alternative Implementierung haben? Also was könnte der Grund dafür sein, dass ich mich dafür entscheide, eine alternative Implementierung zu Bitcoin Core zu entwickeln oder zu betreiben? Ja, also ich glaube, am besten diskutieren wir gleich mal die drei Alternativen, die wir jetzt bisher angesprochen haben. Also angefangen bei BTCD.

Das ist eine Neuimplementierung, die in der Programmiersprache Go geschrieben wurde. Und von dem, was ich über das Projekt bisher erfahren habe, ist der Hauptanreiz, dass die Implementierung garantiert, dass das Go-Tooling, das Sie durch diese Implementierung zur Verfügung gestellt haben, in ihrer Umgebung von anderen Go-Programmen, wie zum Beispiel LND von Lightning Labs, wiederverwendbar ist.

Und dazu gehören auch, dazu gehören auch Schnittstellen, die Bitcoin Core selber zum Teil nicht eins zu eins implementieren kann. Genau. Also der Clou ist, Sie können Datenstrukturen, die Sie in BTC-D definiert haben, in LND wiederverwenden.

Das bedeutet, dass man das auf einer anderen Programmiersprache, auf einer anderen Plattform in dem Sinne jetzt dann auch hochgezogen hat und dadurch einfacher neue Anwendungen darauf schreiben kann, als jetzt auf diesem sehr klassischen und schwerfälligen C++-Kern, wo dann Bitcoin Core jetzt an der Stelle draufläuft und das dann entsprechend an Bitschnittstellen noch besser anbinden kann. Verstehen wir das richtig? Ja, genau. Genau.

Ja. Also, das ist der Clou bei, sagen wir mal, diesen Neuimplementierungen, die halt sprachspezifisch sind. Mhm. Dann einer ähnlichen Philosophie folgt LibBitcoin. Da geht's auch darum, dass das Tooling, das Bitcoin Core zur Verfügung stellt, im Sinne von, wie man genau auf die internen Datenstrukturen zugreift, und wie wiederverwendbar der interne Code von Bitcoin Core für andere Programme ist.

Und deswegen wurde LibBitcoin so geschrieben, dass der Code extrem modular ist, Heißt, es gibt einzelne Module, die man in anderen Projekten relativ einfach wieder benutzen kann. Also zum Beispiel ein Wallet oder eine Datenbank, die bessere Anbindungen für Wallets garantiert. Oder auch Möglichkeiten, um Bitcoin Script besser zu debuggen. Also sozusagen die Regeln, die interessantere Transaktionskompositionen ermöglichen, zu entwickeln und zu untersuchen.

Und in welcher Programmiersprache ist LibBitcoin geschrieben? LibBitcoin ist auch ein C++. Ah, ok. Also selbe Programmiersprache wie bei Bitcoin Core, aber gehört jetzt zur Klasse der alternativen Bitcoin-Implementierung, die quasi den Code von Grund auf neu geschrieben haben. Genau, von Grund auf neu geschrieben und der Philosophie folgend, dass es maximal modular sein sollte, maximal wiederverwendbar von anderen Projekten.

Okay, super. Ich glaube, das habe ich schon soweit verstanden. Dann die Frage nach Bitcoin Nots. Was machen die? Genau. Bitcoin Nots ist ein sogenannter Code Fork von Bitcoin Core. Dort geht es eigentlich nur darum, bestimmte Features, die im Bitcoin Core zu kontrovers sind, oder nicht unbedingt erwünscht werden von allen Entwicklern, als Alternativimplementierung zur Verfügung zu stellen.

Also es hat bestimmte Features, die in Bitcoin Core entweder abgelehnt wurden, oder zu lange brauchten, bis sie schlussendlich implementiert oder released wurden. Das heißt, wir haben in manchen Stellen, also bisher ist glaube ich, Bitcoin hat es jetzt gerade in dieser Op-return-Debatte ja immer so in persona von seinem Entwickler immer aufgetreten, dass die gewissen Dinge halt eher einschränken beziehungsweise eingeschränkt lassen,

also eher, sage ich mal, limitieren in irgendeiner Form. Aber jetzt hast du gerade als Beispiel angeführt, dass da auch Features drin sind, die es in Bitcoin Core vielleicht in dem Sinne noch nicht gibt oder nie geben wird. Who knows? Ist ja auch dann interessant, weil das dann ja dann auch dann von diesem Projekt komplett dann alleinstehend dann implementiert werden muss und vielleicht dann aber auch dann wieder als Basis dann für Bitcoin Core irgendwann dienen könnte.

Ja, das könnte man durchaus so sehen. Ich glaube, es gibt jetzt nicht unbedingt ein Feature, wo man sagen könnte, okay, Bitcoin Nods dient als Testlauf dafür, wie es dann später in Bitcoin Core aussehen könnte. Da ist mir in der Richtung nichts bekannt.

Aber im Sinne von Features, die jetzt mal abgesehen von der Einschränkungen, den Einschränkungen des Mempools, oder halt die aktuelle Mempool-Filter-Debatte, gibt's Features, die zum Beispiel den Nutzer dazu anregen, öfters seine Nodes zu updaten, Und das ist jetzt in Bitcoin Core selber zu kontrovers, aber solche Sachen kann man dann natürlich in alternativen Implementierungen leicht implementieren und auch so umsetzen. Habe ich das richtig verstanden?

Also sagst du, dass Bitcoin Nods von seinen Nutzern öfter erwartet, dass sie ein Update machen? Öfter als es im Bitcoin Core gefordert ist? Ja, genau. Also per Default erwartet BitcoinNOTS, dass man zwischen ein und zwei Jahren die Software updatet. Und was passiert, wenn ich das nicht tue? Also wenn ich jetzt meinen BitcoinNOTS zwei Jahre lang nicht update?

Also es gibt eine Option, die bei Startup immer gesetzt ist, und wenn sie gesetzt ist, was der Default ist, dann werden Blöcke ab einer bestimmten Zeit, also zwischen 1 und 2 Jahren, nicht mehr akzeptiert. Das heißt, die Node bleibt einfach bei einem bestimmten Block stehen. Okay, mir erschließt sich noch nicht so ganz, warum BitcoinNutz das von seinen Nutzern fordert. Also was ist der praktische Grund dafür, das so zu implementieren?

Das ist natürlich eine philosophische Frage, was für eine Update-Kadenz man von seinen dem Nutzer erwarten möchte und wie viel man jetzt wirklich da zu leisten möchte, die Nutzer auf eine Art und Weise dazu anzuregen, auch zu updaten. Die Grundhaltung ist zum einen, dass wenn ein Softfork in dieser Zwischenzeit passiert, dass man dann updaten sollte, weil man nicht mehr sonst den kompletten Konsensusregeln des Netzwerks folgt.

Heißt, man könnte unter Umständen einen Block zugespielt bekommen, der für den Rest des Netzwerks nicht mehr valide ist. Genau. Und zum anderen, und dann geht's natürlich in die Mempool und Filterdebatte rein, dadurch, dass diese neuen Metaprotokolle, zum Beispiel irgendwelche Bilder oder NFTs in die Blockchain einspielen,

Immer auf eine bestimmte Art und Weise Ihre Daten in die Blockchain reinschreiben, muss man natürlich regelmäßig updaten, um diesen neuen Art und Weise entgegenzukommen oder sie halt richtig zu detektieren. Genau.

Okay, das macht es ein bisschen klarer für mich. Es gab vor ein paar Wochen mal eine Folge, in der der Merch beim René vom Blocktrainer Podcast war und da haben sie auch, also vor allem Merch, hat ein bisschen länger über Bitcoin Nutz gesprochen und das, was bei mir so ein bisschen hängen geblieben ist, ich habe es technisch ehrlich gesagt nicht so ganz verstanden, worum es, also wie seine Argumentation war, aber hängen geblieben ist bei mir,

dass Bitcoin Nots irgendwie sehr, sehr viele Patches braucht und dass das halt sehr instabil sein könnte. Kannst du vielleicht mal erklären oder vielleicht können wir an diesem Beispiel von Bitcoin Nots mal erklären, was es denn so schwierig macht, alternative Implementierungen zu bauen, um dann vielleicht zu unserem eigentlichen Thema überzuwechseln?

Ja, bei Bitcoin Nots, wo es sich hier um einen Codefork von Bitcoin Core handelt, müssen Sie regelmäßig auf den aktuellen Stand von Bitcoin Core rebasen, nennt man das in der Git-Sprache, aber wir können es einfach Updaten nennen. Heißt, sie müssen regelmäßig den Code, der Bitcoin Core in der Zwischenzeit geschrieben hat, bei sich ins Projekt reinziehen und den dann irgendwie neu reinintegrieren.

Und das muss man machen, weil wir halt regelmäßig irgendwelche Sicherheitslücken entdecken, Oder halt auch, weil wir die Performance der Node signifikant verbessern. Und da möchte man natürlich nicht zurückbleiben, nur weil man irgendeine alternative Implementierung betreibt. Also Sie sind darauf angewiesen, regelmäßig Bitcoin Core reinzuziehen.

Und die Schwierigkeit dabei kann dann sein, wenn das eigene Patchset das Bitcoin-NOTS unterhält, also die eigenen Veränderungen, die Bitcoin-NOTS von Bitcoin-Core unterscheiden. Wenn diese Veränderungen groß sind und über die Zeit immer mehr und mehr wachsen, dann wird diese regelmäßige Integration komplizierter.

Und es können sich dabei Fehler einschleichen, und es kann auch dazu führen, dass dann der integrierte Code nicht mehr dem ursprünglichen Code entspricht, weil bei der Integration zum Teil dermaßen viele Sachen umgeschrieben werden müssen, dass sich Fehler einschleichen.

Also vielleicht, um das nochmal irgendwie nochmal zusammenzufassen, wie ich das jetzt verstanden habe, wir haben einen Bitcoin Core als Basis, davon gibt es dann einen Fork, der quasi beim initialen Fork eins zu eins noch komplett identisch ist, dann fängt das das Bitcoin-Nodes-Team an, bestimmte Funktionalitäten. Zum Beispiel in einer Funktion ändern sie den Wert von null auf eins, weil sie denken, dass eins an der Stelle der bessere Wert ist als null, das, was es von Bitcoin Core ist.

Dann kommt eine neue Version von Bitcoin Core nach zwei Monaten zum Beispiel. Und dann hat sich an dieser Datei oder an diesem Quellcode, wo dann diese eins ursprünglich dann mal verändert wurde, was geändert. Das heißt, das muss ja dann wieder nachgezogen in jedem Release an der Stelle, so verstehe ich das.

geforderten Projekt gemacht wird, wird ja dann nach jedem mit jeder Iteration oder mit jedem quasi neuen Update, was dann von Bitcoin Core kommt, es immer komplizierter, das irgendwie dann nachzuhalten,

um dann quasi so seinen eigenen Stand dann da aufrecht zu erhalten. Und was natürlich das große Problem an der Stelle ist, Bitcoin Core wurde ja dann mit den Parametern getestet, wie es veröffentlicht wurde und wenn ich davon dann natürlich jetzt dann erstmal ganz viel dann nach dieser Veröffentlichung verändern muss, habe ich ja die ganzen Tests an der Stelle ja auch schon nicht mehr, die dann nicht mehr auf dieser Code-Basis basieren. Genau. Und das sieht man bei Notts spezifisch auch schon.

Sie haben große Mühe damit, das ganze Testsystem, das Bitcoin Core hat, auf Bitcoin Notts abzustimmen. Also viele der Teste laufen bei Bitcoin Notts einfach nicht. Haben nicht auch die anderen alternativen Implementierungen wie LibBitcoin und BTCD diese Herausforderung, dass sie ständig nachziehen müssen, was Bitcoin Core macht? Ich stelle die Frage einfach mal an dich, gebe keine Antwort vor. Solange wir keinen Softfork machen, nicht.

Also es ist wirklich nur beim Softfork, wo sich alle Clients eindeutig einig sein müssen über die Veränderungen. Genau. Ah, okay. Also das ist für mich jetzt eine ganz neue Erkenntnis. Das würde ich ganz gerne nochmal festhalten. Also alternative Implementierungen wie LibBitcoin und BTCD, die die Codebasis komplett neu geschrieben haben, die müssen nur sich an Bitcoin Core angleichen oder nachziehen oder updaten, wenn es zu einem SoftFork kommt.

Also zum Beispiel die Einführung von Taproot war jetzt glaube ich das letzte, was wir gemacht haben. Diesen Soft Fork Tabroot mussten dann BTCD und LibBitcoin nachbauen, damit sie quasi auf demselben Stand sind. Während Bitcoin Notz, weil es einfach ein Fork von Bitcoin Core ist, jegliche Änderungen in Bitcoin Core irgendwie nachziehen muss. Ja, genau.

Okay. Ich meine, sie haben ja den Vorteil, sie müssen es nicht neu schreiben, jetzt in dem Fall Bitcoin-NOTS, aber man muss es trotzdem natürlich bei sich integrieren und dann bereitstellen, damit Bitcoin-NOTS auch Taproot unterstützt. Ja. Okay, cool.

Ich glaube, wir sollten so langsam mal zu deinem Projekt übergehen, auf das ich auch sehr, sehr gespannt bin. Das finde ich sehr spannend. Ich habe das jetzt so verstanden, man könnte versuchen von Bitcoin Core etwas zu leisten, um eine bessere alternative Implementierung zu ermöglichen. Wie genau das und was genau man da

macht, das werden wir uns gleich anschauen. Aber ist das erstmal so richtig? Also geht es unter Anderem gibt es sicherlich noch andere Fragen, aber geht es unter anderem auch darum, um alternative Implementierung zu Bitcoin Core besser möglich zu machen? Ja, also darauf arbeite ich ganz klar hin und ich habe mittlerweile sogar meine eigene alternative Implementierung, die auf meinem Projekt basiert. Okay, sehr schön. Gut, also dann lass uns mal das Kit beim Namen

nennen. Das Ganze firmiert unter dem Stichwort LibBitcoin Kernel oder dem Projekt Bitcoin Kernel Library. Vielleicht müssen wir eins vorweg schicken. Wir haben ja hier schon die alternative Implementierung LibBitcoin genannt gehabt. Aber LibBitcoin Kernel, also die alternative und das Thema LibBitcoin-Kernel haben nichts miteinander zu tun. Weißt du, wie es zu dieser eher unglücklichen Namensgebung kam? Ja, das liegt daran, dass bei Bitcoin Core intern die

verschiedenen Code-Module auch den Präfix "libbitcoin" haben. Also zum Beispiel gibt gibt es ein LibBitcoin Wallet, ein LibBitcoin Node, ein LibBitcoin Common und das wurde aus dieser Namensgebung herausgeboren. Leider wurde dies, bevor ich das Projekt übernommen hatte, gemacht und jetzt kann ich es nicht mehr ändern. Ja, okay, aber ich glaube, damit können wir leben. Wir haben es jetzt mal auseinandergehalten. Wir reden tatsächlich über LibBitcoin Kernel hier in diesem Fall.

Im Grunde geht es ums Kernel und LibBitcoin ist so ein Präfix, den einige Module in Bitcoin Core haben. Genau. Okay. Vielleicht können wir ein bisschen mal in der Historie anfangen. Vielleicht kannst du mal so ein bisschen erzählen, woher kommt diese Idee, seit wann gibt es sie eigentlich, wer hat das initiiert. Ich meine, das Projekt, das hast du ja eben schon in der Einleitung gesagt gehabt, das bestand ja schon, bevor du dich mit Bitcoin Core beschäftigt hast.

>> Ja. Also ursprünglich entstand die Idee, dass man den Konsensuscode von Bitcoin Core in ein separates Modul isoliert. Schon seit 2013. Und zwar wurde das von Corey Fields initiiert. Der geht auch unter dem Handel der Uni auf dem Bitcoin Core Repository. Und das führte zur Entwicklung des ursprünglichen LibBitcoin Konsensus.

Und diese Library hatte aber den Nachteil, oder dieses Modul an Programmiercode, hatte den Nachteil, dass sie nur einen ziemlich beschränkten Teil des Blockvalidierungscodes vom Bitcoin Core beinhaltete. Heißt, man konnte damit nicht einen ganzen Bitcoin-Block validieren, sondern nur überprüfen, ob die Transaktionen korrekte Skripte und korrekte Signaturen haben. Mehr konnte man damit nicht machen.

Und es gab einige alternative Implementierungen von Bitcoin, die diesen LibBitcoin-Konsensus wiederverwendet haben, aber das Projekt verlief sich über die Jahre so ein bisschen, weil es halt diese grundlegende Barriere gab. Also, es war halt einfach zu beschränkt, was dabei zur Verfügung stand.

Und dann vor etwa vier bis fünf Jahren wurde dieses Projekt dann neu aufgegleist mit dem Bitcoin-Körnel-Projekt und das hatte dann explizit das Ziel, wir als Bitcoin-Core möchten unseren kompletten Validierungsprogrammiercode für alternative Implementierungen und auch andere Use Cases, die wir vielleicht heute zum Teil nicht mal genau vorhersehen können, zur Verfügung stellen. Okay, das heißt, es gab schon länger das LibBitcoin-Konsensus-Projekt und dann ist

diese Idee wieder aufgegriffen worden. Du hattest, glaube ich, eben schon mal erwähnt, Carl Dong ist der Name, der das so ein bisschen vorangetrieben hat. Ja, genau. Richtig? Genau, genau. Und daraus ist jetzt, also aus LibBitcoin-Konsensus ist dann, Also das Projekt ist fortgeführt worden, aber unter einem anderen Namen, nämlich "LitBitcoin Kernel". Vielleicht macht es noch mal Sinn, hierzu ein bisschen zu erklären, was heißt das denn jetzt eigentlich?

Was ist so eine Library und warum hat man den Namen "LitBitcoin Kernel" gewählt? Vielleicht hilft es uns, das ein bisschen besser zu verstehen, worum es eigentlich in dem Projekt geht. Ja. Eine Library ist grundsätzlich einfach eine Ansammlung an Programmiercode, die von anderem Programmiercode wiederverwendet werden kann. Heißt, ich kann Funktionalität, die in einem Modul an Features oder Codes zur Verfügung gestellt wird, in einem anderen Modul wiederverwenden. Und, ja, diese Module nennen wir

Libraries. Genau. Und jetzt natürlich die Frage, wieso heißt es denn Körnel? Vielleicht haben die einen oder anderen von euch schon von Betriebssystemkörneln gehört, also zum Beispiel dem Linux-Körnel. Im Prinzip heißt das, dass die Library anders als es sonst bei vielen anderen Libraries üblich ist, einen internen State hat.

Heißt, sie trackt in unserem Fall, okay, das ist die Sequenz an Bitcoin-Blöcken, und an diese Sequenz von Bitcoin-Blöcken, also diesem State, möchte ich jetzt einen weiteren Block ranhängen und validieren. Und weil es eben diesen State gibt, also diesen internen State, an dem wir etwas verändern möchten, nennen wir die Library einen Körner.

Das heißt, der Unterschied zwischen einer regulären Library, die einfach nur auf Funktionalitäten bereitsteht, wie zum Beispiel, okay, weiß ich nicht, addiere mir diese zwei Zahlen zusammen, ich habe zwei Input-Parameter A plus B, Und als Ergebnis kommt c hinten raus, weil das dann addiert wird. Das ist quasi eine Library, die hat jetzt kein Status oder kein State in dem Sinne. Aber einen Kernel in dem Sinne, der hat halt immer einen Zustand, der quasi an ihm angebunden ist.

Und dadurch ist quasi dieser Kernel in dem Sinne aktiv und nicht nur relativ, nicht nur passiv in dem Sinne von dieser Beispiel Additionslibrary an der Stelle. Ja. Und was dazu kommt, weil wir halt diese riesengroße Datenstruktur haben, haben wir nicht die Möglichkeit, alle Operationen im Arbeitsspeicher zu machen. Heißt, wir müssen eine Komponente haben, die auch über das Betriebssystem dann auf den eigentlichen Speicher zugreift, um Blöcke zu lesen, um zu sehen, was das aktuelle UTXO-Set ist.

Also die Menge an noch nicht ausgegebenen Coins ist. Genau. Mhm. Also man versucht im Grunde, die gesamte Validierungslogik aus Bitcoin Core sauber rauszutrennen, sodass man sagen kann, hier, wenn du dieses Paket nimmst, diese Library nimmst, dann hast du quasi ein Tool, ein Werkzeug, um die Validierungslogik in Bitcoin mitzumachen, nachzustellen? Ich weiß gar nicht, was da der richtige Ausdruck ist. Ja, mitzumachen, ich glaube, das wäre der richtige Ausdruck.

Wie kann ich mit dieser Library am Bitcoin-Konsensus mitmachen? Also was macht es denn so schwierig? Ein Außenstehender alleine könnte jetzt sagen, ich kenne doch die Regeln, Das sind A, B, C und D. Da hatten wir eben drüber gesprochen. Wir hatten über den Merkle Root gesprochen, über, dass da gültige Transaktionen drin enthalten sein sollen. Es kann aber jetzt nicht so schwierig sein, das bisschen Validierungslogik da rauszuziehen. Trotzdem geht das Projekt schon über zehn Jahre voran.

Kannst du es uns erklären? Warum ist es so komplex? Ja, zum einen ist der Teufel natürlich im Detail. Und das andere Problem ist, Der Bitcoin Core Code wurde natürlich nicht geschrieben mit dem Hintergedanken, okay, es wird mit der Zeit einige andere alternative Implementierungen geben, die diese Logik eins zu eins irgendwie wiedergeben müssen.

Deshalb schlich es sich über diese Dekade an Entwicklungsarbeit, die im Bitcoin Core reingeschlossen wurde, schlichen sich Verkettungen zwischen verschiedenen Komponenten und Modulen im Code ein, die jetzt nicht unbedingt etwas mit Validierung zu tun hatten. Heißt, man musste wirklich, ja, zwei, drei Jahre an Entwicklungsarbeit nur damit verbringen, klar abzugrenzen, Okay, das hier ist der Validierungscode, und das hier ist der Code, der das Wallet benutzt.

Dies hier wird nur von der Logik benutzt, die das Peer-to-Peer-Netzwerk zur Verfügung stellt. Dies wird vom Bitcoin Core GUI benutzt. Und diese Abgrenzung war tatsächlich schwierig zum Teil. Du sagst "war" sehr schwierig. Man könnte raushören, dass das Projekt jetzt doch einen guten und soliden Stand erreicht hat. Ja, genau. Diese Isolation ist mittlerweile großteils abgeschlossen.

Also das Projekt ist mittlerweile so weit, dass nicht mehr darüber diskutiert wird, was jetzt genau in der Library drin ist und was nicht, und wie man das besser abtrennen sollte, sondern wie die Library letztendlich von externen Projekten benutzt wird. Also was da genau die Schnittstelle sein sollte, und wie sie möglichst ergonomisch für diese anderen Projekte aussehen sollte. Aber vielleicht nochmal so zur, dass man das nochmal rund macht.

Du hattest jetzt beschrieben, das ist jetzt ein fortlaufender Prozess gewesen in den letzten Jahren, das so zu extrahieren. Also ist jetzt diese Abgrenzung in dem Sinne, das ist jetzt alles schon in den ganzen Iterationen, die jetzt dann Bitcoin Core in den letzten Jahren hatte,

immer wieder dann auch so implementiert worden, um auf dieses Ziel hinzuarbeiten. Oder ist das jetzt aktuell noch eher ein theoretisches Konstrukt, wie es in Zukunft gebaut werden könnte, diese Abtrennung dann von diesem Validation Part? Nein, diese Abtrennung ist tatsächlich größtenteils fertig jetzt. Also da wird nicht mehr viel daran gearbeitet, was jetzt genau noch isoliert werden muss.

Es gab jetzt sogar einige Anstöße, um nicht nur das Kernel-Modul intern zu isolieren, sondern es komplett in ein externes Projekt umzuwandeln. Und das funktioniert tatsächlich auch schon. Also man könnte, und vielleicht wird das in einigen Jahren dann auch das tatsächliche Ziel vom Projekt, man könnte Bitcoin Core selber vom Kernel herauslösen, sodass es dann nur noch das Kernel-Modul an sich gibt, außerhalb von Bitcoin Core.

Dass man das dann unabhängig von Bitcoin Core, was jetzt ja die ganzen Funktionalitäten, die wir heute kennen, bereitstellt, auch losgelöst davon betreiben kann. Mit dann einer neuen Software, die vielleicht dann diese Funktionalität einfach nur so als Bereitstellung von Funktionalität an der Stelle dann verwendet, um da halt diesen Konsensus dann nutzen zu können. Und dann baue ich darauf irgendwas Neues. Genau. Genau.

Ich glaube, da sind wir jetzt ja auch schon direkt bei dem nächsten Punkt. diesen Zugriff dann, wenn du jetzt gesagt hast, dieser Umbau von dem eigentlichen Kernel hat schon stattgefunden, dass das schon isoliert an der Stelle ist. Jetzt ist natürlich dann nur die Frage, so wie ich's verstanden habe, wie kommen denn jetzt alternative Implementierungen, wie kommen neue Entwickler, die das vielleicht in Zukunft nutzen wollen?

Die müssen ja irgendwie dann auch auf diesen Kernel zugreifen können in einer, sag ich mal, bequemen Art und Weise. Und da hab ich jetzt verstanden, da gibt es jetzt dann diesen Bitcoin-Kernel, diese API, die da jetzt gebaut wird, quasi als Vorschlag aktuell rumgeistert. Vielleicht kannst du da mal einen kurzen Aufschlag zu geben, dann können wir da ja weiter reingehen. Genau, diese API ermöglicht es, externen Projekten und externen Programmen

diese Konsensus oder Validierungslogik wieder zu verwenden. Und API ist in der Hinsicht einfach diese Schnittstelle und wie sie genau designt wurde, um möglichst einfach und vor allem in unserem Fall relevant sicher, ohne dass man irgendwelche neuen Bugs mit der Benutzung der API an sich wieder generieren könnte, implementieren kann. Darf ich noch mal kurz einhaken? Also wir haben jetzt noch ein paar Begriffe aufgebracht, die vielleicht nochmal ein bisschen erklärungsbedürftig sind.

Also wir hatten schon über eine Library gesprochen. Jetzt kommt der Begriff der API oder Schnittstelle. Vielleicht könnt ihr mich mal kurz aufklären oder mich und unsere Zuhörer aufklären, was ist denn eigentlich eine API? Und wenn wir diese Frage geklärt haben, würde mich dann doch nochmal interessieren, mir ist das ganze Zusammenspiel noch nicht so richtig klar geworden.

Also wie hängen jetzt die Library, die API und andere Module, Bausteine im Bitcoin Core oder andere Implementierungen damit zusammen. Wie kann man da irgendwie eine Architektur, ein System bauen, das uns jetzt voranbringt? Ja, du hast es eigentlich schon richtig angesprochen. Also wir haben diese verschiedenen Module in Bitcoin Core, diese verschiedenen Libraries, wie wir sie auch nennen.

Und die müssen irgendwie miteinander, ja, nicht unbedingt kommunizieren können, aber man muss Funktionalität in einer Library von der anderen Library aus ausrufen können. Und… Sorry, können wir da vielleicht ein Beispiel nennen, so dass man sich das mal ein bisschen plastischer vorstellen kann? Also gibt es irgendwie, weiß nicht, jetzt im Peer-to-Peer Teil von Bitcoin, gibt es da etwas, wo wir auf die Validierungslogik zurückgreifen? Ja, natürlich. Wir können das gerne durchspielen. Danke.

Also nehmen wir an, wir haben eine Peer-to-Peer Library und unsere Kernelibrary. Und die Peer-to-Peer-Library möchte jetzt mit dem Blog, den sie über das Peer-to-Peer-Netzwerk empfangen hat, mit der Kernel-Library gerne feststellen, ob dieser Blog valide ist. Und dazu ruft sie eine Funktion in der Kernel-Library auf, also zum Beispiel, wir können sie ValidateBlog nennen, Und sie ruft diese Funktion auf, und kriegt dann als Ergebnis von der Funktion zurück, ob der Block valide war oder nicht.

Also, ob er an die Blockchain RAM baut, und allen Konsensusregeln entspricht, oder ob er entweder komplett nichts mit der Chain zu tun hat, oder irgendeiner bestimmten Validierungsregel nicht entsprochen hat. Und diese Menge an verschiedenen Funktionen, also jetzt in unserem Beispiel diese ValidateBlock-Funktion, diese Menge an potenziellen anderen Funktionen, die es nebst Verdi-Date-Block vielleicht auch noch in der Library gibt. Dies nennen wir die API oder die Schnittstelle zur Library hin.

Also für mich ist ja so eine API ist ja in dem Sinne eigentlich der große Unterschied ist ja in dem Sinne, dass es dokumentiert ist. Also dass man eine Dokumentation oder eine aufbereitete Art und Weise hat, wie man diese bestimmten Funktionalitäten nutzen kann. Also, dass man Schnittstellen halt hat, die vielleicht in irgendwelchen Libraries oder Code-Teilen rumliegen, ist ja dann das eine.

Aber dass das Ganze ja dann auch wirklich so konzipiert worden ist, dass das von extern auch verwendet werden kann. Also, dass da wirklich mit dem Hintergrund, dass das wiederverwendet wird. Und diese API beschreibt ja dann an der Stelle, API steht übrigens an der Stelle für Application Programming Interface, also ist es im Endeffekt eine Schnittstelle, nichts anderes ist es dann.

Das ist ja dann idealerweise gut dokumentiert, dass man in dieser Dokumentation von der API drinsteht und sagt, aha, okay, da gibt es diese Funktion BlockValidate. Und diese BlockValidate erwartet als Übergabewert zum Beispiel einen, weiß ich nicht, einen Bitcoin-Blockobjekt oder so was zum Beispiel und liefert als Rückgabewert dann halt, war oder falsch, an der Stelle, ob die Validierung erfolgreich war oder entsprechend halt nicht.

Dass das Ganze ja entsprechend dann gut dokumentiert aufbereitet ist, dass man als externer Entwickler auch weiß, wie nutze ich denn diese Libraries? Ja, die Dokumentation vor allem bei einer solchen Library, wo halt sehr viel auf dem Spiel steht, dass man sie auch richtig verwendet, ist extrem wichtig. Also da steckte ich bisher sehr viele

Stunden rein. Und nebst guter Dokumentation versucht man bei der Entwicklung dieser Schnittstellen auch auf ein Prinzip zu setzen, was sich "correct by construction" nennt. Übersetzt ist das glaube ich korrekt aufgrund der zugrunde liegenden Konstruktion der API. Aber es ist jetzt ein bisschen verschwurbelt übersetzt. [Herr Antrim lacht] >> Okay, aber ich glaube, ich verstehe, worum es geht. Also es ist der Versuch sicherzustellen, wenn du eine Antwort bekommst, ist diese Antwort richtig,

wie auch immer sie lautet. In dem Beispiel von "Validate Block", "Block ist gültig" oder "Block ist ungültig", diese beiden Aussagen sind einfach richtig.

Genau. Und ferner geht es auch darum, dass wenn es jetzt zum Beispiel bei "Block validate" Nötig ist, dass der Block, den wir validieren, eine bestimmte zugrunde liegende Struktur haben muss, also ein bestimmtes Format haben muss, dann muss die Library eine separate Funktion zur Verfügung stellen, die zuerst sicherstellt, dass der Block das richtige Format hat, und dann, wenn das korrekt gemacht wurde, dann erst den Blog validiert.

Also, dass sich nicht bei der, ja, vielleicht nutzerkontrollierten Art und Weise, wie jetzt dieser Blog genau formatiert ist, Konsensusfehler einschleichen könnten. Und die, diese Verkettung von Funktionen, dass man wirklich nur einen Weg hat, um etwas zu validieren, also um ein bestimmtes Ergebnis zu erreichen, das nennt man dieses Correct-by-Construction-Prinzip. Also es gibt nur einen korrekten Weg, um diese Validierungsfunktion aufzurufen.

>> TORRENCE BOEHMER: Thorsten, möchtest du nochmal technisch nachschärfen an dieser Stelle? Nö, das passt für mich. Das ist ja die Frage, ob du das verstanden hast jetzt. Ich glaube, ich habe eine ganz gute Vorstellung bekommen. Vielen Dank euch beiden dafür auf jeden Fall.

Lasst es doch mal vielleicht an unsere Zuhörer denken, die jetzt gehört haben, okay, jetzt gibt es da dieses Projekt, der Bitcoin Kernel Library und der Charlatan, der baut jetzt da an dieser Schnittstelle, an der API. Was bringt das denn eigentlich für das gesamte Bitcoin Projekt? Also Was haben wir denn davor, wenn du, Sharlatan, jetzt an diesem Projekt API zur Bitcoin Kernel Library arbeitest? Was kann uns das alles einbringen? Eine ganze Menge an Sachen.

Vielleicht sollte man zuerst sagen, dass Bitcoin Core unmöglich allen Nutzern von Bitcoin gerecht werden kann. Also es wird immer Use Cases und Ansprüche von Nutzern geben, die Bitcoin Core nicht erfüllen kann. Und aus diesen Anforderungen heraus entstehen dann alternative Implementierungen, die, wenn sie nicht eins zu eins den Consensus-Code von Bitcoin Core wiederverwenden, Gefahr laufen, Consensus-Bugs drin zu haben.

Heißt, sie sind darauf angewiesen, Bitcoin Core auf irgendeine Art und Weise wiederzuverwenden. Ein sehr gutes Beispiel dafür ist zum Beispiel das U3XO-Projekt. wo es darum geht, einen Fullnode mit einem viel kleineren Datenabdruck laufen zu lassen. Also anstelle von, ja, hunderten Gigabytes an Daten, die nötig sind, um eine Bitcoin-Fullnode zu betreiben, braucht ein U3XO-Knoten nur wenige Megabytes. Und dieses alternative Datenmodell wurde mittlerweile implementiert.

Sie müssen aber jedoch auch wiederum die Validierungslogik von Bitcoin, Bug für Bug vom Bitcoin Core, neu implementieren. Und wenn Sie stattdessen die Bitcoin Kernel Library verwenden können, müssen Sie das nicht tun. und das wurde jetzt jüngst experimentell vor einigen Wochen von der Utrex O-Implementierung Floresta umgesetzt.

Und das hatte für sie nicht nur die Folge, dass sie jetzt halt viel sicherer damit fahren, weil sie sich keine Gedanken darum mehr machen müssen, aus Versehen Bugs in den Consensus mit eingeschleust zu haben, sondern es war auch 15 mal performanter für Sie, den hochoptimierten Bitcoin Core Code zu benutzen.

Und das kommt dann natürlich beim Endnutzer an und ist vor allem bei einer Implementierung wie Floresta, wo es ja darum geht, einen Fullnode für Geräte zur Verfügung zu stellen, die sehr verminderte Kapabilitäten haben, wie zum Beispiel Handys oder ein Raspberry Pi oder so, die davon extrem profitieren würden. Haben die, wir haben die diesen, den Konsensus dann verwendet, weil das wird ja noch in dem Sinne, das ist ja noch nicht final gemerged an der Stelle.

Haben die das dann aus dem Bitcoin Core Code extrahiert, so wie der jetzt ist? Oder wie haben die das dann dort verwendet? Ja, weil das noch nicht gemerged ist, habe ich aber trotzdem schon ein eigenes Projekt ins Leben gerufen, dass diesen Code bereits zur Verfügung stellt an andere Projekte. Aber halt, ja, nicht vom Hauptprojekt aus, sondern von meiner eigenen Version heraus, die ich selber maintaine. [Siebert]

Und die haben sich dann auf deine Version bezogen und das auf der Basis dann gebaut? Genau. Aber das beinhaltet nur Veränderungen, die nötig sind, um diese Schnittstelle sauber zur Verfügung zu stellen. Also es sind keine Veränderungen an der eigentlichen Logik oder so drin. Sorry, ich hab gerade ein bisschen, ihr habt mich gerade ein bisschen abgehängt. Das habe ich nicht verstanden.

Könnt ihr das nochmal vielleicht für mich zusammenfassen, damit ich wieder den Anschluss kriege? Worum ging es jetzt? Also weil diese Veränderung für die Schnittstelle noch nicht in Bitcoin Core drin ist, habe ich bereits ein paralleles Projekt, das diese Schnittstelle zur Verfügung stellt an andere Projekte. Ah, okay, okay. Das heißt, du hast selber eine alternative Implementierung von Bitcoin gebaut mit deiner Library? Ja, genau. Genau. Ah,

okay, okay. Und das können jetzt so Projekte wie UtrexO können das benutzen für ihre Dinge? Ja. Ah, okay, cool. Okay. Das habe ich mitgenommen und das erste Thema, das schien mir noch größer zu sein als jetzt dieses UtrexO Projekt, ne? Also allgemein würde das ja bedeuten, dass wir sehr schwachbrüstige Endgeräte benutzen können, um validierende Nodes zu sein, richtig? Also das wäre jetzt spezifisch bei Utrex O der Fall. Ah, okay.

Jedoch könnten wir auch andere alternative Implementierungen zur Verfügung stellen oder oder programmieren, die etwas andere Trade-offs in der Art und Weise, wie Bitcoin Core genau Systemressourcen benutzt, während eine Full Node läuft. Und ja, da gibt's einige Sachen, an denen man rumschrauben könnte, um eine alternative Implementierung aufzusetzen, die vielleicht eher auf Bendy's oder Raspberry Pi's zugeschnitten ist.

Du hattest uns im, ja in der Vorbesprechung hattest du uns einen Blogbeitrag von dir mitgeschickt. Den verlinken wir auch gerne in den Shownotes. Und da sprachst du auch unter anderem davon, dass auch Data Science Projekte und Indexer wie ElectRS zum Beispiel eben die Bitcoin Kernel Library sehr gut verwenden könnten. Magst du uns das vielleicht mal erklären, was damit gemeint ist?

Also was sind diese Data Science Projekte oder Indexer, was können Sie denn jetzt auf einmal tun, wenn Sie eine Library, die API zur Library haben? Darum geht es ja jetzt im Grunde. Ja, genau. Es geht darum, dass Sie den Programmiercode der Bitcoin Core benutzt, um die Blöcke und das UTXO-Set auf die Festplatte abzuspeichern, dass Sie diesen Code extern wiederverwenden können.

Und das ist vom Vorteil, weil man zur Zeit bei Bitcoin Core Blöcke und Transaktionsdaten nur über spezifische Schnittstellen, die performance-mäßig ja nicht unbedingt dazu ausgelegt sind, Unmengen an Daten sehr schnell durchzuspeisen. Also, das ist spezifisch das RPC und das REST-Interface, das hierfür oft verwendet wird.

Und der Grundgedanke, wie die Kernel-Library dabei helfen könnte, ist, anstelle, dass man über dieses Bitcoin-Core-eigene REST-Interface geht, liest man die Daten einfach direkt von der Festplatte. Also man muss nicht mehr diesen Umweg über andere Schnittstellen und andere Codierungen gehen, die einiges an Performance rauben, um diese Daten vom Bitcoin-Core abzugreifen und zu analysieren.

Was bedeutet, dass du da mit dieser API relativ nativ dann auch auf einer Hardware-Ebene unterwegs bist oder relativ hardware-nah unterwegs bist, um so dann diese ganzen Zwischenstellen da irgendwie zu überspringen, um da direkt dann an die Block bzw. Chain-Informationen, die dann auf der SSD, auf der Festplatte liegen, dann dran zu kommen? Genau, das wäre dann der Vorteil dieses Kernel Approaches, also dass man wirklich auf der niedrigsten Ebene, die diese Applikation hat, agieren kann.

Also auf den Daten selber.

Ja, Paul, ich weiß nicht, hast du noch ein weiteres, ein weiterer Punkt dazu, sonst können wir vielleicht mal ganz konkret werden und zu dem letzten Punkt kommen, dass du ja tatsächlich auch schon einen Pull-Request für deine API im Bitcoin-Core-Projekt aufgemacht hast.

Und vielleicht willst du noch mal ein bisschen was dazu erzählen, weil wir gerade ja schon wirklich dann auch über diese Schnittstelle im Detail ein bisschen gesprochen haben, die ja im Endeffekt genau dann das liefern wird, was du gerade beschrieben hast, dass man eine hardware-nahe Schnittstelle an der dann halt bekommt, die halt all das ermöglicht wird. Oder wie ist da jetzt der Stand?

Genau. Diese Schnittstelle erlaubt es zum einen hardware-nah diese Daten abzulesen, und zum anderen, dass man mit den Konsensusregeln Blöcke und Transaktionen validieren kann. Und sie wurde jetzt experimentell auch in anderen Programmiersprachen schon zur Verfügung gestellt, also bisher in Rust und in Python, und dort dann auch von anderen Entwicklern schon verwendet.

Also eben wie angesprochen von Floresta, aber auch schon für einige Datenanalysen, und experimentell auch schon, um ein Index schnell aufzubauen für Silent Payments. Und ja, das klingt jetzt alles so, als ob der Anreiz groß wäre, diese Schnittstelle oder diese Kernel-API schnell im Bitcoin Core zu merchen. Das Problem ist natürlich, Bitcoin Core läuft immer sehr konservativ und langsam.

Heißt, es wird wahrscheinlich noch eine Weile dauern, bis genügend Entwickler oder andere Entwickler, die am Bitcoin Core arbeiten, von dieser Veränderung überzeugt genug sind, damit sie auch wirklich reingemerged wird.

Und das sind Diskussionen jetzt nicht unbedingt nur, wie jetzt diese Schnittstelle aussehen soll, sondern es geht auch darum, wie man garantieren kann, dass eine Schnittstelle, die Bitcoin Core wahrscheinlich ja für den Rest der Zeitdauer, wo dieses Projekt existiert, also hoffentlich für die nächsten paar tausend Jahre, auch maintained werden muss. Heißt, es braucht hier wirklich sehr viel Buy-in von allen anderen. Und das ist schwer abzuschätzen, wie viel Zeit das noch kosten wird.

Aber du hattest den Pull-Request ja letztes Jahr noch im August gestellt, soweit ich das hier sehen kann. Aber das wird jetzt quasi kontinuierlich werden da jetzt, dann bekommst du da auch Feedback und das wird dann entsprechend dann auch wieder dann in den Stand eingearbeitet. Oder ist der Pull-Request jetzt in der Stand erstmal so, wie er vor, wie er jetzt im August letztes Jahr war. Und das ist dann erst mal der Stand, der dann jetzt dann hier diskutiert wird.

Und der verändert sich dann auch nicht mehr. Oder wie? Wie funktioniert das jetzt so an der Stelle? Das wurde schon ziemlich überarbeitet. Also da floss schon sehr viel Feedback ein. Ich hoste mittlerweile auch ziemlich komplette Dokumentationen darüber auf meiner Webseite. Das wurde auch auf Feedback der anderen Entwickler hin

dann so gemacht. Was weiterhin für mich sehr spannend bleibt, ist zu sehen, dass obwohl dieser Pull Request noch nicht gemerged wird, wird die Schnittstelle schon von anderen Entwicklern und Projekten benutzt. Und das gibt mir Zuversicht, dass es auf kurz oder lang in Bitcoin-Core landen wird. Man sieht ja offensichtlich, dass da Bedarf für da ist, dass die Leute oder dann halt andere Projekte sich sowas ja auch gerne wünschen würden.

So einen einfachen Zugang zu diesem Thema und bzw. wie du schon gesagt hast, diese ganzen Konsensus-Problematiken, dass man sich über diesen ganzen Kram keine Gedanken mehr machen muss, wenn man eine eigene Software schreiben möchte, die halt Funktionalitäten davon braucht. Ja, und jede Implementierung ist halt komplett davon abhängig, dass es keine Hardcore-Bugs da drin gibt, weil wenn es welche gibt, dann verlieren die Nutzer unter Umständen viel Geld.

Das wollen wir tun, Licht vermeiden. Aber also wenn ich dich so sprechen höre, dann bist du sehr vorsichtig, sehr konservativ in deinen Abschätzungen, wann das denn in Bitcoin reingemerged wird. Das hört sich für mich danach an, als würden da noch ein, zwei, drei Versionen ins Land gehen, bevor die API tatsächlich dann in Bitcoin Core zur Verfügung steht? Ja, aber ich muss klar sagen, ich finde das sehr, sehr gut so.

Und ich arbeite auch am Bitcoin Core, vor allem weil ich diesen Prozess extrem schätze. Und es ist manchmal etwas zermürbend, wenn man halt das Feedback dann zum fünften Mal wieder bekommt, obwohl man es schon durchdiskutiert hatte. Aber es gehört für mich absolut dazu, wenn man am Bitcoin Core arbeitet. Ja, das ging, glaube ich, auch eher in Richtung unserer Zuhörer. Wir sprechen zwar jetzt über dieses Projekt und über die Schnittstelle, aber solche Dinge brauchen in Bitcoin leider Zeit.

Das ist halt einfach so, nur dass man nicht erwartet, okay jetzt in der nächsten Version von Bitcoin Core ist die Schnittstelle zur Verfügung und dann kriegen wir diese ganzen fantastischen Projekte oder noch mehr fantastische Projekte ins Haus geliefert. Thorsten, wie sieht es aus? Hast du noch Fragen an den Scharlatan? Ich glaube wir haben

einen relativ runden Abriss da drin. Vielleicht nochmal ganz kurz jetzt dann um das Thema noch mal abzuschließen jetzt mit dem aktuellen Stand, gibt es noch größere Meilensteine, die jetzt aktuell noch irgendwie der API aus deiner Sicht irgendwie noch fehlen oder ist das jetzt, wenn du sagst, andere Projekte verwenden das ja schon, dass da jetzt gerade von der Grundfunktionalität eigentlich jetzt soweit schon alles dann drin

ist? Oder fehlt da noch irgendwie was, wo du sagst, okay, das muss auf jeden Fall noch mit rein oder wie ist da der stand im grunde denke ich ist alles für eine erste version da drin und ich glaube spiegelt sich auch in dem wieder wie die library bisher von anderen bereits verwendet wurde. Also habe ich eigentlich kein Feedback gehalten, dass ja, ein bestimmtes Feature noch fehlt oder eine bestimmte Funktion auch auf diese oder diese Art und Weise dazugefügt werden müsste.

Es sind dann eher Sachen wie der Aufbau und wie man können. Also Feinarbeiten an der Stelle ja. Ja.

Cool. Mit Blick auf die Uhr, wir haben schon über eine Stunde miteinander gesprochen. Also erstmal vielen, vielen Dank, Sharnatan, dass du uns besucht hast und mit uns über dieses echt spannende Thema gesprochen hast. Also ich habe einiges mitgenommen. Ich habe gelernt, dass es unterscheidende Merkmale zwischen den verschiedenen Bitcoin-Implementierungen gibt. Also BTCD und LibBitcoin sind Implementierungen, die den Code von Grund auf neu geschrieben

haben, während Nods ein Fork von Core ist. War mir bis jetzt noch nicht klar. Wir haben über LibBitcoin-Kernel gesprochen, also den Versuch, die Konsensuslogik aus Bitcoin Core

zu extrahieren und das Ganze in eine eigene Library zu überführen. Dieses Projekt ist, wenn ich es richtig verstanden habe, eigentlich in einem sehr guten Stand, eigentlich so gut abgeschlossen und du arbeitest jetzt in diesem Projekt weiter daran eine Schnittstelle zu eben dieser Bitcoin Kernel Library zur Verfügung zu stellen, die dann ganz viele Anwendungsmöglichkeiten, ich lasse es mal dabei, weil in den Details

habe ich es nicht mehr ganz verstanden, aber ganz viele Anwendungsmöglichkeiten bietet und insofern ein sehr sehr spannendes Projekt ist. Thorsten, möchtest du noch was hinzufügen? Passt für mich. Super. Sehr schön. Vielen Dank. Ja, dann Charlatan, also du arbeitest wirklich Vollzeit an dem Bitcoin-Körnel-Projekt. Gibt es noch irgendwie andere Projekte, wo du involviert bist oder ein Auge drauf hast oder etwas, wo du denkst, hey, das ist super

spannend. Da sollte Node-Signal vielleicht mal eine Folge zu machen. Also ich bin schon sehr auf den Kernel fokussiert zurzeit. Innerhalb von Bitcoin Core arbeite ich auch viel an dem Multiprocess-Projekt. Dabei geht es darum, bestimmte Funktionalitäten von Bitcoin Core in eigene eigenständige Programme umzuwandeln. Also, dass man später ein Wallet-Programm hat, ein GUI-Programm und alles wird zentral von einem Node-Programm gesteuert und überwacht.

Und das Projekt ist vor allem interessant, weil es zum einen diese Isolierung zwischen Wallet, GUI und Node vorantreibt, was das Ganze ein bisschen sicherer macht. Heißt, wenn es irgendein Crashbug in der Wallet gibt, dann stürzt unter Umständen jetzt nicht mehr die Node auch ab, heißt irgendwelche anderen externen Services, die von der Node abhängig sind, können weiterlaufen. Und zum anderen ist es auch interessant, ähnlich wie das Kernel-Projekt, dass es anderen außenstehenden

Projekten erlaubt, sich besser an Bitcoin Core anzuschließen. Also es wird einfacher, andere Datenbanken an Bitcoin Core anzubinden, andere Services, andere Goys an Bitcoin Core anzubinden. Ich finde es sehr spannend.

Das klingt auf jeden Fall spannend. Thorsten, vielleicht können wir das bei uns in unserer internen Planung mal auf die Longlist setzen. Vielleicht können wir ja dazu noch mal sprechen. Auf jeden Fall, Schartan, was wir bestimmt tun werden, ist, dich nochmal einladen, wenn das Projekt Bitcoin Kernel API dann vielleicht in Bitcoin Core gemerged wurde. Vielleicht macht es dann nochmal Sinn, darüber gemeinsam zu sprechen, das vielleicht auch ein bisschen zu feiern.

Wir würden dich auf jeden Fall gerne wieder bei uns als Gast begrüßen dürfen. Das war ein sehr angenehmes Gespräch. Ja, danke. Hat mich mega gefreut. Ich bin auch schon lange ein Node-Signal-Fan. Da geht uns das Herz auf. Danke, danke. Ja, super.

Dann würde ich sagen, achso, vielleicht noch den Value for Value Hinweis, den wir ganz am Ende bringen, den haben wir am Anfang vergessen, aber trotzdem, wenn ihr uns bis hierhin zugehört habt, würden wir uns sehr freuen, wenn ihr uns mit einer kleinen Spende unterstützt. Value for Value ist das Motto. Ihr wisst, wie es geht. Ich würde sagen, focus on the signal, not on the noise. Bis demnächst. Ciao, ciao. Danke, ciao. [Musik]