Bitcoin begreifen

8. Peer-to-Peer Netzwerk

Dieses Kapitel behandelt

Entfernen der letzten zentralen Autorität: der Shared Folder
Verfolgen einer Transaktion im Peer-to-Peer Netzwerk
Abschied von den albernen Cookie Tokens
Bootstrappen des Peer-to-Peer Netzwerks

Reden wir mal Tacheles: Reden wir von dem Shared Folder, den alle von den Minern produzierten Blocks auf ihrem Weg zu den anderen Minern und Full Nodes passieren müssen. Dieses Kapitel wird den zentralen Share entfernen und ihn durch ein dezentralisiertes Netzwerk von Gleichen, ein sog. Peer-to-Peer Netzwerk, ersetzen (Abbildung 1). Das Peer-to-Peer Netzwerk ermöglicht es den Full Nodes (einschliesslich Minern) sich einander die Blocks direkt zu schicken. Wenn Nodes direkt miteinander sprechen, brauchen wir zur Kommunikation keinen zentralen Autoritätspunkt mehr.

Ein weiteres Problem, von dem wir noch nicht gesprochen haben ist, wie Wallets Transaktionen via Mail an die Miner schicken. Wenn ein neuer Miner dem System beitritt, müssen alle Wallets ihre Miner-Liste aktualisieren. Nicht cool. Mit diesem schicken Peer-to-Peer Netzwerk von Nodes können Wallets ihre Transaktionen an alle Miner übermitteln, ohne zu wissen, wer oder wo diese sind.

Abbildung 1. Bitcoins Peer-to-Peer Netzwerk

Wir werden eine Transaktion auf ihrem Weg durch das Netzwerk betrachten, sowohl als unbestätigte Transaktion als auch, irgendwann später, als Teil eines produzierten Blocks. Die Transaktion wird in Johns Wallet anfangen und als bestätigte Transaktion in der Blockchain enden, wobei Bobs Wallet davon in Kenntnis gesetzt wird.

Nachdem wir die Transaktion durch das System begleitet haben, werden wir das Cookie Token System zum Verständnis von Bitcoin nicht mehr benötigen. Ab da werden wir nur noch von Bitcoin sprechen. Es existieren dann praktisch keine Unterschiede mehr zwischen dem Cookie Token System und Bitcoin, sodass es sinnlos ist, von Cookie Tokens zu reden, wenn wir doch eigentlich Bitcoin lernen wollen.

Das letzte Thema in diesem Kapitel behandelt, wie sich ein neuer Node mit dem Netzwerk verbindet und zu einem Teil desselben wird. Das ist alles andere als trivial. Wie findet er Nodes zum Verbinden? Wie lädt er die Blockchain bis zum jüngsten Block? All dies wird klargestellt. Gegen Ende des Kapitels lernst du dann, wie du deinen eigenen Node einrichtest.

8.1. Der Shared Folder

Der Administrator des Shares, Luke, ist eine zentrale Autorität (Abbildung 2). Schlussendlich entscheidet er, welche Blocks im Share Folder gespeichert werden können. Er entscheidet auch darüber, wer Lese- und wer Schreibberechtigung auf dem Share hat.

Abbildung 2. Der Shared Folder ist ein zentraler Punkt der Machtbefugnis.

Bisher hatten wir angenommen, das Luke ein völlig neutraler, netter Kerl ist–aber was, wenn nicht, oder was, wenn er durch die Acme Versicherung gezwungen wird, bestimmte Blocks abzulehnen? Wozu der Proof of Work, wenn das System auf der Blockebene zensiert werden kann? Proof of Work hat die Transaktionen zensurfest gemacht, weil es Benutzern erlaubte, ihre Transaktionen an mehrere Miner zu schicken. Aber die Blocks, die die Transaktionen enthalten, können immer noch von jemandem zensiert werden, der Administratorrechte auf dem Share besitzt. Einfach gesagt, ist das System noch nicht zensurresistent. Solange irgendeine Einheit entscheiden kann, welche Blocks oder Transaktionen erlaubt sind, ist das System nicht zensurfest.

Der Shared Folder stellt ein weiteres Problem dar. Nimm an, Rashid hat einen 1 MB Block erzeugt und ihn auf den Share gelegt. Jeder, der den Share im Auge behält, also alle Full Nodes, werden Rashids Block auf einmal herunterladen. Wenn wir 100 Full Nodes haben, ist der Gesamtbedarf an Daten, der vom Share heruntergeladen werden muss, 100 MB. Das macht die Verteilung des Blocks vom Erzeuger zu allen anderen Nodes–die Block Propagation–entsetzlich langsam. Je mehr Nodes, desto langsamer die Block Propagation.

8.2. Bauen wir ein Peer-to-Peer Netzwerk

Was wäre, wenn die Full Node und Miner direkt miteinander reden könnten, anstatt sich auf einen zentralen Share zu verlassen? Sie könnten sich die Blocks in einem Peer-to-Peer Netzwerk gegenseitig direkt schicken (Abbildung 3).

Abbildung 3. In einem Peer-to-Peer Netzwerk werden Blocks von einem Node zum nächsten geschickt, so wie sich Tratsch, oder Gossip, unter Menschen verbreitet.

Stell dir das Peer-to-Peer Netzwerk wie eine grosse Menge Leute vor. Einer allein weiss nicht alles, kennt aber vielleicht drei Leute. Wenn etwas Interessantes passiert–zum Beispiel, dass Rashid einen Block findet–dann erzählt er seinen drei Freunden davon, die ihrerseits wiederum all ihren Freunden davon erzählen, und das geht so weiter, bis jeder von dem neuen Block weiss. Wir nennen solche Netzwerke aus einleuchtenden Gründen Gossip Netzworks.

Relay

Einen Block zu relayen bedeutet, den Block an andere weiterzugeben.

Blocks können jetzt nicht mehr einfach gestoppt werden. Ein Node kann sich entscheiden, einen Block nicht an seine Peers weiterzugeben, nicht zu relayen, aber die Peers sind noch mit mehreren anderen Peers verbunden, die ihnen den Block gerne geben. Ein einzelner Node kann nicht viel an Zensur ausrichten.

Angenomen Rashid findet einen Block und er möchte diesen Block an alle Nodes verteilen. Rashid schickt seinen Block an Qi, To und das Café. Aus irgendeinem Grund leitet das Café den Block nicht an Lisa weiter (Abbildung 4). Aber Lisa hat mehrere Peers in ihrem Netzwerk. Sie ist mit Tom und Qi vernetzt. Tom erzählt Lisa von diesem neuen Block und schickt ihn ihr. Das Café kann die Information nicht vor Lisa verbergen, solange diese gut verbunden ist–viele verschiedene Peers hat.

Abbildung 4. Wenn das Café sich weigert, einen Block an Lisa weiterzuleiten, dann macht es jemand anders.

Jetzt, wo wir dieses schicke Netzwerk haben, können die Wallets das benutzen, um ihre Transaktionen an die Miner zu schicken. Dann werden sie nicht mehr die Liste der Mail-Adressen der Miner pflegen müssen. Die Transaktionen werden über das Peer-to-Peer Netzwerk ausgestrahlt, oder broadcast und erreichen innerhalb von Sekunden alle Full Nodes. Darunter auch die Miner, denn diese sind ebenfalls Full Nodes. Wir haben dies kurz in [ch01] behandelt und hier in Abbildung 5 nochmals dargestellt.

Abbildung 5. Transaktionen durchqueren das Peer-to-Peer Netzwerk, genau wie Blocks dies tun. Wallets brauchen die Miner nicht mehr zu kennen.

Hier gilt dasselbe wie für Blocks: ein einzelner Node kann Transaktionen nicht an einer Verbreitung über das Netzwerk hindern. Ein weiterer angenehmer Effekt der Benutzung des Peer-to-Peer Netzwerks für Transaktionen ist, dass der Empfänger einer Transaktion Bescheid bekommen kann, dass eine Transaktion aussteht, oder pending ist, also auf Bestätigung durch Minen eines ihn enthaltenden Blocks wartet. Wir schauen uns später an, wie das funktioniert.

8.3. Wie reden Peers?

TCP

Wenn man eine Webseite auf https://bitcoin.org öffnet, baut der Web Browser eine TCP Verbindung zu bitcoin.org auf, lädt eine Web Page über diese Verbindung herunter und zeigt sie an.

Schauen wir uns an, wie die Kommunikation zwischen Peers geschieht. Wir betrachten konkret, wie Tom sich mit Lisa verbindet, und wie sie über ihren Kommunikationskanal miteinander reden, der als Transmission Control Protocol (TCP) Verbindung bezeichnet wird (Abbildung 6).

Abbildung 6. Tom und Lisa kommunizieren über das Internet durch einen Kommunikationskanal.

Angenommen, Toms Node kennt Lisas Node. In Abschnitt 8.7 werde ich zeigen, wie Tom von anderen Nodes erfährt. Nehmen wir für den Moment an, dass er IP Adresse und Port von Lisas Node kennt. Jetzt möchte er sich mit Lisas Node verbinden, um mit ihr zu kommunizieren. Jeder Computer im Internet hat eine Internet Protocol (IP) Adresse; auf diese Weise können alle Computer Informationen zueinander schicken. Ein Computerprogramm, das nach eingehenden Verbindungen lauscht, führt ein listen auf einer bestimmten Portnummer seiner IP Adresse aus. Lisas Computer hat die IP Adresse 142.12.233.96, und es läuft darauf ein Cookie Token Programm, das auf Port 8333 horcht.

Port 8333

Port 8333 ist der Default Listening Port in Bitcoin Core, der verbreitetsten Full Node Software.

Toms Node verbindet sich mit Lisas Node über die IP Adresse 142.12.233.96 und den TCP Port 8333. Sein Node (Computerprogramm) fängt an, indem es sein Betriebssystem (OS für Operating System) um den Aufbau einer Verbindung zu Lisa bittet (Abbildung 7). Das OS schickt eine Message an Lisa’s Computer, dass Tom mit einem Computerprogramm auf Lisas Port 8333 sprechen möchte. Ihr Computer weiss, dass ein Programm auf Port 8333 hört, schickt also eine “Gern, willkommen” Meldung. Tom’s Computer quittiert das indem er eine “OK, cool. Reden wir …” Message schickt.

