WEBVTT

00:00:13.830 --> 00:00:14.830
*33C3-Vorspannmusik*

00:00:14.830 --> 00:00:19.420
Herald: Gut, dann machen wir
weiter mit dem nächsten Vortrag.

00:00:19.420 --> 00:00:24.509
Der ist von vimja, der ist
Informatikstudent aus Bern in der Schweiz,

00:00:24.509 --> 00:00:28.740
und er arbeitete bzw. er
beschäftigte sich mit Bitcoin

00:00:28.740 --> 00:00:33.210
und Ethereum, und schrieb seine
Bachelorarbeit über die Suche

00:00:33.210 --> 00:00:38.210
nach Informationen in der Bitcoin-
Blockchain. Und da macht es total Sinn,

00:00:38.210 --> 00:00:43.120
dass der uns jetzt eine Einführung
zu Blockchains präsentieren wird.

00:00:43.120 --> 00:00:45.580
Ein großer Applaus für vimja!

00:00:45.580 --> 00:01:03.570
*Applaus mit Pfeifen und Jubel*
Das ist deine Bühne!

00:01:03.570 --> 00:01:09.909
*weiterhin Applaus*

00:01:09.909 --> 00:01:18.580
vimja: Toll, das ist jetzt
gerade kaputtgegangen.

00:01:18.580 --> 00:01:19.580
*Gelächter*

00:01:19.580 --> 00:01:21.300
So ist es besser.

00:01:21.300 --> 00:01:22.390
*Applaus*
Danke.

00:01:22.390 --> 00:01:23.880
Genau, das geht jetzt
natürlich auch nicht.

00:01:23.880 --> 00:01:25.070
Mache ich es halt von Hand.

00:01:25.070 --> 00:01:26.840
Ist vermutlich, weil ihr alle das Wi-Fi
braucht, geht das 2,4-GHz-Band nicht mehr.

00:01:26.840 --> 00:01:30.570
Ja das hat er euch ja alles
schon gesagt, der Herald.

00:01:30.570 --> 00:01:35.150
In dieser Zeit, in der ich mich
mit Blockchains befasst habe,

00:01:35.150 --> 00:01:39.270
durfte ich natürlich sehr viele
sehr interessante Dinge lernen,

00:01:39.270 --> 00:01:41.830
und ich möchte jetzt heute abend
einen Teil dieses Wissens

00:01:41.830 --> 00:01:45.150
an euch weitergeben. Genau.

00:01:45.150 --> 00:01:52.710
Das Ganze ist natürlich ein sehr komplexes
Thema, das viele komplizierte Dinge

00:01:52.710 --> 00:01:56.120
enthält, und deshalb fangen wir jetzt mit
etwas sehr einfachem an, was wir alles

00:01:56.120 --> 00:01:59.850
kennen. Und zwar herkömmliche
Besitzsysteme – also Systeme,

00:01:59.850 --> 00:02:04.100
die ausdrücken wem etwas gehört. Und,
eigentlich, mit der Erkenntnis, dass man

00:02:04.100 --> 00:02:11.190
all diese Besitzsysteme als
Zustandsübergangssysteme darstellen kann.

00:02:11.190 --> 00:02:16.019
Das gilt sowohl für Finanzsysteme,
die wir haben um Geld zu verwalten,

00:02:16.019 --> 00:02:20.090
als auch etwa für Grundstücke, also
Systeme mit denen wir verwalten,

00:02:20.090 --> 00:02:21.620
wem ein Grundstück gehört.

00:02:21.620 --> 00:02:27.520
Das Mapping funktioniert dann in etwa
so, dass wir sagen, der Zustand ist

00:02:27.520 --> 00:02:33.510
die Sammlung der Informationen wem
was gehört. Und jedes Übertragen

00:02:33.510 --> 00:02:37.720
eines Besitzes ist eine Transition,
die zu einem neuen Zustand führt.

00:02:37.720 --> 00:02:42.120
Also am Beispiel eines finanziellen
Systems sagen wir, der Zustand ist

00:02:42.120 --> 00:02:46.959
die Sammlung aller Konten, die es gibt.
Das drückt für jede Person aus,

00:02:46.959 --> 00:02:51.230
wieviel Geld ihr gehört. Und ein Übergang
ist, wenn jemand eine Transaktion macht,

00:02:51.230 --> 00:02:54.160
also Geld überweist, von einem Konto
zu einem anderen, dann führt das

00:02:54.160 --> 00:02:58.440
zu einem neuen Zustand.
So, das sehen wir hier abgebildet

00:02:58.440 --> 00:03:02.650
mit Grundstücken. Wir sehen hier, der
Zustand, der enthält diese Information,

00:03:02.650 --> 00:03:06.760
wem die Grundstücke gehören.
Und dann verkauft der Bob

00:03:06.760 --> 00:03:10.890
sein Grundstück Nr. 42 an Alice und
das führt zu einem neuen Zustand.

00:03:10.890 --> 00:03:15.660
Ich habe da den Unterschied markiert,
damit der eindeutig sichtbar ist.

00:03:15.660 --> 00:03:20.410
Nun, in all diesen Systemen ist es sehr
wichtig, dass sich alle Teilnehmer des

00:03:20.410 --> 00:03:25.730
Systems auf einen Zustand einigen können.
Dass sie sich einig sind, wem was gehört.

00:03:25.730 --> 00:03:30.050
Denn wenn sie das nicht können, sind
Angriffe auf das System möglich,

00:03:30.050 --> 00:03:32.390
insbesondere der sogenannte
Double-Spend-Angriff,

00:03:32.390 --> 00:03:37.840
der in der Blockchain-Welt bekannt und
gefürchtet ist. Und was bedeutet das?

00:03:37.840 --> 00:03:41.670
Das ist ganz einfach, wenn jemand etwas
zweimal ausgibt. Bei Geld ist das ein

00:03:41.670 --> 00:03:45.310
wenig abstrakt (also wie gibt man zweimal
dasselbe Geld aus), aber bei Grundstücken

00:03:45.310 --> 00:03:49.450
ist das ganz einfach. Stellen wir uns vor,
jemand verkauft dasselbe Grundstück

00:03:49.450 --> 00:03:52.430
zweimal. Das ist natürlich kriminell
und darf nicht vorkommen.

00:03:52.430 --> 00:03:57.850
Schauen wir uns jetzt mal an wie
das funktioniert. Stellen wir uns vor,

00:03:57.850 --> 00:04:01.940
Malroy hat ein schönes Grundstück,
das Grundstück Nr. 5. Und sowohl Alice

00:04:01.940 --> 00:04:05.700
als auch Bob möchten gerne das
Grundstück kaufen. Und Malroy

00:04:05.700 --> 00:04:09.750
wird jetzt versuchen, das an beide zu
verkaufen. Also trifft er sich mit Alice.

00:04:09.750 --> 00:04:13.761
Das ist also jetzt der aktuelle Zustand.
Wir haben gesehen, das Grundstück Nr. 5

00:04:13.761 --> 00:04:20.430
gehört hier dem Malroy. Der trifft sich
mit Alice. Und er verkauft es an Alice.

00:04:20.430 --> 00:04:24.550
Er überweist ihr das Grundstück. Wir sehen
diese Transition – überweist das Grundstück

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,

00:04:29.129 --> 00:04:31.990
der hat davon nichts mitgekriegt.
Irgendwie – Bob und Alice wissen

00:04:31.990 --> 00:04:36.300
immer noch nicht recht wie man sicher
miteinander kommuniziert. Und deshalb

00:04:36.300 --> 00:04:39.199
weiß der Bob jetzt nichts davon, dass
die Alice das Grundstück gekauft hat.

00:04:39.199 --> 00:04:43.680
Er denkt, das Grundstück gehört immer noch
Malroy. Also trifft er sich mit Malroy.

00:04:43.680 --> 00:04:47.939
Und auch er einigt sich mit Malroy auf
einen Preis. Und Malroy tut jetzt so,

00:04:47.939 --> 00:04:52.080
als würde er den Besitz des
Grundstücks an Bob übertragen.

00:04:52.080 --> 00:04:56.460
Und für Bob sieht die Welt jetzt so
aus, d.h. Bob ist überzeugt, das ist

00:04:56.460 --> 00:05:00.339
der korrekte Zustand des Systems.
Da haben wir natürlich ein Problem,

00:05:00.339 --> 00:05:03.290
weil Bob und Alice, die sind sich
jetzt gar nicht einig darüber,

00:05:03.290 --> 00:05:07.499
wem das Grundstück gehört. Ja, Malroy
ist natürlich abgehauen mit dem Geld.

00:05:07.499 --> 00:05:10.980
Und das System ist kaputt, weil Bob
und Alice die können nicht mehr

00:05:10.980 --> 00:05:15.050
miteinander handeln. Und auch wenn
jetzt jemand anderes das Grundstück

00:05:15.050 --> 00:05:17.909
kaufen möchte: bei wem kauft er es
denn jetzt? Was ist denn rechtmäßig?

00:05:17.909 --> 00:05:24.199
Nun, in der Welt der Grundstücke gibt
es dafür eine ganz einfache Lösung,

00:05:24.199 --> 00:05:28.530
nämlich das Grundbuchamt. Und das
Grundbuchamt fungiert eigentlich

00:05:28.530 --> 00:05:33.310
als zentrale Referenzstelle,
die den Zustand verwaltet,

00:05:33.310 --> 00:05:37.460
und alle Änderungen verwaltet. Jedesmal
wenn jemand ein Grundstück verkauft,

00:05:37.460 --> 00:05:42.089
muss das über das Grundbuchamt erledigt
werden. Das Grundbuchamt überprüft,

00:05:42.089 --> 00:05:45.580
dass das überhaupt zulässig ist, ob das
Grundstück wirklich der Person gehört

00:05:45.580 --> 00:05:50.169
und führt das dann nach. Und so kann das
Grundbuchamt diese einfachen Angriffe

00:05:50.169 --> 00:05:58.280
verhindern. Diese (?)(?)(?) Lösung
funktioniert auch für Finanzsysteme.

00:05:58.280 --> 00:06:02.770
Also wenn wir an Banken denken, wenn ich
ein Konto habe, da ist dann halt die Bank

00:06:02.770 --> 00:06:07.289
die zentrale Autorität, welche den Zustand
verwaltet. Für jede… jedesmal,

00:06:07.289 --> 00:06:11.499
wenn ich eine Transaktion mache, also Geld
überweise, überprüft die Bank vorher,

00:06:11.499 --> 00:06:15.759
ob ich wirklich das nötige Geld dazu
habe. Und dann wird mein Kontostand

00:06:15.759 --> 00:06:21.999
nachgeführt. Und die verwaltet so
für alle Teilnehmer den Zustand.

00:06:21.999 --> 00:06:26.919
Und das funktioniert eigentlich erstaunlich
gut. Nun wollen wir ein System, mit dem

00:06:26.919 --> 00:06:31.229
wir Zahlungen über das Internet abwickeln
können. Und wir hätten gerne, dass das

00:06:31.229 --> 00:06:34.849
dezentral ist. Weil, wenn das nicht
dezentral ist, dann kann natürlich

00:06:34.849 --> 00:06:39.909
eine zentrale Autorität das System
zensieren und manipulieren.

00:06:39.909 --> 00:06:43.539
Und eine zentrale Stelle kann angegriffen
werden. Ich denke, wir haben das alle

00:06:43.539 --> 00:06:47.539
in den letzten Jahren beobachten müssen,
wie Paypal sehr einfach willkürlich

00:06:47.539 --> 00:06:52.650
Konten sperrt, und das System zensiert.
So, und deshalb brauchen wir ein

00:06:52.650 --> 00:06:55.550
besseres System, eine bessere
Lösung für das Internetzeitalter.

00:06:55.550 --> 00:06:58.550
Und diese bessere Lösung ist
natürlich die ‚Blockchain‘.

00:06:58.550 --> 00:07:05.220
Die Blockchain bringt einige ganz
unglaubliche Eigenschaften mit sich.

00:07:05.220 --> 00:07:09.529
Die Blockchain braucht keine zentrale
Stelle um den Zustand zu verwalten.

00:07:09.529 --> 00:07:12.930
Die Teilnehmer des Systems müssen sich
gegenseitig nicht vertrauen, sie müssen

00:07:12.930 --> 00:07:16.419
sich gegenseitig nicht kennen. Sie müssen
nicht einmal wissen, wieviele Leute

00:07:16.419 --> 00:07:19.990
denn eigentlich da teilnehmen. Und
trotzdem können die sich alle immer

00:07:19.990 --> 00:07:21.879
auf einen Zustand des Systems einigen.

00:07:21.879 --> 00:07:27.960
Ich werde das jetzt demonstrieren,
die Regeln, die wir brauchen

00:07:27.960 --> 00:07:32.250
um das zu ermöglichen. Anhand
einer sehr einfachen Blockchain,

00:07:32.250 --> 00:07:36.659
die in diesem ersten Kapitel auch
noch keinen Proof-of-Work hat. Also

00:07:36.659 --> 00:07:39.149
diese erste Blockchain wird noch
angreifbar sein. Und ich werde auch

00:07:39.149 --> 00:07:42.970
zeigen wie es geht. Und erst im nächsten
Kapitel dann werde ich erklären,

00:07:42.970 --> 00:07:47.080
welche Maßnahmen wir ergreifen
müssen, um Angriffe zu verhindern.

00:07:47.080 --> 00:07:51.659
Und das Ganze fängt an mit dem Netzwerk
welches wir nutzen. Also wir sagen quasi,

