Nodesignal-Spezial - E300 - 18 Jahre Bitcoin Whitepaper

0:22 Herzlich willkommen zu Nodesignal 300. Wir haben es geschafft. Wir haben die magische 300 erreicht. Ja, wir sind die, was auch immer. Hi, Zetti. Hallo, herzlichen Glückwunsch, lieber Thorsten. Du als Founder. Du hast das Ding ja mit dir hingebracht. 300. Junge, das ist eine Zahl. Wir sind alle Sparta, sage ich dazu nur.

0:50 Ja. Die 300. Folge nach bald fünf Jahren, meine Güte. Das ist echt viel, finde ich. Aber gut, wir halten uns ja eigentlich nicht so sehr mit so kleinen Zahlen auf. Wir brauchen eigentlich größere Zahlen, mindestens sechsstellig. Bald werden sie siebenstellig. Zetti, was ist mit der Blockzeit? Wie ist es höher als 300?

1:13 Ich habe 973532 und als Hash habe ich hinten die 6A7AE5. Yes, die habe ich auch. Foundry. Foundry, was auch sonst. Ja, 300. Folge, passend zum oder kurz Ende Oktober. Da gibt es in der Bitcoin-Welt was zu feiern. Und zwar den White Paper Day. Am 31., beziehungsweise ich glaube sogar tatsächlich in den USA war das, nee, Nevermind, vergiss es.

1:51 Ich glaube, bei uns war es der Bei uns war es der erste und in den USA ist es der 31. Also kommt immer so ein bisschen drauf an, wann man das als Veröffentlichungsdatum halt nimmt. Und was spannend ist tatsächlich, es sind 18 Jahre her, dass das White Paper veröffentlicht wurde. Das war ja 2008 und quasi das White Paper ist volljährig, zumindest nach deutschem oder noch europäischem Gesetz.

2:14 In den USA dauert es noch drei Jahre, aber nach unseren Rechnungen ist das White Paper jetzt volljährig. Erwachsenenstrafrecht, Schnaps, Autofahren ohne Eltern. Da ist jetzt einiges möglich. Zumindest in Deutschland. Schnaps gibt es in den USA nicht. Autofahren gibt es, glaube ich, in den USA auch nicht.

2:33 Wobei, die können ja, glaube ich, noch früher Autofahren, oder? Ich weiß das gar nicht. Naja, anyway. Auf jeden Fall, das White Paper ist volljährig. Herzlichen Glückwunsch von unserer Stelle. Happy Birthday. Ja. Und deswegen haben wir uns heute mal überlegt, wir nehmen das mal zum Anlass, darüber zu reden.

2:49 Das Wildpaper steht bei mir auch hier, ich glaube, wie das irgendwie bei vielen Bitcoinern ist, irgendwie so eingerahmt oder in irgendeiner Leinwand oder sonst irgendwie sowas, dass das hier irgendwie so steht. Aber ich glaube, was da wirklich so alles so genau drin steht, also inhaltlich, hat man vielleicht ein, zweimal, wenn überhaupt, ganz am Anfang gemacht und dann hat man da, glaube ich, schon lange nicht mehr drauf geguckt.

3:10 Ja, es ist irgendwie ganz vage in meinem Kopf, der Text. Also hin und wieder habe ich nochmal reingeguckt, aber so umfassend beschäftigt habe ich mich damit, glaube ich, so in meiner Anfangszeit. Ich kann mich gar nicht genau erinnern. Wie, wo? Hat das schon mal jemand zum Thema gemacht ausführlich? Auf jeden Fall.

3:25 Können wir gleich nochmal kurz darauf eingehen. Aber wir hatten ja auch so ein bisschen oder zumindest heute habe ich wieder diesen passenden Pulli an, wo auch das Bitcoin White Paper nämlich auch drauf abgebildet ist. Wir hatten in der Live-Folge, die wir bei dir gemacht haben, da hat ja Jan-Paul mit seinem Take, das quasi Running in Node is not optional, ja auch sich quasi immer irgendwie aufs White Paper bezogen an der Stelle.

3:44 Also da hatten wir ja auch schon mal so ein bisschen so darüber gesprochen, wo er so... sag ich mal, die Grundidee oder ist ja auch als Manifest teilweise eher auch genannt wird, dass da ja so die Grundregeln von Bitcoin definiert sind, was ja teilweise auch dann bei, wie die Grundfunktionalität funktioniert, die ja auch tatsächlich der Fall ist.

4:03 Aber ich glaube, darüber hinaus wurden natürlich viele in das Paper natürlich auch quasi Dinge, die halt ergänzt wurden danach. Also dann gerade dann jetzt auch, was Satoshi dann irgendwie in irgendwelchen Bitcoin-Talk-Foren oder sowas da noch von sich gegeben hat. Das ergänzt ja häufig so ein bisschen so das White Paper selber.

4:19 Sind das dann irgendwie diese drei PDF-Seiten oder wie viel auch, kommt aber drauf an, was für ein Format man halt hat. Aber anyway. Ich finde die, um den Schwenk vielleicht noch zu machen, ich finde diese Parallelen zur Theologie dann natürlich super spannend. Einerseits haben wir natürlich am 31. den Weltspartag.

4:34 Andererseits aber ja auch das Anschlagen der Thesen Luthers. Und damit ja quasi Sola Scriptura, dem Protestantismus, der da sich ausbreitet. Also die, ja sozusagen die Schrift und ja allein Gottes. Gnade sozusagen als Garant für den Eintritt in das Himmelreich. Und das ist ja super parallel zu betrachten, wenn wir uns heute darüber unterhalten, was für ein Stellenwert das Bitcoin-White-Paper oder auch die Worte Satoshis für uns haben.

