1
00:00:00,000 --> 00:00:13,890
<i>33C3-Vorspannmusik</i>

2
00:00:13,890 --> 00:00:20,810
Herald: Gut, dann machen wir
weiter mit dem nächsten Vortrag.

3
00:00:20,810 --> 00:00:24,509
Der ist von vimja, der ist
Informatikstudent aus Bern in der Schweiz,

4
00:00:24,509 --> 00:00:28,740
und er arbeitete bzw. er
beschäftigte sich mit Bitcoin

5
00:00:28,740 --> 00:00:32,890
und Ethereum, und schrieb seine
Bachelorarbeit über die Suche

6
00:00:32,890 --> 00:00:38,210
nach Informationen in der Bitcoin-
Blockchain. Und da macht es total Sinn,

7
00:00:38,210 --> 00:00:43,120
dass der uns jetzt eine Einführung
zu Blockchains präsentieren wird.

8
00:00:43,120 --> 00:00:45,580
Ein großer Applaus für vimja!

9
00:00:45,580 --> 00:00:50,030
<i>Applaus mit Pfeifen und Jubel</i>
Das ist deine Bühne!

10
00:00:50,030 --> 00:00:56,519
<i>weiterhin Applaus</i>

11
00:00:56,519 --> 00:00:58,920
vimja: Toll, das ist jetzt
gerade kaputtgegangen.

12
00:00:58,920 --> 00:01:05,460
<i>Gelächter</i>

13
00:01:05,460 --> 00:01:08,000
So ist es besser.

14
00:01:08,000 --> 00:01:13,230
<i>Applaus</i>
Danke.

15
00:01:13,230 --> 00:01:19,980
Genau, das geht jetzt
natürlich auch nicht.

16
00:01:19,980 --> 00:01:22,240
Mache ich es halt von Hand.

17
00:01:22,240 --> 00:01:27,740
Ist vermutlich, weil ihr alle das Wi-Fi
braucht, geht das 2,4-GHz-Band nicht mehr.

18
00:01:27,740 --> 00:01:31,570
Ja das hat er euch ja alles
schon gesagt, der Herald.

19
00:01:31,570 --> 00:01:34,680
In dieser Zeit, in der ich mich
mit Blockchains befasst habe,

20
00:01:34,680 --> 00:01:39,270
durfte ich natürlich sehr viele
sehr interessante Dinge lernen,

21
00:01:39,270 --> 00:01:41,830
und ich möchte jetzt heute abend
einen Teil dieses Wissens

22
00:01:41,830 --> 00:01:48,810
an euch weitergeben. Genau.

23
00:01:48,810 --> 00:01:52,710
Das Ganze ist natürlich ein sehr komplexes
Thema, das viele komplizierte Dinge

24
00:01:52,710 --> 00:01:56,120
enthält, und deshalb fangen wir jetzt mit
etwas sehr einfachem an, was wir alles

25
00:01:56,120 --> 00:01:59,850
kennen. Und zwar herkömmliche
Besitzsysteme – also Systeme,

26
00:01:59,850 --> 00:02:04,100
die ausdrücken wem etwas gehört. Und,
eigentlich, mit der Erkenntnis, dass man

27
00:02:04,100 --> 00:02:11,190
all diese Besitzsysteme als
Zustandsübergangssysteme darstellen kann.

28
00:02:11,190 --> 00:02:16,019
Das gilt sowohl für Finanzsysteme,
die wir haben um Geld zu verwalten,

29
00:02:16,019 --> 00:02:20,090
als auch etwa für Grundstücke, also
Systeme mit denen wir verwalten,

30
00:02:20,090 --> 00:02:23,490
wem ein Grundstück gehört.

31
00:02:23,490 --> 00:02:27,520
Das Mapping funktioniert dann in etwa
so, dass wir sagen, der Zustand ist

32
00:02:27,520 --> 00:02:33,510
die Sammlung der Informationen wem
was gehört. Und jedes Übertragen

33
00:02:33,510 --> 00:02:37,720
eines Besitzes ist eine Transition,
die zu einem neuen Zustand führt.

34
00:02:37,720 --> 00:02:41,760
Also am Beispiel eines finanziellen
Systems sagen wir, der Zustand ist

35
00:02:41,760 --> 00:02:45,879
die Sammlung aller Konten, die es gibt.
Das drückt für jede Person aus,

36
00:02:45,879 --> 00:02:51,230
wieviel Geld ihr gehört. Und ein Übergang
ist, wenn jemand eine Transaktion macht,

37
00:02:51,230 --> 00:02:54,160
also Geld überweist, von einem Konto
zu einem anderen, dann führt das

38
00:02:54,160 --> 00:02:58,440
zu einem neuen Zustand.
So, das sehen wir hier abgebildet

39
00:02:58,440 --> 00:03:02,280
mit Grundstücken. Wir sehen hier, der
Zustand, der enthält diese Information,

40
00:03:02,280 --> 00:03:06,760
wem die Grundstücke gehören.
Und dann verkauft der Bob

41
00:03:06,760 --> 00:03:10,890
sein Grundstück Nr. 42 an Alice und
das führt zu einem neuen Zustand.

42
00:03:10,890 --> 00:03:15,660
Ich habe da den Unterschied markiert,
damit der eindeutig sichtbar ist.

43
00:03:15,660 --> 00:03:20,410
Nun, in all diesen Systemen ist es sehr
wichtig, dass sich alle Teilnehmer des

44
00:03:20,410 --> 00:03:26,150
Systems auf einen Zustand einigen können.
Dass sie sich einig sind, wem was gehört.

45
00:03:26,150 --> 00:03:30,050
Denn wenn sie das nicht können, sind
Angriffe auf das System möglich,

46
00:03:30,050 --> 00:03:32,950
insbesondere der sogenannte
Double-Spend-Angriff,

47
00:03:32,950 --> 00:03:37,840
der in der Blockchain-Welt bekannt und
gefürchtet ist. Und was bedeutet das?

48
00:03:37,840 --> 00:03:41,440
Das ist ganz einfach, wenn jemand etwas
zweimal ausgibt. Bei Geld ist das ein

49
00:03:41,440 --> 00:03:45,310
wenig abstrakt (also wie gibt man zweimal
dasselbe Geld aus), aber bei Grundstücken

50
00:03:45,310 --> 00:03:48,990
ist das ganz einfach. Stellen wir uns vor,
jemand verkauft dasselbe Grundstück

51
00:03:48,990 --> 00:03:54,880
zweimal. Das ist natürlich kriminell
und darf nicht vorkommen.

52
00:03:54,880 --> 00:03:57,850
Schauen wir uns jetzt mal an wie
das funktioniert. Stellen wir uns vor,

53
00:03:57,850 --> 00:04:01,940
Malroy hat ein schönes Grundstück,
das Grundstück Nr. 5. Und sowohl Alice

54
00:04:01,940 --> 00:04:05,700
als auch Bob möchten gerne das
Grundstück kaufen. Und Malroy

55
00:04:05,700 --> 00:04:10,020
wird jetzt versuchen, das an beide zu
verkaufen. Also trifft er sich mit Alice.

56
00:04:10,020 --> 00:04:13,761
Das ist also jetzt der aktuelle Zustand.
Wir haben gesehen, das Grundstück Nr. 5

57
00:04:13,761 --> 00:04:20,430
gehört hier dem Malroy. Der trifft sich
mit Alice. Und er verkauft es an Alice.

58
00:04:20,430 --> 00:04:24,550
Er überweist ihr das Grundstück. Wir sehen
diese Transition – überweist das Grundstück

59
00:04:24,550 --> 00:04:29,129
von Malroy an Alice. Und im neuen Zustand
gehört es jetzt der Alice. So, der Bob,

60
00:04:29,129 --> 00:04:31,990
der hat davon nichts mitgekriegt.
Irgendwie – Bob und Alice wissen

61
00:04:31,990 --> 00:04:36,300
immer noch nicht recht wie man sicher
miteinander kommuniziert. Und deshalb

62
00:04:36,300 --> 00:04:39,199
weiß der Bob jetzt nichts davon, dass
die Alice das Grundstück gekauft hat.

63
00:04:39,199 --> 00:04:43,680
Er denkt, das Grundstück gehört immer noch
Malroy. Also trifft er sich mit Malroy.

64
00:04:43,680 --> 00:04:47,939
Und auch er einigt sich mit Malroy auf
einen Preis. Und Malroy tut jetzt so,

65
00:04:47,939 --> 00:04:52,710
als würde er den Besitz des
Grundstücks an Bob übertragen.

66
00:04:52,710 --> 00:04:56,460
Und für Bob sieht die Welt jetzt so
aus, d.h. Bob ist überzeugt, das ist

67
00:04:56,460 --> 00:05:00,339
der korrekte Zustand des Systems.
Da haben wir natürlich ein Problem,

68
00:05:00,339 --> 00:05:03,290
weil Bob und Alice, die sind sich
jetzt gar nicht einig darüber,

69
00:05:03,290 --> 00:05:07,499
wem das Grundstück gehört. Ja, Malroy
ist natürlich abgehauen mit dem Geld.

70
00:05:07,499 --> 00:05:10,980
Und das System ist kaputt, weil Bob
und Alice die können nicht mehr

71
00:05:10,980 --> 00:05:14,690
miteinander handeln. Und auch wenn
jetzt jemand anderes das Grundstück

72
00:05:14,690 --> 00:05:18,749
kaufen möchte: Bei wem kauft er es
denn jetzt? Was ist denn rechtmäßig?

73
00:05:18,749 --> 00:05:23,859
Nun, in der Welt der Grundstücke gibt
es dafür eine ganz einfache Lösung,

74
00:05:23,859 --> 00:05:27,560
nämlich das Grundbuchamt. Und das
Grundbuchamt fungiert eigentlich

75
00:05:27,560 --> 00:05:33,310
als zentrale Referenzstelle,
die den Zustand verwaltet,

76
00:05:33,310 --> 00:05:37,460
und alle Änderungen verwaltet. Jedesmal
wenn jemand ein Grundstück verkauft,

77
00:05:37,460 --> 00:05:42,089
muss das über das Grundbuchamt erledigt
werden. Das Grundbuchamt überprüft,

78
00:05:42,089 --> 00:05:46,020
dass das überhaupt zulässig ist, ob das
Grundstück wirklich der Person gehört

79
00:05:46,020 --> 00:05:50,169
und führt das dann nach. Und so kann das
Grundbuchamt diese einfachen Angriffe

80
00:05:50,169 --> 00:05:58,960
verhindern. Diese Lösung
funktioniert auch für Finanzsysteme.

81
00:05:58,960 --> 00:06:02,770
Also wenn wir an Banken denken, wenn ich
ein Konto habe, da ist dann halt die Bank

82
00:06:02,770 --> 00:06:07,289
die zentrale Autorität, welche den Zustand
verwaltet. Für jede… jedesmal,

83
00:06:07,289 --> 00:06:11,499
wenn ich eine Transaktion mache, also Geld
überweise, überprüft die Bank vorher,

84
00:06:11,499 --> 00:06:15,759
ob ich wirklich das nötige Geld dazu
habe. Und dann wird mein Kontostand

85
00:06:15,759 --> 00:06:22,499
nachgeführt. Und die verwaltet so
für alle Teilnehmer den Zustand.

86
00:06:22,499 --> 00:06:26,919
Und das funktioniert eigentlich erstaunlich
gut. Nun wollen wir ein System, mit dem

87
00:06:26,919 --> 00:06:31,229
wir Zahlungen über das Internet abwickeln
können. Und wir hätten gerne, dass das

88
00:06:31,229 --> 00:06:34,849
dezentral ist. Weil, wenn das nicht
dezentral ist, dann kann natürlich

89
00:06:34,849 --> 00:06:39,909
eine zentrale Autorität das System
zensieren und manipulieren.

90
00:06:39,909 --> 00:06:43,539
Und eine zentrale Stelle kann angegriffen
werden. Ich denke, wir haben das alle

91
00:06:43,539 --> 00:06:47,719
in den letzten Jahren beobachten müssen,
wie Paypal sehr einfach willkürlich

92
00:06:47,719 --> 00:06:52,650
Konten sperrt, und das System zensiert.
So, und deshalb brauchen wir ein

93
00:06:52,650 --> 00:06:56,250
besseres System, eine bessere
Lösung für das Internetzeitalter.

94
00:06:56,250 --> 00:06:59,840
Und diese bessere Lösung ist
natürlich die ‚Blockchain‘.

95
00:06:59,840 --> 00:07:05,760
Die Blockchain bringt einige ganz
unglaubliche Eigenschaften mit sich.

96
00:07:05,760 --> 00:07:09,529
Die Blockchain braucht keine zentrale
Stelle um den Zustand zu verwalten.

97
00:07:09,529 --> 00:07:12,930
Die Teilnehmer des Systems müssen sich
gegenseitig nicht vertrauen, sie müssen

98
00:07:12,930 --> 00:07:16,419
sich gegenseitig nicht kennen. Sie müssen
nicht einmal wissen, wieviele Leute

99
00:07:16,419 --> 00:07:19,990
denn eigentlich da teilnehmen. Und
trotzdem können die sich alle immer

100
00:07:19,990 --> 00:07:25,469
auf einen Zustand des Systems einigen.

101
00:07:25,469 --> 00:07:27,960
Ich werde das jetzt demonstrieren,
die Regeln, die wir brauchen

102
00:07:27,960 --> 00:07:32,250
um das zu ermöglichen. Anhand
einer sehr einfachen Blockchain,

103
00:07:32,250 --> 00:07:35,759
die in diesem ersten Kapitel auch
noch keinen Proof-of-Work hat. Also

104
00:07:35,759 --> 00:07:39,149
diese erste Blockchain wird noch
angreifbar sein. Und ich werde auch

105
00:07:39,149 --> 00:07:42,970
zeigen wie es geht. Und erst im nächsten
Kapitel dann werde ich erklären,

106
00:07:42,970 --> 00:07:47,820
welche Maßnahmen wir ergreifen
müssen, um Angriffe zu verhindern.

107
00:07:47,820 --> 00:07:51,659
Und das Ganze fängt an mit dem Netzwerk
welches wir nutzen. Also wir sagen quasi,

108
00:07:51,659 --> 00:07:55,039
wir sind alle diese Leute, und wir würden
gerne miteinander Transaktionen machen

