Nodesignal-Talk - E189 - Bitcoin hat Bugs

Ja, guten Abend. Ja, der Murch ist aus, ja, wieder New York City wieder mit dabei und dementsprechend andere Zeitzone, aber das soll uns nicht aufhalten, eine schöne Podcast-Folge

aufzunehmen. Genau, wir wollen heute darüber sprechen, dass Bitcoin nicht perfekt ist, denn Bitcoin hat auch wie jede andere Software vermutlich Bugs und beziehungsweise es gibt sogar Bugs, die bekannt sind, die aber nicht so kritisch sind, dass wir sie instant fixen müssen, aber trotzdem uns da das Augenmerk darauf haben sollten, dass wir in Zukunft vielleicht da eine Lösung für finden. Aber bevor wir da reingehen, erst mal Murch, kannst du uns mal kurz die Blog-Zeit geben,

damit wir uns entsprechend synchronisieren können. Die Blog-Zeit ist gerade 846.520. Sehr gut, habe ich auch. Hat ja ein paar Lauch, perfekt. Großartig, dann haben wir das auch erledigt. Gut, ganz kurzer Kommentar noch vorweg, ihr kennt es, wir sind ein Value for Value Podcast, das bedeutet, wir bringen euch hier keine Werbung, wir bringen euch hier das reine Bitcoin-Signal, in dem Fall heute das Bitcoin-Bugs-Signal oder wie auch immer man das

sagen kann. Das heißt, wenn das, was wir hier für euch machen oder das jetzt heute insbesondere, was der Murch heute an Mehrwert und Input hier in diese Folge liefert, einen Mehrwert für euch bietet und ihr das entsprechend honorieren wollt, dann könnt ihr uns gerne eine kleine Spende in Form von Satz, in Form eines Boosts oder als Direktspende dalassen. Das würde uns auf jeden Fall helfen, den Podcast hier zu betreiben, damit wir diese Formate auch in Zukunft bringen können.

Genau, da werden wir uns auf jeden Fall sehr darüber freuen. In dem Sinne, dann kann man, glaube ich, direkt ins Thema reinstarten, Jan-Paul.

Es gibt noch was, was ich vorher noch besprechen möchte. Genau. Denn, Murch, wir hatten beim letzten Mal, als wir über Bitcoin, ich glaube, da haben wir über Bitcoin Core Development gesprochen, da hatten wir auch diskutiert, dass es bei dem BIP-Vergabeprozess, also dem Bitcoin Improvement Proposal Vergabeprozess, einen kleinen Flaschenhals gibt. Da hat sich was getan, Murch. Was ist passiert? Ja, die Diskussion ist wieder etwas aufgeflammt dieses Jahr und irgendwie waren dann genug Leute

hinreichend motiviert, dass man mal was ändern sollte. Man hat sich dann auf der Mailing-List geeinigt, dass noch einige andere Bitcoin-Entwickler bzw. einfach Leute aus der Bitcoin-Entwicklungsszene BIP-Editor werden, also im Bitcoin Improvement Proposals Repository, dort eben die Editor oder, wie sagt man, Herausgeber, vielleicht nicht wirklich,

Funktion übernehmen. Das heißt, es wurden fünf weitere Personen zu BIP-Editors ernannt und jetzt, wo wir sechs Leute haben, die dafür verantwortlich sind, flutscht es gerade wieder ein bisschen mehr. Wir hatten, ich glaube, das war Ende April oder so, wo das gestartet hat, dass wir jetzt zu Sext, dort arbeiten. Ihr hört schon, ich sage "wir". Ich bin einer der neuen BIP-Editoren und wir hatten,

glaube ich, 154 offene Pull-Requests oder so. Seitdem sind wir runter auf unter 40. Wir haben, glaube ich, um die 120 oder so Pull-Requests verarbeitet, viele davon gemerged, einige auch einfach geschlossen, weil sie nicht mehr relevant waren, vor Jahren geöffnet und irgendwie eben nicht von den, also ich sollte sagen, die BIPs sind ja Autorendokumente. Der Inhalt eines BIPs gehört dem Autor, nicht der Community. Es ist die Meinung oder die Empfehlung eines Individuums oder

mehrere Individuen. Das heißt, wenn jemand was editieren möchte in einem fremden BIP, dann muss der ursprüngliche Autor das absegnen und wenn das eben nicht passiert, dann kann die Änderung nicht durchgeführt werden, weil eben das Dokument dem Autor gehört und nicht der Community. Und dementsprechend haben wir auch einige Sachen einfach schließen können, aber das meiste ist halt gemerged. Wir haben einige neue Nummern vergeben seitdem es gab ein paar BIPs, die gemerged

wurden. Zum Beispiel wurde Silent Payments jetzt letzte Woche gemerged, Truck Transactions wurde gemerged, was V3 Transaktion auch heißt. Was haben wir noch? Gestern habe ich die Nummer für das DNS Payment Information BIP von Matt Corallo assigned. Das ist Nummer 353. Ja, das ist ziemlich cool. Da läuft jetzt was. Ich glaube, dass man auch sieht, dass ein paar Leute wieder angespannt sind, auch

BIPs zu schreiben. Es ist schön, dass der Flaschenhals weniger ist. Wir haben immer noch so ein bisschen ein paar Problem-Proposals, wo wir nicht genau wissen, was wir damit machen sollen. Also es wäre vielleicht schön, unabhängig davon, dass es jetzt mehr Editoren gibt und der Prozess dementsprechend ein bisschen flüssiger läuft, wenn wir vielleicht uns einfach auch nochmal angucken, was an dem Prozess funktioniert und wie wir den Prozess vielleicht überarbeiten könnten. Da

gibt es so ein paar Themen. Also zum Beispiel das Statusfeld auf den BIPs. Da gibt es zwölf verschiedene Werte oder so, die erlaubt sind. Und viele von denen sind äquivalent zu anderen oder vielleicht auch einfach nicht sinnvoll, weil sie versuchen zu tracken, wie weit das BIP von der Community angenommen wurde. Aber es sind ja Autorendokumente und dementsprechend ist ein Feld, das trackt, wie viel der Community das schon angenommen oder implementiert hat. Das ist

vielleicht ein wenig fehl am Platz. Und ein paar andere Themen. Ich hatte da mal versucht, die Konversation, also Tim Ruffing und ein paar andere Leute hatten da zur Mailinglist schon was geschrieben. Ich hatte das mal zusammengefasst. Und ich versuche mich darin, ein überarbeitetes Dokument zur Verfügung zu stellen. Ist ein bisschen zäh, zu schreiben, wie andere Leute

BIP schreiben sollen. Jedenfalls bisher zieht sich das noch ein bisschen. Mal gucken. Vielleicht jetzt, wo das BIPs Repository ein bisschen weniger offene Arbeit hat, die gleich ins Gesicht springt, komme ich eher dazu. Es ist auf jeden Fall schön zu hören, dass da ein bisschen Bewegung reingekommen ist und dass ihr euch jetzt auch nochmal den Prozess anschaut. Ich weiß, das ist mühsame Arbeit, solche Prozesse zu, also gerade wenn man einen existierenden Prozess hat, den dann umzubauen

oder neu zu strukturieren. Dinge wegzuwerfen, die völlig fehl am Platz sind oder auch nie genutzt wurden. Also trotzdem vielen Dank dir und auch deinen Kollegen, die das übernommen habt. Ich muss nur kurz sagen, ich fand den Begriff des BIP-Herausgebers gar nicht so schlecht. Dann sind quasi die Autoren, sind die Redakteure dieses BIPs, denen gehört das quasi, was es inhaltlich darstellt. Und ihr gebt es quasi nur innerhalb dieses BIP Repositories. Dann vergebt

ihr dem quasi eine Seitennummer im Grunde, wo es dann erscheint. Ja und nein. Also im Prinzip ist es auch wieder eher nur so eine Hausmeisterarbeit. Die Dokumente gehören den jeweiligen Autoren. Und was wir versuchen, ist eben eine zentrale Plattform zur Verfügung zu stellen, wo Leute ihre Idee zur Verfügung stellen können, zur Diskussion stellen können und dann eben nur an einem Ort gucken müssen, ob es dazu schon mal eine Idee gibt, ob sich Ideen wiederholen, eine richtig gute

Spezifizierung haben, dadurch dass wir einfach Qualitätsansprüche stellen. Aber ich würde gerne in einem neuen Prozess, falls wir den Prozess überarbeiten, versuchen, weniger Entscheidungsgewalt zu den Editoren zu geben. Also bisher zum Beispiel ist ein Satz in BIP 2, das den Prozess regelt und das ist, ob es mit der Philosophie von Bitcoin übereinstimmt. Also es ist halt super subjektiv, ob ein Vorschlag mit der Philosophie von Bitcoin übereinstimmt. Und da gibt es jetzt zum Beispiel

halt ein, zwei Problem BIPs, wo das heiß diskutiert wird. Okay, wir wollen aber nicht weiter ins Detail gehen, glaube ich. Oder Thorsten, hast du noch eine Frage zu dem BIP Prozess? Nö, also das klingt ja, wenn ihr von 140 jetzt auf 40 runter, dann ist ja die Perspektive, sofern natürlich die Problem BIPs irgendwann mal sich auflösen, dass ja dann die Pipeline da irgendwann dann vielleicht dann auch mal einigermaßen dann bald geleert ist, wenn ihr jetzt so viel

Manpower dahinter habt. Ja, es sind jetzt ein paar aktiv entwickelte BIPs ja noch gerade drin. Es sind ein paar drin, die sind auf Prozess gelabelt, weil unklar ist, ob diese, also jemand hat die Regel von BIP 2 verwendet, dass wenn ein BIP sich für drei Jahre nicht vorwärts bewegt, kann es als rejected geschossen werden und das ist für fünf BIPs oder so eingereicht. Aber im Grunde genommen, da wehrt sich zum Beispiel ein Autor gerade, weil er sagt, mein Ding ist immer noch bereit,

gemerged zu werden. Es ist nicht mein Problem, dass die Community es gerade noch nicht will. Es ist offen seit sieben, acht Jahren oder so. Ich glaube, dass das eher eine permanente Aussage ist, aber kann man schon die Position haben, dass das eben nicht rejected ist, sondern es ist immer noch bereit, es ist nur noch nicht angenommen von der Community. Und das wäre vielleicht auch was,

was in einem neuen Prozess dann wäre. Eben ein BIP ist noch ein Draft, ein BIP ist vorgeschlagen zur Adoption oder zur Implementierung oder es ist final, es ist implementiert und ändert sich nicht mehr. Und vielleicht sind dann die anderen Statüsse alle obsolet, vielleicht noch withdrawn, also dass jemand sagt, fand ich mal eine gute Idee, finde ich nicht mehr, ich ziehe es zurück. Und vielleicht würde das zum Beispiel helfen, dass man sich nicht so sehr drum kümmern muss,

