Proseminar Bitcoins: Netzwerkmessung

Tim Suchanek

Abstract

Seit 2005 sind verteilte Hash Tabellen (engl. Distributed Hash Tables, kurz DHT) im Einsatz
vom Filesharing Netzwerk Bittorrent. Besonders die Stabilitat und Performance ist in solch
einem DHT Netzwerk sehr wichtig. Sehr ahnliche Anforderungen gelten auch f
ur das Netzwerk
der virtuellen W
ahrung Bitcoin. In dieser Proseminar Arbeit werden besonders basierend
auf dem Paper von J
unemann et al. [JuAH11] diese beiden Netzwerke unter den Aspekten
der Netzwerkgr
oe, der geographischen Verteilung, der sog. Guarded Hosts, dem Netzwerk
Bootstrapping, den Session L
angen und den Verbreitungs- und Lookup Geschwindigkeiten
verglichen.

Einleitung

Eine Distributed Hash Table (DHT) ist ein Peer-to-Peer (P2P) Netzwerk, dass den Lookup
aber auch das Speichern von Schl
ussel/Wert (engl. key/value) Paaren in einem Netzwerk
ermoglicht. Dabei gibt es viele verschiedene Ansatze, wie zB. das Kademlia, das Chord oder

auch das Pastry Protokoll. Einen Uberblick

der Protokolle gibt es in [Lim05].
DHTs finden ihren Einsatz in den unterschiedlichsten Bereichen. Bisher meist durch akademische Motivationen wurden verteilte Dateisysteme, Inhalts Verbreitungssysteme (engl. content
distribution), verteilte DNS Systeme aber auch Verkehrsinformationssysteme, DHT basiert
entwickelt. Auch wenn diese Anwendungen die DHT f
ur sich sehr mageschneidert verwenden,
greifen alle Anwendungen auf die gleichen darunterliegenden Prinzipien zu. Zu diesen gehoren unter anderem der verteilte Informations Lookup, Routing oder auch Daten Speicherung.
Dies muss jedoch auch gleichzeitig skalierbar sein.
Da die Anwendungen damit
ahnliche Anforderungen haben, liegt die Idee nahe, einen dedizierten und o
ffentlichen
DHT
Service aufzubauen, den sich verschiedene Anwendungen teilen

konnen. Dann muss nicht jede Anwendung eine eigene Infrastruktur aufbauen und kann direkt auf einer h
oheren Ebene der Architektur einsteigen. Diese Idee ist nicht neu. Bereits 2005
wurde mit OpenDHT [Yu05] genau dieser Ansatz verfolgt. OpenDHT wurde im Rahmen einer Ph.D. Thesis entwickelt und war als offentlicher DHT Service gedacht, der im PlanetLab,
einer f
ur akademische Zwecke freien Testumgebung, lief. Wahrend OpenDHT zwar als eine
geeignete Test -und Entwicklungsumgebung f
ur neue DHT Anwendungen galt, weil man sich
nicht um die Bereitstellung der Netzwerkinfrastruktur k
ummern musste, gab es trotzdem
zwei wesentliche Nachteile: Zum einen skalierte OpenDHT nicht mit der wachsenden Anzahl
der Netzwerkteilnehmer (engl. Peers). Denn nur die PlanetLab Knoten haben zum Netzwerk
beigetragen. Zum anderen mussten diese Knoten auch gewartet werden, was bei einem dezentralisierten Netzwerk nicht der Fall gewesen ware. 2009 wurde der OpenDHT Service dann
eingestellt.
Mit einem auf Endbenutzer verteilten Netzwerk w
urden diese beiden Nachteile nicht mehr ins
Gewicht fallen. Deswegen wird im Paper von J
unemann et al. [JuAH11] untersucht, ob ein

solches Basis DHT Netzwerk mit der Idee von OpenDHT moglich ist, dem jedoch die Endbenutzer zum Erfolg beitragen und den sich viele verschiedene Anwendungen teilen konnen.
Die Faktoren, die f
ur die Umsetzung eines solchen Netzwerks besonders wichtig sind, hangen
jedoch stark von den Endbenutzern und weniger der Implementierung ab. Deswegen macht
es Sinn, hier zuerst bestehende Netzwerke zu erforschen. Zu den wichtigen Kennzahlen gehort
besonders die Lookup Zeit, also die Zeit, die benotigt wird, bis der Inhalt (engl. value) zu
einem gewissen Schl
ussel (engl. key) im Netzwerk gefunden wird. Diese ist wiederum abhangig von einigen anderen Faktoren, wie zB. der Sitzungslange (engl. session length), aber auch
dem Anteil der bewachten Teilnehmer (engl. Guarded Hosts), also Teilnehmer des Netzwerks,
deren Datenverkehr durch NAT Gateways oder Firewalls eingeschrankt ist. Dazu wird spater
noch in den Grundlagen 3.4 eingegangen. Eine groe Gefahr f
ur die Stabilitat des Netzwerks
stellt die sog. Churn Rate dar, also die Anzahl von Benutzern, welche das Netzwerk zu einem
bestimmten Zeitpunkt verlassen und beitreten. Da die gespeicherten Daten auch f
ur langere
Zeit im Netzwerk bestehen sollen, m
ussen dementsprechend Daten dupliziert und transferiert
werden, damit sie nicht verloren gehen. Wenn also Knoten im Netzwerk wegfallen, muss sich
das Netzwerk um diese L
ucken herum stricken.