109
00:07:55,039 --> 00:07:59,759
können. Und zuerst einigen wir uns
alle auf einen Ursprungszustand.

110
00:07:59,759 --> 00:08:03,319
Damit fangen wir an. Wir sagen z.B.
„am Anfang gehört allen nichts“.

111
00:08:03,319 --> 00:08:08,429
Das ist ein leerer Zustand. Und dann
brauchen wir ein p2p-Netzwerk.

112
00:08:08,429 --> 00:08:13,529
Und jedesmal wenn jemand Geld überweist
an jemand anderes, dann veröffentlicht er

113
00:08:13,529 --> 00:08:17,490
die Transaktion in diesem Netzwerk,
und das Netzwerk leitet die Transaktion

114
00:08:17,490 --> 00:08:21,949
solange an alle Teilnehmer weiter,
bis alle Teilnehmer diese Transaktion

115
00:08:21,949 --> 00:08:27,169
gesehen haben. Das bringt
natürlich viele Probleme mit sich.

116
00:08:27,169 --> 00:08:29,529
Das Netzwerk ist irgendwie nicht
synchronisiert, nicht alle Leute

117
00:08:29,529 --> 00:08:34,510
sehen die gleichen Transaktionen, die
Reihenfolge der Transaktionen ist unklar.

118
00:08:34,510 --> 00:08:37,940
Leute werden versuchen das anzugreifen
– das wird dazu führen, dass es

119
00:08:37,940 --> 00:08:42,458
Transaktionen gibt die nicht miteinander
kompatibel sind. Und irgendwie

120
00:08:42,458 --> 00:08:45,310
Transaktionen, die abhängen von
nicht-kompatiblen Transaktionen und

121
00:08:45,310 --> 00:08:49,790
dann auch wieder nicht kompatibel sind.
Das ist ein riesengroßes Durcheinander da.

122
00:08:49,790 --> 00:08:52,370
Und deshalb brauchen wir jetzt
eine Möglichkeit, wie wir uns alle

123
00:08:52,370 --> 00:08:57,180
auf einen Zustand, auf einen Konsens
einigen können. Und – wie gesagt –

124
00:08:57,180 --> 00:09:00,790
das ist jetzt die ‚Blockchain‘.

125
00:09:00,790 --> 00:09:04,420
Und wir definieren einige Regeln,
die wir anwenden um uns zu einigen.

126
00:09:04,420 --> 00:09:08,240
Wir sagen, wir gruppieren die Transaktionen
die vorher so lose auf dem Netzwerk waren

127
00:09:08,240 --> 00:09:13,470
zu Blöcken. Die Blöcke hängen alle
voneinander ab. Wir sagen dann auch,

128
00:09:13,470 --> 00:09:17,780
der aktuelle Zustand des Netzwerks ist das
Ende der längsten Kette zusammenhängender

129
00:09:17,780 --> 00:09:22,720
Blöcke. Und die Blöcke müssen einige
Kriterien erfüllen. Ich habe das da…

130
00:09:22,720 --> 00:09:26,940
also das ist jetzt quasi der Ur… der
leere Zustand, mit dem wir beginnen.

131
00:09:26,940 --> 00:09:32,300
Und da kommen da Transaktionen
über das Netzwerk. Und irgendwann

132
00:09:32,300 --> 00:09:34,950
macht jemand einen Block der diese
Transaktionen zusammenfasst. Und jetzt

133
00:09:34,950 --> 00:09:39,810
sehen wir am Ende dieses Blocks ist
der Zustand. Wenn ich diesen Zustand

134
00:09:39,810 --> 00:09:43,110
nachvollziehen will dann nehme ich den
leeren Ursprungszustand, und dann

135
00:09:43,110 --> 00:09:47,080
jede Transaktion aus dem ersten Block,
und dann wende ich diese Transaktionen,

136
00:09:47,080 --> 00:09:52,170
eine nach der anderen, auf den Zustand
an, und dann erhalte ich den Endzustand.

137
00:09:52,170 --> 00:09:55,421
Mit der Zeit kommen
neue Transaktionen rein

138
00:09:55,421 --> 00:10:00,140
über das Netzwerk. Und diese Transaktionen
werden nicht Teil des Zustands

139
00:10:00,140 --> 00:10:02,950
– wir haben ja gesagt der Zustand ist das
Ende der längsten Kette von Blöcken,

140
00:10:02,950 --> 00:10:06,270
und die sind in keinem Block. Erst wenn
jemand einen Block daraus macht,

141
00:10:06,270 --> 00:10:09,890
werden die Teil des Zustands.
Wir sehen auch, die Blöcke hängen jeweils

142
00:10:09,890 --> 00:10:13,540
voneinander ab, die haben so einen Pfeil,
der sie miteinander verbindet, also

143
00:10:13,540 --> 00:10:18,590
jeder Block zeigt auf den vorhergehenden
Block, und bildet so eben diese Kette

144
00:10:18,590 --> 00:10:23,650
von Blöcken. Nun, jetzt versucht trotzdem
jemand da eine bösartige Transaktion

145
00:10:23,650 --> 00:10:27,810
zu machen, die mit den anderen nicht
kompatibel ist. Da macht jemand

146
00:10:27,810 --> 00:10:32,000
einen Block daraus. Und jetzt sagen
wir aber einfach, Blöcke, die

147
00:10:32,000 --> 00:10:35,470
Transaktionen enthalten welche sich
widersprechen sind nicht valide.

148
00:10:35,470 --> 00:10:38,360
Der Block, den kann zwar jemand
erstellen, aber wir sagen dann, das ist

149
00:10:38,360 --> 00:10:42,180
kein valider Block, der wird vom Netzwerk
nicht akzeptiert. Und der wird auch

150
00:10:42,180 --> 00:10:46,450
nicht Teil des Zustands. Also wenn jemand
einen Block bauen will und eine dieser

151
00:10:46,450 --> 00:10:52,610
Transaktionen enthält, dann muss sich
derjenige der den Block erstellt

152
00:10:52,610 --> 00:10:56,090
entscheiden welche der Transaktionen
denn jetzt enthalten sein sollen

153
00:10:56,090 --> 00:11:00,280
in dem Block. Und die anderen lässt er
außen vor. Für welche er sich entscheidet,

154
00:11:00,280 --> 00:11:04,660
das ist dem Typen ganz allein überlassen.
Er kann das selber entscheiden was er da

155
00:11:04,660 --> 00:11:10,690
reinpacken will. Dann kommen mit
der Zeit neue Transaktionen rein.

156
00:11:10,690 --> 00:11:14,300
Und jetzt könnte es sein, dass jemand so
einen Block Nummer 4 macht, welcher

157
00:11:14,300 --> 00:11:18,730
jetzt trotzdem wieder die böse Transaktion
enthält. Und dann sagen wir aber einfach,

158
00:11:18,730 --> 00:11:21,911
Blöcke welche Transaktionen enthalten,
welche nicht kompatibel sind

159
00:11:21,911 --> 00:11:25,450
mit Transaktionen in älteren Blöcken sind
auch ungültig, und der Block wird auch

160
00:11:25,450 --> 00:11:29,870
nicht Teil des Zustands. So. Was aber
gültig ist, ist jemand der einen Block

161
00:11:29,870 --> 00:11:33,880
Nummer 3 macht, der so aussieht. Und jetzt
haben wir das Problem: Wir haben gesagt,

162
00:11:33,880 --> 00:11:36,640
der Zustand ist die längste Kette von
Blöcken. Hier ist jetzt der Zustand

163
00:11:36,640 --> 00:11:40,370
nicht mehr eindeutig definiert und da muss
jetzt halt jeder Teilnehmer des Netzwerkes

164
00:11:40,370 --> 00:11:44,960
selbst entscheiden wie er damit umgeht,
was er jetzt als Zustand anerkennt.

165
00:11:44,960 --> 00:11:48,240
So, aber dann kommen halt neue
Transaktionen wieder rein. Und irgendwann

166
00:11:48,240 --> 00:11:52,590
baut jemand einen Block Nummer 4, der
diese Transaktion enthält. Und dadurch,

167
00:11:52,590 --> 00:11:57,920
dass der Block Nr. 4 auf den vorherigen
Block Nr. 3 verweist, ist es jetzt klar,

168
00:11:57,920 --> 00:12:01,530
von welchem Block der abhängt.
Und damit ist die Kette auch wieder klar,

169
00:12:01,530 --> 00:12:06,300
und die längste Kette wird wieder zum
Zustand. So. Jetzt habe ich gesagt,

170
00:12:06,300 --> 00:12:09,830
diese Blockchain die ich jetzt beschrieben
habe hat keinen Proof-of-Work und folglich

171
00:12:09,830 --> 00:12:14,510
ist sie angreifbar für ein double-spend.
Sagen wir Malroy würde gerne

172
00:12:14,510 --> 00:12:19,050
ein Fahrrad klauen. Er geht da so in den
Fahrradladen von Alice, und möchte dort

173
00:12:19,050 --> 00:12:23,510
gerne ein Fahrrad kaufen, das kostet
jetzt 1000 Euro in dem Beispiel.

174
00:12:23,510 --> 00:12:26,170
Ich werde jetzt… hier habe ich
die Darstellung etwas geändert,

175
00:12:26,170 --> 00:12:30,370
diese Vierecke mit Pfeilen dran, das sind
jetzt halt einfach Blöcke. Ich werde

176
00:12:30,370 --> 00:12:34,570
nicht mehr jede Transaktion einzeln
zeichnen. Und die sehen den Zustand,

177
00:12:34,570 --> 00:12:39,110
wie er da ist. Da sind all die Konten
aufgeführt, unter anderem diejenigen

178
00:12:39,110 --> 00:12:45,070
von Alice und Malroy. So.
Malroy geht also in den Laden,

179
00:12:45,070 --> 00:12:51,340
sucht sich das [Fahrrad] aus, geht zum
Tresen und macht dort die Transaktion

180
00:12:51,340 --> 00:12:56,880
an Alice. Und diese Transaktion wird
übers Netzwerk zu Alice weitergeleitet.

181
00:12:56,880 --> 00:13:00,480
Sie sieht die Transaktion, aber da sie
noch nicht Teil eines Blockes ist,

182
00:13:00,480 --> 00:13:04,260
ist sie auch noch nicht Teil des Zustands.
Irgendwann aber erstellt jemand halt

183
00:13:04,260 --> 00:13:07,880
einen Block der diese Transaktion enthält.
Die ist jetzt Teil des Zustandes.

184
00:13:07,880 --> 00:13:12,760
Wir sehen im Zustand des Systems,
dass Alice das Geld erhalten hat.

185
00:13:12,760 --> 00:13:17,130
Sie gibt das Fahrrad an Malroy, und der
fährt davon. Neue Blöcke kommen dazu.

186
00:13:17,130 --> 00:13:20,860
Und jetzt startet Malroy den Angriff.
Und was Malroy macht, er erstellt

187
00:13:20,860 --> 00:13:25,230
eine alternative Transaktion, die dasselbe
Geld überweist, diesmal aber nicht

188
00:13:25,230 --> 00:13:30,260
an Alice sondern an sich selbst. Genauer:
an ein zweites Konto das ebenfalls ihm

189
00:13:30,260 --> 00:13:36,510
gehört. Und er erstellt einen alternativen
Block, der diese Transaktion enthält.

190
00:13:36,510 --> 00:13:40,830
Und dann erstellt er ganz viele neue
Blöcke die davon abhängen. Solange,

191
00:13:40,830 --> 00:13:44,670
bis seine Kette von Blöcken länger
ist als die anderen, also die Kette,

192
00:13:44,670 --> 00:13:49,570
die zur Zeit auf dem Netzwerk ist. Und
dann veröffentlicht er die gesamte Kette

193
00:13:49,570 --> 00:13:53,540
auf dem Netzwerk. Und jetzt ist seine
Kette die längste Kette. Die wird

194
00:13:53,540 --> 00:13:58,380
vom Netzwerk als Zustand anerkannt. Und
in diesem Zustand hat er das Geld erhalten.

195
00:13:58,380 --> 00:14:02,210
Alice hat das Geld nicht erhalten. Und
Malroy hat das Fahrrad erfolgreich

196
00:14:02,210 --> 00:14:05,720
gestohlen. So, das hat also funktioniert.

197
00:14:05,720 --> 00:14:09,650
Wir müssen das verhindern. Das
Problem weshalb Malroy diesen Angriff

198
00:14:09,650 --> 00:14:13,780
machen konnte ist natürlich, dass er in
einer sehr kurzen Folge viele Blöcke

199
00:14:13,780 --> 00:14:18,230
erstellen konnte. Also das Problem ist
eigentlich, es ist zu einfach neue Blöcke

200
00:14:18,230 --> 00:14:23,250
zu erstellen. Also machen wir es halt
schwieriger, neue Blöcke zu erstellen.

201
00:14:23,250 --> 00:14:27,030
Und dazu sagen wir, für jeden Block
der erstellt wird, muss eine Aufgabe

202
00:14:27,030 --> 00:14:33,980
gelöst werden, eine Challenge.
Und um diese Challenge zu erstellen,

203
00:14:33,980 --> 00:14:40,120
muss man halt Zeit, und Rechenzeit
aufwenden. Die Lösung für diese Aufgabe

204
00:14:40,120 --> 00:14:45,161
nennen wir den Proof-of-Work. Und den
Prozess um den Proof-of-Work zu erstellen

205
00:14:45,161 --> 00:14:49,560
nennen wir das ‚Mining‘. Und dann sagen
wir, zusammen mit jedem neuen Block

206
00:14:49,560 --> 00:14:53,800
muss der passende Proof-of-Work
veröffentlicht werden. Und nur Blöcke,

207
00:14:53,800 --> 00:14:58,210
welche einen passenden Proof-of-Work haben
werden vom Netzwerk als Teil des Zustands

208
00:14:58,210 --> 00:15:03,300
anerkannt. Jetzt funktioniert das
Erstellen neuer Blöcke etwas anders.

209
00:15:03,300 --> 00:15:06,810
Und zwar ist es jetzt so, dass ein Block
nicht mehr einfach entsteht, sondern

210
00:15:06,810 --> 00:15:10,650
ein ‚Miner‘ muss daran arbeiten. Jeder
Miner arbeitet natürlich für sich selbst