was andere vorschlagen. Ja, super. Dann lass uns doch mal zum eigentlichen Thema übergehen. Ich

versuche es mal ein bisschen einzuleiten. Es gab einen Artikel, der auch so ein bisschen die Runde gemacht hat auf Delving Bitcoin und zwar hieß der "The Great Consensus Cleanup Revival", so hieß der Artikel oder der Aufsatz von Antoine Ponceau, glaube ich. Ich denke, das ist die richtige Aussprache. Genau. Und Antoine hat etwas aufgegriffen, was Matt Corello bereits vor mehreren Jahren mal aufgeschrieben hatte. "The Great Consensus Cleanup" hieß das damals schon.

Ist ein BIP ohne Nummer übrigens. Habt ihr das auf dem Schirm? Das ist ein Draft, also ein Entwurf eines BIPs, das nie als Puller Request geöffnet wurde gegen das BIPs Repository. Wenn du genau guckst, das ist zwar in einem BIPs Repository, aber in Matts BIPs Repository. Nicht im Bitcoin BIPs Repository. Okay, sehr gut. Genau, also das ist noch ein Draft, den Matt Corello 2019 mal

aufgeschrieben hat. Und genau, da geht es darum, dass es eigentlich vier bekannte Bugs gibt in Bitcoin, die man fixen könnte und vielleicht auch fixen sollte, weil sie ein Problem darstellen könnten. Das ganze Thema hat Antoine jetzt 2024, ich glaube im März, nochmal aufgegriffen und das nochmal aufgeschrieben einfach. Worum handelt es sich hier? Wie schlimm ist es eigentlich? Und genau, können wir es fixen? Und wie können wir es fixen? Und gibt es da vielleicht noch eine

offene Diskussion? Und wir haben uns gedacht, wir schauen uns das mal gemeinsam mit dir, Mörch, das Thema mal an. Sehr gut. Sehr gut. Okay, gut, dann gehen wir mal rein. Also es gibt

insgesamt vier. Wir fangen gleich mit dem ersten an. Das ist die sogenannte Time Warp Attacke. Ich habe es mal für mich übersetzt mit der Block Beschleunigungsattacke. Ich glaube, wir werden darauf kommen, wie wir das meinen. Wie wollen wir einsteigen? Ich denke, es gibt zwei Dinge, die wir voraussetzen müssen jetzt, um in die Diskussion oder in das Verständnis reinzukommen, nämlich die Regeln für Timestamps. Da gibt es genau zwei Stück. Timestamps dürfen zum ersten

nicht weiter als zwei Stunden in der Zukunft liegen. Jetzt ist die Frage natürlich, zwei Stunden von UTC nehme ich an, also universaler Zeit. Oder Mörch, weißt du das? Zwei Stunden von deiner eigenen Node. Zwei Stunden von meiner eigenen Node. Die Uhr deiner eigenen Node bewertet, ob, also ja, Zeitzonen natürlich auch. Aber wenn der Block mehr als zwei Stunden in der Zukunft liegt, dann akzeptiert deine Node den Block nicht. Okay. Und vielleicht auch gleich hier,

also die zwei Regeln, ja, sag erst die zweite Regel, dann zeige ich dir das. Okay, okay. Also die zweite Regel ist, der Timestamp, der auf einem Block draufgedrückt ist, der muss größer sein, als der Median der letzten elf Blöcke. Das ist die sogenannte Median Time Pace, also der Median der letzten elf Blöcke. Willst du gleich ergänzen, was daran vielleicht ein bisschen genauer ausgedrückt werden sollte? Nee, nee, super ausgedrückt. Die interessante Sache ist, eine von den zwei Regeln

ist eine Konsensusregel. Oh, okay. Nämlich nur, dass der Timestamp größer als der Median der letzten elf Blöcke sein muss, ist eine Konsensusregel. Das andere ist eine Acceptance-Regel, in dem Sinne, dass es, es kann gar nicht eine Konsensusregel sein. Wenn du nämlich einen Block veröffentlicht, der genau zwei Stunden und eine Minute in der Zukunft liegt, und du sendest den dann ans Netzwerk,

die meisten Nodes, also die mit den richtigen Uhrzeiten, tun die nicht, den verwerfen. Aber wenn du den drei Minuten später nochmal zur Verfügung stellst, dann ist der vollkommen akzeptabel. Das heißt, wenn der Block permanent invalid, ungültig wäre, dann wäre das, also wenn es eine Konsensusregel wäre, dann wäre er permanent ungültig. Aber das kann nicht der Fall sein für ein zukünftiges Event, weil die Blockchain kann grundsätzlich nur über Dinge entscheiden,

die in der Blockchain sind. Und damit quasi nur Dinge, die entweder in der Vergangenheit oder in der Blockchain passieren. Genau, und jetzt der Median-Time-Past, also dieser Zeitstempel, der ist ja in die letzten elf Blöcke eingeschrieben. Also die sind ja bereits in der Blockchain enthalten. Insofern ist das ein, ja, wie ist es jetzt, das ist der ausschlaggebende Wert oder ja, warum ist das jetzt eine Konsensusregel? Weil ein Block, der eine niedrigere

Timestamp hat als den Median der elf vorherigen, der ist halt permanent invalid. Der wird immer eine niedrigere Zeit haben als der Median der vorherigen elf. Vielleicht auch interessant ist, Median der vorherigen elf, warum nicht einfach der Block sechs vorher? Weil nämlich eben das Timestamp-Fenster ist so groß. Das heißt, es könnte durchaus passieren, dass ein Block,

der eine höhere Höhe hat, eine niedrigere Timestamp hat. Und das wäre erlaubt, aber du schaust dir also eben die Timestamps der letzten elf Blöcke an, sortierst die und nimmst den mittleren. Das heißt aber nicht unbedingt, dass es der mittlere Block von der Höhe ist, sondern nur eben der mittlere Block der Timestamps. Genau, ich sortiere die Timestamps, egal in welcher Reihenfolge sie reingekommen sind. Es gibt Blöcke, das hast du ja gesagt, die einen jüngeren

Timestamp haben können als frühere Blöcke. Genau, einen jüngeren Timestamp als frühere Blöcke. Ein jüngerer Block kann einen früheren Timestamp haben als ein älterer Block. Ja, genau. Es gibt verschiedene Wege, um das zu beschreiben, glaube ich. Aber ich glaube,

wir haben es jetzt verstanden. Vor allem, du könntest ja einfach einen Block veröffentlichen, der zwei Stunden in der Zukunft liegt und der nächste Miner, der dann einen Block ungefähr zehn Minuten später findet und das richtige Timestamp verwendet, der wäre ja dann eine Stunde 50 früher als der Block davor, auf dem er aufgebaut hat. Genau, aber das ist valide.

Und das wäre legal, aber eben in Grenzen. Das heißt, wenn dann Leute sagen, ja, Bitcoin ist eine Uhr, selbst muss ich dann immer sagen, ja, aber eine sehr impräzise Uhr. Ja, also genau, ich glaube, das ist auch noch nicht so einfach zu verstehen. Also ich gehe damit, Bitcoin ist tatsächlich keine Uhr, aber Bitcoin hat seine eigene Zeit. Aber diese eigene Zeit ist die Blockzeit und die ist halt gemessen an der Realzeit sehr unzuverlässig oder sehr

volatil. So, ne? Grob korreliert. Grob korreliert klingt professionell. Genau. So, jetzt haben wir noch gar nicht, also jetzt haben wir erst mal überhaupt über die Parameter gesprochen, unter denen wir Timestamps in Bitcoin-Blöcken vorfinden. Wir brauchen noch eine weitere Voraussetzung. Was müssen wir noch erklären? Das war mir selber auch noch nicht so klar, aber das Difficulty Adjustment berechnet sich aus dem Timestamp vom ersten und letzten

Block einer Periode, also von Block 0 und Block 2015 innerhalb einer Difficulty-Perioden. Die beiden Timestamps werden genommen und dann wird geschaut, wie lange hat es insgesamt gedauert, glaube ich. Dann geht man, glaube ich, davon aus, es sind 2016 Blöcke, also 10 Minuten, also 20.160 Minuten wäre der Erwartungswert. Na, okay. 2015 Blöcke. Und das ist genau das Problem. Ja, ja, okay. Okay, dann übergebe ich gleich dir das Wort.

Was ist eigentlich der Bug? Der eigentliche Bug ist, damit du überlappende Zeitfenster haben würdest, würdest du immer vom letzten Block der vorherigen Periode zum letzten Block der nächsten Periode rechnen müssen. Dann würdest du eigentlich die Zeit der gesamten Difficulty-Periode bekommen. Aber der Bug ist ein Off-by-one-Error. Du kriegst nur die Zeit vom ersten Block zum letzten Block

statt vom letzten Block zum letzten Block. Und dieser Off-by-one erlaubt dir eben, dass, wenn du immer den letzten Block verwenden würdest, wenn du den nach links oder nach rechts schiebst, also früher oder später, dann würde ja, wenn du es verfrühst, dann macht er zwar die vorherige Difficulty-Periode kürzer, aber die spätere länger. Aber dadurch, dass du den letzten Block verwendest, um die vorherige Difficulty-Periode-Zeit zu berechnen und den ersten Block als

den Startpunkt der nächsten Difficulty-Periode verwendest, sind die unabhängig. Und das ist genau das, was den Time Warp überhaupt erst erlaubt. Aber ich glaube, ich habe jetzt für mich etwas sehr Entscheidendes verstanden. Du sagtest gerade was von Unabhängigkeit zwischen diesen beiden Difficulty-Perioden. Es müsste eigentlich so sein, damit sie nicht unabhängig voneinander sind, sondern abhängig voneinander sind, wäre es eigentlich so, dass man immer

die 2016-Blocke zurückvergleicht. Also quasi den letzten Block der jetzigen Periode mit dem letzten Block der vorherigen Periode. Nur dann bekommst du quasi ein überlappendes Zeitfenster zwischen zwei Difficulty-Perioden. Weil aber der erste Block einer Difficulty-Periode und der letzte Block genommen werden, hast du eine Unabhängigkeit dieser Difficulty-Periode von der Difficulty-Periode davor. Und das ist das Problem. Da kommt es eigentlich her. Danke Jan-Paul, jetzt habe

ich das auch verstanden. Jetzt macht das auch Sinn. Die Lösung hast du ja gerade ein bisschen angedeutet. Aber ich würde jetzt gerne vielleicht, dass wir das Angriffsszenario nennen. Wir gehen jetzt ja, das Angriffsszenario ist vielleicht, um da schon mal so einen kleinen Einsprung zu machen, ist ja, dass die, die kommt von den Minern her. Also die Miner können prinzipiell, je nachdem, was für eine Art von Blöcke sie veröffentlichen, diesen Bug ausnutzen.