Abbildung 7. Toms Computerprogramm stellt eine TCP Verbindung mit Lisas Computer her. Danach können die beiden Daten miteinander austauschen.

Die Node Software auf Toms und Lisas Computern war an diesem Austausch nicht beteiligt–er wurde durch ihre Betriebssysteme erledigt, wie Linux, Windows oder macOS. Wenn die Nachrichtenabfolge erledigt ist, reicht das OS die Verbindung an die Node Software weiter. Lisas und Toms Nodes können jetzt frei miteinander sprechen. Über den Kommunikationskanal, die TCP Connection, kann Tom Daten an Lisa senden, und Lisa kann Daten an Tom schicken.

8.4. Das Netzwerkprotokoll

Tom und Lisa können jetzt über einen Kommunikationskanal Daten senden und empfangen. Aber wenn Toms Node eine Sprache spricht, die Lisas Node nicht versteht, ist die Kommunikation nicht sinnvoll (Abbildung 8). Die Nodes müssen eine gemeinsame Sprache benutzen: ein Protokoll.

Abbildung 8. Lisa muss verstehen können, was Tom im Kanal schreibt.

Das Cookie Token Netzwerk Protokoll definiert eine Menge erlaubter Nachrichtentypen. Eine typische Nachricht im Cookie Token (naja, Bitcoin) Netzwerk ist die inv Message (Abbildung 9).

Es ist eine Abstraktion

Echte Netzwerkmessages sehen nicht genau so aus; ich stelle eine abstrakte Sicht auf die Messages dar. Das genaue Format der Netzwerknachrichten zu behandeln, würde den Umfang dieses Buches sprengen.

Abbildung 9. Eine typische Netzwerkmessage

Ein Node benutzt die inv–kurz für inventory–Message, um andere Nodes über etwas zu informieren, was er besitzt. In Abbildung 9 informiert Toms Node Lisas Node, dass Tom Lisa drei Dinge anzubieten hat: zwei Transaktionen und einen Block. Die Message enthält eine ID für jedes dieser Objekte.

8.4.1. John schickt die Transaktion

Folgen wir einer Transaktion vom Anfang bis zum Ende durch das Netzwerk, um zu sehen, welche Netzwerkmessages benutzt werden. Wir gehen von einem bereits etablierten Peer-to-Peer Netzwerk aus. Wir kommen später darauf zurück, wie das Bootstrapping des Netzwerks vonstatten geht.

In [lightweight-wallets] hatten wir gesagt, dass Wallets sich mit Full Nodes verbinden und Informationen über alle Block Header und Transaktionen bekommen können (Abbildung 10).

Abbildung 10. Lightweight Wallets kommunizieren mit Nodes mit Hilfe des Bitcoin Protokolls.

Ich bin dort nicht ins Detail darüber gegangen, wie diese Kommunikation funktioniert. Sie benutzt dasselbe Protokoll, das die Nodes zur Kommunikation untereinander benutzen. Die Wallets und Full Nodes (einschliesslich der Miner) sprechen alle dieselbe “Sprache.”

Angenommen John möchte einen Keks vom Café kaufen. Johns Wallet ist mit Toms Node über einen TCP Kommunikationskanal verbunden. Er scannt die Zahlungs-URI vom Wallet des Cafés. Johns Wallet erzeugt und signiert dann die Transaktion. Das kennst du ja schon. Dann ist es Zeit, die Transaktion an Toms Node zu schicken (Abbildung 11).

Abbildung 11. Die Transaktion wird über eine TCP Verbindung an Toms Node geschickt.

Das geschieht in einem dreistufigen Prozess. Johns Wallet schickt die Transaktion nicht einfach ungefragt lost: es informiert zunächst Toms Node, dass eine Transaktion abgeholt werden kann (Abbildung 12).

Abbildung 12. Toms Node wird über Johns Transaktion informiert, sodass Tom sie abholen kann.

Die erste Nachricht ist eine inv Message, wie im vorangegangenen Abschnitt erklärt. Johns Wallet schickt das inv an Toms Full Node. Tom schaut nach, ob er die Transaktion bereits hat. Er hat sie noch nicht, weil Johns Wallet sie gerade erst erzeugt und noch niemandem geschickt hat. Toms Node will diese Transaktion haben, also fordert er sie mit einer getdata Message an, die aussieht wie eine inv Message, aber mit einer anderen Bedeutung: getdata heisst “Ich will dieses Zeug,” wogegen inv heisst “Ich habe dieses Zeug.”

Johns Wallet empfängt die getdata Message und schicht eine tx Message, in der die ganze Transaktion enthalten ist, an Toms Node. Tom wird die Transaktion verifizieren und behalten. Ausserdem wird er sie an seine Netzwerknachbarn relayen.

Du fragst dich vielleicht, weshalb Johns Wallet die Transaktion nicht gleich komplett schickt. Warum der Quatsch mit inv und getdata? Das wird später klarer, aber es liegt daran, dass Nodes die Transaktion vielleicht schon haben; wir sparen Bandbreite, indem wir nur die Transaktions-Hashes anstelle der gesamten Transaktion schicken.

8.4.2. Tom leitet die Transaktion weiter

Wenn die Transaktion gültig ist, informiert Toms Node seine Nachbarn darüber mit einer inv Message (Abbildung 13), genau wie Johns Wallet es getan hat, als es Toms Node über die Transaktion informiert hatte.

Abbildung 13. Tom leitet die Transaktion an seine Peers weiter.

Der Prozess ist für diese drei Nachrichtenwechsel derselbe wie der, den John benutzt hat, als er die Transaktion zuerst an Tom geschickt hat (Abbildung 14). Lisa, Qi und Rashid werden eine inv Message von Tom erhalten.

Abbildung 14. Toms Node schickt die Transaktion mit dem bekannten dreiteiligen Verfahren an Qis Node.

Wenn Lisa, Qi und Rashid die Transaktion bekommen haben, werden auch sie ihre Peers darüber informieren, sobald sie sie verifiziert haben. Qis und Rashids Nodes sind ein wenig langsamer, also dauert es bei ihnen ein bisschen länger, die Transaktion zu überprüfen; wir kommen später auf die beiden zurück.

Lisa war schnell mit dem überprüfen der Transaktion, also ist sie die erste beim relayen. Sie weiss bereits, dass sie die Transaktion von Tom bekommen hat, wird also Toms Node nicht mit einer inv Message informieren. Aber Lisa weiss nicht, dass Qi die Transaktion bereits hat, und sie weiss nicht, ob das Café sie hat. Sie sendet diesen beiden Nodes eine inv Nachricht. Der Nodes des Cafés wird ein getdata zurückschicken, weil er die Transaktion noch nicht gesehen hat. Qis Node hat die Transaktion bereits und wird überhaupt nicht antworten (Abbildung 15). Sie merkt sich allerdings, dass Lisa die Transaktion hat.

Abbildung 15. Lisas Node schickt ein inv an Qis Node, aber Qis Node hat die Transaktion bereits.

Qi hat gerade die Transaktion fertig geprüft. Sie weiss, dass Lisas Node sie schon hat, also braucht sie kein inv an Lisas Node zu schicken. Aber sie weiss nicht, ob Rashid sie hat, also schickt sie ein inv an Rashids Node.

Rashids war der langsamste Node beim Verifizieren von Johns Transaktion, also hat er schon ein inv von Qis Node bekommen, als es für ihn Zeit ist, das inv zu seinen Nachbarn zu schicken. Und er weiss von früher, dass Tom die Transaktion bereits hat. Er schickt nur einen inv an den Node des Cafes, der das inv ignorieren wird, weil er die Transaktion bereits besitzt.

8.4.3. Das Lightweight Wallet des Cafés wird benachrichtigt

Ich hatte zuvor erwähnt, dass eine gute Sache daran, die Transaktionen durch das Peer-to-Peer Netzwerk wandern zu lassen, die ist, dass ein Empfänger-Wallet eine frühe Benachrichtigung über eine ausstehende Transaktion erhalten kann. Schauen wir uns das einmal genauer an.

Der Full Node des Cafés hat die Transaktion erhalten und sie geprüft. Das Café hat auch ein Lightweight Wallet auf einem Mobiltelefon, das es zum Senden und Empfangen von Geld verwendet. Das Café macht sich Sorgen um die Sicherheit, also ist das Lightweight Wallet so konfiguriert, dass es sich nur mit dem Full Node des Cafés verbindet, seinem vertrauten Node oder Trusted Node (Abbildung 16).

Abbildung 16. Das Lightweight Wallet des Cafés verfügt über eine TCP-Verbindung zu einem eigenen Full Node.

Dieses gängige Setup gibt dem Café die völlige Sicherheit eines Full Nodes, kombiniert mit der Flexibilität und Mobilität eines Lightweight Wallets. Ich habe dieses Setup in [security-of-lightweight-wallets] beschrieben.

Der Full Node des Cafés hat gerade Johns Transaktion verifiziert. Er möchte nun seine Nachbarn über die neue Transaktion informieren. Er ist mit Lisas Node, Rashids Node und dem Lightweight Wallet des Cafés verbunden. Der Full Node weiss bereits, dass Lisas und Rashids Nodes diese Transaktion haben, schickt also kein inv an diese beiden Nodes. Der Full Node weiss nicht, ob das Wallet die Transaktion hat, aber es wird nicht sofort eine inv Message an das Wallet schicken.

Bloom Filter

Das Wallet ist ein Lightweight Wallet, das Bloom Filter benutzt, wie sie in [bloom-filters-obfuscate-addresses] beschrieben wurden. Der Full Node testet die Transaktion gegen den Bloom Filter, und wenn sie auf den Filter passt, schickt er eine inv Message an das Wallet. Wenn es nicht passt, schickt er keine inv Message.

Johns Transaktion geht an das Café, also passt der Bloom Filter auf die Transaktion und der Full Node wird ein inv senden. Das Wallet wird die volle Transaktion mittels getdata anfordern, wie in Abbildung 17 dargestellt.