211
00:15:10,650 --> 00:15:14,540
daran, einen neuen Block zu erstellen.
Wir sehen hier, der Block an dem der Miner

212
00:15:14,540 --> 00:15:19,991
arbeitet, ist hier so gestrichelt
markiert. Und dann, wenn der Miner

213
00:15:19,991 --> 00:15:23,920
daran arbeitet, kommen neue Transaktionen
rein. Und irgendwann gelingt es dem Miner

214
00:15:23,920 --> 00:15:27,910
den Block fertigzustellen. In dem Moment
veröffentlicht er den Block zusammen mit

215
00:15:27,910 --> 00:15:31,440
dem Proof-of-Work im Netzwerk. Der wird
vom Netzwerk anerkannt, und der Miner

216
00:15:31,440 --> 00:15:39,740
beginnt sofort an einem neuen Block zu
arbeiten, und das geht dann halt so weiter.

217
00:15:39,740 --> 00:15:43,990
Nun, die Funktion die wir brauchen um das
Erstellen der Blöcke schwierig zu machen

218
00:15:43,990 --> 00:15:49,730
muss einige Bedingungen erfüllen. Sie
muss natürlich schwierig sein zu lösen.

219
00:15:49,730 --> 00:15:53,110
Dann muss aber… obwohl es lange gehen
muss die zu erstellen, muss es sehr

220
00:15:53,110 --> 00:15:56,580
einfach sein, das Ergebnis zu prüfen.
Also wenn ich einen Block erhalte, und

221
00:15:56,580 --> 00:16:00,460
den passenden Proof-of-Work, muss
ich – zack! – sofort sagen können,

222
00:16:00,460 --> 00:16:03,390
der Proof-of-Work ist gültig oder nicht,
weil ich will ja entscheiden, ob das

223
00:16:03,390 --> 00:16:07,500
Teil meines Zustandes
sein soll oder nicht.

224
00:16:07,500 --> 00:16:11,960
Und dann ist es wichtig, dass die
Funktion abhängt von genau dem Block,

225
00:16:11,960 --> 00:16:15,230
für den sie erstellt wird. Also der
Proof-of-Work soll nur genau

226
00:16:15,230 --> 00:16:19,140
für den einen Block gültig sein.
Das ist sehr wichtig, denn ansonsten

227
00:16:19,140 --> 00:16:23,589
könnte Malroy auf Vorrat über
mehrere Wochen hinweg einfach

228
00:16:23,589 --> 00:16:27,220
Proof-of-Works erstellen und dann die
einfach an einen Block ranflanschen,

229
00:16:27,220 --> 00:16:31,810
und so in kurzer Zeit trotzdem wieder
eine lange Kette erstellen. Wenn aber

230
00:16:31,810 --> 00:16:37,150
der Proof-of-Work direkt abhängig ist
vom Block für den er erstellt wird,

231
00:16:37,150 --> 00:16:40,150
dann muss Malroy mit dem Erstellen
des Proof-of-Work so lange warten,

232
00:16:40,150 --> 00:16:44,290
bis der vorhergehende Block bekannt
ist und damit auch ihm bekannt ist,

233
00:16:44,290 --> 00:16:47,360
was er jetzt in den neuen Block packt.

234
00:16:47,360 --> 00:16:52,010
Und dann soll es auch noch möglich sein,
die Schwierigkeit der Aufgabe zu variieren.

235
00:16:52,010 --> 00:16:56,110
Denn damit das System als stabiles
Finanzsystem funktioniert, möchte ich

236
00:16:56,110 --> 00:16:59,250
gerne wissen, wie lange es geht von
dem Moment wo ich eine Transaktion

237
00:16:59,250 --> 00:17:04,409
veröffentliche bis sie Teil des Zustandes
wird. Und wenn das Netzwerk

238
00:17:04,409 --> 00:17:08,000
sehr viel mehr Rechenkraft hat, dann
geht es plötzlich schneller, neue Blöcke

239
00:17:08,000 --> 00:17:11,179
zu erstellen und dann will ich diese
Schwierigkeit anpassen können, damit es

240
00:17:11,179 --> 00:17:16,660
wieder länger geht. Nun jetzt, wo
das Mining nicht mehr einfach ist,

241
00:17:16,660 --> 00:17:20,169
und es aufwendig ist, müssen wir irgendwie
einen Incentive haben, damit die Leute

242
00:17:20,169 --> 00:17:25,089
es auch tun – also irgendeinen Anstoß.
So und wir sagen halt, der Miner,

243
00:17:25,089 --> 00:17:29,020
dem es gelingt einen Block zu erstellen,
der bekommt eine Belohnung,

244
00:17:29,020 --> 00:17:34,350
den sogenannten ‚Block Reward‘, und wir
implementieren das, indem wir sagen,

245
00:17:34,350 --> 00:17:38,010
der Miner darf für sich selbst eine
zusätzliche Transaktion in den Block

246
00:17:38,010 --> 00:17:41,999
hineinpacken, und mit dieser Transaktion
überweist er sich selbst Geld

247
00:17:41,999 --> 00:17:45,809
aus dem Nichts heraus. Wo das
Geld herkommt: Es gibt eigentlich

248
00:17:45,809 --> 00:17:48,779
zwei Möglichkeiten, die populär sind.
Entweder sagen wir, das sind

249
00:17:48,779 --> 00:17:53,110
die Überweisungsgebühren der anderen
Transaktionen in dem Block.

250
00:17:53,110 --> 00:17:57,540
Oder dann sagen wir halt, das ist Geld,
welches neu geschaffen wird. Wir haben ja

251
00:17:57,540 --> 00:18:02,670
vorhin gesehen, wir haben einen leeren
Zustand als den Ursprungszustand definiert,

252
00:18:02,670 --> 00:18:06,069
und wenn wir das so tun, muss das
Geld, welches die Leute ausgeben,

253
00:18:06,069 --> 00:18:10,250
irgendwo herkommen. Und das ist halt eine
Möglichkeit, Geld in das System zu bringen,

254
00:18:10,250 --> 00:18:14,559
die nicht von einer zentralen Stelle
kontrolliert wird, und eigentlich

255
00:18:14,559 --> 00:18:21,290
eine faire Möglichkeit.
Etwas weiteres ist, dass…

256
00:18:21,290 --> 00:18:25,290
diese zusätzliche Transaktion macht
den Block natürlich individuell, denn

257
00:18:25,290 --> 00:18:29,770
jeder Miner wird das Geld an sich selbst
zu überweisen versuchen und, also,

258
00:18:29,770 --> 00:18:35,130
diese eine Transaktion wird für jeden
Miner anders sein. Und das stellt sicher,

259
00:18:35,130 --> 00:18:39,599
dass die alle an einem ein wenig anderen
Problem arbeiten. Wenn die alle

260
00:18:39,599 --> 00:18:43,659
versuchen würden, das genau selbe Problem
zu lösen, auf die genau selbe Art,

261
00:18:43,659 --> 00:18:47,809
dann würde es immer demjenigen als erstes
gelingen, der die meiste Rechenkraft hat,

262
00:18:47,809 --> 00:18:51,679
und das wollen wir nicht, denn dann würde
ja eine Person alle Blöcke erzeugen,

263
00:18:51,679 --> 00:18:54,570
und wir wollen ja, dass viele Personen
Blöcke erzeugen, damit das niemand

264
00:18:54,570 --> 00:18:59,830
zensieren kann. Dadurch, dass das Problem,
an welchem sie arbeiten, für jeden Miner

265
00:18:59,830 --> 00:19:02,749
etwas anders ist, gelingt es halt
zwischendurch auch jemandem

266
00:19:02,749 --> 00:19:06,879
mit weniger Rechenkraft, als erstes eine
Lösung zu finden. Und in der Praxis

267
00:19:06,879 --> 00:19:12,159
geht das dann ganz gut, dass wir sagen
können, wer 20% der Rechenkraft hat

268
00:19:12,159 --> 00:19:15,559
dem wird es auch in etwa einem Fünftel
der Fälle gelingen als erstes einen Block

269
00:19:15,559 --> 00:19:21,210
zu finden. Dann muss der Miner halt
noch entscheiden, an welchem Block

270
00:19:21,210 --> 00:19:25,399
er arbeiten will. Aber der Miner will ja…
also an welchem Ende der Kette…

271
00:19:25,399 --> 00:19:29,129
Wir haben vorhin gesehen, es kann sein,
dass diese Ketten mehrere Enden haben.

272
00:19:29,129 --> 00:19:33,730
Aber das ist ganz einfach, denn der Miner
will ja den Reward kriegen. Der Reward ist

273
00:19:33,730 --> 00:19:37,719
eine Transaktion, welche nur dann
Teil des Zustandes wird wenn es Teil

274
00:19:37,719 --> 00:19:40,740
in einem Block ist, wenn es Teil der
längsten Kette ist. Und der Block ist

275
00:19:40,740 --> 00:19:44,249
nur dann Teil der längsten Kette wenn
er an diesem Ende angesetzt wird.

276
00:19:44,249 --> 00:19:49,039
Also arbeiten alle Miner am Ende der
längsten Kette. So, jetzt habe ich

277
00:19:49,039 --> 00:19:52,970
versprochen, dass wir so den Double-Spend
verhindern können, von vorhin.

278
00:19:52,970 --> 00:19:57,389
Wollen wir mal gucken, ob das geht!
Das Szenario ist wieder dasselbe.

279
00:19:57,389 --> 00:20:03,290
Malroy will das Fahrrad klauen,
im Laden von Alice.

280
00:20:03,290 --> 00:20:08,760
Der Unterschied ist, dass das Netzwerk
arbeiten muss um die Blöcke zu erstellen.

281
00:20:08,760 --> 00:20:13,090
Und dann geht es wieder so vonstatten.
Malroy erstellt jetzt zwei Transaktionen.

282
00:20:13,090 --> 00:20:17,110
Eine, um das Geld der Alice zu überweisen.
Diese Transaktion macht er öffentlich

283
00:20:17,110 --> 00:20:20,550
im Netzwerk, damit die von allen gesehen
werden kann. Und eine Transaktion,

284
00:20:20,550 --> 00:20:25,330
um das Geld an sich selbst zu überweisen.
Die behält er vorläufig geheim. Dann wird

285
00:20:25,330 --> 00:20:29,350
der vorhergehende Block fertiggestellt,
und sofort fängt das Netzwerk an

286
00:20:29,350 --> 00:20:34,220
den nächsten Block zu erstellen. Das
Netzwerk enthält in dem Block natürlich

287
00:20:34,220 --> 00:20:37,750
die Transaktion von Malroy an Alice,
denn das ist ja die einzige Transaktion

288
00:20:37,750 --> 00:20:42,129
die dem Netzwerk bekannt ist. Und
Malroy arbeitet jetzt ganz alleine daran,

289
00:20:42,129 --> 00:20:47,579
den alternativen Block zu erstellen. In
dem die andere Transaktion enthalten ist.

290
00:20:47,579 --> 00:20:51,539
Jetzt ist es aber so: das Netzwerk hat
natürlich mehr Rechenkraft als Malroy

291
00:20:51,539 --> 00:20:56,659
allein. Der hat halt nicht so viele
Computer. Und deshalb wird das Netzwerk

292
00:20:56,659 --> 00:21:01,340
immer schneller sein darin, neue Blöcke
zu erstellen als Malroy. Malroys Kette

293
00:21:01,340 --> 00:21:06,169
wird nie die längste Kette, wird nie Teil
des Zustands. Und der Angriff wurde

294
00:21:06,169 --> 00:21:13,779
erfolgreich abgewehrt. Die einzige Art
und Weise wie Malroy gewinnen könnte,

295
00:21:13,779 --> 00:21:17,639
also wie Malroy den Angriff trotzdem
durchführen könnte, wäre, wenn er

296
00:21:17,639 --> 00:21:21,899
schneller Blöcke erstellen könnte als
das Netzwerk. Und das wird ihm aber

297
00:21:21,899 --> 00:21:25,909
nur dann gelingen, wenn er mehr als
50% der Rechenkraft im Netzwerk hätte.

298
00:21:25,909 --> 00:21:28,679
Denn dann wäre die Wahrscheinlichkeit,
dass er einen Block findet, höher

299
00:21:28,679 --> 00:21:33,469
als bei allen anderen Minern gemeinsam.
Und dann könnte er das tun. Und deshalb

300
00:21:33,469 --> 00:21:40,500
spricht man bei Bitcoin und anderen
Kryptowährungen von diesen 50%-Attacken.

301
00:21:40,500 --> 00:21:43,769
So, jetzt gibt es noch eine andere Art,
einen Double-Spend auszuführen. Das ist

302
00:21:43,769 --> 00:21:49,020
ein etwas schwierigerer Angriff.
Und er hat jetzt damit zu tun, wie

303
00:21:49,020 --> 00:21:53,429
das Peer-to-Peer-Netzwerk funktioniert,
das wir brauchen um die Transaktionen

304
00:21:53,429 --> 00:22:01,279
und Blöcke zu verteilen. Jetzt ist der
Angriff ein wenig schwieriger, also

305
00:22:01,279 --> 00:22:05,330
muss Malroy etwas wertvolleres stehlen.
Er geht zu Bob. Bob verkauft Autos.

306
00:22:05,330 --> 00:22:09,520
Er wird versuchen ein Auto zu stehlen.
Und um das zu tun, wird er versuchen

307
00:22:09,520 --> 00:22:13,210
die Verbindung von Bob mit dem
Peer-to-Peer-Netzwerk zu kontrollieren.

308
00:22:13,210 --> 00:22:17,260
Wir sehen hier, Bob ist mit dem Netzwerk
verbunden. Mit diesen drei Peers. Und

309
00:22:17,260 --> 00:22:21,710
Malroy hat zwei Möglichkeiten: entweder
er kontrolliert die Internetverbindung

310
00:22:21,710 --> 00:22:26,490
von Bob. Oder dann kontrolliert er
halt die drei Nodes, mit denen Bob

311
00:22:26,490 --> 00:22:30,400
verbunden ist. Wie realistisch das ist,
das will ich hier nicht diskutieren.

312
00:22:30,400 --> 00:22:34,820
Grundsätzlich ist es ja schon
vorstellbar. Und jetzt hat Malroy

