Nodesignal-Talk - E167 - Bitcoin Core Development

Wir haben uns heute wieder zusammengefunden in einer schönen Dreierrunde und ich habe zwei Nodes bei mir im Netzwerk gefunden. Einmal auf der einen Seite der Jan Paul. Hi. Hi Thorsten, grüß dich. Und wir haben uns den Murch wieder eingeladen. Hallo Murch. Servus. Schön, dass wir dich wieder hier bei uns begrüßen dürfen. Und dadurch, dass du nicht zum ersten Mal bei uns bist, weißt du es natürlich auch, was deine erste Amtshandlung für heute ist und das ist die Blogzeit, die wir brauchen.

Die Blogzeit ist gerade 831.298. Passt. Ja, ist bei mir auch so. Ist auch eine sehr schöne Blogzeit mit 12 bis 220 Satz per vByte. Die Details habe ich nicht, die zeigt meine Node nicht an. Die Range ist durchaus vorhanden. Gut, ja ihr wisst es ganz kurz, wir sind ein Value for Value Podcast. Wir schalten keine Werbung, dafür den regelmäßigen Aufruf. Wenn das, was wir hier machen, euch gefällt, eine kleine Spende wert ist, dann würden wir uns darüber sehr freuen. Das könnt

ihr über das Lightning Netzwerk machen, das könnt ihr online über Paynium machen. Jetzt sind die Fees ja wieder ein bisschen niedriger, da ist das durchaus wieder attraktiver. Die Informationen dazu, wie ihr das machen könnt, findet ihr in den Show Nodes bzw. bei uns auf der Webseite. Und ja, wenn ihr das macht, freut uns das auf jeden Fall sehr. Murch, starten wir ins Thema rein. Was haben wir uns denn

heute vorgenommen bzw. ich frage erstmal Jan-Paul, was wollen wir denn heute machen? Ja, ich wollte ganz gerne mal über das Thema Bitcoin Core Entwicklung sprechen. Also wie wird eigentlich dieses Bitcoin Core entwickelt? Was ist das überhaupt? Genau, das ist noch mal eine gute Frage. Klären wir auch, was ist überhaupt Bitcoin Core. Ich glaube nämlich, dass da einige Missverständnisse unterwegs sind, was die Rolle der Bitcoin Core Entwickler angeht

und der Maintainer und was Bitcoin Core überhaupt erst ist. Und dazu hat sich der Murch bereit erklärt. Es freut mich sehr, Murch, dass du dabei bist, um heute mit uns über das Thema zu sprechen. Freut mich, hier zu sein. Du bist selber auch Core-Entwickler. Kann man das so sagen? Also, Core Contributors sind halt alle Leute, die mal was beigetragen haben zu Bitcoin Core. Insofern, es gibt Firmen oder Organisationen, wo das formell so ist. Jemand, der an Bitcoin Core

arbeitet, ist ein Core-Entwickler oder Core-Contributor. Aber sonst generell ist es eigentlich eher so, dass es ein diffuser Term ist, der nicht näher irgendwie formell definiert ist. Ich weiß von Leuten, die nach ihrer ersten Issue, die sie aufgemacht haben oder einem Pull-Request, wo sie einen Tippfehler in einem Kommentar gefixt haben, sich als Bitcoin Core Contributor bezeichnen. Ich weiß von Leuten, die Vollzeit an Bitcoin Core arbeiten, die sich das Gleiche nennen.

Also, es ist, was du möchtest. Das heißt, was du möchtest. Insofern, ja, ich habe auch schon mal zu Bitcoin Core beigetragen.

Großartig. Deswegen bist du nämlich auch heute hier, um genau diese Fragen zu beantworten. Aber fangen wir doch vielleicht mal, bevor wir so in diese Rollen eingehen, die es so bei Bitcoin Core gibt, erst mal mit der Frage an, was ist denn überhaupt Bitcoin Core und ist Bitcoin Core und Bitcoin das Gleiche? Ist das vielleicht dann auch was komplett Unterschiedliches? Vielleicht einfach erst mal diese Begriffsklärung.

Ja, also Bitcoin ist auch viele Dinge. Ich würde sagen, erst mal, Bitcoin betrifft normalerweise das gesamte Netzwerk. Es gibt natürlich eine Reihe verschiedener Implementierungen von den Bitcoin-Regeln. Ungefähr, ich glaube, 98 Prozent der Nodes, zumindest der Listening Nodes auf dem Netzwerk sind Bitcoin Core. Insofern ist Bitcoin Core sehr relevant, weil im Zweifelsfall, wenn etwas bei Bitcoin Core funktioniert, aber in einer anderen Software nicht, dann läuft das Netzwerk

läuft eben weiter. Wenn in Bitcoin Core etwas nicht funktioniert und in irgendeinem anderen Client aber akzeptiert wird, dann ist halt trotzdem der andere Client wahrscheinlich nicht ausschlaggebend. Einfach, weil so viel vom Bitcoin Netzwerk an Bitcoin Core dranhängt. Einfach selbst andere Software ist häufig gepaart mit einem Bitcoin Core Node als der

Quelle der Wahrheit. Also zum Beispiel, wenn man einen Lightning Node laufen lässt, dann häufig in Kombination mit einem Bitcoin Core Node, der im Hintergrund die Blockchain-Daten mitteilt. Also insofern, ich würde sagen, Bitcoin Core ist zurzeit die Referenzimplementierung der Bitcoin-Regeln. Das ist sie schon immer, in dem Sinne, dass Bitcoin Core sich entwickelt hat aus Satoshis Codebase, die eben damals von Satoshi zur Verfügung gestellt wurde, ist sehr stark

verändert seitdem. Ich glaube, die ursprüngliche Codebase war, glaube ich, so 12.000 Zeilen oder sowas. Wir sind knapp unter 200.000 Zeilen jetzt und ich glaube, irgendwas wie 95 Prozent der Zeilen, die Satoshi geschrieben hat, gibt es nicht mehr. Aber das ist mehr so das Schiff des Tesors. Es ist immer zwischendrin zu jedem Schritt, was das Codebase, das ursprünglich von Satoshi betreut wurde und es ist es immer noch, aber es hat trotzdem fast nichts mehr zu tun mit dem Codebase

von damals. Außer, dass es die gleichen Regeln implementiert. Also vielleicht noch mal zur

Erklärung, was das Schiff des Tesors ist. Das ist ein Beispiel, ein Gedankenexperiment und zwar gibt es eben dieses Schiff des Tesors, das am Strand liegt oder am Hafen liegt und dann wird das Stück für Stück, also Einzelteil für Einzelteil, Planke für Planke, Schraube für Schraube auseinandergenommen, also rausgenommen und durch ein anderes Teil ersetzt, aber genau baugleich, so dass du halt nach einer gewissen Zeit hast du halt das baugleiche Schiff, aber es besteht nicht

mehr aus denselben Teilen. Die Frage ist jetzt, ist es immer noch das Schiff des Tesors? Das ist das Beispiel und ich glaube, das wollte Merti auch zeigen, dass quasi 95 Prozent des Codes von Satoshi nicht mehr im Bitcoin Core enthalten ist, aber es immer noch auf denselben Regeln funktioniert. Also es immer noch dasselbe Schiff ist, auf dem wir alle fahren. Genau.

Ja sehr schön, aber Bitcoin Core ist ein Begriff, der ja nicht von Satoshi gekommen ist, also das ist ja ein Begriff, der sich erst später entwickelt hat oder hat Satoshi schon seine Referenzimplementierung Bitcoin Core genannt? Ich glaube, er hat es einfach nur Bitcoin genannt, oder?

Genau, ursprünglich hieß das Softwareprojekt einfach Bitcoin, das fanden manche Leute dann etwas verwirrend, weil das Netzwerk ja auch Bitcoin heißt und die Währung heißt auch Bitcoin, deswegen wenn dann die Software auch noch Bitcoin heißt, dann wird es langsam schwer zu wissen, was eigentlich gerade gemeint ist. Ursprünglich haben dann manche Leute von dem Satoshi Client gesprochen oder von Bitcoin Qt, weil der Original Release hatte das Qt Framework für die Benutzeroberfläche

verwendet und Bitcoin D als der Daemon, also die Servervariante der Software. Und ich meine, dass es Gavin Andreessen vielleicht war, der Bitcoin Core als Namen vorgeschlagen hat, 2014, 2013 sowas. Und seit dann wurde das Projekt umbenannt zu dem Zeitpunkt. Ich meine, es war noch als Gavin Andreessen Lead Maintainer war und seitdem heißt das Projekt halt so. Da hast du direkt auch schon den perfekten Übergang gerade gemacht,

indem du das Wort Bitcoin Core Lead Maintainer genannt hast. Du hattest gerade eben von dir selber als Contributor gesprochen, der du bist und dann gibt es noch Core Entwickler, ob es die denn gibt, sei jetzt mal dahingestellt, ob Contributor und Entwickler das gleiche ist,