Abbildung 17. Das Wallet des Cafes bekommt Johns Transaktion vom Trusted Node des Cafes, nachdem die Transaktion gegen den Bloom Filter geprüft wurde.

Das Wallet hat jetzt die Transaktion erhalten. Es kann dem Cafébesitzer eine Message anzeigen, dass eine Transaktion aussteht. Der Cafébesitzer hat nun die Wahl:darauf vertrauen, dass die Transaktion–eine sogenannte 0-conf Transaktion–irgendwann bestätigt wird, oder warten bis sie bestätigt ist. Wenn das Café die 0-conf Transaktion akzeptiert, dann vertraut es darauf, dass John eine ausreichend hohe Transaction Fee bezahlt hat und dass die Transaktion nicht doppelt ausgegeben wird.

Diesmal entscheidet das Café, dass es warten muss bis die Transaktion in einen gültigen Block Eingang gefunden hat. Dies bringt uns zur nächsten Phase: die Einbettung der Transaktion in einen Block in der Blockchain.

8.4.4. Einbetten der Transaktion in einen Block

Denken wir zurück an die Miner im System. Am Ende von [mitigating-miner-centralization] gab es 10 verschiedene Miner; aber drehen wir die Zeit zurück und tun so, als wären Qi, Tom, Lisa und Rashid zur Zeit die einzigen Miner im System.

Die Transaktion hat alle diese Miner im Rahmen der Transaction Propagation erreicht. Johns Wallet hat früher die Transaktion via Mail an alle Miner geschickt. Jetzt schickt er sie an irgendeinen Full Node, und sie pflanzt sich durch das gesamte Peer-to-Peer Netzwerk fort. Miner können wählen, Johns Transaktion in den Block, den sie gerade minen, zu integrieren. Angenommen, die Transaction Fee der Transaktion ist hoch genug, dass alle Miner gewillt sind, sie einzubetten, und dass Rashid als nächster Miner einen gültigen Proof of Work für seinen Block findet, der Johns Transaktion enthält (Abbildung 18).

Abbildung 18. Rashids Block enthält Johns Transaktion

Rashid möchte möglichst schnell seinen Block zu den anderen Minern bekommen und so das Risiko minimieren, dass ein anderer Miner vor Rashid einen Block propagiert.

BIP130

Der Prozess ist in BIP130 definiert, der den alten Block Propagation Mechanismus ersetzt, der inv Messages verwendet hat.

Er erzeugt eine headers Message und schickt sie an alle seine Peers: Tom, das Café und Qi. Rashid Peers werden eine getdata Nachricht zurückschicken und Rashid wird darauf mit dem eigentlichen Block antworten. Der Nachrichtenaustausch zwischen Rashid und Qi wird aussehen wie der in Abbildung 19.

Abbildung 19. Rashids Node schickt Rashids Block zu Qis Node.

Der eigentliche Block wird in einer block Message verschickt, die den ganzen Block enthält.

Verfolgen wir weiter die Block Propagation durch das Peer-to-Peer Netzwerk. Rashid hat seinen Block an Tom geschickt, and das Café und an Qi. Jetzt prüfen diese drei Nodes den Block und verschicken, falls er gültig ist, headers Messages an alle ihre Peers, die den Block vielleicht noch nicht haben (Abbildung 20).

Qi und Tom schicken einander zufällig gleichzeitig ihre headers Messages. Das ist kein Problem; weil beide den Block haben, ignorieren sie die headers Message von Peers. Lisa wird den Block von einem ihrer Peers anfragen, genauso wie Qi den Block von Rashid angefordert hat.

Abbildung 20. Alle ausser Lisa haben den Block. Tom, das Café und Qi schicken headers Messages.

Damit endet die Propagation dieses Blocks–fast. Die Lightweight Wallets müssen noch über den Block informiert werden.

8.4.5. Wallet Benachrichtigung

Toms Node ist mit Johns Wallet verbunden, also schickt Tom eine headers Message an John. Ebenso schickt der Full Node des Cafés eine headers Message an das Lightweight Wallet des Cafés. Die Full Nodes von Tom und dem Café testen den Block in keiner Weise auf Bloom Filter. Sie schicken die headers Message auf jeden Fall, aber das Lightweight Wallet wird den vollen Block nicht anfordern.

Wie dir vielleicht noch aus [ch06] in Erinnerung ist, laden Lightweight Wallets die vollen Blocks nicht herunter. Meistens ist Johns Wallet nur an den Block Headern interessiert, damit es den Proof of Work überprüfen kann. Aber ab und zu sind Transaktionen in einem Block, die für Johns Wallet interessant sind, und das Wallet will den Beweis, dass die Transaktion wirklich in dem Block enthalten sind. Um herauszufinden, ob relevante Transaktionen vorliegen, schickt er eine getdata Message an Tom und fordert eine merkleblock Message für den Block an.

John bekommt eine merkleblock Message, die den Block Header und einen partiellen Merkle Tree enthält, der seine Transaktions-ID (txid) an den Merkle Root im Block Header bindet (Abbildung 21).

Abbildung 21. Tom schickt einen merkleblock mit dem Merkle Proof, dass Johns Transaktion Teil des Blocks ist.

Abbildung 22 ist eine kleine Wiederholung von [ch06].

Abbildung 22. Die merkleblock Message enthält einen Block Header und einen partiellen Merkle Tree.

Johns Wallet wird verifizieren, dass

Der Block Header korrekt ist und gültigen Proof of Work hat.
Der Merkle Root im Header mittels des partiellen Merkle Tree rekonstruiert werden kann.
Die txid von Johns Transaktion ist in den partiellen Merkle Tree eingebunden. Um die irrelevanten Transaktionen, die ja nur vertuschen sollen, was zu John gehört, kümmert er sich nicht.

Johns Wallet ist jetzt sicher, dass sich seine Transaktion in dem neuen Block befindet. Das Wallet kann John eine Nachricht einblenden, die sagt “Deine Transaktion hat 1 Confirmation.”

Das Lightweight Wallet des Cafés wird auf die gleiche Weise benachrichtigt.

Weil das Wallet des Cafés einen Trusted Node verwendet ist Privacy kein grosses Problem (Abbildung 23). Das Wallet kann einen grossen Bloom Filter benutzen, um die Anzahl irrelevanter Transaktionen zu verringern, womit auch der Bedarf an Mobildaten sinkt. Je knapper der Bloom Filter, desto weniger Verschleierung + Datenverkehr wird an das Wallet geschickt.

Abbildung 23. Das Café fordert einen Merkle Block von seinem Trusted Full Node an.

Der Besitzer des Cafés kann John jetzt beruhigt den Keks übergeben. John isst ihn auf. Der Handel ist erledigt.

8.4.6. Mehr Confirmations

Im Laufe der Zeit werden von den Minern mehr Blocks produziert. Diese Blocks propagieren durch das Netzwerk und landen bei jedem Full Node. Die Lightweight Wallets bekommen Merkle Blocks, um Bandbreite zu sparen.

Für jeden neuen Block, der hereinkommt, wird Johns Transaktion unter mehr und mehr Proof of Work begraben (Abbildung 24). Das macht Johns Transaktion schwerer und schwerer doppelt auszugeben. Mit jedem neuen Block bekommt Johns Transaktion eine weitere Confirmation.

Abbildung 24. Je mehr Blocks ankommen, desto sicherer wird Johns Transaktion.

8.5. Wir verlassen das Cookie Token System

Ich glaube nicht, dass das Cookie Token System jetzt noch zum Verständnis von Bitcoin beiträgt. Es ist Zeit, das Cookie Token System loszulassen und zu beginnen, nur noch über Bitcoin zu sprechen. Wir haben das Cookie Token System bis zu einem Punkt weiterentwickelt, an dem es keine Unterschiede mehr zu Bitcoin gibt. Tabelle 1 zeigt die Konzept-Mapping-Tabelle.

Tabelle 1. Der Shared Folder wurde zugunsten des Peer-to-Peer Netzwerk verworfen.
Cookie Tokens	Bitcoin	Behandelt in
1 Cookie Token	1 bitcoin	[ch02]
Der Shared Folder	Das Bitcoin Netzwerk	Kapitel 8

Das letzte Cookie Token Konzept, das sich von Bitcoin unterscheidet, der Shared Folder, wurde eliminiert. Schauen wir, wie sich alles entwickelt hat, in Abbildung 25.

Wir behalten unsere Freunde im Büro noch eine Weile. John wird vermutlich ein paar weitere Kekse kaufen müssen, aber er wird die jetzt mit bitcoins bezahlen.

Abbildung 25. Die Evolution des Cookie Token Systems

8.5.1. Überblick über Bitcoin

Das Bitcoin Peer-to-Peer Netzwerk ist riesig. Zum Zeitpunkt des Schreibens:

Gibt es rund 10.000 öffentlich zugängliche Full Nodes.
Beträgt Bitcoins Geldmenge rund 17.400.000 BTC.
Ist jedes bitcoin rund $6.500 wert.
Arbeitet Bitcoin etwa 250.000 Transaktionen pro Tag ab.
Wird täglich ein Volumen von geschätzt 100.000 BTC mit einem Wert von $630 Millionen bewegt.
Beträgt die gesamte Mining Hashrate rund 50 EHash/s, or 50 × 10¹⁸ Hash/s. Ein typischer Desktop Computer schafft rund 25 MHash/s.
Werden pro Tag rund 17 BTC in Transaction Fee gezahlt. Das sind durchschnittlich 6.800 satoshis pro Transaktion, oder rund $0.40 pro Transaktion.
Benutzen Leute überall auf der Welt Bitcoin, um Probleme in ihrem Alltag zu umschiffen.

8.6. Wo waren wir?

In diesem Kapitel geht es um Bitcoins Peer-to-Peer Netzwerk. Die erste Hälfte des Kapitels beschreibt das Netzwerk in Aktion, nachdem es aufgesetzt wurde, wie in Abbildung 26 dargestellt, einer Wiederholung aus [ch01].

Abbildung 26. Das Bitcoin Netzwerk verteilt Blocks (und Transaktionen) an alle Teilnehmer.

Die zweite Hälfte des Kapitels betrachtet einen Node, der dem Netzwerk neu beitritt.