00:07:51.659 --> 00:07:55.039
wir sind alle diese Leute, und wir würden
gerne miteinander Transaktionen machen

00:07:55.039 --> 00:07:59.759
können. Und zuerst einigen wir uns
alle auf einen Ursprungszustand.

00:07:59.759 --> 00:08:03.319
Damit fangen wir an. Wir sagen z.B.
„am Anfang gehört allen nichts“.

00:08:03.319 --> 00:08:08.429
Das ist ein leerer Zustand. Und dann
brauchen wir ein p2p-Netzwerk.

00:08:08.429 --> 00:08:13.529
Und jedesmal wenn jemand Geld überweist
an jemand anderes, dann veröffentlicht er

00:08:13.529 --> 00:08:17.490
die Transaktion in diesem Netzwerk,
und das Netzwerk leitet die Transaktion

00:08:17.490 --> 00:08:21.949
solange an alle Teilnehmer weiter,
bis alle Teilnehmer diese Transaktion

00:08:21.949 --> 00:08:27.169
gesehen haben. Das bringt
natürlich viele Probleme mit sich.

00:08:27.169 --> 00:08:30.729
Das Netzwerk ist irgendwie nicht
synchronisiert, nicht alle Leute

00:08:30.729 --> 00:08:34.960
sehen die gleichen Transaktionen, die
Reihenfolge der Transaktionen ist unklar.

00:08:34.960 --> 00:08:38.510
Leute werden versuchen das anzugreifen
– das wird dazu führen, dass es

00:08:38.510 --> 00:08:42.458
Transaktionen gibt die nicht miteinander
kompatibel sind. Und irgendwie

00:08:42.458 --> 00:08:45.310
Transaktionen, die abhängen von
nicht-kompatiblen Transaktionen und

00:08:45.310 --> 00:08:49.180
dann auch wieder nicht kompatibel sind.
Das ist ein riesengroßes Durcheinander da.

00:08:49.180 --> 00:08:52.370
Und deshalb brauchen wir jetzt
eine Möglichkeit, wie wir uns alle

00:08:52.370 --> 00:08:57.180
auf einen Zustand, auf einen Konsens
einigen können. Und – wie gesagt –

00:08:57.180 --> 00:08:59.740
das ist jetzt die ‚Blockchain‘.

00:08:59.740 --> 00:09:04.820
Und wir definieren einige Regeln,
die wir anwenden um uns zu einigen.

00:09:04.820 --> 00:09:08.240
Wir sagen, wir gruppieren die Transaktionen
die vorher so lose auf dem Netzwerk waren

00:09:08.240 --> 00:09:13.470
zu Blöcken. Die Blöcke hängen alle
voneinander ab. Wir sagen dann auch,

00:09:13.470 --> 00:09:17.780
der aktuelle Zustand des Netzwerks ist das
Ende der längsten Kette zusammenhängender

00:09:17.780 --> 00:09:22.720
Blöcke. Und die Blöcke müssen einige
Kriterien erfüllen. Ich habe das da…

00:09:22.720 --> 00:09:26.940
also das ist jetzt quasi der Ur… der
leere Zustand, mit dem wir beginnen.

00:09:26.940 --> 00:09:32.300
Und da kommen da Transaktionen
über das Netzwerk. Und irgendwann

00:09:32.300 --> 00:09:36.020
macht jemand einen Block der diese
Transaktionen zusammenfasst. Und jetzt

00:09:36.020 --> 00:09:40.220
sehen wir am Ende dieses Blocks ist
der Zustand. Wenn ich diesen Zustand

00:09:40.220 --> 00:09:43.110
nachvollziehen will dann nehme ich den
leeren Ursprungszustand, und dann

00:09:43.110 --> 00:09:47.080
jede Transaktion aus dem ersten Block,
und dann wende ich diese Transaktionen,

00:09:47.080 --> 00:09:51.080
eine nach der anderen, auf den Zustand
an, und dann erhalte ich den Endzustand.

00:09:51.080 --> 00:09:55.421
Mit der Zeit kommen
neue Transaktionen rein

00:09:55.421 --> 00:10:00.140
über das Netzwerk. Und diese Transaktionen
werden nicht Teil des Zustands

00:10:00.140 --> 00:10:02.950
– wir haben ja gesagt der Zustand ist das
Ende der längsten Kette von Blöcken,

00:10:02.950 --> 00:10:06.270
und die sind in keinem Block. Erst wenn
jemand einen Block daraus macht,

00:10:06.270 --> 00:10:09.890
werden die Teil des Zustands.
Wir sehen auch, die Blöcke hängen jeweils

00:10:09.890 --> 00:10:13.540
voneinander ab, die haben so einen Pfeil,
der sie miteinander verbindet, also

00:10:13.540 --> 00:10:18.590
jeder Block zeigt auf den vorhergehenden
Block, und bildet so eben diese Kette

00:10:18.590 --> 00:10:23.650
von Blöcken. Nun, jetzt versucht trotzdem
jemand da eine bösartige Transaktion

00:10:23.650 --> 00:10:27.810
zu machen, die mit den anderen nicht
kompatibel ist. Da macht jemand

00:10:27.810 --> 00:10:31.570
einen Block daraus. Und jetzt sagen
wir aber einfach, Blöcke, die

00:10:31.570 --> 00:10:34.960
Transaktionen enthalten welche sich
widersprechen sind nicht valide.

00:10:34.960 --> 00:10:38.360
Der Block, den kann zwar jemand
erstellen, aber wir sagen dann, das ist

00:10:38.360 --> 00:10:42.180
kein valider Block, der wird vom Netzwerk
nicht akzeptiert. Und der wird auch

00:10:42.180 --> 00:10:48.010
nicht Teil des Zustands. Also wenn jemand
einen Block bauen will und eine dieser

00:10:48.010 --> 00:10:52.610
Transaktionen enthält, dann muss sich
derjenige der den Block erstellt

00:10:52.610 --> 00:10:56.090
entscheiden welche der Transaktionen
denn jetzt enthalten sein sollen

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,

00:11:00.280 --> 00:11:04.660
das ist dem Typen ganz allein überlassen.
Er kann das selber entscheiden was er da

00:11:04.660 --> 00:11:10.350
reinpacken will. Dann kommen mit
der Zeit neue Transaktionen rein.

00:11:10.350 --> 00:11:14.300
Und jetzt könnte es sein, dass jemand so
einen Block Nummer 4 macht, welcher

00:11:14.300 --> 00:11:19.150
jetzt trotzdem wieder die böse Transaktion
enthält. Und dann sagen wir aber einfach,

00:11:19.150 --> 00:11:21.911
Blöcke welche Transaktionen enthalten,
welche nicht kompatibel sind

00:11:21.911 --> 00:11:25.450
mit Transaktionen in älteren Blöcken sind
auch ungültig, und der Block wird auch

00:11:25.450 --> 00:11:29.870
nicht Teil des Zustands. So. Was aber
gültig ist, ist jemand der einen Block

00:11:29.870 --> 00:11:33.880
Nummer 3 macht, der so aussieht. Und jetzt
haben wir das Problem: wir haben gesagt,

00:11:33.880 --> 00:11:36.640
der Zustand ist die längste Kette von
Blöcken. Hier ist jetzt der Zustand

00:11:36.640 --> 00:11:40.370
nicht mehr eindeutig definiert und da muss
jetzt halt jeder Teilnehmer des Netzwerkes

00:11:40.370 --> 00:11:44.250
selbst entscheiden wie er damit umgeht,
was er jetzt als Zustand anerkennt.

00:11:44.250 --> 00:11:48.700
So, aber dann kommen halt neue
Transaktionen wieder rein. Und irgendwann

00:11:48.700 --> 00:11:52.890
baut jemand einen Block Nummer 4, der
diese Transaktion enthält. Und dadurch,

00:11:52.890 --> 00:11:58.130
dass der Block Nr. 4 auf den vorherigen
Block Nr. 3 verweist, ist es jetzt klar,

00:11:58.130 --> 00:12:01.530
von welchem Block der abhängt.
Und damit ist die Kette auch wieder klar,

00:12:01.530 --> 00:12:06.300
und die längste Kette wird wieder zum
Zustand. So. Jetzt habe ich gesagt,

00:12:06.300 --> 00:12:09.830
diese Blockchain die ich jetzt beschrieben
habe hat keinen Proof-of-Work und folglich

00:12:09.830 --> 00:12:14.510
ist sie angreifbar für ein double-spend.
Sagen wir Malroy würde gerne

00:12:14.510 --> 00:12:19.050
ein Fahrrad klauen. Er geht da so in den
Fahrradladen von Alice, und möchte dort

00:12:19.050 --> 00:12:23.030
gerne ein Fahrrad kaufen, das kostet
jetzt 1000 Euro in dem Beispiel.

00:12:23.030 --> 00:12:26.600
Ich werde jetzt… hier habe ich
die Darstellung etwas geändert,

00:12:26.600 --> 00:12:30.370
diese Vierecke mit Pfeilen dran, das sind
jetzt halt einfach Blöcke. Ich werde

00:12:30.370 --> 00:12:35.380
nicht mehr jede Transaktion einzeln
zeichnen. Und die sehen den Zustand,

00:12:35.380 --> 00:12:39.110
wie er da ist. Da sind all die Konten
aufgeführt, unter anderem diejenigen

00:12:39.110 --> 00:12:44.380
von Alice und Malroy. So.
Malroy geht also in den Laden,

00:12:44.380 --> 00:12:51.340
sucht sich das [Fahrrad] aus, geht zum
Tresen und macht dort die Transaktion

00:12:51.340 --> 00:12:56.880
an Alice. Und diese Transaktion wird
übers Netzwerk zu Alice weitergeleitet.

00:12:56.880 --> 00:13:00.260
Sie sieht die Transaktion, aber da sie
noch nicht Teil eines Blockes ist,

00:13:00.260 --> 00:13:04.260
ist sie auch noch nicht Teil des Zustands.
Irgendwann aber erstellt jemand halt

00:13:04.260 --> 00:13:07.880
einen Block der diese Transaktion enthält.
Die ist jetzt Teil des Zustandes.

00:13:07.880 --> 00:13:12.610
Wir sehen im Zustand des Systems,
dass Alice das Geld erhalten hat.

00:13:12.610 --> 00:13:17.130
Sie gibt das Fahrrad an Malroy, und der
fährt davon. Neue Blöcke kommen dazu.

00:13:17.130 --> 00:13:21.770
Und jetzt startet Malroy den Angriff.
Und was Malroy macht, er erstellt

00:13:21.770 --> 00:13:25.230
eine alternative Transaktion, die dasselbe
Geld überweist, diesmal aber nicht

00:13:25.230 --> 00:13:30.260
an Alice sondern an sich selbst. Genauer:
an ein zweites Konto das ebenfalls ihm

00:13:30.260 --> 00:13:35.420
gehört. Und er erstellt einen alternativen
Block, der diese Transaktion enthält.

00:13:35.420 --> 00:13:41.350
Und dann erstellt er ganz viele neue
Blöcke die davon abhängen. Solange,

00:13:41.350 --> 00:13:44.920
bis seine Kette von Blöcken länger
ist als die anderen, also die Kette,

00:13:44.920 --> 00:13:49.570
die zur Zeit auf dem Netzwerk ist. Und
dann veröffentlicht er die gesamte Kette

00:13:49.570 --> 00:13:54.040
auf dem Netzwerk. Und jetzt ist seine
Kette die längste Kette. Die wird

00:13:54.040 --> 00:13:57.920
vom Netzwerk als Zustand anerkannt. Und
in diesem Zustand hat er das Geld erhalten.

00:13:57.920 --> 00:14:02.680
Alice hat das Geld nicht erhalten. Und
Malroy hat das Fahrrad erfolgreich

00:14:02.680 --> 00:14:05.720
gestohlen. So, das hat also funktioniert.

00:14:05.720 --> 00:14:09.650
Wir müssen das verhindern. Das
Problem weshalb Malroy diesen Angriff

00:14:09.650 --> 00:14:14.250
machen konnte ist natürlich, dass er in
einer sehr kurzen Folge viele Blöcke

00:14:14.250 --> 00:14:18.230
erstellen konnte. Also das Problem ist
eigentlich, es ist zu einfach neue Blöcke

00:14:18.230 --> 00:14:21.810
zu erstellen. Also machen wir es halt
schwieriger, neue Blöcke zu erstellen.

00:14:21.810 --> 00:14:27.030
Und dazu sagen wir, für jeden Block
der erstellt wird, muss eine Aufgabe

00:14:27.030 --> 00:14:33.670
gelöst werden, eine Challenge.
Und um diese Challenge zu erstellen,

00:14:33.670 --> 00:14:40.120
muss man halt Zeit, und Rechenzeit
aufwenden. Die Lösung für diese Aufgabe

00:14:40.120 --> 00:14:45.161
nennen wir den Proof-of-Work. Und den
Prozess um den Proof-of-Work zu erstellen

00:14:45.161 --> 00:14:49.560
nennen wir das ‚Mining‘. Und dann sagen
wir, zusammen mit jedem neuen Block

00:14:49.560 --> 00:14:53.800
muss der passende Proof-of-Work
veröffentlicht werden. Und nur Blöcke,

00:14:53.800 --> 00:14:58.210
welche einen passenden Proof-of-Work haben
werden vom Netzwerk als Teil des Zustands

00:14:58.210 --> 00:15:02.940
anerkannt. Jetzt funktioniert das
Erstellen neuer Blöcke etwas anders.