Genau, da wäre es vielleicht dann erstmal die Frage, was ist das Angriffsszenario? Genau, also dadurch, dass zwar die Zeit von Blöcken strikt steigen muss, nämlich sie muss immer höher sein als der Median der elf vorherigen Blöcke. Der Median der Timestamps der elf vorherigen Blöcke. Das heißt, im Prinzip geht die Zahl immer hoch, aber sie muss eben nicht so viel

hochgehen, wie das eigentliche Timestamp steigen würde. Der Angriff ist jetzt also, dass die, eine Mehrheit der Miner, der Angriff funktioniert nur, wenn du mindestens 50% der Hashrate verwendest. Wenn die alle anfangen, ein falsches Timestamp in Blöcke zu schreiben, und zwar die Zeit zurückhalten in Timestamps. Im ersten Block, sagen wir mal, sind wir bei Zeit 0. Im zweiten Block tun sie nur um eine Sekunde erhöhen. Im dritten Block erhöhen sie um eine Sekunde. Im

vierten Block erhöhen sie um eine Sekunde. Und dann im letzten Block tun sie die tatsächliche Zeit reinschreiben. Im nächsten Block, im ersten Block der nächsten Difficulty Period, beziehen sie sich aber dank des Medians eben wieder nur auf die Zeit von zwei Wochen vorher. Das heißt, für die erste Difficulty Period halten sie quasi die Zeit stehen nur ein paar tausend Sekunden mehr

als der erste Block. Und nehmen wir mal an, einfach die gesamte Hashrate ist beteiligt, aber mindestens die Hälfte, damit immer sechs Blöcke von den letzten elf müssen eben diese

uralte Zeit haben. Dann steigt der Timestamp von jedem Block nur um eine Sekunde und das erlaubt eben dem Angreifer im ersten Block von der nächsten Difficulty Period wieder die alte Zeit zu verwenden, weil eben vermutlich zehn von den elf Blöcken so einen niedrigen Timestamp haben, dass sie zwar im letzten Block der Difficulty Period die Normalzeit verwenden, aber oder sogar zwei Stunden in die Zukunft schieben, aber dann für den ersten Block in der neuen Difficulty

Period wieder die alte Zeit haben. Und was jetzt eben passiert ist, in der ersten Difficulty Period hast du die normale... Warte mal, können wir nochmal... Also ich würde da mal ganz kurz nicht bremsen, weil ich glaube, das müssen wir nochmal erklären. Das ist nämlich nicht ganz so einfach zu verstehen. Also ich habe zumindest zwei, drei Anläufe gebraucht, um das zu kapieren. Also das Ergebnis ist, na oder so, wenn Miner koalieren und eine 51% Attacke auf die Beine stellen können,

wahrscheinlich machen sie es eher mit 60, 70%. Machen wir einfach halber... Es ist eine 100% Attacke, sodass alle Blöcke von dieser koalierenden Minergemeinschaft erstellt werden. So, und dann machen sie sich folgendes zunutze, dass sie nämlich quasi gefälschte Timestamps herausgeben können, und zwar allein auf der Regel, dass sie schauen, was ist der Median der letzten elf Blöcke. Und so sind sie halt in der Lage, in einer Difficulty Period die ersten

2014 Blöcke jeweils eine Sekunde nacheinander zu bringen. Also so wie du das eben erklärt hast. Du machst Anführungszeichen-Merge... Also die Blöcke werden ja nicht jede Sekunde gefunden, sondern die Timestamps werden gesetzt. Also sie brauchen zwei Wochen ungefähr, um die Blöcke zu finden, aber die Timestamps steigen nur um 2014. Genau, so. Und jetzt der 2015. Den Block, dem geben sie die reale Zeit, und diese zwei Stunden

plus sind, glaube ich, nur noch mal eine Optimierung. Das ist quasi das Maximum, dass sie aus dieser... Genau, es ist Sahnehäubchen. Darum geht es gar nicht, um diese zwei Stunden, sondern es geht darum, okay, den letzten Block, den bringen sie zur reellen Zeit. So, dann haben wir... Dann ist im Grunde noch nichts passiert, weil wir dann eine Difficulty Period haben, die quasi, wie erwartet, zwei Wochen gedauert hat,

und die Difficulty ändert sich nicht. Aber in der nächsten Difficulty Period können die Miner, weil sie auf die letzten elf Blöcke zurückblicken können, können sie quasi den ersten Timestamp des ersten Blocks nahezu vor zwei Wochen, also quasi 2015 Sekunden oder 2016 Sekunden nach dem vorherigen Difficulty Period, können sie die jetzt setzen. Nach dem ersten Block der vorherigen Difficulty Period. Genau, also sagen wir mal einfach halber so nach, sagen wir mal, 2016 Sekunden.

Also eine halbe Stunde, ein bisschen mehr als eine halbe Stunde mehr. Genau, genau, da setzen sie den wieder. Und dann fängt diese Attacke anzugreifen, weil sie dann wieder die Timestamps sekundenweise setzen, bis es dann quasi zum letzten Block dieser Periode kommt. Und dann wird das gleiche Spiel wieder. Da wird der reelle Timestamp gesetzt. Und dann kommt das Interessante. Dann wird nämlich verglichen zwischen dem, das hatten wir eben,

dem letzten Timestamp und dem ersten Timestamp. Und dann stellt sich die Blockchain auf einmal fest. Huch, da sind jetzt eigentlich vier Wochen vergangen. Also muss ich ja die Difficulty halbieren. Und das ist quasi der Angriff, der passiert. Und das wird wiederholt. Und Antoine in seinem Artikel führt dann aus, dass diese Attacke, das dauert nur 40 Tage und dann sind wir bei einer Difficulty von eins. Und das ist das Einfachste, was wir an Blöcken haben können.

Und dann regnet es Blöcke. Genau. Und der Witz ist, also die ersten 14 Tage passiert gar nichts, weil man natürlich auf die vorherige Difficulty festgelegt ist. In den zweiten zwei Wochen passiert auch immer noch nichts, weil die Difficulty ja noch nicht runtergegangen ist. Also nach 28 Tagen kann jeder sehen, dass die Timestamps, offensichtlich jemand was mit den Timestamps macht, aber es ist noch nichts passiert. Und dann innerhalb von zwölf Tagen fangen die Blöcke

an exponentiell schneller zu werden, bis die Difficulty eins ist. Und zwar die fünfte Woche ist nämlich jetzt interessant. Die dritte Difficulty Period dauert nur etwa sieben Tage, weil ja die Difficulty sich halbiert hat nach der vierten Woche. Also der zweite Difficulty Adjustment halbiert die Difficulty. Das heißt, die nächsten 2016 Blöcke brauchen nur ungefähr eine Woche. Aber jetzt geht die Difficulty auf 40 Prozent runter von der vorherigen,

also 20 Prozent insgesamt schon von dem Start des Attacks, des Angriffs. Und jetzt dauert es nur noch 2,8 Tage, um die nächste Difficulty Period abzuarbeiten. Dann geht es weiter runter und so fort. Die Blöcke kommen immer schneller, die Difficulty Period geht aber immer schneller runter, weil die Realzeit immer noch voranschreitet gegenüber der Original Startzahl vom Angriff. Und nach ungefähr 40 Tagen erreicht man tatsächlich Difficulty eins. Wahrscheinlich würde dann der

Miner oder der Angreifer leere Blöcke oder sogar einfach das UTXO-Set bloaten. Also er würde die komplette Blockbelohnung bis 2140 innerhalb von diesen 40 Tagen einsammeln können und zwischenteilig praktisch nur leere Blöcke oder sogar UTXO-Bloat minen. Also das mit den leeren Blöcken verstehe ich. Das mit dem UTXO-Bloat, kannst du das nochmal

erklären, was du damit meinst? Ja, er könnte ja auch einfach nur Transaktionen in die Blöcke packen, die von ihm selbst sind, die ganz ganz viele Outputs erzeugen und das UTXO-Set aufblasen. Okay, es geht nur darum, dass er irgendwelche, also dass das UTXO-Set einfach möglichst hochniveaus macht. Also wenn er eh schon irgendwie schabernacktreibt,

kann er zum Beispiel das jetzt noch kombinieren mit "Adding Insult to Injury". Also nicht nur die Blöcke alle sammeln, die gesamte Blockrewort monopolisieren, sondern er würde dann auch noch vielleicht das UTXO-Set voll packen mit Müll. Ja, verstehe ich. Ist dir das klar, Thorsten? Ja, ich habe das verstanden. Ich würde gerne aber nochmal so als Ergänzung, warum das genau 40 Tage dauert. Ich meine mich ja zu erinnern, dass wir ja bei der Anpassung der Schwierigkeit ja gewisse Grenzen haben,

dann also in die eine oder die andere Richtung. Vielleicht müssen wir das nochmal klären, weil ich glaube, nach oben ist die Anpassung ja durchaus begrenzt. Da ist irgendwie nur ein Viertel oder sowas gewesen. Also nach unten scheint sie jetzt ja größer zu sein als nach oben. Ne, in beide Richtungen maximal ein Viertel. Sorry, Faktor 4. Also die Difficulty kann entweder sich vervierfachen oder auf 25% schrumpfen.

Aber, wenn jetzt eben die dritte Difficulty Period ist ja halbiert, also dauert nur noch sieben Tage. Aber danach sind ja fünf Wochen vergangen, die mit den zwei Wochen angepeilter Zeit verglichen werden, sodass es eben zu 40% der vorherigen Difficulty geht. Aber die vorherige Difficulty war ja schon halbiert. Das heißt, wir sind schon bei 20% nach der

dritten Difficulty Period. Ich hätte das weiter ausgerechnet, aber ich glaube, das nächste Mal geht es dann schon auf 13% oder 12% oder so runter. Vielleicht ist es auch gar nicht so wichtig. Es ist auf jeden Fall klar, es geht relativ schnell die Difficulty runter auf den einfachsten Schwierigkeitsgrad. Genau, und dann gibt es halt ganz, ganz viele Sachen. Also es wird ja mindestens immer danach zu noch weniger als 40% von der vorherigen gehen. Und diese Prozentzahl schrumpft ja weiter,

während die Realzeit weiterläuft. Ja, okay. Also jedenfalls geht dann ruckzuck. Ja, jetzt die Frage natürlich, was ist das Problem daran? Also ja, okay, dann werden auf einmal alle Rewards eingesammelt. Vielleicht haben wir noch das Problem, wie hast du es genannt, Insight to Injury, dass wir ein geblotetes, aufgeblähtes UTXO-Set bekommen. Was wäre

denn noch problematisch an der ganzen Geschichte? Naja, zum Beispiel haben wir jetzt einige Protokolle, die auf Bitcoin aufbauen, die darauf bauen, dass wenn die Gegenseite bescheißt, man Zeit zu reagieren hat. Und diese Zeit mit Object Sequence Verify ist natürlich an Block Blöcke gefunden, geknüpft. Also wenn du zum Beispiel einen...