8.7. Bootstrappen des Netzwerks

Das Szenario in Abschnitt 8.4 ging davon aus, dass alle involvierten Nodes bereits miteinander verbunden waren. Aber wie beginnt ein neuer Node? Wie findet er andere Nodes, zu denen er sich verbinden kann? Wie lädt er die volle Blockchain ab dem Genesis Block, Block 0, bis zum letzten Block? Woher weiss er, was der letzte Block ist?

Klären wir das.

Nehmen wir an, Selma möchte einen eigenen Full Node starten. Folgendes würde typischerweise geschehen (Abbildung 27):

Selma lädt, verifiziert und startet das Full Node Computerprogramm.
Das Computerprogramm verbindet sich mit einigen Nodes.
Selmas Node lädt Blocks von ihren Peers.
Selmas Node geht in den normalen Betrieb über.

Abbildung 27. Der Betrieb eines Full Nodes involviert das Herunterladen und Laufenlassen der Software, das Verbinden zu anderen Nodes, Herunterladen von alten Blocks und den Übergang in den normalen Betrieb.

8.7.1. Schritt 1–Starte die Software

Selma braucht ein Computerprogramm, um einen Full Node laufen zu lassen. Das am häufigsten benutzte solche Programm ist Bitcoin Core. Einige andere sind verfügbar, wie libbitcoin, bcoin, bitcoinj und btcd. Wir fokussieren und nur auf Bitcoin Core, aber du kannst gern die anderen selbst ausprobieren.

Um Bitcoin Core herunterzuladen, besucht Selma dessen Webseite, https://bitcoincore.org, und findet dort den Download Link. Aber sie trifft auf ein mögliches Problem: Selma ist sich nicht sicher, ob das Programm, das sie herunterlädt, wirklich die Version ist, die von den Bitcoin Entwicklern freigegeben wurde. Jemand könnte Selma getäuscht haben, sodass sie das Programm von bitconcore.org herunterlädt statt von bitcoincore.org, oder jemand könnte bitcoincore.org gehackt haben und die Download Dateien durch andere Programme ersetzt haben.

Das Bitcoin Core Team signiert deshalb alle freigegebenen Versionen des Programms mit einem private Key–nennen wir ihn den Bitcoin Core Key. Sie liefern die Signatur in einer herunterladbaren Datei namens SHA256SUMS.asc. Diese Datei enthält den Hashwert der freigegebenen Bitcoin Core Software und eine Signatur, die den Inhalt von SHA256SUMS.asc signiert (Abbildung 28).

Abbildung 28. Das Bitcoin Core Team signiert das freigegebene Programm mit seinem private Key.

Selma hat sowohl das Programm heruntergeladen, in einer Datei namens bitcoin-0.17.0-x86_64-linux-gnu.tar.gz, und die Signaturdatei, SHA256SUMS.asc. Um zu verifizieren, dass das Programm in der Tat mit dem Bitcoin Core private Key signiert wurde, muss sie den korrespondierenden public Key kennen. Aber woher soll sie den kennen?

Das ist ein schwieriges Problem. Weisst du noch, als Lisa Blocks mit ihrem private Key signiert hat? Wie haben die Full Node verifiziert, dass die Blocks wirklich von Lisa signiert waren? Sie hatten mehrere Quellen benutzt, um Lisas public Key zu holen–zum Beispiel das schwarze Brett am Eingang zum Büro, das Intranet der Firma, und das Befragen von Kollegen. Dasselbe gilt hier; man sollte nicht einer einzelnen Quelle glauben, sondern sollte mindestens zwei verschiedene Quellen heranziehen. Der Key, der zur Zeit zum Signieren der Bitcoin Core Releases benutzt wird, heisst

Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>

und hat den folgenden 160-bit SHA1 Hash, oder Fingerprint:

01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964

Dieses Buch kann als eine von Selmas Quellen dienen. Sie beschliesst

Den Fingerprint des Keys von https://bitcoincore.org zu holen.
Den Fingerprint mit dem Bitcoin Begreifen Buch zu verifizieren.
Den Fingerprint mit einem Freund zu verifizieren.

Wo bekommt man den Key?

Es ist eigentlich ziemlich egal, wo du den public Key herbekommst, aber es ist wichtig zu verifizieren, dass der Fingerprint der ist, den du erwartest.

Die Fingerprints der drei Quellen stimmen überein, also lädt Selma den public Key von einem Key Server herunter. Ein Key Server ist ein Computer im Internet, der eine Datenbank von Keys bereitstellt. Key Server werden üblicherweise benutzt, um Keys anhand ihrer Fingerprints herunterzuladen. Selma vertraut dem Key Server nicht, also muss sie verifizieren, dass der Fingerprint ihres heruntergeladenen Keys dem erwarteten Fingerprint entspricht, was er tut.

Nun, da sie den Bitcoin Core public Key besitzt, kann sie die Signatur der Datei SHA256SUMS.asc überprüfen (Abbildung 29).

Sie benutzt den Bitcoin Core public Key, um die Signatur in der Signaturdatei zu überprüfen. Sie muss auch verifizieren, dass das Programm denselben Hashwert hat, wie er in SHA256SUMS.asc steht. Die Signatur ist gültig und die Hashes passen, was bedeutet, Selma kann sicher sein, dass die Software, die sie laufen lassen will, authentisch ist.

Abbildung 29. Selma verifiziert die Bitcoin Core Signatur, und dass der Hash in der Signaturdatei zum Hash des eigentlichen Programms passt.

Selma startet das Programm auf ihrem Computer.

8.7.2. Schritt 2–Verbindung zu Nodes

Als Selmas Full Node Programm startet, ist es noch mit keinem anderen Node verbunden. Sie ist noch nicht Teil des Bitcoin Netzwerks. In diesem Schritt wird der Node versuchen, Peers zum Verbinden zu finden.

Um sich mit einem Peer zu verbinden, braucht der Full Node die IP Adresse und die TCP Portnummer für diesen Peer. Zum Beispiel:

IP: 142.12.233.96 Port: 8333

Eine IP Adresse und Portnummer werden oft geschrieben als

142.12.233.96:8333

Finden der ersten Peers

Wo findes Selmas Node die ersten Adressen anderer Peers? Mehrere Quellen sind verfügbar (Abbildung 30):

Man konfiguriert den Full Node mit benutzerdefinierten Adressen. Selma kann eine Adresse bekommen, indem sie einen Freund fragt, der einen Node am laufen hat.
Man benutzt das Domain Name System (DNS), um die ersten Adressen nachzuschlagen, zu denen man sich verbindet.
Man benutzt hartkodierte Peer Adressen im Full Node Programm.

Abbildung 30. Selmas Full Node hat drei verschiedene Arten von Quellen, um initiale Peers zu finden.

Selmas Node sollte sich nicht anfangs mit nur einem Node verbinden. Falls dieser einzelne Node bösartig wäre, könnte sie das unmöglich feststellen. Wenn man sich gleich zu Beginn mit mehreren Nodes verbindet, kann man überprüfen, dass die Daten, die diese senden, miteinander konsistent sind. Wenn nicht, dann lügen eine oder mehrere Nodes dich an, oder sie sind selbst hereingefallen.

Der normale Weg, initiale Node Adressen zu finden ist, sie im DNS System nachzuschlagen. DNS ist ein globales Namen Nachschlagesystem, das benutzt wird, um die IP Adressen zu Computernamen zu finden. Zum Beispiel, wenn du https://bitcoin.org mit deinem Web Browser besuchst, wird er DNS benutzen, um die IP Adresse zu dem Namen bitcoin.org zu finden. Die Bitcoin Core Software tut dasselbe. Die nachzuschlagenden Namen sind in Bitcoin Core hartkodiert, genau wie die hartkodierten IP Adressen und Ports. Mehrere DNS Seeds sind in die Software hineincodiert. Ein Nachschlagen im DNS kann mehrere IP Adressen zurückliefern, und jedes neue Nachschlagen könnte einen anderen Satz von IP Adressen liefern. Die dritte und letzte Option wird als letzter Ausweg benutzt.

Bedenke von Abbildung 30, dass DNS Nachschlageresultate keine Portnummern enthalten. Die anderen beiden Methoden, initiale Peers zu finden, enthalten normalerweise eine, aber die DNS Antwort kann lediglich IP Adressen liefern. Von den Nodes dieser IP Adressen kann man annehmen, dass sie auf den Default Port von Bitcoin Core horchen, und der ist 8333.

Handshaking

Angenommen Selmas Node verbindet sich mit Qis Node, 1.234.63.203:4567 und mit Rashids Node, 47.196.31.246:8333. Selma richtet eine TCP Verbindung zu jedem der beiden Nodes ein und schickt eine initiale Message an jede der beiden über die neuen TCP Verbindungen. Schauen wir uns an, wie sie mit Qis Node spricht (Abbildung 31).

Abbildung 31. Selma tauscht eine version Message mit Qi aus.

Der Austausch, genannt Handshake, beginnt bei Selma, die eine version Message an Qi schickt. Der Handshake wird benutzt, um sich auf eine Protokollversion zu einigen und um einander mitzuteilen, welche Block Heights sie jeweils haben. Die version Messsage enthält eine Menge Information, die nicht im Bild gezeigt wird, aber das Wichtigste ist da:

Protokollversion: Die Version des Netzwerkprotokolls, oder der “Sprache,” die Peers benutzen, um miteinander zu reden. Selma und Qi werden version 70012 benutzen, weil das die höchste Version ist, die Qi versteht. Selma kennt alle Protokollversionen bis hinauf zu ihrer eigenen.
User Agent: Das wird im Bild als “Software Identifikation” bezeichnet, weil “User Agent” etwas kryptisch klingt. Es wird als Hinweis an den anderen Node benutzt, welche Software bei uns läuft, kann aber beliebig sein.
Height: Dies ist die Höhe, die Height der Spitze der besten Chain, die der Node hat.

Sonstige nützliche Informationen in der version Message sind unter anderem

Services: Eine Liste von Features, die dieser Node unterstützt, wie die von Lightweight Clients benutzten Bloom Filter.
Meine Adresse: Die IP Adresse und Portnummer des Nodes, der die version Message schickt. Ohne sie wüsste Qi nach einem Restart nicht, wie sie sich wieder mit Selmas Node verbinden könnte.