ist jetzt auch mal so. Erst mal egal, aber welche Rollen oder welche Funktionen gibt es denn rund um das Bitcoin Core Projekt, weil du gerade gesagt hast, was ist denn der Unterschied zwischen einem Contributor und einem Maintainer oder vielleicht dann auch dem Lead Maintainer, also wer macht da was? Also wie gesagt, Contributor ist so ein bisschen diffus, weil Contributor sind Leute, die einmal irgendwas am Codebase gemacht haben, die das vielleicht in

ihrer Freizeit mit sehr wenig Insgesamtzeit machen. Es gibt einige, die Vollzeit daran arbeiten und generell gibt es eben ein paar Leute, die quasi aus dem Projekt heraus gewählt sind, um Aufgaben zu übernehmen, die das Projekt eben braucht. Die haben in dem Sinne keine leitende Funktion oder so, sondern die haben eine Aufgabe zu gucken, was eigentlich bereit ist, gemerged zu werden. Die sehen sich Projekte an, sind alle Concerns, ich kann das gar nicht auf Deutsch,

also wurden alle Fragen, die aufgeworfen wurden, schon abgehandelt. Ist dieser Vorschlag, der eben gemerged werden soll, bereit gemerged zu werden, hat es hinreichend Review bekommen und so weiter und die können diesen Merge Button drücken, sodass das eben zu dem Hauptzweig des Codebases hinzugefügt wird und sonst kümmern die sich halt auch um eine ganz andere Reihe von organisatorischen Dingen, wie den Release Schedule zu planen, zu gucken, dass die Release Binaries

hochgeladen und signiert werden, solche Sachen. Aber die haben eben nicht, wie das häufig falsch verstanden wird, in irgendeiner Form eine herausragende leitende Funktion oder sogar irgendwie eine Projektleitung, sondern die kümmern sich darum, dass die anderen Teilnehmer am Projekt ihren Code gemerged kriegen. Also ich kann es nachvollziehen, dass das natürlich Fragen aufwirft, weil es ja schon eine gewisse Torwächterrolle hat, wobei ich dich jetzt aber so verstehen würde,

dass das eher administrativ zu verstehen ist. Also sie schauen eher, also irgendjemand muss halt diesen Merge Button drücken und sie sind es, die diesen Merge Button drücken müssen. Was sind die Voraussetzungen dafür? Okay, dann gibt es jetzt einen Pull Request, der ja entsprechend reviewed ist, sind irgendwie alle Sorgen und Zweifel adressiert worden, kann man das Risiko in Kauf nehmen? Jetzt habe ich aber schon ein paar Sätze gesagt, wo ich sagen würde, da ist aber doch

einiges an Verantwortung, oder? Bei dem Lead-Maintainer. Verantwortung ist sicherlich viel und man sollte natürlich auch erkennen, dass alle Maintainer Vollzeit am Projekt arbeiten, die werden bezahlt, sich Vollzeit mit diesem einen Projekt auseinanderzusetzen. Ich mache noch einen Haufen anderer Sachen nebenher, ich arbeite auch Vollzeit an Bitcoin Sachen, aber eben nicht nur an Bitcoin Core und die Maintainer sind in der Regel eben Leute,

die sich sehr stark auf Bitcoin Core fokussieren. Dementsprechend sind die sehr viel in dem Codebase unterwegs, auch die meisten von ihnen sehr lange schon und dementsprechend eben haben sie, hätten sie auch so Einfluss, selbst wenn sie jetzt nicht diese administrative Rolle übernommen hätten, aber einfach weil sie das Codebase sehr gut kennen, weil ihre Meinung unter den anderen

Projektteilnehmern Gewicht hat, weil wir denken, dass sie wissen, wovon sie reden. Und ja, also in der Regel funktioniert es eben so, dass ein Pull Request, je nachdem wie komplex und kritisch es ist, zwei, vielleicht mal auch fünf Acts bekommt, also Acknowledgements von anderen Entwicklern, dass sie dieses Pull Request für bereit zum Merge halten und in der Regel ist dann einer der Maintainer auch, mindestens einer darunter, dass sie das selbst reviewen, vielleicht auch

erst nachdem genug andere Leute ihren Senf dazu gegeben haben und es für gut befunden haben und dann nachdem sie es selbst reviewt haben auf Qualitätssicherheit und alles andere, dann eben das Merge. Habe ich jetzt eigentlich überhaupt deine Frage beantwortet? Doch, ich denke schon.

Also ich glaube, das ist, es ist halt ein sehr sensibles Gebiet. Also ich zögere so ein bisschen, weil ich mich gerade frage, wie ich jetzt richtig die Frage stelle, weil es gibt ja keine Bitcoin Organisation, also irgendwie eine Firma, eine Struktur, irgendwie eine Hierarchie, ein Machtgefälle in irgendeiner Form, die jetzt irgendwas vorgeben kann. Gleichzeitig muss man sich ja fragen, wie wird denn jemand Lead Maintainer? Also wie kommt es dazu, dass jemand

diese sehr verantwortungsvolle Aufgabe übertragen bekommt? Ist nur zweimal passiert, dementsprechend wissen wir ganz genau, wie das passiert. Ah, okay. Oder dreimal, wenn wir sagen, Satoshi war auch Lead Maintainer. Also Satoshi hat es erfunden. Er hat dann Gavin in einer privaten Nachricht mitgeteilt, dass das Projekt in guten Händen ist. Also vermuten wir mal, falls Gavin uns nicht anlügt,

dass Gavin von Satoshi quasi den Lead Maintainer-Status übertragen bekommen hat. Und Gavin hat dann offiziell den Lead Maintainer-Titel an Vladimir weitergeleitet, als er sich mehr auf Research konzentrieren wollte. Das war 2014, glaube ich. Und Vladimir hat das dann 2014 bis Anfang 2022 gemacht, bis er gesagt hat, dass er genug hat und zurücktritt. Und jetzt haben wir keinen Lead Maintainer mehr. Okay. Das heißt, wir haben jetzt mehrere Core Maintainer. Oder wie habt

ihr das gelöst? Oder wie ist es gelöst worden? Also ganz am Anfang waren Maintainer eigentlich einfach Leute, die häufig an dem Repository gearbeitet hatten und gute Beiträge geleistet hatten, denen man einfach quasi ein hinreichendes Sachverständnis anverhaftete, dass sie Merge-Rechte

haben sollten. Die ersten paar Leute haben einfach von Satoshi Merge-Recht bekommen. Also ich glaube, das war Sirius, also Mati Malmi, Gavin natürlich, ich glaube, TKTM und noch ein paar andere Leute, die halt einfach am Anfang gleich da waren, Dinge getan haben, dann hat er ihnen einfach Merge-Rechte gegeben. Natürlich heißt das nicht, dass die machen können, was sie wollen. Das wird

häufig missverstanden. Wir arbeiten in der Öffentlichkeit. Jede einzelne Sache, die wir am Codebase machen, kann von jedem, der das Codebase anguckt, gesehen, analysiert, beurteilt werden. Das heißt, wenn wir uns darüber unterhalten, was gemerged werden soll, dann passiert das häufig auf GitHub in dem Pull-Request und zum Beispiel für mein letztes Projekt hatte ich über 200 Kommentare, die ich, also die gesamte Unterhaltung mit den Review-Kommentaren und meinen

Antworten darauf und so fort, war über 200 Beiträge in diesem einen Pull-Request. Wenn wir uns über mehr Konzeptionelles unterhalten, dann passiert das vielleicht auf Delving Bitcoin oder auf der Mailing-Liste oder früher auch auf dem Bitcoin Wizards IAC-Channel, die auch alle öffentlich

einsehbar und archiviert sind. Wenn wir, naja, also alles eigentlich, was wir machen, außer wenn wir jetzt direkt mal mit jemandem uns kurzschließen, ein Videogespräch führen, wo wir vielleicht Details abstimmen oder Ideen sammeln oder sonst was, ist halt komplett in der Öffentlichkeit.

Das heißt, wenn irgendein Maintainer irgendwas mergt, was nicht hinreichend reviewed war oder was sogar mehr oder weniger offensichtlich schadhaft war, dann, also Maintainer werden ist eine langfristige, lange Arbeit, wo man erstmal viel Vorarbeit leisten muss und zeigen muss, dass man das Codebase versteht, dass man sinnvolle Arbeit macht. Wenn man dann aber irgendwie

Scheiße treibt, dann ist man ruckzuck weg. Das haben wir auch ein einziges Mal gesehen und zwar Gavin Andreessen hat auf einer Konferenz Craig Wright als sehr wahrscheinlich die gleiche Person, die Satoshi ist, bezeichnet und da war eben die Sorge groß, dass er zum Beispiel jemanden wie Craig Wright die Maintainer-Rechte geben würde, also das Codebase übertragen würde und nicht, dass derjenige dann zum Beispiel einen Release hätte machen können, den irgendjemand akzeptiert

hätte oder sowas. Also das hätte halt einen Haufen Arbeit für andere Leute machen können, wenn er zum Beispiel alle anderen aus dem Codebase ausgesperrt hätte. Also nicht nur das Codebase, vom Codebase gibt es ja zigtausende Kopien, das ist nicht das große Problem. Das große Problem ist, dass wir fast 30.000 Issues und Pull Requests mit hunderten von Kommentaren auf