5:03 Also da gibt es ja Leute, die das dann sehr wörtlich auslegen und sagen, ja damals stand schon ein White-Paper oder Satoshi hat gesagt. Und dann gibt es natürlich das andere Extrem, das sagt, man muss das, so wie es moderne Theologen auch machen, man muss es in die heutige Zeit übersetzen. Was bedeuten Satoshis Worte oder das White Paper selber eigentlich in der heutigen Zeit, also diese Umsetzung.

5:24 Und inzwischen diesen Polen, also diesen extremen Polen, findet dann so die Debatte statt. Das kann man ganz gut parallel sehen. Nein, klar, das White Paper war natürlich jetzt zu dem damaligen Zeitpunkt vor der eigentlichen Implementierung ja eine... quasi ein theoretisches Konzept, weil es zu dem Zeitpunkt, wo es veröffentlicht wurde, noch nicht implementiert war.

5:45 Das war ja dann erst ein oder zwei Monate später, wo dann ja dann prinzipiell das Bitcoin-Netzwerk ja dann auch erst am 3. Januar dann da seinen ersten Block gefunden hat und damit ja auch wirklich erst gestartet ist. Und diese Momentaufnahme, die dieses White Paper in dem Sinne ja halt ist, ist ja dann auch der Stand von damals.

6:01 Und jetzt ist natürlich auch durch ganz viele Soft Forks und so weiter und so fort viel dazugekommen. Aber wie ich gerade eben schon gesagt habe, es ist... Trotzdem von seiner Grund- und Funktionalität. Wir haben einen Block, dann haben wir einen anderen Block und der ist mit einem Hash mit dem vorigen Block verknüpft und man hat so prinzipiell dann die bekannte Blockchain, die daraus dann irgendwann oder Tamechain, die daraus entstanden ist.

6:22 Also das ist ja weiterhin immer noch genauso, wie es damals aufgeschrieben wurde. Ja, du hattest gerade aber eben noch angeführt. dass eigentlich in der Vergangenheit schon einige Leute schon sehr, sehr viel über das White Paper gesprochen haben. Da erinnere ich mich jetzt wieder an Chris mit seiner Bitcoin-Bibliothek, der da zum einen die Lesung gemacht hat, glaube ich, also er hat einfach das White Paper vorgelesen, glaube ich, in seiner Übersetzung.

6:49 Und er hat eine Doppelfolge damals mit dem Volker gemacht, wo er das inhaltlich quasi seziert hat, würde ich es jetzt mal nennen. Ich erinnere mich, das war gut. generell die Bitcoin-Bibliothek. Das waren schöne Zeiten. Das war so die Honeymoon-Phase von mir mit Bitcoin. Da war sie immer ein treuer Begleiter.

7:10 Nicht nur einfach wegen der Texte und der Besprechung, sondern natürlich auch die lustige Side-Story rund um die Bibliothek, die der Chris da aufgebaut hat. Mit den Charakteren, die man lieb gewonnen hat. Das ist richtig. Ich weiß gar nicht, wie häufig wir Chris jetzt irgendwie in den letzten zwei Jahren gefühlt oder wie lange die Bibliothek jetzt schon nicht mehr online ist, gesagt haben, Chris.

7:30 Mach doch mal was. Und dann so mal, ja, in vier Wochen, in zwei Wochen, demnächst. Ja, erinnere mich dir auch nochmal dran, dann können wir das auf jeden Fall machen. Chris, ich habe dich dreimal erinnert. Ja, okay, demnächst. Irgendwann hatte man ja selber auch ein schlechtes Gewissen, ihn immer so unter Druck zu setzen.

7:49 Dann haben die Hörer das auch übernommen. Ich wollte gerade sagen, ja. Also irgendwie, glaube ich, in den letzten zwei, drei Zitadellen waren immer wieder Leute, wo ich es mitbekommen habe. Ja, Chris, was ist denn jetzt? Das hat scheinbar auch nicht gereicht. Naja, es ist eigentlich ein Juwel, was wiedergeboren werden sollte oder was eigentlich da sein.

8:10 Also was trotzdem irgendwo zur Geschichte von Bitcoin, zumindest aus der deutschen Bitcoin-Geschichte, so ein bisschen aus meiner Perspektive dazugehört, weil er ja schon so seine Story da drin hatte. Ja, stell dir vor, du machst Hopp auf und kannst einfach auf Bitcoin-Bibliothek klicken. Wie schön wäre das?

8:27 Weißt du was? Ich mache das jetzt einfach mal. Die Hoffnung stirbt ja zuletzt, dass wir das hier einfach mal suchen. Vielleicht hat Chris ja was gemacht, ohne uns Bescheid zu sagen. Wer weiß. Das kann ja durchaus sein. Bitcoin Bibliothek suchen. Oha. Was habe ich denn hier? Hier ist so etwas, das sieht aus wie das gleiche Logo wie das, was Chris damals verwendet hat.

8:56 Da ist eine Folge drin. Klick mal drauf. Okay, mal gucken. Da steht Folge 1. Die Bitcoin-Bibliothek. Nein. Wow. Wie lange habe ich dieses Intro nicht mehr gehört? Gänsehaut. Ist so, ist so. Ja. Ja, okay. Hier steht erste Folge und auch passend dazu die White Paper Lesung. Also wenn das wirklich jetzt hier wahr ist, dann können wir eigentlich Feierabend machen, oder?