Auerdem wichtig f
ur eine erfolgreiche Umsetzung eines offentlichen DHT Service, ist die
Vertrauensw
urdigkeit der einzelnen Teilnehmer. Wenn zB. bestimmte Benutzer in einem Verkehrssystem bewusst falsche Informationen verbreiten, kann das fatale sicherheitstechnische
Folgen f
ur das gesamte System haben. Bis auf die Vertrauensw
urdigkeit werden diese Punkte
alle in [JuAH11] untersucht. F
ur diese Untersuchungen galt es, ein Netzwerk geeigneter Gr
oe zu finden, dem man so viel Informationen entnehmen kann, dass man ihnen eine gewisse
Aussagekraft entziehen kann.
Wahrend mit OpenDHT die ersten Versuche in dem Bereich der offentlich eingesetzen DHTs
gemacht wurden, hat auch die Filesharing Community DHTs f
ur sich entdeckt. Bis 2005 gab
es namlich in den Bittorrent Peer-to-Peer (P2P) Netzwerken immer noch einen zentralen
Aspekt. Und zwar muss dem Netzwerk bekannt gemacht werden, wo Dateien aber auch Teile
von Dateien liegen und von wo man diese Dateien moglichst schnell her bekommt. Diese
Aufgabe u
bernehmen die sog. Tracker. Diese Tracker wurden bis 2005 noch u
ber zentrale
Server verwaltet, die zB. von Organisationen wie The Pirate Bay [pir] zur Verf
ugung gestellt

werden. Um diese zu entlasten und den dezentralisierten Charakter auch in diesem Aspekt von
Bittorrent umzusetzen, wurde eine Alternative zu Trackern mithilfe von DHTs implementiert.
Diese enthalten dann kleine Informationspakete hinterlegt hinter einem Hash, wo sich die
Daten schlussendlich befinden. Mittlerweile sind diese DHTs auch im Einsatz im Bittorrent
Netzwerk, jedoch hat der Endbenutzer die Wahl, ob er sie oder die herkommlichen Tracker
einsetzt.
Eine der gr
oten dieser Tracker Alternativen ist das Bittorrent Mainline DHT Netzwerk mit
u
ur ein erfolgreiches DHT Netzwerk
ber 10 Millionen aktiven Peers. Da die Faktoren, die f
wichtig sind, besonders vom Endbenutzer Verhalten abhangen, kann man in einem Netzwerk
dieser Groe wichtige Erkenntnisse erlangen, ob ein Basis DHT, wie es in [JuAH11] vorgeschlagen wird, m
oglich ist. Die DHTs im Einsatz der Filesharing Netzwerke zu betrachten,
hat jedoch auch noch einen anderen entscheidenden Vorteil. Die Autoren von [JuAH11] gehen sogar so weit, dass sie vorschlagen, den Basis DHT Service in den Filesharing Clients
einzubauen. Momentan werden die minimalistischen DHT Clients auch schon im normalen
Filesharing Client ausgeliefert, diese konnte man dann direkt mit dem f
ur allgemeinere Zwecke
erweiterten Basis DHT Client ersetzen.
So wird in [JuAH11] genau dieses Bittorrent Mainline DHT Netzwerk analysiert, welches auf
dem Kademlia Protokoll aufbaut. Da auch das Peer-to-Peer Netzwerk der virtuellen Wahrung
Bitcoin eine
ahnliche Struktur aufweist, jedoch bis jetzt sehr wenig erforscht ist, versuchen
wir, Parallelen zwischen diesen beiden Netzwerken zu finden. Als Vergleich von Bitcoin Seite

dient das Paper von Donet et al. [Joan14]. Da auerdem der skalierbare und sichere Informationsfluss u
ber die ganze Welt eine groe Rolle bei beiden Netzwerken spielt, werden sie in
dieser Proseminar Arbeit unter bestimmten Gesichtspunkten verglichen.
Zu diesen Punkten geh
oren:
1. Gro
e der Netzwerke: Die Netzwerkarchitektur muss jeweils so konstruiert sein, dass
das Netzwerk mit beliebiger Groe skaliert, ohne dass die Performance einb
ut. Hier
wird die Gr
oe anhand der Anzahl der Teilnehmer (engl. Peers) bemessen, auch wenn
im Bitcoin Netzwerk die Rechenkraft eine wichtige Groe des Netzwerks darstellt.
2. Geographische Verteilung: Damit beide Netzwerke u
berall auf der Welt performant
funktionieren k
onnen, m
ussen sie moglichst gleichmaig u
ber die Kontinente verteilt
sein. Da Bitcoin einige Jahre nach Bittorrent zum Leben berufen wurde, ist es auerdem
aus sozialwissenschaftlicher Sicht interessant zu sehen, dass wenn ein Benutzer bereits
Bittorrent benutze, ob er auch eher dazu bereit ist, Bitcoin einzusetzen.
3. NATs/Firewalls: Die Performance des DHT Netzwerks wird stark durch Peers eingeschr
ankt, welche NAT Gateways oder Firewalls im Einsatz haben. Die Frage ist, ob
dies auch f
ur Bitcoin gilt.
4. Bootstrapping: Direkt nach dem Starten der jeweiligen Clients muss in einer gewissen
Weise eine initiale Verbindung zum Netzwerk aufgebaut werden. Auerdem muss gewahrleistet sein, dass die Verbindung auch tatsachlich zum echten Netzwerk aufgebaut
wird. Dieser Prozess des sog. Bootstrapping wird in beiden Netzwerken ahnlich gelost.
5. Sessionl
angen: Die Sessionl
angen spielen f
ur die Stabilitat eines DHT Services eine
sehr groe Rolle. Jedoch auch im Bitcoin Netzwerk m
ussen gewisse Sessionlangen eingehalten werden, damit die Teilnahme am Netzwerk u
berhaupt erst Sinn macht.
6. Lookup- und Verbreitungs Geschwindigkeit: Im DHT Netzwerk ist eine der
wichtigsten Charakteristiken die Lookup Geschwindigkeit von key/value Paaren im
Netzwerk. Die Messung aus [Joan14], die dieser Kennzahl am nachsten ist, ist die