Wenn Qis Node Selmas version Message empfängt, antwortet Qi mit ihrer eigenen version Message. Ausserdem schickt sie eine verack Message direkt am Anschluss an die version Message. Das verack enthält keine weitere Information; es wird nur benutzt um Selma zu bestätigen, dass Qi die version Message erhalten hat.

Sobald Selmas Node Qis version Message erhalten hat, antwortet sie Qis Node mit einer verack Message. Der Handshake ist erledigt. Selma geht dieselbe Prozedur mit Rashids Node durch.

Die Peers der Peers finden

Wenn Selmas Node sich mit Rashids Node verbunden hat, bittet er diesen Node um weitere Peer Adressen, mit denen er sich verbinden kann. So kann Selma ihre Menge an Peers erweitern (Abbildung 32).

Abbildung 32. Selma bittet ihre Peers um zusätzliche Peer-Adressen.

Selma ist erst mit zwei Peers verbunden: Qis Node und Rashids Node. Aber sie findet, dass sie Verbindung zu mehr Nodes braucht. Nur mit zwei Nodes verbunden zu sein hat einige Implikationen:

Qi und Rashid könnten kollaborieren, um Transaktionen und Blocks vor Selma geheimzuhalten.
Qis Node könnte ausfallen, womit Selma dann auf Rashids Node angewiesen ist und dieser könnte den Informationsfluss an Selma beliebig einschränken.
Sowohl Qis als auch Rashids Nodes könnten ausfallen, womit dann Selma vollständig vom Netzwerk getrennt wäre, bis sie sich über den initialen Peer-Nachschlage-Mechanismus wieder mit ein paar anderen Nodes verbindet.

Abbildung 33 zeigt, wie Selma Rashid um mehr Peer-Adressen zum Verbinden bittet.

Abbildung 33. Selma erbittet mehr Peer-Adressen von Rashids Node. Er antwortet mit einem ganzen Bündel.

Initiale Nodes

Nach Empfang einer addr Message trennen sich Nodes von den Initialnodes wieder (ausser von den manuell konfigurierten), um deren Überlastung zu verhindern. Sie dienen schliesslich vielen weiteren Nodes als Initialnodes.

Selma schickt eine getaddr Message an einen Peer, Rashids Node. Rashid antwortet mit einem Satz IP Adressen und TCP Ports, die Selma zum Verbinden mit weiteren Peers benutzen kann. Rashid bestimmt, welche Adressen er Selma schickt, aber normalerweise sind es die Adressen, mit denen Rashid bereits verbunden ist und vielleicht noch ein paar, die Rashid von seinen Peers aufgesammelt, aber nicht selbst verwendet hat.

Selma verbindet sich mit einigen der empfangenen Adressen, um ihren Verbindungsgrad, ihre Connectivity, zu erhöhen. Mit je mehr Peers man verbunden ist, desto höhere Connectivity hat man. Ein hoher Grad an Connectivity verringert das Risiko, Informationen zu verpassen, weil sich Peers schlecht benehmen. Ausserdem verbreitet sich Information schneller, wenn mehr Nodes eine höhere Connectivity haben. Ein typischer Bitcoin Full Node hat etwa 100 aktive Verbindungen gleichzeitig. Davon sind nur acht (in der Standardeinstellung, dem Default) ausgehende Verbindungen oder outbound Connections, also Verbindungen, die von diesem Node ausgehend aufgebaut wurden. Der Rest sind einkommende Verbindungen oder inbound Connections, die von anderen Nodes aufgebaut wurden. Demzufolge wird ein Full Node, der nicht auf Port 8333 aus dem Internet erreichbar ist–zum Beispiel aufgrund einer Firewall–insgesamt nicht mehr als acht Verbindungen haben.

8.7.3. Schritt 3–Synchronisieren

Jetzt, da Selma gut verbunden mit, und Teil von, dem Bitcoin Netzwerk ist, ist es Zeit für sie, die volle Blockchain bis zum letzten verfügbaren Block herunterzuladen und zu verifizieren.Dieser Prozess heisst Synchronisierung, sync oder Initial Block Download.

Selma hat nur einen einzigen Block: den Genesis Block. Der Genesis Block ist in der Bitcoin Core Software hartcodiert, sodass alle Nodes ihn beim Start bereits haben.

Sie muss alle historischen Blocks von ihren Peers herunterladen, bevor sie neu erzeugte Blocks verifizieren kann. Denn sie hat keine Ahnung, wie die aktuelle Menge an unbenutzten Transaktions Outputs (unspent transaction outputs, UTXO Set) aussieht. Um sich das aktuelle UTXO Set zusammen zu bauen, muss sie mit einem leeren UTXO Set beginnen, alle historischen Blocks beginnend bei Block 0 durchgehen und das UTXO Set mit den Informationen aus den Transaktionen in den Blocks aktualisieren.

Der Prozess ist wie folgt:

Lade alle historischen Block Header von einem Peer herunter und verifiziere den Proof of Work.
Alle Blocks der stärksten Chain von mehreren Peers gleichzeitig herunterladen.

Selma sucht Tom als den Peer aus, von dem sie alle Block Header herunterladen möchte. Abbildung 34 zeigt, wie Selmas Node die Block Header von Toms Node lädt.

Vereinfacht

Die getheaders Message enthält eine Liste einiger Block IDs von Selmas Blockchain, sodass Tom auch dann einen gemeinsamen Block mit Selma finden kann, wenn Tom nicht Selmas Chain Tip hat. Kümmern wir uns aber nicht gross darum.

Sie schickt eine getheaders Message mit Selmas jüngster Block ID, die zufälligerweise der Genesis Block, Block 0, ist. Tom schickt eine Liste mit 2.000 Block Headern zurück; jeder Block Header ist 80 Bytes. Selma verifiziert den Proof of Work von jedem Header und fordert ein neues Bündel Header von Tom an. Dieser Prozess setzt sich fort, bis Selma ein Bündel von weniger als 2.000 Headern von Tom erhält, was das Signal dafür ist, dass er keine weiteren Header für Selma hat.

Abbildung 34. Selma lädt die Block Header von Tom, indem sie wiederholt getheaders Messages mit ihrer jüngsten Block ID schickt.

Wenn Selma alle Header von Tom bekommen hat, bestimmt sie, welcher Zweig der stärkste ist und fängt an, die eigentlichen Blockdaten dieses Zweiges von ihren Peers zu laden. Sie kann von mehreren Peers gleichzeitig Daten holen, um die Geschwindigkeit zu erhöhen. Abbildung 35 zeigt ihre Kommunikation mit Rashids Node.

Grössere Brocken

In diesem Beispiel fordert Selma 3 Blocks auf einmal an, aber in Wirklichkeit würde Bitcoin Core eine Liste von mindestens 16 Blocks pro Bündel anfordern.

Es beginnt mit Selma, die eine getdata Message an Rashid schickt. Diese Message spezifiziert, welche Blocks sie von Rashid laden will, und dieser schickt die angeforderten Blocks einzeln in block Messages. Selma lädt wohlgemerkt nur einige der Blocks von Rashid. Sie lädt gleichzeitig auch Blocks von Tom, weshalb es in der Abfolge von Blocks Lücken gibt. Dieser Prozess wiederholt sich, bis Selma keine weiteren Blocks mehr von Rashid will.

Abbildung 35. Selma lädt Blocks von Rashid, indem sie wiederholt getdata Messages mit einer Liste von Block IDs schickt, zu denen sie die Blocks braucht.

Initialer Download

Der Initial Blockchain Download, ungefähr 210 GB zum Zeitpunkt des Schreibens, dauert einige Stunden bis Tage, abhängig von der Hardwareleistung und Internetgeschwindigkeit.

Während Selma Blocks lädt, wird Rashid wahrscheinlich weitere neue Blocks von seinen Peers erhalten. Angenommen er bekommt einen neuen Block während Selma die ersten 100 Blocks von Rashid erhält. Dann wird Rashid eine headers Message an seine Peers, einschliesslich Selma, schicken, wie in Abschnitt 8.4.4 beschrieben. Auf diese Weise bleibt Selma über alle neuen Blocks informiert, die während ihrer initialen Synchronisation erscheinen, und kann sie später von irgendeinem Peer anfordern.

Während Selma Blocks empfängt, verifiziert sie diese, aktualisiert ihr UTXO Set und fügt die Blocks ihrer eigenen Blockchain hinzu.

Verifikation früher Blocks

Der zeitraubendste Teil an der Verifikation eines Blocks ist die Verifikation der Transaktions-Signaturen. Wenn man irgendeine Block ID kennt, die Teil der gültigen Blockchain ist, dann kann man das Verifizieren der Signaturen aller Blocks bis einschliesslich zu diesem überspringen (Abbildung 36). Das beschleunigt den Initial Blockchain Download bis zu diesem Block stark.

Abbildung 36. Um den Initial Block Download zu beschleunigen, werden die Signaturen hinreichend alter Transaktionen nicht verifiziert.

Andere Dinge, wie die Prüfung, dass keine Double-Spends passieren oder dass die Block Rewards korrekt sind, werden immer noch durchgeführt. Der synchronisierende Node muss sein eigenes UTXO Set aufbauen, also muss er immer noch durch alle Transaktionen gehen, um das UTXO Set entsprechend zu aktualisieren.

Bitcoin Core kommt mit der vorkonfigurierten Block ID eines Blocks von einigen Wochen vor dem Release Datum. Für Bitcoin Core 0.17.0 ist dieser Block

Height: 534292
Hash: 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8

Das ist ungefähr 10.000 Blocks älter als das Release Datum. Das ist natürlich ein Konfigurationsparameter, und der erwähnte Block ist nur ein vernünftiger Defaultwert. Selma hätte das ändern können, als sie ihren Node gestartet hat, oder sie hätte mit Freunden und anderen vertrauten Quellen verifizieren können, dass dieser Block in der Tat eine “alle Transaktionen sind gültig Blockchain” repräsentiert. Sie hätte das Feature auch sperren können, um alle Transaktionssignaturen seit Block 0 zu überprüfen.