313
00:22:34,820 --> 00:22:39,190
einige interessante Möglichkeiten. Er kann
jetzt nämlich kontrollieren, welche Blöcke

314
00:22:39,190 --> 00:22:43,330
und Transaktionen der Bob sieht.
Also Transaktionen und Blöcke,

315
00:22:43,330 --> 00:22:47,710
welche auf dem Netzwerk erscheinen,
kann Malroy quasi vor Bob geheimhalten.

316
00:22:47,710 --> 00:22:52,059
Und er kann Bob auch Transaktionen und
Blöcke präsentieren, die er dem Rest

317
00:22:52,059 --> 00:22:57,920
des Netzwerkes nicht präsentiert.
So, das ist der Angriff. Wir sehen,

318
00:22:57,920 --> 00:23:01,880
was das Netzwerk sieht.
Links und rechts, was Bob sieht.

319
00:23:01,880 --> 00:23:06,929
Am Anfang ist das natürlich an beiden
Orten gleich. Jetzt geht der Malroy

320
00:23:06,929 --> 00:23:12,230
zu dem Bob und wird das Auto kaufen.
Er macht eine Transaktion.

321
00:23:12,230 --> 00:23:15,850
Er macht zwei Transaktionen. Eine,
um das Geld an Bob zu überweisen.

322
00:23:15,850 --> 00:23:19,480
Diese schickt er nur an Bob. Und
versteckt sie vor dem Netzwerk.

323
00:23:19,480 --> 00:23:23,960
Und eine zweite Transaktion, mit der er
das Geld wieder an sich selbst überweist.

324
00:23:23,960 --> 00:23:28,480
Diese Transaktion veröffentlicht er im
Netzwerk. Jetzt wird das Netzwerk

325
00:23:28,480 --> 00:23:33,950
daran arbeiten, einen Block zu erstellen,
mit der Transaktion von Malroy zu Malroy.

326
00:23:33,950 --> 00:23:38,990
Weil das Netzwerk kennt keine andere
Transaktion. Und Malroy allein arbeitet

327
00:23:38,990 --> 00:23:44,750
daran einen Block zu erstellen, mit
dem er das Geld an Bob überweist.

328
00:23:44,750 --> 00:23:48,130
Natürlich wiederum, das Netzwerk hat viel
mehr Rechenkraft, es ist viel schneller

329
00:23:48,130 --> 00:23:51,549
darin, neue Blöcke zu erstellen. So, und

330
00:23:51,549 --> 00:23:56,149
schlussendlich gelingt es dann aber Bob
[Malroy!] trotzdem, einen Block zu erstellen.

331
00:23:56,149 --> 00:23:59,690
Und alle diese Blöcke die auf dem Netzwerk
erstellt wurden – muss man vielleicht

332
00:23:59,690 --> 00:24:05,350
noch sagen – die hält der Malroy vor Bob
geheim. Also, alle diesen neuen Blöcke,

333
00:24:05,350 --> 00:24:08,919
die hat Bob nie gesehen. Und deshalb
wird Bob diesen einen Block von Malroy

334
00:24:08,919 --> 00:24:13,269
als die längste Kette von Blöcken
akzeptieren. Und jetzt ist die Transaktion

335
00:24:13,269 --> 00:24:18,469
von Malroy an Bob Teil von Bobs
Zustand. Er gibt Malroy das Auto.

336
00:24:18,469 --> 00:24:25,210
Malroy fährt davon. Er beendet die
Attacke. Und jetzt verbindet sich Bob

337
00:24:25,210 --> 00:24:29,339
wieder ganz normal mit dem Netzwerk.
Die beiden Ketten werden synchronisiert.

338
00:24:29,339 --> 00:24:33,410
Und wir sehen, in der schlussendlich
resultierenden Kette hat Bob das Geld

339
00:24:33,410 --> 00:24:41,690
nicht erhalten. Malroy hat also das
Auto erfolgreich stehlen können.

340
00:24:41,690 --> 00:24:45,690
Das ist gar nicht gut. Jetzt hat ja dieser
Angriff funktioniert. Oder hat er das

341
00:24:45,690 --> 00:24:52,659
denn wirklich? Denn diesmal war der
Angriff erfolgreich. Aber Malroy musste

342
00:24:52,659 --> 00:24:56,519
jetzt dafür arbeiten. Er musste diesen
einen Block erstellen. Und das hat ihn

343
00:24:56,519 --> 00:25:00,400
viel Zeit gekostet. Natürlich kostet
es ihn auch irgendwie Rechenkraft,

344
00:25:00,400 --> 00:25:03,440
und den Strom den er braucht um seinen
Computer zu betreiben. Das wollen wir

345
00:25:03,440 --> 00:25:07,360
jetzt aber gar nicht mit einbeziehen.
Sondern wir schauen jetzt nach diesen

346
00:25:07,360 --> 00:25:11,509
Dings die Zeit gekostet. Denn der Malroy
hat ja einen Computer, den er braucht,

347
00:25:11,509 --> 00:25:15,760
um die Blöcke zu erstellen. Und dieser
Computer kann immer nur eines auf’s Mal

348
00:25:15,760 --> 00:25:20,290
tun. Entweder erstellt er jetzt diesen
Fake-Block für Bob, oder er erstellt

349
00:25:20,290 --> 00:25:25,789
richtige Blöcke auf die richtige Chain.
Er kann nicht beides auf’s Mal tun.

350
00:25:25,789 --> 00:25:31,750
So, und das macht es sehr, sehr
teuer diesen Angriff durchzuführen.

351
00:25:31,750 --> 00:25:35,759
Stellen wir uns vor… das sind jetzt einfach 
irgendwelche Annahmewerte für unser

352
00:25:35,759 --> 00:25:39,379
Netzwerk… die sind da halt in jeder
Kryptowährung etwas anders definiert.

353
00:25:39,379 --> 00:25:44,730
Sagen wir, unser Netzwerk erzeugt einen
Block alle zehn Minuten. Der Block Reward,

354
00:25:44,730 --> 00:25:49,700
welchen der Miner kriegt ist 1000 Euro.
Und Malroy hätte jetzt 20% der Rechenkraft

355
00:25:49,700 --> 00:25:54,691
des Netzwerkes. Wenn wir sagen 100% der
Rechenkraft erzeugt alle zehn Minuten.

356
00:25:54,691 --> 00:26:00,309
einen Block, dann erzeugt Malroy auf
sich alleine gestellt nur alle 50 Minuten

357
00:26:00,309 --> 00:26:06,409
einen Block. D.h. der Angriff auf Bob
dauert 50 Minuten. Nun, wenn aber Malroy

358
00:26:06,409 --> 00:26:12,000
50 Minuten lang minen würde, anstatt Bob
anzugreifen, dann würde er in dieser Zeit

359
00:26:12,000 --> 00:26:16,289
durchschnittlich 1000 Euro verdienen.
Er kann sich jetzt also entscheiden,

360
00:26:16,289 --> 00:26:22,590
entweder greift er Bob an und stiehlt das
23.000 Euro teure Auto, oder er verdient

361
00:26:22,590 --> 00:26:26,470
mit fairem Mining 1000 Euro.
Natürlich wird er dieses Auto immer noch

362
00:26:26,470 --> 00:26:31,810
stehlen wollen. Der Mechanismus, um
das zu verhindern ist aber ganz einfach.

363
00:26:31,810 --> 00:26:36,419
Wir sagen jetzt, Bob gibt dem
Malroy das Auto nicht, sobald Bob

364
00:26:36,419 --> 00:26:41,259
das Geld erhalten hat, sondern er
wartet dann noch einige Blöcke.

365
00:26:41,259 --> 00:26:43,849
Das sieht dann in etwa so aus. Ich habe
jetzt nicht genügend Blöcke gemalt,

366
00:26:43,849 --> 00:26:49,279
weil die da nicht Platz hatten.
Also sagen wir halt, wir sehen

367
00:26:49,279 --> 00:26:54,510
auf der rechten Seite, wo die
Transaktion Teil des Zustandes wird.

368
00:26:54,510 --> 00:26:59,609
Und in diesem Moment gibt halt der
Bob das Auto noch nicht an Malroy,

369
00:26:59,609 --> 00:27:05,179
sondern erst einige Blöcke später. Und
für jeden zusätzlichen Block, den Malroy

370
00:27:05,179 --> 00:27:08,039
erstellen muss, um Bob davon zu
überzeugen, dass das jetzt wirklich

371
00:27:08,039 --> 00:27:12,230
die richtige Kette ist, muss Malroy
weitere 50 Minuten aufwenden,

372
00:27:12,230 --> 00:27:17,580
und das kostet ihn jedesmal 1000 Euro.
Wenn also Bob sagt: „Ich warte 24 Blöcke

373
00:27:17,580 --> 00:27:22,530
bevor ich dem Malroy das Auto gebe“. Dann
ist der Angriff für Malroy plötzlich teurer

374
00:27:22,530 --> 00:27:27,360
als das Auto einen Wert hat. Und dadurch
kann Bob den Angriff verhindern.

375
00:27:27,360 --> 00:27:31,179
Malroy kann den zwar immer noch
durchführen, aber es ist schlicht einfach

376
00:27:31,179 --> 00:27:35,069
nicht interessant für Malroy das zu tun,
weil er mehr Geld macht wenn er

377
00:27:35,069 --> 00:27:44,739
in der selben Zeit mint. So. Jetzt haben
wir viel gesprochen über generische

378
00:27:44,739 --> 00:27:48,580
Konzepte von Blockchains. Jetzt will
ich noch etwas dazu sagen, wie das

379
00:27:48,580 --> 00:27:53,820
in Bitcoin implementiert wird. Zumindest
einige der Dinge. Schauen wir uns zuerst

380
00:27:53,820 --> 00:27:58,499
die Blöcke an. Und wir wissen ja, in der
Informatik mögen wir es, Bodys und Header

381
00:27:58,499 --> 00:28:03,340
zu definieren. Das tun wir überall,
irgendwie, in unseren Netzwerkprotokollen;

382
00:28:03,340 --> 00:28:07,799
in Nachrichten und Dateiformaten
sagen wir, der Body enthält den Inhalt,

383
00:28:07,799 --> 00:28:12,049
die eigentlichen Daten. Und der Header
enthält die Metadaten. Und genau dasselbe

384
00:28:12,049 --> 00:28:17,390
tun wir auch in unseren Blockchains. In
Bitcoin ist es so, der Body eines Blockes

385
00:28:17,390 --> 00:28:22,500
enthält alle Transaktionen. Die sind dort
geordnet aufgeführt. Der Miner muss

386
00:28:22,500 --> 00:28:29,130
einige Regeln einhalten, wenn er das
macht. Z.B. wenn Transaktion B

387
00:28:29,130 --> 00:28:32,460
von Transaktion A abhängt, die beide
im selben Block sind, müssen die

388
00:28:32,460 --> 00:28:36,190
in der richtigen Reihenfolge drin sein.
Aber sonst kann der die irgendwie

389
00:28:36,190 --> 00:28:40,350
dort einpacken. Aber sobald er das mal
gemacht hat, ist dann… diese Reihenfolge

390
00:28:40,350 --> 00:28:44,739
ist anschließend wichtig. Und die erste
Transaktion im Block ist jeweils

391
00:28:44,739 --> 00:28:47,750
die coin-based-Transaktion,
mit der sich der Miner

392
00:28:47,750 --> 00:28:53,019
den Block Reward überweist.

393
00:28:53,019 --> 00:28:59,000
Um jetzt diesen Body zu verbinden mit dem
Header nutzt Bitcoin einen Merkle Tree.

394
00:28:59,000 --> 00:29:02,249
Das ist ein binärer Baum,

395
00:29:02,249 --> 00:29:08,470
bei dem jeweils… der Node ist der
hash der konkatenierten Werte

396
00:29:08,470 --> 00:29:11,480
der Children des Nodes.

397
00:29:11,480 --> 00:29:15,049
Und Bitcoin verwendet fast überall…
wo Bitcoin Hashes macht,

398
00:29:15,049 --> 00:29:17,990
wenden sie einen – dhash nennen sie das,

399
00:29:17,990 --> 00:29:22,979
das ist ein double-sha256-Hash, also
so nennt sich der Hash eines Hashes

400
00:29:22,979 --> 00:29:27,700
eines Wertes, den sie nehmen. Das
sieht dann so aus: wir haben unseren Body

401
00:29:27,700 --> 00:29:31,539
des Blocks. Dann erstellen wir für
jede Transaktion den double-hash.

402
00:29:31,539 --> 00:29:34,710
Und dann beginnen wir damit, den Tree
zu erstellen. Also auf jeden Node,

403
00:29:34,710 --> 00:29:40,629
für jeden blauen Node konkatenieren wir
die beiden grünen Nodes, und machen dann

404
00:29:40,629 --> 00:29:44,410
den Hash davon. Das machen wir für
jede Ebene, bis wir schlussendlich

405
00:29:44,410 --> 00:29:49,850
beim Merkle Root angelangen, und der
wird dann Teil des Block Headers.

406
00:29:49,850 --> 00:29:53,879
Und der Block Header enthält diese Dinge:
die Version – das ist irgendwie

407
00:29:53,879 --> 00:29:58,480
eine arbitrary Nummer, die von den
Entwicklern von Zeit zu Zeit geändert wird,

408
00:29:58,480 --> 00:30:01,809
wenn sie irgendwie finden,
dass wird jetzt Zeit dafür.

409
00:30:01,809 --> 00:30:05,559
Dann den Previous Block Hash. Wir haben
gesehen, die Blöcke verweisen jeweils

410
00:30:05,559 --> 00:30:09,199
auf den vorhergehenden Block. Das ist
in Bitcoin so gelöst, dass der Header

411
00:30:09,199 --> 00:30:13,069
eines Blocks den Hash des vorhergehenden
Blocks enthält. Also auch hier wieder

412
00:30:13,069 --> 00:30:18,730
den double-hash. Den Merkle Root haben
wir bereits gesehen. Dann enthält

413
00:30:18,730 --> 00:30:22,460
der Block-Header noch einen Time Stamp.
Das sind ziemlich komplizierte Regeln,

414
00:30:22,460 --> 00:30:26,780
wonach dieser Time Stamp gebildet
wird, aber das ist egal. Das ist