Ja, genau. Wenn du versuchst, einen Lightning Channel zu schließen, oder genauer genommen, wenn jemand versucht, einen Lightning Channel zu schließen mit einem alten Zustand, aber die Blöcke durchrauschen mit 100 Blöcken pro Minute oder so, dann sind natürlich 100 Blöcke relativ wenig Zeit zu reagieren, um deine Justice Transaction durchzukriegen. Also zum Beispiel alle Lightning Channels wären jetzt quasi von jedweitiger Seite sofort

zu einzusammeln. Und ja, überhaupt alles, was irgendwie an diese Annahme, dass Zeit und Blockhöhen einigermaßen korreliert sind, geknüpft ist, fängt eben an zu scheitern. Und das natürlich unabhängig davon, dass ja sowieso das Vertrauen irgendwie in das komplette Netzwerk irgendwie dann erstmal maßgeblich geschädigt ist, weil halt ja quasi alles, worauf es irgendwie gefußt hat, irgendwie torpediert wurde dann dadurch.

Ja, das ist jetzt interessant zum Beispiel in dem Kontext, dass zumindest ein Entwickler sich dagegen wehrt, dass das gefixt wird. Nämlich das wäre eine Art, ein Softfork zu machen, mit der wir die Blockintervalle verkürzen. Du könntest nämlich jetzt die Miner dazu tatsächlich anspornen, dass sie diesen Time Warp Bug ausnutzen und dass sie

dann vielleicht vier Blöcke pro zehn Minuten sammeln. Und das würde uns dann natürlich hier mal so viel Block Space geben, aber das ist ein Spiel mit Feuer, weil du dann den Minern natürlich eh schon in die Situation versetzt, dass sie den Time Warp Bug ausnutzen. Und damit haben sie quasi die ersten zwei Wochen mindestens schon, vielleicht sogar mehr als die ersten zwei Wochen vom Angriff vorbereitet.

Das habe ich noch nicht ganz verstanden. War jetzt die Aussage, dass wenn der Fix für dieses Time Warp Problem oder die Blockbeschleunigungsattacke, wenn das bekannt wird, dann würden die Miner eben genau diese Blockbeschleunigungsattacke durchführen? Ist das das Argument? Nee, nee. Nee, okay, dann habe ich es nicht verstanden. Jemand wollte nicht, dass dieser Bug repariert wird. Vielleicht reden wir erst mal darüber, was der Fix ist. Genau, lass uns, genau.

Ja, also wie wir vorhin ganz am Anfang schon gesagt hatten, das Problem ist, dass die zwei Difficulty Periods, die aufeinander folgen, unabhängig sind. Und dementsprechend kann man das Problem mitigieren, indem man verlangt, dass der erste Block von der zweiten Difficulty Period zeitnah im Timestamp sitzt, vom Timestamp des letzten Blocks der vorherigen Difficulty Period. Und das ist hinreichend, weil natürlich die Difficulty berechnet wird vom Timestamp

des ersten und des letzten Blocks. Das heißt, wenn, ich glaube, der konkrete Vorschlag ist, dass der erste Block von einer neuen Difficulty Period kann nicht mehr als zehn Minuten vor dem Block, vor der Timestamp des letzten Blocks vorher liegen. Also der 2015. Block der ersten Difficulty Period könnte zehn Minuten in der Zukunft liegen vom ersten Block der zweiten

Difficulty Period, aber nicht mehr. Und das verhindert, dass man eben den ersten Block zwei Wochen in der Vergangenheit hält und dementsprechend kann man eben diesen Schabernack nicht mehr treiben. Und in dem Kontext konkret hat ein Entwickler gesagt, wir sollten das nicht fixen, weil das uns die Möglichkeit nimmt, einen Soft-Fork zu machen, mit dem

wir schnellere Blockintervalle haben könnten. Konkret die Idee ist, Block Space Increases ein Hard-Fork, aber mit dem Time Warp Bug könntest du eine Blockintervallverkürzung als Soft-Fork machen, indem du eben Miner zwingst, dass sie die Timestamps in der Vergangenheit halten und dementsprechend die Difficulty künstlich niedriger gehalten wird, als sie ist, und Blöcke tatsächlich alle zweieinhalb Minuten reinkommen. Egal.

Ich kann nicht sagen, dass ich das verstanden habe. Das übersteigt gerade meine Vorstellungskraft Also genau wie der Angreifer bescheißen kann und eben die Timestamp vom ersten Block in der Vergangenheit halten kann, kann ein Kartell der Miner Ein gewolltes Verhalten dann, ne? Ja. Könntest du das mit einem Soft-Fork erzwingen und dann könnte ein Kartell der Miner die Difficulty auf einem Viertel der echten Difficulty halten. Und dann hättest du Blöcke alle zweieinhalb Minuten reloaden können.

Also aber während der Aktivierung des Soft-Forks? Wenn der Soft-Fork aktiv wäre, würde der eben verlangen, dass die Miner mit dem Timestamp bescheißen. Die Timestamps wären dann vollkommen entkoppelt von der echten Zeit. Aber würden dazu führen, dass du viermal so viele Blöcke hast. Okay, lass uns. Sorry, vielleicht stehe ich da gerade auch komplett auf dem Stoff. Nicht so wichtig. Machen wir mal eine andere Folge drüber. Oder lieber eigentlich nicht,

weil es eine scheiß Idee ist. Na gut, also wir fassen nochmal zusammen. Also der Fix ist, soweit ich das jetzt verstanden habe, auch nicht sonderlich kontrovers. Also es gibt eine breite Zustimmung, glaube ich, dafür, dass man einfach den Timestamps des ersten Blocks einer Difficulty-Periode begrenzt durch den Timestamp des letzten Blocks der vorherigen Difficulty-Periode. Das heißt, die müssen irgendwie beieinander liegen.

Thomas hat erklärt, der Block der vorherigen Periode darf maximal zehn Minuten nach dem ersten Block der neuen Periode liegen. Also der Timestamp natürlich. Ja. Genau. Okay. Das Problem, das damit mit diesen zehn, also woher die zehn Minuten kommen, ist, anscheinend hat manche Mining-Hardware in der Firmware programmiert, dass du bis zu zehn Minuten brauchen kannst. Das heißt, die machen Time-Rolling. Das ist ein altes Konzept, wo du zusätzliche

Entropie kriegst, dadurch, dass du das Timestamp änderst. Und die Firmware verlangt, dass du mindestens zehn Minuten Platz hast. Das heißt, wenn jemand den letzten Block in der Difficulty-Period zwei Stunden in die Zukunft schieben würde, könntest du immer noch 150 Minuten bis zwei Stunden als dein Time-Rolling-Fenster verwenden. Und da kommen eben die zehn Minuten. Ja, okay. Ich glaube, das ist auch nochmal ein eigenes Thema. Also woher kommt das eigentlich,

dass wir diese völlig merkwürdigen Timestamps bekommen können? Aber da wollen wir jetzt, glaube ich, heute nicht drauf eingehen. Aber ich denke, das Thema Time Warp oder Blockbeschleunigungsattacke

haben wir damit durch. Ich würde ganz gerne mal zum zweiten Thema kommen. Und das wäre Worst-Case-Block-Validation-Time. So heißt das. Also mein Verständnis davon ist, es gibt Transaktionen in Blöcken, hier insbesondere Non-Sequit-Transaktionen, die relativ aufwendig darin sind, validiert zu werden. Also das heißt, sehr vereinfacht gesprochen, wenn du als Node von einem neuen Block hörst, dann schaust du dir den Block an, schaust dir auch

die Transaktionen darin an und schaust, ob diese Transaktionen gültig sind. Das machst du, indem du zum Beispiel prüfst, ob die Signaturen darin valide sind. Also du berechnest quasi diese ECDSA. Das war jetzt, glaube ich, falsch ausgerückt. Aber mit dem ECDSA berechnest du quasi die Gültigkeit der Signatur dieser Transaktion. Genau. Und jetzt gibt es aber Umstände, und das kann uns der Murchant vielleicht ein bisschen erklären, unter denen eben

dieses Validieren eines Blocks sehr, sehr lange dauern kann. Also in dem Beispiel von dem Antoine Ponçon, der hat das mal gebenchmarked mit seinem Gerät auf seinem Laptop, hat das dann, ich habe es irgendwo aufgeschrieben, hier, ich glaube, drei Minuten gedauert mit seinem Laptop. Auf einem Raspberry Pi 4 kam er da auf ganze anderthalb Stunden. Und das ist natürlich dann klar, dass das problematisch ist, wenn du einen Block bekommst und du brauchst

anderthalb Stunden, um überhaupt zu prüfen, ist das überhaupt ein gültiger Block. Genau. Jetzt, Murchant, also die Frage erstmal an dich. Also soweit, glaube ich, passt die Beschreibung, würde ich sagen. Kannst du vielleicht mal ein bisschen erklären, woher diese langen Validierungszeiten herkommen können? Ja, also Antoine möchte zurzeit eigentlich noch nicht genau über die Muster reden, mit denen man solche sehr, sehr teuer zu validierende

Transaktionen bauen kann. Aber es gibt schon ein paar in der Vergangenheit, wo man das so ein bisschen sehen kann. Insofern denke ich, dass die einfachen, also es gab diese Megatransaktion in 2015, wo ein Miner einen Haufen Dust ausgegeben hatte. Und dieser Block illustriert das Quadratic Hashing Problem. Also Segwit hat ja verändert, was genau signiert wird in einer Bitcoin-Transaktion. Also wenn wir eine Bitcoin-Transaktion signieren, dann

müssen wir ja uns zu dem gesamten Inhalt dieser Transaktion bekennen. Also alle Inputs, alle Outputs, wenn die nicht so da sind, ist meine Signatur ungültig. Sonst macht ja die Signatur in dem Sinn. Wir reden mal nicht über die Ausnahmen. Das hatten wir übrigens in der Folge, als wir über Transaktionen gesprochen haben, hatten wir genau das, was signiert eigentlich eine Transaktion. Und da war nochmal klar,

dass es ein Gerüst gibt innerhalb dieser Transaktion, das signiert wird. Und natürlich die Signatur selber kann natürlich nicht Teil dieser Signatur sein, sonst hätten wir einen Zirkel. Aber hört da gerne nochmal in diese Folge mit Merge rein, da haben wir es nochmal ein bisschen erklärt. Genau. Und also jedenfalls dieses Commitment-Hash, das erzeugt wird von der ganzen Transaktion, damit man eben einen Fingerabdruck von der

Transaktion hat, den man signiert. In Non-Circuit-Transaktionen braucht es eine quadratische Berechnung, um den zu berechnen für jeden. Man muss nämlich für jeden Input einen anderen Commitment-Hash berechnen. Und je mehr Inputs man hat, desto mehr Commitment-Hashes muss man berechnen.