Nach einer Weile ist Selma endlich auf gleicher Höhe mit den anderen Nodes und bereit zum Übergang in den Normalbetrieb.

8.7.4. Schritt 4–Normalbetrieb

Dieser Schritt ist einfach, denn wir haben ihn bereits in Abschnitt 8.4 besprochen. Selma beginnt den Normalbetrieb. Von nun an wird sie bei der Block- und Transaktionsverbreitung mitmachen und jede einkommende Transaktion verifizieren (Abbildung 37).

Selma hat jetzt einen ausgewachsenen Full Node.

Abbildung 37. Selma ist endlich ein aktiver Teil des Bitcoin Peer-to-Peer Netzwerks.

8.8. Betrieb eines eigenen Full Nodes

Online Anleitungen

Detailliertere Instruktionen für alle grösseren Betriebssysteme findest du auf [web-install].

Dieser Abschnitt führt dich durch das Aufsetzen deines eigenen Bitcoin Full Nodes auf einem Linux OS. Es richtet sich an Leser, die sich mit Linux und der Kommandozeile auskennen.

Du hast gesehen, wie in der Theorie ein Bitcoin Full Node heruntergeladen, gestartet und synchronisiert wird. Dieser Abschnitt hilft dir, deinen eigenen Full Node zu installieren.

Dieser Abschnitt setzt voraus, dass du

Einen Computer mit mindestens 2 GB RAM und einem Linux OS hast
Eine Menge freien Platz auf der Festplatte hast, etwa 210 GB werden benötigt.
Eine Internetverbindung ohne eingeschränkten Datenvolumen.
Weisst, wie man zu einer Kommandozeile kommt und wie man sie bedient.

Wenn du kein Linux OS hast, kannst du diese Anweisungen trotzdem benutzen; aber du musst die Version von Bitcoin Core installieren, die zu deinem Betriebssystem passt, und die Kommandos werden anders aussehen. Ich schlage vor, du gehst auf [web-install] um aktuelle Anweisungen für dein nicht-Linux OS zu bekommen.

Im allgemeinen ist der Prozess, um seinen eigenen Node aufzusetzen, folgender:

Lade Bitcoin Core von https://bitcoincore.org/en/download herunter.
Verifiziere die Software.
Entpacke und starte sie.
Warte, bis der Initial Blockchain Download fertig ist.

8.8.1. Bitcoin Core downloaden

Um deinen eigenen Bitcoin Full Node zu betreiben, musst du das Softwareprogramm laufen lassen. In diesem Beispiel lädst du Bitcoin Core von [web-download] herunter. Zum Zeitpunkt des Schreibens ist die jüngste Version von Bitcoin Core 0.17.0. Laden wir sie herunter:

$ wget https://bitcoincore.org/bin/bitcoin-core-0.17.0/\
    bitcoin-0.17.0-x86_64-linux-gnu.tar.gz

Wie der Dateiname bitcoin-0.17.0-x86_64-linux-gnu.tar.gz andeutet, lädt das Kommando die Version 0.17.0 für 64-bit (x86_64) Linux (linux-gnu). Zu der Zeit, wo du dies hier liest, sind wahrscheinlich schon neuere Versionen von Bitcoin Core freigegeben worden. Schaue auf [web-download] nach, um die jüngste Version von Bitcoin Core zu bekommen. Und falls du ein anderes Betriebssystem oder eine andere Computerarchitektur benutzt, dann suche bitte die richtige Datei für dich aus.

8.8.2. Verifizieren der Software

Dieser Abschnitt ist schwierig und verlangt eine ganze Menge Arbeit auf der Kommandozeile. Wenn du die Bitcoin Core Software nur zum experimentieren installieren und laufen lassen willst, kannst du diesen Abschnitt überspringen und zu Abschnitt 8.8.3 springen. Wenn du es nicht nur zum experimentieren nimmst, dann verstehe bitte zunächst die Risiken die weiter vorne in diesem Kapitel unter Abschnitt 8.7.1 besprochen wurden, bevor du weiterspringst.

Dieser Abschnitt zeigt dir, wie du verifizieren kannst, dass die heruntergeladene .tar.gz Datei nicht irgendwie verfälscht worden ist. Die Datei ist mit dem private Key des Bitcoin Core Teams signiert worden. Der Überprüfungsprozess besteht aus den folgenden drei Schritten:

Lade die Signaturdatei herunter
Verifiziere, dass der Hash der .tar.gz Datei zum Hash im Message Teil der Signaturdatei passt.
Lade den public Key des Bitcoin Core Teams herunter.
Installiere den public Key als vertrauenswürdig auf deinem Computer.
Verifiziere die Signatur.

Fangen wir an.

Herunterladen der Signaturdatei

Um zu prüfen, dass dein heruntergeladenes Bitcoin Paket tatsächlich vom Bitcoin Core Team stammt, muss du die Signaturdatei namens SHA256SUMS.asc herunterladen. Abbildung 38, wiederholt von Abschnitt 8.7.1, erklärt den Aufbau der SHA256SUMS.asc Datei.

Abbildung 38. Das Bitcoin Core Team signiert das freigegebene Programm mit seinem private Key.

Lade die Signaturdatei SHA256SUMS.asc von demselben Server, von dem du das Programm geladen hast:

$ wget https://bitcoincore.org/bin/bitcoin-core-0.17.0/SHA256SUMS.asc

Die Datei wird benutzt, um zu überprüfen, dass das geladene .tar.gz File vom Bitcoin Core Team signiert wurde. Beachte, dass diese Datei nur für Version 0.17.0 gilt. Wenn du eine andere Version von Bitcoin Core benutzt, dann hol dir die passende Signaturdatei von [web-download].

Das folgende Listing zeigt, wie der Inhalt der Datei aussieht (die eigentlichen Hashes sind abgekürzt worden):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

1e43...35ed  bitcoin-0.17.0-aarch64-linux-gnu.tar.gz
a4ff...7585  bitcoin-0.17.0-arm-linux-gnueabihf.tar.gz
967a...f1b7  bitcoin-0.17.0-i686-pc-linux-gnu.tar.gz
e421...5d61  bitcoin-0.17.0-osx64.tar.gz
0aea...ac58  bitcoin-0.17.0-osx.dmg
98ef...785e  bitcoin-0.17.0.tar.gz
1f40...8ee7  bitcoin-0.17.0-win32-setup.exe
402f...730d  bitcoin-0.17.0-win32.zip
b37f...0b1a  bitcoin-0.17.0-win64-setup.exe
d631...0799  bitcoin-0.17.0-win64.zip
9d6b...5a4f  bitcoin-0.17.0-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJbtIOFAAoJEJDIAZ42wulk5aQP/0tQp+EwFQPtSJgtmjYucw8L
SskGHj76SviCBSfCJ0LKjBdnQ4nbrIBsSuw0oKYLVN6OIFIp6hvNSfxin1S8bipo
hCLX8xB0FuG4jVFHAqo8PKmF1XeB7ulfOkYg+qF3VR/qpkrjzQJ6S/nnrgc4bZu+
lXzyUBH+NNqqlMeTRzYW92g0zGMexig/ZEMqigMckTiFDrTUGkQjJGzwlIy73fXI
LZ/KtZYDUw82roZINXlp4oNHDQb8qT5R1L7ACvqmWixbq49Yqgt+MAL1NG5hvCSW
jiVX4fasHUJLlvVbmCH2L42Z+W24VCWYiy691XkZ2D0+bmllz0APMSPtgVEWDFEe
wcUeLXbFGkMtN1EDCLctQ6/DxYk3EM2Ffxkw3o5ehTSD6LczqNC7wG+ysPCjkV1P
O4oT4AyRSm/sP/o4qxvx/cpiRcu1BQU5qgIJDO+sPmCKzPn7wEG7vBoZGOeybxCS
UUPEOSGan1Elc0Jv4/bvbJ0XLVJPVC0AHk1dDE9zg/0PXof9lcFzGffzFBI+WRT3
zf1rBPKqrmQ3hHpybg34WCVmsvG94Zodp/hiJ3mGsxjqrOhCJO3PByk/F5LOyHtP
wjWPoicI2pRin2Xl/YTVAyeqex519XAnYCSDEXRpe+W4BdzFoOJwm5S6eW8Q+wkN
UtaRwoYjFfUsohMZ3Lbt
=H8c2
-----END PGP SIGNATURE-----

Die signierte Message im oberen Teil der Datei listet mehrere Dateien zusammen mit ihren jeweiligen SHA256 Hashes auf. Die aufgezählten Dateien sind Installationspakete für alle Betriebssysteme und Architekturen, für die Bitcoin Core freigegeben worden ist. Der untere Teil der Datei ist die Signatur der Message im oberen Teil. Die Signatur bindet sich an die gesamte Message und damit an alle Hashes und Dateien, die in der Message aufgelistet werden.

Überprüfen des Hashes der heruntergeladenen Datei

Die Datei, die du heruntergeladen hast, heisst bitcoin-0.17.0-x86_64-linux-gnu.tar.gz, also erwartest du, dass der SHA256 Hash dieser Datei mit 9d6b…5a4f übereinstimmt. Schauen wir mal nach:

$ sha256sum bitcoin-0.17.0-x86_64-linux-gnu.tar.gz
9d6b472dc2aceedb1a974b93a3003a81b7e0265963bd2aa0acdcb17598215a4f  bitcoin-0.17.0-x86_64-linux-gnu.tar.gz

Das Kommando berechnet den SHA256 Hash deines heruntergeladenen Files. Er stimmt tatsächlich mit dem Hash in der Datei SHA256SUMS.asc überein. Wenn die beiden nicht übereinstimmen würden, dann würde irgendetwas nicht stimmen und du solltest mit der Installation aufhören und nachschauen, was da los ist.

Den Bitcoin Core Signier Key holen

Um zu prüfen, dass die Signatur in der Signaturdatei mit dem Bitcoin Core Key geleistet wurde, brauchst du den dazugehörigen public Key. Wie in Abschnitt 8.7.1 erwähnt, musst du nachschauen, welchen Fingerprint der Bitcoin Core Key besitzt, und dann diesen Key von irgendwo herunterladen.