dem GitHub-Repository haben. Die werden natürlich auch schon gespiegelt und wir haben Kopien davon, aber einfach das wieder einzupflegen, irgendwo anders, dass man damit interagieren kann oder das dann halt nur als Archiv zu haben, in dem man suchen kann, aber alles neu schreiben, wo man die Diskussion weiterführt, würde so ein Projekt natürlich viel Arbeit und Stunden kosten.

Dann hatten sich damals eben viele Bitcoin Core Contributors zusammen entschieden, dass vielleicht zu der Zeit, wo Gavin Andreessen eh schon aktiv nicht mehr am Codebase arbeitete, er auch keine Maintainer-Rechte haben sollte, weil wer weiß, was er damit jetzt macht. Und dann hat man ihm die weggenommen. Und nachdem er dann halt eigentlich auch nicht aktiv war, hat man sie ja ihm auch nicht mehr zurückgegeben danach.

Du hast jetzt schon ziemlich viel immer von diesem Review-Prozess gesprochen. Ich weiß nicht, ob wir da jetzt schon reingehen sollten. Ich wette, wir werden uns für später auf jeden Fall noch so mal, dass wir mal so exemplarisch mal so durch diesen Merch hatten, eine Idee und möchte das gerne mit Bitcoin Core einbringen. Was passiert als erstes und so was? Das können wir gleich gerne machen. Aber vielleicht können wir erst mal ein bisschen noch so auf diese Reviewer-Funktion

im GitHub sprechen. Was machen die Leute? Was haben die zu tun? Was sollten sie tun? Ist das ein standardisierter Prozess oder macht da jeder, jeder so, wie er das für richtig hält? Ja, also das ist kein standardisierter Prozess. Es gibt so ein paar Gebrauchsmuster vielleicht. Sag es auf Englisch, wir versuchen es zu übersetzen. Ich sage noch mal zu meiner Verteidigung, ich lebe jetzt seit fast sieben Jahren in

den USA und ich arbeite die ganze Zeit in Englisch natürlich. Und gerade, wenn man dann über so sein Tagesgeschäft in einer anderen Sprache plötzlich spricht, ist das manchmal schwierig. Also die Reviewer verwenden zum Beispiel so Kürzel wie "ack" oder "nack" oder so was, um eben mitzuteilen, dass, also zum Beispiel ein Concept-Ack würde mitteilen, dass man konzeptionell die Idee gut findet, aber man ist noch nicht bereit oder man

unterstützt noch nicht das Mergen dieses Vorschlags. Weiter dann würde man vielleicht sagen "Approach-Ack", also nicht nur finde ich das konzeptionell gut, ich glaube, dass deine Herangehensweise an dieses Problem korrekt ist, also ich unterstütze, wie du daran vorgehst, oder eben auch Concept-Ack, aber Approach-Nack. Ich finde die Idee gut, aber sollte anders gemacht werden. Hier ist eine Beschreibung, was ich mir vorstelle zum Beispiel. Generell, glaube ich, fangen wir an,

wenn jemand ein neues Pull-Request aufmacht, dass wir die Ideen konzeptionell bewerten. Also ist es denn generell etwas, was wir wollen? Löst das ein Problem, das wir haben, oder ist es halt irgendwie Larifari? Wir brauchen halt nicht ein Pull-Request, dass irgendjemand sein Geschmacksmuster reinbringt. Also wir hatten irgendjemanden, der vor einer Weile mal Blacklist in Disallow-List oder sowas umbenennen wollte und sowas. Und das ändert funktional nichts. Da ist halt der Review-Aufwand,

um das überall zu prüfen, wurde das jetzt richtig ersetzt. Da ist der Mehrwert so viel, das ist ein furchtbares Beispiel übrigens, aber der Mehrwert von so einem Pull-Request ist halt nicht hoch genug, dass wir das annehmen konzeptionell. Also selbst wenn was vollkommen korrekt ist, wenn es halt einfach nicht hinreichend viel besser macht oder wichtig genug ist. Wir haben

so einen großen Review-Prozess. Es kann teilweise für ganz kleine Dinge schon Monate dauern, bis irgendwas gemerged wird, einfach weil die Software so viel Geld verwaltet und sicher verwahrt, dass wir lieber fünfmal hingucken, dass wenn etwas nicht hinreichend gut ist, wir das trotzdem

vielleicht ablehnen, auch wenn es vollkommen korrekt ist. Und das ist halt vielleicht so eher die Konzept-Ebene und dann, wenn einige Leute sagen, hey, konzeptionell ist es gut oder aktiv das unterstützen, vielleicht Vorschläge machen, wie es verbessert werden soll oder so, dann geht es eher so ins Detail-Review, wo Leute anfangen zu gucken, wie ist es denn implementiert, ist es sicher, ist es sinnvoll, wie interagiert es mit anderen Teilen vom Codebase, tut es wirklich

nur die Sachen anfassen, die verändert werden muss, um dieses Feature einzusetzen, vermischt es vielleicht zu viele Dinge in einem einzelnen Schritt, kannst du das vielleicht in zwei getrennte Comets aufteilen und so weiter. Und dann vielleicht ganz am Ende kommen noch ein paar, hey, kannst du diesen Kommentar vielleicht ein bisschen klarer gestalten, hier fehlt vielleicht noch dieser Gedanke oder sonst was, also so dieses ganz Detailige, wo nur falls du es jetzt noch mal

änderst, vielleicht kannst du hier noch ein paar Wörter einfügen oder sowas. Und dann ist es generell bereit gemerged zu werden und man fängt dann vielleicht noch mal an, das im IAC Channel ein bisschen breit zu treten, dass man sagt, hey, ich glaube, das ist ziemlich weit, vielleicht, falls es dich interessiert, kannst du mal drauf gucken oder so. Und irgendwann, wenn die Sterne richtig stehen und ein Maintainer Zeit hat, sich das auch zu reviewen, dann drückt er vielleicht auf den Knopf.

Jetzt hast du mehrfach die Begriffe "ACK" und "NACK" verwendet, vielleicht können wir die für unsere Zuhörer noch mal ganz kurz erklären, für die, die es nicht kennen sollten. Ja, also ich glaube, es ist kurz für Acknowledgement und was es eben bedeuten soll, ist, ich finde diese Änderung gut und unterstütze, dass es so gemerged wird, wie es ist. Also einfach nur die drei Buchstaben "ACK" oder "NACK" eben, um die Verneinung dessen auszudrücken, das hier ist

nicht gut, das sollte nicht gemerged werden. Generell fungieren wir mit "Rough Consensus" und das ist, glaube ich, auch noch so ein diffuses Konzept, der jetzt häufig falsch verstanden wird. "Rough Consensus" heißt, dass alle Kommentare und Bedenken adressiert werden müssen. Also, es muss darüber geredet worden sein. Es heißt nicht unbedingt, dass man wirklich alle Bedenken

und Kommentare umsetzen muss. Also zum Beispiel kann es sein, dass fünf Leute "NACK" auf einem Pull-Request posten, aber es trotzdem gemerged wird, weil eben die Gründe, aus denen sie gegen dieses Pull-Request sind, nicht für stichhaltig befunden werden von denen, die aktiv daran

arbeiten, die dazu beitragen oder das evaluieren. Also die Aufgabe der Maintainer ist es eben jetzt festzustellen, ist etwas bereit, technisch hinreichend reif gemerged zu werden und gibt das "Rough Consensus" dafür, also ist Unterstützung unter der Entwickler-Community, die zur Bitcoin

Core beiträgt, vorhanden, um es zu mergen. Und ich sage jetzt bewusst, die Entwickler-Community, wenn dann halt mal wieder 15 Leute von Twitter durchrollen und 15 "NACK" drauf schreiben, aber eigentlich überhaupt keine Ahnung haben, wo es für uns geht und auch keinen Grund dafür angeben, dann wird das halt vollkommen ignoriert. Ganz kurz, "Rough Consensus", da packen wir euch einen Artikel in die Show Nodes, der auf "Dalvin Bitcoin" erschienen ist, ich glaube im Januar,

von "Rirden Code", mir sagt der Name nichts. Den fand ich aber recht aufschlussreich, den Artikel, den kann man sich mal durchlesen. Das bezieht sich übrigens auf RFC 7282 von IETF, die haben diesen "Rough Consensus" nämlich eingeführt. Ja, da wäre jetzt dann die Frage,

wie wird man denn, beziehungsweise wir haben jetzt über ein paar von diesen Rollen gesprochen und wie wird man das denn? Ich meine, du hattest jetzt gesagt, man muss sich im Zweifelsfall irgendwie engagieren, man muss sich irgendwie eine Reputation aufbauen, so habe ich es verstanden, in irgendeiner Form, um zumindest dann irgendwo nachher in diesen erlesenen Kreis von den Maintainern zu kommen. Ja, kannst du da vielleicht noch irgendwie was zu sagen?