00:15:02.940 --> 00:15:06.810
Und zwar ist es jetzt so, dass ein Block
nicht mehr einfach entsteht, sondern

00:15:06.810 --> 00:15:11.120
ein ‚Miner‘ muss daran arbeiten. Jeder
Miner arbeitet natürlich für sich selbst

00:15:11.120 --> 00:15:14.540
daran, einen neuen Block zu erstellen.
Wir sehen hier, der Block an dem der Miner

00:15:14.540 --> 00:15:19.991
arbeitet, ist hier so gestrichelt
markiert. Und dann, wenn der Miner

00:15:19.991 --> 00:15:23.920
daran arbeitet, kommen neue Transaktionen
rein. Und irgendwann gelingt es dem Miner

00:15:23.920 --> 00:15:27.910
den Block fertigzustellen. In dem Moment
veröffentlicht er den Block zusammen mit

00:15:27.910 --> 00:15:31.770
dem Proof-of-Work im Netzwerk. Der wird
vom Netzwerk anerkannt, und der Miner

00:15:31.770 --> 00:15:38.940
beginnt sofort an einem neuen Block zu
arbeiten, und das geht dann halt so weiter.

00:15:38.940 --> 00:15:43.990
Nun, die Funktion die wir brauchen um das
Erstellen der Blöcke schwierig zu machen

00:15:43.990 --> 00:15:49.070
muss einige Bedingungen erfüllen. Sie
muss natürlich schwierig sein zu lösen.

00:15:49.070 --> 00:15:53.460
Dann muss aber… obwohl es lange gehen
muss die zu erstellen, muss es sehr

00:15:53.460 --> 00:15:56.950
einfach sein, das Ergebnis zu prüfen.
Also wenn ich einen Block erhalte, und

00:15:56.950 --> 00:16:00.460
den passenden Proof-of-Work, muss
ich – zack! – sofort sagen können,

00:16:00.460 --> 00:16:03.390
der Proof-of-Work ist gültig oder nicht,
weil ich will ja entscheiden, ob das

00:16:03.390 --> 00:16:05.300
Teil meines Zustandes
sein soll oder nicht.

00:16:05.300 --> 00:16:11.960
Und dann ist es wichtig, dass die
Funktion abhängt von genau dem Block,

00:16:11.960 --> 00:16:15.230
für den sie erstellt wird. Also der
Proof-of-Work soll nur genau

00:16:15.230 --> 00:16:19.860
für den einen Block gültig sein.
Das ist sehr wichtig, denn ansonsten

00:16:19.860 --> 00:16:23.589
könnte Malroy auf Vorrat über
mehrere Wochen hinweg einfach

00:16:23.589 --> 00:16:27.220
Proof-of-Works erstellen und dann die
einfach an einen Block ranflanschen,

00:16:27.220 --> 00:16:31.810
und so in kurzer Zeit trotzdem wieder
eine lange Kette erstellen. Wenn aber

00:16:31.810 --> 00:16:37.150
der Proof-of-Work direkt abhängig ist
vom Block für den er erstellt wird,

00:16:37.150 --> 00:16:40.150
dann muss Malroy mit dem Erstellen
des Proof-of-Work so lange warten,

00:16:40.150 --> 00:16:44.290
bis der vorhergehende Block bekannt
ist und damit auch ihm bekannt ist,

00:16:44.290 --> 00:16:45.890
was er jetzt in den neuen Block packt.

00:16:45.890 --> 00:16:52.010
Und dann soll es auch noch möglich sein,
die Schwierigkeit der Aufgabe zu variieren.

00:16:52.010 --> 00:16:56.110
Denn damit das System als stabiles
Finanzsystem funktioniert, möchte ich

00:16:56.110 --> 00:16:59.250
gerne wissen, wie lange es geht von
dem Moment wo ich eine Transaktion

00:16:59.250 --> 00:17:04.409
veröffentliche bis sie Teil des Zustandes
wird. Und wenn das Netzwerk

00:17:04.409 --> 00:17:08.000
sehr viel mehr Rechenkraft hat, dann
geht es plötzlich schneller, neue Blöcke

00:17:08.000 --> 00:17:11.179
zu erstellen und dann will ich diese
Schwierigkeit anpassen können, damit es

00:17:11.179 --> 00:17:16.660
wieder länger geht. Nun jetzt, wo
das Mining nicht mehr einfach ist,

00:17:16.660 --> 00:17:20.169
und es aufwendig ist, müssen wir irgendwie
einen Incentive haben, damit die Leute

00:17:20.169 --> 00:17:25.089
es auch tun – also irgendeinen Anstoß.
So und wir sagen halt, der Miner,

00:17:25.089 --> 00:17:29.020
dem es gelingt einen Block zu erstellen,
der bekommt eine Belohnung,

00:17:29.020 --> 00:17:34.350
den sogenannten ‚Block Reward‘, und wir
implementieren das, indem wir sagen,

00:17:34.350 --> 00:17:38.590
der Miner darf für sich selbst eine
zusätzliche Transaktion in den Block

00:17:38.590 --> 00:17:41.999
hineinpacken, und mit dieser Transaktion
überweist er sich selbst Geld

00:17:41.999 --> 00:17:46.389
aus dem Nichts heraus. Wo das
Geld herkommt: es gibt eigentlich

00:17:46.389 --> 00:17:48.779
zwei Möglichkeiten, die populär sind.
Entweder sagen wir, das sind

00:17:48.779 --> 00:17:53.110
die Überweisungsgebühren der anderen
Transaktionen in dem Block.

00:17:53.110 --> 00:17:57.960
Oder dann sagen wir halt, das ist Geld,
welches neu geschaffen wird. Wir haben ja

00:17:57.960 --> 00:18:02.270
vorhin gesehen, wir haben einen leeren
Zustand als den Ursprungszustand definiert,

00:18:02.270 --> 00:18:06.309
und wenn wir das so tun, muss das
Geld, welches die Leute ausgeben,

00:18:06.309 --> 00:18:10.600
irgendwo herkommen. Und das ist halt eine
Möglichkeit, Geld in das System zu bringen,

00:18:10.600 --> 00:18:14.559
die nicht von einer zentralen Stelle
kontrolliert wird, und eigentlich

00:18:14.559 --> 00:18:21.320
eine faire Möglichkeit.
Etwas weiteres ist, dass…

00:18:21.320 --> 00:18:24.880
diese zusätzliche Transaktion macht
den Block natürlich individuell, denn

00:18:24.880 --> 00:18:29.770
jeder Miner wird das Geld an sich selbst
zu überweisen versuchen und, also,

00:18:29.770 --> 00:18:35.130
diese eine Transaktion wird für jeden
Miner anders sein. Und das stellt sicher,

00:18:35.130 --> 00:18:39.419
dass die alle an einem ein wenig anderen
Problem arbeiten. Wenn die alle

00:18:39.419 --> 00:18:43.659
versuchen würden, das genau selbe Problem
zu lösen, auf die genau selbe Art,

00:18:43.659 --> 00:18:47.809
dann würde es immer demjenigen als erstes
gelingen, der die meiste Rechenkraft hat,

00:18:47.809 --> 00:18:51.679
und das wollen wir nicht, denn dann würde
ja eine Person alle Blöcke erzeugen,

00:18:51.679 --> 00:18:54.950
und wir wollen ja, dass viele Personen
Blöcke erzeugen, damit das niemand

00:18:54.950 --> 00:18:59.830
zensieren kann. Dadurch dass das Problem,
an welchem sie arbeiten, für jeden Miner

00:18:59.830 --> 00:19:02.749
etwas anders ist, gelingt es halt
zwischendurch auch jemandem

00:19:02.749 --> 00:19:07.769
mit weniger Rechenkraft, als erstes eine
Lösung zu finden. Und in der Praxis

00:19:07.769 --> 00:19:12.159
geht das dann ganz gut, dass wir sagen
können, wer 20% der Rechenkraft hat

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

00:19:15.559 --> 00:19:21.770
zu finden. Dann muss der Miner halt
noch entscheiden, an welchem Block

00:19:21.770 --> 00:19:25.399
er arbeiten will. Aber der Miner will ja…
also an welchem Ende der Kette…

00:19:25.399 --> 00:19:29.129
Wir haben vorhin gesehen, es kann sein,
dass diese Ketten mehrere Enden haben.

00:19:29.129 --> 00:19:33.960
Aber das ist ganz einfach, denn der Miner
will ja den Reward kriegen. Der Reward ist

00:19:33.960 --> 00:19:37.169
eine Transaktion, welche nur dann
Teil des Zustandes wird wenn es Teil

00:19:37.169 --> 00:19:41.100
in einem Block ist, wenn es Teil der
längsten Kette ist. Und der Block ist

00:19:41.100 --> 00:19:44.399
nur dann Teil der längsten Kette wenn
er an diesem Ende angesetzt wird.

00:19:44.399 --> 00:19:49.039
Also arbeiten alle Miner am Ende der
längsten Kette. So, jetzt habe ich

00:19:49.039 --> 00:19:52.970
versprochen, dass wir so den Double-Spend
verhindern können, von vorhin.

00:19:52.970 --> 00:19:57.389
Wollen wir mal gucken, ob das geht!
Das Szenario ist wieder dasselbe.

00:19:57.389 --> 00:20:01.980
Malroy will das Fahrrad klauen,
im Laden von Alice.

00:20:01.980 --> 00:20:07.470
Der Unterschied ist, dass das Netzwerk
arbeiten muss um die Blöcke zu erstellen.

00:20:07.470 --> 00:20:12.730
Und dann geht es wieder so vonstatten.
Malroy erstellt jetzt zwei Transaktionen.

00:20:12.730 --> 00:20:17.110
Eine, um das Geld der Alice zu überweisen.
Diese Transaktion macht er öffentlich

00:20:17.110 --> 00:20:21.450
im Netzwerk, damit die von allen gesehen
werden kann. Und eine Transaktion,

00:20:21.450 --> 00:20:25.330
um das Geld an sich selbst zu überweisen.
Die behält er vorläufig geheim. Dann wird

00:20:25.330 --> 00:20:29.350
der vorhergehende Block fertiggestellt,
und sofort fängt das Netzwerk an

00:20:29.350 --> 00:20:34.220
den nächsten Block zu erstellen. Das
Netzwerk enthält in dem Block natürlich

00:20:34.220 --> 00:20:37.750
die Transaktion von Malroy an Alice,
denn das ist ja die einzige Transaktion

00:20:37.750 --> 00:20:42.129
die dem Netzwerk bekannt ist. Und
Malroy arbeitet jetzt ganz alleine daran,

00:20:42.129 --> 00:20:46.249
den alternativen Block zu erstellen. In
dem die andere Transaktion enthalten ist.

00:20:46.249 --> 00:20:51.539
Jetzt ist es aber so: das Netzwerk hat
natürlich mehr Rechenkraft als Malroy

00:20:51.539 --> 00:20:56.659
allein. Der hat halt nicht so viele
Computrr. Und deshalb wird das Netzwerk

00:20:56.659 --> 00:21:01.340
immer schneller sein darin, neue Blöcke
zu erstellen als Malroy. Malroys Kette

00:21:01.340 --> 00:21:06.169
wird nie die längste Kette, wird nie Teil
des Zustands. Und der Angriff wurde

00:21:06.169 --> 00:21:13.779
erfolgreich abgewehrt. Die einzige Art
und Weise wie Malroy gewinnen könnte,

00:21:13.779 --> 00:21:17.639
also wie Malroy den Angriff trotzdem
durchführen könnte, wäre, wenn er

00:21:17.639 --> 00:21:21.899
schneller Blöcke erstellen könnte als
das Netzwerk. Und das wird ihm aber

00:21:21.899 --> 00:21:25.909
nur dann gelingen, wenn er mehr als
50% der Rechenkraft im Netzwerk hätte.

00:21:25.909 --> 00:21:28.679
Denn dann wäre die Wahrscheinlichkeit,
dass er einen Block findet, höher

00:21:28.679 --> 00:21:33.809
als bei allen anderen Minern gemeinsam.
Und dann könnte er das tun. Und deshalb

00:21:33.809 --> 00:21:38.590
spricht man bei Bitcoin und anderen
Kryptowährungen von diesen 50%-Attacken.

00:21:38.590 --> 00:21:44.279
So, jetzt gibt es noch eine andere Art,
einen Double-Spend auszuführen. Das ist

00:21:44.279 --> 00:21:49.880
ein etwas schwierigerer Angriff.
Und er hat jetzt damit zu tun, wie

00:21:49.880 --> 00:21:53.429
das Peer-to-Peer-Netzwerk funktioniert,
das wir brauchen um die Transaktionen

00:21:53.429 --> 00:22:01.279
und Blöcke zu verteilen. Jetzt ist der
Angriff ein wenig schwieriger, also

00:22:01.279 --> 00:22:05.330
muss Malroy etwas wertvolleres stehlen.
Er geht zu Bob. Bob verkauft Autos.

00:22:05.330 --> 00:22:09.230
Er wird versuchen ein Auto zu stehlen.
Und um das zu tun, wird er versuchen

00:22:09.230 --> 00:22:13.210
die Verbindung von Bob mit dem
Peer-to-Peer-Netzwerk zu kontrollieren.

00:22:13.210 --> 00:22:17.740
Wir sehen hier, Bob ist mit dem Netzwerk
verbunden. Mit diesen drei Peers. Und

00:22:17.740 --> 00:22:21.710
Malroy hat zwei Möglichkeiten: entweder
er kontrolliert die Internetverbindung

