Öffentlich zugänglicher Leitfaden zur Entwicklungsphilosophie von Bitcoin von Kalle Rosenbaum und Mitautorin Linnéa Rosenbaum. Er hilft Lesern mit technischen Grundkenntnissen, die Gründe für Entwurfsentscheidungen und deren Grenzen zu untersuchen.
Hauptautor von Bitcoin Development Philosophy ist Kalle Rosenbaum, Mitautorin ist Linnéa Rosenbaum. Chaincode Labs gab das Buch in Auftrag und finanzierte es. Die Einleitung stellt es als Leitfaden zu Entwurfsabwägungen und Erfahrungen aus der Bitcoin-Entwicklung vor, nicht als verbindliche Vorschrift darüber, wer über das Protokoll entscheiden soll. [2]
Das Buch setzt ein grundlegendes Verständnis von Proof of Work, dem Erstellen von Blöcken und dem Lebenszyklus einer Transaktion voraus. Die Kapitel verbinden eigene Erläuterungen mit Verweisen auf Artikel und Vorträge; das Repository enthält außerdem eine getrennte Sammlung übernommener Texte mit Herkunftsangaben. Ziel ist es, Vorschläge im Zusammenhang beurteilen zu lernen, statt lediglich Befehle zu lernen. [2]
Das Inhaltsverzeichnis umfasst 9 Hauptkapitel: Dezentralisierung, Trustlessness, Privatsphäre, begrenztes Angebot, Aktualisierungen, Adversarial thinking, offener Quellcode, Skalierung und Umgang mit Vorfällen. Es folgen Diskussionsfragen sowie Hinweise für Rückmeldungen und das Erstellen des Buches aus den Quelldateien. Von diesem Gesamtwerk haben wir die beiden nachfolgend besprochenen Kapitel ausführlich gelesen; die übrigen beschreiben wir hier anhand der Struktur. [1]
Das Kapitel Trustlessness unterscheidet ein Protokoll, das ohne Vertrauen in einen Vermittler auskommt, vom Vertrauen in die verwendete Software und Hardware. Ein eigener Full Node prüft empfangene Blöcke nach seinen Regeln, etwa die Ausgabe von Coins und das Ausbleiben doppelter Ausgaben innerhalb der Kette. Er garantiert jedoch nicht, dass Teile der Kette nicht umgeschrieben werden; deshalb trennt das Kapitel die Regelvalidierung vom Reorganisationsrisiko und der Bedeutung von Bestätigungen. [3]
Ein weiterer Teil von Trustlessness behandelt reproduzierbare Builds und die Herkunft der zu ihrer Erstellung verwendeten Werkzeuge. Übereinstimmende Ausgabedateien mehrerer unabhängiger Ersteller helfen bei der Prüfung der Distribution, beweisen aber für sich genommen weder die Korrektheit des Quellcodes noch die des gesamten Compilers und der Hardware. Leser sollen erkennen, welchen Teil einer Abhängigkeit sie tatsächlich überprüft haben; die beschriebenen Verfahren haben wir hier nicht ausgeführt. [3]
Adversarial thinking beginnt mit Sicherheitsannahmen und unterscheidet das Funktionieren in der Praxis von einem formalen Sicherheitsbeweis für das gesamte System. Es geht nicht nur um Programmfehler: Das Kapitel weist auf die Isolation eines Knotens vom ehrlichen Netzwerk und auf die Störung offener Zusammenarbeit hin. Es soll zum Suchen nach Fehlermöglichkeiten und Angreifermotiven anregen, statt eine bequeme Erzählung als Sicherheitsanalyse auszugeben. [4]
Das Kapitel zitiert Voskuils Widerstandsaxiom als Annahme, dass ein System staatlicher Kontrolle widerstehen kann. Das Zitat selbst stellt dies ausdrücklich nicht als bewiesene Tatsache dar. Deshalb unterscheiden wir in diesem Überblick die Argumentation des Autors und die zugrunde liegende Annahme von einer Garantie, dass eine konkrete Umsetzung jedem Gegner widersteht. [4]
Wir haben die gesamte Einleitung About this book und die vollständigen Quelltexte der Kapitel Trustlessness und Adversarial thinking im offiziellen Repository gelesen, einschließlich ihrer Schlussfolgerungen und eingebetteten Zitate. Wir haben sämtliche vier Illustrationen dieser beiden Kapitel betrachtet. Die übrigen Kapitel und alle verlinkten Artikel haben wir nicht vollständig gelesen; die verlinkten Vorträge haben wir nicht angesehen. Wir haben weder einen reproduzierbaren Build noch einen Betriebstest oder ein Sicherheitsaudit durchgeführt. [2] [3] [4]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin Core, Konsensregeln, Soft Fork, Full Node.
01Ersetzt das Buch eine Protokollspezifikation oder einen praktischen Programmierkurs?+
Es konzentriert sich auf Gründe, Abwägungen und Annahmen der Entwicklung. Es setzt technische Grundkenntnisse voraus und verweist auf weiteres Material. Dieser Überblick bestätigt es weder als vollständige Spezifikation noch als praktischen Kurs, dessen Übungen wir durchgeführt hätten.
02Bedeutet Trustlessness, dass ich überhaupt nichts mehr vertrauen muss?+
So stellt es das gelesene Kapitel nicht dar. Es unterscheidet die Regelüberprüfung durch den eigenen Knoten vom Vertrauen in Software und Hardware sowie vom Risiko einer Umschreibung der Kette. Wichtig ist zu wissen, was eine konkrete Prüfung tatsächlich garantiert und was eine Annahme bleibt.