Verbreitungsgeschwindigkeit, in der Anderungen

an der Blockchain den anderen Peers
mitgeteilt werden.

3
3.1

Grundlagen
Kademlia

Das Bitcoin Mainline DHT Netzwerk basiert auf dem Kademlia Protokoll. Kademlia ist eines
von mehreren DHT Protokollen, die die verteilte Speicherung von key/value Paaren ermoglichen. Wahrend Kademlia zwar den Aufbau des Netzwerks vorgibt, konnen die Implementierungen stark variieren, was auch einen Einfluss auf die Performance haben kann. Alle Peers
bekommen innerhalb des DHT Netzwerks eine eindeutige ID zugeordnet. Entweder besteht
diese ID schon, wenn der Client bereits zum Netzwerk verbunden war, oder sie wird im Client
zufallig generiert. Diese ID stammt aus einem 160 bit Bereich (engl. ID Space). In diesem ID
Space sind aber auch die Hash Werte der zu speichernden Daten untergebracht. Dieser Hash
muss nat
urlich im gesamten Netzwerk von dem selben Algorithmus ausgef
uhrt werden, da
sonst die Hashs nicht mehr korrespondieren. Im Bittorrent Mainline DHT ist dies der SHA-1
Hash eines Torrents. Ein Torrent ist eine Bittorrent spezifische Datei, die Metainformationen
zu der Datei selbst enth
alt.

F
ur die Speicherung eines Hash Werts sind die nachsten 8 Peers zustandig, deren ID moglichst
nah an dem gesuchten Hash Wert liegt. Der Abstand von Hash und ID wird mit der XOR
Metrik gemessen. Dabei wird das exklusive Oder (XOR) bitweise zwischen den beiden Werten
gebildet. Das Ergebnis dieser Operation wird dann als Integer interpretiert und gibt damit
die Distanz an. Wenn ein Knoten selbst eine Information in das Netzwerk einspeisen mochte,
dann berechnet er zuerst den charakteristischen Hash Wert der Information. Dann sucht er
die 8 Knoten, die am n
achsten am Hash liegen und propagiert an diese seine Information.
Um im Kademlia Netzwerk kommunizieren zu konnen, gibt es sog. Remote Procedure Calls
(RPCs):
PING: Um die Verf
ugbarkeit von anderen Peers u
ufen zu konnen.
berpr
STORE: Um ein key/value Paar zu einer gewissen Adresse zu speichern.
FIND NODE: Um Peers zu finden, deren Distanz gering zu einer gewissen Knoten ID
ist.
FIND VALUE: Um an den Value zu einem gewissen Key zu erlangen.
Diese Befehle, die u
ber das Netzwerk an andere Peers geschickt werden konnen, werden u
ber
das KRPC Protokoll verschickt, welches auf UDP basiert.
Um den Value zu einem Key erhalten zu konnen, muss der Knoten einen Lookup durchf
uhren.
Der Lookup Prozess l
auft wie folgt ab:
1. F
uhre einen FIND NODE RPC bei den aktuell bekannten Peers aus, die moglichst nah
an der Ziel ID liegen.
2. Frage die neu erhaltenden Peers auch mit einem FIND NODE RPC nach weiteren Peers
ab.
3. Wiederhole Schritt 2 solange, bis keine Peers mehr erscheinen, die naher an der Ziel ID
als die schon bekannten Peers liegen.
4. Hole u
ber FINDE VALUE den Inhalt zur Ziel ID von den 8 bekannten Peers.

3.2

Untersuchungen DHT Netzwerk

W
urde man das komplette Mainline DHT Netzwerk durch scannen, so w
urde ein Scan oder
auch Crawl genannt, einige Stunden dauern. Von Anfang bis Ende der Messung hatte sich
dann schon wieder so viel im Netzwerk geandert, dass es in der Messung eine groe Ungenauigkeit gibt. Deswegen haben die Autoren von [JuAH11] sich daf
ur entschieden, nur eine
Stichprobe vom Netzwerk zu nehmen. Diese benotigt zum einen weniger Bandbreite und zum
anderen kann sie schneller berechnet werden. Daf
ur wird der ID Space von 2152 Kademlia
1
IDs untersucht, was 256 des Netzwerks ausmacht. Hier wird die Annahme gemacht, dass die
IDs gleichm
aig u
ber den kompletten ID Space verteilt sind. Somit sollte die Geographie der
Peers hier keine Rolle spielen. Der Crawler selbst benutzt im Gegensatz zu anderen Crawlern
nur DHT Lookups, um sich im Netzwerk fortzubewegen. Es wurden 10 Lookups pro Se
kunde gemacht. Der Scan dieses ID Bereichs ist in mehrere Zyklen aufgeteilt. Die Anzahl der
Lookups pro Zyklus verdoppelt sich nach jedem Zyklus. Damit dauert jeder weitere Zyklus
doppelt so lange.

3.3

Untersuchungen Bitcoin Netzwerk