00:22:21.710 --> 00:22:26.840
von Bob. Oder dann kontrolliert er
halt die drei Nodes, mit denen Bob

00:22:26.840 --> 00:22:30.840
verbunden ist. Wie realistisch das ist,
das will ich hier nicht diskutieren.

00:22:30.840 --> 00:22:34.820
Grundsätzlich ist es ja schon
vorstellbar. Und jetzt hat Malroy

00:22:34.820 --> 00:22:39.190
einige interessante Möglichkeiten. Er kann
jetzt nämlich kontrollieren, welche Blöcke

00:22:39.190 --> 00:22:43.330
und Transaktionen der Bob sieht.
Also Transaktionen und Blöcke,

00:22:43.330 --> 00:22:47.870
welche auf dem Netzwerk erscheinen,
kann Malroy quasi vor Bob geheimhalten.

00:22:47.870 --> 00:22:52.059
Und er kann Bob auch Transaktionen und
Blöcke präsentieren, die er dem Rest

00:22:52.059 --> 00:22:58.330
des Netzwerkes nicht präsentiert.
So, das ist der Angriff. Wir sehen,

00:22:58.330 --> 00:23:01.200
was das Netzwerk sieht.
Links und rechts, was Bob sieht.

00:23:01.200 --> 00:23:06.929
Am Anfang ist das natürlich an beiden
Orten gleich. Jetzt geht der Malroy

00:23:06.929 --> 00:23:11.320
zu dem Bob und wird das Auto kaufen.
Er macht eine Transaktion.

00:23:11.320 --> 00:23:15.850
Er macht zwei Transaktionen. Eine,
um das Geld an Bob zu überweisen.

00:23:15.850 --> 00:23:19.480
Diese schickt er nur an Bob. Und
versteckt sie vor dem Netzwerk.

00:23:19.480 --> 00:23:23.960
Und eine zweite Transaktion, mit der er
das Geld wieder an sich selbst überweist.

00:23:23.960 --> 00:23:28.480
Diese Transaktion veröffentlicht er im
Netzwerk. Jetzt wird das Netzwerk

00:23:28.480 --> 00:23:33.950
daran arbeiten, einen Block zu erstellen,
mit der Transaktion von Malroy zu Malroy.

00:23:33.950 --> 00:23:38.990
Weil das Netzwerk kennt keine andere
Transaktion. Und Malroy allein arbeitet

00:23:38.990 --> 00:23:42.240
daran einen Block zu erstellen, mit
dem er das Geld an Bob überweist.

00:23:42.240 --> 00:23:48.130
Natürlich wiederum, das Netzwerk hat viel
mehr Rechenkraft, es ist viel schneller

00:23:48.130 --> 00:23:51.549
darin, neue Blöcke zu erstellen. So, und

00:23:51.549 --> 00:23:56.149
schlussendlich gelingt es dann aber Bob
[Malroy!] trotzdem, einen Block zu erstellen.

00:23:56.149 --> 00:23:59.690
Und alle diese Blöcke die auf dem Netzwerk
erstellt wurden – muss man vielleicht

00:23:59.690 --> 00:24:05.350
noch sagen – die hält der Malroy vor Bob
geheim. Also, alle diesen neuen Blöcke,

00:24:05.350 --> 00:24:08.919
die hat Bob nie gesehen. Und deshalb
wird Bob diesen einen Block von Malroy

00:24:08.919 --> 00:24:13.269
als die längste Kette von Blöcken
akzeptieren. Und jetzt ist die Transaktion

00:24:13.269 --> 00:24:17.749
von Malroy an Bob Teil von Bobs
Zustand. Er gibt Malroy das Auto.

00:24:17.749 --> 00:24:25.210
Malroy fährt davon. Er beendet die
Attacke. Und jetzt verbindet sich Bob

00:24:25.210 --> 00:24:28.899
wieder ganz normal mit dem Netzwerk.
Die beiden Ketten werden synchronisiert.

00:24:28.899 --> 00:24:33.590
Und wir sehen, in der schlussendlich
resultierenden Kette hat Bob das Geld

00:24:33.590 --> 00:24:37.720
nicht erhalten. Malroy hat also das
Auto erfolgreich stehlen können.

00:24:37.720 --> 00:24:45.690
Das ist gar nicht gut. Jetzt hat ja dieser
Angriff funktioniert. Oder hat er das

00:24:45.690 --> 00:24:52.659
denn wirklich? Denn diesmal war der
Angriff erfolgreich. Aber Malroy musste

00:24:52.659 --> 00:24:56.519
jetzt dafür arbeiten. Er musste diesen
einen Block erstellen. Und das hat ihn

00:24:56.519 --> 00:25:00.400
viel Zeit gekostet. Natürlich kostet
es ihn auch irgendwie Rechenkraft,

00:25:00.400 --> 00:25:03.440
und den Strom den er braucht um seinen
Computer zu betreiben. Das wollen wir

00:25:03.440 --> 00:25:07.360
jetzt aber gar nicht mit einbeziehen.
Sondern wir schauen jetzt nach diesen

00:25:07.360 --> 00:25:11.509
Dings die (?) Zeit gekostet. Denn der Malroy
hat ja einen Computer, den er braucht,

00:25:11.509 --> 00:25:16.340
um die Blöcke zu erstellen. Und dieser
Computer kann immer nur eines auf’s Mal

00:25:16.340 --> 00:25:20.290
tun. Entweder erstellt er jetzt diesen
Fake-Block für Bob, oder er erstellt

00:25:20.290 --> 00:25:25.789
richtige Blöcke auf die richtige Chain.
Er kann nicht beides auf’s Mal tun.

00:25:25.789 --> 00:25:29.480
So, und das macht es sehr, sehr
teuer diesen Angriff durchzuführen.

00:25:29.480 --> 00:25:34.749
Stellen wir uns vor… (?)(?)(?)(?)(?)(?)
(?)(?) welche Annahmewerte für unser

00:25:34.749 --> 00:25:39.669
Netzwerk… die sind da halt in jeder
Kryptowährung etwas anders definiert.

00:25:39.669 --> 00:25:44.730
Sagen wir, unser Netzwerk erzeugt einen
Block alle zehn Minuten. Der Block Reward,

00:25:44.730 --> 00:25:49.700
welchen der Miner kriegt ist 1000 Euro.
Und Malroy hätte jetzt 20% der Rechenkraft

00:25:49.700 --> 00:25:54.691
des Netzwerkes. Wenn wir sagen 100% der
Rechenkraft erzeugt alle zehn Minuten.

00:25:54.691 --> 00:26:00.309
einen Block, dann erzeugt Malroy auf
sich alleine gestellt nur alle 50 Minuten

00:26:00.309 --> 00:26:06.409
einen Block. D.h. der Angriff auf Bob
dauert 50 Minuten. Nun, wenn aber Malroy

00:26:06.409 --> 00:26:12.000
50 Minuten lang minen würde, anstatt Bob
anzugreifen, dann würde er in dieser Zeit

00:26:12.000 --> 00:26:16.289
durchschnittlich 1000 Euro verdienen.
Er kann sich jetzt also entscheiden,

00:26:16.289 --> 00:26:22.590
entweder greift er Bob an und stiehlt das
23.000 Euro teure Auto, oder er verdient

00:26:22.590 --> 00:26:26.690
mit fairem Mining 1000 Euro.
Natürlich wird er dieses Auto immer noch

00:26:26.690 --> 00:26:31.220
stehlen wollen. Der Mechanismus, um
das zu verhindern ist aber ganz einfach.

00:26:31.220 --> 00:26:36.419
Wir sagen jetzt, Bob gibt dem
Malroy das Auto nicht, sobald Bob

00:26:36.419 --> 00:26:39.809
das Geld erhalten hat, sondern er
wartet dann noch einige Blöcke.

00:26:39.809 --> 00:26:44.039
Das sieht dann in etwa so aus. Ich habe
jetzt nicht genügend Blöcke gemalt,

00:26:44.039 --> 00:26:49.279
weil die da nicht Platz hatten.
Also sagen wir halt, wir sehen

00:26:49.279 --> 00:26:54.510
auf der rechten Seite, wo die
Transaktion Teil des Zustandes wird.

00:26:54.510 --> 00:26:59.609
Und in diesem Moment gibt halt der
Bob das Auto noch nicht an Malroy,

00:26:59.609 --> 00:27:05.179
sondern erst einige Blöcke später. Und
für jeden zusätzlichen Block, den Malroy

00:27:05.179 --> 00:27:08.039
erstellen muss, um Bob davon zu
überzeugen, dass das jetzt wirklich

00:27:08.039 --> 00:27:12.230
die richtige Kette ist, muss Malroy
weitere 50 Minuten aufwenden,

00:27:12.230 --> 00:27:17.580
und das kostet ihn jedesmal 1000 Euro.
Wenn also Bob sagt: „Ich warte 24 Blöcke

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

00:27:22.530 --> 00:27:27.360
als das Auto einen Wert hat. Und dadurch
kann Bob den Angriff verhindern.

00:27:27.360 --> 00:27:31.179
Malroy kann den zwar immer noch
durchführen, aber es ist schlicht einfach

00:27:31.179 --> 00:27:36.429
nicht interessant für Malroy das zu tun,
weil er mehr Geld macht wenn er

00:27:36.429 --> 00:27:45.129
in der selben Zeit minet. So. Jetzt haben
wir viel gesprochen über generische

00:27:45.129 --> 00:27:48.890
Konzepte von Blockchains. Jetzt will
ich noch etwas dazu sagen, wie das

00:27:48.890 --> 00:27:53.820
in Bitcoin implementiert wird. Zumindest
einige der Dinge. Schauen wir uns zuerst

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

00:27:58.499 --> 00:28:03.340
zu definieren. Das tun wir überall,
irgendwie, in unseren Netzwerkprotokollen;

00:28:03.340 --> 00:28:07.799
in Nachrichten und Dateiformaten
sagen wir, der Body enthält den Inhalt,

00:28:07.799 --> 00:28:12.049
die eigentlichen Daten. Und der Header
enthält die Metadaten. Und genau dasselbe

00:28:12.049 --> 00:28:17.390
tun wir auch in unseren Blockchains. In
Bitcoin ist es so, der Body eines Blockes

00:28:17.390 --> 00:28:22.500
enthält alle Transaktionen. Die sind dort
geordnet aufgeführt. Der Miner muss

00:28:22.500 --> 00:28:29.130
einige Regeln einhalten, wenn er das
macht. Z.B. wenn Transaktion B

00:28:29.130 --> 00:28:32.460
von Transaktion A abhängt, die beide
im selben Block sind, müssen die

00:28:32.460 --> 00:28:36.190
in der richtigen Reihenfolge drin sein.
Aber sonst kann der die irgendwie

00:28:36.190 --> 00:28:40.350
dort einpacken. Aber sobald er das mal
gemacht hat, ist dann… diese Reihenfolge

00:28:40.350 --> 00:28:44.739
ist anschließend wichtig. Und die erste
Transaktion im Block ist (?)(?)

00:28:44.739 --> 00:28:47.750
die coin-based-Transaktion,
mit der sich der Miner

00:28:47.750 --> 00:28:49.759
den Block Reward überweist.

00:28:49.759 --> 00:28:59.000
Um jetzt diesen Body zu verbinden mit dem
Header nutzt Bitcoin einen Merkle Tree.

00:28:59.000 --> 00:29:00.979
Das ist ein binärer Baum,

00:29:00.979 --> 00:29:08.470
bei dem jeweils… der Node ist der
hash der konkatenierten Werte

00:29:08.470 --> 00:29:11.480
der Children des Nodes.

00:29:11.480 --> 00:29:15.279
Und Bitcoin verwendet fast überall…
wo Bitcoin Hashes macht,

00:29:15.279 --> 00:29:17.990
wenden sie einen – dhash nennen sie das,

00:29:17.990 --> 00:29:22.979
das ist ein double-sha256-Hash, also
so nennt sich der Hash eines Hashes

00:29:22.979 --> 00:29:27.440
eines Wertes, den sie nehmen. Das
sieht dann so aus: wir haben unseren Body

00:29:27.440 --> 00:29:30.999
des Blocks. Dann erstellen wir für
jede Transaktion den double-hash.

00:29:30.999 --> 00:29:34.710
Und dann beginnen wir damit, den Tree
zu erstellen. Also auf jeden Node,

00:29:34.710 --> 00:29:40.629
für jeden blauen Node konkatenieren wir
die beiden grünen Nodes, und machen dann

00:29:40.629 --> 00:29:44.940
den Hash davon. Das machen wir für
jede Ebene, bis wir schlussendlich

00:29:44.940 --> 00:29:48.770
beim Merkle Root angelangen, und der
wird dann Teil des Block Headers.

00:29:48.770 --> 00:29:53.879
Und der Block Header enthält diese Dinge:
die Version – das ist irgendwie

00:29:53.879 --> 00:29:58.820
eine arbitrary Nummer, die von den
Entwicklern von Zeit zu Zeit geändert wird,

00:29:58.820 --> 00:30:01.809
wenn sie irgendwie finden,
dass wird jetzt Zeit dafür.

00:30:01.809 --> 00:30:05.559
Dann den Previous Block Hash. Wir haben
gesehen, die Blöcke verweisen jeweils

00:30:05.559 --> 00:30:09.539
auf den vorhergehenden Block. Das ist
in Bitcoin so gelöst, dass der Header

00:30:09.539 --> 00:30:14.799
eines Blocks den Hash des vorhergehenden
Blocks enthält. Also auch hier wieder

