Der Bitcoin Core Full Client gilt nach wie vor als der Bitcoin Client schlechthin. Die Software ist Wallet sowie Full Node in einem. Nutzer verifizieren die gesamte Blockchain und stellen die Einhaltung der Konsensregeln sicher.
Bitcoin Core Version 0.19.0 ist das 19. große Update der ursprünglichen Nakamoto-Software. Die wichtigsten Updates im Überblick – von Bech32 bis Bloom-Filter.
Bech32 als Default
Bech32-Adressen gibt es schon seit Längerem. Genauer gesagt existiert das neue Adressformat seit 2016. Damals fand BIP 173 offiziellen Anklang im Bitcoin Core Update 0.16.0.
Neu ist aber, dass Bech32-Adressen von nun an standardmäßig im Client aktiviert sind. Musste man vorher noch vom alten P2SH-Format umschalten, werden Invoices für eingehende Transaktionen ab sofort automatisch im Bech32-Format erstellt.
Bech32-Adressen beginnen mit einem „bc“ anstatt der üblichen 1 oder 3. Sie sind zwar um 15 Prozent länger, aber dafür einfacher für Menschen zu lesen. Dies soll in erster Linie das Risiko vermindern, durch Eingabefehler BTC Funds zu verlieren. Zudem spielt es bei Bech32 keine Rolle mehr, ob Zeichen groß oder klein geschrieben werden – dadurch eliminieren die Entwickler eine weitere Fehlerquelle.
Das GUI [Graphical User Interface, graphische Nutzeroberfläche] stellt Bech32-Adressen ab sofort als Standard zur Verfügung. Nutzer können den Adresstyp aber mithilfe eines Buttons ändern,
heißt es in den offiziellen Release Notes.
Bloom Filter zunächst abgesagt
Unter Light Clients versteht man einen bestimmten Wallet-Typen, der im Gegensatz zu Full Nodes wie Bitcoin Core nicht die gesamte Blockchain herunterladen. Aufgrund der besseren Dateneffizienz kommen Light Clients daher vor allem bei Mobile Wallets zum Einsatz. Da Light Clients nicht alle Transaktionen verifizieren, sondern nur die Block Header herunterladen, sind sie zwar schlanker, aber auch unsicherer. Gleichzeitig sind Lightweight Nodes von Full Nodes abhängig, da sie gewisse Daten abrufen müssen.
Und hier kommen Bloom Filter ins Spiel. Bloom Filter sind eine Methode, um an Transaktionsdaten von Full Nodes zu kommen. Denn mithilfe von Bloom Filtern fragen Light Clients Daten an, die sie benötigen (etwa bestimmte Transaktionsdaten), und übertragen diese auf den Light Client.
Allerdings bergen Bloom Filter ihre ganz eigenen Tücken. So gelten die Filter, die bereits seit BIP 37 Teil von Bitcoin Core sind, als Angriffsfläche für Denial of Service Attacks (DoS). Denn häufig rauben Bloom-Anfragen Full Nodes wichtige Rechenkapazitäten sowie Speicherplatz auf der Festplatte. Angreifer könnten sich dies zunutze machen und Full Nodes unter Beschuss nehmen.
Die Konfiguration für Bloom Filter ist im Update entsprechend erstmals standardmäßig ausgeschaltet. Nutzer können NODE_BLOOM aber nach wie vor eigenhändig einschalten und etwa eine Whitelist an vertrauenswürdigen Lightweight Clients für Bloom-Anfragen freischalten.
Lösung: Compact Block Filters für Light Clients
Wie beschrieben hängen Lightweight Clients am Tropf von Full Nodes. Bloom Filter ersatzlos abzuschalten erscheint daher nicht wirklich gangbar. Dies haben die findigen Bitcoin Core Developer selbstredend auf dem Schirm und den Support für sogenannte Compact Filter auf Block-Daten verbessert.
In der Beschreibung des dazugehörigen BIP 158 ist explizit die Rede von einer Ersatzimplementierung, die als Ablöse von Bloom Filtern fungieren soll. BIP 158 ist so konstruiert, dass die Größe der von Light Clients angefragten Daten möglichst gering ist. So kann das Risiko von DoS-Attacken, die von Lightweight Clients ausgehen, vermindert werden.
Im Prinzip funktionieren Compact Block Filter wie Bloom Filter, nur umgekehrt. Anstatt dass die Light Node Daten der Full Node abfragt, bauen die Full Nodes Filter, die sie an Light Clients senden.
Mit dem Befehl „getblockfilter“ können Nutzer die im BIP 158 beschriebenen Filter anfragen und als sogenannten RPC (Remote Procedure Call) verfügbar machen.
Two-Block-Outbound-Verbindungen standardmäßig eingeschaltet
Partitioning Attacks zielen darauf ab, ehrliche Nodes von Peer-to-Peer-Netzwerken wie Bitcoin abzutrennen und somit effektiv zwei Netzwerke zu erzeugen. Zwischen den unterschiedlichen Teilen des Netzwerks können sodann keine Informationen ausgetauscht werden. Angreifer könnten dem abgetrennten Teil des P2P-Netzwerks etwa eine „falsche“ Blockchain unterjubeln und so Double Spends durchführen. Obgleich für eine Partitioning Attack eine große Anzahl angreifender Netzwerkknoten notwenig ist, ist sie nicht auszuschließen.
Die Attacke ist jedoch unwirksam, sobald auch nur eine Verbindung zum abgetrennten Teil der Blockchain existiert. Denn dann können Blockchain-Informationen zwischen allen Teilen des Netzwerks ausgeschaut werden und alle Nodes erkennen, welche Chain die tatsächlich gültige ist.
Genau dies soll eine neue Implementierung im Bitcoin Core Client 0.19.0 sicherstellen. Denn anstatt bisher an eine Node, leiten Bitcoin Core 0.19.0 Full Nodes Blöcke ab sofort an zwei Nodes weiter.
Diese Verbindungen sind so konzipiert, dass sie wenig zusätzlichen Speicher- oder Bandbreitenressourcenbedarf verursachen, sollten aber Partitioning Attacks erschweren,
heißt es im Release Update.