Ja, also ich würde sagen, dass wir versuchen, ein meritokratisches Projekt zu sein. Es ist immer schwierig, also es ist nicht erst rein nur das. Natürlich, sobald mehr als drei Leute in einem Raum sind, gibt es Leute, die besser miteinander können und weniger gut. Das heißt, man hat vielleicht überlappende Interessen, man arbeitet an einem gemeinsamen Projekt zusammen, das heißt, man reviewt vielleicht eher mal das, was einen eh schon interessiert und wenn jemand halt gerade

was Interessantes macht, dann kriegt das viel Aufmerksamkeit. Wenn man generell häufig und gerne zusammenarbeitet mit jemand, dann weiß man eben, woran die arbeitet, hat vielleicht leichter Zugang zu diesem Review oder Projekt, um eben mal drauf zu gucken, ob das erreicht, was es verspricht

oder... Und was man eben da ganz viel braucht, ist Frustrationstoleranz und Geduld, weil, wie zum Beispiel, also ich habe es ja schon zweimal erwähnt, mein CoinGrinder Pull Request wurde jetzt gerade am Samstag vor zehn Tagen gemerged und das war offen seit Juli 2023, die Fees waren sehr hoch, also habe ich einen CoinSelection Algorithmus implementiert, der eben tatsächlich das Inputset mit dem minimalen Gewicht sucht, um eben die kleinstmögliche Transaktion zu bauen bei hohen

Feerates. Das hätte super gut geholfen bei den extrem hohen Feerates, 300 bis 600 Zeitsperiode, die man im Sommer und Herbst gesehen hat, aber leider ist es eben erst jetzt gemerged worden und am Ende waren es halt irgendwie über 200 Kommentare, die auf dem Pull Request waren, es wurde nochmal ein zweiter Phasetest hinzugefügt, es sind noch ein paar Optimierungen hinzugefügt worden und am Ende sind es halt 15 Comments, 700 Zeilen geändert am Codebase,

davon 200 Zeilen Kommentare, 400 Zeilentests und 150 Zeilen oder so sind der eigentliche Code. Und über jede einzelne Zeile wurde, okay, vielleicht nicht jede, aber fast jede wurde halt diskutiert, bis alle glücklich waren oder hinreichend glücklich. Und im Grunde genommen, also wer kann Bitcoin Core Contributor werden? Am besten Collabs, wenn man irgendwie schon selbst die Software verwendet und irgendein Problem hat, das einen nervt und das lösen möchte und dann

einfach damit anfängt. Also wenn man selbst sein eigener Endkunde ist und eben klar definieren kann, was man eigentlich versucht, welches Problem man versucht zu lösen, dann hat man meistens schon mal einen Fuß im Sattel und dann braucht es noch ein bisschen langen Atem. Man muss, ich würde sagen, relativ gut getesteten Code schreiben, man muss sich ein bisschen an die Richtlinien halten, wie eben der Code aussehen soll im Bitcoin Core Repository. Das ist sicherlich schwierig,

wenn man das erste Mal reinguckt. Das ist auch ein Codebase, das halt 15 Jahre lang gewachsen ist, das heißt, es gibt diverse Anachronismen und auch einfach Dinge, die von Anfang an komisch waren, die man nicht ändern kann, weil das halt sonst Konsensusprobleme erzeugen würde. Zum Beispiel die Endian S, also danke Satoshi. Naja, jedenfalls, wenn man ein Contributor werden möchte, dann ist

vielleicht Reviewer das Einfachste. Man sucht sich einfach ein Pull Request, das man interessant findet, kommt vielleicht mal zu dem Bitcoin Core Review Club, der einmal im Monat mittwochs und donnerstags abgehandelt wird und dann kann man mit anderen Leuten sich ein Pull Request angucken.

Man bekommt sozusagen eine Führung durch ein Pull Request von jemandem, der sich damit auseinandergesetzt hat, kann aber vorher selbst so sich ein bisschen einarbeiten anhand von Fragen, die zur Verfügung gestellt wurden und dann einfach mal reinstürzen, sich Sachen angucken, anfangen, das Codebase ein bisschen zu verstehen und dann, wenn man selbst was schreiben will, vielleicht ein eigenes Problem lösen. Okay, aber das hat ja jetzt den Prozess beschrieben,

wenn wir jetzt irgendwie eine relativ einfache Änderung in Bitcoin Core reinholen wollen, aber da gibt es natürlich auch große Änderungen, die berühmten Konsensänderungen, die da immer mal wieder im Raum stehen. Kannst du vielleicht mal auseinandernehmen, also wann ist es eine Konsensänderung und wann ist es eher etwas anderes, irgendwie ein Change Request oder ein Pull Request, der etwas, eine Kleinigkeit ändert

oder verbessert, der aber jetzt keine Konsensänderung nach sich zieht. Wo ist da so der grundlegende Unterschied? Ich würde sagen, der grundlegende Unterschied ist, Konsensregeln betreffen immer Blockakzeptanz, also wird ein Block als valide evaluiert oder nicht von dem Node und wenn man eben die Grenzen dessen, was ein Bitcoin Node akzeptieren würde oder nicht akzeptieren würde, ändert, dann hat man eine Konsensänderung. Es gibt ein paar verwandte

Regelsysteme, es gibt zum Beispiel die Mempool Policy, das betrifft nur Bitcoin Core. Was eben Bitcoin Core akzeptieren wird, um es in seinem sozusagen Kurzzeitgedächtnis für unbestätigte Transaktionen aufzunehmen, das sind Regeln für Transaktionen, die sind größtenteils noch strenger als die Konsensregeln, aber das betrifft ja nur Bitcoin Core. Was akzeptiert Bitcoin Core in seinem Mempool und andere Bitcoin Implementierungen sind da teilweise anders konfiguriert, teilweise

lassen sie mehr oder weniger zu. Und dann gibt es noch Netzwerkregeln oder so Sachen, die eben das Peer-to-Peer-Netzwerk betreffen. Das sind auch keine Konsensregeln, weil es nicht verändert, was eben im Block dann später akzeptiert wird, aber das hat natürlich auch große Tragweite dahingehend, wie das Netz funktioniert, was man auf dem Netz schicken kann, ob vielleicht sich

verschiedene Implementierungen im Netzwerk segregieren und so weiter. Also es gibt viele verschiedene Dinge, die emergente Effekte haben können darüber, wie das Peer-to-Peer-Netzwerk

funktioniert, selbst wenn es ja nicht mal Konsensregeln sind. Und sobald es eben an diese Dinge geht, wo entweder es verschiedene andere Implementierungen mit betrifft, zum Beispiel, wenn man eben die Mempool-Policy verändert von Bitcoin Core, dann betrifft es Lightning Nodes, die dranhängen und davon abhängig sind, dass sie ihre Commitment-Transaktionen zum Beispiel zeitnah in das Bitcoin-Netzwerk absondern können. Oder die Netzwerk-Akzeptanzregeln, wie zum Beispiel,

dass ein Block eben, der Timestamp darf nicht mehr als zwei Stunden in der Zukunft liegen. Das ist keine Konsensusregel, aber das ist ein Implementierungsdetail von Bitcoin Core, das trotzdem sehr wichtig ist, damit das Netzwerk sinnvoll funktioniert. Jedenfalls, wenn man anfängt, mit solchen Regeln zu interagieren oder die zu verändern, dann fangen Leute an, ganz, ganz genau

hinzugucken. Wenn man sich zum Beispiel anguckt für Tabroot, da hat AJ und andere haben einen Review-Club organisiert, nur für Tabroot und ich glaube, am Ende haben 150 Leute teilgenommen, sicherlich viele von denen zum ersten Mal wirklich viel auf Bitcoin Core und vor allem auch Konsensus Code geguckt. Aber wenn dann eben so große Änderungen an den Konsensusregeln gemacht

werden, dann sind plötzlich ganz, ganz viele Leute sehr besorgt und gucken genau hin. Wenn man dagegen zum Beispiel nur irgendwas ändern möchte, wie die Benutzeroberfläche aussieht in Bitcoin Core und das betrifft niemanden außer die GUI-Nutzer von Bitcoin Core und da ist jetzt irgendwo die Fee Rate mit einem Zeichen mehr Präzision dargestellt oder sonst was,

dann war das eine Option, um die Präzision zu ändern. Dann ist das was ganz anderes, dann gucken sich das halt die Leute an, die die GUI interessant finden und da reicht vielleicht dann auch einer, der drauf guckt und sagt, ja das schaut gut aus oder ein Tippfehler wird repariert. Das tut ein Maintainer vielleicht dann einfach gleich, zieht richtig aus, ist gemerged. Wie sieht denn so ein typischer Weg aus von "Merge hat eine Idee" zu "Die Sache,

die Fieberechnung von Merge wird gemerged". Das ist irgendwie ein witziges Wort. Um das nochmal nachzuvollziehen, das was du gemacht hast, war jetzt ja auch keine Konsensusänderung, es war, wie würdest du das einschätzen, war es eine kleine Änderung, war es aber schon eine relevante Änderung für den Bitcoin, den Core-Client. Wahrscheinlich eher sowas in die Richtung, also so wie das Netzwerk dann auch oder wie beziehungsweise Netzwerkteilnehmer über Bitcoin