Aber man muss natürlich auch mehr Daten in diesem Commitment-Hash verarbeiten. Das heißt, wenn man also eine Transaktion mit extrem vielen Inputs hat, dann tut man, also Legacy-Inputs, nicht Segment-Inputs, dann tut man jedes Mal ein Commitment-Hash berechnen, wo eben diese eine Signatur freigelassen wird und mit einem Dummy-Element ersetzt wird. Alle anderen müssen neu berechnet werden. Je mehr Daten da sind, desto größer ist die einzelne Berechnung.

Aber dann muss man das einmal pro Input machen. Das ist ganz klassisch das Quadratic-Hashing-Problem. Und mit SegWit wurde das eben verbessert, sodass der größte Teil des Commitment-Hashes

gleich für jeden Input ist. Es ist immer noch wichtig, dass die Signatur, die man gibt, nur für einen bestimmten Input gültig ist, sodass man nicht, wenn man zum Beispiel mehrere Inputs in einer Transaktion hat, die das gleiche Output-Script haben, man möchte nicht mit einer Signatur für einen Input gleichzeitig auch andere Inputs signieren, weil das zu diversen Unsicherheits-, also Angriffspotenzialen führt. Insbesondere, wenn man zum Beispiel

eine Hardware-Wallet anlügt, was die anderen Inputs auf einer Transaktion sind. Können wir auch mal im Detail reingehen. Jedenfalls, Quadratic-Hashing ist quasi ein Beispiel, das einigermaßen bekannt ist, wie man Transaktionen bauen kann, die erstaunlich lange zu validieren brauchen, länger als sie sollten. Ja, ich glaube, das reicht uns auch an dieser Stelle. Also das ist einfach gegeben. So ist einfach Bitcoin strukturiert. Es gibt also die Möglichkeit, dass diese Blöcke erscheinen,

die für schwachbrüstige Nodes schwierig zu berechnen sind. Die Frage ist natürlich,

welchen Impact hat das auf das Netzwerk? Also was bedeutet das genau? Wo ist der Schaden, der Impact dieses Bugs? Ja, zum Beispiel, wenn ein kleiner Miner so einen Block bauen würde, oder vielleicht sogar nur eine einzige Transaktion, die extrem lange zu validieren braucht in dem ganzen

Block, und diesen Block dann eben ans Netzwerk schickt. Jeder Node, der den Block kriegt, ist erstmal, weil Single-Threaded in der Berechnung bleibt stecken, und arbeitet jetzt, sagen wir mal drei Minuten mindestens, vielleicht sogar anderthalb Stunden, wenn es ein Raspberry Pi ist, daran zu validieren, ob dieser Block gültig ist. Und in der Zeit wird der Angreifer, der den Block veröffentlicht hat, lustig vor sich hinminen, während niemand sonst

mit ihm im Wettbewerb steht. Natürlich, wenn das ein kleiner Miner anfängt, dann tun wahrscheinlich die großen Miner sagen "Ja, hallo", und können natürlich dann zum Gegenschlag ausholen und das auch machen. Und das tut den kleinen Minern dann noch viel mehr weh als den großen Minern. Und dann fühlen sich vielleicht alle Miner plötzlich in der Situation, dass sie immer diese Blöcke minen müssen, damit sie in einem fairen Wettbewerb zueinander stehen.

Und dann können wir auch keine Transaktionen mehr darin unterbinden. Also insgesamt, das ist alles eher hässlich. Vor allem einfach, also es ist tragisch, das ist so, diese Blöcke können gebaut werden, aber man könnte zumindest gewisse Regeln einführen für diese Legacy-Transaktionen

und zusätzlich die beschränken, wie schlimm das sein könnte. Und die Hoffnung wäre, dass dadurch, dass diese Transaktionen jetzt schon non-standard wären, also generell von den meisten Bitcoin-Nodes im Netzwerk gar nicht weitergeleitet werden würden oder in den Mempool aufgenommen werden würden, dass niemand sich darauf verlässt, dass diese

Transaktionen gültig sind und angenommen werden. Das heißt, die Angst wäre eben, dass, wenn man neue Regeln einführt und beschränkt, welche Transaktionen gültig sein dürfen, dass man dabei Leute darum bringt, ihre Bitcoin ausgeben zu können. Und das möchte man natürlich nicht. Also im Prinzip schon gar nicht. Ja, okay. Ich glaube, das würde mir an dieser Stelle reichen, weil ich hier noch eine Frage

habe, das konnte ich mir noch nicht so ganz erklären. Du hattest das eben ja schon kurz angedeutet, man möchte gar nicht so genau darüber sprechen, welche Transaktionen das denn sind, die eben diese langen Blockvalidierungszeiten auslösen. Denn es ist ja klar, sobald diese Information öffentlich ist, ist es natürlich ein leichtes für einen Angreifer eben genau diese Transaktionen zu konstruieren oder eine solche Transaktion zu konstruieren und damit

das Netzwerk zumindest zu schaden oder anzugreifen. Insofern kann ich das verstehen, dass diese Diskussionen natürlich im kleinen Kreis stattfinden. Die Frage, die sich für mich noch nicht aufgelöst hat, war, irgendwann müsst ihr ja mit der Lösung um die Ecke kommen. Also irgendwann müsst ihr ja quasi rauskommen und sagen, okay, das haben wir uns jetzt überlegt, um

diesen Schaden zu minimieren. Ist es nicht so, dass ein schlauer Angreifer genau an diesem Punkt dann sieht, okay, was kann ich denn jetzt noch machen, was dann ab Aktivierung des Soft Forks nicht mehr möglich ist und haben wir dann nicht ein Zeitfenster, wo genau dieses Problem dann auftreten könnte oder die Wahrscheinlichkeit einfach exponentiell größer wird, als sie jetzt ist. Und ich weiß noch nicht genau, also habt ihr euch

darüber Gedanken gemacht, wie löst man das auf? Ich kann es mir noch nicht erklären. Das ist ein sehr guter Punkt und ja, das wäre eine Möglichkeit. Ich glaube, eine Idee könnte sein, dass man vielleicht Blockvalidierung unterbrechen kann, wenn ein Block schon lange gebraucht hat, um validiert zu werden und man einen anderen Block angekündigt bekommt von seinen Peers, dass man wechselt und schaut, ob man den schnell validieren kann. Also zurzeit

ist Blockvalidierung oder generell Bitcoin Core ist Single Threaded. Es tut also immer nur ein Ding und alles ist unterbrochen, während es einen Block validiert. Das heißt, wenn man das schafft, dass zum Beispiel Peer-to-Peer von Blockvalidation hinreichend getrennt ist, dass wenn ein weiterer Block angekündigt wird, man eben Blockvalidierung unterbrechen kann, parallel einen anderen Block prüfen kann, wenn der sofort durchgeht, dass man einfach sagt, okay, das ist der neue beste Block

und ich gebe auf, diesen langsamen Block zu validieren. Ich weiß nicht, ob Antoine jetzt oder andere in der Richtung schon an einem Patch arbeiten oder irgendwas, aber das wäre zum Beispiel eine Möglichkeit, die mir jetzt einfällt. Aber das wäre ja dann eigentlich auch keine Anpassung vom Konsens, oder? Weil das ja einfach nur ein Verhalten innerhalb von Bitcoin Core wäre,

wie dann die Validierung stattfindet. Ich habe zum einen den, sage ich mal, den schwierigen Block, der vielleicht jetzt auf meinem Raspberry Pi eine Stunde dauern würde, und ich kriege von irgendjemand anderem dann fünf Minuten später den gleichen Block. Für mich ist der andere ja dann durchaus schneller validierbar, also leite ich den ja weiter. Wenn diese Logik natürlich dann bei hinreichend vielen kleinen Nodes ankommt, dann propagieren die ja prinzipiell

mehr den einfacheren Block als den größeren. Das ist natürlich nur dann die Frage, was ist mit Nodes, die halt super viel Rechenpower haben und das Ding halt irgendwie trotzdem innerhalb von ein paar Sekunden oder ein paar Millisekunden dann validieren können im Vergleich zu einem Raspberry Pi. Die leiten den ja trotzdem dann weiter. Für so Monster-Server-Nodes ist das ja

dann eigentlich keine Lösung. Ja, und falls eben diese Monster, also wenn du einen Mining Pool betreibst, dann hast du wahrscheinlich da schon einigermaßen an brauchbaren Rechner stehen. Das heißt, die werden diese Blöcke eher weniger als drei Minuten brauchen und dann ist es eben Teil der besten Chain und dann macht es für normale Node-Betreiber schwierig, die Blockchain zu verarbeiten, weil die müssen ja dann trotzdem dadurch,

die müssen den Block trotzdem validieren. Und das ist vielleicht die andere große Gefahr, ist, wenn viele dieser Blöcke auftreten, die Mining Pools trotzdem damit zurechtkommen, aber für den End-User wird es extrem teuer, die Blockchain zu validieren. Okay, ich glaube jetzt in der Diskussion sollte ein bisschen rausgekommen sein,

dass sich, also das ist wirklich ein Bug, dem wir alle Aufmerksamkeit schenken sollten. Das wäre jetzt zumindest meine Interpretation, weil das ja doch in meinen Augen größten Auswirkungen auf das Bitcoin-Netz erhaben könnte. Und halt auch ein Szenario, was ja auch quasi unabhängig von der Hashrate passieren kann. Also was jetzt quasi irgendjemand machen kann, der einfach so eine krasse Transaktion veröffentlicht. Ja, jeder Miner könnte diesen Block minen.

Ja, genau. Also ich weiß, du bist in dem Thema natürlich nicht so tief involviert, das hast du im Vorgespräch kurz angedeutet. Aber was ist denn so dein Eindruck? Ich meine, du sprichst ja auch mit deinen Kollegen, die sich mit diesem Problem jetzt intensiver beschäftigen. Also ist es lösbar aus ihrer Sicht oder aus jetziger Perspektive? Man kann

ja jetzt nicht sagen, es wird jetzt gelöst, das Problem. Aber sind sie da auf einem guten Weg oder sehen sie den möglichen Soft Fork erst in zwei Jahren oder drei Jahren kommen? Ich glaube, dass die Lösungen hier alle nicht so furchtbar komplex sind. Hier würde man einfach wahrscheinlich Limits einführen für gewisse Bestandteile von Transaktionen, dass die nur so und so häufig auftreten dürfen. Es wäre eben wichtig, dass man niemanden seine Coins konfisziert,

also unausgegaber macht. Ich glaube aber, was da so ein bisschen im Konflikt steht, ist dieses hochheilige Prinzip, dass man eben keine Coins konfisziert und es theoretisch möglich sein könnte, dass irgendjemand eine vorsignierte Transaktion gebaut hat vor vielen Jahren und darauf baut, dass sie ihre Unmenge an Bitcoin irgendwann durch diese Transaktion, durch dieses Nadelöhr in Freiheit schicken. Und wenn man diese Regel einführt, plötzlich ihr Geld unausgegaber