Das Bitcoin P2P Netzwerk dient besonders der Kommunikation von neuen Transaktionen
oder auch neu berechneten Bl
ocken. In [Joan14] wurde das Netzwerk im Zeitraum vom 30.
November 2013 bis zum 5. Januar 2014 untersucht. Es wurde taglich ein komplettes Abbild
des Netzwerks (engl. network snapshot) gemacht. Diesen Snapshot zu erstellen hat jeweils
ca. 2 Stunden gedauert. Als Basis wurden 600 Peers gewahlt, um von den weiteren Peers zu
erfahren. Insgesamt wurden damit 37 Tage gemessen und 872.648 verschiedene Peers entdeckt.
Es wurden allerdings schon beim ersten Snapshot am ersten Tag 111.475 Knoten gefunden.

Das zeigt, dass eine groe Uberlappung

der Knoten existiert, womit das Netzwerk eine gewisse
Stabilitat aufweist.
Um die Informationsausbreitung messen zu konnen, wurden 2000 Peers ausgewahlt, zu denen
parallel eine Verbindung aufgebaut wurde. 1377 von diesen haben die Verbindung akzeptiert.
Von diesen 1377 Peers wurde 26 Stunden bzgl. Transaktionen und Block Chains gelauscht.
Nach den 26 Stunden wurden dann lediglich die Block Chain Informationen f
ur weitere 92
Stunden beobachtet. Die Autoren nennen als Grund, dass sie weiterhin Informationen bzgl.
der Blocke erhalten, jedoch nicht von der Datenflut der Transaktionen beeinflusst werden
wollten. Insgesamt wurden in dieser Sondermessung dann 13.910.769 Transaktionen wahrgenommen, von denen 70.254 einzigartig wahren. Bzgl. der Blockinformationen wurden 492.793
Block Kopien mit 11.663 tats
achlich unterschiedlichen Blocken empfangen.

3.4

Guarded Hosts

Guarded Hosts, also Teilnehmer des Netzwerks, die entweder durch NAT Gateways oder auch
Firewalls eine eingeschr
ankte Konnektivitat haben, verlangsamen die Lookup Geschwindigkeit
im Netzwerk. Durch sie schlagen die RPCs mit einer gewissen Wahrscheinlichkeit fehl, da die
Pakete durch das UDP Protokoll leicht verloren gehen konnen und im Gegensatz zum TCP
Protokoll, das im Bitcoin Netzwerk eingesetzt wird, kein Handshake stattfindet. Infolgedessen
kann es passieren, dass Guarded Hosts von anderen Peers keine Pakete erhalten, wenn sie
diesen nicht vorher auch schon Pakete geschickt haben.

3.5

Pearson Korrelationskoeffizient

In Abschnitt 5 wird mithilfe des Pearson Korrelationskoeffizienten die Korrelation zwischen

den landerspezifischen Messdaten der Netzwerke gebildet. Im Folgenden soll erklart werden,
wie dieser Koeffizient berechnet wird. Wir betrachten im Folgenden den empirischen Pearson
Korrelationskoeffizienten, welcher sich auf Messreihen bezieht.
Der Pearson Korrelationskoeffizient wurde vom britischen Mathematiker Karl Pearson zusammen mit dem franz
osischen Physiker Auguste Bravais entwickelt. Man kann ihn benutzen, um
den linearen Zusammenhang von zwei Messreihen zu berechnen. Er kann alle Werte zwischen
-1 und +1 annehmen. Dabei gilt Kor(X, X) = 1 und Kor(X, X) = 1. Gilt allerdings
Kor(X, Y ) = 0, so sind die beiden Messreihen komplett von einander unabhangig.
Hat man eine Messreihe von gepaarten Auspragungen (x1 , y1 ), (x2 , y2 ), ..., (xn , yn ), so wird
nun der sog. empirische Korrelationskoeffizient wie folgt gebildet:
n
P

Kore (x, y) := %e (x, y) := rx y := s

(xi x
)(yi y)

i=1
n
P

(xi x
)2

i=1

n
P

(yi y)2

i=1

Dabei sind x
=

n
n
1 P
1 P
xi und y =
yi die empirischen Mittelwerte, berechnet anhand der
n i=1
n i=1

Messreihe.

3.6

Netzwerk Bootstrapping

Wenn ein DHT Client gerade gestartet wurde, muss er die Adressen von initialen Peers bekommen, damit er am Netzwerk teilnehmen kann. Daf
ur gibt es im Client schon vorprogrammierte
sog. DHT Bootstrap Nodes. Diese werden oft von den Client Herstellern selbst betrieben und
sind jeweils u
ber eine DNS Adresse erreichbar. Solch einen DHT Bootstrap Server kann auch
jeder selbst betreiben, auf Github [dhtb] ist der Code zu finden.
Hingegen im Bitcoin Netzwerk, werden drei alternative Bootstrapping Methoden angeboten:
1. Addr: Der Bitcoin Client beinhaltet eine feste List von initialen Knoten Adressen,
um zum Netzwerk verbinden zu konnen. Hatte man noch keine Verbindung u
ber das
IRC Bootstrapping (Siehe Punkt 3) und keine Verbindung zum Netzwerk, wird diese
Adressendatenbank durch das Verbinden zu einem der Knoten erneuert.
2. DNS: Von bekannten DNS Adressen holt sich Bitcoin die korrespondierenden IP Adressen und f
ugt diese zu der Liste der potentiellen Adressen hinzu
3. IRC: Seit der 0.6.x Version des Bitcoin Clients ist das IRC Bootstrapping nicht mehr
als Standard definiert. Die IRC Bootstrapping Prozedur lauft jedoch wie folgt ab:
Bitcoin tritt zuf
allig einem IRC Channel zwischen #bitcoin00 und #bitcoin99 auf
irc.lfnet.org bei. Der Nickname ist eine encodierte Version der IP Adresse. Wenn man
nun die Nicknames der anderen Benutzer in diesem Channel dekodiert, erhalt man die
IP Adressen der momentan zu Bitcoin verbundenen Benutzern.