Core über die Fees informiert werden. Das ist ja schon relevant auch für, weiß ich nicht, im Peripher irgendwie, wenn Lightning, das was du eben als Beispiel gemacht hast, wenn Lightning Nodes ihre Commitment Transaktionen zetteln wollen, da müssen sie ja auch wahrscheinlich die Fees entsprechend richtig berechnen können. Okay, ich glaube wir vermischen gerade ein paar

Sachen. Also ich hatte das Beispiel für eine Mempool-Policy-Änderung und dann hatten wir die erhöhte Präzision in der Benutzeroberfläche und mein Ding selbst war einfach nur ein Coin Selection Algorithmus, den ich hinzugefügt habe, also eine neue Methode wie die Bitcoin Core Wallet ihre eigenen Inputs für Transaktionen wählt. Also meine Änderung zum Beispiel hat nichts mit

Konsensus zu tun, überhaupt nichts. Es betrifft nicht mal irgendwie verschiedene Nodes, sondern derjenige, der diese neue Version von Bitcoin Core verwendet in seiner Wallet und wenn die Fee Rates höher als 30 Satz präwiebert sind, der wird eben unter anderem auch diese neue Methode verwenden, um ein Input Set auszuwählen und wenn das dann eben das Input Set ist, das am besten abschneidet in unserer Heuristik, dann wird die Transaktion damit gebaut und erspart hoffentlich ein bisschen

an Fees. Das heißt, es betrifft nur einen einzelnen Nutzer, nur die Wallet. Das war insofern überhaupt nicht kritisch, außer dass es hoffentlich richtig ist, weil wir natürlich das Geld von Leuten ausgeben und Leute müssen, also andere Entwickler haben das dann eben dahingehend untersucht, ob mein neuer Algorithmus eben tatsächlich das kleinste Input Set findet und tatsächlich den Nutzern Kosten spart und dass ich nicht zum Beispiel jetzt plötzlich einfüge, dass wenn

jemand Transaktionen mit diesem Algorithmus baut, schicken sie mir dann eine kleine Spende oder sonst was. Also das ist tatsächlich sehr, sehr isoliert und in einer kleinen Nische von Bitcoin Core. Eine viel wichtigere oder größere Änderung zum Beispiel war jetzt vor kurzem BIP 352 war das, glaube ich, also die V2-Protokollregeln, also die V2-P2P-Messages, die von Anfang an das Messaging ist verschlüsselt. Das betrifft das ganze Netzwerk, das betrifft, wie Nodes miteinander reden,

aber selbst das ist nur Opt-in. Falls dein Node gegenüber das noch nicht spricht, dann tun wir automatisch zurück zur alten Version der P2P-Messages gehen und tun uns eben mit der alten Sprache mit den anderen Nodes unterhalten. Aber sowas zum Beispiel betrifft dann eben das ganze Netzwerk und fügt ein neues Feature zu, wie man eben jetzt voll verschlüsselt mit Nodes reden kann auf dem Netzwerk. 324. 324, okay. Ich schreibe es nochmal

mit und dann suchen wir es auch nochmal raus für die Show Nodes. Den letzten BIP, den du jetzt gerade angesprochen hast, also V2-P2P-Messages, der benötigt ja in keiner Weise irgendeine Aktivierung, oder? Der wurde einfach im neuesten Release von Bitcoin Core, war der mit drin und jede Node, die diese neuestes Release von Bitcoin Core laufen lässt und dieses Feature aktiviert hat. Das war nur eine Frage, kann man das aktivieren und deaktivieren? Im letzten Release

war es drin, aber deaktiviert. Man kann es also anschalten. Im nächsten Release wird es dann hoffentlich automatisch angeschaltet drin sein. Genau, aber das heißt, da haben eigentlich nur

die Maintainer und Core Contributor und Reviewer, die da drauf geschaut haben, die haben gesagt, okay, das ist ein sinnvolles Feature, das können wir gut gebrauchen in Bitcoin und haben entschieden, dass wir das dann in den aktuellen Bitcoin Core reinmergen. Dann gibt es aber natürlich auch Änderungen, die einen größeren Prozess erfordern, nämlich diese BIPs, oder? Das ist nochmal was anderes, wenn wir über ein Bitcoin Improvement Proposal sprechen, oder? Die eine Aktivierung

bedürfen. Wo ist der Unterschied eigentlich? Also generell, hier, lass uns doch mal drüber reden, was BIPs sind. Genau, lass uns mal drüber reden, was BIPs sind. Jetzt habe ich mir eine flakalosilierte, blöde Frage gestellt. Lass uns mal drüber reden, was BIPs sind. Passt schon. Also ganz dumm, BIP steht erstmal als Akronym für Bitcoin Improvement Proposal. Generell würde ich sagen, beschreiben BIPs Ideen oder eine Art, ein Dokument öffentlich zur Verfügung zu stellen,

dass man einen klaren Referenzpunkt hat, worüber wir eigentlich reden. Also das BIPs Repository enthält einen Haufen formell beschriebene Ideen, was man so mit Bitcoin treiben kann und könnte. Nicht alle davon sind gut, nicht alle davon sollten wir umsetzen, aber das ermöglicht Leuten eben, ganz konkret auszudrücken, was stelle ich mir vor, was muss dafür passieren, wie möchte ich das System verändern. Und dadurch, dass man eben diese formelle Definition hat, kann man als eine

dezentrale Community gut darüber reden. Wenn ich sage BIP 324, dann wissen Leute ganz genau, kann ich im BIPs Repository nachgucken, es ist V2 P2P Transport Protocol und so weiter. Und es ist eben, das ist notwendig, damit wir eben eine verteilte Unterhaltung haben können über eine konkrete Idee. Das ist, was ein BIP eigentlich leistet. BIPs kommen in drei Flavors, also informationelle BIPs, prozedurale BIPs und, ich glaube, ich habe es schon mal aufgeschrieben.

Also vielleicht lasst mich das anders ausdrücken. Ein BIP muss nicht unbedingt eine Konsensusänderung erzeugen. Es kann zum Beispiel auch einfach nur ein User-Ebene-Beschreibung von einem Vorgehen sein, zum Beispiel die ganzen BIPs rund um Derivationspfade für verschiedene Wallet-Standards. Das sind BIPs, weil viele verschiedene Wallets was implementieren und es gut ist, wenn die das auf die gleiche Art und Weise implementieren, sodass man in der anderen Wallet das Backup

importieren kann. Aber eigentlich, wie irgendjemand seine Private Keys verwaltet, ist eigentlich so eine individuelle User-Problematik. Der kann daheim sich was würfeln und kann es auf Klopapier schreiben. Das funktioniert immer noch, aber es gibt eben einen Standard dafür,

dass eben, wenn man sinnvolle Software implementiert, die Backups miteinander kompatibel sind. Aber das lebt zum Beispiel, das existiert überhaupt nicht auf der Protokoll-Ebene im Netzwerk oder sonst irgendwo, sondern nur in den individuellen Wallets und eben um Backups zukunftssicherer zu gestalten. Dann gibt es eben Konsensusänderungen und dort würde man eben konkret Änderungen vorschlagen, für welche Art von Blöcken valide sind, welche Blöcke von dem Netzwerk akzeptiert werden. Wir

tun da generell von Soft-Folks und Hard-Folks sprechen. Soft-Folks sind Änderungen, bei denen die Menge aller validen Blöcke reduziert wird. Also nur ein Subset dessen, was vorher erlaubt wurde, ist danach noch erlaubt. Zum Beispiel SegWit war ein Soft-Folk in dem Sinne, dass zwar neue Features hinzugefügt wurden, aber die haben eigentlich die Byte-Sequenzen, die in Blöcken auftauchen dürfen, reduziert. Und dadurch war es eben ein Soft-Folk, weil vorher Blöcke, die

erlaubt worden waren, später nicht mehr erlaubt waren. Und dementsprechend, wenn eine Mehrheit der Hashrate und hoffentlich auch der Listening-Nodes so ein Soft-Folk enforced, also durchsetzt, dann wird das Netzwerk auf diese neue Regeln sich einspielen. Wenn man ein Hard-Folk macht, ist es genau umgekehrt. Man verändert die Menge der akzeptablen Blöcke von einem kleineren Set auf ein größeres Set und alle Nodes, die noch auf der alten Version sind, werden die neuen Blöcke,

die jetzt erlaubt sind, nicht akzeptieren. Und das führt dazu, dass alle Nodes im Netzwerk upgedatet sein müssen, damit das funktioniert. Sonst bleiben sie einfach stehen in dem Moment, wo das erste Mal eine Transaktion diese neuen Regeln oder ein Block diese neuen Regeln verwendet. Je nachdem, wie man es interpretiert, hatten wir ganz, ganz, ganz am Anfang unserer Netzwerkgeschichte