wird. Aber in Praxis, wenn irgendjemand diese Konstruktionen verwenden würde, dann sollten wir die gesehen haben, mindestens in Testnet, vielleicht in Mainnet. Irgendjemand sollte diese Konstruktionen verwendet haben, sonst wäre es vollkommen unverantwortlich von irgendjemandem, dass sie eine geheime, vorsignierte Transaktion gebaut haben, die ein Muster verwendet, das nie irgendwo sonst gesehen wurde. Aber ja, da ist eben dieses Prinzip, wir wollen nie irgendwie

jemandem seine Coins wegnehmen, gegenüber in der Praxis ist es wahrscheinlich okay. Und da ist irgendwie so die Reibung, wie viel ist okay, wie viel ist nicht okay. Also könnte eventuell nochmal spannende Diskussionen geben, wenn ich das Problem so… Also je nachdem, wer es aufgreift

und wie vehement er seine Position vertritt. Vielleicht auch ein bisschen verwandt zu der Diskussion mit den Inscriptions und Ordernotes im letzten Jahr, wo eben einerseits ist, wer bestimmt denn, was akzeptable Transaktionen sind und was man machen darf oder nicht machen darf auf dem Netzwerk, gegenüber was möglich ist. Und fällt so in ein ähnliches Lager. Lass uns das Thema hier ruhen lassen. Ich glaube, wir haben es ausreichend besprochen. Wir haben

nämlich noch zwei Themen vor uns und die Zeit rennt. Vielleicht kriegen wir es ein bisschen kürzer hin. Ja, okay, das dritte Thema. Da muss ich sagen, da habe ich echt mitgekämpft.

Merkle Tree attacks using 64 bytes Transactions. Ja, also ich kann ja mal… Soll ich mal versuchen, zu erklären, was ich meine habe, verstanden zu haben? Oder Magst du einen Aufschlag machen? Sonst darf ich gerne mal versuchen, zu erklären, was ich meine, verstanden zu haben. Also ich muss sagen, ich habe mir… Ja, fang du an. Genau, lassen wir den Anfänger machen und dann können wir gucken, ob wir es irgendwie korrigieren können. Vielleicht ist das ja ein Ansatz,

den wir verfolgen wollen. Also ich beziehe mich jetzt auf den Podcast, der jetzt gerade neu rausgekommen ist. Hier Bitcoin Explained, also wo Sörs Provost und Aaron van Wyrdom regelmäßig sprechen. Und die haben genau diesen Artikel auch besprochen. Einfach ein Zufall, dass das jetzt kam. Und da habe ich mir versucht, das anzuhören. Und also die Show packen wir euch in die Show Nodes natürlich. Und da auch hat Aaron van Wyrdom sehr gestruggelt, sehr damit gekämpft,

dieses Problem zu verstehen. Ich versuche es mal mit einem einfachen Beispiel zu erklären. Also wir nehmen an, ich bin ein Miner und der Thorsten ist eine validierende Node. Und ich schicke dem Thorsten einen Block. Und… Ah ne, vielleicht muss ich noch eine Ebene früher anfangen, glaube ich. Ich glaube, wir müssen darüber reden, wie Merkle Trees funktionieren. Ja, ich glaube auch. Genau, wir müssen erst mal erklären, was ist ein Merkle Tree. Aber Mörsch,

das kannst du doch bestimmt erklären. Was ist ein Merkle Tree? Wofür benutzen wir ihn? Sehr gut. Also ein Merkle Tree ist ein Binärbaum, der gebaut wird, indem wir anfangen bei den Transaktionen. Also eine Liste der Transaktionen. Das sind die Blätter in unserem Baum. Und wir tun dann die paarweise hashen, indem wir erst jede Transaktion selbst hashen, um eine TxID zu erhalten. Dann diese TxIDs von Transaktion A und B aneinander dran flanschen. Das nennt man eine

Konkatenation. Also der TxID A einfach verknüpft mit Transaktions-ID B. Das wird wiederum gehasht und dann mit dem Hash verbunden, das aus Transaktion C und D kam und so weiter. So geht das eben. Auf jeder Ebene halbiert sich die Zahl der Nodes, bis wir eben am Ende nur noch einen Node übrig haben. Das ist die sogenannte Merkle Root. Die packen wir in unseren Blockheader, um ein Commitment zu haben, dass alle diese Transaktionen, die in dem Hashbaum, also in

dem Merkle Tree, vorhanden sind, eben in dem Block enthalten sind. Die Konstruktion ist leider etwas seltsam. Nämlich die Operation, die auf einer Transaktion durchgeführt wird, um die Transaktions-ID zu erhalten, ist ein Doppel-SHA-256. Aber die inneren Nodes und die TxIDs und überhaupt alle Schritte in dem Baum sind auch SHA-256-Doppel-Hashes. Das heißt, wir unterscheiden nicht zwischen TxIDs

und inneren Nodes. Die werden gleich behandelt. Die andere Schwäche ist, dass wenn wir eine ungerade Zahl von Nodes haben, egal welcher Ebene, dann wird der nächste Node obendrüber gebildet, indem das letzte Element wiederholt wird. Das heißt, wenn wir drei Transaktionen ABC hätten, dann ist das erste Hash TxID A und TxID B und das zweite Hash ist TxID C, konkret mit TxID C wiederholt. Da gibt es ein paar Probleme mit, aber hier insbesondere gibt es zwei mögliche

Probleme. Zurück zu dir. Okay, ich verstehe, worauf du hinaus willst. Das ist das, was in Antoines Artikel beschrieben ist. Aber ehrlich gesagt habe ich das da nicht verstanden, sondern habe das jetzt so verstanden, wie es der Seurs in seinem Podcast erklärt hat. Und er sagt, es gibt ein Problem mit diesen 64-Byte-langen Transaktionen. Die sind halt

möglich. Es gibt halt Transaktionen, die sind halt genau 64-Byte-lang. Das Problem ist, dass wir nicht unterscheiden können, ob es sich um eine 64-Byte-Transaktion handelt oder um zwei mal quasi den Doppelschad 256 von zwei Transaktionen, die nämlich genau 32-Byte jeweils lang sind. Also so sehen zwei 32-Transaktions-Hashes genauso aus wie eine 64-Byte-Transaktion. Und damit kann ich jetzt ziemlich einen Unsinn bauen. Und zwar, jetzt kann ich da weitermachen, was ich

eben erklären wollte. Also ich bin jetzt zum Beispiel dieser Unsinn bauende Miner und schicke dem Thorsten, seiner validierenden Node, einen Block und sage ihm, pass mal auf, hier ist eine 64-Byte-Transaktion drin. Und der Thorsten schaut sich diesen Block an, prüft die, kalkuliert die und stellt fest, hey, diese 64-Byte-Transaktion ist ja ungültig. Genau. Gleichzeitig habe ich

dem Murch denselben Block geschickt. Allerdings habe ich ihm mitgeteilt, dass da nicht eine 64-Byte- Transaktion dran ist, sondern dass es sich um zwei gültige Transaktions-Hashes handelt, je A32-Byte. Murch prüft diesen Block und sagt, hey, das ist super, das ist ein gültiger Block, den nehme ich. Das Problem entsteht dabei, wenn Murch jetzt hingeht und Thorsten informiert, hey Thorsten, ich habe hier einen gültigen Block gefunden. Ich sehe, du bist ja noch auf dem letzten

Block, also noch nicht auf dem aktuellen Block. Dann schaut Thorsten sich diesen Block an, sieht den Merkle-Root, der nämlich für beide Blöcke unglücklicherweise gleich ist und sagt, hey, diesen Block habe ich schon gesehen, den brauche ich nicht, danke schön, den habe ich schon als ungültig anerkannt. Genau. Und das ist das Problem, das entstehen kann, dass Thorsten so quasi als Node gezwungen wird, also beziehungsweise auf einen gültigen Block wartet, während Murch einfach

weiter auf der gültigen Kette die nächsten Blöcke in Empfang nimmt. Genau, man kann das Netzwerk splitten. Genau, ich werde dann vom Netzwerk abgetrennt, weil ich immer dann quasi außer Dienst gestellt werde, weil ich keine gültigen Blöcke mehr bekomme, weil ich immer noch auf den quasi richtigen Block 1, sage ich jetzt mal, warte, aber du bist schon bei Block 5 oder so. Genau, du hast die beste Chain als ungültig eingestuft und hast aufgehört, dem Netzwerk zu

folgen. Das ist eins der beiden Probleme. Okay, das ist nur eins der beiden Probleme. Welches habe ich jetzt als Problem? Das Going Down oder das Going Up? Ich glaube, das könnte man so oder so interpretieren. Das andere ist, du kannst explizit eine Transaktion bauen, wo die letzten 32 Bytes in der Transaktion genau übereinstimmen mit dem Hash einer anderen Transaktion. Also wenn du jetzt diese Transaktion eben in einen Block packst, kannst du dann so tun, als ob das Blatt,

das ja eigentlich die Transaktion ist, wieder ein innerer Knoten des Baums ist. Und dann sagst du ja, der linke Hashing-Partner sind die ersten 32 Byte der Transaktion und der rechte Hashing-Partner ist die TX-ID von meiner Angriffstransaktion und damit kann ich einem Light-Client einen gültigen Merkle-Path geben, der beweist, dass meine Angriffstransaktion in diesem Block war.

Und damit kann ich zum Beispiel so tun, als ob ich Jan-Paul bezahlt habe, gebe ihm die TX-ID von meiner Angriffstransaktion, dann packe ich aber eine Helfer-Transaktion in einen Block, die gültig ist, wo die letzten 32 Byte übereinstimmen mit der Angriffstransaktion. Und ich mache mir dazu Nutze zum Beispiel, dass ich auswählen kann, das Amount und das Output-Skript in der Transaktion,

die hinten in der Transaktion stehen. Und ja, dann muss ich noch ein bisschen grinden. Also es ist ein teurer Angriff, aber ich könnte damit einen Light-Client, der sich nur darauf verlässt, einen Pfad durch den Merkle-Baum zu sehen, beweisen, dass diese Transaktion schon 100 Bestätigungen hat. Sofern ich irgendwo eine Transaktion im Baum finden kann, wo die letzten

32 Byte mit der TX-ID von meiner neuen Transaktion übereinstimmen. Und das wäre natürlich sehr unglücklich für den Light-Client, wenn der denkt, ich habe ihn bezahlt und das hat schon 100 Bestätigungen, wenn die Transaktion aber gar nicht im Baum steht. Okay, also ähnliche Attacke, allerdings deutlich aufwändiger. Also diese Transaktion, also die ungültige Transaktion, die man dem Light-Client schickt, die zu finden ist ja nicht ganz so einfach. Also die passende

Transaktions-ID dazu zu finden ist ja nicht ganz so einfach. Ja, man würde erst die Angreifer- Transaktion grinden müssen, dass sie eine bestimmte TX-ID hat, die eben passt auf eine Transaktion. Und dann würde man eine Transaktion schicken, die eben auf dieses Muster passt. Tatsächlich würde ich sagen, ist das in der Praxis einfacher von den beiden Angriffen. Ach, warum? Weil damit du einen inneren Node kriegst, der mit einer, also ein Block muss ja