9:33 Arbeitslos jetzt, ja. Also ganz ehrlich, es macht keinen Sinn. Es macht einfach keinen Sinn, über das Bitcoin-Wide-Paper zu sprechen oder zumindest diese Idee irgendwie da. Klar, könnten wir darüber reden. Aber ich finde, an das Niveau, was Chris gemacht hat, kommen wir einfach nicht dran. Und das müssen wir uns eingestehen, dass wir da nicht dran kommen.

9:54 Und wo eine Folge 1 ist, wird ja sicherlich auch eine Folge 2 kommen, oder? Das wäre die Hoffnung. Wir können ja Chris ja mal fragen. Mein Vorschlag ist, wir machen jetzt hier Schluss und wir schicken euch jetzt einfach in die erste Folge von der Bitcoin-Bibliothek, die offensichtlich ja wieder erreichbar ist.

10:11 Das wäre mein Vorschlag, Zetti, was sagst du? Klingt gut. Ich höre das Intro gleich nochmal. Brauchst du witzig nochmal Gänsehaut erzeugen? Ja. Sehr gut. Ja, dann haben wir jetzt einfach mal auf und sagen viel Spaß bei der Lesung von der Bitcoin-Bibliothek, die offensichtlich ja wieder da ist. In dem Sinne viel Spaß damit und Fokus on the Signal.

10:32 Na dann da nice. Ciao, ciao. Ciao. Die Bitcoin-Bibliothek. Der Bitcoin-Lesepodcast. Nein, hallo, bitte nicht mit dem Kuchen in den Lesesaal. Oh nein, Kinder. Kinder, der Bitcoin-Standard ist kein Malbuch. Bitte einfach wieder ins Regal stellen. Genau da, unter A, neben Antonopoulos. Um Satoshis Willen, der Hund markiert hier sein Revier.

11:32 Hallo, ist das Ihr Hund? Was für ein Stress. Oh, da seid ihr ja schon. Hallo und willkommen in der Bitcoin-Bibliothek. Ihr merkt, heute ist ganz schön was los. Vielleicht zu viel. Wartet mal, wir gehen mal nach nebenan. Es ist ein besonderer Sonntag. Heute wird das White Paper von Satoshi gelesen. White Paper.

12:07 Die unscheinbare PDF-Publikation eines anonymen Mitglieds in einer Kryptografie-Mailing-Liste. Die neun Seiten, aufgebaut wie eine wissenschaftliche Publikation, mit der 2008 alles begann. Sozusagen die Geburtsstunde von Bitcoin. Deshalb hatte das Bibliotheksteam die Idee, heute einen Event zu machen.

12:32 Mit Kaffee, selbstgemachtem Kuchen und Kinderprogramm. Der Kuchen ist ja lecker. Aber das hier ist immer noch eine Bibliothek mit gut sortiertem Bestand und kein Freizeitpark. Aber auf mich hat mal wieder keiner gehört. Vielleicht habt ihr es schon gemerkt. Es ist eine Doppelfolge. Warum? Nun, das White Paper von Satoshi mag für Bitcoin-Einsteiger zunächst etwas technisch und abstrakt erscheinen.

13:03 Für viele Bitcoin-Padawanschüler und Meister jedoch ist es ein Kunstwerk. Jeder Sats ergibt Sinn. Es ist ein essentieller Teil des sonderbaren Puzzles von Bitcoin. Satoshi hat mit der Idee, welche im White Paper steckt, ohne es großartig zu erwähnen, nebenbei ein essentielles Problem von verteilten Systemen in der Informatik gelöst.

13:28 Ihr erfahrt hierzu noch mehr. Es gibt daher heute parallel zwei Veranstaltungen. Im Lesesaal 4a könnt ihr euch die Lesung des White Papers anhören. Im Lesesaal 4b gibt es eine Erläuterung des White Papers mit einem Special Guest. Die Novizen mögen vielleicht im Plenarsaal 4b starten, mit der Erläuterung.

13:52 Die Fortgeschrittenen können sich direkt in den Lesesaal 4a begeben. Bitte die Laserschwerter am Eingang abgeben. Ich zeige euch kurz, wo ihr hin müsst. Ihr fragt euch, wie ich in beiden Sälen gleichzeitig sein kann. Das geht. Kein Problem. 4a. 4b. Ich bin zwar ein einfacher Bibliothekar, aber auch ich habe ein paar Geheimnisse.

14:40 Noch eine kurze Anmerkung. Es gibt aktuell zwei weiter verbreitete deutsche Übersetzungen des White Papers im Netz. Die eine findet man auf bitcoin.org. Sie ist von 99bitcoins übersetzt. Herzlichen Dank für die Übersetzung. Die andere findet man auf bitcoin.de. Für mich war diese Übersetzung besser lesbar.

15:02 Ich empfand jedoch einzelne Begriffe der anderen Version zutreffender ins Deutsche überführt. So wurde hier der Begriff Cash nicht mit dem Wort Zahlungssystem, sondern nach meinem Verständnis richtiger mit Bargeld übersetzt. Nun aber ab in den Text. Eine reine Peer-to-Peer-Version von elektronischem Bargeld würde es ermöglichen, Online-Zahlungen direkt von einer Partei an eine andere zu senden, ohne ein Finanzinstitut bemühen zu müssen.