Gr
oe der Netzwerke

In [JuAH11] wird die Gr

oe des Netzwerks dadurch berechnet, dass die Autoren ausgehen,
1
dass ihre Stichprobe 256 des gesamten Netzwerks darstellt. Die Anzahl der Peers wird auf
die gesamte Netzwerk Gr
oe extrapoliert, in dem man sie mit 256 multipliziert. Eine der
wichtigsten Kennzahlen in diesem Bereich ist die schon in Abschnitt 2 vorgestellte Churn
Rate. Wenn Peers das Netzwerk st
andig verlassen und ihm wieder beitreten, gilt es nat
urlich,
jeweils neue Peers zu finden und zu ihnen zu verbinden. Dadurch konvergiert die Anzahl der
Peers, die pro Sekunde gefunden werden nicht gegen 0, sondern gegen die Churn Rate. Um die
Churn Rate im Netzwerk messen zu konnen, hab die Autoren von [JuAH11] einen angepassten
Crawler eingesetzt. Dieser Crawler untersucht das Netzwerk in festen Zyklen mit jeweils 214
Lookups, mit einer Geschwindigkeit von 160 Lookups pro Sekunde. In jedem Zyklus speichert
der Crawler wie viele neue Peers hinzukamen, die nicht im letzten Zyklus entdeckt wurden.
Mit dieser Methodik konnte eine Churn Rate von durchschnittlich 288.23 Peers pro Sekunde
gefunden werden.
Die Autoren von [JuAH11] konnten auerdem einen deutlichen taglichen Zyklus der Benut
zung des Netzwerks erkennen. Uber
die Woche steigt zu dem die Netzwerkauslastung, mit dem
Hohepunkt am Sonntag mit einer Steigerung von 60% im Vergleich zum wochentlichen Minimum am Mittwoch. Eine auf den DHTs basierende Anwendung m
usste also mit den taglichen
Fluktation umgehen k
onnen. Jedoch wurden keine unvorhergesehenen Hoch- oder Tiefpunkte im Netzwerk festgestellt, womit eine stabile Grundlage f
ur DHT basierende Anwendungen
geboten werden kann.

In [Joan14] wurden lediglich t

agliche Messungen gemacht. Es wird auch nicht auf die Churn
Rate eingegangen, womit hier der Vergleich nicht moglich ist.

Abbildung 1: Messungen des SCCs

Jedoch ist festzustellen, dass beide Netzwerke jeweils u
ber die Monate verteilt groe Fluktuationen aufweisen. Im DHT Netzwerk haben die Forscher im Mai 2014, 3 Jahre nach dem sie
ihr Paper ver
offentlicht haben, eine Verdopplung der Netzwerkgroe festgestellt, die innerhalb
von 7 Tagen von statten ging. Eine weitere groe Fluktuation wird im nachsten Abschnitt
betrachtet, die im Bitcoin Netzwerk von November 2013 bis Februar 2014 stattfand. Obwohl
die Netzwerke schon mehrere Jahre etabliert sind, kann die Groe also signifikant u
ber kurze
Zeit variieren.

Geographische Korrelation

In diesem Abschnitt wird untersucht, wie gro die Korrelation ist, wenn in einem Land Bittorrent mit einer gewissen Gr
oe etabliert ist, ob auch Bitcoin in einer ahnlichen Groe in diesem
Land verwendet wird. Die zugrundeliegenden Daten der DHTs kommen vom Steinbuch Centre of Computing (SCC). Hier haben wir die Landerverteilung aller gemessenen Peers vom
Zeitraum 19.02.2013 11:11:03 CET bis 14.04.2013 11:30:12 CET. In diesem Zeitraum wurden
360 Messungen mit Peers von insgesamt 39 Landern vorgenommen. Verglichen werden diese Daten zum einen mit den Messungen der Universitat Autonoma de Barcelona [Joan14],
welche im Zeitraum vom 30. November 2013 bis zum 05. Januar 2014 stattfanden. Zum anderen werden die Daten mit Messungen der Platform Bitcoin Status [bit] verglichen, welche
vom September 2013 bis zum 06. Juni 2014 festgehalten wurden. Das genaue Anfangsdatum
der Bitcoin Status Messungen ist nicht bekannt. Als Merkmal des Vergleichs wird jeweils die
gemessene absolute Zahl von Peers in einem Land gewahlt.
Die Daten des SCCs [JuAH11] beinhalten jeweils die absolute Anzahl der Peers der Lander

zu einem gewissen Timestamp in Millisekunden. Uber

diese Werte wurde bei jedem Land der
Durchschnitt u
ber
alle
Timestamps
gebildet.
Diese
Werte
setzen wir jetzt mit Hilfe von dem

in Abschnitt 3.5 vorgestellten Pearson Korrelationskoeffizient in Korrelation. Im Folgenden

die gebildeten Korrelationen, jeweils mit dem SCC als Basis.
Korrelationen
Vergleichsmenge
Korrelationskoeffizient
Barcelona, 1. Tag
0.724
Barcelona, 37 Tage
0.548
Bitcoin Status, gesamte Zeit
0.858
Tabelle 1: Messdaten des SCC korreliert mit Daten aus [Joan14] und [bit]