415
00:30:26,780 --> 00:30:31,850
nicht so wichtig. Die ‚Difficulty‘ ist ein
Ausdruck dafür wie schwierig es war

416
00:30:31,850 --> 00:30:35,989
den Proof-of-Work für diesen bestimmten
Block zu definieren. Und die ‚Nonce‘

417
00:30:35,989 --> 00:30:43,579
ist ein Wert der gebraucht wird zum Minen.

418
00:30:43,579 --> 00:30:48,359
Ja und der Proof-of-Work in Bitcoin ist
nichts anderes als der Hash des Blocks.

419
00:30:48,359 --> 00:30:53,139
Und der muss dann eine Bedingung
erfüllen. Und zwar muss dieser Hash

420
00:30:53,139 --> 00:30:58,580
mit einer gewissen Anzahl Nullen beginnen.
Also ich nehme den Header des Blocks

421
00:30:58,580 --> 00:31:04,359
und bilde den double-hash davon.
Und dann müssen die ersten paar Bits

422
00:31:04,359 --> 00:31:08,559
von diesem Hash müssen Null sein. Und
wieviele Bits das sind, das ist dann eben

423
00:31:08,559 --> 00:31:13,470
die variable Schwierigkeit. Also wenn
ich mehr Nullen haben muss zu Beginn

424
00:31:13,470 --> 00:31:16,970
dann ist es schwieriger den Proof-of-Work
zu erstellen. Und bei weniger

425
00:31:16,970 --> 00:31:22,229
natürlich einfacher. Das Mining
funktioniert dann so dass… der Miner

426
00:31:22,229 --> 00:31:25,919
nimmt einfach mal diesen Header,
und bildet den double-hash davon.

427
00:31:25,919 --> 00:31:29,919
Dann prüft er ob der jetzt diese Bedingung
erfüllt. Das wird er vermutlich nicht tun.

428
00:31:29,919 --> 00:31:34,210
Und dann inkrementiert er halt die nonce,
dadurch hat sich der Header verändert,

429
00:31:34,210 --> 00:31:39,109
er bildet wieder den hash davon, und prüft
das. Und so macht er immer weiter.

430
00:31:39,109 --> 00:31:45,509
Es ist aber so, diese nonce ist lediglich
32 bit lang, und der Hash mit 256 bit

431
00:31:45,509 --> 00:31:50,249
ist wesentlich größer. Es kann also gut
sein, dass einfach durch das Inkrementieren

432
00:31:50,249 --> 00:31:55,130
der Nonce kein passender Proof-of-Work
gefunden wird. Und in dem Fall wird

433
00:31:55,130 --> 00:32:00,949
der Miner die coin-based Transaktion
verändern. Und zwar hat diese coin-based

434
00:32:00,949 --> 00:32:05,450
Transaktion hat den Transaction Input,
der wird bei einer normalen Transaktion

435
00:32:05,450 --> 00:32:09,729
dafür gebraucht zu beschreiben, woher
das Geld kommt in dieser Transaktion.

436
00:32:09,729 --> 00:32:14,229
Das hat die coin-based nicht, denn die
macht ja quasi Geld aus dem Nichts heraus,

437
00:32:14,229 --> 00:32:18,179
und den Wert in diesem Fall kann
dann der Miner frei beeinflussen.

438
00:32:18,179 --> 00:32:22,239
Dadurch ändert sich der Hash dieser
Transaktion, und das setzt sich dann

439
00:32:22,239 --> 00:32:27,799
durch den Merkle Tree hindurch fort bis
es quasi auch den Merkle Root verändert.

440
00:32:27,799 --> 00:32:32,679
Und dadurch ist der ganze Blockheader
wieder verändert und der Miner

441
00:32:32,679 --> 00:32:37,799
kann weiterarbeiten. So, das lässt sich ja
dann auch sehr einfach prüfen, ob das jetzt

442
00:32:37,799 --> 00:32:41,700
ein korrekter Proof-of-Work ist. Ich nehme
einfach diesen Blockheader und bilde

443
00:32:41,700 --> 00:32:48,449
den Hash und schaue ob das so stimmt.

444
00:32:48,449 --> 00:32:53,330
Das Bitcoin-Netzwerk versucht alle zehn
Minuten einen neuen Block zu erstellen.

445
00:32:53,330 --> 00:32:57,519
Um diese Zeit stabil zu halten,
wird die Schwierigkeit im Netzwerk

446
00:32:57,519 --> 00:33:02,899
alle 14 Tage, also alle 2016 Blöcke,
angepasst, mit einem Algorithmus

447
00:33:02,899 --> 00:33:10,539
wo jeder Miner feststellen kann wie weit
muss ich jetzt die Schwierigkeit verändern.

448
00:33:10,539 --> 00:33:14,379
Die coin-based Transaktion, mit der
sich der Miner Geld überweist,

449
00:33:14,379 --> 00:33:18,039
enthält in Bitcoin zwei Dinge:
einerseits die Transaction Fees, also

450
00:33:18,039 --> 00:33:24,759
die Transaktionsgebühren der Transaktion
in den Block; und anderseits auch noch

451
00:33:24,759 --> 00:33:29,500
neue Bitcoin, die neu ins System kommen.
Das waren ursprünglich 50 Bitcoin pro Block,

452
00:33:29,500 --> 00:33:34,619
heute sind es noch 12,5, der
Wert halbiert sich alle vier Jahre.

453
00:33:34,619 --> 00:33:38,509
Das war das letzte Mal in diesem Sommer,
da hat sich der Wert halbiert. Seither

454
00:33:38,509 --> 00:33:47,810
gibt es nur noch 12,5 Bitcoin
für einen neuen Block.

455
00:33:47,810 --> 00:33:51,999
Jetzt wollen wir noch uns anschauen
wie wir ‚Light Clients‘ bauen können.

456
00:33:51,999 --> 00:33:56,509
Bitcoin kennt eigentlich mehr oder weniger,
drei Arten von Clients: ein ‚Full Node‘

457
00:33:56,509 --> 00:34:02,589
ist ein Client, welcher die
gesamte Blockchain speichert.

458
00:34:02,589 --> 00:34:06,630
Der überprüft jede eingehende
Transaktion, jeden eingehenden Block

459
00:34:06,630 --> 00:34:10,639
überprüft dieser Client, ob der auch
wirklich valide ist. Und er tut noch

460
00:34:10,639 --> 00:34:14,119
etwas anderes, nämlich er seeded diese
Blöcke die er hat an das Netzwerk.

461
00:34:14,119 --> 00:34:17,800
Also wenn jemand kommt und sagt:
„Ich hätte gern einen Block“ dann gibt

462
00:34:17,800 --> 00:34:22,149
der Full Node diesen Block raus. Dann gibt
es ‚Pruning Clients‘. Der macht eigentlich

463
00:34:22,149 --> 00:34:27,940
das genau selbe wie der Full Node.
Also der überprüft auch alle Transaktionen

464
00:34:27,940 --> 00:34:32,520
und alle Blöcke. Aber der speichert jetzt
halt nicht die ganze Blockchain, sondern

465
00:34:32,520 --> 00:34:35,550
wenn er findet „den Block brauche ich
nicht mehr“, dann löscht er den.

466
00:34:35,550 --> 00:34:39,100
Und das macht dem Client Speicherplatz.
Der braucht aber immer noch

467
00:34:39,100 --> 00:34:43,580
sehr viel Rechenkraft und sehr viel
Bandbreite, deutlich zuviel als dass ich

468
00:34:43,580 --> 00:34:48,130
das auf meinem Smartphone laufen lassen
möchte. Und deshalb gibt es noch

469
00:34:48,130 --> 00:34:53,520
die Light Clients oder SPV Clients.
Die dann auch geeignet sind,

470
00:34:53,520 --> 00:34:56,980
um [sie] auf einem mobilen Gerät laufen
zu lassen. Und wie die funktionieren,

471
00:34:56,980 --> 00:35:01,210
will ich jetzt noch besprechen.

472
00:35:01,210 --> 00:35:05,590
Ein Light Client oder ein SPV Client,
was der tut zuerst ist, er lädt

473
00:35:05,590 --> 00:35:09,020
die Header aller Blöcke herunter. Wir
haben ja gesehen, der Proof-of-Work

474
00:35:09,020 --> 00:35:15,420
ist der Hash des Block Headers. D.h.
um den Proof-of-Work zu kontrollieren

475
00:35:15,420 --> 00:35:18,760
brauche ich nicht den gesamten
Block, der Block Header genügt.

476
00:35:18,760 --> 00:35:23,230
Und dasselbe gilt auch für die
Verknüpfung der Blöcke untereinander.

477
00:35:23,230 --> 00:35:26,390
Welches der vorhergehende Block
ist, das steht ja auch im Header.

478
00:35:26,390 --> 00:35:30,510
D.h. auch für diese Funktion brauche ich
nicht die ganzen Blöcke herunterzuladen.

479
00:35:30,510 --> 00:35:35,450
Und so kann ich korrekt
die längste Kette erstellen,

480
00:35:35,450 --> 00:35:40,350
innerhalb des Netzwerks, indem
ich nur die Header herunterlade.

481
00:35:40,350 --> 00:35:45,560
Und der Gewinn dabei ist natürlich enorm.
Zur Zeit gibt es etwa 450.000 Blöcke.

482
00:35:45,560 --> 00:35:52,350
Die brauchen mehr als 95 GB Speicherplatz.
Wenn man dann noch TX Index aktiviert

483
00:35:52,350 --> 00:35:56,230
sind es, glaube ich, so um die
110 GB Speicherplatz, die es braucht.

484
00:35:56,230 --> 00:36:00,450
Das ist natürlich blödsinnig viel auf einem
Smartphone. Aber nur die Block Headers,

485
00:36:00,450 --> 00:36:03,730
alle Block Headers von diesen
450.000 Blöcken, die passen

486
00:36:03,730 --> 00:36:10,180
in deutlich weniger als 100 MB rein. Und
das ist dann durchaus ein realistischer Wert,

487
00:36:10,180 --> 00:36:14,940
dass ich das auf einem Smartphone habe.
Das zweite Konzept ist der Merkle Branch,

488
00:36:14,940 --> 00:36:18,540
und das ist dann eigentlich noch fast
die interessantere Funktion, die uns

489
00:36:18,540 --> 00:36:22,790
der Merkle Tree bildet. Und damit kann
jeder beweisen, dass eine Transaktion

490
00:36:22,790 --> 00:36:26,770
tatsächlich Teil des Zustands ist.

491
00:36:26,770 --> 00:36:30,650
Nun, die eine Möglichkeit, wie wir den
Merkle Tree nachbauen können,

492
00:36:30,650 --> 00:36:35,210
ist natürlich, indem wir den Block
Body herunterladen, und dann

493
00:36:35,210 --> 00:36:39,580
den ganzen Merkle Tree bauen.
Wenn ich jetzt aber nur beweisen will

494
00:36:39,580 --> 00:36:44,200
dass eine Transaktion Teil des Blockes
ist, gibt es eine effizientere Möglichkeit.

495
00:36:44,200 --> 00:36:47,950
Angenommen ich will jetzt beweisen,
dass die Transaktion (3) tatsächlich

496
00:36:47,950 --> 00:36:51,920
Teil des Blocks ist. Dann brauche ich
nicht alle Transaktionen herunterzuladen,

497
00:36:51,920 --> 00:36:57,760
sondern es reicht diese Transaktion (3)
herunterzuladen. – Ui, das war falsch. –

498
00:36:57,760 --> 00:37:01,480
Und dann die restlichen Hashes,
also von jeder Ebene des Baums

499
00:37:01,480 --> 00:37:04,480
lade ich einen Hash herunter.
Und damit kann ich jetzt

500
00:37:04,480 --> 00:37:11,420
den Merkle Root Node wieder nachbilden,
und so feststellen, dass diese Transaktion

501
00:37:11,420 --> 00:37:15,890
tatsächlich Teil des Blocks ist.
Das ist genau das was…

502
00:37:15,890 --> 00:37:19,150
das hat jetzt natürlich auch einige
Vorteile. Ich brauche jetzt

503
00:37:19,150 --> 00:37:23,520
weniger Elemente herunterzuladen, und
ich kann halt Hashes herunterladen, also

504
00:37:23,520 --> 00:37:27,110
anstatt Transaktionen. Vorhin in dem
Beispiel hat das nicht soviel gebracht.

505
00:37:27,110 --> 00:37:30,371
Aber wenn wir einen Block nehmen
mit 1600 Transaktionen, das ist

506
00:37:30,371 --> 00:37:34,880
dieser Tage durchaus ein üblicher Block,
dann brauche ich jetzt zum Validieren

507
00:37:34,880 --> 00:37:38,810
nicht mehr 1600 Transaktionen
herunterzuladen, sondern es genügt

508
00:37:38,810 --> 00:37:42,400
eine Transaktion herunterzuladen und
dann elf Hashes, und damit kann ich

509
00:37:42,400 --> 00:37:47,270
den Merkle Branch nachbauen.

510
00:37:47,270 --> 00:37:52,640
Und so funktioniert ein SPV Client. SPV
steht für ‚simple payment verification‘.

511
00:37:52,640 --> 00:37:56,660
Und das hat eigentlich… das wurde schon
im White Paper zu Bitcoin beschrieben,

512
00:37:56,660 --> 00:38:00,890
wie das funktioniert. Alles was der
tun muss, um zu beweisen, dass

513
00:38:00,890 --> 00:38:04,950
eine Transaktion reingekommen ist, ist,
er lädt zuerst alle Block Header herunter,

514
00:38:04,950 --> 00:38:10,320
wie vorhin besprochen, er bildet
den längsten Branch daraus,

515
00:38:10,320 --> 00:38:15,580
dann lädt er eine Transaktion herunter.
Und wenn ich jetzt wissen will…

516
00:38:15,580 --> 00:38:18,331
wenn ich von jemandem Geld erhalte und
ich will jetzt zeigen, ich habe das Geld

517
00:38:18,331 --> 00:38:22,610
tatsächlich erhalten, lade ich halt diese
Transaktion herunter, und dann lade ich

518
00:38:22,610 --> 00:38:27,110
den passenden Merkle Branch herunter.
Und jetzt kann ich quasi zeigen, dass