15:55 Digitale Signaturen bilden einen Teil der Lösung, aber die Hauptvorteile gehen verloren, wenn weiterhin eine vertrauenswürdige dritte Partei notwendig ist, um Double Spending, Mehrfachausgaben zu verhindern. Wir schlagen eine Lösung für das Double Spending Problem vor, indem wir ein Peer-to-Peer-Netzwerk benutzen.

16:14 Das Netzwerk gibt Transaktionen einen Zeitstempel, indem es sie in eine fortlaufende Kette von Hash-basierten Arbeitsbeweisen, Proof-of-Work, hasht und so eine Aufzeichnung erzeugt, die nicht geändert werden kann, ohne den Proof-of-Work neu zu erzeugen. Die längste Kette dient nicht nur als Nachweis für die Sequenz bezeugter Ereignisse, sondern auch als Beweis, dass sie vom größten Pool an CPU-Leistung stammt.

16:42 Solange der Großteil der CPU-Leistung von Nodes kontrolliert wird, die nicht kooperieren, um das Netzwerk anzugreifen, werden diese die längste Kette generieren und schneller sein als die Angreifer. Das Netzwerk selbst erfordert nur eine Minimalstruktur. Nachrichten werden auf Best-Effort-Basis übertragen und die Nodees können das Netzwerk beliebig verlassen und wieder betreten, da sie die längste Proof-of-Work-Kette als Beweis darüber akzeptieren, was geschah, während sie weg waren.

17:12 1. Einführung Es hat sich ergeben, dass der Handel im Internet inzwischen fast vollständig darauf beruht, dass Finanzinstitute als zu vertrauende dritte Parteien dienen, um elektronische Zahlungen zu verarbeiten. Während dieses System für die meisten Transaktionen ausreichend gut funktioniert, leidet es nach wie vor unter den Schwächen eines Modells, das auf Vertrauen beruht.

17:40 Vollständig unumkehrbare Transaktionen sind nicht wirklich möglich, da Finanzinstitute es nicht vermeiden können, in Streitfällen zu vermitteln. Die Kosten der Vermittlung erhöhen die Kosten der Transaktion, was die Mindestgröße für machbare Transaktionen erhöht und die Möglichkeit kleiner Gelegenheitstransaktionen eliminiert.

18:00 Ein größerer Schaden entsteht darüber hinaus durch den Wegfall der Möglichkeit, irreversible Zahlungen für irreversible Dienstleistungen zu tätigen. Durch die Option, Transaktionen rückgängig zu machen, erhöht sich das notwendige Vertrauen. Händler müssen ihren Kunden gegenüber misstrauisch sein und von ihnen mehr Informationen verlangen, als ansonsten notwendig wären.

18:23 Ein bestimmtes Maß an Betrug wird als unvermeidbar akzeptiert. Diese Kosten und Zahlungsunsicherheiten können durch persönlichen Kontakt und die Verwendung einer physischen Währung vermieden werden, doch es existiert kein Mechanismus für die Leistung von Zahlungen über einen Kommunikationskanal ohne eine vertrauenswürdige Partei.

18:44 Nodewendig ist ein elektronisches Zahlsystem, das auf kryptografischen Nachweisen anstelle von Vertrauen basiert und es zwei bereitwilligen Parteien ermöglicht, Transaktionen direkt untereinander durchzuführen, ohne dass eine vertrauenswürdige dritte Partei benötigt wird. Transaktionen, bei denen es rechnerisch unmöglich ist, sie zu widerrufen, würden die Verkäufer vor Betrug schützen und standardisierte Treuhandmechanismen könnten auf einfache Weise implementiert werden, um die Käufer zu schützen.

19:15 In diesem Paper schlagen wir eine Lösung für das Double-Spending-Problem vor, die unter Verwendung eines verteilten Peer-to-Peer-Zeitstempel-Servers einen rechnerischen Nachweis der chronologischen Reihenfolge der Transaktionen erzeugt. Das System ist sicher, solange die ehrlichen Nodes mehr CPU-Leistung kontrollieren als jede kooperierende Gruppe von angreifenden Nodes.

19:40 2. Transaktionen Wir definieren eine elektronische Münze, Coin, als eine Kette digitaler Signaturen. Jeder Eigentümer überträgt den Coin auf den nächsten, indem er einen Hash der vorherigen Transaktion sowie den öffentlichen Schlüssel des nächsten Eigentümers digital signiert und dies an das Ende des Coins anhängt.

20:04 Der Empfänger der Zahlung kann die Signaturen verifizieren, um die Kette der Eigentümer zu verifizieren. Die Bildung zeigt das Prinzip der Transaktion. Das Problem ist natürlich, dass der Zahlungsempfänger nicht verifizieren kann, dass einer der Eigentümer den Coin nicht doppelt ausgegeben hat. Eine gebräuchliche Lösung ist, eine zentrale, vertrauenswürdige Instanz oder Münzanstalt einzuführen, die jede Transaktion auf Double Spending Mehrfachausgabe prüft.

20:36 Nach jeder Transaktion muss der Coin an die Münzanstalt zurückgegeben werden, damit diese einen neuen Coin herausgibt und nur bei Coins, die direkt von der Münzanstalt ausgegeben wurden, kann darauf vertraut werden, dass sie nicht doppelt ausgegeben worden sind. Das Problem mit dieser Lösung ist, dass das Schicksal des gesamten Geldsystems von dem Unternehmen abhängt, das die Münzanstalt betreibt und dass jede Transaktion über dieses laufen muss, wie bei einer Bank.