00:30:14.799 --> 00:30:19.210
den double-hash. Den Merkle Root haben
wir bereits gesehen. Dann enthält

00:30:19.210 --> 00:30:22.460
der Block-Header noch einen Time Stamp.
Das sind ziemlich komplizierte Regeln,

00:30:22.460 --> 00:30:27.860
wonach dieser Time Stamp gebildet
wird, aber das ist egal. Das ist

00:30:27.860 --> 00:30:31.850
nicht so wichtig. Die ‚Difficulty‘ ist ein
Ausdruck dafür wie schwierig es war

00:30:31.850 --> 00:30:35.989
den Proof-of-Work für diesen bestimmten
Block zu definieren. Und die ‚Nonce‘

00:30:35.989 --> 00:30:39.739
ist ein Wert der gebraucht wird zum Minen.

00:30:39.739 --> 00:30:48.029
Ja und der Proof-of-Work in Bitcoin ist
nichts anderes als der Hash des Blocks.

00:30:48.029 --> 00:30:53.139
Und der muss dann eine Bedingung
erfüllen. Und zwar muss dieser Hash

00:30:53.139 --> 00:30:58.580
mit einer gewissen Anzahl Nullen beginnen.
Also ich nehme den Header des Blocks

00:30:58.580 --> 00:31:04.359
und bilde den double-hash davon.
Und dann müssen die ersten paar Bits

00:31:04.359 --> 00:31:08.559
von diesem Hash müssen Null sein. Und
wieviele Bits das sind, das ist dann eben

00:31:08.559 --> 00:31:13.470
die variable Schwierigkeit. Also wenn
ich mehr Nullen haben muss zu Beginn

00:31:13.470 --> 00:31:18.240
dann ist es schwieriger den Proof-of-Work
zu erstellen. Und bei weniger

00:31:18.240 --> 00:31:22.229
natürlich einfacher. Das Mining
funktioniert dann so dass… der Miner

00:31:22.229 --> 00:31:25.919
nimmt einfach mal diesen Header,
und bildet den double-hash davon.

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.

00:31:29.919 --> 00:31:34.210
Und dann inkrementiert er halt die nonce,
dadurch hat sich der Header verändert,

00:31:34.210 --> 00:31:39.109
er bildet wieder den hash davon, und prüft
das. Und so macht er immer weiterrr.

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

00:31:45.509 --> 00:31:50.249
ist wesentlich größer. Es kann also gut
sein, dass einfach durch das Inkrementieren

00:31:50.249 --> 00:31:55.690
der Nonce kein passender Proof-of-Work
gefunden wird. Und in dem Fall wird

00:31:55.690 --> 00:32:01.519
der Miner die coin-based Transaktion
verändern. Und zwar hat diese coin-based

00:32:01.519 --> 00:32:05.450
Transaktion hat den Transaction Input,
der wird bei einer normalen Transaktion

00:32:05.450 --> 00:32:09.359
dafür gebraucht zu beschreiben, woher
das Geld kommt in dieser Transaktion.

00:32:09.359 --> 00:32:14.229
Das hat die coin-based nicht, denn die
macht ja quasi Geld aus dem Nichts heraus,

00:32:14.229 --> 00:32:18.179
und den Wert in diesem Fall kann
dann der Miner frei beeinflussen.

00:32:18.179 --> 00:32:22.239
Dadurch ändert sich der Hash dieser
Transaktion, und das setzt sich dann

00:32:22.239 --> 00:32:28.129
durch den Merkle Tree hindurch fort bis
es quasi auch den Merkle Root verändert.

00:32:28.129 --> 00:32:32.679
Und dadurch ist der ganze Blockheader
wieder verändert und der Miner

00:32:32.679 --> 00:32:38.369
kann weiterarbeiten. So, das lässt sich ja
dann auch sehr einfach prüfen, ob das jetzt

00:32:38.369 --> 00:32:41.700
ein korrekter Proof-of-Work ist. Ich nehme
einfach diesen Blockheader und bilde

00:32:41.700 --> 00:32:43.519
den Hash und schaue ob das so stimmt.

00:32:43.519 --> 00:32:53.330
Das Bitcoin-Netzwerk versucht alle zehn
Minuten einen neuen Block zu erstellen.

00:32:53.330 --> 00:32:57.519
Um diese Zeit stabil zu halten,
wird die Schwierigkeit im Netzwerk

00:32:57.519 --> 00:33:02.899
alle 14 Tage, also alle 2016 Blöcke,
angepasst, mit einem Algorithmus

00:33:02.899 --> 00:33:07.049
wo jeder Miner feststellen kann wie weit
muss ich jetzt die Schwierigkeit verändern.

00:33:07.049 --> 00:33:14.379
Die coin-based Transaktion, mit der
sich der Miner Geld überweist,

00:33:14.379 --> 00:33:18.039
enthält in Bitcoin zwei Dinge:
einerseits die Transaction Fees, also

00:33:18.039 --> 00:33:24.759
die Transaktionsgebühren der Transaktion
in den Block; und anderseits auch noch

00:33:24.759 --> 00:33:29.940
neue Bitcoin, die neu ins System kommen.
Das waren ursprünglich 50 Bitcoin pro Block,

00:33:29.940 --> 00:33:34.049
heute sind es noch 12,5, der
Wert halbiert sich alle vier Jahre.

00:33:34.049 --> 00:33:39.309
Das war das letzte Mal in diesem Sommer,
da hat sich der Wert halbiert. Seither

00:33:39.309 --> 00:33:44.880
gibt es nur noch 12,5 Bitcoin
für einen neuen Block.

00:33:44.880 --> 00:33:52.429
Jetzt wollen wir noch uns anschauen
wie wir ‚Light Clients‘ bauen können.

00:33:52.429 --> 00:33:56.509
Bitcoin kennt eigentlich mehrere Ränge (?),
drei Arten von Clients: ein ‚Full Node‘

00:33:56.509 --> 00:33:59.729
ist ein Client, welcher die
gesamte Blockchain speichert.

00:33:59.729 --> 00:34:06.630
Der überprüft jede eingehende
Transaktion, jeden eingehenden Block

00:34:06.630 --> 00:34:10.639
überprüft dieser Client, ob der auch
wirklich valide ist. Und er tut noch

00:34:10.639 --> 00:34:14.119
etwas anderes, nämlich er seeded diese
Blöcke die er hat an das Netzwerk.

00:34:14.119 --> 00:34:17.800
Also wenn jemand kommt und sagt:
„Ich hätte gern einen Block“ dann gibt

00:34:17.800 --> 00:34:22.149
der Full Node diesen Block raus. Dann gibt
es ‚Pruning Clients‘. Der macht eigentlich

00:34:22.149 --> 00:34:27.940
das genau selbe wie der Full Node.
Also der überprüft auch alle Transaktionen

00:34:27.940 --> 00:34:32.520
und alle Blöcke. Aber der speichert jetzt
halt nicht die ganze Blockchain, sondern

00:34:32.520 --> 00:34:35.550
wenn er findet „den Block brauche ich
nicht mehr“, dann löscht er den.

00:34:35.550 --> 00:34:39.100
Und das macht dem Client Speicherplatz.
Der braucht aber immer noch

00:34:39.100 --> 00:34:43.580
sehr viel Rechenkraft und sehr viel
Bandbreite, deutlich zuviel als dass ich

00:34:43.580 --> 00:34:48.130
das auf meinem Smartphone laufen lassen
möchte. Und deshalb gibt es noch

00:34:48.130 --> 00:34:53.750
die Light Clients oder SPV Clients.
Die dann auch geeignet sind,

00:34:53.750 --> 00:34:56.980
um [sie] auf einem mobilen Gerät laufen
zu lassen. Und wie die funktionieren,

00:34:56.980 --> 00:34:58.790
werde ich jetzt noch besprechen.

00:34:58.790 --> 00:35:05.980
Ein Light Client oder ein SPV Client,
was der tut zuerst ist, er lädt

00:35:05.980 --> 00:35:09.400
die Header aller Blöcke herunter. Wir
haben ja gesehen, der Proof-of-Work

00:35:09.400 --> 00:35:15.420
ist der Hash des Block Headers. D.h.
um den Proof-of-Work zu kontrollieren

00:35:15.420 --> 00:35:18.140
brauche ich nicht den gesamten
Block, der Block Header genügt.

00:35:18.140 --> 00:35:21.940
Und dasselbe gilt auch für die
Verknüpfung der Blöcke untereinander.

00:35:21.940 --> 00:35:26.390
Welches der vorhergehende Block
ist, das steht ja auch im Header.

00:35:26.390 --> 00:35:30.510
D.h. auch für diese Funktion brauche ich
nicht die ganzen Blöcke herunterzuladen.

00:35:30.510 --> 00:35:35.450
Und so kann ich korrekt
die längste Kette erstellen,

00:35:35.450 --> 00:35:39.710
innerhalb des Netzwerks, indem
ich nur die Header herunterlade.

00:35:39.710 --> 00:35:45.560
Und der Gewinn dabei ist natürlich enorm.
Zur Zeit gibt es etwa 450.000 Blöcke.

00:35:45.560 --> 00:35:50.600
Die brauchen mehr als 95 GB Speicherplatz.
Wenn man dann noch Tags Index (?) aktiviert

00:35:50.600 --> 00:35:54.980
sind es, glaube ich, so um die
110 GB Speicherplatz, die es braucht.

00:35:54.980 --> 00:36:00.450
Das ist natürlich blödsinnig viel auf einem
Smartphone. Aber nur die Block Headers,

00:36:00.450 --> 00:36:03.730
alle Block Headers von diesen
450.000 Blöcken, die passen

00:36:03.730 --> 00:36:10.180
in deutlich weniger als 100 MB rein. Und
das ist dann durchaus ein realistischer Wert,

00:36:10.180 --> 00:36:14.940
dass ich das auf einem Smartphone habe.
Das zweite Konzept ist der Merkle Branch,

00:36:14.940 --> 00:36:18.540
und das ist dann eigentlich noch fast
die interessantere Funktion, die uns

00:36:18.540 --> 00:36:22.790
der Merkle Tree bildet. Und damit kann
jeder beweisen, dass eine Transaktion

00:36:22.790 --> 00:36:25.210
tatsächlich Teil des Zustands ist.

00:36:25.210 --> 00:36:30.650
Nun, die eine Möglichkeit, wie wir den
Merkle Tree nachbauen können,

00:36:30.650 --> 00:36:35.210
ist natürlich, indem wir den Block
Body herunterladen, und dann

00:36:35.210 --> 00:36:39.580
den ganzen Merkle Tree bauen.
Wenn ich jetzt aber nur beweisen will

00:36:39.580 --> 00:36:44.200
dass eine Transaktion Teil des Blockes
ist, gibt es eine effizientere Möglichkeit.

00:36:44.200 --> 00:36:47.950
Angenommen ich will jetzt beweisen,
dass die Transaktion (3) tatsächlich

00:36:47.950 --> 00:36:51.920
Teil des Blocks ist. Dann brauche ich
nicht alle Transaktionen herunterzuladen,

00:36:51.920 --> 00:36:58.260
sondern es reicht diese Transaktion (3)
herunterzuladen. – Ui, das war falsch. –

00:36:58.260 --> 00:37:01.480
Und dann die restlichen Hashes,
also von jeder Ebene des Baums

00:37:01.480 --> 00:37:04.480
lade ich einen Hash herunter.
Und damit kann ich jetzt

00:37:04.480 --> 00:37:11.420
den Merkle Root Node wieder nachbilden,
und so feststellen, dass diese Transaktion

00:37:11.420 --> 00:37:14.700
tatsächlich Teil des Blocks ist.
Das ist genau das was…

00:37:14.700 --> 00:37:19.150
das hat jetzt natürlich auch einige
Vorteile. Ich brauche jetzt

00:37:19.150 --> 00:37:23.520
weniger Elemente herunterzuladen, und
ich kann halt Hashes herunterladen, also

00:37:23.520 --> 00:37:27.110
anstatt Transaktionen. Vorhin in dem
Beispiel hat das nicht soviel gebracht.

00:37:27.110 --> 00:37:30.371
Aber wenn wir einen Block nehmen
mit 1600 Transaktionen, das ist

00:37:30.371 --> 00:37:34.880
dieser Tage durchaus ein üblicher Block,
dann brauche ich jetzt zum Validieren

00:37:34.880 --> 00:37:38.810
nicht mehr 1600 Transaktionen
herunterzuladen, sondern es genügt

00:37:38.810 --> 00:37:42.400
eine Transaktion herunterzuladen und
dann elf Hashes, und damit kann ich

00:37:42.400 --> 00:37:44.530
den Merkle Branch nachbauen.

00:37:44.530 --> 00:37:52.640
Und so funktioniert ein SPV Client. SPV
steht für ‚simple payment verification‘.

00:37:52.640 --> 00:37:56.660
Und das hat eigentlich… das wurde schon
im White Paper zu Bitcoin beschrieben,

00:37:56.660 --> 00:38:00.890
wie das funktioniert. Alles was der
tun muss, um zu beweisen, dass

00:38:00.890 --> 00:38:04.950
eine Transaktion reingekommen ist, ist,
er lädt zuerst alle Block Header herunter,

00:38:04.950 --> 00:38:10.320
wie vorhin besprochen, er bildet
den längsten Branch daraus,

00:38:10.320 --> 00:38:14.130
dann lädt er eine Transaktion herunter.
Und wenn ich jetzt wissen will…

00:38:14.130 --> 00:38:18.331
wenn ich von jemandem Geld erhalte und
ich will jetzt zeigen, ich habe das Geld

