Wie validiert Bitcoin Transaktionen

[RayKuus]

Hallo zusammen,

ich habe vergangenen Freitag eine kurze Präsentation über Bitcoin in meinem Seminar-Kurs gehalten und mein Professor hat mich mit folgender Frage konfrontiert:

Wie werden Bitcoin Transaktionen validiert?

In anderen Worten, wie funktioniert der Algorithmus zur Verifikation der einzelnen Transaktionen? Die Blockchain ist ja schließlich 400 GB groß, woher wissen denn die Nodes bei der Überprüfung einer Transaktion, dass die entsprechende Person genügend Funds hat? Ich vermute mal, es werden nicht die 400 GB durchgegangen.

Durch das Internet bin ich auf UTXO gestoßen, wenn ich das richtig verstanden habe, dann wird bei der Erstellung einer Transaktion auf ältere Transaktionen verwiesen, die beweisen, dass man über die Bitcoin verfügt. Wie wird aber sichergestellt, dass nicht zweimal auf die gleichen Transaktionen verwiesen wird?

Auf diese Fragen habe ich bisher keine Antworten gefunden, vielleicht kann mir hier ja jemand aushelfen!  :-)

[battlecore]

Google: doublespend

Das klärt die groben Sachen. Dann kannst du gezielter die Details erfragen.

 

Bearbeitet 10. Mai 2022 von battlecore

[RayKuus]

vor 1 Minute schrieb battlecore:

Google: doublespend

Das klärt die groben Sachen. Dann kannst du gezielter die Details erfragen.

 

Wie funktioniert der Confirmation mechanism der Transaktionen? 

[Jokin]

Sehr präzise Fragen 🙂

Schau mal hier: https://learnmeabitcoin.com/technical/transaction-data

Schau dir an wie Transaktionen aufgebaut sind. Generell besteht jede Transaktion aus INPUTs und OUTPUTs, die in Summe "fast" null ergeben (der Rest ist die Miner-Fee).

Bezogen auf die verlinkte Seite und etwas vereinfacht:

OUTPUTs enthalten die Empfängeradressen in einem Skript ("ScriptPubKey") und die Anzahl der Bitcoin ("Value"). Davon kann es beliebig viele geben, die durchnummeriert werden.
(Dieses Skript ist für Standardtransaktionen so etwas: "Dieser UTXO darf von demjenigen ausgegeben werden, der die Transaktion mit dem PrivateKey der Adresse 1L....4D57 signiert")

Solange diese OUTPUTs nicht als INPUTs weiterer Transaktionen verwendet werden, sind sie im Status "unspent".

Alle "unspent transaction OUTPUTs" (UTXO) bilden das "UTXO-Set" welches in einer leicht durchsuchbaren Struktur separat abgelegt wird um nicht die 400 GB durchsuchen zu müssen. Das macht jeder Node für sich selbst anhand der Blockchain - die muss einmalig natürlich durchsucht werden um das UTXO-Set aufzubauen.

 

Wenn ein UTXO ausgegeben wird, dann taucht er als INPUT einer Transaktion auf.

INPUTs enthalten die Transaktions-ID ("TXID") und den Index aus der Durchnummerierung der Outputs ("VOUT").

Die Validierung erfolgt dann so ungefähr:

Der Bitcoinnode erhält eine neue Transaktion. Er prüft ob die INPUT-Transaktionen in seinem UTXO-Set vorhanden sind. Dann greift er sich aus dem ursprünglichen UTXO den "ScriptPubKey" und prüft ob die Bedingungen erfüllt sind um diesen UTXO in eine neue Transaktion aufzunehmen. Wenn alles schön ist, ist die Transaktion validiert und wird an den nächsten Bitcoin-Node weiter gegeben. Jeder Node prüft auf's Neue ob die Transaktion gültig ist.

Sobald ein Miner diese Transaktion in einen Block aufgenommen hat, macht der die Runde über alle Nodes und alle Nodes aktualisieren ihr UTXO-Sets NACHDEM sie wieder alle Transaktionen des Blocks geprüft haben ob die INPUTS in ihren UTXO-Sets enthalten sind.

 

Ein Doublespend kann nur dann erfolgen, wenn ausreichend (>50%) der Miner-Nodes diesen Doublespend akzeptieren.

 

[battlecore]

Womit sich erklärt wieso der Stromverbrauch von Bitcoin so hoch sein muss wie er jeweils gerade ist.

Das verhindert effektiv das jemand 51 Prozent der aktuellen Minerleistung aufbaut um das Netzwerk zu attackieren. Mit anderen Worten, jemand müsste mehr Leistung aufbringen als der Rest der Kryptowelt.

[battlecore]

Btw. fällt ein Doublespend auf.

Der Angreifer hätte mit seinem Angriff die Chain verändert. Wenn dies auffällt wird der Teil der Chain sn dem Block abgeschnitten der zuletzt intakt war. Es wird immer die längere Kette weiterverfolgt. Da der Angreifer nur einige Blöcke schafft ist sein manipulierter Teil sehr kurz und verwaist daher einfach.

Aber er kann seinen Teil der Kette alleine weiterverfolgen. Ein Fork. Meinetwegen könnte er ihn BTCF (BTC-Fork) nennen. Vielleicht finden sich andere die mitmachen.

[Cricktor]

Bitcoin verwendet Script als Mini-Programmiersprache für Sperr-Skripte, um das Ausgeben von Coins/UTXO zu reglementieren. Diese Lockings Scripts definieren die Bedingungen, die erfüllt werden müssen, um einen UTXO ausgeben zu können. (Unter dem angegebenen Link sind dann noch die sog. Standard-Skripte näher erklärt.)

Die Skripte steuern eine Art virtueller Stapel-Rechenmaschine und erlauben dadurch Flexibilität innerhalb von Bitcoin. Im Gegensatz zu Ethereum ist Bitcoin-Script nicht touring-vollständig, dies aber mit Absicht, um z.B. DoS durch Endlosschleifen o.ä. zu verhindern.

Üblicherweise enden solche Skripte mit dem OP-Code OP_CHECKSIG, der eine digitale kryptografische Signatur prüft, die der Ausgebende in der Transaktion liefern muss und die ausschließlich der Besitzer des Privaten Schlüssels, zu dem der UTXO "gehört", liefern kann. (Nebenbei: es ist aber technisch möglich, auch ein Locking Script ohne abschließendes OP_CHECKSIG zu machen, dann könnte diesen UTXO praktisch jede/r ausgeben, sofern alle anderen Bedingungen des Locking Scripts erfüllt werden können. Meines Wissens hat es solche "seltsamen" UTXOs durchaus gegeben, wenn auch aus naheliegenden Gründen sehr sehr selten.)

Das ist jetzt recht grob beschrieben und umfasst nicht alles, was zur Verifikation passiert. Aber generell kann man sagen, daß eine Transaktion, die von einer Node ins Bitcoin-Netzwerk versendet wird (zu den mit ihr verbundenen anderen Nodes), von den anderen empfangenden Nodes auf die Einhaltung aller definierten Bitcoin-Konsensregeln überprüft wird. Wird eine Konsensregel gebrochen, wird die Transaktion (oder analog auch ein Block mit Transaktionen) von der empfangenen Node verworfen. Nodes können aktiv vom Bitcoin-Netzwerk ignoriert werden, die notorisch damit auffallen, nicht-regelkonforme Transaktionen oder Blöcke zu verbreiten zu versuchen.

Bearbeitet 10. Mai 2022 von Cricktor