21:05 Wir brauchen eine Methode, um Gewissheit für den Zahlungsempfänger zu schaffen, dass die vorherigen Eigentümer keine früheren Transaktionen signiert haben. Für unsere Zwecke ist die erste Transaktion diejenige, die zählt, sodass wir uns keine Sorgen über spätere Versuche bei Mehrfachausgaben machen müssen.

21:26 Die einzige Möglichkeit, die Abwesenheit einer Transaktion zu bestätigen, ist es, alle Transaktionen zu kennen. Um dies ohne vertrauenswürdige Partei zu erreichen, müssen Transaktionen öffentlich gemacht werden. Und wir benötigen ein System, mit dem sich die Teilnehmer auf einen einzigen Verlauf der Reihenfolge, in der sie eingetroffen sind, einigen.

22:00 Der Zahlungsempfänger benötigt einen Nachweis, dass sich zum Zeitpunkt jeder Transaktion die Mehrheit der Knoten des Netzwerks einig sind, dass sie diese zuerst empfangen haben. 3. Zeitstempelserver Die von uns vorgeschlagene Lösung beginnt mit einem Zeitstempelserver. Ein Zeitstempel-Server funktioniert, indem er den Hash eines Blocks von mit Zeitstempel zu versehenden Datensätzen nimmt und den Hash weitläufig, etwa in einer Zeitung oder einem Usenet-Post, veröffentlicht.

22:38 Der Zeitstempel beweist, dass die Daten zu diesem Zeitpunkt existiert haben. Offensichtlich, denn sonst gäbe es keinen Hash von ihnen. Jeder Zeitstempel beinhaltet seinen Hash, den vorhergegangenen Zeitstempel und bildet eine Kette, bei der jeder zusätzliche Zeitstempel den vorherigen verstärkt. Die Abbildung zeigt den Hash-basierten Zeitstempel-Server.

23:03 Viertens. Proof-of-Work. Um einen verteilten Zeitstempel-Server auf Peer-to-Peer-Basis zu implementieren, müssen wir ein Proof-of-Work-System, ähnlich des Hash-Cache-Systems von Adam Beck, anstatt der Zeitungen oder Usenet-Posts verwenden. Der Proof-of-Work beinhaltet die Suche nach einem Wert, bei dem, wenn er gehashed wird, etwa durch SHA-256, der Hash mit einer Anzahl von 0-Bits beginnt.

23:32 Die durchschnittlich erforderliche Arbeit ist exponentiell zu der Anzahl der erforderlichen 0-Bits und kann durch die Ausführung eines einzelnen Hashes verifiziert werden. Für unser Zeitstempel-Netzwerk implementieren wir den Proof-of-Work, indem eine Nonce im Block so lange ansteigt, bis ein Wert gefunden wird, der dem Hash des Blocks die erforderlichen Nullbits gibt.

23:57 Nachdem die CPU genügend Arbeit aufgewendet hat, um den Proof-of-Work zu erfüllen, kann der Block nicht mehr geändert werden, ohne dass die Arbeit erneut ausgeführt werden muss. Da spätere Blocks damit verkettet werden, würde die Arbeit zur Änderung des Blocks die Neuerstellung aller nachfolgenden Blocks beinhalten.

24:16 Die Abbildung zeigt das Zeitstempel-Netzwerk mit implementiertem Proof-of-Work. Der Proof-of-Work löst außerdem das Problem, bei Mehrheitsentscheidungen die Repräsentanten zu bestimmen. Wenn die Mehrheit auf einer Stimme je IP-Adresse basieren würde, könnte diese durch jeden unterwandert werden, der in der Lage ist, viele IPs zu reservieren.

24:39 Proof-of-Work ist im Grunde eine Stimme pro CPU. Die Mehrheitsentscheidung wird durch die längste Kette repräsentiert, in die der größte Proof-of-Work-Aufwand investiert wurde. Wenn eine Mehrheit der CPU-Leistung von ehrlichen Knoten kontrolliert wird, wird die ehrliche Kette am schnellsten wachsen und alle konkurrierenden Ketten abhängen.

25:02 Um einen vergangenen Block zu ändern, müsste ein Angreifer den Proof-of-Work des Blocks sowie den aller nachfolgenden Blocks neu erzeugen und dann die ehrlichen Nodes einholen und überholen. Wir werden später demonstrieren, dass die Möglichkeit, dass ein langsamerer Angreifer aufholt, sich exponentiell verringert, je mehr nachfolgende Blöcke hinzugefügt werden.

25:26 Um steigende Hardwareleistung und zeitlich schwankendes Interesse, einen arbeitenden Knoten zu betreiben, auszugleichen, wird die Proof-of-Work-Schwierigkeit durch einen gleitenden Mittelwert bestimmt, der eine durchschnittliche Anzahl von Blocks pro Stunde anpeilt. Wenn sie zu schnell generiert werden, steigt die Schwierigkeit.

25:47 5. Netzwerk Die Schritte zum Betrieb des Netzwerks sind die folgenden. 1. Neue Transaktionen werden an alle Knoten ausgestrahlt. 2. Jeder Knoten sammelt die neuen Transaktionen in einem Block. 3. Jeder Knoten arbeitet daran, einen schwierigen Proof-of-Work für seinen Block zu finden. 4. Wenn ein Knoten einen Proof-of-Work findet, strahlt er den Block an alle Knoten aus.

26:21 5. Die Knoten akzeptieren den Block nur, wenn alle Transaktionen darin gültig und nicht bereits ausgegeben sind. 6. Die Knoten drücken ihre Akzeptanz des Blocks aus, indem sie daran arbeiten, den nächsten Block in der Kette zu erzeugen, wofür sie die Hash des akzeptierten Blocks als vorhergegangene Hash verwenden.