Du könntest zum Beispiel:

Den Fingerprint des Bitcoin Core Teams von https://bitcoincore.org holen, der offiziellen Webseite des Bitcoin Core Teams.
Im Buch Bitcoin Begreifen nachschauen, um den Fingerprint zu prüfen.
Den Fingerprint mit einem Freund zu verifizieren.

Fang damit an, dass du den Bitcoin Core Team public Key Fingerprint auf deren Webseite suchst. Du findest den folgenden Fingerprint auf der Download Seite:

01EA5486DE18A882D4C2684590C8019E36C2E964

Jetzt schau in das Buch Bitcoin Begreifen, um zu prüfen, dass der Fingerprint im Buch zu dem auf https://bitcoincore.org passt. Schau in Abschnitt 8.7.1 von Kapitel 8. Dort steht

01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964

Das ist derselbe Fingerprint (wenn auch etwas anders formatiert). Das Buch und die Webseite https://bitcoincore.org behaupten beide, dass dieser Key zum Bitcoin Core Team gehört. Verlassen wir uns aber nicht darauf. Du rufst ausserdem einen Freund an und lässt dir den Fingerprint vorlesen:

Du: “Hallo, Donna! Wie lautet der Fingerprint des aktuellen Bitcoin Core Signatur Keys?”

Donna: “Hi! Ich habe den selbst erst vor ein paar Monaten verifiziert und ich weiss, dass der Fingerprint 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964. ist”

Du: “Danke, das stimmt mit meinem überein. Tschüss!”

Donna: “Bitteschön. Tschüss!”

Donnas Aussage verstärkt dein Vertrauen in diesen Key. Jetzt glaubst du, genügend Beweise dafür zu haben, dass dies in der Tat der korrekte Key ist.

Fangen wir damit an, den Key herunterzuladen. Um dies zu tun, kannst du ein Tool namens gpg benutzen, was für GnuPG steht, was wiederum eine Abkürzung für Gnu Privacy Guard ist. Dieses Programm entspricht einem Standard namens OpenPGP (Pretty Good Privacy). Dieser Standard spezifiziert, wie Keys ausgetauscht werden können, und wie Verschlüsselung und digitale Signaturen in kompatibler Weise zu erledigen sind.

GnuPG ist auf den meisten Linux Computern per Default installiert. Um einen public Key mit einem bestimmten Fingerprint zu laden, gibst du das folgende gpg Kommando ein:

$ gpg --recv-keys 01EA5486DE18A882D4C2684590C8019E36C2E964
gpg: key 90C8019E36C2E964: public key "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

Je nachdem, welche Version von gpg du benutzt, kann der Output variieren. Dieses Kommando lädt den public Key von einem verfügbaren Key Server und verifiziert, dass der geladene public Key tatsächlich den Fingerprint besitzt, den du angefordert hast. Der Besitzer des Keys ist “Wladimir J. van der Laan (Bitcoin Core binary release signing key).”

Der vorangegangene Befehl lädt den Key in gpg und fügt ihn deiner Liste bekannter Keys hinzu. Aber im Output des Befehls steht “no ultimately trusted keys found,” also “keine ultimativ vertrauenswürdigen Keys gefunden.” Dies bedeutet, dass dieser Key nicht von irgendeinem Key, dem du vertraust, signiert worden ist. Du hast den Key nur importiert. In gpg können Keys andere Keys signieren, um deren Legitimität zu bezeugen.

Signiere den public Key auf deinem Computer als vertrauenswürdig

Du hast verifiziert, dass der Key zum Bitcoin Core Team gehört und ihn mittels gpg auf deinem System installiert.

Du wirst jetzt diesen Key mit einem private Key signieren, der dir gehört. Das tust du, um dir zu merken, dass du diesem Key vertraust. Das Bitcoin Core Team wird wahrscheinlich künftig weitere Versionen von Bitcoin Core freigeben. Wenn GnuPG sich diesen public Key als vertrauenswürdig merkt, musst du nicht mehr durch all diese Key-Verifikations-Schritte gehen, wenn du einen Upgrade installierst.

Der Prozess ist wie folgt:

Erzeuge deinen eigenen Key.
Signiere den Bitcoin Core public Key mit deinem eigenen private Key.

GnuPG lässt dich mit folgendem Befehl einen eigenen Key erzeugen:

$ gpg --gen-key
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Hinweis: Gib "gpg --full-generate-key" ein und du bekommst einen vollständigen Key-Erzeugungs-Dialog.

GnuPG muss eine Benutzer ID konstruieren, um deinen Key zu identifizieren.

GnuPG fragt nach deinem Namen und deiner Mailadresse. Beantworte diese Fragen, denn sie dienen zur Identifizierung deines Keys:

Real name: Kalle Rosenbaum
Email address: kalle@example.com
You selected this USER-ID:
    "Kalle Rosenbaum <kalle@example.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit?

Mach weiter, indem du O drückst (den Grossbuchstaben “oh”). Dann musst du dir ein Passwort ausdenken, mit dem der private Key verschlüsselt wird. Such das Passwort aus, und sorge dafür, dass du es nicht vergisst oder verlierst.

Die Key Erzeugung kann eine Weile dauern, weil es etwas Zeit braucht, für den Key gute Zufallszahlen zu erzeugen. Wenn es fertig ist, solltest du einen Output wie diesen sehen:

public and secret key created and signed.

pub   rsa2048 2018-04-27 [SC] [expires: 2020-04-26]
      B8C0D19BB7E17E5CEC6D69D487C0AC3FEDA7E796
      B8C0D19BB7E17E5CEC6D69D487C0AC3FEDA7E796
uid                      Kalle Rosenbaum <kalle@example.com>
sub   rsa2048 2018-04-27 [E] [expires: 2020-04-26]

Jetzt hast du einen eigenen Key, mit dem du Keys signieren kannst, denen du vertraust. Signieren wir den Bitcoin Core Team Key:

$ gpg --sign-key 01EA5486DE18A882D4C2684590C8019E36C2E964

pub  rsa4096/90C8019E36C2E964
     created: 2015-06-24  expires: 2019-02-14  usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>


pub  rsa4096/90C8019E36C2E964
     created: 2015-06-24  expires: 2019-02-14  usage: SC
     trust: unknown       validity: unknown
 Primary key fingerprint: 01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964

     Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>

This key is due to expire on 2019-02-14.
Are you sure that you want to sign this key with your
key "Kalle Rosenbaum <kalle@example.com>" (8DC7D3846BA6AB5E)

Really sign? (y/N)

Gib y ein. Dann wirst du nach dem Passwort des private Keys gefragt. Gib es ein und drücke Enter. Der Bitcoin Core Key sollte jetzt von gpg als vertrauenswürdig eingestuft worden sein. Das vereinfacht den Ablauf, wenn du künftig einen Upgrade der Node Software einspielen willst.

Schauen wir uns den neu signierten Key einmal an:

$ gpg --list-keys 01EA5486DE18A882D4C2684590C8019E36C2E964
pub   rsa4096 2015-06-24 [SC] [expires: 2019-02-14]
      01EA5486DE18A882D4C2684590C8019E36C2E964
uid           [  full  ] Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>

Das Wort, das wir suchen, ist full in eckigen Klammern. Das bedeutet, dass gpg und du, ihr beide dem Key vollständig vertraut.

Verifizieren der Signatur

Es ist Zeit, die Signatur der SHA256SUMS.asc Datei zu verifizieren:

$ gpg --verify SHA256SUMS.asc
gpg: Signature made Wed 03 Oct 2018 10:53:25 AM CEST
gpg:                using RSA key 90C8019E36C2E964
gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" [full]

Da steht, dass die Signatur Good ist und mit einem Schlüssel signiert ist, dem du voll und ganz vertraust, [full].

Zusammenfassend hast du Folgendes getan:

Bitcoin Core und die Signaturdatei heruntergeladen
Überprüft, ob der Hash der Datei .tar.gz mit dem in SHA256SUMS.asc angegebenen Hash übereinstimmt
Einen public Key heruntergeladen und überprüft, ob er zu Bitcoin Core gehört
Den Key mit deinem eigenen private Key signiert, damit GnuPG und du sich merken, dass der Bitcoin Core Key legitim ist
Die Signatur der Datei SHA256SUMS.asc verifiziert

Wenn du das Programm später upgraden willst, kannst du mehrere dieser Schritte überspringen. Der Prozess beschränkt sich dann auf diese Schritte

Bitcoin Core und die Signaturdatei herunterladen.
Prüfen, dass der Hash der .tar.gz Datei mit dem Hash in SHA256SUMS.ac übereinstimmt.
Die Signatur der SHA256SUMS.asc Datei überprüfen.

8.8.3. Auspacken und starten

Packen wir die Software aus:

tar -zxvf bitcoin-0.17.0-x86_64-linux-gnu.tar.gz

Das erzeugt ein Verzeichnis namens bitcoin-0.17.0. Gehe in das Verzeichnis bitcoin-0.17.0/bin und schau dich um:

$ cd bitcoin-0.17.0/bin
$ ls
bitcoin-cli  bitcoind  bitcoin-qt  bitcoin-tx  test_bitcoin

Hier hast du mehrere ausführbare Programme:

bitcoin-cli ist ein Programm, mit dem sowohl man Informationen über den Node, der auf dem Computer läuft, herauskriegen kann, als auch das eingebaute Wallet verwalten kann, das bei Bitcoin Core mitgeliefert wird.
Das Programm bitcoind benutzt man, wenn man den Node im Hintergrund ohne grafische Benutzerschnittstelle (GUI) laufen lassen will.
Das Programm bitcoin-qt benutzt man, wenn man ein GUI für den Node braucht. Das ist nützlich, wenn man das eingebaute Wallet benutzt.
Das Programm bitcoin-tx ist ein kleines Hilfsprogramm zum Erzeugen und Modifizieren von Bitcoin Transaktionen.
Und es gibt noch test_bitcoin, was eine Test-Suite für Bitcoin ist.

In diesem Tutorial benutzen wir bitcoind, was für “Bitcoin daemon” steht. In UNIX Systemen wie Linux bezeichnet das Wort daemon Computerprogramme, die im Hintergrund laufen.