00:38:18.331 --> 00:38:22.610
tatsächlich erhalten, lade ich halt diese
Transaktion herunter, und dann lade ich

00:38:22.610 --> 00:38:27.150
den passenden Merkle Branch herunter.
Und jetzt kann ich quasi zeigen, dass

00:38:27.150 --> 00:38:32.160
dieser Merkle Branch tatsächlich mit der
längsten Kette von Blöcken verbunden ist.

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.

00:38:36.990 --> 00:38:40.560
So, das ist diese Funktionsweise.
Jetzt haben wir noch etwas mehr Zeit,

00:38:40.560 --> 00:38:44.290
als ich gehofft hatte. Ich werde jetzt
noch versuchen, die Pruning Clients

00:38:44.290 --> 00:38:48.580
zu erklären. Das hängt dann damit zusammen
wie eigentlich Bitcoin-Transaktionen

00:38:48.580 --> 00:38:53.910
funktionieren. Nun, wir sind es ja
gewohnt, dass wir irgendwie auf der Bank

00:38:53.910 --> 00:38:58.260
ein Konto haben. Und das Konto
hat einen Besitzer. Hoffentlich mich!

00:38:58.260 --> 00:39:02.660
Und es hat einen Geldbetrag. Und jedesmal,
wenn ich eine Transaktion durchführe,

00:39:02.660 --> 00:39:06.760
verändert sich der Geldbetrag. Also ich
überweisen jemandem Geld, und dann

00:39:06.760 --> 00:39:11.520
verändert sich halt der Betrag auf meinem
Konto. In Bitcoin funktioniert das

00:39:11.520 --> 00:39:15.620
wesentlich anders, dort besitze ich
nicht ein Konto, sondern ich besitze

00:39:15.620 --> 00:39:20.170
sogenannte ‚Unspent Transaction Outputs‘.
Und wir sehen jetzt hier, sagen wir Alice

00:39:20.170 --> 00:39:23.880
hat diese fünf Unspent Transaction
Outputs, die haben (?)(?) einen Besitzer,

00:39:23.880 --> 00:39:29.230
nämlich Alice. Und jeweils einen Betrag
der dort verfügbar ist. Und der Betrag

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

00:39:33.840 --> 00:39:38.910
eine Transaktion machen, an Bob,
die würde ihm gerne 42 Bitcoin überweisen.

00:39:38.910 --> 00:39:42.340
Dann erstellt sie eine Transaktion, und
sagt, das Geld dieser Transaktion,

00:39:42.340 --> 00:39:47.610
42 Bitcoin, sollen an Bob gehen. Und jetzt
muss sie das Geld irgendwoher haben.

00:39:47.610 --> 00:39:53.480
Und dann sagt sie halt, ich gebe
diese drei Transaction Outputs aus.

00:39:53.480 --> 00:39:56.920
Und das Interessante an Transaction
Outputs… wie gesagt, den Betrag

00:39:56.920 --> 00:40:00.980
kann man nicht verändern, sondern
Alice muss die alle komplett ausgeben.

00:40:00.980 --> 00:40:05.930
Jetzt sind aber diese Transaction Outputs
zusammengenommen 44 Bitcoin,

00:40:05.930 --> 00:40:12.170
und nicht 42 Bitcoins. D.h. diese
Transaktion gibt jetzt zuviel Geld aus,

00:40:12.170 --> 00:40:17.330
also sie gibt mehr Transaction Outputs aus
als sie dann schlussendlich Geld dem Bob

00:40:17.330 --> 00:40:21.400
überweist. Und was kann jetzt Alice
tun? Was sie tut, ist, sie macht

00:40:21.400 --> 00:40:27.360
einen zweiten Output in ihrer Transaktion.
Und hier überweist sie jetzt Geld an Alice.

00:40:27.360 --> 00:40:31.670
D.h. eine Transaktion in Bitcoin kann
beliebig viele Inputs und beliebig viele

00:40:31.670 --> 00:40:36.740
Outputs haben. Was es hier noch zu
sagen gibt, ist, haben wir immer noch

00:40:36.740 --> 00:40:41.070
einen Unterschied. Jetzt haben wir 44
Bitcoin, die in die Transaktion reinkommen,

00:40:41.070 --> 00:40:45.860
und nur 43 die rausgehen. Das restliche
Bitcoin, das jetzt hier nicht ausgegeben wird,

00:40:45.860 --> 00:40:51.340
das ist quasi impliziert die Transaction
Fee, welche der Miner erhält, der diese

00:40:51.340 --> 00:40:56.580
Transaktion mint. So eine Transaction Fee
ist implementiert. Jetzt haben wir gesehen,

00:40:56.580 --> 00:40:59.640
Alice hat durch das Erstellen dieser
Transaktion neue Transaction Outputs

00:40:59.640 --> 00:41:05.610
erstellt. Nämlich einen, der jetzt Bob
gehört, und einen der Alice gehört.

00:41:05.610 --> 00:41:08.980
Und jetzt können wir auch nachvollziehen,
diese Transaction Outputs, welche Alice

00:41:08.980 --> 00:41:13.850
ausgegeben hat, die gehören alle irgendwie
zu anderen Transaktionen, welche es vorhin

00:41:13.850 --> 00:41:20.070
gegeben hat. Nun, ein Transaction Output
kann einen von zwei Zuständen haben.

00:41:20.070 --> 00:41:24.930
Er kann ausgegeben sein, oder nicht.
Und natürlich kann man nur die ausgeben,

00:41:24.930 --> 00:41:29.320
die noch nicht ausgegeben sind. Und das
heißt, wenn ich wissen will, wieviel Geld

00:41:29.320 --> 00:41:33.350
Alice gehört, dann suche ich mir alle
Transaction Outputs zusammen,

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.

00:41:38.360 --> 00:41:41.200
Das kann ich für jeden Teilnehmer
des Systems machen, dann weiß ich

00:41:41.200 --> 00:41:46.900
für jeden Teilnehmer, wieviel Geld denn
der Person gehört. Wenn ich jetzt also

00:41:46.900 --> 00:41:50.980
alle Transaction Outputs nehme, die
nicht ausgegeben sind, dann habe ich

00:41:50.980 --> 00:41:56.530
den aktuellen Zustand des Netzwerks. Dann
weiß ich für jeden Teilnehmer, wieviel Geld

00:41:56.530 --> 00:42:05.200
diese Person hat. Und genau diesen
Mechanismus macht sich ein Pruning Client

00:42:05.200 --> 00:42:08.610
zunutze. Der sagt nämlich, eigentlich
brauche ich nicht die ganze Blockchain

00:42:08.610 --> 00:42:12.931
zu speichern, das ist ja blöd, denn wenn
eine neue Transaktion reinkommt, und

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

00:42:17.260 --> 00:42:22.060
einen Output ausgibt, der noch unspent
ist, denn wenn die Transaktion einen

00:42:22.060 --> 00:42:25.520
Transaction Output ausgibt, der schon
ausgegeben ist, dann ist die natürlich

00:42:25.520 --> 00:42:29.430
nicht valide, man kann ja nicht dasselbe
Geld zweimal ausgeben. Oder wenn

00:42:29.430 --> 00:42:32.080
die Transaktion versucht, einen
Transaction Output auszugeben,

00:42:32.080 --> 00:42:35.120
den es gar nicht gibt, dann ist
die natürlich auch nicht valide.

00:42:35.120 --> 00:42:42.290
Was jetzt also ein Pruning Client tut –
und das tut übrigens auch ein Full Node:

00:42:42.290 --> 00:42:46.570
wenn eine neue Transaktion reinkommt,
und da steht in der Transaktion „ich gebe

00:42:46.570 --> 00:42:52.220
diesen Transaction Output aus“, dann
geht der Full Node nicht und versucht,

00:42:52.220 --> 00:42:56.290
die 100 GB große Blockchain zu durchsuchen
nach diesem Transaction Output, das wäre

00:42:56.290 --> 00:43:00.160
ja blödsinnig, sondern der legt sich halt
eine kleine Datenbank an, und dort

00:43:00.160 --> 00:43:04.180
stehen alle Transaction Outputs drin.
Und dann sagt er sich, für jeden…

00:43:04.180 --> 00:43:08.580
also alle Unspent Transaction Outputs
stehen dort drin, und dann sagt sich

00:43:08.580 --> 00:43:12.250
der Client, für jede Transaktion,
die reinkommt und die valide ist,

00:43:12.250 --> 00:43:17.540
entferne ich alle Transaction Outputs die
die Transaktion ausgibt aus der Datenbank,

00:43:17.540 --> 00:43:22.870
und alle neuen Transaction Outputs füge
ich dort ein. Und so behält der Client

00:43:22.870 --> 00:43:28.960
den Zustand. Und der Pruning Client sagt
sich dann halt: „Naja, die Blöcke, die

00:43:28.960 --> 00:43:31.550
brauche ich jetzt ja nicht mehr, weil ich
habe den Zustand in der Datenbank,

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.“

00:43:35.380 --> 00:43:39.260
Der muss dann noch etwas vorsichtig sein,
denn wenn jetzt plötzlich von weiter hinten

00:43:39.260 --> 00:43:42.800
eine längere Kette kommt, dann muss er
das ja wieder nachvollziehen können,

00:43:42.800 --> 00:43:47.620
also wird er sich noch einige Blöcke
zusätzlich speichern, als nur den neuesten.

00:43:47.620 --> 00:43:54.720
Aber er kann so sehr viel Speicherplatz
sparen. Er muss aber… trotzdem

00:43:54.720 --> 00:43:59.600
muss ein Pruning Client eigentlich jede
Transaktion, die es jemals gegeben hat,

00:43:59.600 --> 00:44:05.160
herunterladen, und muss dann halt auch
die alle verifizieren. Das braucht auch

00:44:05.160 --> 00:44:08.280
immer noch sehr viel Rechenkraft, und
sehr viel Bandbreite. Und deshalb sind

00:44:08.280 --> 00:44:11.270
solche Clients nicht geeignet
für Mobilgeräte.

00:44:11.270 --> 00:44:21.190
Und was man hier vielleicht noch sagen
kann, ich habe jetzt eigentlich irgendwie

00:44:21.190 --> 00:44:23.220
gesagt, …

00:44:23.220 --> 00:44:30.690
…ich habe jetzt gesagt, Alice gibt einen
Transaction Output aus. Das ist…

00:44:30.690 --> 00:44:35.170
In Wirklichkeit ist es in Bitcoin
recht kompliziert implementiert.

00:44:35.170 --> 00:44:38.790
Das funktioniert nämlich so, dass der
Transaction Output hat ein Stück Code

00:44:38.790 --> 00:44:44.170
drin. Dafür gibt es in Bitcoin eine eigene
Assemblersprache, die das betreibt.

00:44:44.170 --> 00:44:50.960
Und der Input muss jetzt ebenfalls ein
Stück Code enthalten. Und wenn die dann

00:44:50.960 --> 00:44:55.670
nacheinander ausgeführt werden, muss das
dann „plus den Wert two ergeben“,(?)

00:44:55.670 --> 00:45:00.070
und nur in dem Fall wurde der Output
richtig ausgegeben. Und das ist

00:45:00.070 --> 00:45:04.120
ein ziemlich kompliziertes System, wie das
wirklich funktioniert. Das ist dann halt

00:45:04.120 --> 00:45:07.440
eine eigene Programmiersprache, die ist
zwar nicht Turing-vollständig, aber damit

00:45:07.440 --> 00:45:12.710
lassen sich dann alle möglichen lustigen
Regeln implementieren. Die häufigste Regel

00:45:12.710 --> 00:45:19.960
die man findet, in über 80%
der Fälle, sind sogenannte…

00:45:19.960 --> 00:45:28.800
…die Regel sagt dann irgendsowas wie:
„Um diesen Output ausgeben zu können,

00:45:28.800 --> 00:45:32.920
musst du beweisen, dass du den geheimen
Schlüssel besitzt zu dem öffentlichen

00:45:32.920 --> 00:45:37.900
Schlüssel, dessen Hash ich jetzt hier
reinpacke.“ Und in dem Input steht dann

00:45:37.900 --> 00:45:43.310
halt: „Ja, ich besitze diesen geheimen
Schlüssel, und ich beweise dir das,

00:45:43.310 --> 00:45:47.680
indem ich hier den öffentlichen Schlüssel
reinpacke und die Transaktion mit dem

00:45:47.680 --> 00:45:52.840
geheimen Schlüssel signiere.“ Und dann
kann jemand, der das verifizieren will,

00:45:52.840 --> 00:45:56.930
kann einfach den öffentlichen Schlüssel
nehmen, schauen ob das dem Hash entspricht,

00:45:56.930 --> 00:46:03.210
und dann mit dem öffentlichen Schlüssel
die Signatur der Transaktion verifizieren.

00:46:03.210 --> 00:46:09.940
Das ist die mit Abstand häufigste Art,
wie diese Transaktionen in Wirklichkeit

00:46:09.940 --> 00:46:15.280
funktionieren. Aber das ist halt dann sehr
kompliziert, und damit könnte man leicht

00:46:15.280 --> 00:46:20.720
einen eigenen Vortrag füllen.
Deshalb werde ich jetzt hier aufhören.

00:46:20.720 --> 00:46:24.180
Habe ich da diese tolle Seite gebastelt.

00:46:24.180 --> 00:46:30.120
– Ups, das ist eigentlich zu weit –

00:46:30.120 --> 00:46:36.640
Finde ich es, oder nicht?