26:44 Knoten gehen immer davon aus, dass die längste Kette die korrekte ist und arbeiten daran, diese zu verlängern. Wenn zwei Knoten gleichzeitig verschiedene Versionen des nächsten Blocks übertragen, könnten einige Knoten die eine oder andere Version zuerst empfangen. In diesem Fall arbeiten Sie an der ersten, die Sie empfangen haben, speichern aber den anderen Zweig für den Fall, dass dieser länger wird.

27:09 Der Gleichstand wird gebrochen, wenn der nächste Proof-of-Work gefunden wird und ein Zweig länger wird. Die Nodes, die am anderen Zweig gearbeitet haben, werden dann auf den längeren umschalten. Die Ausstrahlung neuer Transaktionen muss nicht zwingend jeden Knoten erreichen. Solange Sie viele Knoten erreichen, werden Sie früher oder später in einem Block aufgenommen.

27:33 Blockausstrahlungen sind auch tolerant gegenüber verlorenen Nachrichten. Wenn ein Knoten einen Block nicht empfängt, wird er diesen anfordern, sobald er den nächsten Block empfängt und erkennt, dass ihm dieser fehlt. 6. Anreize Durch Konvention ist die erste Transaktion in einem Block eine spezielle Transaktion, die einen neuen Coin schöpft, der dem Erzeuger des Blocks gehört.

28:01 Dies gibt neuen Knoten einen Anreiz, das Netzwerk zu unterstützen und bietet einen Weg, Münzen erstmals in Umlauf zu bringen, da es keine zentrale Instanz gibt, die sie herausgibt. Das ständige Hinzufügen einer konstanten Anzahl neuer Coins ist analog zu Goldgräbern, die Ressourcen aufwenden, um mehr Gold in Umlauf zu bringen.

28:23 In unserem Falle sind es CPU-Zeit und Elektrizität, die aufgewendet werden. Die Anreize können auch durch Transaktionsgebühren gefördert werden. Wenn der Ausgangswert der Transaktion geringer ist als ihr Eingangswert, entspricht der Unterschied einer Transaktionsgebühr, die dem Wert des Anreizes des Blocks hinzugefügt wird, der die Transaktion enthält.

28:48 Wenn einmal eine vorherbestimmte Anzahl von Coins in Umlauf gebracht wurde, können die Anreize vollständig auf Transaktionsgebühren übergehen und so vollständig inflationsfrei sein. Die Anreize können helfen, Knoten zu motivieren, ehrlich zu bleiben. Wenn ein gieriger Angreifer in der Lage ist, mehr CPU-Leistung aufzubringen als alle ehrlichen Nodes, müsste er wählen, ob er diese Leistung verwendet, um Menschen zu betrügen, indem er seine Zahlungen zurückstiehlt oder ob er sie nutzt, um neue Coins zu erzeugen.

29:22 Er sollte es profitabler finden, sich an die Regeln zu halten. Regeln, die ihn mit mehr neuen Coins versorgen können als alle anderen zusammen. Als dass er das System und damit die Gültigkeit seines eigenen Wohlstands untergräbt. 7. Speicherplatz zurückgewinnen Sobald die letzte Transaktion eines Coins unter ausreichend Blöcken begraben ist, können die verbrauchten Transaktionen davor gelöscht werden, um Speicherplatz zu sparen.

29:55 Um dies zu ermöglichen, ohne den Hash des Blocks zu brechen, werden die Transaktionen in einem Merkle-Tree gehashed und lediglich die Root in die Hash des Blocks aufgenommen. Alte Blöcke können damit komprimiert werden, indem Zweige des Baums gekappt werden. Die internen Hashes müssen nicht gespeichert werden.

30:16 Die Abbildung zeigt die Speicherplatz-Zurückgewinnung. Ein Blockheader ohne Transaktionen benötigt etwa 80 Byte. Wenn wir davon ausgehen, dass Blöcke alle 10 Minuten generiert werden, entsprechen 80 Byte mal 6 mal 24 mal 365 gleich 4,2 Megabyte pro Jahr. Mit Computersystemen, die im Jahr Stand 2008 typischerweise mit 2 GB RAM verkauft werden und Moore's Law, das aktuell ein Wachstum von 1,2 GB prognostiziert, sollte Speicherplatz kein Problem darstellen, selbst wenn die Blockheader im Speicher gehalten werden müssen.

30:59 8. Vereinfachte Zahlungsverifizierung Es ist möglich, Zahlungen zu verifizieren, ohne einen kompletten Netzwerk-Node zu betreiben. Ein Nutzer muss lediglich eine Kopie der Blockheader der längsten Proof-of-Work-Kette aufbewahren, die er erhalten kann, indem er andere Netzwerkknoten so lange abfragt, bis er überzeugt ist, dass er die längste Kette hat, und den Merkel-Zweig beziehen, der die Transaktion mit dem Block verknüpft, durch den sie einen Zeitstempel erhalten hat.

31:30 Er kann die Transaktion nicht selbst prüfen, aber indem er sie mit einer Stelle in der Kette verknüpft, kann er sehen, dass sie von einem Netzwerk Node akzeptiert wurde und Blöcke, die danach angefügt wurden, bestätigen weiter, dass sie vom Netzwerk akzeptiert wurde. Die Abbildung zeigt vereinfachte Zahlungsverifizierung.