519
00:38:27,110 --> 00:38:32,160
dieser Merkle Branch tatsächlich mit der
längsten Kette von Blöcken verbunden ist.

520
00:38:32,160 --> 00:38:36,990
Und so habe ich jetzt den Beweis dafür,
dass ich das Geld tatsächlich erhalten habe.

521
00:38:36,990 --> 00:38:40,560
So, das ist diese Funktionsweise.
Jetzt haben wir noch etwas mehr Zeit,

522
00:38:40,560 --> 00:38:44,290
als ich gehofft hatte. Ich werde jetzt
noch versuchen, die Pruning Clients

523
00:38:44,290 --> 00:38:49,010
zu erklären. Das hängt dann damit zusammen
wie eigentlich Bitcoin-Transaktionen

524
00:38:49,010 --> 00:38:53,910
funktionieren. Nun, wir sind es ja
gewohnt, dass wir irgendwie auf der Bank

525
00:38:53,910 --> 00:38:58,440
ein Konto haben. Und das Konto
hat einen Besitzer. Hoffentlich mich!

526
00:38:58,440 --> 00:39:02,720
Und es hat einen Geldbetrag. Und jedesmal,
wenn ich eine Transaktion durchführe,

527
00:39:02,720 --> 00:39:06,760
verändert sich der Geldbetrag. Also ich
überweisen jemandem Geld, und dann

528
00:39:06,760 --> 00:39:11,520
verändert sich halt der Betrag auf meinem
Konto. In Bitcoin funktioniert das

529
00:39:11,520 --> 00:39:15,620
wesentlich anders, dort besitze ich
nicht ein Konto, sondern ich besitze

530
00:39:15,620 --> 00:39:20,170
sogenannte ‚Unspent Transaction Outputs‘.
Und wir sehen jetzt hier, sagen wir Alice

531
00:39:20,170 --> 00:39:23,880
hat diese fünf Unspent Transaction
Outputs, die haben jeweils einen Besitzer,

532
00:39:23,880 --> 00:39:29,230
nämlich Alice. Und jeweils einen Betrag
der dort verfügbar ist. Und der Betrag

533
00:39:29,230 --> 00:39:33,840
kann nicht geändert werden. Das ist fest.
Und nehmen wir jetzt an, Alice würde gerne

534
00:39:33,840 --> 00:39:38,910
eine Transaktion machen, an Bob,
die würde ihm gerne 42 Bitcoin überweisen.

535
00:39:38,910 --> 00:39:42,200
Dann erstellt sie eine Transaktion, und
sagt, das Geld dieser Transaktion,

536
00:39:42,200 --> 00:39:47,270
42 Bitcoin, sollen an Bob gehen. Und jetzt
muss sie das Geld irgendwoher haben.

537
00:39:47,270 --> 00:39:53,200
Und dann sagt sie halt, ich gebe
diese drei Transaction Outputs aus.

538
00:39:53,200 --> 00:39:56,920
Und das Interessante an Transaction
Outputs… wie gesagt, den Betrag

539
00:39:56,920 --> 00:40:01,760
kann man nicht verändern, sondern
Alice muss die alle komplett ausgeben.

540
00:40:01,760 --> 00:40:05,930
Jetzt sind aber diese Transaction Outputs
zusammengenommen 44 Bitcoin,

541
00:40:05,930 --> 00:40:10,990
und nicht 42 Bitcoins. D.h. diese
Transaktion gibt jetzt zuviel Geld aus,

542
00:40:10,990 --> 00:40:17,330
also sie gibt mehr Transaction Outputs aus
als sie dann schlussendlich Geld dem Bob

543
00:40:17,330 --> 00:40:21,400
überweist. Und was kann jetzt Alice
tun? Was sie tut, ist, sie macht

544
00:40:21,400 --> 00:40:27,360
einen zweiten Output in ihrer Transaktion.
Und hier überweist sie jetzt Geld an Alice.

545
00:40:27,360 --> 00:40:31,670
D.h. eine Transaktion in Bitcoin kann
beliebig viele Inputs und beliebig viele

546
00:40:31,670 --> 00:40:36,740
Outputs haben. Was es hier noch zu
sagen gibt, ist, haben wir immer noch

547
00:40:36,740 --> 00:40:41,070
einen Unterschied. Jetzt haben wir 44
Bitcoin, die in die Transaktion reinkommen,

548
00:40:41,070 --> 00:40:45,860
und nur 43 die rausgehen. Das restliche
Bitcoin, das jetzt hier nicht ausgegeben wird,

549
00:40:45,860 --> 00:40:50,810
das ist quasi impliziert die Transaction
Fee, welche der Miner erhält, der diese

550
00:40:50,810 --> 00:40:56,400
Transaktion mint. So eine Transaction Fee
ist implementiert. Jetzt haben wir gesehen,

551
00:40:56,400 --> 00:40:59,640
Alice hat durch das Erstellen dieser
Transaktion neue Transaction Outputs

552
00:40:59,640 --> 00:41:05,760
erstellt. Nämlich einen, der jetzt Bob
gehört, und einen der Alice gehört.

553
00:41:05,760 --> 00:41:08,980
Und jetzt können wir auch nachvollziehen,
diese Transaction Outputs, welche Alice

554
00:41:08,980 --> 00:41:13,850
ausgegeben hat, die gehören alle irgendwie
zu anderen Transaktionen, welche es vorhin

555
00:41:13,850 --> 00:41:19,800
gegeben hat. Nun, ein Transaction Output
kann einen von zwei Zuständen haben.

556
00:41:19,800 --> 00:41:24,930
Er kann ausgegeben sein, oder nicht.
Und natürlich kann man nur die ausgeben,

557
00:41:24,930 --> 00:41:29,320
die noch nicht ausgegeben sind. Und das
heißt, wenn ich wissen will, wieviel Geld

558
00:41:29,320 --> 00:41:33,350
Alice gehört, dann suche ich mir alle
Transaction Outputs zusammen,

559
00:41:33,350 --> 00:41:38,360
die Alice gehören, und addiere die Summe,
und dann weiß ich, Alice gehört „soviel“ Geld.

560
00:41:38,360 --> 00:41:41,200
Das kann ich für jeden Teilnehmer
des Systems machen, dann weiß ich

561
00:41:41,200 --> 00:41:46,900
für jeden Teilnehmer, wieviel Geld denn
der Person gehört. Wenn ich jetzt also

562
00:41:46,900 --> 00:41:50,980
alle Transaction Outputs nehme, die
nicht ausgegeben sind, dann habe ich

563
00:41:50,980 --> 00:41:56,530
den aktuellen Zustand des Netzwerks. Dann
weiß ich für jeden Teilnehmer, wieviel Geld

564
00:41:56,530 --> 00:42:04,960
diese Person hat. Und genau diesen
Mechanismus macht sich ein Pruning Client

565
00:42:04,960 --> 00:42:09,470
zunutze. Der sagt nämlich, eigentlich
brauche ich nicht die ganze Blockchain

566
00:42:09,470 --> 00:42:12,931
zu speichern, das ist ja blöd, denn wenn
eine neue Transaktion reinkommt, und

567
00:42:12,931 --> 00:42:17,260
ich wissen will ob die tatsächlich valide
ist, dann muss ich nur prüfen, ob die

568
00:42:17,260 --> 00:42:22,060
einen Output ausgibt, der noch unspent
ist, denn wenn die Transaktion einen

569
00:42:22,060 --> 00:42:25,520
Transaction Output ausgibt, der schon
ausgegeben ist, dann ist die natürlich

570
00:42:25,520 --> 00:42:29,430
nicht valide, man kann ja nicht dasselbe
Geld zweimal ausgeben. Oder wenn

571
00:42:29,430 --> 00:42:32,790
die Transaktion versucht, einen
Transaction Output auszugeben,

572
00:42:32,790 --> 00:42:36,220
den es gar nicht gibt, dann ist
die natürlich auch nicht valide.

573
00:42:36,220 --> 00:42:42,290
Was jetzt also ein Pruning Client tut –
und das tut übrigens auch ein Full Node:

574
00:42:42,290 --> 00:42:46,270
wenn eine neue Transaktion reinkommt,
und da steht in der Transaktion „ich gebe

575
00:42:46,270 --> 00:42:51,770
diesen Transaction Output aus“, dann
geht der Full Node nicht und versucht,

576
00:42:51,770 --> 00:42:55,930
die 100 GB große Blockchain zu durchsuchen
nach diesem Transaction Output, das wäre

577
00:42:55,930 --> 00:43:00,160
ja blödsinnig, sondern der legt sich halt
eine kleine Datenbank an, und dort

578
00:43:00,160 --> 00:43:05,520
stehen alle Transaction Outputs drin.
Und dann sagt er sich, für jeden…

579
00:43:05,520 --> 00:43:08,580
also alle Unspent Transaction Outputs
stehen dort drin, und dann sagt sich

580
00:43:08,580 --> 00:43:12,090
der Client, für jede Transaktion,
die reinkommt und die valide ist,

581
00:43:12,090 --> 00:43:17,540
entferne ich alle Transaction Outputs die
die Transaktion ausgibt aus der Datenbank,

582
00:43:17,540 --> 00:43:22,870
und alle neuen Transaction Outputs füge
ich dort ein. Und so behält der Client

583
00:43:22,870 --> 00:43:28,530
den Zustand. Und der Pruning Client sagt
sich dann halt: „Naja, die Blöcke, die

584
00:43:28,530 --> 00:43:31,550
brauche ich jetzt ja nicht mehr, weil ich
habe den Zustand in der Datenbank,

585
00:43:31,550 --> 00:43:35,380
der ist auch viel kleiner als all die
blöden Blöcke, die Blöcke werfe ich fort.“

586
00:43:35,380 --> 00:43:39,260
Der muss dann noch etwas vorsichtig sein,
denn wenn jetzt plötzlich von weiter hinten

587
00:43:39,260 --> 00:43:42,770
eine längere Kette kommt, dann muss er
das ja wieder nachvollziehen können,

588
00:43:42,770 --> 00:43:47,520
also wird er sich noch einige Blöcke
zusätzlich speichern, als nur den neuesten.

589
00:43:47,520 --> 00:43:54,720
Aber er kann so sehr viel Speicherplatz
sparen. Er muss aber… trotzdem

590
00:43:54,720 --> 00:44:00,420
muss ein Pruning Client eigentlich jede
Transaktion, die es jemals gegeben hat,

591
00:44:00,420 --> 00:44:04,490
herunterladen, und muss dann halt auch
die alle verifizieren. Das braucht auch

592
00:44:04,490 --> 00:44:08,280
immer noch sehr viel Rechenkraft, und
sehr viel Bandbreite. Und deshalb sind

593
00:44:08,280 --> 00:44:13,300
solche Clients nicht geeignet
für Mobilgeräte.

594
00:44:13,300 --> 00:44:15,870
Und was man hier vielleicht noch sagen
kann, ich habe jetzt eigentlich irgendwie

595
00:44:15,870 --> 00:44:25,300
gesagt, …

596
00:44:25,300 --> 00:44:31,510
…ich habe jetzt gesagt, Alice gibt einen
Transaction Output aus. Das ist…

597
00:44:31,510 --> 00:44:34,570
In Wirklichkeit ist es in Bitcoin
recht kompliziert implementiert.

598
00:44:34,570 --> 00:44:38,790
Das funktioniert nämlich so, dass der
Transaction Output hat ein Stück Code

599
00:44:38,790 --> 00:44:44,940
drin. Dafür gibt es in Bitcoin eine eigene
Assemblersprache, die das betreibt.

600
00:44:44,940 --> 00:44:50,960
Und der Input muss jetzt ebenfalls ein
Stück Code enthalten. Und wenn die dann

601
00:44:50,960 --> 00:44:55,670
nacheinander ausgeführt werden, muss das
am Schluss den Wert 'two' ergeben,

602
00:44:55,670 --> 00:44:59,740
und nur in dem Fall wurde der Output
richtig ausgegeben. Und das ist

603
00:44:59,740 --> 00:45:03,820
ein ziemlich kompliziertes System, wie das
wirklich funktioniert. Das ist dann halt

604
00:45:03,820 --> 00:45:07,440
eine eigene Programmiersprache, die ist
zwar nicht Turing-vollständig, aber damit

605
00:45:07,440 --> 00:45:11,940
lassen sich dann alle möglichen lustigen
Regeln implementieren. Die häufigste Regel

606
00:45:11,940 --> 00:45:23,410
die man findet, in über 80%
der Fälle, sind sogenannte…

607
00:45:23,410 --> 00:45:28,250
…die Regel sagt dann irgendsowas wie:
„Um diesen Output ausgeben zu können,

608
00:45:28,250 --> 00:45:32,380
musst du beweisen, dass du den geheimen
Schlüssel besitzt zu dem öffentlichen

609
00:45:32,380 --> 00:45:37,400
Schlüssel, dessen Hash ich jetzt hier
reinpacke.“ Und in dem Input steht dann

610
00:45:37,400 --> 00:45:43,310
halt: „Ja, ich besitze diesen geheimen
Schlüssel, und ich beweise dir das,

611
00:45:43,310 --> 00:45:47,680
indem ich hier den öffentlichen Schlüssel
reinpacke und die Transaktion mit dem

612
00:45:47,680 --> 00:45:52,840
geheimen Schlüssel signiere.“ Und dann
kann jemand, der das verifizieren will,

613
00:45:52,840 --> 00:45:56,930
kann einfach den öffentlichen Schlüssel
nehmen, schauen ob das dem Hash entspricht,

614
00:45:56,930 --> 00:46:04,630
und dann mit dem öffentlichen Schlüssel
die Signatur der Transaktion verifizieren.

615
00:46:04,630 --> 00:46:09,940
Das ist die mit Abstand häufigste Art,
wie diese Transaktionen in Wirklichkeit

616
00:46:09,940 --> 00:46:14,240
funktionieren. Aber das ist halt dann sehr
kompliziert, und damit könnte man leicht

617
00:46:14,240 --> 00:46:22,250
einen eigenen Vortrag füllen.
Deshalb werde ich jetzt hier aufhören.

618
00:46:22,250 --> 00:46:28,900
Habe ich da diese tolle Seite gebastelt.

619
00:46:28,900 --> 00:46:32,920
– Ups, das ist eigentlich zu weit –