00:46:36.640 --> 00:46:43.160
Ja, ha, gefunden! Unglaublich.
*Lachen*

00:46:43.160 --> 00:46:48.860
Also wir haben jetzt noch Zeit für Fragen,
wenn ihr noch was wissen wollt.

00:46:48.860 --> 00:46:54.940
Oder ihr könnt mich auch erreichen,
am einfachsten hier über das DECT-Telefon

00:46:54.940 --> 00:47:01.890
in dem Kongress, wenn ihr Fragen habt.
Ihr findet einen Handout der Slides

00:47:01.890 --> 00:47:06.000
auch im Fahrplan. Und ich werde auch
die Folien selbst noch hochladen,

00:47:06.000 --> 00:47:09.520
und den entsprechenden Source Code
zum Erzeugen der Folien werde ich auch

00:47:09.520 --> 00:47:10.520
verlinken.

00:47:10.520 --> 00:47:12.520
*Beifall*

00:47:12.520 --> 00:47:17.220
Herald: vimja!!

00:47:17.220 --> 00:47:21.910
*andauernder Beifall*

00:47:21.910 --> 00:47:31.540
Es ist noch einiges an Zeit für Fragen;
also wenn ihr Fragen habt,

00:47:31.540 --> 00:47:35.440
dann reiht euch an den Mikrofonen auf.
Eine Sache möchte ich sagen:

00:47:35.440 --> 00:47:40.280
wenn ihr jetzt rausgehen wollt, verlasst
bitte leise den Saal, damit das

00:47:40.280 --> 00:47:44.360
mit den Fragen einigermaßen klappt.
Liebe Tür-Engel, wir lassen im Moment

00:47:44.360 --> 00:47:50.790
noch niemanden rein. Erstmal können Leute
nur rausgehen. Und bitte tut das leise.

00:47:50.790 --> 00:47:53.230
Wir fangen mit dem Signal-Engel an.

00:47:53.230 --> 00:47:58.730
Signal Angel: Eine Frage aus dem Internet
bezüglich dem Man-in-the-middle

00:47:58.730 --> 00:48:02.290
double-spending-Angriff. Könnte Mallory
nicht diesen Angriff gleichzeitig

00:48:02.290 --> 00:48:08.360
mit derselben Fake-Blockchain gegen zehn
verschiedene Autohändler machen, und

00:48:08.360 --> 00:48:13.210
mit dem gleichen Aufwand zehn Autos klauen?
Damit würde es sich doch wieder lohnen,

00:48:13.210 --> 00:48:17.320
auch wenn man mit dem Gegenwert eines
Autos an Rechenzeit investieren müsste.

00:48:17.320 --> 00:48:23.400
vimja: Das ist eine gute Überlegung die
ich mir so noch auch gar nie gemacht habe.

00:48:23.400 --> 00:48:30.030
Ich müsste darüber mal nachdenken. Ich
nehme aber grundsätzlich an, dass es

00:48:30.030 --> 00:48:35.670
vermutlich funktionieren würde. Der
Aufwand wird dann aber halt sehr viel

00:48:35.670 --> 00:48:41.440
größer, irgendwie um die Netzwerk-Nodes
zu kontrollieren. Grundsätzlich denke ich

00:48:41.440 --> 00:48:44.950
aber, dass es kein… damit das System
wirklich sicher ist, sollte das

00:48:44.950 --> 00:48:52.200
kein Argument sein dürfen. Also ich hätte
jetzt auf Anhieb gesagt, dass es vermutlich

00:48:52.200 --> 00:48:53.650
klappen würde.

00:48:53.650 --> 00:48:57.211
Herald: Okay, dann machen wir weiter
mit Mikrofon 2, hier vorne, bitte!

00:48:57.211 --> 00:49:03.220
Frage: Ja, hallo. Du hast gesagt, mit
einer 50%-Attack kann man im Prinzip

00:49:03.220 --> 00:49:07.540
die Blockchains hijacken. Wenn man
sich jetzt mal eine hypothetische

00:49:07.540 --> 00:49:11.480
Regierungsorganisation mit sehr, sehr,
sehr viel Rechenpower überlecht,

00:49:11.480 --> 00:49:15.890
mal so ganz in den Raum geraten, gibt’s
Überlegungen, wie wahrscheinlich das ist?

00:49:15.890 --> 00:49:19.540
vimja: Nun, es ist so, mit einfach
herkömmlicher Rechenpower wird das

00:49:19.540 --> 00:49:23.270
kaum möglich sein, also irgendwie
für diese spezielle Aufgabe,

00:49:23.270 --> 00:49:28.400
den Double-SHA256-Hash, hat das Bitcoin-
Netzwerk ein Vielfaches der Rechenkraft,

00:49:28.400 --> 00:49:32.980
die selbst die 500 schnellsten Supercomputer
aufbringen könnten. Es gibt aber eine

00:49:32.980 --> 00:49:36.580
viel einfachere Möglichkeit, unser guter
Freund China, denn die meisten…

00:49:36.580 --> 00:49:40.070
denn heute ist es halt so: eigentlich
möchte man gerne, dass die Miner

00:49:40.070 --> 00:49:43.740
verteilt sind, und jeder ein wenig zuhause
minet. In Praxis ist es aber so, dass

00:49:43.740 --> 00:49:47.770
das heute das große Geschäft ist. Und das
wird dann halt heute in Rechenzentren

00:49:47.770 --> 00:49:53.920
in China betrieben. Und China hat heute
mehr als 50% der Rechenkraft von Bitcoin,

00:49:53.920 --> 00:49:57.430
also, toll, unsere unabhängige Währung
gehört jetzt den Chinesen.

00:49:57.430 --> 00:50:01.360
Und selbst wenn das nicht stimmen sollte,
und das nicht funktionieren sollte,

00:50:01.360 --> 00:50:04.630
ist es so, dass all die spezielle
Hardware, die heute zum Mining

00:50:04.630 --> 00:50:08.940
notwendig ist, in China hergestellt wird.
Und China könnte einfach all diese Fabriken,

00:50:08.940 --> 00:50:12.710
in denen die hergestellt werden,
beschlagnahmen, und nach einigen Monaten

00:50:12.710 --> 00:50:15.120
hätten sie trotzdem wieder mehr
Rechenleistung als jeder andere,

00:50:15.120 --> 00:50:20.470
und könnte die Währung so kontrollieren.
Also, das ist durchaus wahrscheinlich.

00:50:20.470 --> 00:50:24.390
Herald: Dann machen wir weiter
mit Mikrofon 1, hier vorne, bitte.

00:50:24.390 --> 00:50:28.970
Frage: Ja, mir geht’s auch gerade um die
Rechenpower. Also gibt es da irgendwie

00:50:28.970 --> 00:50:34.200
Ansätze in anderen elektronischen
Währungen, wie das verhindert werden kann,

00:50:34.200 --> 00:50:40.380
dass immer quasi zum Stand der aktuellen
Technik die maximale Rechenpower nötig ist,

00:50:40.380 --> 00:50:42.561
um so ein System laufen zu lassen?

00:50:42.561 --> 00:50:47.400
vimja: Es hat zur Zeit, im Verlauf der
Zeit verschiedene Möglichkeiten,

00:50:47.400 --> 00:50:49.820
also verschiedene Ansätze gegeben.

00:50:49.820 --> 00:50:55.150
Das eine was man immer wieder versucht
hat, ist halt, dass man das nicht nur auf

00:50:55.150 --> 00:50:59.720
Rechenkraft beschränkt, sondern dass man
sagt, der Angriff der braucht nicht nur

00:50:59.720 --> 00:51:03.950
Rechenpower sondern auch viel RAM,
oder viel Memory. Und dadurch ist es

00:51:03.950 --> 00:51:08.250
sehr viel schwieriger, Hardware zu bauen.
Oder sehr viel teurer, Hardware zu bauen,

00:51:08.250 --> 00:51:12.850
die darauf spezialisiert ist, und man
erhofft sich davon Erfolge, aber

00:51:12.850 --> 00:51:16.010
schlussendlich hat man dort wieder
dasselbe Problem. Ich weiß aber,

00:51:16.010 --> 00:51:20.600
dass Ethereum arbeitet an einem Konzept,
das nennen sie Proof-of-Stake.

00:51:20.600 --> 00:51:24.730
Und wie genau das funktioniert, kann ich
dir nicht sagen. Aber da hängt dann

00:51:24.730 --> 00:51:29.160
die Wahrscheinlichkeit, dass du einen
Block erstellst, davon ab wieviel Geld

00:51:29.160 --> 00:51:33.130
du besitzt in dem Netzwerk, oder sowas.
Und die brauchen dann eigentlich

00:51:33.130 --> 00:51:35.840
kein Mining mehr. Und die haben dann halt
auch das Problem nicht mehr dass man

00:51:35.840 --> 00:51:40.700
unglaublich viel Strom braucht, um das
Ding zu minen. Und ich dachte, die wollten

00:51:40.700 --> 00:51:44.900
diesen Sommer umstellen. Ich habe dann
aber das Ganze ein wenig aus den Augen

00:51:44.900 --> 00:51:47.790
verloren, und kann dir jetzt nicht
sagen wie weit die damit sind.

00:51:47.790 --> 00:51:48.790
Also grundsätzlich…

00:51:48.790 --> 00:51:50.340
Frage: Wie heißt das nochmal?

00:51:50.340 --> 00:51:53.930
vimja: ‚Proof-of-Stake‘. Und das wird in
Ethereum implementiert. Aber wie weit

00:51:53.930 --> 00:51:56.920
die sind, kann ich dir nicht sagen. Das
müsstest du selbst nachschauen gehen.

00:51:56.920 --> 00:51:57.940
Frage: Danke.

00:51:57.940 --> 00:52:02.440
Herald: Dann machen wir weiter mit
Mikrofon 4, dort drüben, bitte!

00:52:02.440 --> 00:52:06.550
Frage: Ich stelle mal zwei Fragen. Das
eine ist: öffentliche Grundbuchämter

00:52:06.550 --> 00:52:11.470
könnte man doch sehr gut in der Blockchain
umlegen [anlegen], und dadurch könnte

00:52:11.470 --> 00:52:15.370
doch die Verwaltung sehr viel Geld
einsparen, und z.B. Handelsregister

00:52:15.370 --> 00:52:16.730
sind ja auch öffentlich, die könnte man
doch auch in die Blockchain verschieben.

00:52:16.730 --> 00:52:20.450
Oder mache ich da irgendeinen Denkfehler,
dass es am Schluss für die Verwaltung

00:52:20.450 --> 00:52:23.350
teurer kommt? Und was mich auch
noch wundert, was deine Meinung

00:52:23.350 --> 00:52:25.240
zu Smart Contracts ist.

00:52:25.240 --> 00:52:30.300
vimja: Also, zu der ersten Frage, das ist
so, daran wird tatsächlich gearbeitet.

00:52:30.300 --> 00:52:33.850
Insbesondere die britische Regierung hat
auch Forschungsgruppen, die erforschen

00:52:33.850 --> 00:52:41.890
sollen, wie Blockchains der Verwaltung
helfen können. Gerade beim Grundbuchamt,

00:52:41.890 --> 00:52:46.000
also solche Systeme brauchen starke
Anpassungen, gerade wenn wir uns

00:52:46.000 --> 00:52:52.670
vorstellen, ein Grundbuchamt, wenn es dann
jemandem gelingen würde, irgendwie

00:52:52.670 --> 00:52:55.690
jetzt trotzdem ein Grundstück quasi
zu stehlen, und das würde einfach

00:52:55.690 --> 00:53:01.960
in dieser Blockchain drin feststehen, wie
würde man das wieder rückgängig machen?

00:53:01.960 --> 00:53:06.120
Also wenn wir heute ein Grundbuchamt
haben, dann können die alles überschreiben.

00:53:06.120 --> 00:53:10.530
Und irgendwie möchten wir ja dann trotzdem
nicht einfach nur dieser Blockchain vertrauen.

00:53:10.530 --> 00:53:14.810
Wir möchten trotzdem die Möglichkeit
haben, dass gewisse Stellen, gerade eben

00:53:14.810 --> 00:53:18.020
unser Staat, das überschreiben können.
Da müssen dann in diese Blockchains

00:53:18.020 --> 00:53:22.460
zusätzliche Mechanismen eingebaut werden,
dass das trotzdem geht, und das ist dann

00:53:22.460 --> 00:53:26.850
halt bedenklich, weil jetzt trotzdem da
jemand das Zeugs kaputtmachen kann.

00:53:26.850 --> 00:53:30.750
Also das ist nicht ganz einfach, diese
Dinge zu tun. Aber ich denke schon,

00:53:30.750 --> 00:53:38.360
dass gerade Grundbuchämter eine gute
Chance sind, und das ist vermutlich auch

00:53:38.360 --> 00:53:43.290
etwas vom Ersten, was wir implementiert
sehen werden. Soviel für öffentliche Ämter.

00:53:43.290 --> 00:53:48.000
Aber ich denke auch, dass es einen
Hybridbetrieb geben wird. Also

00:53:48.000 --> 00:53:52.020
dass man quasi sagt, das ist zwar
öffentlich in einer Blockchain, aber

00:53:52.020 --> 00:53:56.360
schlussendlich, was wirklich gilt ist
immer noch das, was im Grundbuchamt steht,

00:53:56.360 --> 00:53:59.480
und das wird dann halt solange so
weiterbetrieben, bis sich das wirklich

00:53:59.480 --> 00:54:03.220
bewährt hat, und man den Übergang macht.
Und die zweite Frage, sorry, habe ich

