--German-- Ep. 10 [Bitcoin Full-Nodes] Verifizieren wartende Bitcoin-Transaktionen - Part 3

Vormerk
Gelange auf einfachste Weise zum Grundverständnis von Kryptowährungen durch Bilder(Danke an @RatzFratz) und Analogien. Jede Geschichte, baut auf den vorherigen Artikeln auf. Ich empfehle daher sich ein paar Minuten Zeit zu nehmen und nochmal die vorherigen Geschichten aufzufrischen. Je öfter man die Artikel durchliest, desto sicherer wird man mit dem Umgang und der Anwendung von Bitcoin-Technologie. Als Steemit-Nutzer rate ich jedem dazu, sich ein grundlegendes Verständnis über Kryptowährungen wie Bitcoin und Steem anzueignen, um bestmöglich und verantwortungsvoll mit seinem Profil(und somit mit seinem Geld) umgehen zu können. Falls in den Artikeln irgendwas unklar sein sollte, schreibt einfach einen Kommentar. Ich werde versuchen schnellstmöglich darauf einzugehen. Danke!

---

In Ep. 9 haben wir gesehen, dass Flint eine Full-Node im Bitcoin-Netzwerk ist. Eine Full-Node überprüft wartende Bitcoin-Transaktionen auf Korrektheit. Dafür braucht eine Full-Node sein eigenes lokales Blockchain-Buch, in welchem alle zuvor ausgeführten Bitcoin-Transaktionen verzeichnet sind. Wir haben gesehen, dass Block1 der Blockchain beim Download der Bitcoin-Software dabei war.

In unserem Beispiel, beinhaltet Block1 nur eine Transaktion. Das ist die Gewinn-Auszahlung aus dem 1sten Mathematik-Wettbewerb(=1. Bitcoin-Mining) an den Gewinner. Nennen wir den Gewinner "David". Die einzige Transaktion in Block1 ist also:

"50 neue(=new) BTC -> David"

Wir haben gesehen, dass die neue Full-Node Flint Kopien der restlichen Blocks für seine lokale Blockchain von anderen Full-Nodes erhält. Er muss aber sichergehen, dass die erhaltenen Kopien korrekt sind, und somit nur legitime Transaktionen beinhalten, bevor Flint diese Kopien zu seiner Blockchain hinzufügt. Wir haben zuvor erwähnt, dass Flint als neue Full-Node den ersten Block beim Download der Bitcoin-Software erhalten hat.

Schauen wir uns nun die Kopie von Block2 an, welche Flint von Eric erhalten hat.

In unserem Beispiel hier, ist in Block2 ebenfalls nur eine Transaktion enthalten:

"Transaktion: David --> 50 BTC --> John"

Bevor Flint diesen Block2 in seine Blockchain hinzufügt, überprüft er also die enthaltene Transaktion auf Legitimität.

Das erste, was Flint überprüft, ist, ob dieser Block2 auch tatsächlich Block2 ist. Was ist damit gemeint? Nun, jeder Block muss seinen Status-Quo angeben. Das heißt, welchen Block er referenziert. In unserem Beispiel ist in Block2 vermerkt, dass er Block1 referenziert, seinen Vorgänger-Block.
Nachdem Flint die Referenz überprüft hat, fängt er an die in Block2 beinhalteten Transaktionen zu überprüfen: Er muss sichergehen, dass:

alle enthaltenen Transaktionen jeweils vom den rechtmäßigen Bitcoin-Eigentümern getätigt worden sind(=Ep. 1 Digitale Signaturen).

alle enthaltenen Transaktionen nur Bitcoins beinhalten, die nicht schon zuvor ausgegeben worden sind(=Double Spend)

Schauen wir uns das anhand der Transaktion in Block2 an, wo David 50 BTC an John senden möchte.

In Block2 initiiert David eine Transaktion, indem er in dieser Transaktion eine vorherige Transaktion referenziert. In unserem Beispiel deutet David auf die vorherige Transaktion in Block1. Im Prinzip sagt David, dass er der Empfänger dieser vorherigen Transaktion ist, und er diese empfangenen Bitcoins nun ausgeben möchte. Um zu beweisen, dass er tatsächlich der Empfänger dieser Bitcoins ist, hat David, wie schon erwähnt, den passenden privaten Schlüssel angeben(=Digitale Signaturen).

Anschließend muss Flint nur noch überprüfen, ob dieser referenzierte Bitcoin-Empfang aus Block1, nicht schon zuvor von David verwendet worden ist. Diese Überprüfung erfolgt, indem Flint alle Blocks zwischen dem referenzierten Bitcoinempfang(hier Block1) und der gewollten Ausgabe dieser referenzierten Bitcoins nach bereits getätigter Referenzierung(hier Block2), durchforstet.

Nachdem Flint das überprüft hat, fügt er diesen Block2 zu seiner lokalen Blockchain hinzu. Flint's eigene Blockchain besteht nun aus zwei Seiten: Block1 und Block2.

Als nächstes überprüft Flint in unserem Beispiel Block3 auf die gleiche Weise, wie er Block2 überprüft hat. Das geht so weiter bis Flints eigene Blockchain auf den neuesten Stand der Dinge ist, also alle existierende Blocks hinzugefügt hat.

Zusammenfassung

Eine neue Full-Node überprüft die erhaltenen Block-Kopien auf Korrektheit bevor sie zur eigenen lokalen Blockchain hinzugefügt werden

Die Full-Node überprüft zuerst, ob der letzte Block referennziert wird

Die Full-Node überprüft danach, ob die enthaltenen Transaktionen auch jeweils von den rechtmäßigen Eigentümern initiiert worden sind(=Digitale Signaturen).

Die Full-Node überprüft, ob die initiierte Transaktion nur empfangene Bitcoins referenziert, welche nicht schon zuvor referenziert, und somit ausgegeben, worden sind.

---