Korrelationen von Bitcoin Status und der Universitat Autonoma de Barcelona

Vergleichsmenge
Korrelationskoeffizient
Barcelona, 1. Tag
0.839
Barcelona, 37 Tage
0.658
Tabelle 2: Messdaten aus [bit] korreliert mit [Joan14]
Wie in Tabelle 1 zu sehen, ist die Korrelation der Messungen aus Barcelona zwar am 1.
Tag noch bei 0.724, was auf eine mittlere Korrelation zur
uck schlieen lasst. Dies andert
sich jedoch dramatisch, wenn man die Messungen u
ber alle 37 Tage betrachtet. Hier liegt
die Korrelation nur noch bei 0.548. An dieser Stelle macht es Sinn, noch eine zweite Quelle
hinzuzuziehen, deswegen wurde hier auch noch Bitcoin Status betrachtet. Mit Bitcoin Status
gibt es einen Koeffizienten von 0.858, womit ein starker Zusammenhang zu den Messungen
bzgl. der DHT besteht.
In den Messergebnissen aus [Joan14] und [bit] gibt es offensichtlich starke Widerspr
uche. Dies
wird besonders deutlich in Tabelle 2. Obwohl eigentlich die selbe Sache gemessen wurde, und
die Messungen u
ohere Aussagekraft haben sollten, haben die Messungen
ber 37 Tage eine h
aus Barcelona nur einen Koeffizienten von 0.658 zu den Daten von Bitcoin Status.
Ein Beispiel f
ur diese groen Unterschiede der Messungen ist Russland und die USA.
Anzahl der Peers
Quelle
Russland
USA
[Joan14]
66705
145495
[bit]
964
6540
Tabelle 3: Unterschiede von Russland und USA aus [Joan14] und [3]
In [bit] hat die USA die 7-fache Anzahl von Knoten von Russland, in [Joan14] lediglich die
2-fache.
In Abb. 2 ist zu sehen, dass w
ahrend dem 30. November 2013 und 05. Januar 2014, als die Messungen aus [Joan14] stattfanden, groe Fluktationen im Netzwerk vorzuweisen sind. Demnach
kann die Aussagekraft der Messungen aus [Joan14] f
ur die tatsachliche gesamte Verteilung
des Bitcoin Netzwerks angezweifelt werden. Besonders ab Marz 2014 ist zu sehen, dass die
Daten sich stabilisieren. Diese Zeit findet hingegen auf akkumuliert Gewicht in den Bitcoin
Status Werten, womit die h
ohere Korrelation dieser Daten von 0.858 zu den Messungen vom
SCC zu erkl
aren ist.

Abbildung 2: Messungen von Bitcoin Status

Sozialwissenschaftlich interpretiert konnen diese Daten so gedeutet werden, dass Menschen,
die bereits Bittorrent im Einsatz haben, auch eher dazu geneigt sind, Bitcoin, was auch ein
P2P-Netzwerk mit
ahnlicher Technologie ist, zu nutzen.
Ein genauerer Ansatz w
are jedoch an dieser Stelle, tatsachlich u
ber die IP Adressen eine
Zuordnung der einzelnen Bitcoin und auch Bittorrent Peers zu erstellen, die tatsachlich jetzt
gerade in beiden Netzwerken sind oder zumindest mit der gleichen IP in beiden Netzwerken
waren. Letzteres wird aber wieder eine gewisse Ungenauigkeit enthalten, da IP Adressen sich
u
ber die Zeit bei manchen Peers dynamisch verandern konnen. Da es jedoch besonders zum
Bitcoin Netzwerk noch wenig Forschung gibt, haben wir uns zu dieser Heuristik entschieden.
In [Wolk14] werden die Ergebnisse von [Joan14] diskutiert und untersucht, ob auch die Art
der Messungen wirklich genau ist. Das Skript um die Korrelationen zu berechnen, wurde in
NodeJS programmiert und ist unter [dhta] auf Github zu finden.
Insgesamt ist zur geographischen Verteilung aus DHT Sicht zu sagen, dass die Peers wohl
verteilt auf der ganzen Welt liegen. Der starkste Kontinent ist dabei Europa mit ca. 38.5%
des gesamten Netzwerks. Wichtig an dieser Stelle zu erwahnen, ist die hohe Veranderung
der Anzahl der Peers aus Europa, die vom taglichen Minimum bis zum taglichen Maximum
um 400% ansteigt. Besonders in Europa m
ussen also Anwendungen auf diese Fluktuationen
achten.
Im Bitcoin Netzwerk hingegen konnte von den Autoren von [Joan14] festgestellt werden, dass
die USA und China zusammen 37% des Netzwerks ausmachen. Lander wie Deutschland, das
vereinigte K
onigreich und auch Russland machen mit 9%, 4%, 7% auch einen groen Teil des
Netzwerks aus.

Lookup- und Verbreitungs Geschwindigkeit

Der Lookup ist eine elementare Operation der DHTs. Zwar muss er beim Filesharing nicht
besonders schnell sein, da meist Dateien innerhalb von mehreren Minuten heruntergeladen
werden, jedoch ist eine kleine Lookup Zeit f
ur andere Anwendungen sehr wichtig. Dazu zahlen