ein paar Sachen, die man vielleicht als Hard-Folk klassifizieren könnte. Sonst generell machen wir nur Soft-Folks, weil wir wollen, dass jemand, der seine Node hat laufen lassen und nicht drauf geguckt hat, nicht plötzlich aus dem Netzwerk ausgeschossen wird. Genau, das ist das Thema der Rückwärtskompatibilität. Das heißt, bei einem Soft-Folk sind alte Nodes immer noch Teil des Netzwerks. Sie werden damit nicht rausgeschmissen, weil sie akzeptieren immer noch die neuen Blöcke,

auch wenn sie für sie den Inhalt nicht verstehen. Nicht nur den Inhalt nicht verstehen, sondern vielleicht gar nicht, die merken gar nicht, dass bestimmte Blocktypen gar nicht mehr auftauchen. So was könnte man sich ja dann auch darunter vorstellen. Also ein Netz habe ich da, ein Soft-Folk ist vorwärtskompatibel. Mit der alten Software ohne eine Änderung kannst du die

Daten, die für eine neue Version der Software geschrieben wurde, immer noch akzeptieren. Das heißt, der Soft-Folk ist auch rückwärtskompatibel, aber vor allem vorwärtskompatibel, weil die alten Nodes immer noch dem Netzwerk folgen können. Die können Inputs, die für die neue Version gemeinsam interpretieren. Und rückwärtskompatibel in dem Sinne, dass die neue Software natürlich auch alles lesen können muss, was vorher geschrieben wurde. Also die ganze Blockchain

von vorher noch interpretieren kann. Wir sind ja schon beim Soft-Folk meines

Erachtens schon ziemlich am Ende da angekommen, was passiert, wenn irgendjemand mal ein Update, also sagen wir, das wird bei Segwit oder Taproot. Das ist ja im Endeffekt das Ende eines Updates oder eines Upgrades vom Bitcoin-Konsensus gewesen. Aber lasst uns mal wieder ein bisschen zurückgehen. Vielleicht du hattest eben die BIPs erwähnt. Sind BIPs der erste Schritt, wenn irgendeine Person oder eine Gruppierung eine Konsensusregelung anstrebt? Ist das das erste,

was erstellt wird? Dass man halt irgendwie sagt, hier, ich möchte gerne Änderungen machen, kriege ich jetzt hier ein BIP, damit wir das auf der Basis diskutieren? Wird das in einer Mailing-Liste diskutiert, wie es früher viel im Open-Source-Feld gemacht wird? Wie ist da der Einstieg quasi in so eine Thematik? Ich glaube, wir fangen eigentlich eher ein

paar Schritte vorher noch an. Erstmal wird man wahrscheinlich ein bisschen über, man hat unter der Dusche morgens eine Idee und dann fragt man vielleicht einen Kollegen oder einen Kameraden, der sich vielleicht mit der Thematik einigermaßen auskennt, was der denn davon hält. Man fängt an, irgendwie so die Idee ein bisschen auszurollen, ein bisschen abzuklopfen. Ist das sinnvoll? Löst

das ein wichtiges Problem? Ist das den Aufwand wert? Und so weiter. Man ist wahrscheinlich also vielleicht bei einem Forums-Post in Delving Bitcoin eher erstmal, wo man, nachdem man mit ein paar Leuten darüber geplaudert hat, ob sich das lohnt zu formalisieren, das dann in mehr Detail beschreibt und vielleicht dort einfach mal so ein bisschen Brainstorming betreibt oder sein Konzept

vorstellt, vielleicht darüber nachdenkt, was denn die Herangehensweise sein würde. Und dann, wenn die Idee schon ein bisschen gereift ist, dass man relativ konkret weiß, was man eigentlich machen möchte, würde man anfangen, die so formell aufzuschreiben, wie das für ein BIP notwendig ist. Ein BIP sollte hinreichend genau spezifiziert sein, dass man zum Beispiel eine Konsensusänderung

implementieren kann von dem BIP. Das wird sicherlich natürlich nicht im ersten Entwurf wasserdicht ausformuliert sein, aber damit man überhaupt erstmal so genau weiß, was man machen möchte, hat man vielleicht schon eine Prototyp-Implementierung gemacht. Man hat bestimmt

viel darüber diskutiert. Man hat hoffentlich schon zwei, drei andere Entwickler hinreichend von seiner Idee begeistert, dass die mit auf die Prototyp-Implementierung geguckt haben oder ihre Ideen beitragen, sodass, wenn man das BIP schreibt, vielleicht zwei, drei Autoren dastehen, die sagen, "Hey, wir machen das. Das ist eine gute Idee. Das bietet einen Mehrwert in dieser Art und Weise." Und wenn eben dann dieser Entwurf für ein BIP hinreichend spezifiziert ist, dann macht man erst

ein Pull-Request auf zum BIPs-Repository. Ich weiß nicht, ob ihr die Mailing-Liste gelesen habt, aber dann kann es ein bisschen dauern, bis man vielleicht eine Nummer kriegt und bis der BIP Maintainer vielleicht in den paar Stunden, die er einmal im Monat draufguckt, dazu kommt, dein BIP-Proposal anzugucken. Und wenn es dann alles schön gut spezifiziert ist, hinreichend reviewed wurde, viele Leute das toll finden und letztlich oder es zumindest hinreichend gut

ausformuliert ist, dann wird es halt gemerged und dann hat es eine Nummer. Und dann kann man das überall breittreten und hat eine genaue Referenz, was denn die konkrete Idee ist, die eigentlich evaluiert wird. Das heißt zum Beispiel Silent Payments, das hat vor einer Weile eine BIP-Nummer bekommen. Das wurde jetzt aber erst vor einem Monat oder wurde es überhaupt schon gemerged? Ich glaube, es ist noch nicht gemerged. Aber da reden wir zum Beispiel öffentlich schon seit einem

Jahr oder so drüber. Und also das BIP selbst, der Entwurf für das BIP, findet irgendwann zwischen Prototyp und Idee statt oder nach Prototyp sogar. Dann ist vielleicht schon eine relativ konkrete Implementierung vorgestellt, bevor man alle Probleme mit der Implementierung genau ausgefeilt hat und das alles genau genug beschreiben kann in dem BIP, dass die Implementierung sinnvoll ist, dass man datensparsam ist, dass es nicht Probleme gibt mit anderen Sachen, dass es keine Bugs mehr

gibt und so weiter. Und dann, erst wenn es auf dem Punkt ist, wird das BIP gemerged. Schaut euch zum Beispiel Music 2 an. Music 2 war vorgeschlagen als Idee 2013 oder so. Man könne ja Signatur- Aggregation machen mit Schnorrsignaturen. Der Taproot Softfork war dann, ich möchte sagen, 2017 eine Idee, vielleicht war es 2018. Und das Music 2 BIP wurde auch vor weniger als einem halben Jahr endlich gemerged, glaube ich. Also das Ganze dauert eine Weile. Ich würde

mal noch mal eine Frage dazwischen stellen. Du hast es kurz angedeutet, aber dieser BIP-Nummer Zuweisungsprozess steht ja auch immer mal wieder in der Diskussion, weil der so eine Art Flaschenhals bildet in dem ganzen Prozess. Vielleicht kannst du noch mal kurz beschreiben, was da der aktuelle Stand ist, wie eben diese BIP-Zuweisung genau funktioniert. Also wir haben einen Maintainer,

der eben sich um die BIPs kümmert und das ist eigentlich auch eine administrative Aufgabe. Der Maintainer soll gucken, ob das BIP hinreichend genau spezifiziert ist, ob die Idee generell mit Bitcoin zu tun hat. Es geht nicht darum, ob es eine gute oder schlechte Idee ist oder eine Empfehlung zur Implementierung oder sonst was. Wenn es eben die doch schon relativ signifikant hohe Hürde

eines akzeptablen BIP-Entwurfs erreicht, dann soll er einfach das merchen. Und wenn es so aussieht, als ob das in die Richtung geht, dann wird vielleicht eine Nummer auf dieses Proposal gepackt und das hilft natürlich dann konkret über diese Idee zu reden. Und der Maintainer, der sich darum kümmert, der hat eben das relativ genau Timebox zu ungefähr einmal im Monat für ein paar Stunden guckt er da drauf und das ist manchmal dann etwas langsam, bis man eine Antwort

kriegt. Ich glaube, wir haben so um die 150 offene Pull-Requests im BIPs-Repository. Ich müsste jetzt gucken, um die genaue Nummer zu wissen. Aber naja, jedenfalls die Leute, die ein BIP schreiben, die Autoren, sind die Besitzer dieses BIPs. Das gehört nicht der

Community, sondern den Leuten, zumindest bis es gemerged ist. Wenn es gemerged ist, kann man glaube ich vielleicht sagen, wenn man große Änderungen am BIP noch machen möchte, sollte man lieber ein neues schreiben, das dann sagt "Supersedes anderes BIP", sodass eben diese Referenz zu einer konkreten Idee und einer Implementierung dieser Idee beibehalten wird. Es hilft nicht so, wenn man fünf verschiedene Versionen von etwas hat und das alles die