620
00:46:32,920 --> 00:46:42,750
Finde ich es, oder nicht?

621
00:46:42,750 --> 00:46:45,760
Ja, ha, gefunden! Unglaublich.
<i>Lachen</i>

622
00:46:45,760 --> 00:46:48,860
Also wir haben jetzt noch Zeit für Fragen,
wenn ihr noch was wissen wollt.

623
00:46:48,860 --> 00:46:54,940
Oder ihr könnt mich auch erreichen,
am einfachsten hier über das DECT-Telefon

624
00:46:54,940 --> 00:47:01,890
in dem Kongress, wenn ihr Fragen habt.
Ihr findet einen Handout der Slides

625
00:47:01,890 --> 00:47:06,000
auch im Fahrplan. Und ich werde auch
die Folien selbst noch hochladen,

626
00:47:06,000 --> 00:47:09,520
und den entsprechenden Source Code
zum Erzeugen der Folien werde ich auch

627
00:47:09,520 --> 00:47:11,460
verlinken.

628
00:47:11,460 --> 00:47:12,960
<i>Beifall</i>

629
00:47:12,960 --> 00:47:14,550
Herald: vimja!!

630
00:47:14,550 --> 00:47:24,790
<i>andauernder Beifall</i>

631
00:47:24,790 --> 00:47:31,540
Es ist noch einiges an Zeit für Fragen;
also wenn ihr Fragen habt,

632
00:47:31,540 --> 00:47:35,440
dann reiht euch an den Mikrofonen auf.
Eine Sache möchte ich sagen:

633
00:47:35,440 --> 00:47:40,280
wenn ihr jetzt rausgehen wollt, verlasst
bitte leise den Saal, damit das

634
00:47:40,280 --> 00:47:44,360
mit den Fragen einigermaßen klappt.
Liebe Tür-Engel, wir lassen im Moment

635
00:47:44,360 --> 00:47:50,430
noch niemanden rein. Erstmal können Leute
nur rausgehen. Und bitte tut das leise.

636
00:47:50,430 --> 00:47:55,520
Wir fangen mit dem Signal-Engel an.

637
00:47:55,520 --> 00:47:58,730
Signal Angel: Eine Frage aus dem Internet
bezüglich dem Man-in-the-middle

638
00:47:58,730 --> 00:48:02,290
double-spending-Angriff. Könnte Mallory
nicht diesen Angriff gleichzeitig

639
00:48:02,290 --> 00:48:07,210
mit derselben Fake-Blockchain gegen zehn
verschiedene Autohändler machen, und

640
00:48:07,210 --> 00:48:12,890
mit dem gleichen Aufwand zehn Autos klauen?
Damit würde es sich doch wieder lohnen,

641
00:48:12,890 --> 00:48:20,050
auch wenn man mit dem Gegenwert eines
Autos an Rechenzeit investieren müsste.

642
00:48:20,050 --> 00:48:25,590
vimja: Das ist eine gute Überlegung die
ich mir so noch auch gar nie gemacht habe.

643
00:48:25,590 --> 00:48:30,030
Ich müsste darüber mal nachdenken. Ich
nehme aber grundsätzlich an, dass es

644
00:48:30,030 --> 00:48:35,670
vermutlich funktionieren würde. Der
Aufwand wird dann aber halt sehr viel

645
00:48:35,670 --> 00:48:40,970
größer, irgendwie um die Netzwerk-Nodes
zu kontrollieren. Grundsätzlich denke ich

646
00:48:40,970 --> 00:48:44,950
aber, dass es kein… damit das System
wirklich sicher ist, sollte das

647
00:48:44,950 --> 00:48:50,730
kein Argument sein dürfen. Also ich hätte
jetzt auf Anhieb gesagt, dass es vermutlich

648
00:48:50,730 --> 00:48:54,790
klappen würde.

649
00:48:54,790 --> 00:48:58,251
Herald: Okay, dann machen wir weiter
mit Mikrofon 2, hier vorne, bitte!

650
00:48:58,251 --> 00:49:03,220
Frage: Ja, hallo. Du hast gesagt, mit
einer 50%-Attack kann man im Prinzip

651
00:49:03,220 --> 00:49:07,140
die Blockchains hijacken. Wenn man
sich jetzt mal eine hypothetische

652
00:49:07,140 --> 00:49:11,480
Regierungsorganisation mit sehr, sehr,
sehr viel Rechenpower überlegt,

653
00:49:11,480 --> 00:49:16,220
mal so ganz in den Raum geraten, gibt’s
Überlegungen, wie wahrscheinlich das ist?

654
00:49:16,220 --> 00:49:19,540
vimja: Nun, es ist so, mit einfach
herkömmlicher Rechenpower wird das

655
00:49:19,540 --> 00:49:22,750
kaum möglich sein, also irgendwie
für diese spezielle Aufgabe,

656
00:49:22,750 --> 00:49:28,400
den Double-SHA256-Hash, hat das Bitcoin-
Netzwerk ein Vielfaches der Rechenkraft,

657
00:49:28,400 --> 00:49:32,510
die selbst die 500 schnellsten Supercomputer
aufbringen könnten. Es gibt aber eine

658
00:49:32,510 --> 00:49:36,580
viel einfachere Möglichkeit, unser guter
Freund China, denn die meisten…

659
00:49:36,580 --> 00:49:40,070
denn heute ist es halt so: eigentlich
möchte man gerne, dass die Miner

660
00:49:40,070 --> 00:49:43,740
verteilt sind, und jeder ein wenig zuhause
minet. In Praxis ist es aber so, dass

661
00:49:43,740 --> 00:49:47,770
das heute das große Geschäft ist. Und das
wird dann halt heute in Rechenzentren

662
00:49:47,770 --> 00:49:54,280
in China betrieben. Und China hat heute
mehr als 50% der Rechenkraft von Bitcoin,

663
00:49:54,280 --> 00:49:57,430
also, toll, unsere unabhängige Währung
gehört jetzt den Chinesen.

664
00:49:57,430 --> 00:50:01,030
Und selbst wenn das nicht stimmen sollte,
und das nicht funktionieren sollte,

665
00:50:01,030 --> 00:50:04,630
ist es so, dass all die spezielle
Hardware, die heute zum Mining

666
00:50:04,630 --> 00:50:08,940
notwendig ist, in China hergestellt wird.
Und China könnte einfach all diese Fabriken,

667
00:50:08,940 --> 00:50:12,710
in denen die hergestellt werden,
beschlagnahmen, und nach einigen Monaten

668
00:50:12,710 --> 00:50:15,120
hätten sie trotzdem wieder mehr
Rechenleistung als jeder andere,

669
00:50:15,120 --> 00:50:21,250
und könnte die Währung so kontrollieren.
Also, das ist durchaus wahrscheinlich.

670
00:50:21,250 --> 00:50:24,680
Herald: Dann machen wir weiter
mit Mikrofon 1, hier vorne, bitte.

671
00:50:24,680 --> 00:50:28,970
Frage: Ja, mir geht’s auch gerade um die
Rechenpower. Also gibt es da irgendwie

672
00:50:28,970 --> 00:50:34,200
Ansätze in anderen elektronischen
Währungen, wie das verhindert werden kann,

673
00:50:34,200 --> 00:50:40,380
dass immer quasi zum Stand der aktuellen
Technik die maximale Rechenpower nötig ist,

674
00:50:40,380 --> 00:50:44,041
um so ein System laufen zu lassen?

675
00:50:44,041 --> 00:50:47,400
vimja: Es hat zur Zeit, im Verlauf der
Zeit verschiedene Möglichkeiten,

676
00:50:47,400 --> 00:50:51,700
also verschiedene Ansätze gegeben.

677
00:50:51,700 --> 00:50:55,150
Das eine was man immer wieder versucht
hat, ist halt, dass man das nicht nur auf

678
00:50:55,150 --> 00:50:59,720
Rechenkraft beschränkt, sondern dass man
sagt, der Angriff der braucht nicht nur

679
00:50:59,720 --> 00:51:03,950
Rechenpower sondern auch viel RAM,
oder viel Memory. Und dadurch ist es

680
00:51:03,950 --> 00:51:08,250
sehr viel schwieriger, Hardware zu bauen.
Oder sehr viel teurer, Hardware zu bauen,

681
00:51:08,250 --> 00:51:12,240
die darauf spezialisiert ist, und man
erhofft sich davon Erfolge, aber

682
00:51:12,240 --> 00:51:16,010
schlussendlich hat man dort wieder
dasselbe Problem. Ich weiß aber,

683
00:51:16,010 --> 00:51:21,500
dass Ethereum arbeitet an einem Konzept,
das nennen sie Proof-of-Stake.

684
00:51:21,500 --> 00:51:24,730
Und wie genau das funktioniert, kann ich
dir nicht sagen. Aber da hängt dann

685
00:51:24,730 --> 00:51:29,160
die Wahrscheinlichkeit, dass du einen
Block erstellst, davon ab wieviel Geld

686
00:51:29,160 --> 00:51:32,900
du besitzt in dem Netzwerk, oder sowas.
Und die brauchen dann eigentlich

687
00:51:32,900 --> 00:51:35,840
kein Mining mehr. Und die haben dann halt
auch das Problem nicht mehr dass man

688
00:51:35,840 --> 00:51:40,700
unglaublich viel Strom braucht, um das
Ding zu minen. Und ich dachte, die wollten

689
00:51:40,700 --> 00:51:44,660
diesen Sommer umstellen. Ich habe dann
aber das Ganze ein wenig aus den Augen

690
00:51:44,660 --> 00:51:47,560
verloren, und kann dir jetzt nicht
sagen wie weit die damit sind.

691
00:51:47,560 --> 00:51:48,260
Also grundsätzlich…

692
00:51:48,260 --> 00:51:50,100
Frage: Wie heißt das nochmal?

693
00:51:50,100 --> 00:51:53,570
vimja: ‚Proof-of-Stake‘. Und das wird in
Ethereum implementiert. Aber wie weit

694
00:51:53,570 --> 00:51:57,490
die sind, kann ich dir nicht sagen. Das
müsstest du selbst nachschauen gehen.

695
00:51:57,490 --> 00:51:58,770
Frage: Danke.

696
00:51:58,770 --> 00:52:02,440
Herald: Dann machen wir weiter mit
Mikrofon 4, dort drüben, bitte!

697
00:52:02,440 --> 00:52:06,550
Frage: Ich stelle mal zwei Fragen. Das
eine ist: öffentliche Grundbuchämter

698
00:52:06,550 --> 00:52:11,470
könnte man doch sehr gut in der Blockchain
umlegen [anlegen], und dadurch könnte

699
00:52:11,470 --> 00:52:14,590
doch die Verwaltung sehr viel Geld
einsparen, und z.B. Handelsregister

700
00:52:14,590 --> 00:52:16,730
sind ja auch öffentlich, die könnte man
doch auch in die Blockchain verschieben.

701
00:52:16,730 --> 00:52:20,450
Oder mache ich da irgendeinen Denkfehler,
dass es am Schluss für die Verwaltung

702
00:52:20,450 --> 00:52:22,980
teurer kommt? Und was mich auch
noch wundert, was deine Meinung

703
00:52:22,980 --> 00:52:26,250
zu Smart Contracts ist.

704
00:52:26,250 --> 00:52:30,300
vimja: Also, zu der ersten Frage, das ist
so, daran wird tatsächlich gearbeitet.

705
00:52:30,300 --> 00:52:35,030
Insbesondere die britische Regierung hat
auch Forschungsgruppen, die erforschen

706
00:52:35,030 --> 00:52:41,890
sollen, wie Blockchains der Verwaltung
helfen können. Gerade beim Grundbuchamt,

707
00:52:41,890 --> 00:52:46,000
also solche Systeme brauchen starke
Anpassungen, gerade wenn wir uns

708
00:52:46,000 --> 00:52:52,460
vorstellen, ein Grundbuchamt, wenn es dann
jemandem gelingen würde, irgendwie

709
00:52:52,460 --> 00:52:55,690
jetzt trotzdem ein Grundstück quasi
zu stehlen, und das würde einfach

710
00:52:55,690 --> 00:53:01,960
in dieser Blockchain drin feststehen, wie
würde man das wieder rückgängig machen?

711
00:53:01,960 --> 00:53:06,120
Also wenn wir heute ein Grundbuchamt
haben, dann können die alles überschreiben.

712
00:53:06,120 --> 00:53:10,230
Und irgendwie möchten wir ja dann trotzdem
nicht einfach nur dieser Blockchain vertrauen.

713
00:53:10,230 --> 00:53:14,810
Wir möchten trotzdem die Möglichkeit
haben, dass gewisse Stellen, gerade eben

714
00:53:14,810 --> 00:53:18,020
unser Staat, das überschreiben können.
Da müssen dann in diese Blockchains

715
00:53:18,020 --> 00:53:22,460
zusätzliche Mechanismen eingebaut werden,
dass das trotzdem geht, und das ist dann

716
00:53:22,460 --> 00:53:26,850
halt bedenklich, weil jetzt trotzdem da
jemand das Zeugs kaputtmachen kann.

717
00:53:26,850 --> 00:53:30,750
Also das ist nicht ganz einfach, diese
Dinge zu tun. Aber ich denke schon,

718
00:53:30,750 --> 00:53:38,360
dass gerade Grundbuchämter eine gute
Chance sind, und das ist vermutlich auch

719
00:53:38,360 --> 00:53:43,760
etwas vom Ersten, was wir implementiert
sehen werden. Soviel für öffentliche Ämter.

720
00:53:43,760 --> 00:53:48,000
Aber ich denke auch, dass es einen
Hybridbetrieb geben wird. Also

721
00:53:48,000 --> 00:53:51,580
dass man quasi sagt, das ist zwar
öffentlich in einer Blockchain, aber

722
00:53:51,580 --> 00:53:56,360
schlussendlich, was wirklich gilt ist
immer noch das, was im Grundbuchamt steht,

723
00:53:56,360 --> 00:53:59,480
und das wird dann halt solange so
weiterbetrieben, bis sich das wirklich

724
00:53:59,480 --> 00:54:03,220
bewährt hat, und man den Übergang macht.
Und die zweite Frage, sorry, habe ich

725
00:54:03,220 --> 00:54:07,190
wieder vergessen.

