Hallo Zusammen
Ich habe einige Verständnisfragen technischer Art.
Das difficulty adjustment muss nach meinem Verständnis dezentral von jeder node selbständig berechnet und implementiert werden, und das alle 2016 Blöcke. Kann es passieren, dass unterschiedliche nodes auf unterschiedliche ergebnisse kommen und was hätte das für Auswirkungen? Die „Messlatte“, was 10 Minuten sind, muss irgendwo herkommen bzw müssen sich alle nodes irgendwie einig sein, was genau 10 Minuten sind. Hat eine node einen internen Zeitgeber oder gleicht sie sich mit einem Zeitserver ab? Und wenn Zeitserver - ist das nicht potentiell eine zentralisierte Schwachstelle?
Miner generieren nach meinem Verständnis zufällige Daten, welche anschliessend via SHA256 einen bestimmten Hash ergeben. Was passiert, wenn zwei Miner zu unterschiedlichen Zeitpunkten den gleichen, gültigen Hash berechnen? Prüfen die nodes für jeden neuen Block alle hashes der Vergangenheit auf Wiederholungen?
Nein, das Target ist eindeutig wenn man sich über die vergangenen Blöcke einig ist. Jeder Block hat einen Timestamp, der vom Miner gewählt wurde.
Exakt gleiche Frage hier:
Nein, nicht wirklich. Miner müssen nur laufend ihren Block bzw. den Blockheader irgendwie anpassen um auf ein anderes Ergebnis zu kommen (in der Hoffnung dass es dem Target entspricht).
Im Blockheader stehen sehr wichtige Informationen wie der Hash des vorherigen Blockes, der Timestamp und ein Fingerabdruck aller Transaktionen.
Dann gibt es ein Zahlenfeld das einfach laufend inkrementiert wird (Nonce), um für eine neue Hashsumme zu sorgen. Dieses Feld ist sogar so klein bzw. Mining Hardware so schnell, dass es mehrmals pro Sekunde komplett ausgereizt wird und Miner zusätzlich andere Parameter anpassen müssen.
Bin mir nicht ganz sicher was du meinst.
Wenn zwei Miner (ca.) gleichzeitig einen Block finden (d.h. Difficulty wird eingehalten, nicht identische Hashsumme) veröffentlichen beide ihren Block. Beide Blöcke sind gültig, es gibt eine Fork. Einer der beiden Miner wird leer ausgehen. Welcher das ist entscheidet der nächste Miner der einen Block findet. Er bestimmt an welchen Block er sich anhängt. In der Regel ist dass der Block den er zuerst erhalten hat.
Das kommt allerdings relativ selten vor, da der Zeitraum wirklich extrem eng beieinander liegen muss. Denn ansonsten machen alle Miner sofort mit dem nächsten Block weiter wenn ein neuer gefunden wurde.
Wenn zwei Miner zu unterschiedlichen Zeitpunkten die gleiche Hashsumme finden (also mit unterschiedlichem Blockheader), dann nennt man dann eine Kollision. Das ist extrem unwahrscheinlich!
Es geht hier ausschließlich um eine Fork in der Chain („Chain Split“), also in den Daten, der hier im Beispiel durch einen Zufall auftritt (zwei Miner finden Block auf gleicher Höhe). Alle sind sich aber über die Regeln einig und innerhalb weniger Blöcke, wahrscheinlich direkt dem nächsten, hat das Netzwerk wieder die „beste“ Chain gefunden.
Eine Hard Fork ist eine Fork in den Regeln bzw. im Protokoll die nicht mit den bisherigen Regeln vereinbar ist (nicht vorwärtskompatibel). Damit einher geht natürlich auch eine Fork in der Blockchain bzw. ein Chain Split.
Um noch den Unterschied zwischen einer Soft- und Hard Fork zu erläutern:
Wenn ein vegetarisches Restaurant plötzlich vegane Gerichte anbietet, dann ist das eine Soft Fork, denn auch Vegetarier können vegane Gerichte essen. Wenn es auf Fleischgerichte umstellt, eine Hard Fork.
Die längste Chain (bzw. die mit „dem größten Proof of Work“) ist gültig, man nennt das auch die „beste Chain“.
Betrachten wir das aus der Perspektive einer Node, du wolltest es genau:
Zwei Miner finden zufällig gleichzeitig einen neuen Block, A und B (beide mit gleicher Blockhöhe). Die beiden Blöcke werden im Netzwerk veröffentlicht. Unsere Node wird zwingend einen der beiden Blöcke zuerst erhalten, sagen wir das ist Block A, und diesen zunächst als den gültigen anerkennen. Der andere ist zunächst irrelevant, wird aber registriert.
Es hängt jetzt davon ab welcher Miner den nächsten Block findet. Jeder Miner kann theoretisch für sich entscheiden welchen der beiden konkurrierenden Blöcke er als Vorgänger in seinen Header schreibt. Damit bestimmt der Miner, sollte er den nächten Block finden, welcher der beiden Blöcke verworfen wird.
Die meisten Miner werden auf den Block aufsetzen den sie zuerst erhalten haben. Welcher das ist kann sich je nach Netzwerk Topologie unterscheiden.
Der Miner bzw. Pool der einen der beiden Blöcke gefunden hat wird selbstverständlich auf seinem Block aufsetzen, da er natürlich sein verdientes Geld retten will (aber das deckt sich sowieso mit der Aussage oben).
Sobald der nächste Block gefunden und veröffentlicht wurde ist die beste Chain wieder klar und der Split wurde aufgelöst.
Entweder baut der neue Block A2 sowieso auf der besten Chain unserer Node auf, dann geht es normal weiter.
Oder der neue Block B2 baut auf dem zunächst von unserer Node ignorierten Block B auf. Dann wird der jetzt ungültige Block A zurück genommen und alle Transaktionen landen wieder im Mempool bzw. alle STXO werden wieder zu UTXO.
Dann werden die beiden gültigen Blöcke B und B1 als gültig anerkannt.
Transaktionen die in Block A lagen aber nicht in B und B1 liegen haben nie stattgefunden bzw. liegen jetzt wieder im Mempool.
Transaktionen die in Block A lagen und auch in Block B oder B1 liegen haben ganz normal stattgefunden und sind gültig, da die Transaktionen in Block A sowieso nie stattgefunden haben.
Klar, das dürfte schon (relativ) oft passiert sein, ist aber wie gesagt sehr unwahrscheinlich. Der einzige Nachteil der durch solch ein Ereignis auftreten kann ist dass eine Transaktion zurück in den Mempool rutscht. Das ist dann etwas nervig und ggf. verwirrend, da man doch gerade eben schon eine Bestätigung hatte. Es kann aber nichts verloren gehen und man kann das realistisch auch nicht für einen Double Spend ausnutzen.
Im Nachhinein ist es sehr schwer nachzuvollziehen wie oft es genau dazu gekommen ist. Ich kann schließlich auch einfach ungültige Blöcke nachträglich zusammenbauen und behaupten dass wäre ein „echter“ Stale Block.
Man bräuchte eine Node die schon seit langer Zeit genau darauf geachtet und es entsprechend protokolliert hat.
Hier gibt es eine Statistik, aber wie aussagekräftig die ist – keine Ahnung.
Wir sprechen hier eigentlich von „Stale Blocks“ und nicht von „Orphan Blocks“, zumindest verstehe ich das so, die beiden Begriffe werden häufig vermischt.
Meine Node hat Kenntnis von zuletzt „orphaned chain forks“ mit Zweiglänge 1 bei folgenden Blockhöhen der Bitcoin-Mainchain (Genesis-Block hat Höhe/Nr. Null):
693118, 694157, 696145, 697008, 705970, 714637, 723102, 730848, 733430
Die Daten bekommt man in Bitcoin Core mit dem Consolen-Kommando getchaintips.