zB. DNS- oder auch Verkehrssysteme. Im Gegensatz zu allen anderen Metriken ist die Lookup Geschwindigkeit sehr abh
angig vom Protokoll selbst. Sogar die Client Implementierung
macht einen groen Unterschied. Dies ist sogar der Fall im selben Netzwerk. Unterschiede der
Implementierungen liegen besonders in der Zeit, die gewartet wird, bis die Anfrage geschickt,
aber auch wie-viele Anfragen gleichzeitig gesendet werden. Um die Lookups auch nachvollziehen zu konnen, haben die Autoren zwei Clients untersucht, deren Code offentlich zuganglich
ist. Diese sind zum einen der Transmission Client 2.12 und der Bittorrent Mainline Client
V.5.2.2. Die Clients haben zu Messzwecken jeweils 400 Lookups durchgef
uhrt. Der Mainline
Client war nach den Messungen 3-mal schneller, zu den Kosten dass er 100-mal so viele Pakete
versendet. Die durchschnittliche Lookup Zeit des Transmission Clients war 250.1 Sekunden,
beim Mainline Client hingegen 78.5 Sekunden. Insgesamt ist zu sagen, dass diese Zeiten nicht
f
ur einen Basis DHT Service reichen w
urden. Jedoch zeigen andere Forschungsarbeiten, dass
kleinere Lookup Zeiten m
oglich sind. So wurde zB. in [StRe06] im KAD Netzwerk eine Lookup Zeit von 2 Sekunden festgestellt. Da dies jedoch in einem anderen Netzwerk mit einem
anderen Client geschah, kann man die Ergebnisse nicht direkt vergleichen.
Im Bitcoin Netzwerk gibt es auch Lookups. Eine andere Metrik, die hier jedoch sehr wichtig
ist, ist die Geschwindigkeit, in der Transaktionen oder selbst neu berechnete Blocke verbreitet werden. Im Bitcoin Netzwerk kann dies viel bedeuten, da es passieren kann, dass derselbe
Block zur gleichen Zeit von einem anderen Peer ausgerechnet wird. Kann dieser seine Losung
der Challenge schneller dem Netzwerk kommunizieren, sodass das Netzwerk seine Losung akzeptiert, hat der Benutzer die Opportunitatskosten von einem Bitcoin, den er verdienen hatte
konnen. Auf der anderen Seite muss eine Transaktion auch im Netzwerk akzeptiert werden,
damit sie valide wird. Hier gilt es auch, moglichst zuverlassig kommunizieren zu konnen. Es
wurden 1377 Knoten bzgl. der Informationsverbreitung betrachtet. Bei den Blocken wurde
1
festgestellt, das 50% der gesendeten Blocke nach 22 Sekunden der Knoten erreicht hat. 50%
4
1
der propagierten Transaktionen brauchten hingegen ganze 17 Minuten, um bei der Peers
4
anzukommen.
Weitere Analysen der Block- und Transaktionsverbreitung sind in [Wolk14] zu finden.

Diskussion

Die beiden Paper, die in dieser Proseminar Arbeit verwendet wurden, um den Vergleich der
beiden Netzwerke Bittorrent und Bitcoin herzustellen, haben an sich nichts mit einander zu
tun. Jedoch wurde in dieser Arbeit versucht, gewisse Parallelen herzustellen bzw. wie im
Abschnitt der Geographischen Korrelation zu sehen war, zu verschmelzen.
Um einen genaueren Vergleich der beiden Netzwerke herstellen zu konnen, sind noch ein paar
Manahmen f
ur weitere Forschung m
oglich. Zum einen kann der Zusammenhang der Bitcoin
und Bittorrent Benutzer viel genauer dadurch untersucht werden, dass man tatsachlich die
IP Adressen der Knoten vergleicht und zuordnet. Damit bekommt man auch eine wesentlich
aussagekraftigere Antwort auf die sozialwissenschaftliche Frage, die im Abschnitt der Geographischen Korrelation gestellt wurde. Zum anderen hat sich aber auch das Paper [JuAH11]
lediglich mit dem Informations Lookup als Metrik beschaftigt. Doch auch die Speicherung
von Informationen, also im verteilten Netzwerk die Ausbreitung, kann eine Rolle f
ur DHT
basierende Anwendungen spielen. Damit hatte man auch eine Metrik, die sehr ahnlich zur
Transaktions- und Block Ausbreitung ist. Damit ware ein Vergleich der beiden Ausbreitungsgeschwindigkeiten m
oglich.
Es war aber auch festzustellen, dass interessanterweise die Messungen von [Joan14] genau
in der Zeit aufgenommen wurden, als der Bitcoin Wechselkurs in starkem Schwanken war.

10

Zudem zeigen die Messungen von Bitcoin Status, dass auch die Anzahl und die Landerverteilung der Knoten in diesen 37 Tagen besonders stark durchwachsen war. Hier stellt sich die
Frage, warum die Autoren von [Joan14] nicht gewartet haben, bis sich die Verteilung weiter
stabilisiert hat. Ausserdem war zu sehen, dass in [Joan14] nur taglich Messungen gemacht
wurden, die jeweils ca. 2 Stunden dauerten. Allein innerhalb dieser 2 Stunden kann sich das
Netzwerk stark ver
andert haben. Auch wenn man im Bitcoin Netzwerk nicht einfach den
ID Space aufteilen kann, um eine Stichprobe vom Netzwerk nehmen zu konnen, sollte ein
Ansatz gew
ahlt werden, mit dem man die Messung schneller durchf
uhren kann. Dann ist es
auch moglich, viel genauere Messungen durchzuf
uhren, mit denen man zB. die Churn Rate
feststellen k
onnte. Die Aussagekraft der Messungen aus [Joan14] kann auch durch die Art der
Messungen angezweifelt werden, worauf in [Wolk14] genauer eingegangen wird.
Ein Punkt, auf den in [JuAH11] nicht genauer eingegangen wird, ist die Aufteilung des ID
Space in eine Gr
oe von 2152 bit. Hier stellt sich die Frage, ob nur alle IDs ber
ucksichtigt
werden, f
ur die gilt: ID 2152 , oder ob diese 2152 IDs mit einem Padding u
ber den ID Space
verteilt sind. Wenn tats
achlich die Relation als Ma gewahlt wird, konnte es Clients geben,
die bewusst einen h
oheres Intervall vom ID Space wahlen, um nicht gefunden zu werden.
Um zu u
ufen, ob die Lokalit
at der Messung eine Rolle spielt, haben die Forscher von
berpr
[JuAH11] auch die gleichen Messungen von der DePaul Universitat mit einem PlanetLab
Knoten durchgef
uhrt. Hier wurden keine Unterschiede festgestellt. Eine solche zweite Version
der Messung k
onnte man auch mit Variationen des ID Space machen, um sicherstellen zu
konnen, dass dieser keine Auswirkungen auf die Messungen hat.