immer eine Coinbase-Transaktion haben. Und wenn du also versuchst, einen möglichst kleinen Baum zu haben, damit du irgendwo eine Ebene hast, wo alle inneren Knoten wie Transaktionen aussehen, damit du jemandem erzählen kannst, dass dieser Block invalide ist, dann muss eine davon eine

Coinbase-Transaktion haben. Und dann fängt eine Coinbase-Transaktion zum Beispiel erst mal mit einer 32 Nullen an, oder fängt nicht an, aber im Input-Skript stehen im Outpoint des Inputs von der Coinbase-Transaktion stehen ja 32 Nullen und dann 4 mal 256, weil jede Coinbase-Transaktion hat ja keinen echten Input und so weiter. Also ich glaube, das ist schwerer zu grinden tatsächlich

als diese Fake-Transaktion. Okay, also ich glaube festzustellen ist hier, es gibt das Problem mit diesen 64-Byte-Transaktionen, die einfach zulässig sind, auch wenn sie selten vorkommen wohl oder auch nur nicht sehr sinnvoll sind. Ich weiß nicht, ob wir das noch kurz besprechen wollen. Können wir das nochmal in zwei Sätzen kurz zusammengefasst mergen? Was ist das Problem mit diesen, oder das ist nicht das Problem, aber was diese 64-Byte-Transaktion ausmacht, was sie so merkwürdig

macht? Ja, also ein Input selbst muss ja immer mindestens 41 Byte haben, weil wir 36 Byte brauchen um TxId und Outpoint, sorry, wie Out, also Output-Index und vorherige Transaktionen sind 36 Bytes, nSequence sind 4 Bytes und dann mindestens 1 Byte für das Input-Skript sind wir schon bei 41, 10 Byte für den Header sind wir bei 51, 8 Byte für das Amount sind wir bei 59 und dann ein OP-Return plus ein Byte oder so sind 61, dann kannst du also irgendwie noch 2, 3 Byte, kommst

auf 64. Das heißt, die Transaktion hat nur einen Input, nur einen Output und der Output ist ein OP-Return wahrscheinlich oder sonst irgendwas non-standard komisches. Das heißt, diese Transaktionen zu bauen, die treten so nicht einfach in der Natur auf. Genau, also muss man schon bereit sein, quasi Coins wegzuschmeißen, um diese Transaktion, die 64 Byte lang ist, zu konstruieren. Genau, der Fix ist, glaube ich, relativ einfach. Wir sagen einfach, 64 Byte Transaktionen sind

nicht mehr zulässig. Ist es so einfach, Mörsch? 64 Byte Transaktionen sind verboten. Ja, es gibt ein paar Fixes. Also einer ist gegen diese SPV-Attacke. Der SPV-Client fragt nicht nur nach dem Merkle-Path für die Transaktion, sondern lässt sich dann immer auch den Merkle-Path für die Coinbase-Transaktion geben. Und da die Coinbase-Transaktion schwer zu faken ist, muss er gleichzeitig die Höhe des Baums lernen. Weil ja im Merkle-Tree sind ja alle Transaktionen

auf dem selben Level. Das heißt, wenn er die Länge des Pfades zur Coinbase-Transaktion kennt, kennt er auch die Tiefe von den echten Transaktionen. Damit kann man nichts mehr unten dran hängen. Und auch die mittleren Knoten sind dann schwerer zu faken. 64 Byte Transaktionen einfach verbieten hilft auch. Also das ist einfach ein fundamentales Problem, dass 64 Byte Transaktionen im gleichen Input-Space liegen wie innere Knoten. Das ist einfach

irgendwie eine hässliche Situation. Wenn man eh schon Consensus Cleanup macht, dann sollte man das auch fixen. Aber der Angriff tut mich jetzt nicht unbedingt wach halten nachts. Ja, also genau. Scheint nicht ganz so schlimm zu sein. Und der Pfad, wie man das lösen könnte, scheint auch aufgezeichnet zu sein. Genau. Ich glaube, dann können wir einfach zum nächsten

Thema übergehen. Da muss ich sagen, da hat es mich ehrlich gesagt verlassen. Es geht um Wishlists. BIP30-Verifizierung oder BIP30-Verification. Also wie war das? Also ab Block 1.983.702 können wir uns nicht mehr darauf verlassen, dass neue Blöcke mit BIP34 einfach geprüft werden können, weil es dann zu Coinbase-Transaktionen kommen kann, die dieselbe ID haben wie frühere Coinbase-Transaktionen. Soweit meine ich das irgendwie verstanden zu

haben. Nicht nur Coinbase-Transaktionen, die die gleiche ID haben, sondern man könnte genau die gleiche Coinbase-Transaktion nochmal verwenden. Nochmal verwenden in dem Block 1.900.000 und und und. Ja, genau. Also ist auch ein bisschen ein konstruiertes Problem, aber lass mal am Anfang anfangen. Es gibt zwei Paare von jeweils zwei Transaktionen, die sich wiederholen in Bitcoin, weil nicht alle Transaktionen einzigartig sein mussten zu Beginn der Bitcoin-Zeiten.

Coinbase-Transaktionen vor allem waren vollkommen vom Miner kontrolliert. Der Input war frei gewählt, wenn sonst keine Fees gesammelt wurden oder sonst was, war der Output gleich 50 Bitcoin raus an den nächsten. Und dementsprechend hat irgendjemand hat die gleiche Coinbase-Transaktion zweimal verwendet und dann jemand anders oder die gleiche Entität nochmal später. Das Problem hier war erstens, wenn ein Output noch nicht ausgegeben ist, also noch im UTXO-Set ist und dann nochmal

erzeugt wird, kann man ihn nur einmal ausgeben. Also zweimal erzeugt, einmal ausgegeben ist er weg. Das heißt, jemand hat da 100 Bitcoin vernichtet und das andere Problem ist, wenn jemand den ersten ausgibt und dann jemand später die gleiche Transaktion nochmal erzeugt, dann ist ja die gleiche Transaktion, die den erzeugten Output von der ersten Coinbase-Transaktion ausgegeben hatte, wieder gültig, um die zweite Output, die erzeugt wurde, auszugeben. Angenommen,

dass es keine anderen Inputs gibt. Wenn Transaktion A als Coinbase-Transaktion im Block 5 aufgetaucht ist und in Block 105 ausgegeben wurde und dann erzeugt jemand Coinbase-Transaktion A in Block 160 nochmal, dann kann die in Block 260, wer auch immer die Original-Transaktion, kann ja wieder replayt werden. Das ist ja gleicher Input wieder. Also generell möchte man,

dass Transaktionen einzigartig sind. Dementsprechend wurde erst in BIP30 verboten, dass eine Transaktion sich wiederholen darf, solange alle Outputs noch nicht ausgegeben sind. Also wenn ein UTXO noch existiert, mit der gleichen TX-ID, die er erzeugt hat, kann diese TX-ID nicht mehr wiederverwendet werden. Das hätte das Problem, dass die zwei Duplikate,

erzeugt hat, verhindert. Aber das ist ziemlich teuer. Da musst du nämlich jedes Mal dein ganzes UTXO-Set durchgucken und sagen "Hey, gibt es diese TX-ID schon im UTXO-Set?" Und dementsprechend hat man sich dann überlegt, wir könnten doch einfach verlangen, dass jemand eine laufende Nummer in jeder Coinbase-Transaktion auftauchen lässt. Und zwar verlangt man jetzt, dass die

ersten vier Byte im Input-Script von Coinbase-Transaktionen die Blockhöhe ist. Also in jeder Coinbase-Transaktion, seit BIP34 aktiv ist, ich glaube 2010 oder so, 2011 vielleicht, stehen die ersten vier Bytes, die Blockhöhe, zu der die Coinbase-Transaktion gehört. Da jede Blockhöhe nur einmal in der besten Chain existiert, sind Coinbase-Transaktionen jetzt einzigartig.

Bevor diese Regel eingeführt wurde, stand da aber zufälliges Daten-Kurscht. Und es ist tatsächlich wohl so, ich hatte mir das notiert, 189.023 Transaktionen, die gefunden wurden, bevor Regel 34 eingeführt wurde, das heißt es muss dann doch mindestens über zweieinhalb Jahre, drei Jahre alt sein, also nach Existenz von Bitcoin, sonst gäbe es nicht so viele Coinbase-Transaktionen, haben vorne Daten stehen, die später irgendwann mal als Blockhöhen

interpretiert werden könnten. Und das erste Mal, wo das passiert, ist in Block 1.983.732, hat er was auch immer gesagt. 702 habe ich mir aufgeschrieben, aber kann auch nachgehen. Ja genau, diese sehr lange Zahl. Das ist zum Glück ungefähr 20 Jahre, 21 Jahre von jetzt, das heißt wir haben ein bisschen Zeit darauf zu reagieren. Wir wollen nicht darauf zurückfallen müssen, dass wir das ganze UTXO-Set durchgucken und schauen müssen, ob irgendeine Transaktion

schon mal existiert, bevor wir eine Coinbase-Transaktion akzeptieren. Außerdem ist es sehr unpraktisch, alte Coinbase-Transaktionen zu wiederholen, weil insbesondere die Block-Subsidy so viel höher war damals. Das heißt, man muss eine ganze Menge Fees einsammeln, damit man die Coinbase-Transaktion wiederholen kann und die so viel Geld ausschütten kann.

Und dann geht das Geld ja an den ursprünglichen Miner vom alten Block. Insofern finde ich es auch eher unrealistisch, dass zum Beispiel im Block 1.900.000, wie auch immer, ich glaube da sind 192 Bitcoin in der Block-Reward im Originalblock. Das heißt, jemand müsste da irgendwie um die 190 oder noch mehr Bitcoin mit reinstecken, damit sie die Coinbase-Transaktion wiederholen können.

Das halte ich für etwas unattraktiv. Und es gibt einen ganz einfachen Fix und vielleicht wäre das auch die elegantere Variante gewesen von BIP34, nämlich statt dass man die ersten vier Bytes vom Input-Script in der Coinbase-Transaktion verwendet und dort die Blockhöhe reinschreibt, hätte man verlangen sollen, dass die nLockTime in der Coinbase-Transaktion zur Blockhöhe gesetzt wird. Das Feld ist eh unverwendet in der Coinbase-Transaktion. Man könnte dann einfach in

der nLockTime den Block bergen auf die Höhe, in der er auftaucht. Ich glaube normalerweise ist nLockTime ja die letzte Höhe, in der es nicht stehen darf. Das ist also eine leichte Uminterpretation, aber das wäre ein guter Nutzen von einem Feld, das sonst nicht verwendet wird in der Coinbase-Transaktion. Das würde auch verhindern, dass irgendwelche Coinbase-Transaktionen wiederholt werden, weil soweit ich weiß alle diese 189.000 Transaktionen eine LockTime von 0 haben.

