0:00:00.000,0:00:13.890 33C3-Vorspannmusik 0:00:13.890,0:00:20.810 Herald: Gut, dann machen wir[br]weiter mit dem nächsten Vortrag. 0:00:20.810,0:00:24.509 Der ist von vimja, der ist[br]Informatikstudent aus Bern in der Schweiz, 0:00:24.509,0:00:28.740 und er arbeitete bzw. er[br]beschäftigte sich mit Bitcoin 0:00:28.740,0:00:32.890 und Ethereum, und schrieb seine[br]Bachelorarbeit über die Suche 0:00:32.890,0:00:38.210 nach Informationen in der Bitcoin-[br]Blockchain. Und da macht es total Sinn, 0:00:38.210,0:00:43.120 dass der uns jetzt eine Einführung[br]zu Blockchains präsentieren wird. 0:00:43.120,0:00:45.580 Ein großer Applaus für vimja! 0:00:45.580,0:00:50.030 Applaus mit Pfeifen und Jubel[br]Das ist deine Bühne! 0:00:50.030,0:00:56.519 weiterhin Applaus 0:00:56.519,0:00:58.920 vimja: Toll, das ist jetzt[br]gerade kaputtgegangen. 0:00:58.920,0:01:05.460 Gelächter 0:01:05.460,0:01:08.000 So ist es besser. 0:01:08.000,0:01:13.230 Applaus[br]Danke. 0:01:13.230,0:01:19.980 Genau, das geht jetzt[br]natürlich auch nicht. 0:01:19.980,0:01:22.240 Mache ich es halt von Hand. 0:01:22.240,0:01:27.740 Ist vermutlich, weil ihr alle das Wi-Fi[br]braucht, geht das 2,4-GHz-Band nicht mehr. 0:01:27.740,0:01:31.570 Ja das hat er euch ja alles[br]schon gesagt, der Herald. 0:01:31.570,0:01:34.680 In dieser Zeit, in der ich mich[br]mit Blockchains befasst habe, 0:01:34.680,0:01:39.270 durfte ich natürlich sehr viele[br]sehr interessante Dinge lernen, 0:01:39.270,0:01:41.830 und ich möchte jetzt heute abend[br]einen Teil dieses Wissens 0:01:41.830,0:01:48.810 an euch weitergeben. Genau. 0:01:48.810,0:01:52.710 Das Ganze ist natürlich ein sehr komplexes[br]Thema, das viele komplizierte Dinge 0:01:52.710,0:01:56.120 enthält, und deshalb fangen wir jetzt mit[br]etwas sehr einfachem an, was wir alles 0:01:56.120,0:01:59.850 kennen. Und zwar herkömmliche[br]Besitzsysteme – also Systeme, 0:01:59.850,0:02:04.100 die ausdrücken wem etwas gehört. Und,[br]eigentlich, mit der Erkenntnis, dass man 0:02:04.100,0:02:11.190 all diese Besitzsysteme als[br]Zustandsübergangssysteme darstellen kann. 0:02:11.190,0:02:16.019 Das gilt sowohl für Finanzsysteme,[br]die wir haben um Geld zu verwalten, 0:02:16.019,0:02:20.090 als auch etwa für Grundstücke, also[br]Systeme mit denen wir verwalten, 0:02:20.090,0:02:23.490 wem ein Grundstück gehört. 0:02:23.490,0:02:27.520 Das Mapping funktioniert dann in etwa[br]so, dass wir sagen, der Zustand ist 0:02:27.520,0:02:33.510 die Sammlung der Informationen wem[br]was gehört. Und jedes Übertragen 0:02:33.510,0:02:37.720 eines Besitzes ist eine Transition,[br]die zu einem neuen Zustand führt. 0:02:37.720,0:02:41.760 Also am Beispiel eines finanziellen[br]Systems sagen wir, der Zustand ist 0:02:41.760,0:02:45.879 die Sammlung aller Konten, die es gibt.[br]Das drückt für jede Person aus, 0:02:45.879,0:02:51.230 wieviel Geld ihr gehört. Und ein Übergang[br]ist, wenn jemand eine Transaktion macht, 0:02:51.230,0:02:54.160 also Geld überweist, von einem Konto[br]zu einem anderen, dann führt das 0:02:54.160,0:02:58.440 zu einem neuen Zustand.[br]So, das sehen wir hier abgebildet 0:02:58.440,0:03:02.280 mit Grundstücken. Wir sehen hier, der[br]Zustand, der enthält diese Information, 0:03:02.280,0:03:06.760 wem die Grundstücke gehören.[br]Und dann verkauft der Bob 0:03:06.760,0:03:10.890 sein Grundstück Nr. 42 an Alice und[br]das führt zu einem neuen Zustand. 0:03:10.890,0:03:15.660 Ich habe da den Unterschied markiert,[br]damit der eindeutig sichtbar ist. 0:03:15.660,0:03:20.410 Nun, in all diesen Systemen ist es sehr[br]wichtig, dass sich alle Teilnehmer des 0:03:20.410,0:03:26.150 Systems auf einen Zustand einigen können.[br]Dass sie sich einig sind, wem was gehört. 0:03:26.150,0:03:30.050 Denn wenn sie das nicht können, sind[br]Angriffe auf das System möglich, 0:03:30.050,0:03:32.950 insbesondere der sogenannte[br]Double-Spend-Angriff, 0:03:32.950,0:03:37.840 der in der Blockchain-Welt bekannt und[br]gefürchtet ist. Und was bedeutet das? 0:03:37.840,0:03:41.440 Das ist ganz einfach, wenn jemand etwas[br]zweimal ausgibt. Bei Geld ist das ein 0:03:41.440,0:03:45.310 wenig abstrakt (also wie gibt man zweimal[br]dasselbe Geld aus), aber bei Grundstücken 0:03:45.310,0:03:48.990 ist das ganz einfach. Stellen wir uns vor,[br]jemand verkauft dasselbe Grundstück 0:03:48.990,0:03:54.880 zweimal. Das ist natürlich kriminell[br]und darf nicht vorkommen. 0:03:54.880,0:03:57.850 Schauen wir uns jetzt mal an wie[br]das funktioniert. Stellen wir uns vor, 0:03:57.850,0:04:01.940 Malroy hat ein schönes Grundstück,[br]das Grundstück Nr. 5. Und sowohl Alice 0:04:01.940,0:04:05.700 als auch Bob möchten gerne das[br]Grundstück kaufen. Und Malroy 0:04:05.700,0:04:10.020 wird jetzt versuchen, das an beide zu[br]verkaufen. Also trifft er sich mit Alice. 0:04:10.020,0:04:13.761 Das ist also jetzt der aktuelle Zustand.[br]Wir haben gesehen, das Grundstück Nr. 5 0:04:13.761,0:04:20.430 gehört hier dem Malroy. Der trifft sich[br]mit Alice. Und er verkauft es an Alice. 0:04:20.430,0:04:24.550 Er überweist ihr das Grundstück. Wir sehen[br]diese Transition – überweist das Grundstück 0:04:24.550,0:04:29.129 von Malroy an Alice. Und im neuen Zustand[br]gehört es jetzt der Alice. So, der Bob, 0:04:29.129,0:04:31.990 der hat davon nichts mitgekriegt.[br]Irgendwie – Bob und Alice wissen 0:04:31.990,0:04:36.300 immer noch nicht recht wie man sicher[br]miteinander kommuniziert. Und deshalb 0:04:36.300,0:04:39.199 weiß der Bob jetzt nichts davon, dass[br]die Alice das Grundstück gekauft hat. 0:04:39.199,0:04:43.680 Er denkt, das Grundstück gehört immer noch[br]Malroy. Also trifft er sich mit Malroy. 0:04:43.680,0:04:47.939 Und auch er einigt sich mit Malroy auf[br]einen Preis. Und Malroy tut jetzt so, 0:04:47.939,0:04:52.710 als würde er den Besitz des[br]Grundstücks an Bob übertragen. 0:04:52.710,0:04:56.460 Und für Bob sieht die Welt jetzt so[br]aus, d.h. Bob ist überzeugt, das ist 0:04:56.460,0:05:00.339 der korrekte Zustand des Systems.[br]Da haben wir natürlich ein Problem, 0:05:00.339,0:05:03.290 weil Bob und Alice, die sind sich[br]jetzt gar nicht einig darüber, 0:05:03.290,0:05:07.499 wem das Grundstück gehört. Ja, Malroy[br]ist natürlich abgehauen mit dem Geld. 0:05:07.499,0:05:10.980 Und das System ist kaputt, weil Bob[br]und Alice die können nicht mehr 0:05:10.980,0:05:14.690 miteinander handeln. Und auch wenn[br]jetzt jemand anderes das Grundstück 0:05:14.690,0:05:18.749 kaufen möchte: Bei wem kauft er es[br]denn jetzt? Was ist denn rechtmäßig? 0:05:18.749,0:05:23.859 Nun, in der Welt der Grundstücke gibt[br]es dafür eine ganz einfache Lösung, 0:05:23.859,0:05:27.560 nämlich das Grundbuchamt. Und das[br]Grundbuchamt fungiert eigentlich 0:05:27.560,0:05:33.310 als zentrale Referenzstelle,[br]die den Zustand verwaltet, 0:05:33.310,0:05:37.460 und alle Änderungen verwaltet. Jedesmal[br]wenn jemand ein Grundstück verkauft, 0:05:37.460,0:05:42.089 muss das über das Grundbuchamt erledigt[br]werden. Das Grundbuchamt überprüft, 0:05:42.089,0:05:46.020 dass das überhaupt zulässig ist, ob das[br]Grundstück wirklich der Person gehört 0:05:46.020,0:05:50.169 und führt das dann nach. Und so kann das[br]Grundbuchamt diese einfachen Angriffe 0:05:50.169,0:05:58.960 verhindern. Diese Lösung[br]funktioniert auch für Finanzsysteme. 0:05:58.960,0:06:02.770 Also wenn wir an Banken denken, wenn ich[br]ein Konto habe, da ist dann halt die Bank 0:06:02.770,0:06:07.289 die zentrale Autorität, welche den Zustand[br]verwaltet. Für jede… jedesmal, 0:06:07.289,0:06:11.499 wenn ich eine Transaktion mache, also Geld[br]überweise, überprüft die Bank vorher, 0:06:11.499,0:06:15.759 ob ich wirklich das nötige Geld dazu[br]habe. Und dann wird mein Kontostand 0:06:15.759,0:06:22.499 nachgeführt. Und die verwaltet so[br]für alle Teilnehmer den Zustand. 0:06:22.499,0:06:26.919 Und das funktioniert eigentlich erstaunlich[br]gut. Nun wollen wir ein System, mit dem 0:06:26.919,0:06:31.229 wir Zahlungen über das Internet abwickeln[br]können. Und wir hätten gerne, dass das 0:06:31.229,0:06:34.849 dezentral ist. Weil, wenn das nicht[br]dezentral ist, dann kann natürlich 0:06:34.849,0:06:39.909 eine zentrale Autorität das System[br]zensieren und manipulieren. 0:06:39.909,0:06:43.539 Und eine zentrale Stelle kann angegriffen[br]werden. Ich denke, wir haben das alle 0:06:43.539,0:06:47.719 in den letzten Jahren beobachten müssen,[br]wie Paypal sehr einfach willkürlich 0:06:47.719,0:06:52.650 Konten sperrt, und das System zensiert.[br]So, und deshalb brauchen wir ein 0:06:52.650,0:06:56.250 besseres System, eine bessere[br]Lösung für das Internetzeitalter. 0:06:56.250,0:06:59.840 Und diese bessere Lösung ist[br]natürlich die ‚Blockchain‘. 0:06:59.840,0:07:05.760 Die Blockchain bringt einige ganz[br]unglaubliche Eigenschaften mit sich. 0:07:05.760,0:07:09.529 Die Blockchain braucht keine zentrale[br]Stelle um den Zustand zu verwalten. 0:07:09.529,0:07:12.930 Die Teilnehmer des Systems müssen sich[br]gegenseitig nicht vertrauen, sie müssen 0:07:12.930,0:07:16.419 sich gegenseitig nicht kennen. Sie müssen[br]nicht einmal wissen, wieviele Leute 0:07:16.419,0:07:19.990 denn eigentlich da teilnehmen. Und[br]trotzdem können die sich alle immer 0:07:19.990,0:07:25.469 auf einen Zustand des Systems einigen. 0:07:25.469,0:07:27.960 Ich werde das jetzt demonstrieren,[br]die Regeln, die wir brauchen 0:07:27.960,0:07:32.250 um das zu ermöglichen. Anhand[br]einer sehr einfachen Blockchain, 0:07:32.250,0:07:35.759 die in diesem ersten Kapitel auch[br]noch keinen Proof-of-Work hat. Also 0:07:35.759,0:07:39.149 diese erste Blockchain wird noch[br]angreifbar sein. Und ich werde auch 0:07:39.149,0:07:42.970 zeigen wie es geht. Und erst im nächsten[br]Kapitel dann werde ich erklären, 0:07:42.970,0:07:47.820 welche Maßnahmen wir ergreifen[br]müssen, um Angriffe zu verhindern. 0:07:47.820,0:07:51.659 Und das Ganze fängt an mit dem Netzwerk[br]welches wir nutzen. Also wir sagen quasi, 0:07:51.659,0:07:55.039 wir sind alle diese Leute, und wir würden[br]gerne miteinander Transaktionen machen 0:07:55.039,0:07:59.759 können. Und zuerst einigen wir uns[br]alle auf einen Ursprungszustand. 0:07:59.759,0:08:03.319 Damit fangen wir an. Wir sagen z.B.[br]„am Anfang gehört allen nichts“. 0:08:03.319,0:08:08.429 Das ist ein leerer Zustand. Und dann[br]brauchen wir ein p2p-Netzwerk. 0:08:08.429,0:08:13.529 Und jedesmal wenn jemand Geld überweist[br]an jemand anderes, dann veröffentlicht er 0:08:13.529,0:08:17.490 die Transaktion in diesem Netzwerk,[br]und das Netzwerk leitet die Transaktion 0:08:17.490,0:08:21.949 solange an alle Teilnehmer weiter,[br]bis alle Teilnehmer diese Transaktion 0:08:21.949,0:08:27.169 gesehen haben. Das bringt[br]natürlich viele Probleme mit sich. 0:08:27.169,0:08:29.529 Das Netzwerk ist irgendwie nicht[br]synchronisiert, nicht alle Leute 0:08:29.529,0:08:34.510 sehen die gleichen Transaktionen, die[br]Reihenfolge der Transaktionen ist unklar. 0:08:34.510,0:08:37.940 Leute werden versuchen das anzugreifen[br]– das wird dazu führen, dass es 0:08:37.940,0:08:42.458 Transaktionen gibt die nicht miteinander[br]kompatibel sind. Und irgendwie 0:08:42.458,0:08:45.310 Transaktionen, die abhängen von[br]nicht-kompatiblen Transaktionen und 0:08:45.310,0:08:49.790 dann auch wieder nicht kompatibel sind.[br]Das ist ein riesengroßes Durcheinander da. 0:08:49.790,0:08:52.370 Und deshalb brauchen wir jetzt[br]eine Möglichkeit, wie wir uns alle 0:08:52.370,0:08:57.180 auf einen Zustand, auf einen Konsens[br]einigen können. Und – wie gesagt – 0:08:57.180,0:09:00.790 das ist jetzt die ‚Blockchain‘. 0:09:00.790,0:09:04.420 Und wir definieren einige Regeln,[br]die wir anwenden um uns zu einigen. 0:09:04.420,0:09:08.240 Wir sagen, wir gruppieren die Transaktionen[br]die vorher so lose auf dem Netzwerk waren 0:09:08.240,0:09:13.470 zu Blöcken. Die Blöcke hängen alle[br]voneinander ab. Wir sagen dann auch, 0:09:13.470,0:09:17.780 der aktuelle Zustand des Netzwerks ist das[br]Ende der längsten Kette zusammenhängender 0:09:17.780,0:09:22.720 Blöcke. Und die Blöcke müssen einige[br]Kriterien erfüllen. Ich habe das da… 0:09:22.720,0:09:26.940 also das ist jetzt quasi der Ur… der[br]leere Zustand, mit dem wir beginnen. 0:09:26.940,0:09:32.300 Und da kommen da Transaktionen[br]über das Netzwerk. Und irgendwann 0:09:32.300,0:09:34.950 macht jemand einen Block der diese[br]Transaktionen zusammenfasst. Und jetzt 0:09:34.950,0:09:39.810 sehen wir am Ende dieses Blocks ist[br]der Zustand. Wenn ich diesen Zustand 0:09:39.810,0:09:43.110 nachvollziehen will dann nehme ich den[br]leeren Ursprungszustand, und dann 0:09:43.110,0:09:47.080 jede Transaktion aus dem ersten Block,[br]und dann wende ich diese Transaktionen, 0:09:47.080,0:09:52.170 eine nach der anderen, auf den Zustand[br]an, und dann erhalte ich den Endzustand. 0:09:52.170,0:09:55.421 Mit der Zeit kommen[br]neue Transaktionen rein 0:09:55.421,0:10:00.140 über das Netzwerk. Und diese Transaktionen[br]werden nicht Teil des Zustands 0:10:00.140,0:10:02.950 – wir haben ja gesagt der Zustand ist das[br]Ende der längsten Kette von Blöcken, 0:10:02.950,0:10:06.270 und die sind in keinem Block. Erst wenn[br]jemand einen Block daraus macht, 0:10:06.270,0:10:09.890 werden die Teil des Zustands.[br]Wir sehen auch, die Blöcke hängen jeweils 0:10:09.890,0:10:13.540 voneinander ab, die haben so einen Pfeil,[br]der sie miteinander verbindet, also 0:10:13.540,0:10:18.590 jeder Block zeigt auf den vorhergehenden[br]Block, und bildet so eben diese Kette 0:10:18.590,0:10:23.650 von Blöcken. Nun, jetzt versucht trotzdem[br]jemand da eine bösartige Transaktion 0:10:23.650,0:10:27.810 zu machen, die mit den anderen nicht[br]kompatibel ist. Da macht jemand 0:10:27.810,0:10:32.000 einen Block daraus. Und jetzt sagen[br]wir aber einfach, Blöcke, die 0:10:32.000,0:10:35.470 Transaktionen enthalten welche sich[br]widersprechen sind nicht valide. 0:10:35.470,0:10:38.360 Der Block, den kann zwar jemand[br]erstellen, aber wir sagen dann, das ist 0:10:38.360,0:10:42.180 kein valider Block, der wird vom Netzwerk[br]nicht akzeptiert. Und der wird auch 0:10:42.180,0:10:46.450 nicht Teil des Zustands. Also wenn jemand[br]einen Block bauen will und eine dieser 0:10:46.450,0:10:52.610 Transaktionen enthält, dann muss sich[br]derjenige der den Block erstellt 0:10:52.610,0:10:56.090 entscheiden welche der Transaktionen[br]denn jetzt enthalten sein sollen 0:10:56.090,0:11:00.280 in dem Block. Und die anderen lässt er[br]außen vor. Für welche er sich entscheidet, 0:11:00.280,0:11:04.660 das ist dem Typen ganz allein überlassen.[br]Er kann das selber entscheiden was er da 0:11:04.660,0:11:10.690 reinpacken will. Dann kommen mit[br]der Zeit neue Transaktionen rein. 0:11:10.690,0:11:14.300 Und jetzt könnte es sein, dass jemand so[br]einen Block Nummer 4 macht, welcher 0:11:14.300,0:11:18.730 jetzt trotzdem wieder die böse Transaktion[br]enthält. Und dann sagen wir aber einfach, 0:11:18.730,0:11:21.911 Blöcke welche Transaktionen enthalten,[br]welche nicht kompatibel sind 0:11:21.911,0:11:25.450 mit Transaktionen in älteren Blöcken sind[br]auch ungültig, und der Block wird auch 0:11:25.450,0:11:29.870 nicht Teil des Zustands. So. Was aber[br]gültig ist, ist jemand der einen Block 0:11:29.870,0:11:33.880 Nummer 3 macht, der so aussieht. Und jetzt[br]haben wir das Problem: Wir haben gesagt, 0:11:33.880,0:11:36.640 der Zustand ist die längste Kette von[br]Blöcken. Hier ist jetzt der Zustand 0:11:36.640,0:11:40.370 nicht mehr eindeutig definiert und da muss[br]jetzt halt jeder Teilnehmer des Netzwerkes 0:11:40.370,0:11:44.960 selbst entscheiden wie er damit umgeht,[br]was er jetzt als Zustand anerkennt. 0:11:44.960,0:11:48.240 So, aber dann kommen halt neue[br]Transaktionen wieder rein. Und irgendwann 0:11:48.240,0:11:52.590 baut jemand einen Block Nummer 4, der[br]diese Transaktion enthält. Und dadurch, 0:11:52.590,0:11:57.920 dass der Block Nr. 4 auf den vorherigen[br]Block Nr. 3 verweist, ist es jetzt klar, 0:11:57.920,0:12:01.530 von welchem Block der abhängt.[br]Und damit ist die Kette auch wieder klar, 0:12:01.530,0:12:06.300 und die längste Kette wird wieder zum[br]Zustand. So. Jetzt habe ich gesagt, 0:12:06.300,0:12:09.830 diese Blockchain die ich jetzt beschrieben[br]habe hat keinen Proof-of-Work und folglich 0:12:09.830,0:12:14.510 ist sie angreifbar für ein double-spend.[br]Sagen wir Malroy würde gerne 0:12:14.510,0:12:19.050 ein Fahrrad klauen. Er geht da so in den[br]Fahrradladen von Alice, und möchte dort 0:12:19.050,0:12:23.510 gerne ein Fahrrad kaufen, das kostet[br]jetzt 1000 Euro in dem Beispiel. 0:12:23.510,0:12:26.170 Ich werde jetzt… hier habe ich[br]die Darstellung etwas geändert, 0:12:26.170,0:12:30.370 diese Vierecke mit Pfeilen dran, das sind[br]jetzt halt einfach Blöcke. Ich werde 0:12:30.370,0:12:34.570 nicht mehr jede Transaktion einzeln[br]zeichnen. Und die sehen den Zustand, 0:12:34.570,0:12:39.110 wie er da ist. Da sind all die Konten[br]aufgeführt, unter anderem diejenigen 0:12:39.110,0:12:45.070 von Alice und Malroy. So.[br]Malroy geht also in den Laden, 0:12:45.070,0:12:51.340 sucht sich das [Fahrrad] aus, geht zum[br]Tresen und macht dort die Transaktion 0:12:51.340,0:12:56.880 an Alice. Und diese Transaktion wird[br]übers Netzwerk zu Alice weitergeleitet. 0:12:56.880,0:13:00.480 Sie sieht die Transaktion, aber da sie[br]noch nicht Teil eines Blockes ist, 0:13:00.480,0:13:04.260 ist sie auch noch nicht Teil des Zustands.[br]Irgendwann aber erstellt jemand halt 0:13:04.260,0:13:07.880 einen Block der diese Transaktion enthält.[br]Die ist jetzt Teil des Zustandes. 0:13:07.880,0:13:12.760 Wir sehen im Zustand des Systems,[br]dass Alice das Geld erhalten hat. 0:13:12.760,0:13:17.130 Sie gibt das Fahrrad an Malroy, und der[br]fährt davon. Neue Blöcke kommen dazu. 0:13:17.130,0:13:20.860 Und jetzt startet Malroy den Angriff.[br]Und was Malroy macht, er erstellt 0:13:20.860,0:13:25.230 eine alternative Transaktion, die dasselbe[br]Geld überweist, diesmal aber nicht 0:13:25.230,0:13:30.260 an Alice sondern an sich selbst. Genauer:[br]an ein zweites Konto das ebenfalls ihm 0:13:30.260,0:13:36.510 gehört. Und er erstellt einen alternativen[br]Block, der diese Transaktion enthält. 0:13:36.510,0:13:40.830 Und dann erstellt er ganz viele neue[br]Blöcke die davon abhängen. Solange, 0:13:40.830,0:13:44.670 bis seine Kette von Blöcken länger[br]ist als die anderen, also die Kette, 0:13:44.670,0:13:49.570 die zur Zeit auf dem Netzwerk ist. Und[br]dann veröffentlicht er die gesamte Kette 0:13:49.570,0:13:53.540 auf dem Netzwerk. Und jetzt ist seine[br]Kette die längste Kette. Die wird 0:13:53.540,0:13:58.380 vom Netzwerk als Zustand anerkannt. Und[br]in diesem Zustand hat er das Geld erhalten. 0:13:58.380,0:14:02.210 Alice hat das Geld nicht erhalten. Und[br]Malroy hat das Fahrrad erfolgreich 0:14:02.210,0:14:05.720 gestohlen. So, das hat also funktioniert. 0:14:05.720,0:14:09.650 Wir müssen das verhindern. Das[br]Problem weshalb Malroy diesen Angriff 0:14:09.650,0:14:13.780 machen konnte ist natürlich, dass er in[br]einer sehr kurzen Folge viele Blöcke 0:14:13.780,0:14:18.230 erstellen konnte. Also das Problem ist[br]eigentlich, es ist zu einfach neue Blöcke 0:14:18.230,0:14:23.250 zu erstellen. Also machen wir es halt[br]schwieriger, neue Blöcke zu erstellen. 0:14:23.250,0:14:27.030 Und dazu sagen wir, für jeden Block[br]der erstellt wird, muss eine Aufgabe 0:14:27.030,0:14:33.980 gelöst werden, eine Challenge.[br]Und um diese Challenge zu erstellen, 0:14:33.980,0:14:40.120 muss man halt Zeit, und Rechenzeit[br]aufwenden. Die Lösung für diese Aufgabe 0:14:40.120,0:14:45.161 nennen wir den Proof-of-Work. Und den[br]Prozess um den Proof-of-Work zu erstellen 0:14:45.161,0:14:49.560 nennen wir das ‚Mining‘. Und dann sagen[br]wir, zusammen mit jedem neuen Block 0:14:49.560,0:14:53.800 muss der passende Proof-of-Work[br]veröffentlicht werden. Und nur Blöcke, 0:14:53.800,0:14:58.210 welche einen passenden Proof-of-Work haben[br]werden vom Netzwerk als Teil des Zustands 0:14:58.210,0:15:03.300 anerkannt. Jetzt funktioniert das[br]Erstellen neuer Blöcke etwas anders. 0:15:03.300,0:15:06.810 Und zwar ist es jetzt so, dass ein Block[br]nicht mehr einfach entsteht, sondern 0:15:06.810,0:15:10.650 ein ‚Miner‘ muss daran arbeiten. Jeder[br]Miner arbeitet natürlich für sich selbst 0:15:10.650,0:15:14.540 daran, einen neuen Block zu erstellen.[br]Wir sehen hier, der Block an dem der Miner 0:15:14.540,0:15:19.991 arbeitet, ist hier so gestrichelt[br]markiert. Und dann, wenn der Miner 0:15:19.991,0:15:23.920 daran arbeitet, kommen neue Transaktionen[br]rein. Und irgendwann gelingt es dem Miner 0:15:23.920,0:15:27.910 den Block fertigzustellen. In dem Moment[br]veröffentlicht er den Block zusammen mit 0:15:27.910,0:15:31.440 dem Proof-of-Work im Netzwerk. Der wird[br]vom Netzwerk anerkannt, und der Miner 0:15:31.440,0:15:39.740 beginnt sofort an einem neuen Block zu[br]arbeiten, und das geht dann halt so weiter. 0:15:39.740,0:15:43.990 Nun, die Funktion die wir brauchen um das[br]Erstellen der Blöcke schwierig zu machen 0:15:43.990,0:15:49.730 muss einige Bedingungen erfüllen. Sie[br]muss natürlich schwierig sein zu lösen. 0:15:49.730,0:15:53.110 Dann muss aber… obwohl es lange gehen[br]muss die zu erstellen, muss es sehr 0:15:53.110,0:15:56.580 einfach sein, das Ergebnis zu prüfen.[br]Also wenn ich einen Block erhalte, und 0:15:56.580,0:16:00.460 den passenden Proof-of-Work, muss[br]ich – zack! – sofort sagen können, 0:16:00.460,0:16:03.390 der Proof-of-Work ist gültig oder nicht,[br]weil ich will ja entscheiden, ob das 0:16:03.390,0:16:07.500 Teil meines Zustandes[br]sein soll oder nicht. 0:16:07.500,0:16:11.960 Und dann ist es wichtig, dass die[br]Funktion abhängt von genau dem Block, 0:16:11.960,0:16:15.230 für den sie erstellt wird. Also der[br]Proof-of-Work soll nur genau 0:16:15.230,0:16:19.140 für den einen Block gültig sein.[br]Das ist sehr wichtig, denn ansonsten 0:16:19.140,0:16:23.589 könnte Malroy auf Vorrat über[br]mehrere Wochen hinweg einfach 0:16:23.589,0:16:27.220 Proof-of-Works erstellen und dann die[br]einfach an einen Block ranflanschen, 0:16:27.220,0:16:31.810 und so in kurzer Zeit trotzdem wieder[br]eine lange Kette erstellen. Wenn aber 0:16:31.810,0:16:37.150 der Proof-of-Work direkt abhängig ist[br]vom Block für den er erstellt wird, 0:16:37.150,0:16:40.150 dann muss Malroy mit dem Erstellen[br]des Proof-of-Work so lange warten, 0:16:40.150,0:16:44.290 bis der vorhergehende Block bekannt[br]ist und damit auch ihm bekannt ist, 0:16:44.290,0:16:47.360 was er jetzt in den neuen Block packt. 0:16:47.360,0:16:52.010 Und dann soll es auch noch möglich sein,[br]die Schwierigkeit der Aufgabe zu variieren. 0:16:52.010,0:16:56.110 Denn damit das System als stabiles[br]Finanzsystem funktioniert, möchte ich 0:16:56.110,0:16:59.250 gerne wissen, wie lange es geht von[br]dem Moment wo ich eine Transaktion 0:16:59.250,0:17:04.409 veröffentliche bis sie Teil des Zustandes[br]wird. Und wenn das Netzwerk 0:17:04.409,0:17:08.000 sehr viel mehr Rechenkraft hat, dann[br]geht es plötzlich schneller, neue Blöcke 0:17:08.000,0:17:11.179 zu erstellen und dann will ich diese[br]Schwierigkeit anpassen können, damit es 0:17:11.179,0:17:16.660 wieder länger geht. Nun jetzt, wo[br]das Mining nicht mehr einfach ist, 0:17:16.660,0:17:20.169 und es aufwendig ist, müssen wir irgendwie[br]einen Incentive haben, damit die Leute 0:17:20.169,0:17:25.089 es auch tun – also irgendeinen Anstoß.[br]So und wir sagen halt, der Miner, 0:17:25.089,0:17:29.020 dem es gelingt einen Block zu erstellen,[br]der bekommt eine Belohnung, 0:17:29.020,0:17:34.350 den sogenannten ‚Block Reward‘, und wir[br]implementieren das, indem wir sagen, 0:17:34.350,0:17:38.010 der Miner darf für sich selbst eine[br]zusätzliche Transaktion in den Block 0:17:38.010,0:17:41.999 hineinpacken, und mit dieser Transaktion[br]überweist er sich selbst Geld 0:17:41.999,0:17:45.809 aus dem Nichts heraus. Wo das[br]Geld herkommt: Es gibt eigentlich 0:17:45.809,0:17:48.779 zwei Möglichkeiten, die populär sind.[br]Entweder sagen wir, das sind 0:17:48.779,0:17:53.110 die Überweisungsgebühren der anderen[br]Transaktionen in dem Block. 0:17:53.110,0:17:57.540 Oder dann sagen wir halt, das ist Geld,[br]welches neu geschaffen wird. Wir haben ja 0:17:57.540,0:18:02.670 vorhin gesehen, wir haben einen leeren[br]Zustand als den Ursprungszustand definiert, 0:18:02.670,0:18:06.069 und wenn wir das so tun, muss das[br]Geld, welches die Leute ausgeben, 0:18:06.069,0:18:10.250 irgendwo herkommen. Und das ist halt eine[br]Möglichkeit, Geld in das System zu bringen, 0:18:10.250,0:18:14.559 die nicht von einer zentralen Stelle[br]kontrolliert wird, und eigentlich 0:18:14.559,0:18:21.290 eine faire Möglichkeit.[br]Etwas weiteres ist, dass… 0:18:21.290,0:18:25.290 diese zusätzliche Transaktion macht[br]den Block natürlich individuell, denn 0:18:25.290,0:18:29.770 jeder Miner wird das Geld an sich selbst[br]zu überweisen versuchen und, also, 0:18:29.770,0:18:35.130 diese eine Transaktion wird für jeden[br]Miner anders sein. Und das stellt sicher, 0:18:35.130,0:18:39.599 dass die alle an einem ein wenig anderen[br]Problem arbeiten. Wenn die alle 0:18:39.599,0:18:43.659 versuchen würden, das genau selbe Problem[br]zu lösen, auf die genau selbe Art, 0:18:43.659,0:18:47.809 dann würde es immer demjenigen als erstes[br]gelingen, der die meiste Rechenkraft hat, 0:18:47.809,0:18:51.679 und das wollen wir nicht, denn dann würde[br]ja eine Person alle Blöcke erzeugen, 0:18:51.679,0:18:54.570 und wir wollen ja, dass viele Personen[br]Blöcke erzeugen, damit das niemand 0:18:54.570,0:18:59.830 zensieren kann. Dadurch, dass das Problem,[br]an welchem sie arbeiten, für jeden Miner 0:18:59.830,0:19:02.749 etwas anders ist, gelingt es halt[br]zwischendurch auch jemandem 0:19:02.749,0:19:06.879 mit weniger Rechenkraft, als erstes eine[br]Lösung zu finden. Und in der Praxis 0:19:06.879,0:19:12.159 geht das dann ganz gut, dass wir sagen[br]können, wer 20% der Rechenkraft hat 0:19:12.159,0:19:15.559 dem wird es auch in etwa einem Fünftel[br]der Fälle gelingen als erstes einen Block 0:19:15.559,0:19:21.210 zu finden. Dann muss der Miner halt[br]noch entscheiden, an welchem Block 0:19:21.210,0:19:25.399 er arbeiten will. Aber der Miner will ja…[br]also an welchem Ende der Kette… 0:19:25.399,0:19:29.129 Wir haben vorhin gesehen, es kann sein,[br]dass diese Ketten mehrere Enden haben. 0:19:29.129,0:19:33.730 Aber das ist ganz einfach, denn der Miner[br]will ja den Reward kriegen. Der Reward ist 0:19:33.730,0:19:37.719 eine Transaktion, welche nur dann[br]Teil des Zustandes wird wenn es Teil 0:19:37.719,0:19:40.740 in einem Block ist, wenn es Teil der[br]längsten Kette ist. Und der Block ist 0:19:40.740,0:19:44.249 nur dann Teil der längsten Kette wenn[br]er an diesem Ende angesetzt wird. 0:19:44.249,0:19:49.039 Also arbeiten alle Miner am Ende der[br]längsten Kette. So, jetzt habe ich 0:19:49.039,0:19:52.970 versprochen, dass wir so den Double-Spend[br]verhindern können, von vorhin. 0:19:52.970,0:19:57.389 Wollen wir mal gucken, ob das geht![br]Das Szenario ist wieder dasselbe. 0:19:57.389,0:20:03.290 Malroy will das Fahrrad klauen,[br]im Laden von Alice. 0:20:03.290,0:20:08.760 Der Unterschied ist, dass das Netzwerk[br]arbeiten muss um die Blöcke zu erstellen. 0:20:08.760,0:20:13.090 Und dann geht es wieder so vonstatten.[br]Malroy erstellt jetzt zwei Transaktionen. 0:20:13.090,0:20:17.110 Eine, um das Geld der Alice zu überweisen.[br]Diese Transaktion macht er öffentlich 0:20:17.110,0:20:20.550 im Netzwerk, damit die von allen gesehen[br]werden kann. Und eine Transaktion, 0:20:20.550,0:20:25.330 um das Geld an sich selbst zu überweisen.[br]Die behält er vorläufig geheim. Dann wird 0:20:25.330,0:20:29.350 der vorhergehende Block fertiggestellt,[br]und sofort fängt das Netzwerk an 0:20:29.350,0:20:34.220 den nächsten Block zu erstellen. Das[br]Netzwerk enthält in dem Block natürlich 0:20:34.220,0:20:37.750 die Transaktion von Malroy an Alice,[br]denn das ist ja die einzige Transaktion 0:20:37.750,0:20:42.129 die dem Netzwerk bekannt ist. Und[br]Malroy arbeitet jetzt ganz alleine daran, 0:20:42.129,0:20:47.579 den alternativen Block zu erstellen. In[br]dem die andere Transaktion enthalten ist. 0:20:47.579,0:20:51.539 Jetzt ist es aber so: das Netzwerk hat[br]natürlich mehr Rechenkraft als Malroy 0:20:51.539,0:20:56.659 allein. Der hat halt nicht so viele[br]Computer. Und deshalb wird das Netzwerk 0:20:56.659,0:21:01.340 immer schneller sein darin, neue Blöcke[br]zu erstellen als Malroy. Malroys Kette 0:21:01.340,0:21:06.169 wird nie die längste Kette, wird nie Teil[br]des Zustands. Und der Angriff wurde 0:21:06.169,0:21:13.779 erfolgreich abgewehrt. Die einzige Art[br]und Weise wie Malroy gewinnen könnte, 0:21:13.779,0:21:17.639 also wie Malroy den Angriff trotzdem[br]durchführen könnte, wäre, wenn er 0:21:17.639,0:21:21.899 schneller Blöcke erstellen könnte als[br]das Netzwerk. Und das wird ihm aber 0:21:21.899,0:21:25.909 nur dann gelingen, wenn er mehr als[br]50% der Rechenkraft im Netzwerk hätte. 0:21:25.909,0:21:28.679 Denn dann wäre die Wahrscheinlichkeit,[br]dass er einen Block findet, höher 0:21:28.679,0:21:33.469 als bei allen anderen Minern gemeinsam.[br]Und dann könnte er das tun. Und deshalb 0:21:33.469,0:21:40.500 spricht man bei Bitcoin und anderen[br]Kryptowährungen von diesen 50%-Attacken. 0:21:40.500,0:21:43.769 So, jetzt gibt es noch eine andere Art,[br]einen Double-Spend auszuführen. Das ist 0:21:43.769,0:21:49.020 ein etwas schwierigerer Angriff.[br]Und er hat jetzt damit zu tun, wie 0:21:49.020,0:21:53.429 das Peer-to-Peer-Netzwerk funktioniert,[br]das wir brauchen um die Transaktionen 0:21:53.429,0:22:01.279 und Blöcke zu verteilen. Jetzt ist der[br]Angriff ein wenig schwieriger, also 0:22:01.279,0:22:05.330 muss Malroy etwas wertvolleres stehlen.[br]Er geht zu Bob. Bob verkauft Autos. 0:22:05.330,0:22:09.520 Er wird versuchen ein Auto zu stehlen.[br]Und um das zu tun, wird er versuchen 0:22:09.520,0:22:13.210 die Verbindung von Bob mit dem[br]Peer-to-Peer-Netzwerk zu kontrollieren. 0:22:13.210,0:22:17.260 Wir sehen hier, Bob ist mit dem Netzwerk[br]verbunden. Mit diesen drei Peers. Und 0:22:17.260,0:22:21.710 Malroy hat zwei Möglichkeiten: entweder[br]er kontrolliert die Internetverbindung 0:22:21.710,0:22:26.490 von Bob. Oder dann kontrolliert er[br]halt die drei Nodes, mit denen Bob 0:22:26.490,0:22:30.400 verbunden ist. Wie realistisch das ist,[br]das will ich hier nicht diskutieren. 0:22:30.400,0:22:34.820 Grundsätzlich ist es ja schon[br]vorstellbar. Und jetzt hat Malroy 0:22:34.820,0:22:39.190 einige interessante Möglichkeiten. Er kann[br]jetzt nämlich kontrollieren, welche Blöcke 0:22:39.190,0:22:43.330 und Transaktionen der Bob sieht.[br]Also Transaktionen und Blöcke, 0:22:43.330,0:22:47.710 welche auf dem Netzwerk erscheinen,[br]kann Malroy quasi vor Bob geheimhalten. 0:22:47.710,0:22:52.059 Und er kann Bob auch Transaktionen und[br]Blöcke präsentieren, die er dem Rest 0:22:52.059,0:22:57.920 des Netzwerkes nicht präsentiert.[br]So, das ist der Angriff. Wir sehen, 0:22:57.920,0:23:01.880 was das Netzwerk sieht.[br]Links und rechts, was Bob sieht. 0:23:01.880,0:23:06.929 Am Anfang ist das natürlich an beiden[br]Orten gleich. Jetzt geht der Malroy 0:23:06.929,0:23:12.230 zu dem Bob und wird das Auto kaufen.[br]Er macht eine Transaktion. 0:23:12.230,0:23:15.850 Er macht zwei Transaktionen. Eine,[br]um das Geld an Bob zu überweisen. 0:23:15.850,0:23:19.480 Diese schickt er nur an Bob. Und[br]versteckt sie vor dem Netzwerk. 0:23:19.480,0:23:23.960 Und eine zweite Transaktion, mit der er[br]das Geld wieder an sich selbst überweist. 0:23:23.960,0:23:28.480 Diese Transaktion veröffentlicht er im[br]Netzwerk. Jetzt wird das Netzwerk 0:23:28.480,0:23:33.950 daran arbeiten, einen Block zu erstellen,[br]mit der Transaktion von Malroy zu Malroy. 0:23:33.950,0:23:38.990 Weil das Netzwerk kennt keine andere[br]Transaktion. Und Malroy allein arbeitet 0:23:38.990,0:23:44.750 daran einen Block zu erstellen, mit[br]dem er das Geld an Bob überweist. 0:23:44.750,0:23:48.130 Natürlich wiederum, das Netzwerk hat viel[br]mehr Rechenkraft, es ist viel schneller 0:23:48.130,0:23:51.549 darin, neue Blöcke zu erstellen. So, und 0:23:51.549,0:23:56.149 schlussendlich gelingt es dann aber Bob[br][Malroy!] trotzdem, einen Block zu erstellen. 0:23:56.149,0:23:59.690 Und alle diese Blöcke die auf dem Netzwerk[br]erstellt wurden – muss man vielleicht 0:23:59.690,0:24:05.350 noch sagen – die hält der Malroy vor Bob[br]geheim. Also, alle diesen neuen Blöcke, 0:24:05.350,0:24:08.919 die hat Bob nie gesehen. Und deshalb[br]wird Bob diesen einen Block von Malroy 0:24:08.919,0:24:13.269 als die längste Kette von Blöcken[br]akzeptieren. Und jetzt ist die Transaktion 0:24:13.269,0:24:18.469 von Malroy an Bob Teil von Bobs[br]Zustand. Er gibt Malroy das Auto. 0:24:18.469,0:24:25.210 Malroy fährt davon. Er beendet die[br]Attacke. Und jetzt verbindet sich Bob 0:24:25.210,0:24:29.339 wieder ganz normal mit dem Netzwerk.[br]Die beiden Ketten werden synchronisiert. 0:24:29.339,0:24:33.410 Und wir sehen, in der schlussendlich[br]resultierenden Kette hat Bob das Geld 0:24:33.410,0:24:41.690 nicht erhalten. Malroy hat also das[br]Auto erfolgreich stehlen können. 0:24:41.690,0:24:45.690 Das ist gar nicht gut. Jetzt hat ja dieser[br]Angriff funktioniert. Oder hat er das 0:24:45.690,0:24:52.659 denn wirklich? Denn diesmal war der[br]Angriff erfolgreich. Aber Malroy musste 0:24:52.659,0:24:56.519 jetzt dafür arbeiten. Er musste diesen[br]einen Block erstellen. Und das hat ihn 0:24:56.519,0:25:00.400 viel Zeit gekostet. Natürlich kostet[br]es ihn auch irgendwie Rechenkraft, 0:25:00.400,0:25:03.440 und den Strom den er braucht um seinen[br]Computer zu betreiben. Das wollen wir 0:25:03.440,0:25:07.360 jetzt aber gar nicht mit einbeziehen.[br]Sondern wir schauen jetzt nach diesen 0:25:07.360,0:25:11.509 Dings die Zeit gekostet. Denn der Malroy[br]hat ja einen Computer, den er braucht, 0:25:11.509,0:25:15.760 um die Blöcke zu erstellen. Und dieser[br]Computer kann immer nur eines auf’s Mal 0:25:15.760,0:25:20.290 tun. Entweder erstellt er jetzt diesen[br]Fake-Block für Bob, oder er erstellt 0:25:20.290,0:25:25.789 richtige Blöcke auf die richtige Chain.[br]Er kann nicht beides auf’s Mal tun. 0:25:25.789,0:25:31.750 So, und das macht es sehr, sehr[br]teuer diesen Angriff durchzuführen. 0:25:31.750,0:25:35.759 Stellen wir uns vor… das sind jetzt einfach [br]irgendwelche Annahmewerte für unser 0:25:35.759,0:25:39.379 Netzwerk… die sind da halt in jeder[br]Kryptowährung etwas anders definiert. 0:25:39.379,0:25:44.730 Sagen wir, unser Netzwerk erzeugt einen[br]Block alle zehn Minuten. Der Block Reward, 0:25:44.730,0:25:49.700 welchen der Miner kriegt ist 1000 Euro.[br]Und Malroy hätte jetzt 20% der Rechenkraft 0:25:49.700,0:25:54.691 des Netzwerkes. Wenn wir sagen 100% der[br]Rechenkraft erzeugt alle zehn Minuten. 0:25:54.691,0:26:00.309 einen Block, dann erzeugt Malroy auf[br]sich alleine gestellt nur alle 50 Minuten 0:26:00.309,0:26:06.409 einen Block. D.h. der Angriff auf Bob[br]dauert 50 Minuten. Nun, wenn aber Malroy 0:26:06.409,0:26:12.000 50 Minuten lang minen würde, anstatt Bob[br]anzugreifen, dann würde er in dieser Zeit 0:26:12.000,0:26:16.289 durchschnittlich 1000 Euro verdienen.[br]Er kann sich jetzt also entscheiden, 0:26:16.289,0:26:22.590 entweder greift er Bob an und stiehlt das[br]23.000 Euro teure Auto, oder er verdient 0:26:22.590,0:26:26.470 mit fairem Mining 1000 Euro.[br]Natürlich wird er dieses Auto immer noch 0:26:26.470,0:26:31.810 stehlen wollen. Der Mechanismus, um[br]das zu verhindern ist aber ganz einfach. 0:26:31.810,0:26:36.419 Wir sagen jetzt, Bob gibt dem[br]Malroy das Auto nicht, sobald Bob 0:26:36.419,0:26:41.259 das Geld erhalten hat, sondern er[br]wartet dann noch einige Blöcke. 0:26:41.259,0:26:43.849 Das sieht dann in etwa so aus. Ich habe[br]jetzt nicht genügend Blöcke gemalt, 0:26:43.849,0:26:49.279 weil die da nicht Platz hatten.[br]Also sagen wir halt, wir sehen 0:26:49.279,0:26:54.510 auf der rechten Seite, wo die[br]Transaktion Teil des Zustandes wird. 0:26:54.510,0:26:59.609 Und in diesem Moment gibt halt der[br]Bob das Auto noch nicht an Malroy, 0:26:59.609,0:27:05.179 sondern erst einige Blöcke später. Und[br]für jeden zusätzlichen Block, den Malroy 0:27:05.179,0:27:08.039 erstellen muss, um Bob davon zu[br]überzeugen, dass das jetzt wirklich 0:27:08.039,0:27:12.230 die richtige Kette ist, muss Malroy[br]weitere 50 Minuten aufwenden, 0:27:12.230,0:27:17.580 und das kostet ihn jedesmal 1000 Euro.[br]Wenn also Bob sagt: „Ich warte 24 Blöcke 0:27:17.580,0:27:22.530 bevor ich dem Malroy das Auto gebe“. Dann[br]ist der Angriff für Malroy plötzlich teurer 0:27:22.530,0:27:27.360 als das Auto einen Wert hat. Und dadurch[br]kann Bob den Angriff verhindern. 0:27:27.360,0:27:31.179 Malroy kann den zwar immer noch[br]durchführen, aber es ist schlicht einfach 0:27:31.179,0:27:35.069 nicht interessant für Malroy das zu tun,[br]weil er mehr Geld macht wenn er 0:27:35.069,0:27:44.739 in der selben Zeit mint. So. Jetzt haben[br]wir viel gesprochen über generische 0:27:44.739,0:27:48.580 Konzepte von Blockchains. Jetzt will[br]ich noch etwas dazu sagen, wie das 0:27:48.580,0:27:53.820 in Bitcoin implementiert wird. Zumindest[br]einige der Dinge. Schauen wir uns zuerst 0:27:53.820,0:27:58.499 die Blöcke an. Und wir wissen ja, in der[br]Informatik mögen wir es, Bodys und Header 0:27:58.499,0:28:03.340 zu definieren. Das tun wir überall,[br]irgendwie, in unseren Netzwerkprotokollen; 0:28:03.340,0:28:07.799 in Nachrichten und Dateiformaten[br]sagen wir, der Body enthält den Inhalt, 0:28:07.799,0:28:12.049 die eigentlichen Daten. Und der Header[br]enthält die Metadaten. Und genau dasselbe 0:28:12.049,0:28:17.390 tun wir auch in unseren Blockchains. In[br]Bitcoin ist es so, der Body eines Blockes 0:28:17.390,0:28:22.500 enthält alle Transaktionen. Die sind dort[br]geordnet aufgeführt. Der Miner muss 0:28:22.500,0:28:29.130 einige Regeln einhalten, wenn er das[br]macht. Z.B. wenn Transaktion B 0:28:29.130,0:28:32.460 von Transaktion A abhängt, die beide[br]im selben Block sind, müssen die 0:28:32.460,0:28:36.190 in der richtigen Reihenfolge drin sein.[br]Aber sonst kann der die irgendwie 0:28:36.190,0:28:40.350 dort einpacken. Aber sobald er das mal[br]gemacht hat, ist dann… diese Reihenfolge 0:28:40.350,0:28:44.739 ist anschließend wichtig. Und die erste[br]Transaktion im Block ist jeweils 0:28:44.739,0:28:47.750 die coin-based-Transaktion,[br]mit der sich der Miner 0:28:47.750,0:28:53.019 den Block Reward überweist. 0:28:53.019,0:28:59.000 Um jetzt diesen Body zu verbinden mit dem[br]Header nutzt Bitcoin einen Merkle Tree. 0:28:59.000,0:29:02.249 Das ist ein binärer Baum, 0:29:02.249,0:29:08.470 bei dem jeweils… der Node ist der[br]hash der konkatenierten Werte 0:29:08.470,0:29:11.480 der Children des Nodes. 0:29:11.480,0:29:15.049 Und Bitcoin verwendet fast überall…[br]wo Bitcoin Hashes macht, 0:29:15.049,0:29:17.990 wenden sie einen – dhash nennen sie das, 0:29:17.990,0:29:22.979 das ist ein double-sha256-Hash, also[br]so nennt sich der Hash eines Hashes 0:29:22.979,0:29:27.700 eines Wertes, den sie nehmen. Das[br]sieht dann so aus: wir haben unseren Body 0:29:27.700,0:29:31.539 des Blocks. Dann erstellen wir für[br]jede Transaktion den double-hash. 0:29:31.539,0:29:34.710 Und dann beginnen wir damit, den Tree[br]zu erstellen. Also auf jeden Node, 0:29:34.710,0:29:40.629 für jeden blauen Node konkatenieren wir[br]die beiden grünen Nodes, und machen dann 0:29:40.629,0:29:44.410 den Hash davon. Das machen wir für[br]jede Ebene, bis wir schlussendlich 0:29:44.410,0:29:49.850 beim Merkle Root angelangen, und der[br]wird dann Teil des Block Headers. 0:29:49.850,0:29:53.879 Und der Block Header enthält diese Dinge:[br]die Version – das ist irgendwie 0:29:53.879,0:29:58.480 eine arbitrary Nummer, die von den[br]Entwicklern von Zeit zu Zeit geändert wird, 0:29:58.480,0:30:01.809 wenn sie irgendwie finden,[br]dass wird jetzt Zeit dafür. 0:30:01.809,0:30:05.559 Dann den Previous Block Hash. Wir haben[br]gesehen, die Blöcke verweisen jeweils 0:30:05.559,0:30:09.199 auf den vorhergehenden Block. Das ist[br]in Bitcoin so gelöst, dass der Header 0:30:09.199,0:30:13.069 eines Blocks den Hash des vorhergehenden[br]Blocks enthält. Also auch hier wieder 0:30:13.069,0:30:18.730 den double-hash. Den Merkle Root haben[br]wir bereits gesehen. Dann enthält 0:30:18.730,0:30:22.460 der Block-Header noch einen Time Stamp.[br]Das sind ziemlich komplizierte Regeln, 0:30:22.460,0:30:26.780 wonach dieser Time Stamp gebildet[br]wird, aber das ist egal. Das ist 0:30:26.780,0:30:31.850 nicht so wichtig. Die ‚Difficulty‘ ist ein[br]Ausdruck dafür wie schwierig es war 0:30:31.850,0:30:35.989 den Proof-of-Work für diesen bestimmten[br]Block zu definieren. Und die ‚Nonce‘ 0:30:35.989,0:30:43.579 ist ein Wert der gebraucht wird zum Minen. 0:30:43.579,0:30:48.359 Ja und der Proof-of-Work in Bitcoin ist[br]nichts anderes als der Hash des Blocks. 0:30:48.359,0:30:53.139 Und der muss dann eine Bedingung[br]erfüllen. Und zwar muss dieser Hash 0:30:53.139,0:30:58.580 mit einer gewissen Anzahl Nullen beginnen.[br]Also ich nehme den Header des Blocks 0:30:58.580,0:31:04.359 und bilde den double-hash davon.[br]Und dann müssen die ersten paar Bits 0:31:04.359,0:31:08.559 von diesem Hash müssen Null sein. Und[br]wieviele Bits das sind, das ist dann eben 0:31:08.559,0:31:13.470 die variable Schwierigkeit. Also wenn[br]ich mehr Nullen haben muss zu Beginn 0:31:13.470,0:31:16.970 dann ist es schwieriger den Proof-of-Work[br]zu erstellen. Und bei weniger 0:31:16.970,0:31:22.229 natürlich einfacher. Das Mining[br]funktioniert dann so dass… der Miner 0:31:22.229,0:31:25.919 nimmt einfach mal diesen Header,[br]und bildet den double-hash davon. 0:31:25.919,0:31:29.919 Dann prüft er ob der jetzt diese Bedingung[br]erfüllt. Das wird er vermutlich nicht tun. 0:31:29.919,0:31:34.210 Und dann inkrementiert er halt die nonce,[br]dadurch hat sich der Header verändert, 0:31:34.210,0:31:39.109 er bildet wieder den hash davon, und prüft[br]das. Und so macht er immer weiter. 0:31:39.109,0:31:45.509 Es ist aber so, diese nonce ist lediglich[br]32 bit lang, und der Hash mit 256 bit 0:31:45.509,0:31:50.249 ist wesentlich größer. Es kann also gut[br]sein, dass einfach durch das Inkrementieren 0:31:50.249,0:31:55.130 der Nonce kein passender Proof-of-Work[br]gefunden wird. Und in dem Fall wird 0:31:55.130,0:32:00.949 der Miner die coin-based Transaktion[br]verändern. Und zwar hat diese coin-based 0:32:00.949,0:32:05.450 Transaktion hat den Transaction Input,[br]der wird bei einer normalen Transaktion 0:32:05.450,0:32:09.729 dafür gebraucht zu beschreiben, woher[br]das Geld kommt in dieser Transaktion. 0:32:09.729,0:32:14.229 Das hat die coin-based nicht, denn die[br]macht ja quasi Geld aus dem Nichts heraus, 0:32:14.229,0:32:18.179 und den Wert in diesem Fall kann[br]dann der Miner frei beeinflussen. 0:32:18.179,0:32:22.239 Dadurch ändert sich der Hash dieser[br]Transaktion, und das setzt sich dann 0:32:22.239,0:32:27.799 durch den Merkle Tree hindurch fort bis[br]es quasi auch den Merkle Root verändert. 0:32:27.799,0:32:32.679 Und dadurch ist der ganze Blockheader[br]wieder verändert und der Miner 0:32:32.679,0:32:37.799 kann weiterarbeiten. So, das lässt sich ja[br]dann auch sehr einfach prüfen, ob das jetzt 0:32:37.799,0:32:41.700 ein korrekter Proof-of-Work ist. Ich nehme[br]einfach diesen Blockheader und bilde 0:32:41.700,0:32:48.449 den Hash und schaue ob das so stimmt. 0:32:48.449,0:32:53.330 Das Bitcoin-Netzwerk versucht alle zehn[br]Minuten einen neuen Block zu erstellen. 0:32:53.330,0:32:57.519 Um diese Zeit stabil zu halten,[br]wird die Schwierigkeit im Netzwerk 0:32:57.519,0:33:02.899 alle 14 Tage, also alle 2016 Blöcke,[br]angepasst, mit einem Algorithmus 0:33:02.899,0:33:10.539 wo jeder Miner feststellen kann wie weit[br]muss ich jetzt die Schwierigkeit verändern. 0:33:10.539,0:33:14.379 Die coin-based Transaktion, mit der[br]sich der Miner Geld überweist, 0:33:14.379,0:33:18.039 enthält in Bitcoin zwei Dinge:[br]einerseits die Transaction Fees, also 0:33:18.039,0:33:24.759 die Transaktionsgebühren der Transaktion[br]in den Block; und anderseits auch noch 0:33:24.759,0:33:29.500 neue Bitcoin, die neu ins System kommen.[br]Das waren ursprünglich 50 Bitcoin pro Block, 0:33:29.500,0:33:34.619 heute sind es noch 12,5, der[br]Wert halbiert sich alle vier Jahre. 0:33:34.619,0:33:38.509 Das war das letzte Mal in diesem Sommer,[br]da hat sich der Wert halbiert. Seither 0:33:38.509,0:33:47.810 gibt es nur noch 12,5 Bitcoin[br]für einen neuen Block. 0:33:47.810,0:33:51.999 Jetzt wollen wir noch uns anschauen[br]wie wir ‚Light Clients‘ bauen können. 0:33:51.999,0:33:56.509 Bitcoin kennt eigentlich mehr oder weniger,[br]drei Arten von Clients: ein ‚Full Node‘ 0:33:56.509,0:34:02.589 ist ein Client, welcher die[br]gesamte Blockchain speichert. 0:34:02.589,0:34:06.630 Der überprüft jede eingehende[br]Transaktion, jeden eingehenden Block 0:34:06.630,0:34:10.639 überprüft dieser Client, ob der auch[br]wirklich valide ist. Und er tut noch 0:34:10.639,0:34:14.119 etwas anderes, nämlich er seeded diese[br]Blöcke die er hat an das Netzwerk. 0:34:14.119,0:34:17.800 Also wenn jemand kommt und sagt:[br]„Ich hätte gern einen Block“ dann gibt 0:34:17.800,0:34:22.149 der Full Node diesen Block raus. Dann gibt[br]es ‚Pruning Clients‘. Der macht eigentlich 0:34:22.149,0:34:27.940 das genau selbe wie der Full Node.[br]Also der überprüft auch alle Transaktionen 0:34:27.940,0:34:32.520 und alle Blöcke. Aber der speichert jetzt[br]halt nicht die ganze Blockchain, sondern 0:34:32.520,0:34:35.550 wenn er findet „den Block brauche ich[br]nicht mehr“, dann löscht er den. 0:34:35.550,0:34:39.100 Und das macht dem Client Speicherplatz.[br]Der braucht aber immer noch 0:34:39.100,0:34:43.580 sehr viel Rechenkraft und sehr viel[br]Bandbreite, deutlich zuviel als dass ich 0:34:43.580,0:34:48.130 das auf meinem Smartphone laufen lassen[br]möchte. Und deshalb gibt es noch 0:34:48.130,0:34:53.520 die Light Clients oder SPV Clients.[br]Die dann auch geeignet sind, 0:34:53.520,0:34:56.980 um [sie] auf einem mobilen Gerät laufen[br]zu lassen. Und wie die funktionieren, 0:34:56.980,0:35:01.210 will ich jetzt noch besprechen. 0:35:01.210,0:35:05.590 Ein Light Client oder ein SPV Client,[br]was der tut zuerst ist, er lädt 0:35:05.590,0:35:09.020 die Header aller Blöcke herunter. Wir[br]haben ja gesehen, der Proof-of-Work 0:35:09.020,0:35:15.420 ist der Hash des Block Headers. D.h.[br]um den Proof-of-Work zu kontrollieren 0:35:15.420,0:35:18.760 brauche ich nicht den gesamten[br]Block, der Block Header genügt. 0:35:18.760,0:35:23.230 Und dasselbe gilt auch für die[br]Verknüpfung der Blöcke untereinander. 0:35:23.230,0:35:26.390 Welches der vorhergehende Block[br]ist, das steht ja auch im Header. 0:35:26.390,0:35:30.510 D.h. auch für diese Funktion brauche ich[br]nicht die ganzen Blöcke herunterzuladen. 0:35:30.510,0:35:35.450 Und so kann ich korrekt[br]die längste Kette erstellen, 0:35:35.450,0:35:40.350 innerhalb des Netzwerks, indem[br]ich nur die Header herunterlade. 0:35:40.350,0:35:45.560 Und der Gewinn dabei ist natürlich enorm.[br]Zur Zeit gibt es etwa 450.000 Blöcke. 0:35:45.560,0:35:52.350 Die brauchen mehr als 95 GB Speicherplatz.[br]Wenn man dann noch TX Index aktiviert 0:35:52.350,0:35:56.230 sind es, glaube ich, so um die[br]110 GB Speicherplatz, die es braucht. 0:35:56.230,0:36:00.450 Das ist natürlich blödsinnig viel auf einem[br]Smartphone. Aber nur die Block Headers, 0:36:00.450,0:36:03.730 alle Block Headers von diesen[br]450.000 Blöcken, die passen 0:36:03.730,0:36:10.180 in deutlich weniger als 100 MB rein. Und[br]das ist dann durchaus ein realistischer Wert, 0:36:10.180,0:36:14.940 dass ich das auf einem Smartphone habe.[br]Das zweite Konzept ist der Merkle Branch, 0:36:14.940,0:36:18.540 und das ist dann eigentlich noch fast[br]die interessantere Funktion, die uns 0:36:18.540,0:36:22.790 der Merkle Tree bildet. Und damit kann[br]jeder beweisen, dass eine Transaktion 0:36:22.790,0:36:26.770 tatsächlich Teil des Zustands ist. 0:36:26.770,0:36:30.650 Nun, die eine Möglichkeit, wie wir den[br]Merkle Tree nachbauen können, 0:36:30.650,0:36:35.210 ist natürlich, indem wir den Block[br]Body herunterladen, und dann 0:36:35.210,0:36:39.580 den ganzen Merkle Tree bauen.[br]Wenn ich jetzt aber nur beweisen will 0:36:39.580,0:36:44.200 dass eine Transaktion Teil des Blockes[br]ist, gibt es eine effizientere Möglichkeit. 0:36:44.200,0:36:47.950 Angenommen ich will jetzt beweisen,[br]dass die Transaktion (3) tatsächlich 0:36:47.950,0:36:51.920 Teil des Blocks ist. Dann brauche ich[br]nicht alle Transaktionen herunterzuladen, 0:36:51.920,0:36:57.760 sondern es reicht diese Transaktion (3)[br]herunterzuladen. – Ui, das war falsch. – 0:36:57.760,0:37:01.480 Und dann die restlichen Hashes,[br]also von jeder Ebene des Baums 0:37:01.480,0:37:04.480 lade ich einen Hash herunter.[br]Und damit kann ich jetzt 0:37:04.480,0:37:11.420 den Merkle Root Node wieder nachbilden,[br]und so feststellen, dass diese Transaktion 0:37:11.420,0:37:15.890 tatsächlich Teil des Blocks ist.[br]Das ist genau das was… 0:37:15.890,0:37:19.150 das hat jetzt natürlich auch einige[br]Vorteile. Ich brauche jetzt 0:37:19.150,0:37:23.520 weniger Elemente herunterzuladen, und[br]ich kann halt Hashes herunterladen, also 0:37:23.520,0:37:27.110 anstatt Transaktionen. Vorhin in dem[br]Beispiel hat das nicht soviel gebracht. 0:37:27.110,0:37:30.371 Aber wenn wir einen Block nehmen[br]mit 1600 Transaktionen, das ist 0:37:30.371,0:37:34.880 dieser Tage durchaus ein üblicher Block,[br]dann brauche ich jetzt zum Validieren 0:37:34.880,0:37:38.810 nicht mehr 1600 Transaktionen[br]herunterzuladen, sondern es genügt 0:37:38.810,0:37:42.400 eine Transaktion herunterzuladen und[br]dann elf Hashes, und damit kann ich 0:37:42.400,0:37:47.270 den Merkle Branch nachbauen. 0:37:47.270,0:37:52.640 Und so funktioniert ein SPV Client. SPV[br]steht für ‚simple payment verification‘. 0:37:52.640,0:37:56.660 Und das hat eigentlich… das wurde schon[br]im White Paper zu Bitcoin beschrieben, 0:37:56.660,0:38:00.890 wie das funktioniert. Alles was der[br]tun muss, um zu beweisen, dass 0:38:00.890,0:38:04.950 eine Transaktion reingekommen ist, ist,[br]er lädt zuerst alle Block Header herunter, 0:38:04.950,0:38:10.320 wie vorhin besprochen, er bildet[br]den längsten Branch daraus, 0:38:10.320,0:38:15.580 dann lädt er eine Transaktion herunter.[br]Und wenn ich jetzt wissen will… 0:38:15.580,0:38:18.331 wenn ich von jemandem Geld erhalte und[br]ich will jetzt zeigen, ich habe das Geld 0:38:18.331,0:38:22.610 tatsächlich erhalten, lade ich halt diese[br]Transaktion herunter, und dann lade ich 0:38:22.610,0:38:27.110 den passenden Merkle Branch herunter.[br]Und jetzt kann ich quasi zeigen, dass 0:38:27.110,0:38:32.160 dieser Merkle Branch tatsächlich mit der[br]längsten Kette von Blöcken verbunden ist. 0:38:32.160,0:38:36.990 Und so habe ich jetzt den Beweis dafür,[br]dass ich das Geld tatsächlich erhalten habe. 0:38:36.990,0:38:40.560 So, das ist diese Funktionsweise.[br]Jetzt haben wir noch etwas mehr Zeit, 0:38:40.560,0:38:44.290 als ich gehofft hatte. Ich werde jetzt[br]noch versuchen, die Pruning Clients 0:38:44.290,0:38:49.010 zu erklären. Das hängt dann damit zusammen[br]wie eigentlich Bitcoin-Transaktionen 0:38:49.010,0:38:53.910 funktionieren. Nun, wir sind es ja[br]gewohnt, dass wir irgendwie auf der Bank 0:38:53.910,0:38:58.440 ein Konto haben. Und das Konto[br]hat einen Besitzer. Hoffentlich mich! 0:38:58.440,0:39:02.720 Und es hat einen Geldbetrag. Und jedesmal,[br]wenn ich eine Transaktion durchführe, 0:39:02.720,0:39:06.760 verändert sich der Geldbetrag. Also ich[br]überweisen jemandem Geld, und dann 0:39:06.760,0:39:11.520 verändert sich halt der Betrag auf meinem[br]Konto. In Bitcoin funktioniert das 0:39:11.520,0:39:15.620 wesentlich anders, dort besitze ich[br]nicht ein Konto, sondern ich besitze 0:39:15.620,0:39:20.170 sogenannte ‚Unspent Transaction Outputs‘.[br]Und wir sehen jetzt hier, sagen wir Alice 0:39:20.170,0:39:23.880 hat diese fünf Unspent Transaction[br]Outputs, die haben jeweils einen Besitzer, 0:39:23.880,0:39:29.230 nämlich Alice. Und jeweils einen Betrag[br]der dort verfügbar ist. Und der Betrag 0:39:29.230,0:39:33.840 kann nicht geändert werden. Das ist fest.[br]Und nehmen wir jetzt an, Alice würde gerne 0:39:33.840,0:39:38.910 eine Transaktion machen, an Bob,[br]die würde ihm gerne 42 Bitcoin überweisen. 0:39:38.910,0:39:42.200 Dann erstellt sie eine Transaktion, und[br]sagt, das Geld dieser Transaktion, 0:39:42.200,0:39:47.270 42 Bitcoin, sollen an Bob gehen. Und jetzt[br]muss sie das Geld irgendwoher haben. 0:39:47.270,0:39:53.200 Und dann sagt sie halt, ich gebe[br]diese drei Transaction Outputs aus. 0:39:53.200,0:39:56.920 Und das Interessante an Transaction[br]Outputs… wie gesagt, den Betrag 0:39:56.920,0:40:01.760 kann man nicht verändern, sondern[br]Alice muss die alle komplett ausgeben. 0:40:01.760,0:40:05.930 Jetzt sind aber diese Transaction Outputs[br]zusammengenommen 44 Bitcoin, 0:40:05.930,0:40:10.990 und nicht 42 Bitcoins. D.h. diese[br]Transaktion gibt jetzt zuviel Geld aus, 0:40:10.990,0:40:17.330 also sie gibt mehr Transaction Outputs aus[br]als sie dann schlussendlich Geld dem Bob 0:40:17.330,0:40:21.400 überweist. Und was kann jetzt Alice[br]tun? Was sie tut, ist, sie macht 0:40:21.400,0:40:27.360 einen zweiten Output in ihrer Transaktion.[br]Und hier überweist sie jetzt Geld an Alice. 0:40:27.360,0:40:31.670 D.h. eine Transaktion in Bitcoin kann[br]beliebig viele Inputs und beliebig viele 0:40:31.670,0:40:36.740 Outputs haben. Was es hier noch zu[br]sagen gibt, ist, haben wir immer noch 0:40:36.740,0:40:41.070 einen Unterschied. Jetzt haben wir 44[br]Bitcoin, die in die Transaktion reinkommen, 0:40:41.070,0:40:45.860 und nur 43 die rausgehen. Das restliche[br]Bitcoin, das jetzt hier nicht ausgegeben wird, 0:40:45.860,0:40:50.810 das ist quasi impliziert die Transaction[br]Fee, welche der Miner erhält, der diese 0:40:50.810,0:40:56.400 Transaktion mint. So eine Transaction Fee[br]ist implementiert. Jetzt haben wir gesehen, 0:40:56.400,0:40:59.640 Alice hat durch das Erstellen dieser[br]Transaktion neue Transaction Outputs 0:40:59.640,0:41:05.760 erstellt. Nämlich einen, der jetzt Bob[br]gehört, und einen der Alice gehört. 0:41:05.760,0:41:08.980 Und jetzt können wir auch nachvollziehen,[br]diese Transaction Outputs, welche Alice 0:41:08.980,0:41:13.850 ausgegeben hat, die gehören alle irgendwie[br]zu anderen Transaktionen, welche es vorhin 0:41:13.850,0:41:19.800 gegeben hat. Nun, ein Transaction Output[br]kann einen von zwei Zuständen haben. 0:41:19.800,0:41:24.930 Er kann ausgegeben sein, oder nicht.[br]Und natürlich kann man nur die ausgeben, 0:41:24.930,0:41:29.320 die noch nicht ausgegeben sind. Und das[br]heißt, wenn ich wissen will, wieviel Geld 0:41:29.320,0:41:33.350 Alice gehört, dann suche ich mir alle[br]Transaction Outputs zusammen, 0:41:33.350,0:41:38.360 die Alice gehören, und addiere die Summe,[br]und dann weiß ich, Alice gehört „soviel“ Geld. 0:41:38.360,0:41:41.200 Das kann ich für jeden Teilnehmer[br]des Systems machen, dann weiß ich 0:41:41.200,0:41:46.900 für jeden Teilnehmer, wieviel Geld denn[br]der Person gehört. Wenn ich jetzt also 0:41:46.900,0:41:50.980 alle Transaction Outputs nehme, die[br]nicht ausgegeben sind, dann habe ich 0:41:50.980,0:41:56.530 den aktuellen Zustand des Netzwerks. Dann[br]weiß ich für jeden Teilnehmer, wieviel Geld 0:41:56.530,0:42:04.960 diese Person hat. Und genau diesen[br]Mechanismus macht sich ein Pruning Client 0:42:04.960,0:42:09.470 zunutze. Der sagt nämlich, eigentlich[br]brauche ich nicht die ganze Blockchain 0:42:09.470,0:42:12.931 zu speichern, das ist ja blöd, denn wenn[br]eine neue Transaktion reinkommt, und 0:42:12.931,0:42:17.260 ich wissen will ob die tatsächlich valide[br]ist, dann muss ich nur prüfen, ob die 0:42:17.260,0:42:22.060 einen Output ausgibt, der noch unspent[br]ist, denn wenn die Transaktion einen 0:42:22.060,0:42:25.520 Transaction Output ausgibt, der schon[br]ausgegeben ist, dann ist die natürlich 0:42:25.520,0:42:29.430 nicht valide, man kann ja nicht dasselbe[br]Geld zweimal ausgeben. Oder wenn 0:42:29.430,0:42:32.790 die Transaktion versucht, einen[br]Transaction Output auszugeben, 0:42:32.790,0:42:36.220 den es gar nicht gibt, dann ist[br]die natürlich auch nicht valide. 0:42:36.220,0:42:42.290 Was jetzt also ein Pruning Client tut –[br]und das tut übrigens auch ein Full Node: 0:42:42.290,0:42:46.270 wenn eine neue Transaktion reinkommt,[br]und da steht in der Transaktion „ich gebe 0:42:46.270,0:42:51.770 diesen Transaction Output aus“, dann[br]geht der Full Node nicht und versucht, 0:42:51.770,0:42:55.930 die 100 GB große Blockchain zu durchsuchen[br]nach diesem Transaction Output, das wäre 0:42:55.930,0:43:00.160 ja blödsinnig, sondern der legt sich halt[br]eine kleine Datenbank an, und dort 0:43:00.160,0:43:05.520 stehen alle Transaction Outputs drin.[br]Und dann sagt er sich, für jeden… 0:43:05.520,0:43:08.580 also alle Unspent Transaction Outputs[br]stehen dort drin, und dann sagt sich 0:43:08.580,0:43:12.090 der Client, für jede Transaktion,[br]die reinkommt und die valide ist, 0:43:12.090,0:43:17.540 entferne ich alle Transaction Outputs die[br]die Transaktion ausgibt aus der Datenbank, 0:43:17.540,0:43:22.870 und alle neuen Transaction Outputs füge[br]ich dort ein. Und so behält der Client 0:43:22.870,0:43:28.530 den Zustand. Und der Pruning Client sagt[br]sich dann halt: „Naja, die Blöcke, die 0:43:28.530,0:43:31.550 brauche ich jetzt ja nicht mehr, weil ich[br]habe den Zustand in der Datenbank, 0:43:31.550,0:43:35.380 der ist auch viel kleiner als all die[br]blöden Blöcke, die Blöcke werfe ich fort.“ 0:43:35.380,0:43:39.260 Der muss dann noch etwas vorsichtig sein,[br]denn wenn jetzt plötzlich von weiter hinten 0:43:39.260,0:43:42.770 eine längere Kette kommt, dann muss er[br]das ja wieder nachvollziehen können, 0:43:42.770,0:43:47.520 also wird er sich noch einige Blöcke[br]zusätzlich speichern, als nur den neuesten. 0:43:47.520,0:43:54.720 Aber er kann so sehr viel Speicherplatz[br]sparen. Er muss aber… trotzdem 0:43:54.720,0:44:00.420 muss ein Pruning Client eigentlich jede[br]Transaktion, die es jemals gegeben hat, 0:44:00.420,0:44:04.490 herunterladen, und muss dann halt auch[br]die alle verifizieren. Das braucht auch 0:44:04.490,0:44:08.280 immer noch sehr viel Rechenkraft, und[br]sehr viel Bandbreite. Und deshalb sind 0:44:08.280,0:44:13.300 solche Clients nicht geeignet[br]für Mobilgeräte. 0:44:13.300,0:44:15.870 Und was man hier vielleicht noch sagen[br]kann, ich habe jetzt eigentlich irgendwie 0:44:15.870,0:44:25.300 gesagt, … 0:44:25.300,0:44:31.510 …ich habe jetzt gesagt, Alice gibt einen[br]Transaction Output aus. Das ist… 0:44:31.510,0:44:34.570 In Wirklichkeit ist es in Bitcoin[br]recht kompliziert implementiert. 0:44:34.570,0:44:38.790 Das funktioniert nämlich so, dass der[br]Transaction Output hat ein Stück Code 0:44:38.790,0:44:44.940 drin. Dafür gibt es in Bitcoin eine eigene[br]Assemblersprache, die das betreibt. 0:44:44.940,0:44:50.960 Und der Input muss jetzt ebenfalls ein[br]Stück Code enthalten. Und wenn die dann 0:44:50.960,0:44:55.670 nacheinander ausgeführt werden, muss das[br]am Schluss den Wert 'two' ergeben, 0:44:55.670,0:44:59.740 und nur in dem Fall wurde der Output[br]richtig ausgegeben. Und das ist 0:44:59.740,0:45:03.820 ein ziemlich kompliziertes System, wie das[br]wirklich funktioniert. Das ist dann halt 0:45:03.820,0:45:07.440 eine eigene Programmiersprache, die ist[br]zwar nicht Turing-vollständig, aber damit 0:45:07.440,0:45:11.940 lassen sich dann alle möglichen lustigen[br]Regeln implementieren. Die häufigste Regel 0:45:11.940,0:45:23.410 die man findet, in über 80%[br]der Fälle, sind sogenannte… 0:45:23.410,0:45:28.250 …die Regel sagt dann irgendsowas wie:[br]„Um diesen Output ausgeben zu können, 0:45:28.250,0:45:32.380 musst du beweisen, dass du den geheimen[br]Schlüssel besitzt zu dem öffentlichen 0:45:32.380,0:45:37.400 Schlüssel, dessen Hash ich jetzt hier[br]reinpacke.“ Und in dem Input steht dann 0:45:37.400,0:45:43.310 halt: „Ja, ich besitze diesen geheimen[br]Schlüssel, und ich beweise dir das, 0:45:43.310,0:45:47.680 indem ich hier den öffentlichen Schlüssel[br]reinpacke und die Transaktion mit dem 0:45:47.680,0:45:52.840 geheimen Schlüssel signiere.“ Und dann[br]kann jemand, der das verifizieren will, 0:45:52.840,0:45:56.930 kann einfach den öffentlichen Schlüssel[br]nehmen, schauen ob das dem Hash entspricht, 0:45:56.930,0:46:04.630 und dann mit dem öffentlichen Schlüssel[br]die Signatur der Transaktion verifizieren. 0:46:04.630,0:46:09.940 Das ist die mit Abstand häufigste Art,[br]wie diese Transaktionen in Wirklichkeit 0:46:09.940,0:46:14.240 funktionieren. Aber das ist halt dann sehr[br]kompliziert, und damit könnte man leicht 0:46:14.240,0:46:22.250 einen eigenen Vortrag füllen.[br]Deshalb werde ich jetzt hier aufhören. 0:46:22.250,0:46:28.900 Habe ich da diese tolle Seite gebastelt. 0:46:28.900,0:46:32.920 – Ups, das ist eigentlich zu weit – 0:46:32.920,0:46:42.750 Finde ich es, oder nicht? 0:46:42.750,0:46:45.760 Ja, ha, gefunden! Unglaublich.[br]Lachen 0:46:45.760,0:46:48.860 Also wir haben jetzt noch Zeit für Fragen,[br]wenn ihr noch was wissen wollt. 0:46:48.860,0:46:54.940 Oder ihr könnt mich auch erreichen,[br]am einfachsten hier über das DECT-Telefon 0:46:54.940,0:47:01.890 in dem Kongress, wenn ihr Fragen habt.[br]Ihr findet einen Handout der Slides 0:47:01.890,0:47:06.000 auch im Fahrplan. Und ich werde auch[br]die Folien selbst noch hochladen, 0:47:06.000,0:47:09.520 und den entsprechenden Source Code[br]zum Erzeugen der Folien werde ich auch 0:47:09.520,0:47:11.460 verlinken. 0:47:11.460,0:47:12.960 Beifall 0:47:12.960,0:47:14.550 Herald: vimja!! 0:47:14.550,0:47:24.790 andauernder Beifall 0:47:24.790,0:47:31.540 Es ist noch einiges an Zeit für Fragen;[br]also wenn ihr Fragen habt, 0:47:31.540,0:47:35.440 dann reiht euch an den Mikrofonen auf.[br]Eine Sache möchte ich sagen: 0:47:35.440,0:47:40.280 wenn ihr jetzt rausgehen wollt, verlasst[br]bitte leise den Saal, damit das 0:47:40.280,0:47:44.360 mit den Fragen einigermaßen klappt.[br]Liebe Tür-Engel, wir lassen im Moment 0:47:44.360,0:47:50.430 noch niemanden rein. Erstmal können Leute[br]nur rausgehen. Und bitte tut das leise. 0:47:50.430,0:47:55.520 Wir fangen mit dem Signal-Engel an. 0:47:55.520,0:47:58.730 Signal Angel: Eine Frage aus dem Internet[br]bezüglich dem Man-in-the-middle 0:47:58.730,0:48:02.290 double-spending-Angriff. Könnte Mallory[br]nicht diesen Angriff gleichzeitig 0:48:02.290,0:48:07.210 mit derselben Fake-Blockchain gegen zehn[br]verschiedene Autohändler machen, und 0:48:07.210,0:48:12.890 mit dem gleichen Aufwand zehn Autos klauen?[br]Damit würde es sich doch wieder lohnen, 0:48:12.890,0:48:20.050 auch wenn man mit dem Gegenwert eines[br]Autos an Rechenzeit investieren müsste. 0:48:20.050,0:48:25.590 vimja: Das ist eine gute Überlegung die[br]ich mir so noch auch gar nie gemacht habe. 0:48:25.590,0:48:30.030 Ich müsste darüber mal nachdenken. Ich[br]nehme aber grundsätzlich an, dass es 0:48:30.030,0:48:35.670 vermutlich funktionieren würde. Der[br]Aufwand wird dann aber halt sehr viel 0:48:35.670,0:48:40.970 größer, irgendwie um die Netzwerk-Nodes[br]zu kontrollieren. Grundsätzlich denke ich 0:48:40.970,0:48:44.950 aber, dass es kein… damit das System[br]wirklich sicher ist, sollte das 0:48:44.950,0:48:50.730 kein Argument sein dürfen. Also ich hätte[br]jetzt auf Anhieb gesagt, dass es vermutlich 0:48:50.730,0:48:54.790 klappen würde. 0:48:54.790,0:48:58.251 Herald: Okay, dann machen wir weiter[br]mit Mikrofon 2, hier vorne, bitte! 0:48:58.251,0:49:03.220 Frage: Ja, hallo. Du hast gesagt, mit[br]einer 50%-Attack kann man im Prinzip 0:49:03.220,0:49:07.140 die Blockchains hijacken. Wenn man[br]sich jetzt mal eine hypothetische 0:49:07.140,0:49:11.480 Regierungsorganisation mit sehr, sehr,[br]sehr viel Rechenpower überlegt, 0:49:11.480,0:49:16.220 mal so ganz in den Raum geraten, gibt’s[br]Überlegungen, wie wahrscheinlich das ist? 0:49:16.220,0:49:19.540 vimja: Nun, es ist so, mit einfach[br]herkömmlicher Rechenpower wird das 0:49:19.540,0:49:22.750 kaum möglich sein, also irgendwie[br]für diese spezielle Aufgabe, 0:49:22.750,0:49:28.400 den Double-SHA256-Hash, hat das Bitcoin-[br]Netzwerk ein Vielfaches der Rechenkraft, 0:49:28.400,0:49:32.510 die selbst die 500 schnellsten Supercomputer[br]aufbringen könnten. Es gibt aber eine 0:49:32.510,0:49:36.580 viel einfachere Möglichkeit, unser guter[br]Freund China, denn die meisten… 0:49:36.580,0:49:40.070 denn heute ist es halt so: eigentlich[br]möchte man gerne, dass die Miner 0:49:40.070,0:49:43.740 verteilt sind, und jeder ein wenig zuhause[br]minet. In Praxis ist es aber so, dass 0:49:43.740,0:49:47.770 das heute das große Geschäft ist. Und das[br]wird dann halt heute in Rechenzentren 0:49:47.770,0:49:54.280 in China betrieben. Und China hat heute[br]mehr als 50% der Rechenkraft von Bitcoin, 0:49:54.280,0:49:57.430 also, toll, unsere unabhängige Währung[br]gehört jetzt den Chinesen. 0:49:57.430,0:50:01.030 Und selbst wenn das nicht stimmen sollte,[br]und das nicht funktionieren sollte, 0:50:01.030,0:50:04.630 ist es so, dass all die spezielle[br]Hardware, die heute zum Mining 0:50:04.630,0:50:08.940 notwendig ist, in China hergestellt wird.[br]Und China könnte einfach all diese Fabriken, 0:50:08.940,0:50:12.710 in denen die hergestellt werden,[br]beschlagnahmen, und nach einigen Monaten 0:50:12.710,0:50:15.120 hätten sie trotzdem wieder mehr[br]Rechenleistung als jeder andere, 0:50:15.120,0:50:21.250 und könnte die Währung so kontrollieren.[br]Also, das ist durchaus wahrscheinlich. 0:50:21.250,0:50:24.680 Herald: Dann machen wir weiter[br]mit Mikrofon 1, hier vorne, bitte. 0:50:24.680,0:50:28.970 Frage: Ja, mir geht’s auch gerade um die[br]Rechenpower. Also gibt es da irgendwie 0:50:28.970,0:50:34.200 Ansätze in anderen elektronischen[br]Währungen, wie das verhindert werden kann, 0:50:34.200,0:50:40.380 dass immer quasi zum Stand der aktuellen[br]Technik die maximale Rechenpower nötig ist, 0:50:40.380,0:50:44.041 um so ein System laufen zu lassen? 0:50:44.041,0:50:47.400 vimja: Es hat zur Zeit, im Verlauf der[br]Zeit verschiedene Möglichkeiten, 0:50:47.400,0:50:51.700 also verschiedene Ansätze gegeben. 0:50:51.700,0:50:55.150 Das eine was man immer wieder versucht[br]hat, ist halt, dass man das nicht nur auf 0:50:55.150,0:50:59.720 Rechenkraft beschränkt, sondern dass man[br]sagt, der Angriff der braucht nicht nur 0:50:59.720,0:51:03.950 Rechenpower sondern auch viel RAM,[br]oder viel Memory. Und dadurch ist es 0:51:03.950,0:51:08.250 sehr viel schwieriger, Hardware zu bauen.[br]Oder sehr viel teurer, Hardware zu bauen, 0:51:08.250,0:51:12.240 die darauf spezialisiert ist, und man[br]erhofft sich davon Erfolge, aber 0:51:12.240,0:51:16.010 schlussendlich hat man dort wieder[br]dasselbe Problem. Ich weiß aber, 0:51:16.010,0:51:21.500 dass Ethereum arbeitet an einem Konzept,[br]das nennen sie Proof-of-Stake. 0:51:21.500,0:51:24.730 Und wie genau das funktioniert, kann ich[br]dir nicht sagen. Aber da hängt dann 0:51:24.730,0:51:29.160 die Wahrscheinlichkeit, dass du einen[br]Block erstellst, davon ab wieviel Geld 0:51:29.160,0:51:32.900 du besitzt in dem Netzwerk, oder sowas.[br]Und die brauchen dann eigentlich 0:51:32.900,0:51:35.840 kein Mining mehr. Und die haben dann halt[br]auch das Problem nicht mehr dass man 0:51:35.840,0:51:40.700 unglaublich viel Strom braucht, um das[br]Ding zu minen. Und ich dachte, die wollten 0:51:40.700,0:51:44.660 diesen Sommer umstellen. Ich habe dann[br]aber das Ganze ein wenig aus den Augen 0:51:44.660,0:51:47.560 verloren, und kann dir jetzt nicht[br]sagen wie weit die damit sind. 0:51:47.560,0:51:48.260 Also grundsätzlich… 0:51:48.260,0:51:50.100 Frage: Wie heißt das nochmal? 0:51:50.100,0:51:53.570 vimja: ‚Proof-of-Stake‘. Und das wird in[br]Ethereum implementiert. Aber wie weit 0:51:53.570,0:51:57.490 die sind, kann ich dir nicht sagen. Das[br]müsstest du selbst nachschauen gehen. 0:51:57.490,0:51:58.770 Frage: Danke. 0:51:58.770,0:52:02.440 Herald: Dann machen wir weiter mit[br]Mikrofon 4, dort drüben, bitte! 0:52:02.440,0:52:06.550 Frage: Ich stelle mal zwei Fragen. Das[br]eine ist: öffentliche Grundbuchämter 0:52:06.550,0:52:11.470 könnte man doch sehr gut in der Blockchain[br]umlegen [anlegen], und dadurch könnte 0:52:11.470,0:52:14.590 doch die Verwaltung sehr viel Geld[br]einsparen, und z.B. Handelsregister 0:52:14.590,0:52:16.730 sind ja auch öffentlich, die könnte man[br]doch auch in die Blockchain verschieben. 0:52:16.730,0:52:20.450 Oder mache ich da irgendeinen Denkfehler,[br]dass es am Schluss für die Verwaltung 0:52:20.450,0:52:22.980 teurer kommt? Und was mich auch[br]noch wundert, was deine Meinung 0:52:22.980,0:52:26.250 zu Smart Contracts ist. 0:52:26.250,0:52:30.300 vimja: Also, zu der ersten Frage, das ist[br]so, daran wird tatsächlich gearbeitet. 0:52:30.300,0:52:35.030 Insbesondere die britische Regierung hat[br]auch Forschungsgruppen, die erforschen 0:52:35.030,0:52:41.890 sollen, wie Blockchains der Verwaltung[br]helfen können. Gerade beim Grundbuchamt, 0:52:41.890,0:52:46.000 also solche Systeme brauchen starke[br]Anpassungen, gerade wenn wir uns 0:52:46.000,0:52:52.460 vorstellen, ein Grundbuchamt, wenn es dann[br]jemandem gelingen würde, irgendwie 0:52:52.460,0:52:55.690 jetzt trotzdem ein Grundstück quasi[br]zu stehlen, und das würde einfach 0:52:55.690,0:53:01.960 in dieser Blockchain drin feststehen, wie[br]würde man das wieder rückgängig machen? 0:53:01.960,0:53:06.120 Also wenn wir heute ein Grundbuchamt[br]haben, dann können die alles überschreiben. 0:53:06.120,0:53:10.230 Und irgendwie möchten wir ja dann trotzdem[br]nicht einfach nur dieser Blockchain vertrauen. 0:53:10.230,0:53:14.810 Wir möchten trotzdem die Möglichkeit[br]haben, dass gewisse Stellen, gerade eben 0:53:14.810,0:53:18.020 unser Staat, das überschreiben können.[br]Da müssen dann in diese Blockchains 0:53:18.020,0:53:22.460 zusätzliche Mechanismen eingebaut werden,[br]dass das trotzdem geht, und das ist dann 0:53:22.460,0:53:26.850 halt bedenklich, weil jetzt trotzdem da[br]jemand das Zeugs kaputtmachen kann. 0:53:26.850,0:53:30.750 Also das ist nicht ganz einfach, diese[br]Dinge zu tun. Aber ich denke schon, 0:53:30.750,0:53:38.360 dass gerade Grundbuchämter eine gute[br]Chance sind, und das ist vermutlich auch 0:53:38.360,0:53:43.760 etwas vom Ersten, was wir implementiert[br]sehen werden. Soviel für öffentliche Ämter. 0:53:43.760,0:53:48.000 Aber ich denke auch, dass es einen[br]Hybridbetrieb geben wird. Also 0:53:48.000,0:53:51.580 dass man quasi sagt, das ist zwar[br]öffentlich in einer Blockchain, aber 0:53:51.580,0:53:56.360 schlussendlich, was wirklich gilt ist[br]immer noch das, was im Grundbuchamt steht, 0:53:56.360,0:53:59.480 und das wird dann halt solange so[br]weiterbetrieben, bis sich das wirklich 0:53:59.480,0:54:03.220 bewährt hat, und man den Übergang macht.[br]Und die zweite Frage, sorry, habe ich 0:54:03.220,0:54:07.190 wieder vergessen. 0:54:07.190,0:54:10.500 Herald: Okay, wenn das die Frage[br]beantwortet und er nicht wieder aufsteht, 0:54:10.500,0:54:14.760 dann würde ich jetzt mit Mikrofon 7[br]weitermachen, dort oben, bitte. 0:54:14.760,0:54:20.140 Frage: Ja, vielen Dank für den spannenden[br]Vortrag. Mich würde noch interessieren, 0:54:20.140,0:54:24.970 vielleicht noch was zu dem Thema ‚Ende[br]der Bitcoins‘, die sind ja anscheinend 0:54:24.970,0:54:29.220 begrenzt, soweit ich das verstanden habe.[br]Und wie wird das Erstellen von neuen 0:54:29.220,0:54:33.880 Blöcken letztendlich in ferner Zukunft[br]dann belohnt, werden die einfach immer so 0:54:33.880,0:54:36.690 weiter unterteilt, und man bekommt dann[br]nur noch Bruchteile von Bitcoins 0:54:36.690,0:54:38.280 als Belohnung, oder wie funktioniert das? 0:54:38.280,0:54:41.520 vimja: Das ist eine sehr gute Frage,[br]die sich natürlich auch diesen Sommer 0:54:41.520,0:54:45.470 gestellt hat, weil sich ja der[br]Block Reward halbiert hat. 0:54:45.470,0:54:49.150 Und erstaunlicherweise ist es dann aber[br]eigentlich ohne Weiteres weitergegangen. 0:54:49.150,0:54:53.210 Nun ist es so, der Mechanismus,[br]der eigentlich greifen sollte, ist 0:54:53.210,0:54:57.880 die Transaction Fees. Dass es durch[br]die Transaction Fees getragen wird, 0:54:57.880,0:55:02.550 diese Gebühr. Nur ist es heute so, dass[br]die Transaction Fees so niedrig sind, 0:55:02.550,0:55:07.410 dass das Minen sich nicht rentieren würde,[br]also der Stromverbrauch ist viel zu hoch, 0:55:07.410,0:55:13.720 als dass es sich lohnen würde, nur[br]für die Transaction Fees zu minen. 0:55:13.720,0:55:17.230 Andererseits ist es aber so, dass die[br]Transaction Fees heute schon sehr hoch 0:55:17.230,0:55:21.090 sind, also die kommen heute irgendwo[br]zwischendurch schon in die Bereiche 0:55:21.090,0:55:24.740 der Transaction Fees, die man auch[br]zahlt bei Kreditkartenüberweisungen. 0:55:24.740,0:55:28.580 Und das ist natürlich absolut lächerlich[br]hoch. Und dann ist es aber auch so, 0:55:28.580,0:55:32.970 dass die Blöcke voll sind, d.h. wenn das[br]Block Limit – das ist ein künstliches 0:55:32.970,0:55:37.260 Limit, wie groß die Blöcke sein dürfen,[br]und die Community führt da großen Krieg 0:55:37.260,0:55:41.690 darüber ob man das jetzt ändern soll oder[br]nicht – aber wenn dieses Limit halt nicht 0:55:41.690,0:55:44.770 erhöht wird, dann passen nicht mehr[br]Transaktionen rein, und dann ist 0:55:44.770,0:55:48.770 der einzige Weg höhere Transaction…[br]also mehr Transaction Fees zu haben 0:55:48.770,0:55:51.620 für den Miner, ist diese Transaction Fees[br]zu erhöhen. Und wenn man die weiter 0:55:51.620,0:55:55.920 erhöht, dann lohnt es sich einfach[br]nicht mehr, Bitcoin zu verwenden. 0:55:55.920,0:55:58.531 Im Moment ist es noch nicht so ein[br]Problem, für die nächsten vier Jahre 0:55:58.531,0:56:02.640 sind es ja noch 12,5 Bitcoin die[br]man kriegt. Aber wie es danach 0:56:02.640,0:56:07.200 weitergehen wird, das muss man abwarten,[br]und dann schauen, was da genau passiert. 0:56:07.200,0:56:10.750 Und ich denke dass das ist auch noch ein[br]dynamisches System, das sich schnell 0:56:10.750,0:56:14.960 wandelt, und da werden auch noch[br]viele Leute viele gute Ideen haben. 0:56:14.960,0:56:17.770 Frage: Darf ich noch mal kurz was[br]nachfragen? D.h. der Proof-of-Work 0:56:17.770,0:56:22.980 ist nicht der direkte Bitcoin, den ich[br]bekomme, also nicht die 12,5 Bitcoins, 0:56:22.980,0:56:28.230 die ich bekomme, um einen Block zu[br]erstellen, ist nicht der Proof-of-Work? 0:56:28.230,0:56:31.930 vimja: Nein nein, das ist… die 12,5 Bitcoin[br]die du kriegst, also die 12,5 Bitcoin 0:56:31.930,0:56:34.940 plus das klein weniger, was von den[br]Transaction Fees kommt, das ist 0:56:34.940,0:56:39.430 der Block Reward. Nennt sich das. Und der[br]Proof-of-Work ist einfach der Beweis dafür, 0:56:39.430,0:56:44.790 dass du die Arbeit auf dich genommen[br]hast, einen Block zu erstellen. 0:56:44.790,0:56:49.500 Herald: Gut, dann machen wir oben[br]auf dem Balkon weiter mit der 8. Bitte. 0:56:49.500,0:56:52.600 Frage: Ja, das ganze Erstellen von[br]den Blöcken basiert ja darauf, dass 0:56:52.600,0:56:56.680 Transaktionen in des System reinkommen.[br]Die Frage wäre jetzt, was passiert, wenn 0:56:56.680,0:57:01.880 keine Transaktionen zur Verfügung stehen.[br]Werden dann Dummy-Transaktionen erzeugt, 0:57:01.880,0:57:03.880 oder leere Blöcke, oder was passiert dann? 0:57:03.880,0:57:08.220 vimja: Nein, das kannst du sehen, wenn du[br]ganz zurückgehst, die ersten Blöcke, die 0:57:08.220,0:57:11.690 überhaupt erstellt wurden, dort gab es ja[br]noch keine Transaktionen. Was hätte auch 0:57:11.690,0:57:16.550 überwiesen werden sollen wenn niemand Geld[br]hat. Und da war es dann halt so, dass 0:57:16.550,0:57:21.180 der Block enthält dann nur die Coin-based-[br]Transaktion. Der Miner wird ja immer 0:57:21.180,0:57:25.000 eine Coin-based-Transaktion machen.[br]Einfach, weil es für ihn interessant ist. 0:57:25.000,0:57:33.150 Und dann erstellt er halt einen Block, der[br]nur diese Coin-based-Transaktion enthält. 0:57:33.150,0:57:35.940 Herald: Dann machen wir weiter[br]hier vorne mit der 2. Bitte. 0:57:35.940,0:57:38.300 Mikro 2 will Mikro 4 Vorrang geben[br]Bitte? 0:57:38.300,0:57:41.720 Wenn du nicht möchtest, dann machen[br]wir mit der 4 weiter! Sehr fair von dir! 0:57:41.720,0:57:48.830 Frage: Och, dankeschön. Ich habe das Thema[br]‚Blockchain‘ in verschiedenen Kontexten 0:57:48.830,0:57:51.480 jetzt im letzten Jahr sehr viel gesehen.[br]Es ist fast ein Buzzword in sehr sehr 0:57:51.480,0:57:55.900 vielen Branchen, von FinTech bis zu[br]IoT oder wo auch immer. Konntest du 0:57:55.900,0:57:59.920 im Kontext deiner Arbeit ein bisschen[br]so einen Trend raussehen, wo sich da 0:57:59.920,0:58:04.100 erste Anwendungen[br]wirklich bewähren können? 0:58:04.100,0:58:08.420 vimja: Erste Anwendungen gibt es ja bereits.[br]Du kannst mit Bitcoin Dinge bezahlen. 0:58:08.420,0:58:13.930 Aber das ist so ein wenig eine Sache.[br]Eines, was ich gesehen habe, wo ich mich 0:58:13.930,0:58:17.800 aber schlicht weigere mich zu beteiligen,[br]ist halt dass Banken das zu verwenden 0:58:17.800,0:58:22.890 versuchen, um die Transaktionen zwischen[br]den Banken zu regeln. Da wird es ja, 0:58:22.890,0:58:26.410 glaube ich, im Anschluss im Saal G[br]einen Talk geben dazu, wie das heute 0:58:26.410,0:58:30.980 gemacht wird, wie Banken zwischeneinander[br]Geld austauschen. Und das möchte man 0:58:30.980,0:58:34.220 in Zukunft mit Bitcoin [eher: Blockchain][br]machen. Und da sind die Banken auch dran, 0:58:34.220,0:58:38.940 sehr viel Geld und sehr viel Zeit rein zu[br]investieren. Das ist halt sehr schade, 0:58:38.940,0:58:43.210 dass diese eigentlich coole Technologie[br]jetzt für sowas verwendet werden soll. 0:58:43.210,0:58:48.940 Aber ich denke das ist eine Anwendung die[br]kommt. Dann eben einfache Kryptowährungen, 0:58:48.940,0:58:53.540 wie etwa Bitcoin, um Dinge[br]zu bezahlen. Und auch… 0:58:53.540,0:58:57.590 ich denke auch mit Ethereum, eben gerade[br]diese Smart Contracts werden kommen, 0:58:57.590,0:59:01.340 dass man halt eben irgendwelche Dinge,[br]irgendwelche Third Parties, die man 0:59:01.340,0:59:05.970 verwendet für Dinge zu regeln, ersetzen[br]wir jetzt aber. Was jetzt als Erstes 0:59:05.970,0:59:09.560 quasi den Durchbruch schaffen wird und[br]als Großes eingesetzt werden wird, 0:59:09.560,0:59:11.770 kann ich dir nicht sagen. 0:59:11.770,0:59:15.630 Herald: Gut, dann, wir sind so ganz knapp[br]an der Zeit, aber du darfst deine Frage 0:59:15.630,0:59:17.050 auf jeden Fall stellen, bitte! 0:59:17.050,0:59:20.520 Frage: Ist auch nur eine ganz kurze,[br]schnelle Frage. Gibt es einen Schutz 0:59:20.520,0:59:24.460 gegen DDoS, dass ich irgendwie das[br]Netzwerk mit falschen Transaktionen 0:59:24.460,0:59:27.890 bombardiere, und dann bricht alles[br]zusammen, gibt es da irgendwie 0:59:27.890,0:59:29.120 einen Schutz dagegen? 0:59:29.120,0:59:31.930 vimja: Ja, das war ja ganz interessant.[br]Das hat es glaube ich vor über einem Jahr 0:59:31.930,0:59:35.050 gegeben, bei Bitcoin, dass das passiert[br]ist, und die waren sich dann 0:59:35.050,0:59:38.630 nicht so ganz einig in der Community,[br]weil die mögen sich sowieso nicht mehr, 0:59:38.630,0:59:42.270 und ‚kriegen‘ nur miteinander, die waren[br]sich da nicht so ganz einig, ob das jetzt 0:59:42.270,0:59:46.391 ein Test war, oder ob das ein DDoS war.[br]Und das Interessante daran ist ja, 0:59:46.391,0:59:51.630 dass es ja tatsächlich Geld kostet, eine[br]Transaktion zu machen. Also du zahlst 0:59:51.630,0:59:55.790 zuerst eine Transaction-Gebühr, und der[br]Schutz sollte eigentlich, hoffentlich, 0:59:55.790,0:59:59.520 sein, dass das da zu teuer ist.[br]Aber offenbar gibt es immer noch 0:59:59.520,1:00:04.340 so viele Bitcoin-Millionäre, die einfach[br]Bitcoins haben zum Davonschmeißen, 1:00:04.340,1:00:08.200 und die dann sowas tun können. Es[br]wird auf jeden Fall an irgendwelchen 1:00:08.200,1:00:11.770 Schutzmechanismen gearbeitet, aber[br]was das ist… zuckt mit den Schultern 1:00:11.770,1:00:15.530 Also was es gibt, in Bitcoin,[br]ist dieses Replace-by-Fee, 1:00:15.530,1:00:22.890 damit die Transaction-Gebühr nach[br]der Veröffentlichung der Transaktion 1:00:22.890,1:00:25.920 anschließend noch erhöht werden[br]kann. Und damit kannst du halt… 1:00:25.920,1:00:29.030 wenn du jetzt siehst, es kommen sehr viele[br]DDoS-Transaktionen rein, kannst du halt 1:00:29.030,1:00:33.640 im Nachhinein die Transaction-Gebühr[br]erhöhen, und das dadurch den Minern 1:00:33.640,1:00:38.480 quasi schmackhaft machen, deine[br]valide Transaktion zu includen. 1:00:38.480,1:00:43.600 Dieses Replace-by-Fee, dieses RBF,[br]ist aber sehr stark umstritten, und 1:00:43.600,1:00:49.580 wird auch standardmäßig nicht[br]aktiviert von der Client-Software. 1:00:49.580,1:00:56.290 Herald: Gut, dann danke vimja, für diese[br]großartige Einführung in die Blockchain! 1:00:56.290,1:01:01.030 Beifall 1:01:01.030,1:01:05.070 Abspannmusik 1:01:05.070,1:01:24.901 Untertitel erstellt von c3subtitles.de[br]im Jahr 2017. Mach mit und hilf uns!