gleiche Nummer hat, dann weiß keiner, wovon man redet. Aber zumindest bis das BIP final ist, gehört es einfach nur dem Autor. Der Autor hat eine Idee, oder die Autoren hoffentlich, haben eine Idee, haben die sehr konkret ausformuliert und stellen die eben zur Diskussion für die Community, wünschen sich, dass Leute kommentieren und unterstützen und Verbesserungsvorschläge machen. Und dann, wenn halt also die Leute, die ein BIP geschrieben haben, sagen, sie wollen hier

einen Tippfehler korrigieren oder sonst was, dann sollte das nicht so lange dauern. Wir haben 150 offene Änderungen im BIPs Repository, nichts wird gemerged und damit tatsächlich einfach nicht mehr die Funktion erreichen, dass Leute ihre Ideen dort zur Diskussion stellen können. Dementsprechend hat halt AJ jetzt das Banana Repository gestartet und er hat eben die Idee, dass er dort alle Ideen einfach relativ unbürokratisch schnell zur Verfügung stellen wird. Er verwendet dann ein

einfacheres Nummernsystem, nämlich einfach eine laufende Nummer. Das ist das fünfte Proposal in 2024, dann ist es 2024/5. Und dann hoffentlich kommen wir zurück zu einem zentralen Punkt, wo man seine Ideen zur Diskussion stellen kann und allen Mitgliedern unserer doch weitgefächerten Community ein konkretes Referenzdokument geben kann, damit alle wissen, worüber man eigentlich redet. Ich wollte gerade sagen, weil das ist super interessant, ich habe das Proposal nämlich

auch gesehen. Das war eben Socratic in Berlin, war das auch Teil der Leseliste und ich fand das echt interessant. Ich würde sagen, der BIP-Prozess erfüllt zurzeit seine Funktion nicht. Und um es mal an einem ganz konkreten Beispiel festzumachen, Casey Rodhamer hat das Ordinals-BIP vorgeschlagen. Ich halte Ordinals für dumm. Die scheinen mir keinen Mehrwert zu schaffen, außer dass sie vielleicht jetzt gerade einige neue Entwickler interessiert gemacht haben, aber die machen Dinge

mit Bitcoin, die ich nicht interessant finde. Insofern weiß ich nicht, ob das ein Mehrwert ist. Ich habe auch kein Interesse an irgendwelchen Colored Coins, die jetzt links und rechts mit VSC20 token, sondern auch uns erzeugt werden. Aber es ist schon eine Idee, die mit Bitcoin zu tun hat und es ist hinreichend genau spezifiziert. Man könnte jetzt sagen, das ist nicht konform mit der Idee für Bitcoin. Aber ist das vielleicht wirklich Aufgabe eines BIPs, Repository

Maintainer, diese Entscheidung für die gesamte Bitcoin-Community zu treffen? Oder ist es trotzdem einfach ein zentraler Punkt, wo man seine Idee zur Verfügung stellen kann, dass sich Leute daran abreiben können? Und insofern, ich hätte verstanden, wenn das Ordinals-BIP gemerged worden wäre, einfach weil es dann eine BIP-Nummer hat und man darüber reden kann und dann können alle sagen,

Ordinals sind scheiße und das hat halt BIP so und so. Und dann machen wir es nicht. Genau wie wir zum Beispiel fünf von den Blockvergrößerungs-Proposals eben nicht gemacht haben und wahrscheinlich die Hälfte der anderen BIPs auch nie umgesetzt wurden. Also zumindest nicht in Bitcoin-Coin. Aber wenn eben jetzt ein Maintainer seine Rolle als solche versteht, dass er persönlich bewerten muss, ob ein BIP konform ist mit der Intention, wofür Bitcoin geschaffen wurde,

dann ist es vielleicht einfach zu politisch und auch vielleicht zu viel verlangt. So viel Zeit sollte keiner investieren müssen, um eben irgendwo ein zentrales Repository zu haben, um Dokumente zur Diskussion zu stellen. Und deswegen, also ich finde den Banana-Vorstoß von AJ finde ich recht gut. Vielleicht löst das Banana-Repository, das BIP-Repository langfristig ab. Wer weiß, vielleicht fängt sich das BIP-Repository auch wieder. Meiner Meinung nach

sollten auch die ganzen Lightning-Bolts BIPs sein. Das ist meiner Meinung nach BIP-Material. Es sollten vielleicht auch viele andere Dinge, über die wir hinreichend viel geredet haben, BIPs sein. Aber nur ja. Es ist irgendwie ein schwieriger Prozess. Das ist so jetzt mein Take-away. Es ist irgendwie nicht ganz klar, was wer wie darf und soll und wie es passieren muss und was jetzt alles als BIP rein muss. Also jetzt nicht nur BIP, also jetzt nach dem klassischen

Prozess, sondern wirklich als, wie finden wir das, was Bitcoin verbessern soll. Wie finden wir tatsächlich diese richtigen Improvement-Proposals? Der ganze Prozess ist kompliziert. Also erstens, wir wollen sicherstellen, dass keiner im Netzwerk ausgeschossen wird. Also vor allem, dass wir kein Geld konfiszieren. Insofern muss ein Proposal in der Regel immer dafür sorgen, dass alle Transaktionen, die vorher jemals genutzt wurden oder sinnvoll pre-signed und

nie veröffentlicht wurden. Unser Albtraum ist quasi, jemand hat eine Transaktion gebaut, in der Vergangenheit hat die pre-signiert und irgendwo aufgezeichnet und dann die Schlüssel weggeschmissen. Also ein Wort oder Covenant gemacht, wo er jetzt nur noch diese Transaktion veröffentlichen kann. Und wir wissen das nicht und wir machen die Konsensus in Valide. Und dann steht er da und kann seine Transaktion nicht mehr durchbringen und verliert sein Geld. Das ist zum

Beispiel etwas, was wir vermeiden wollen. Insofern sind alle unsere Konsensusänderungen immer sehr stark dahingehend geprüft, dass wir niemandem ihr Geld wegnehmen. Und dann muss das auf dem Netzwerk ausgerollt werden, wo ungefähr ein Viertel oder ein Drittel aller Nodes mehr als zwei Jahre alte Versionen laufen lassen. Wo man keinen zwingen kann, Software abzugraden. Wo generell Leute entscheiden, was für sie Bitcoin ist, indem sie wählen, welche Software sie verwenden,

um die Regeln von Bitcoin durchzusetzen. Also wenn nämlich zum Beispiel jemand sagt, Ordinals sind für mich Konsensus in Valide und packt das in einen Client und veröffentlicht diesen Client und übernachten 60 Prozent des Bitcoin-Netzwerks diesen Client, akzeptieren und verwenden den. Und die überzeugen auch die Miner, das zu tun, dann ist das wahrscheinlich langfristig Bitcoin. Und insofern Bitcoin-Core-Entwickler haben jedenfalls keine alleinige Deutungshoheit,

was das Bitcoin-Netzwerk ist und was die Regeln des Bitcoin-Netzwerkes sind. Das ist mehr so ein Triumvirat aus der Industrie, den Nutzern, den Bitcoin-Entwicklern. Ich vergesse wahrscheinlich noch, wie man das anders aufschlüsseln könnte. Aber die Nutzer entscheiden, was für sie Bitcoin

ist, indem sie wählen, welche Software sie laufen lassen. Die Miner und Industrie bauen Blöcke, werden dafür bezahlt oder stellen Services zur Verfügung, die viel Einfluss darauf haben, was eigentlich im Netzwerk wichtig ist, weil sie eben viel ökonomischen Einfluss haben im Netzwerk. Und dann die Entwickler schlagen Ideen vor, vielleicht Ideen, die sie von den Nutzern oder

der Industrie bekommen haben, implementieren die und stellen das eben zur Diskussion. Aber es ist eben jetzt nicht vor allem nicht so, dass ein Maintainer sagt, wir machen das jetzt und dann wird das gemacht. Die Maintainer sind sicher nicht die Diktatoren des Netzwerks oder sowas.

Es ist alles sehr, sehr kompliziert. Und wenn dann eben noch hier und da Sand ins Getriebe geschmissen wird, weil einfach unnötig Dinge verkompliziert werden aus politischen Meinungen heraus oder weil zu wenig Zeit gefunden wird, um irgendwelche administrativen Dinge zu tun, dann ist das vollkommen menschlich und natürlich aber trotzdem frustrierend. Ich habe das Gefühl, ihr habt mich eingeladen zum Ranten. Und der arme Thorsten ist auch schon am… Du wirkst ein bisschen müde, Thorsten.

Ja, weil wir jetzt irgendwie gefühlt 25 Minuten über BIPs gesprochen haben. Das ist vollkommen in Ordnung. Aber ja, jetzt haben wir ziemlich viel über BIPs gesprochen, aber diese BIPs müssen ja in irgendeiner Form auch getestet und implementiert werden. Es gibt ja neben dem Bitcoin Mainnet auch noch sowas wie das Testnet, das SigNet und vielleicht auch noch irgendwelche anderen Netzwerke, die da noch so laufen, die wahrscheinlich für Nichtentwickler ziemlich weit unter dem Radar