Okay, vielleicht nochmal kurz... Die Alternative ist... Ja, nur nochmal kurz die nLockTime zu erklären. Das ist quasi der Zeitstempel, ab dem diese Transaktion überhaupt erst veröffentlicht werden darf. Also wenn die einen höheren Zeitstempel als den jetzigen Zeitstempel hat, dann ist diese Transaktion, wenn sie im Netzwerk auftaucht,

wird die von jedem einfach abgestoßen. Die nLockTime ist noch nicht gültig, die ist noch nicht eingetreten, deswegen kann diese Transaktion nicht angenommen werden. Genau, und ich habe das schon hundertmal nachgeguckt, aber ich glaube es ist so, wenn die nLockTime 100.000 ist, dann ist der erste Block, in dem die Transaktion stehen darf,

100.001. Also auf Blockhöhe 100.000 kann sie gerelaid werden, Leute akzeptieren es in ihrem Mempool, was natürlich dann heißt, dass es erst im nächsten Block stehen kann. Genau. Jetzt hat sich hier unterbrochen, Mertsch, du wolltest noch was ergänzen dazu. Genau, die zweite populäre Variante ist, dass man verlangt, dass ein Block ein Witness Commitment hat, also quasi das Commitment auf die Witness Stacks von Segwit Transaktionen,

als ein Op-Return-Output in der Coinbase Transaktion. Da das auch nicht aufgetreten ist in den ersten paar Jahren von Bitcoin, würde das auch erzwingen, dass keine Coinbase Transaktion wiederholt werden kann. Ich glaube, da gibt es aber das Problem, dass Witness Commitment nur erlaubt ist, wenn Segwit Transaktionen im Block sind. Das kann man nicht garantieren. Vielleicht ist es auch optional. Aber wenn es optional ist, ist es kein Problem. Aber ich meine,

dass man dann auch eine Segwit Transaktion im Block bräuchte. Das heißt, ein leerer Block wäre nicht mehr akzeptabel. Deswegen finde ich, ist wahrscheinlich nLockTime einfacher. Und da gab es ein bisschen die Sorge, dass Miner heutzutage noch kein nLockTime-Feld

setzen können in Blöcken. Aber wenn sie 20 Jahre Zeit haben, um ihre Firmware umzuschreiben und ihre Hardware abzudaten, ich glaube, dann können wir das schon mal ankündigen, dass wir gerne die nLockTime hätten ab Block 1.980.000 oder so. Cool. Ich glaube, dann können wir es auch dabei belasten. Wir sind schon ziemlich weit vorangeschritten.

Oh ja. Genau. Ich sage mal, auch der letzte Bug, den wir da haben, der ist jetzt auch nicht so super tragisch. Wenn ich jetzt die vier in eine Reihenfolge bringen wollte, dann würde ich tatsächlich sagen, dass das Blockvalidierungszeit ein ernstzunehmendes Problem ist. Das ist ein ernstzunehmender Bug. Den müssen wir fixen. Ja, und das zweite, diese Time Warp-Attacke fand ich, nur das mal durchzudenken und zu verstehen, wo das Problem eigentlich liegt, das hat mir sehr viel Spaß gemacht.

Ich weiß nicht, wie realistisch diese Attacke war. Das Problem mit dem Time Warp ist, du brauchst ja eh schon mal ein Kartell von Minern, das über die Hälfte der Hashrate hat, damit der Szene kriegt. Und jeder sieht, dass Schmuh betrieben wird mit den Timestamps. Aber dann hast du eben auch nur fünf Wochen Zeit, um zu reagieren. Die ganze Community muss sich irgendwie organisieren in fünf Wochen und vermutlich Softfork durchführen oder so, um das zu reparieren. Und fünf Wochen ist relativ knapp.

Das ist, warum es einigermaßen hässlich ist, insbesondere in dem Kontext, dass vielleicht Leute aktiv dafür werben würden, dass die Time Warp-Attacke verwendet wird, um schnellere Blöcke zu minen und mehr Blockspace zu schaffen. Hat man denn da irgendwann schon mal Anzeichen von irgendwelchen Minern gesehen, die das irgendwie mal versucht haben? Es gab ja schon mal Situationen, wo wir durchaus schon, jetzt auch mit Foundry oder so was, das ist ja schon ein ziemlich starker Mining Pool.

Also das Potenzial, sage ich jetzt mal, ist ja durchaus schon in irgendeiner Form dafür vorhanden. Es ist natürlich die Frage, wie sich das durchsetzen lässt, weil wir ja eben schon gesagt hatten, tendenziell eher 60, 70 Prozent ist eher das, was man eher bräuchte, als jetzt irgendwie mit 51 dann. Aber gab es da schon mal irgendwie... Naja, sobald du 51 hast, hast du auch 70. Weil du ja einfach manche der anderen Blöcke dann ignorieren könntest.

Aber ja, also hier auch vielleicht mal wieder die übliche Leier. Mining ist einfach noch nicht dezentralisiert genug. Und das ist ein Riesenproblem, dass zwei Mining Pools die Arbeit für über 50 Prozent der Hash-Rail rausgeben. Und ja, das ist immer noch so eins der Dinge, das hält mich wach nachts. Ja, jedenfalls, ich glaube, es könnte relativ hässlich sein, wenn jemand damit anfängt.

Ich habe kein Szenario im Kopf, warum jemand das tun wollte, außer wenn sie einen super heftigen Short auf Bitcoin raus hätten. Was vielleicht eher gegeben ist, jetzt wo es ETFs gibt. Aber ja, es ist ein relativ billiger Fix, indem du einfach verlangst, dass eben die Timestamps von diesen zwei Blöcken nicht so sehr divergieren. Und ja, insofern, ich glaube, dass das im Großen und Ganzen die Probleme relativ bekannt sind und die Fixes sind nicht so kontrovers.

Das wäre vielleicht schon irgendwas, was man endlich mal unter Dach und Fach sortieren sollte. Ja, aber ich glaube, das ganze, oder dieser Aufgreifen von Antoine hat ja dafür gesorgt, dass das nochmal ins Bewusstsein gerückt wird. Und es wird, so wie ich das jetzt beobachte, wird ja auch das weiter diskutiert. Insofern hat das ja schon mal einen ganz guten Impact gehabt, zumindest mit Blick auf die weitere Diskussion, dass da weiterhin darüber gesprochen wird, daran gearbeitet wird.

Aber ist das denn nochmal ganz kurz, wahrscheinlich ist es das nicht, aber wird diese vier Probleme, werden die als Gesamtpaket diskutiert? Oder ist das quasi, weil es halt Probleme sind, die halt auf jeden Fall mehr gefixt werden, die jetzt aber nicht super kritisch sind, dass die halt unabhängig voneinander diskutiert werden? Wahrscheinlich eher auf dem Weg dann, weil das jetzt als dieses Paket bezeichnet wird. Ja, genau. Also die Probleme sind eigentlich ja unabhängig.

Es sind nur irgendwie so vier bekannte Konsensusprobleme, die man gerne mal fixen würde. Und da es eben kein neues Feature ist, da es kontroverser diskutiert wird, wäre es vielleicht relativ einfach, die als Paket gemeinsam zu aktivieren. Wenn jetzt irgendwie zum Beispiel jemand einen Grund finden würde, warum sie eins von diesen für kritisch halten oder gegen den Fix von einem dieser Probleme wären, dann würde das vielleicht aussortiert und die anderen verpackt.

Aber ja, im Grunde genommen ist es historisch, dass es Mert halt mal so vorgeschlagen hatte und jetzt dann Antoine so auch wieder aufgehoben hat. Okay, passt. Schön. Ich glaube, wir machen den Laden dicht. Das war schon ganz schön lange. Erstmal vielen Dank, Mert, dass du dir mal wieder die Zeit für uns genommen hast. Ja, gerne. Mir hat es sehr viel Spaß gemacht. Ich hoffe dir auch. Ja, liebe Kollegen da draußen, liebe Hörer, Mert, hast du noch letzte Worte an deine Zuhörer?

Ja, danke, dass ihr mich wieder als Gast hattet hier. Schön ist es. Immer wieder gerne, Mert. Endlich mal wieder Deutsch sprechen. Das ist immer komisch, über Bitcoin in Deutsch zu sprechen. Okay, das kann der auch schneiden. Nein, das bleibt so drin. Das macht dich halt super sympathisch, deswegen bleibt das auch drin. Ja, es ist in der Tat seltsam, über Bitcoin in Deutsch zu sprechen. Da fehlen mir manchmal die Worte. Aber ja, zurück zu dir.

Du kriegst ja hier ein bisschen Übung, das passt doch. Wunderbar. Musst du öfter zu uns kommen. Gerne. Gut, liebe Hörer da draußen, nochmal an euch der Value for Value Hinweis. Also, wenn euch das gefallen hat, was wir hier gemacht haben, würden wir uns sehr freuen, wenn ihr uns ein paar Satz rüberwachsen lasst. Ihr kennt den Weg mittlerweile, streamt oder boostet oder Einzelspende oder oder oder, kommt auf die Webseite. Da könnt ihr das alles finden.

Silent Payment. Silent Payments haben wir jetzt auch. Oh, habt ihr schon eine Silent Payment Adresse? Ja, aber ich wollte die eigentlich noch nicht so öffentlich verkünden, weil die im Moment auf der Silentium Wallet ist und das ist halt echt... Die ist sehr, sehr Alpha, ja. Ja, genau. So ganz wohl fühle ich mich dabei noch nicht. Ja. Ja. Naja, aber ich meine, wer macht denn heute schon On-Chain-Spenden an einem Bitcoin-Podcast? Naja, es ist wieder etwas bezahlbarer.

Ich war sehr verblüfft, wie die Fee Rates runtergekommen waren jetzt in den letzten zwei, drei Wochen. Das stimmt, aber ich glaube, wir haben noch fast keine On-Chain-Spende bekommen, oder Thorsten? Ja, vor letztes Jahr irgendwann mal, als wir das mit Paynm, glaube ich, einmal ganz frisch hatten, also hier BIP47, da hatten wir dann mal drei Spenden darüber bekommen dann, aber seitdem ist das dann ja auch tote Hose. Ich gucke da in die Wallet immer mal wieder rein, ob da was passiert, aber nee.

Ich muss sagen, dass Silent Payments natürlich genau für Spende, das ist exakt wofür es sehr gut funktioniert. Genau. Auf jeden Fall. Das heißt für euch der Hinweis, wenn ihr nicht wisst, worüber wir reden, letzte Folge oder vorletzte Folge, wann auch immer das hier kommt, Folge 184, da haben wir über Silent Payment gesprochen. Dann mache ich jetzt aber den Laden dicht. Focus on the Signal, not on the noise. Danke euch beiden. Ciao, ciao. Danke, ciao. *Musik* *Musik*

Nodesignal. Focus on the Signal, not on the noise. *Musik*