Schlussbetrachtungen

In dieser Proseminar Arbeit wurden das Bittorrent Mainline DHT mit dem Bitcoin Netzwerk verglichen. Wir haben gesehen, dass beide Netzwerke ziemlich gleichmaig u
ber den
Globus verteilt sind, wobei im DHT Netzwerk Europa und im Bitcoin Netzwerk nach den
Untersuchungen aus [Joan14] China und die USA die dominierenden Regionen dieser Welt
sind. Auerdem war eine deutliche Korrelation der Landerverteilungen festzustellen. Dies
kann allerdings auch mit der Einwohnerdichte der jeweiligen Lander zusammenhangen. Um
weitere Aussagen treffen zu k
onnen, sind noch weitere Manahmen, die im Abschnitt Diskussion angesprochen wurden, n
otig. Das Fazit von [JuAH11] war, dass ein Basis DHT Service
moglich ist, jedoch noch Punkte wie die Vertrauensw
urdigkeit der Knoten beachtet werden
m
ussen. Wir haben gesehen, dass zum aktuellen Zeitpunkt zwar schon einige Forschung zu
DHTs existiert, im Bitcoin Bereich jedoch noch viel Potential besteht. Bis jetzt wurden DHTs
hauptsachlich aus akademischer Motivation betrachtet, doch auch immer mehr 3rd Party Applikationen werden entwickelt. Besonders interessant sind auch die Projekte, die durch das
Zusammenwirken der Prinzipien beider Netzwerke entstehen. Dazu gehoren zB. Twister, eine
Peer-to-Peer Micro Blogging Platform, Gitchain, welches eine verteilte Alternative zu Github
darstellt und als Basis das Filesharing sowie Challenges wie im Bitcoin Netzwerk benutzt, um
Git Repositories zu signieren. Aber auch in dem Projekt Filecoin stecken beide Technologien,
dort sind auch Coins erwerbbar, jedoch wird Starke bzw. Stimmkraft nicht mit Rechenkraft,
sondern mit Speicherplatz bemessen. Die in dieser Arbeit betrachteten Projekte zeigen, dass
die Zukunft noch viele M
oglichkeiten bietet und Projekte dieser Art schnell eine Groe von
vielen Millionen Benutzern erreichen konnen.

11

Literatur
[bit]

RowIT - Bitcoin Peer to Peer Network Status.

http://bitcoinstatus.rowit.co.uk/. Accessed: 2014-07-27.

[dhta]

Analyzing the geographical distribution of dht peers with Node.JS.

https://github.com/timsuchanek/dht-analyzer. Accessed: 2014-07-27.

[dhtb]

DHT bootstrap server. https://github.com/bittorrent/bootstrap-dht/.

Accessed: 2014-07-27.

[Galt]

Francis Galton. Co-relations and their measurement, chiefly from anthropometric

data. http:
//galton.org/essays/1880-1889/galton-1888-co-relations-rsoc.pdf.
Accessed: 2014-07-27.

[Joan14] Joan Antoni Donet Donet Cristina Perez Sola Jordie Herrera Joancomart (Hrsg.).
The Bitcoin P2P network. White paper, Dept. d Enginyeria de la Informacio i les
Comunicacions, Universitat Autonoma de Barcelona, 2014.
[JuAH11] K. Junemann, P. Andelfinger und H. Hartenstein. Towards a Basic DHT Service:
Analyzing Network Characteristics of a Widely Deployed DHT. In Computer
Communications and Networks (ICCCN), 2011 Proceedings of 20th International
Conference on, July 2011, S. 17.
[Lim05]

E. K. Lua J. Crowcroft M. Pias R. Sharma S. Lim. A Survey and Comparison of

Peer-to-Peer Overlay Network Schemes, S. 7293. 2005.

[pir]

The pirate bay. http://thepiratebay.se/. Accessed: 2014-07-27.

[StRe06] D. Stutzbach und R. Rejaie. Improving Lookup Performance Over a

Widely-Deployed DHT. In INFOCOM 2006. 25th IEEE International Conference
on Computer Communications. Proceedings, April 2006, S. 112.
[Wolk14] Eva Wolkwitz (Hrsg.). Proseminar Bitcoins: Netzwerkmessung. Proseminar,
Karlsruher Institut fuer Technologie, 2014.
[Yu05]

S. Rhea B. Godfrey B. Karp J. Kubiatowicz S. Ratnasamy S. Shenker I. Stoica H.

Yu. OpenDHT: a Public DHT Service and its Uses, S. 7384. SIGCOMM. 2005.

12