31:53 Als solche ist die Verifizierung zuverlässig, solange das Netzwerk von ehrlichen Nodes kontrolliert wird. Sie wird aber angreifbarer, wenn das Netzwerk von einem Angreifer überwältigt wird. Während Netzwerkknotentransaktionen selbst verifizieren können, kann die vereinfachte Methode so lange durch einen Angreifer mit fungierten Transaktionen getäuscht werden, wie der Angreifer das Netzwerk dominieren kann.

32:19 Eine Strategie, sich dagegen zu schützen, wäre es, Alarmsignale von Netzwerk-Nodes zu akzeptieren, wenn diese einen ungültigen Block erkennen, was die Software des Users veranlassen würde, den vollen Block und die vom Alarm betroffenen Transaktionen herunterzuladen, um die Inkonsistenz zu bestätigen.

32:39 Unternehmen, die regelmäßige Zahlungen erhalten, werden dennoch ihre eigenen Nodes betreiben wollen, für eine unabhängigere Sicherheit und schnellere Verifizierung. 9. Zusammenführung und Aufteilung von Werten Obgleich es möglich wäre, die Coins einzeln zu handhaben, wäre es unpraktisch, für jeden Cent in einem Transfer eine separate Transaktion durchzuführen.

33:07 Damit Werte aufgeteilt und zusammengeführt werden können, enthalten Transaktionen mehrere Inputs und Outputs. Normalerweise gibt es entweder einen einzelnen Input von einer größeren vorausgegangenen Transaktion oder mehrere Inputs, die kleinere Beträge zusammenfassen und höchstens zwei Ausgänge, einer für die Zahlung und einer für die Rückgabe von Wechselgeld.

33:33 Falls notwendig, zurück an den Absender. Die Abbildung zeigt das Zusammenführen und Aufteilen von Werten. Es sollte erwähnt werden, dass eine Auffächerung, bei der eine Transaktion von mehreren Transaktionen abhängig ist und diese Transaktionen wiederum von vielen anderen abhängen, in diesem Fall kein Problem darstellt.

33:57 Es besteht niemals die Nodewendigkeit, eine vollständige Kopie eines Transaktionsverlaufs abzurufen. Das traditionelle Bankenmodell erreicht ein bestimmtes Datenschutzniveau, indem der Zugriff auf die Information auf die beteiligten Parteien und die vertrauenswürdige dritte Partei begrenzt wird. Die Nodewendigkeit, alle Transaktionen zu veröffentlichen, schließt diese Methode aus, aber der Datenschutz kann dennoch aufrecht erhalten werden, indem der Informationsfluss an einer anderen Stelle unterbrochen wird.

34:36 Indem die öffentlichen Schlüssel anonym bleiben. Die Öffentlichkeit kann sehen, dass jemand einen Betrag an jemand anderen sendet, aber ohne Informationen, die die Transaktionen mit irgendjemandem verknüpfen. Das ist im Level an Informationen ähnlich, das von Aktienbörsen veröffentlicht wird, bei dem die Zeit und die Größe der individuellen Handelsvorgänge, das Tape, veröffentlicht wird, ohne dass dabei gesagt wird, wer die Parteien sind.

35:15 Als zusätzliche Firewall sollte für jede Transaktion ein neues Schlüsselpaar verwendet werden, um zu vermeiden, dass die Schlüssel einem gemeinsamen Eigentümer zugeordnet werden können. Manche Verknüpfungen sind bei Transaktionen mit mehreren Eingängen noch immer unvermeidbar, weil diese notwendigerweise preisgeben, dass ihre Eingänge zum gleichen Eigentümer gehören.

35:39 Das Risiko besteht darin, dass wenn der Eigentümer eines Schlüssels bekannt gegeben wird, die Verknüpfung weitere Transaktionen offenlegen könnte, die zum gleichen Eigentümer gehört haben. 11. Berechnungen Wir ziehen ein Szenario in Betracht, bei dem ein Angreifer versucht, eine alternative Kette schneller zu erzeugen als die ehrliche Kette.

36:04 Selbst wenn dies gelingt, setzt es das System nicht willkürlichen Änderungen aus, wie zum Beispiel die Erzeugung von Wert aus dem Nichts oder das Nehmen von Geld, das dem Angreifer nicht gehört. Die Nodes werden keine ungültige Transaktion als Zahlung akzeptieren und die ehrlichen Nodes werden niemals einen Block akzeptieren, der eine solche enthält.

36:27 Ein Angreifer kann lediglich versuchen, eine seiner eigenen Transaktionen zu verändern, um Geld zurückzubekommen, das er vor kurzem ausgegeben hat. Das Rennen zwischen einer ehrlichen Kette und der Kette eines Angreifers kann als binomischer Random Walk charakterisiert werden. Das Erfolgsereignis ist, dass die ehrliche Kette um einen Block erweitert wird, was deren Vorsprung um plus 1 erhöht, und das Scheitern ist, dass die Kette des Angreifers um einen Block erweitert wird, was den Abstand um minus 1 reduziert.

37:02 Die Wahrscheinlichkeit, dass ein Angreifer aus einem gegebenen Rückstand aufholt, ist analog zum Problem des Ruin des Spielers. Angenommen, ein Spieler mit unbegrenztem Kredit beginnt mit einem Rückstand und spielt potenziell eine unbegrenzte Anzahl von Partien mit dem Ziel, die Gewinnschwelle zu erreichen.