726
00:54:07,190 --> 00:54:10,500
Herald: Okay, wenn das die Frage
beantwortet und er nicht wieder aufsteht,

727
00:54:10,500 --> 00:54:14,760
dann würde ich jetzt mit Mikrofon 7
weitermachen, dort oben, bitte.

728
00:54:14,760 --> 00:54:20,140
Frage: Ja, vielen Dank für den spannenden
Vortrag. Mich würde noch interessieren,

729
00:54:20,140 --> 00:54:24,970
vielleicht noch was zu dem Thema ‚Ende
der Bitcoins‘, die sind ja anscheinend

730
00:54:24,970 --> 00:54:29,220
begrenzt, soweit ich das verstanden habe.
Und wie wird das Erstellen von neuen

731
00:54:29,220 --> 00:54:33,880
Blöcken letztendlich in ferner Zukunft
dann belohnt, werden die einfach immer so

732
00:54:33,880 --> 00:54:36,690
weiter unterteilt, und man bekommt dann
nur noch Bruchteile von Bitcoins

733
00:54:36,690 --> 00:54:38,280
als Belohnung, oder wie funktioniert das?

734
00:54:38,280 --> 00:54:41,520
vimja: Das ist eine sehr gute Frage,
die sich natürlich auch diesen Sommer

735
00:54:41,520 --> 00:54:45,470
gestellt hat, weil sich ja der
Block Reward halbiert hat.

736
00:54:45,470 --> 00:54:49,150
Und erstaunlicherweise ist es dann aber
eigentlich ohne Weiteres weitergegangen.

737
00:54:49,150 --> 00:54:53,210
Nun ist es so, der Mechanismus,
der eigentlich greifen sollte, ist

738
00:54:53,210 --> 00:54:57,880
die Transaction Fees. Dass es durch
die Transaction Fees getragen wird,

739
00:54:57,880 --> 00:55:02,550
diese Gebühr. Nur ist es heute so, dass
die Transaction Fees so niedrig sind,

740
00:55:02,550 --> 00:55:07,410
dass das Minen sich nicht rentieren würde,
also der Stromverbrauch ist viel zu hoch,

741
00:55:07,410 --> 00:55:13,720
als dass es sich lohnen würde, nur
für die Transaction Fees zu minen.

742
00:55:13,720 --> 00:55:17,230
Andererseits ist es aber so, dass die
Transaction Fees heute schon sehr hoch

743
00:55:17,230 --> 00:55:21,090
sind, also die kommen heute irgendwo
zwischendurch schon in die Bereiche

744
00:55:21,090 --> 00:55:24,740
der Transaction Fees, die man auch
zahlt bei Kreditkartenüberweisungen.

745
00:55:24,740 --> 00:55:28,580
Und das ist natürlich absolut lächerlich
hoch. Und dann ist es aber auch so,

746
00:55:28,580 --> 00:55:32,970
dass die Blöcke voll sind, d.h. wenn das
Block Limit – das ist ein künstliches

747
00:55:32,970 --> 00:55:37,260
Limit, wie groß die Blöcke sein dürfen,
und die Community führt da großen Krieg

748
00:55:37,260 --> 00:55:41,690
darüber ob man das jetzt ändern soll oder
nicht – aber wenn dieses Limit halt nicht

749
00:55:41,690 --> 00:55:44,770
erhöht wird, dann passen nicht mehr
Transaktionen rein, und dann ist

750
00:55:44,770 --> 00:55:48,770
der einzige Weg höhere Transaction…
also mehr Transaction Fees zu haben

751
00:55:48,770 --> 00:55:51,620
für den Miner, ist diese Transaction Fees
zu erhöhen. Und wenn man die weiter

752
00:55:51,620 --> 00:55:55,920
erhöht, dann lohnt es sich einfach
nicht mehr, Bitcoin zu verwenden.

753
00:55:55,920 --> 00:55:58,531
Im Moment ist es noch nicht so ein
Problem, für die nächsten vier Jahre

754
00:55:58,531 --> 00:56:02,640
sind es ja noch 12,5 Bitcoin die
man kriegt. Aber wie es danach

755
00:56:02,640 --> 00:56:07,200
weitergehen wird, das muss man abwarten,
und dann schauen, was da genau passiert.

756
00:56:07,200 --> 00:56:10,750
Und ich denke dass das ist auch noch ein
dynamisches System, das sich schnell

757
00:56:10,750 --> 00:56:14,960
wandelt, und da werden auch noch
viele Leute viele gute Ideen haben.

758
00:56:14,960 --> 00:56:17,770
Frage: Darf ich noch mal kurz was
nachfragen? D.h. der Proof-of-Work

759
00:56:17,770 --> 00:56:22,980
ist nicht der direkte Bitcoin, den ich
bekomme, also nicht die 12,5 Bitcoins,

760
00:56:22,980 --> 00:56:28,230
die ich bekomme, um einen Block zu
erstellen, ist nicht der Proof-of-Work?

761
00:56:28,230 --> 00:56:31,930
vimja: Nein nein, das ist… die 12,5 Bitcoin
die du kriegst, also die 12,5 Bitcoin

762
00:56:31,930 --> 00:56:34,940
plus das klein weniger, was von den
Transaction Fees kommt, das ist

763
00:56:34,940 --> 00:56:39,430
der Block Reward. Nennt sich das. Und der
Proof-of-Work ist einfach der Beweis dafür,

764
00:56:39,430 --> 00:56:44,790
dass du die Arbeit auf dich genommen
hast, einen Block zu erstellen.

765
00:56:44,790 --> 00:56:49,500
Herald: Gut, dann machen wir oben
auf dem Balkon weiter mit der 8. Bitte.

766
00:56:49,500 --> 00:56:52,600
Frage: Ja, das ganze Erstellen von
den Blöcken basiert ja darauf, dass

767
00:56:52,600 --> 00:56:56,680
Transaktionen in des System reinkommen.
Die Frage wäre jetzt, was passiert, wenn

768
00:56:56,680 --> 00:57:01,880
keine Transaktionen zur Verfügung stehen.
Werden dann Dummy-Transaktionen erzeugt,

769
00:57:01,880 --> 00:57:03,880
oder leere Blöcke, oder was passiert dann?

770
00:57:03,880 --> 00:57:08,220
vimja: Nein, das kannst du sehen, wenn du
ganz zurückgehst, die ersten Blöcke, die

771
00:57:08,220 --> 00:57:11,690
überhaupt erstellt wurden, dort gab es ja
noch keine Transaktionen. Was hätte auch

772
00:57:11,690 --> 00:57:16,550
überwiesen werden sollen wenn niemand Geld
hat. Und da war es dann halt so, dass

773
00:57:16,550 --> 00:57:21,180
der Block enthält dann nur die Coin-based-
Transaktion. Der Miner wird ja immer

774
00:57:21,180 --> 00:57:25,000
eine Coin-based-Transaktion machen.
Einfach, weil es für ihn interessant ist.

775
00:57:25,000 --> 00:57:33,150
Und dann erstellt er halt einen Block, der
nur diese Coin-based-Transaktion enthält.

776
00:57:33,150 --> 00:57:35,940
Herald: Dann machen wir weiter
hier vorne mit der 2. Bitte.

777
00:57:35,940 --> 00:57:38,300
<i>Mikro 2 will Mikro 4 Vorrang geben</i>
Bitte?

778
00:57:38,300 --> 00:57:41,720
Wenn du nicht möchtest, dann machen
wir mit der 4 weiter! Sehr fair von dir!

779
00:57:41,720 --> 00:57:48,830
Frage: Och, dankeschön. Ich habe das Thema
‚Blockchain‘ in verschiedenen Kontexten

780
00:57:48,830 --> 00:57:51,480
jetzt im letzten Jahr sehr viel gesehen.
Es ist fast ein Buzzword in sehr sehr

781
00:57:51,480 --> 00:57:55,900
vielen Branchen, von FinTech bis zu
IoT oder wo auch immer. Konntest du

782
00:57:55,900 --> 00:57:59,920
im Kontext deiner Arbeit ein bisschen
so einen Trend raussehen, wo sich da

783
00:57:59,920 --> 00:58:04,100
erste Anwendungen
wirklich bewähren können?

784
00:58:04,100 --> 00:58:08,420
vimja: Erste Anwendungen gibt es ja bereits.
Du kannst mit Bitcoin Dinge bezahlen.

785
00:58:08,420 --> 00:58:13,930
Aber das ist so ein wenig eine Sache.
Eines, was ich gesehen habe, wo ich mich

786
00:58:13,930 --> 00:58:17,800
aber schlicht weigere mich zu beteiligen,
ist halt dass Banken das zu verwenden

787
00:58:17,800 --> 00:58:22,890
versuchen, um die Transaktionen zwischen
den Banken zu regeln. Da wird es ja,

788
00:58:22,890 --> 00:58:26,410
glaube ich, im Anschluss im Saal G
einen Talk geben dazu, wie das heute

789
00:58:26,410 --> 00:58:30,980
gemacht wird, wie Banken zwischeneinander
Geld austauschen. Und das möchte man

790
00:58:30,980 --> 00:58:34,220
in Zukunft mit Bitcoin [<i>eher: Blockchain</i>]
machen. Und da sind die Banken auch dran,

791
00:58:34,220 --> 00:58:38,940
sehr viel Geld und sehr viel Zeit rein zu
investieren. Das ist halt sehr schade,

792
00:58:38,940 --> 00:58:43,210
dass diese eigentlich coole Technologie
jetzt für sowas verwendet werden soll.

793
00:58:43,210 --> 00:58:48,940
Aber ich denke das ist eine Anwendung die
kommt. Dann eben einfache Kryptowährungen,

794
00:58:48,940 --> 00:58:53,540
wie etwa Bitcoin, um Dinge
zu bezahlen. Und auch…

795
00:58:53,540 --> 00:58:57,590
ich denke auch mit Ethereum, eben gerade
diese Smart Contracts werden kommen,

796
00:58:57,590 --> 00:59:01,340
dass man halt eben irgendwelche Dinge,
irgendwelche Third Parties, die man

797
00:59:01,340 --> 00:59:05,970
verwendet für Dinge zu regeln, ersetzen
wir jetzt aber. Was jetzt als Erstes

798
00:59:05,970 --> 00:59:09,560
quasi den Durchbruch schaffen wird und
als Großes eingesetzt werden wird,

799
00:59:09,560 --> 00:59:11,770
kann ich dir nicht sagen.

800
00:59:11,770 --> 00:59:15,630
Herald: Gut, dann, wir sind so ganz knapp
an der Zeit, aber du darfst deine Frage

801
00:59:15,630 --> 00:59:17,050
auf jeden Fall stellen, bitte!

802
00:59:17,050 --> 00:59:20,520
Frage: Ist auch nur eine ganz kurze,
schnelle Frage. Gibt es einen Schutz

803
00:59:20,520 --> 00:59:24,460
gegen DDoS, dass ich irgendwie das
Netzwerk mit falschen Transaktionen

804
00:59:24,460 --> 00:59:27,890
bombardiere, und dann bricht alles
zusammen, gibt es da irgendwie

805
00:59:27,890 --> 00:59:29,120
einen Schutz dagegen?

806
00:59:29,120 --> 00:59:31,930
vimja: Ja, das war ja ganz interessant.
Das hat es glaube ich vor über einem Jahr

807
00:59:31,930 --> 00:59:35,050
gegeben, bei Bitcoin, dass das passiert
ist, und die waren sich dann

808
00:59:35,050 --> 00:59:38,630
nicht so ganz einig in der Community,
weil die mögen sich sowieso nicht mehr,

809
00:59:38,630 --> 00:59:42,270
und ‚kriegen‘ nur miteinander, die waren
sich da nicht so ganz einig, ob das jetzt

810
00:59:42,270 --> 00:59:46,391
ein Test war, oder ob das ein DDoS war.
Und das Interessante daran ist ja,

811
00:59:46,391 --> 00:59:51,630
dass es ja tatsächlich Geld kostet, eine
Transaktion zu machen. Also du zahlst

812
00:59:51,630 --> 00:59:55,790
zuerst eine Transaction-Gebühr, und der
Schutz sollte eigentlich, hoffentlich,

813
00:59:55,790 --> 00:59:59,520
sein, dass das da zu teuer ist.
Aber offenbar gibt es immer noch

814
00:59:59,520 --> 01:00:04,340
so viele Bitcoin-Millionäre, die einfach
Bitcoins haben zum Davonschmeißen,

815
01:00:04,340 --> 01:00:08,200
und die dann sowas tun können. Es
wird auf jeden Fall an irgendwelchen

816
01:00:08,200 --> 01:00:11,770
Schutzmechanismen gearbeitet, aber
was das ist… <i>zuckt mit den Schultern</i>

817
01:00:11,770 --> 01:00:15,530
Also was es gibt, in Bitcoin,
ist dieses Replace-by-Fee,

818
01:00:15,530 --> 01:00:22,890
damit die Transaction-Gebühr nach
der Veröffentlichung der Transaktion

819
01:00:22,890 --> 01:00:25,920
anschließend noch erhöht werden
kann. Und damit kannst du halt…

820
01:00:25,920 --> 01:00:29,030
wenn du jetzt siehst, es kommen sehr viele
DDoS-Transaktionen rein, kannst du halt

821
01:00:29,030 --> 01:00:33,640
im Nachhinein die Transaction-Gebühr
erhöhen, und das dadurch den Minern

822
01:00:33,640 --> 01:00:38,480
quasi schmackhaft machen, deine
valide Transaktion zu includen.

823
01:00:38,480 --> 01:00:43,600
Dieses Replace-by-Fee, dieses RBF,
ist aber sehr stark umstritten, und

824
01:00:43,600 --> 01:00:49,580
wird auch standardmäßig nicht
aktiviert von der Client-Software.

825
01:00:49,580 --> 01:00:56,290
Herald: Gut, dann danke vimja, für diese
großartige Einführung in die Blockchain!

826
01:00:56,290 --> 01:01:01,030
<i>Beifall</i>

827
01:01:01,030 --> 01:01:05,070
<i>Abspannmusik</i>

828
01:01:05,070 --> 01:01:24,901
<i>Untertitel erstellt von c3subtitles.de
im Jahr 2017. Mach mit und hilf uns!</i>