Starten wir den Bitcoin Core Daemon im Hintergrund und schauen, was passiert:

$ ./bitcoind -daemon
Bitcoin server starting

Das startet den Node. Er wird automatisch anfangen, sich mit Peers zu verbinden und die Blockchain für dich herunterzuladen.

8.8.4. Initial Blockchain Download

Dieser Prozess braucht Zeit. In Abhängigkeit von deiner Internetverbindung, Prozessor und Massenspeicher kann es von mehreren Tagen bis hinab zu wenigen Stunden dauern.

Du kannst das bitcoin-cli Programm benutzen, um den laufenden Node bezüglich des Download Prozesses abzufragen, wie hier:

$ ./bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 207546,
  "headers": 549398,
  "bestblockhash": "00000000000003a6a5f2f360f02a3b8e4c214d27bd8e079a70f5fb630a0817c5",
  "difficulty": 3304356.392990344,
  "mediantime": 1352672365,
  "verificationprogress": 0.0249296506976196,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000000000202ad90c17ec6ea33c",
  "size_on_disk": 11945130882,
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": false
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "defined",
      "startTime": 1462060800,
      "timeout": 1493596800,
      "since": 0
    },
    "segwit": {
      "status": "defined",
      "startTime": 1479168000,
      "timeout": 1510704000,
      "since": 0
    }
  },
  "warnings": ""
}

Das Kommando zeigt eine Menge Information über die Blockchain an. Merke, dass die Blocks bis zu einer Blockhöhe von 207546 heruntergeladen und verifiziert worden sind. Bitcoin Core wird vor dem Laden der vollen Blocks immer erst die Block Header herunterladen, um den Proof of Work zu verifizieren. Dieser Node hat Header bis 549398 heruntergeladen, was alle derzeit verfügbaren Header sind. Eine weitere interessante Sache ist das initialblockdownload Feld, das bis zum Ende des Initial Block Download auf true bleibt.

Lasse diesen Daemon weiterlaufen. Wir kommen in Anhang A darauf zurück, wo ich ein kleines Tutorial darüber gebe, wie man bitcoin-cli zum Untersuchen der Blockchain verwendet und wie man das eingebaute Wallet benutzt.

Wenn du den Node stoppen willst, setze folgendes Komando ab:

$ ./bitcoin-cli stop

Du kannst den Node wieder starten, wann immer es dir beliebt, und der Node macht dort weiter, wo er vorher aufgehört hatte.

8.9. Zusammenfassung

Wir haben den letzten zentralen Punkt der Autorität, den Shared Folder, durch ein Peer-to-Peer Netzwerk ersetzt. In einem Peer-to-Peer Netzwerk kommunizieren die Full Nodes direkt miteinander. Jeder Node ist mit mehreren (möglicherweise hunderten) anderen Nodes verbunden. Dies macht es extrem schwierig, Blocks und Transaktionen an der Verbreitung durch das Netzwerk zu hindern.

Dieses Kapitel hatte zwei Hauptteile:

Wie Transaktionen und Blocks durch das Netzwerk fliessen
Wie neue Nodes dem Netzwerk beitreten

8.9.1. Part 1–Verfolgen einer Transaktion

Im ersten Teil des Kapitels sind wir einer Transaktion durch das System gefolgt. Es begann mit John, der einen Keks kaufen wollte. Seine Transaktion wurde über das Peer-to-Peer Netzwerk verbreitet und kam am Wallet des Cafés an.

Das Café sieht zwar fast sofort, dass eine Transaktion auf dem Weg ist, aber diese ist noch nicht bestätigt. Die nächste Stufe ist, den Block zu minen. Rashid ist der glückliche Miner, der den nächsten Block findet, in dem Johns Transaktion enthalten ist.

Rashid schickt den Block an seine Peers, die sie an deren Peers relayen und so weiter, bis der Block das gesamte Netzwerk erreicht hat. Teil dieser Verbreitung beinhaltet das Senden der Transaktion an Lightweight Wallets. Diese Lightweight Wallets fordern merkleblock Messages vom Full Node an, damit sie nicht den ganzen Block herunterladen müssen.

8.9.2. Teil 2–Beitritt zum Netzwerk

Der Start eines Nodes involviert vier Schritte:

Laden und Verifizieren einer Full Node Software, zum Beispiel Bitcoin Core. Anschliessender Start dieser Software.
Verbindung zu anderen Nodes.
Download historischer Blocks
Übergang in den Regelbetrieb.

8.9.3. Systemänderungen

Die Tabelle der Konzept-Mappings zwischen dem Cookie Token System und Bitcoin ist winzig geworden (Tabelle 2).

Tabelle 2. Der Shared Folder ist zugunsten des Peer-to-Peer Netzwerks verworfen worden.
Cookie Tokens	Bitcoin	Behandelt in
1 Cookie Token	1 bitcoin	[ch02]

Angesichts fehlender technischer Unterschiede zwischen dem Cookie Token System und dem Bitcoin System lassen wir das Cookie Token System jetzt fallen und arbeiten ab sofort nur noch mit Bitcoin.

Dieses wird das Finale Release des Cookie Token Systems sein. Ein anderes, viel weiter verbreitetes System, nämlich Bitcoin, hat die Welt im Sturm erobert und wir haben uns entschieden, das Cookie Token Projekt einzustampfen. Viel Spass mit der letzten Version (Tabelle 3).

Tabelle 3. Release Notes, Cookie Tokens 8.0
Version	Feature	Wie
8.0	Zensurresistent; diesmal wirklich	Shared Folder durch Peer-to-Peer Netzwerk ersetzt
8.0	Transaktions Broadcasting	Transaktionen werden an Miner und andere Netzwerkteilnehmer über das Peer-to-Peer Netzwerk versendet
7.0	Zensurresistent	Multiple Miner, “Lisas,” ermöglicht durch Proof of Work
7.0	Jeder darf beim Mining mitmachen	Automatische Difficulty Anpassungen
6.0	Hindert Lisa am Löschen von Transaktionen	Signierte Blöcke in einer Blockchain
	Voll validierende Nodes	Lädt und verifiziert die gesamte Blockchain
	Lightweight Wallet spart Daten	Bloom Filter und Merkle Proofs

8.10. Übungen

8.10.1. Wärm dich auf

Warum ist der Shared Folder keine gute Idee?
Was bedeutet es, einen Block zu relayen?
Wozu werden inv Messages verwendet?
Wie entscheidet der Full Node, welche Transaktionen er an Lightweight Wallets schicken soll?
Wie benachrichtigt ein Node ein Lightweight Wallet über eine eingehende, noch offene Transaktion?
Blocks werden nicht komplett an Lightweight Wallets geschickt. Welcher Teil des Blocks wird aber immer an das Wallet geschickt?
Warum schickt das Café einen sehr grossen Bloom Filter an seinen Trusted Node?
Was würde eine sicherheitsbewusste Person nach dem Herunterladen und vor dem Starten von Bitcoin Core tun?
Welche Arten von Quellen für Peer Adressen stehen einem frisch gestarteten Node zur Verfügung?
Woher weiss ein Full Node, ob neu erzeugte Blocks zum Download bereitstehen, wenn er mit der Synchronisation fertig ist?
Das Bitcoin Peer-to-Peer Netzwerk besteht aus den folgenden Nodes:

Welche Node Besitzer musst du bedrohen, um Lisa daran zu hindern, irgendwelche Blocks zu bekommen, ausser denjenigen, die sie selbst erzeugt hat?

8.10.2. Grabe tiefer

Angenommen, Qi hat gerade zwei Transaktionen mit den Transaktions IDs TXID₁ und TXID₂ erhalten. Sie möchte jetzt Rashid über diese neuen Transaktionen informieren. Sie weiss nicht, on Rashid bereits von den Transaktionen weiss. Was tut sie?

Angenommen, du betreibst einen Full Node, und für 18 Minuten fällt der Strom aus. Wenn der Stromausfall vorbei ist, startest du deinen Node wieder. Während dieser 18 Minuten sind zwei Blocks, B₁ und B₂, erzeugt worden. Dein letzter Block ist B₀. Was tut dein Node nach erneuter Verbindung zum Netzwerk? Der Einfachheit halber nehmen wir an, dass keine neuen Blocks während der Synchronisation gefunden werden, und dass du nur einen Peer hast. Benutze diese Tabelle der Message Typen, um das folgende Formular auszufüllen:

Typ Daten Zweck

Typ	Daten	Zweck
`block`	Voller Block	Schickt einen Block an einen Peer
`getheaders`	Block ID	Fordert darauffolgende Block Header nach der gegebenen Block ID von einem Peer an
`getdata`	txids oder Block IDs	Fordert Daten von einem Peer an
`headers`	Liste von Headern	Schickt eine Liste von Headern an einen Peer

block

Voller Block

Schickt einen Block an einen Peer

getheaders

Block ID

Fordert darauffolgende Block Header nach der gegebenen Block ID von einem Peer an

getdata

txids oder Block IDs

Fordert Daten von einem Peer an

headers

Liste von Headern

Schickt eine Liste von Headern an einen Peer

8.11. Zusammenfassung

Das Peer-to-Peer Netzwerk macht Blocks zensurresistent.
Ein Node verbindet sich mit mehreren Peers, um deren Anfälligkeit für das Verbergen von Information zu verringern.
Das Bitcoin Netzwerkprotokoll ist die “Sprache”, in der sich Nodes miteinander unterhalten.
Transaktionen werden auf dem Bitcoin Peer-to-Peer Netzwerk per Broadcast verbreitet, um sowohl Miner als auch die Empfänger von Zahlungen schnell zu erreichen.
Neue Nodes synchronisieren sich mit dem Bitcoin Netzwerk, um mit den anderen Nodes auf die gleiche Ebene zu kommen. Dies dauert Stunden bis Tage.
Nodes brauchen nicht 24/7 online zu bleiben. Sie können ausfallen und wieder hochkommen und sich wieder auf den neuesten Stand synchronisieren.
Signaturverifikation kann für ältere Blocks zur Beschleunigung der initialen Synchronisation übersprungen werden. Das ist nützlich, wenn man definitiv weiss, dass ein bestimmter Block gültig ist.