00:54:03.220 --> 00:54:04.220
wieder vergessen.

00:54:04.220 --> 00:54:10.790
Herald: Okay, wenn das die Frage
beantwortet und er nicht wieder aufsteht,

00:54:10.790 --> 00:54:14.760
dann würde ich jetzt mit Mikrofon 7
weitermachen, dort oben, bitte.

00:54:14.760 --> 00:54:20.140
Frage: Ja, vielen Dank für den spannenden
Vortrag. Mich würde noch interessieren,

00:54:20.140 --> 00:54:24.970
vielleicht noch was zu dem Thema ‚Ende
der Bitcoins‘, die sind ja anscheinend

00:54:24.970 --> 00:54:29.220
begrenzt, soweit ich das verstanden habe.
Und wie wird das Erstellen von neuen

00:54:29.220 --> 00:54:33.880
Blöcken letztendlich in ferner Zukunft
dann belohnt, werden die einfach immer so

00:54:33.880 --> 00:54:36.690
weiter unterteilt, und man bekommt dann
nur noch Bruchteile von Bitcoins

00:54:36.690 --> 00:54:38.280
als Belohnung, oder wie funktioniert das?

00:54:38.280 --> 00:54:41.850
vimja: Das ist eine sehr gute Frage,
die sich natürlich auch diesen Sommer

00:54:41.850 --> 00:54:45.470
gestellt hat, weil sich ja der
Block Reward halbiert hat.

00:54:45.470 --> 00:54:49.150
Und erstaunlicherweise ist es dann aber
eigentlich ohne Weiteres weitergegangen.

00:54:49.150 --> 00:54:53.210
Nun ist es so, der Mechanismus,
der eigentlich greifen sollte, ist

00:54:53.210 --> 00:54:57.880
die Transaction Fees. Dass es durch
die Transaction Fees getragen wird,

00:54:57.880 --> 00:55:02.050
diese Gebühr. Nur ist es heute so, dass
die Transaction Fees so niedrig sind,

00:55:02.050 --> 00:55:07.410
dass das Minen sich nicht rentieren würde,
also der Stromverbrauch ist viel zu hoch,

00:55:07.410 --> 00:55:13.720
als dass es sich lohnen würde, nur
für die Transaction Fees zu minen.

00:55:13.720 --> 00:55:17.390
Andererseits ist es aber so, dass die
Transaction Fees heute schon sehr hoch

00:55:17.390 --> 00:55:21.090
sind, also die kommen heute irgendwo
zwischendurch schon in die Bereiche

00:55:21.090 --> 00:55:24.740
der Transaction Fees, die man auch
zahlt bei Kreditkartenüberweisungen.

00:55:24.740 --> 00:55:28.950
Und das ist natürlich absolut lächerlich
hoch. Und dann ist es aber auch so,

00:55:28.950 --> 00:55:32.970
dass die Blöcke voll sind, d.h. wenn das
Block Limit – das ist ein künstliches

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

00:55:37.260 --> 00:55:41.830
darüber ob man das jetzt ändern soll oder
nicht – aber wenn dieses Limit halt nicht

00:55:41.830 --> 00:55:44.770
erhöht wird, dann passen nicht mehr
Transaktionen rein, und dann ist

00:55:44.770 --> 00:55:48.770
der einzige Weg höhere Transaction…
also mehr Transaction Fees zu haben

00:55:48.770 --> 00:55:52.060
für den Miner, ist diese Transaction Fees
zu erhöhen. Und wenn man die weiter

00:55:52.060 --> 00:55:55.920
erhöht, dann lohnt es sich einfach
nicht mehr, Bitcoin zu verwenden.

00:55:55.920 --> 00:55:58.531
Im Moment ist es noch nicht so ein
Problem, für die nächsten vier Jahre

00:55:58.531 --> 00:56:02.640
sind es ja noch 12,5 Bitcoin die
man kriegt. Aber wie es danach

00:56:02.640 --> 00:56:06.940
weitergehen wird, das muss man abwarten,
und dann schauen, was da genau passiert.

00:56:06.940 --> 00:56:10.750
Und ich denke dass das ist auch noch ein
dynamisches System, das sich schnell

00:56:10.750 --> 00:56:14.130
wandelt, und da werden auch noch
viele Leute viele gute Ideen haben.

00:56:14.130 --> 00:56:17.770
Frage: Darf ich noch mal kurz was
nachfragen? D.h. der Proof-of-Work

00:56:17.770 --> 00:56:22.980
ist nicht der direkte Bitcoin, den ich
bekomme, also nicht die 12,5 Bitcoins,

00:56:22.980 --> 00:56:26.040
die ich bekomme, um einen Block zu
erstellen, ist nicht der Proof-of-Work?

00:56:26.040 --> 00:56:31.930
vimja: Nein nein, das ist… die 12,5 Bitcoin
die du kriegst, also die 12,5 Bitcoin

00:56:31.930 --> 00:56:34.940
plus das klein weniger, was von den
Transaction Fees kommt, das ist

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,

00:56:39.430 --> 00:56:43.040
dass du die Arbeit auf dich genommen
hast, einen Block zu erstellen.

00:56:43.040 --> 00:56:49.800
Herald: Gut, dann machen wir oben
auf dem Balkon weiter mit der 8. Bitte.

00:56:49.800 --> 00:56:52.600
Frage: Ja, das ganze Erstellen von
den Blöcken basiert ja darauf, dass

00:56:52.600 --> 00:56:56.680
Transaktionen in des Syschtem reinkommen.
Die Frage wäre jetzt, was passiert, wenn

00:56:56.680 --> 00:57:01.880
keine Transaktionen zur Verfügung stehen.
Werden dann Dummy-Transaktionen erzeugt,

00:57:01.880 --> 00:57:03.880
oder leere Blöcke, oder was passiert dann?

00:57:03.880 --> 00:57:08.220
vimja: Nein, das kannst du sehen, wenn du
ganz zurückgehst, die ersten Blöcke, die

00:57:08.220 --> 00:57:11.690
überhaupt erstellt wurden, dort gab es ja
noch keine Transaktionen. Was hätte auch

00:57:11.690 --> 00:57:16.550
überwiesen werden sollen wenn niemand Geld
hat. Und da war es dann halt so, dass

00:57:16.550 --> 00:57:21.180
der Block enthält dann nur die Coin-based-
Transaktion. Der Miner wird ja immer

00:57:21.180 --> 00:57:25.000
eine Coin-based-Transaktion machen.
Einfach, weil es für ihn interessant ist.

00:57:25.000 --> 00:57:29.140
Und dann erstellt er halt einen Block, der
nur diese Coin-based-Transaktion enthält.

00:57:29.140 --> 00:57:35.940
Herald: Dann machen wir weiter
hier vorne mit der 2. Bitte.

00:57:35.940 --> 00:57:38.300
*Mikro 2 will Mikro 4 Vorrang geben*
Bitte?

00:57:38.300 --> 00:57:41.720
Wenn du nicht möchtest, dann machen
wir mit der 4 weiter! Sehr fair von dir!

00:57:41.720 --> 00:57:48.830
Frage: Och, dankeschön. Ich habe das Thema
‚Blockchain‘ in verschiedenen Kontexten

00:57:48.830 --> 00:57:51.790
jetzt im letzten Jahr sehr viel gesehen.
Es ist fast ein Buzzword in sehr sehr

00:57:51.790 --> 00:57:55.900
vielen Branchen, von FinTech bis zu
IoT oder wo auch immer. Konntest du

00:57:55.900 --> 00:57:59.920
im Kontext deiner Arbeit ein bisschen
so einen Trend raussehen, wo sich da

00:57:59.920 --> 00:58:01.420
erste Anwendungen
wirklich bewähren können?

00:58:01.420 --> 00:58:08.420
vimja: Erste Anwendungen gibt es ja bereits.
Du kannst mit Bitcoin Dinge bezahlen.

00:58:08.420 --> 00:58:13.930
Aber das ist so ein wenig eine Sache.
Eines, was ich gesehen habe, wo ich mich

00:58:13.930 --> 00:58:18.310
aber schlicht weigere mich zu beteiligen,
ist halt dass Banken das zu verwenden

00:58:18.310 --> 00:58:23.290
versuchen, um die Transaktionen zwischen
den Banken zu regeln. Da wird es ja,

00:58:23.290 --> 00:58:26.410
glaube ich, im Anschluss im Saal G
einen Talk geben dazu, wie das heute

00:58:26.410 --> 00:58:30.980
gemacht wird, wie Banken zwischeneinander
Geld austauschen. Und das möchte man

00:58:30.980 --> 00:58:34.220
in Zukunft mit Bitcoin [*eher: Blockchain*]
machen. Und da sind die Banken auch dran,

00:58:34.220 --> 00:58:38.940
sehr viel Geld und sehr viel Zeit rein zu
investieren. Das ist halt sehr schade,

00:58:38.940 --> 00:58:43.210
dass diese eigentlich coole Technologie
jetzt für sowas verwendet werden soll.

00:58:43.210 --> 00:58:48.940
Aber ich denke das ist eine Anwendung die
kommt. Dann eben einfache Kryptowährungen,

00:58:48.940 --> 00:58:53.540
wie etwa Bitcoin, um Dinge
zu bezahlen. Und auch…

00:58:53.540 --> 00:58:57.590
ich denke auch mit Ethereum, eben gerade
diese Smart Contracts werden kommen,

00:58:57.590 --> 00:59:01.340
dass man halt eben irgendwelche Dinge,
irgendwelche Third Parties, die man

00:59:01.340 --> 00:59:05.970
verwendet für Dinge zu regeln, ersetzen
wir jetzt aber. Was jetzt als Erstes

00:59:05.970 --> 00:59:09.560
quasi den Durchbruch schaffen wird und
als Großes eingesetzt werden wird,

00:59:09.560 --> 00:59:10.560
kann ich dir nicht sagen.

00:59:10.560 --> 00:59:15.630
Herald: Gut, dann, wir sind so ganz knapp
an der Zeit, aber du darfst deine Frage

00:59:15.630 --> 00:59:17.050
auf jeden Fall stellen, bitte!

00:59:17.050 --> 00:59:20.520
Frage: Ist auch nur eine ganz kurze,
schnelle Frage. Gibt es einen Schutz

00:59:20.520 --> 00:59:24.460
gegen DDoS, dass ich irgendwie das
Netzwerk mit falschen Transaktionen

00:59:24.460 --> 00:59:28.760
bombardiere, und dann bricht alles
zusammen, gibt es da irgendwie

00:59:28.760 --> 00:59:29.760
einen Schutz dagegen?

00:59:29.760 --> 00:59:32.130
vimja: Ja, das war ja ganz interessant.
Das hat es glaube ich vor über einem Jahr

00:59:32.130 --> 00:59:35.050
gegeben, bei Bitcoin, dass das passiert
ist, und die waren sich dann

00:59:35.050 --> 00:59:38.630
nicht so ganz einig in der Community,
weil die mögen sich sowieso nicht mehr,

00:59:38.630 --> 00:59:42.540
und ‚kriegen‘ nur miteinander, die waren
sich da nicht so ganz einig, ob das jetzt

00:59:42.540 --> 00:59:46.391
ein Test war, oder ob das ein DDoS war.
Und das Interessante daran ist ja,

00:59:46.391 --> 00:59:51.630
dass es ja tatsächlich Geld kostet, eine
Transaktion zu machen. Also du zahlst

00:59:51.630 --> 00:59:55.790
zuerst eine Transaction-Gebühr, und der
Schutz sollte eigentlich, hoffentlich,

00:59:55.790 --> 00:59:59.520
sein, dass das da zu teuer ist.
Aber offenbar gibt es immer noch

00:59:59.520 --> 01:00:04.340
so viele Bitcoin-Millionäre, die einfach
Bitcoins haben zum Davonschmeißen,

01:00:04.340 --> 01:00:09.160
und die dann sowas tun können. Es
wird auf jeden Fall an irgendwelchen

01:00:09.160 --> 01:00:11.770
Schutzmechanismen gearbeitet, aber
was das ist… *zuckt mit den Schultern*

01:00:11.770 --> 01:00:15.780
Also was es gibt, in Bitcoin,
ist dieses Replace-by-Fee,

01:00:15.780 --> 01:00:22.890
damit die Transaction-Gebühr nach
der Veröffentlichung der Transaktion

01:00:22.890 --> 01:00:25.920
anschließend noch erhöht werden
kann. Und damit kannst du halt…

01:00:25.920 --> 01:00:29.030
wenn du jetzt siehst, es kommen sehr viele
DDoS-Transaktionen rein, kannst du halt

01:00:29.030 --> 01:00:33.640
im Nachhinein die Transaction-Gebühr
erhöhen, und das dadurch den Minern

01:00:33.640 --> 01:00:36.970
quasi schmackhaft machen, deine
valide Transaktion zu includen.

01:00:36.970 --> 01:00:43.600
Dieses Replace-by-Fee, dieses RBF,
ist aber sehr stark umstritten, und

01:00:43.600 --> 01:00:47.990
wird auch standardmäßig nicht
aktiviert von der Client-Software.

01:00:47.990 --> 01:00:56.290
Herald: Gut, dann danke vimja, für diese
großartige Einführung in die Blockchain!

01:00:56.290 --> 01:00:57.290
*Beifall*

01:00:57.290 --> 01:00:58.290
*Abspannmusik*

01:00:58.290 --> 01:01:05.809
*Untertitel erstellt von c3subtitles.de
im Jahr 2017. Mach mit und hilf uns!*