37:22 Wir können die Wahrscheinlichkeit, dass er jemals die Gewinnschwelle erreicht oder dass ein Angreifer jemals eine ehrliche Kette einholt, wie folgt berechnen. Die Bildung zeigt die Formel zur Berechnung der Wahrscheinlichkeit, dass der Angreifer jemals den Rückstand von Z-Blöcken aufholt. Unter der Annahme, dass p größer q fällt die Wahrscheinlichkeit exponentiell, wenn die Anzahl der Blöcke, die der Angreifer aufholen muss, steigt.

37:52 Wenn die Wahrscheinlichkeit gegen ihn ist und er nicht frühzeitig einen glücklichen Sprung vorwärts macht, werden seine Chancen verschwindend gering, wenn er weiter zurückfällt. Wir erörtern nun, wie lange der Empfänger einer neuen Transaktion warten muss, bis er ausreichend sicher ist, dass der Absender die Transaktion nicht mehr ändern kann.

38:15 Wir nehmen an, dass der Absender ein Angreifer ist, der den Empfänger für eine Weile glauben lassen möchte, dass er bezahlt wurde und dann die Transaktion nach einiger Zeit verändert, sodass sie an ihn selbst zurückgezahlt wird. Der Empfänger wird alarmiert, wenn dies geschieht, aber der Absender hofft, dass es dann zu spät ist.

38:36 Der Empfänger generiert ein neues Schlüsselpaar und gibt dem Public Key kurz vor dem Signieren an den Sender. Dies verhindert, dass der Sender bereits im Voraus eine Kette von Blocks vorbereitet, in dem er so lange daran arbeitet, bis er ausreichend Glück gehabt hat, um einen ausreichend großen Vorsprung zu haben und dann die Transaktion in diesem Moment ausführt.

38:59 Wenn die Transaktion einmal abgeschickt wurde, beginnt der unehrliche Sender insgeheim mit der Arbeit an einer parallelen Kette, die eine geänderte Version seiner Transaktion enthält. Der Empfänger wartet, bis die Transaktion zu einem Block hinzugefügt wurde und Z-Blocks dahinter angehängt wurden. Er weiß nicht genau, welchen Fortschritt der Angreifer bereits gemacht hat, aber davon ausgehend, dass die ehrlichen Blocks die durchschnittliche Zeit pro Block benötigt haben, entspricht der potenzielle Fortschritt des Angreifers einer Poisson-Verteilung mit dem erwarteten Wert Lambda gleich Z mal Q durch P.

39:40 Um die Wahrscheinlichkeit zu berechnen, dass der Angreifer jetzt noch aufholen könnte, multiplizieren wir diese Poisson-Dichte für jede Summe des Fortschritts, den er gemacht haben könnte, mit der Wahrscheinlichkeit, dass er von diesem Punkt an aufholen könnte. Wir stellen die Formel um, um zu vermeiden, dass die unendlichen Nachkommastellen der Verteilung addiert werden.

40:05 Und übersetzen dies in C-Code. Es folgt die Übersetzung in C-Code. Wenn wir einige Ergebnisse durchlaufen lassen, können wir erkennen, wie die Wahrscheinlichkeit exponentiell mit Z abfällt. Zwölftens. Fazit. Wir haben ein System für elektronische Transaktionen vorgeschlagen, ohne uns auf Vertrauen zu stützen.

40:32 Wir sind vom üblichen System von aus digitalen Signaturen erstellten Coins ausgegangen, das eine starke Kontrolle über die Eigentümerschaft bietet, aber unvollständig ist, ohne eine Methode, um Mehrfachausgaben zu verhindern. Um dieses Problem zu lösen, haben wir ein Peer-to-Peer-Netzwerk vorgeschlagen, das Arbeitsbeweise benutzt, um eine öffentliche Historie von Transaktionen aufzuzeichnen, die für einen Angreifer rasch unmöglich veränderbar sind, solange ehrliche Nodes die Mehrheit der CPU-Leistung kontrollieren.

41:07 Das Netzwerk ist in seiner unstrukturierten Einfachheit robust. Die Nodes arbeiten alle zur gleichen Zeit mit nur wenig Koordination. Sie müssen nicht identifiziert werden, da die Nachrichten nicht zu einer bestimmten Stelle geleitet werden und nur auf Basis der besten Bemühungen ausgeliefert werden.

41:26 Knoten können das Netzwerk nach Belieben verlassen bzw. diesem beitreten und den Proof of Work als Nachweis dafür akzeptieren, was während ihrer Abwesenheit geschehen ist. Sie stimmen mit ihrer CPU-Leistung ab, drücken ihre Akzeptanz von zulässigen Blöcken dadurch aus, dass sie an deren Erweiterung arbeiten und weisen ungültige Blöcke dadurch ab, dass sie sich weigern, an diesen zu arbeiten.

41:51 Alle erforderlichen Regeln und Anreize können mithilfe dieses Konsensmechanismus durchgesetzt werden. Referenzen Das war die Lesung des White Papers von Satoshi Nakamoto. In Folge 4b findet ihr eine Erörterung des White Papers mit Volker. Hört mal rein. Wenn euch der Text genauso gefallen hat wie mir, folgt der Bitcoin-Bibliothek gerne auf Twitter unter at btc-bibliothek.

42:28 Hier poste ich Neuigkeiten zu kommenden Lesungen. Wenn ihr der Meinung seid, dieser Bitcoin-Podcast kann anderen Menschen dabei helfen, Bitcoin besser zu verstehen, teilt ihn gerne und hinterlasst mir in der Podcast-App eurer Wahl gerne eine positive Bewertung. Dies erhöht die Sichtbarkeit des Podcasts.

42:46 Bis zur nächsten Woche. Vires in numeris, euer Bibliothekar.