Zur Hauptseite  ..\..\..\                                                                       Zur Themenliste ..\..\                                                                Zu Bitcoin Full Node Wallet einrichten  ..\ 


Warum gibt es Bitcoin, Was ist die Absicht
Der Euro als Beispiel einer schlechten Währung
Hartes Geld vs. Regierungsgeld
Blockchain: Einführung
Blockchain: Konsensmechanismus
Vorgänge im Bitcoinnetzwerk (1)
Vorgänge im Bitcoinnetzwerk (2)
Proof of Work und Transaktionen
Weitere Punkte zur Bitcoinmechanik

Bitcoin einfach erklärt

Erläuterungen von Aspekten, die bisher zu kurz gekommen sind



Rechenaufgaben: Proof of Work

Das Prinzip nennt man "Proof of Work". Dieses wurde nicht mit Bitcoin erfunden, sondern wird schon länger für verschiedene Zwecke eingesetzt, beispielsweise bei der Bekämpfung von Email SPAM (leider hat sich das noch nicht flächendeckend durchgesetzt). Das Grundprinzip ist folgendes: Emailprogramme werden mit einem Algorithmus ausgestattet, der vor jedem Versenden eine Rechenaufgabe löst. In den Emails ist die Bestätigung für das Lösen der Aufgabe integriert. Der Empfänger kann verifizieren, dass die empfangene Email vom Absender durch Lösen einer Rechenaufgabe legitimiert wurde. Empfangene Emails, die keine solche Bestätigungen enthalten, können daher nur SPAM sein, und deshalb automatisch gelöscht werden, d.h., der Empfänger sieht diese erst gar nicht. Die Schwierigkeit der Rechenaufgaben ist so, dass sie einerseits für die Anwender (Sender, Empfänger) keine merkliche Zeit verbrauchen (z.B. 1 Sekunde), andererseits aber die massenhafte Versendung von SPAM Emails in kurzer Zeit unmöglich machen, und daher den Anreiz verderben, Spamserver zu betreiben.  Proof of Work ist also nicht nur Schutz vor SPAM, sondern er verdirbt sogar den Anreiz, SPAM zu versenden.

Die weitaus bekannteste Anwendung des
Proof of Work Prinzips findet sich jedoch in Bitcoin. Jeder Block enthält eine Rechenaufgabe, durch deren Lösung die Miner mit Bitcoin belohnt werden.
Dadurch werden gleich mehrere Fliegen mit einer Klappe geschlagen:

Transaktionen unter der Lupe: Outputs

Eine Bitcoin Wallet ist mit einer Adresse verknüpft, zu der wiederum ein Key gehört, den nur der Adressbesitzer kennt.
Bitcoins liegen nicht auf Adressen, sondern auf so genannten "Outputs", die Adressen zugeordnet sind. Eine Adresse kann beliebig viele Outputs haben.
Der Kontostand einer Wallet ist die Summe der Bitcoins, die auf Outputs liegen, die dieser Adresse zugeordnet sind.
Ein Output ist eine Stelle in einem Block der Blockchain, an der tatsächlich eine Anzahl Bitcoins liegt, anders formuliert, eine Stelle, die für zukünftige Transaktionen verwendet werden kann.
Ein Output ist also ein Bezugspunkt, der für eine potentielle Transaktion bereitsteht.

Wenn beispielsweise 0,1 Bitcoin auf Output X liegen, dann kann man davon nicht 0,2 Bitcoin in einer Transaktion verwenden - das ist klar.
Genauso wenig kann man aber auch lediglich 0,05 Bitcoins für eine Transaktion von Output X aus verwenden: Generell kann man den Inhalt eines Outputs nur ganz oder gar nicht verschieben.
Wenn also auf Output X 0,1 Bitcoin liegen, und nur 0,05 an jemand anderen transferiert werden sollen, dann geht das so:

    Man erstellt eine Transaktionsanforderung, bei der 0,05 Bitcoin an die Zieladresse, und die restlichen 0,05 Bitcoin an einen selbst überwiesen werden.
    Das klingt in dieser einfachen Formulierung komisch, deshalb muss man die Transaktion genauer ansehen. Ausgangspunkt ist Adresse ABC, auf deren Output X 0,1 Bitcoin liegen:
    Es wandern also von Output X 0,05 Bitcoin an Output Y, und ebenfalls 0,05 Bitcoin an Output Z.
    Y und Z sind
neu geschaffene Outputs, die für potentielle zukünftige Transaktion bereitstehen. Output X dagegen ist kein gültiger Output mehr, erkennbar daran, dass nichts drauf liegt.
    -> Jede Überweisung im Bitcoinnetzwerk kann nur von einem Output aus erfolgen (der wiederum einer Adresse zugeordnet ist), dabei entsteht an der Zieladresse ein neuer Output,
    während der ursprüngliche Output seine Gültigkeit verliert (nicht ganz, genaueres folgt weiter unten).
Der Grund, wieso das ausgerechnet so abläuft, liegt daran, dass es die automatische Verifizierung von Transaktionsanforderungen durch die Full Nodes vereinfacht. Dies wird anhand eines Beispiels erläutert.

Suche nach einem bestimmten Output

Zurück zu 11:30 Uhr, als Peters Walletsoftware den Transaktionswunsch in das Bitcoinnetzwerk einspeist. Der Einfachheit halber nehmen wir an, es sollen genau so viel Bitcoin transferiert werden, wie auf dem Output von Peters Adresse liegen. Die Transaktionsanforderung hat etwa folgende Gestalt:
Der Transaktionswunsch erreicht Alfreds Full Node. Dessen Bitcoinsoftware springt sofort zu Block 611.478 ihrer Blockchainkopie. Dieser Block enthalte z.B. 5.000 in der Vergangenheit abgeschlossene Transaktionen, die in dem Block in spezifischer Weise angeordnet, sodass der Output in maximal 25 Suchschritten gefunden wird (Merkle Tree, mit "verhashten" Ebenen, das ist zum Verständnis nebensächlich).
Das Auffinden des behaupteten Outputs UND die Tatsache, dass die behauptete Menge Bitcoin dort tatsächlich liegt, ist der Nachweis, dass die angeforderte Transaktion berechtigt ist, daher kommt die Transaktionsanforderung in Alfreds Transaktionspool, und wird an andere Nodes weitergeleitet. Durch kryptographische Techniken ist sichergestellt, dass nur Peter diese Anforderung generieren kann.

Das Beispiel zeigt, dass durch die Outputs die Verifizierung auf Gültigkeit von Transaktionsanforderungen sehr einfach und vor allem schnell geht. Die Bitcoinsoftware wird quasi mit der Nase auf die zu transferierende Bitcoins gestossen, ohne dass eine echte Suche stattfindet. Weiter oben wurde gesagt, nach einer Transaktion verliert der Output, von dem aus transferiert wurde, seine Gültigkeit.
Eigentlich ist es so: Der Output bleibt als solcher bestehen, doch jede weitere Transaktionsanforderung, die diesen Output als Quelle nennt, würde von den Full Nodes nicht verifiziert, und daher verworfen werden. De facto sind bereits verwendete Outputs also tot, können jedoch rückwirkend zur Verfolgung von Transaktionen verwendet werden.

Weiter

Datenschutzhinweise
Mai 2020