laufen. Das Testnet kennt vielleicht noch der eine oder andere, aber dann hört es wahrscheinlich schnell auf. Was für unterschiedliche Varianten von Netzwerken haben wir bei Bitcoin und wofür werden die benutzt? Vielleicht das so als Abschluss noch, damit wir mal da so einen Überblick bekommen. Ja, okay. Also natürlich gibt es das Mainnet. Das ist das, was wir alle

liebevoll als Bitcoin bezeichnen in der Regel. Testnet ist sozusagen der erste Altcoin. Relativ schnell hat Satoshi, ich glaube das war noch Satoshi, der das erste Testnet gestartet hat, einen neuen Genesis Block erzeugt und gesagt hat, die Coins in diesem Netzwerk sind wertlos, aber hier kannst du mal deine Wallet-Implementierung testen und so weiter. Im Grunde genommen ist es also einfach ein Netzwerk, das funktional fast genau gleich zum Mainnet ist, mit einem anderen

Genesis Block startet, wo Leute sozial entschieden haben, dass es nie Wert haben wird. Das Testnet ist auch schon in der dritten Iteration. Für das erste Testnet hat nämlich dann tatsächlich irgendjemand angefangen, die Coins mit einem Wert zu interpretieren und das war dann wirklich einer der ersten Altcoins. Dann wurde das Testnet neu gestartet und oder vielleicht war es das Testnet 2. Das Testnet 2 wurde dann gehandelt und deswegen verworfen. Wir sind auf Testnet 3.

Testnet 3 ist quasi gleich wie Mainnet, außer wenn 20 Minuten kein Block gefunden wurde, kannst du einen Block mit der niedrigsten Difficulty, Difficulty 1 erzeugen. Und wenn du das mit dem Block machst, an dem die Difficulty neu eingestellt wird, dann resetterst du die Difficulty von Testnet allgemein auf die Minimaldifficulty, so dass du, wenn jemand mal das Testnet angeguckt hat, das hat einen Haufen Blockstorms in den letzten Jahren,

wo genau das passiert. Irgendwelche Spaßvögel tun die Difficulty dauernd auf 1 resetten und dann, weil die Difficulty so niedrig ist, dass man mit einem einzelnen ASIC hunderte Blöcke pro Minute finden kann, ist das Testnet tatsächlich schon an dem 10. Halvening vorbeigezogen. Das Testnet ist also tatsächlich mehr oder weniger vollkommen nutzlos inzwischen. Also ja, du kannst schauen, ob du es richtig implementiert hast, ob eine Transaktion im Netzwerk ankommt und gemeint

wird. Manchmal tun Miner auch Transaktionen annehmen, manche tun einfach nur so Minen, die tun, manchmal gibt es heftige Reworks auf Testnet und so weiter. Jedenfalls, weil das Testnet eben nicht mehr so wirklich voll die Funktion erfüllt, dass man dort eben zum Beispiel als Wallet-Implementierer seinen Kunden eine Testnet-Variante zur Verfügung stellt, wo sie etwas erleben, was ähnlich wie Mainnet ist, aber wo das Geld nichts wert ist, dann hatten wir vor

einer Weile das Signet eingeführt. Signet ist wie ein Testnet, das du dir selbst aufsetzen kannst. Und zwar ist es kontrolliert von einem oder mehreren privaten Schlüsseln, nämlich Leuten, die Blöcke in Existenz signieren. Also im Signet wird nicht gemeint, sondern die Leute, die das Signet betreuen, signieren die Blöcke und die machen das halt einfach alle paar Minuten oder alle zehn Minuten genau. Ich glaube, das Mutiny-Net ist ein Signet, wo Blöcke alle 30

Sekunden kommen. Du kannst auch dein eigenes aufsetzen. Ich glaube, es gibt mindestens drei oder vier, die regelmäßig verwendet werden. Das Haupt-Signet, das in Bitcoin Core mit eingestellt ist, wird von einigen Bitcoin-Entwicklern betreut, ich glaube zwei, und die können einfach Blöcke regelmäßig signieren und zur Verfügung stellen. Es gibt noch ein anderes Netz, das du noch gar nicht erwähnt hast, und zwar den Registest von Bitcoin Core, was quasi so eine Art lokales

Testnet ist. Das verwenden wir ganz viel in unseren Tests für Bitcoin Core und das kann man aber auch lokal aufsetzen und dann mit mehreren Computern miteinander verbinden und dann kann man dort auch ein mini lokales Testnet haben, was manche Unternehmen zum Beispiel für internes Testing auch verwenden. Vor einer Weile noch war auf Testnet die Mempool-Policy genau

Konsensus regeln. Das heißt, auf dem Testnet ging alles, was teilweise ein bisschen für Probleme gesorgt hat, weil Leute dann getestet haben auf Testnet, ob eine Transaktion konsensusvalide ist, aber die war vielleicht dann immer noch nicht Mempool-Policy-valide und dann, als sie auf Mainnet gewechselt haben, ist ihre Transaktion eben nicht von anderen Nodes angenommen worden. Deswegen, glaube ich, wurde vor einer Weile das Testnet auf die gleichen Mempool-Policy-Regeln wie das Mainnet

gestellt in den letzten Releases. Aber ja, das nur so als kleinen Überblick, wie man dann vielleicht seine Software ein bisschen testen kann, bevor man sie auf Mainnet rausgibt. Und ich würde jeden Wallet-Entwickler vor allem ermutigen, dass sie nicht auf Mainnet testen. Wir haben das immer wieder auf Bitcoin Stack Exchange, dass irgendjemand fragt "Hey, ich habe diese Transaktion gebaut, warum kann ich das denn jetzt nicht ausgeben?" oder "Warum nehmen andere Nodes das nicht an?"

oder "Es sagt mir hier, dass die Signatur nicht richtig geformt ist." Und dann guckst du die Transaktion an und stellst fest, dass es eine Mainnet-Transaktion ist und denkst dir immer nur so "Klar, sind nur 50 Euro, aber willst du das nicht auf dem Testnet machen, wo du halt auch kein Geld verlierst, weil du es falsch machst?" Ja, sehr gut. Also vielleicht können wir noch daran ankündigen, dass wir uns auf jeden Fall diese alternativen Netze, also Testnet, Signet

und wie ich jetzt gelernt habe, das Racktestnet, das werden wir uns mal anschauen. Da gibt es eine eigene Folge zu. Genau, also vor allem auch aus dem Antrieb, den jetzt auch Mörsch hier gerade gesagt hat, weil man viele Dinge tatsächlich auch, also ich nutze ganz gerne das Testnet, da mal ein bisschen ausprobieren kann. Ich wusste, also ich in meinen Tests, also in meinem privaten, das was ich so probiere, ist mir das jetzt noch nicht so aufgefallen, dass das Testnet

irgendwie nicht so gut funktioniert. Also Transaktionen gingen rein und raus, dafür hat es gereicht. Du baust ja auch keine komplexen Software selber, wo das dann vielleicht irgendwelche exotischen Transaktionen gebaut werden. Ja, aber vor allem einfach, wenn du zum Beispiel einen neuen Node aufs Testnet synchronisieren willst. Wir sind am 10. Halvening vorbei, das sind also über zwei Millionen Blöcke und bis du halt gesynct hast, ist es deutlich länger.

Signet ist viel leichtgewichtiger, vor allem, weil auf dem Testnet auch zum Beispiel vor Segwit irgendjemand ein paar Monate lang mal maximal größe Blocks produziert hat mit 3,7 Megabyte und so weiter. Es ist einfach, das Testnet ist inzwischen, ja wahrscheinlich zwölf Jahre alt

oder so und dementsprechend halt einfach schwer und globig. Mit Signet ist es leichter, vor allem, wenn du dein eigenes Signet aufsetzt oder wenn du halt nur lokal, wenn es nur deinen eigenen Node betrifft, kannst du es halt einfach mal schnell in deinen Red Test reinschmeißen.

Jo, gut. Dann, ich glaube, mit Hinblick auf die Zeit machen wir jetzt an der Stelle für diese Folge erstmal einen Cut. Wir hatten euch ja in der Community jetzt letzte Woche oder diese Woche gefragt, ob ihr Fragen an den Merch habt beziehungsweise Fragen zu dem gesamten Thema Bitcoin Core Entwicklung und da haben auch mit uns ein paar Leute geschrieben und wir würden diese Fragen, die wir von euch aus der Community bekommen haben, jetzt in einer eigenen Folge

machen, die dann die nächste Folge nach dieser dann sein wird. Wann auch immer die kommt, wissen wir jetzt noch nicht genau, aber auf jeden Fall, dass ihr jetzt schon mal wisst, die nächste Folge wird dann eure Community Fragen als zweiter Teil beinhalten. Deswegen, ja erstmal an der Stelle, Merch, vielen, vielen Dank für deine großartigen Ausführungen. Ja, Jan Paul, danke auch, dass du dabei warst und dann verbleiben wir erstmal mit den Worten,

"Focus on the signal, not on the noise". Bis dahin, ciao, ciao. Ciao, danke.