„Bitcoin ist Zeit“ und ähnliches höre ich ja immer wieder fasziniert von Gigi und co.
Aber wie „weiss“ Bitcoin wann 10 min um sind?
Um die durchschnittliche Zeit, die benötig wird um einen neuen gültigen Block zu finden, auf 10 min zu halten wird ja ca. alle zwei Wochen (korrigiert mich gerne) die Difficulty entsprechend angepasst. Dazu muss doch gemessen werden wie lange es im betrachteten vergangenen Zeitraum gedauert hat einen neunen Block zu finden. Doch um dies zu messen muss doch auf eine Uhr die „ausserhalb“ von Bitcoin ist zurückgegriffen werden und damit muss doch einem aussenstehenden Orakel vertraut werden. Und das wäre doch schlecht… ?
Also meine Frage: Wie funktioniert das denn jetzt genau und wie ist das im Code umgesetzt? Wie kann Bitcoin seine „eigene“ Zeit erschaffen?
Miner schreiben ihren eigenen Timestamp in den Block Header. Dafür brauchen sie kein Orakel, Zeit ist universell und kann auf verschiedene Wege ermittelt und verifiziert werden, wenn man besonders misstrauisch ist sogar mit einer Sonnenuhr.
Es ist in einem dezentralen Netzwerk aber auch schwierig die „korrekte“ Uhrzeit durchzusetzen, weshalb es zwei Regeln gibt mit denen der mögliche Zeitbereich eingegrenzt wird. Diese Regeln können entsprechend auch von den Minern ausgereizt werden, weshalb es z.B. möglich ist dass ein Block einen kleineren Timestamp hat als sein Vorgänger!
Die beiden Regeln sind konkret:
Der Timestamp muss größer als die MTP des vorherigen Blockes sein. MTP(= Median Time Past) gibt den Median (nicht den Durchschnitt) der Timestamps der letzten 11 Blöcke an.
Der Timestamp darf nicht mehr als zwei Stunden in der Zukunft liegen (Zeitzonen raus gerechnet) im Verhältnis zur lokalen Uhrzeit der Node1.
Ansonsten wird der Block abgelehnt. Die Uhrzeit wird sozusagen dezentral verifiziert.
Über 2016 Blöcke glättet sich die durchschnittliche Blockzeit dann natürlich und kann repräsentativ für das Adjustment genutzt werden. Hier wird dann die absolute Zeit herangezogen die Vergangen ist um die letzten 2016 Blöcke zu finden.
Niemand kann Zeit erschaffen. Es könnten nur einzelne Entitäten versuchen die Uhrzeit zu fälschen, genauso wie einzelne Entitäten versuchen können Blöcke, Transaktionen oder sonst irgendwas zu manipulieren. Die dezentrale Natur von Bitcoin lässt dies nicht zu.
Wo siehst du hier ein Oracle Problem?
[ 1 ] Genauer gesagt im Verhältnis zur sogenannten network-adjusted time. Der Median aller Timestamps der mit der eigenen Node verbundenen Nodes.
@sutterseba ich bin immer fasziniert wieviel wissen in dir steckt und welche Mühe du dir gibst um die Leute hier aufzuklären. Eine echte Bereicherung fürs Forum, danke dafür!
Wie so oft sollte man die Fragestellung und den Begriff (hier „Oracle Problem“) sauber definieren, bevor man darüber diskutiert.
Falls man 100%ige Sicherheit der Realweltdaten innerhalb der Blockchain fordert, kann man das Oracle Problem per Definition nicht lösen.
Da „das Oracle Problem“ aber soweit ich weiß kein Jahrhunderte alter Lehrsatz ist, finde ich persönlich verschiedene Auslegungen auch in Ordnung. Allerdings wird es gerade von Bitcoinern gerne sehr extrem ausgelegt, so dass man im Prinzip keinerlei Realweltdaten trauen kann, die auf der Blockchain gespeichert sind.
Die Uhrzeit ist eine Größe aus der physischen Welt.
Falls die Frage in diesem Thread also lautet, ob man den Zeitangaben in der Blockchain trauen kann, müsste ein Bitcoiner eigentlich sagen, dass man das natürlich nicht kann!
Dabei ist es egal wieviele genaue und unabhängige Uhren und Miner es in der Realwelt gibt, da das Oracle Problem nach rigoroser Auslegung nicht lösbar ist.
Falls die Frage in diesem Thread aber lautet, ob die Sicherheit von Bitcoin dadurch gefährdet ist, würde ich auf Anhieb mal sagen nein. Falls alle Miner und andere Nodes bei den Zeitangaben und deren Verifizierung zusammenarbeiten, um diese zu fälschen, wäre es eh schon zu spät.
Kommt halt auch wieder darauf an was du mit „Zeitangaben vertrauen“ meinst.
Willst du damit einen Marmorkuchen backen, dann kann das nach hinten los gehen.
Geht es aber nur darum zu verifizieren ob die Zeitangaben innerhalb der Netzwerkregeln liegen oder (mit etwas Toleranz) der physikalischen „Realität“ entsprechen, dann ist das kein Problem – vertrauen muss ich hier niemandem, da ich keine Angaben einer anderen Entität „einfach so hinnehmen“ muss – und da definiere ich mir das Oracle Problem.
Ich kann meiner Node schließlich die frisch abgelesene Uhrzeit meiner Sonnenuhr mitteilen und kann jeden behaupteten Timestamp überprüfen und ggf. ablehnen.
Wenn die Sonne natürlich auch ein Orakel ist wird’s schwierig…
Die Frage vom OP ist streng genommen etwas am dezentralen Aufbau von Bitcoin vorbei formuliert. Es gibt schließlich nicht „die Difficulty“ und „Bitcoin weiss“ auch nicht wann 10 Minuten rum sind. Jede Node muss das für sich entscheiden/berechnen, über fast alles muss ein Konsens gebildet werden – auch über Timestamps.
Ich würde auch behaupten dass ich viel mehr Unsicherheit habe nachzuvollziehen wie viel Energie & Zeit in das finden einer kleinen Hashsumme geflossen ist als irgendeinen Timestamp zu überprüfen. Letzterer ist direkt an einen für mich sichtbaren physikalischen Prozess gebunden, was bei Proof of Work nicht der Fall ist. Der Miner könnte besonders günstigen Strom, hocheffiziente Hardware oder sogar einen Shortcut in SHA-2 gefunden haben, was ich nicht wissen kann und was die Behauptung das Netzwerk gesichert zu haben nicht verifizierbar macht (wenn ich mir diese Behauptung so definiere).
Als Bitcoin Kritiker könnte ich mir hier sicherlich ein Oracle Problem zusammen dichten.
Da hast du Recht. Hier habe ich selbst nicht aufgepasst.
Sehr guter Punkt!
Falls ich eine Node betreibe, kann ich tatsächlich alle neuen Blöcke mit eigenen Realweltdaten validieren.
Hier gibt es dann wirklich einen großen Unterschied zu anderen Projekten. Dort werden auch Daten von einem oder mehreren Oracles auf die Chain gebracht, die ich nicht alle selbst verifizieren kann.
Falls ich nicht schon immer eine Node betrieben habe, kann ich die Zeiten allerdings nicht verifizieren und muss den damaligen Oracles (= allen Nodes zum jeweiligen Zeitpunkt) vertrauen. Also angenommen mich würde nicht die Sicherheit, sondern wirklich die Zeiten interessieren, was schon seltsam wäre.
Es gibt auch wesentlich mehr Nodes bei Bitcoin, als Oracles in anderen Projekten. Deshalb ist diese Diskussion sehr akademisch.
Ich finde es trotzdem interessant, dass der Timestamp wahrscheinlich die einzige sicherheitsrelevante Information auf der Blockchain ist, die man nicht komplett im Nachhinein verifizieren kann.
(Zusammen mit der aufgewendeten Energie natürlich.)
Nun schieben Sie den Kuchen für vier Blöcke in den Ofen. Spannende Geschichte.
Genau diese Frage habe ich mir auch vor Kurzem gestellt. Obwohl ich mich schon einigermaßen mit dem Grundprinzip Mining auseinandergesetzt habe, wurde das nie erwähnt, obwohl es so essenziell ist.
(Wollte ich nur loswerden, eine Antwort auf deine Frage hast du ja schon :D)
Ich hab’ das verlinkte Thema mal überflogen und fand die dort geführte Diskussion zwar interessant aber auch etwas skuril, wenn ich das mal so sagen darf.
Sebastian hat ja schon darauf hingewiesen, daß Miner die Blockzeit innerhalb eines garnicht so kleinen Intervalls selbst bestimmen dürfen, da die Blockzeit Teil des Blockheaders ist und somit den Blockhash ebenso wie die Nonce beeinflussen kann. Miner können somit auch die Blockzeit zum Durchprobieren zum Finden eines validen Blockhashes variieren. Somit ist die Blockzeit eine recht ungenaue und vorallem nicht zuverlässige Zeitangabe, die der Willkür eines Miners innerhalb definierter Grenzen unterliegt. Wann ein Block im Bitcoin-Netzwerk propagiert wird, wird nicht genau in der Blockchain dokumentiert. Hier wird das auch nochmal auf den Punkt gebracht.
Für Miner ist in etwa nur Folgendes relevant: sobald ein neuer Block im Netzwerk propagiert und als valide akzeptiert wurde, beginnt für alle ehrlichen Miner das Rennen zum Finden eines neuen Blocks von vorn. Dabei spielt es überhaupt keine Rolle, welches Zeitintervall für die vorherigen Blöcke jeweils verstrichen ist. Die aktuelle Difficulty legt fest, wieviel Hash-Arbeit das gesamte Miner-Netzwerk statistisch leisten muss, um statistisch nach ca. 10min einen validen Blockhash zu finden. Da das Finden eines validen Blockhashes ein rein zufälliger Vorgang ist, kann dies innerhalb von Sekunden passieren oder es können auch mal deutlich mehr als 20, 30, 40, … Minuten vergehen. Statistisch und im Mittel über viele, viele Blöcke gemessen, ist das Blockintervall durchschnittlich 10min lang. Vorhersagen kann man das nächste Intervall nicht.
Das Zeitorakelproblem hat für den dezentralen und vertrauenslosen Proof of Work meines Erachtens keine Relevanz, weshalb es von Satoshi Nakamoto und späteren Entwicklern für das Bitcoin-Protokoll keine Beachtung fand. Es hätte den dezentralen und vertrauenslosen Ansatz nur unnötig verkompliziert, ohne einen Sicherheitsvorteil zu generieren.
Weißt du zufällig wie aktiv das noch genutzt wird? Mittlerweile löst ja die extraNonce das Problem der fehlenden Variationen.
In Mastering Bitcoin wird darauf eingegangen, aber mir wird da nicht ganz klar ob Timestamps immer noch aktiv angepasst werden. Immerhin sollte das deutlich schneller sein als über die extraNonce einen Teil der Merkle Root neu auszurechnen.
Eight bytes of extra nonce, plus the 4 bytes of „standard“ nonce allow miners to explore a total 296 (8 followed by 28 zeros) possibilities per second without having to modify the timestamp. If, in the future, miners could run through all these possibilities, they could then modify the timestamp. There is also more space in the coinbase script for future expansion of the extra nonce space.
Was impliziert dass der Timestamp aktuell nicht mehr ausgereizt wird.
Aber ich bin doch schneller wenn ich erstmal alle Nonce + Timestamp Kombinationen teste bevor ich mir die Mühe mit der extraNonce mache.
Deine letzte Aussage würde ich aus dem Zitierten so nicht zwingend ableiten. Wobei… definiere „ausreizen“.
Die Extra Nonce sind ja die frei wählbaren 2-100 Bytes des Datenfeldes der Coinbase-Transaktion. Die genannten 8 Bytes Extra Nonce sind nur ein Beispiel, es können mehr oder weniger Bytes sein.
Aber jede Anpassung von Extra Nonce Bytes führt zu einer Neuberechnung des Merkle-Roots.
Was genau nun für die ASICs und Miner-Software weniger rechen- oder datentechnisch aufwändig ist, kann ich auch nur raten (da Bitcoin-Mining für mich uninteressant ist, weil ich das nie wirtschaftlich betreiben könnte).
Das müsste man die Miner fragen, die die ein tiefes Verständnis der inneren Abläufe von Mining-Hardware und -Software haben.
Aus dem Bauch heraus würde ich das auch so sehen, da ich annehme, daß die Neuberechnung des Merkle-Roots rechentechnisch „teurer“ ist. Denkbar ist aber auch eine Kombination von beidem, insbesondere wenn die ASICs im zwei- bis dreistelligen TH/s Bereich rechnen.
Hat man dann eine ganze Farm von zig ASICs, die man alle praktisch ohne Unterbrechung hashen lassen möchte/muss, dann ist das ein interessantes Problem, daß die Hasherei so aufgeteilt wird, daß nirgends Hasharbeit doppelt oder sinnlos ausgeführt wird. Nicht trivial…
Diese Skurrilität kommt dabei heraus, wenn man versucht Bitcoin mit abgefahrenen physikalischen Theorien irgendwie „cooler“ darzustellen. Dabei braucht man diese Theorien hier gar nicht.
Vorsicht, in diesem Thread gibt es mindestens zwei Sebastian.
Es hat zumindest keine größere Relevanz als alle anderen Konsens-relevanten Parameter. Das sehen wir wahrscheinlich alle so.
Es macht keinen großen Unterschied, ob ein Miner einen zu großen Block oder einen Block mit komplett falschem Timestamp im Netzwerk veröffentlicht. In beiden Fällen wird jede einzelne Node diesen Block mit ihren eigenen Regeln und der „eigenen Uhrzeit“ vergleichen und falls nötig verwerfen.
Einen kleinen Unterschied gibt es. Das Blocksizelimit kann ich selbst in meiner Software ändern. Die Uhrzeit erhalten viele Nodes aber sehr wahrscheinlich von irgendeinem NTP Server. Falls der Großteil der Nodes nur wenige NTP Server bzw. die zugrundeliegende zentrale Zeitmessung nutzen würden, wäre das ein Angriffsvektor.
Mögliche Angriffsmöglichkeiten wurden aber auch nicht weiter diskutiert. Dabei wäre das schon interessant. Viele Nodes verwenden relativ wenige NTP Dienste, die wiederum wahrscheinlich alle mit der Weltzeit synchronisiert sind.
NTP kann man ja schon auch etwas defensiver konfigurieren und insbesondere kann und sollte man mehrere Zeitserver angeben. Dann wird eine bösartige Zeitquelle schlicht ignoriert, wenn ansonsten die anderen Zeitserver im normalen Rahmen liegen.
Ein Angreifer hätte es dann schon schwerer einer Node eine falsche Uhrzeit unterzujubeln.
