Bitcoin Core 0.20.0 entrümpelt das BIP70-Payment-Protokoll endgültig
Mit der neuen Version des Bitcoin-Referenzclients werfen die Core-Entwickler das Payment-Protokoll endgültig über Bord. Dies ist ein weiterer Schritt dahin, die Node-Software abzuhärten, während Zahlungsfeatures auf höhere Schichten wie Lightning migrieren.
Vor einigen Tagen hat Bitcoin Core die Version 0.20.0 der mit himmelweitem Abstand wichtigsten Bitcoin-Implementierung veröffentlicht. Die runde Zahl markiert in der Regel einen “Major-Release”, also eine Veröffentlichung mit starken Veränderungen, während die folgenden Versionen, wie 0.20.1, eher kleine Updates mit sich bringen.
In Version 0.20.0 gehen zahlreiche Änderungen ein. Es ist kaum zählbar, wie viele Details geändert und wie viele kleine Bugs gefixt wurden. Wer tief in der Software drin steckt, wird seine Freude haben, sich durch die Details zu arbeiten. Die für die User wohl am deutlichsten spürbare Änderungen dürfte sein, dass Core ab dieser Version automatisch native Segwit-Adressen im bech32-Format generiert. Diese Adressen sparen gegenüber den bisher am häufigsten verwendeten “wrapped” Segwit-Adressen – die man daran erkennt, dass sie mit einer 3 beginnen – einige Bytes an Platz. Sie werden mittlerweile von den meisten Wallets erkannt, weshalb Core wohl den letzten Schritt gegangen ist, um sie zum Standard zu machen.
Weniger spürbar sind hingegen einige Änderungen, die Features, die bereits deaktiviert waren, endgültig entrümpeln. So war die Unterstützung des Payment Protokolls BIP70 bereits mit der letzten großen Veröffentlichung, 0.19.0, abgeschalten worden. Das Payment-Protokoll ist eine Methode, um Transaktionen nicht über das Bitcoin-Netzwerk zu versenden, sondern direkt an den Händler bzw. dessen Zahlungsdienstleister. Es erlaubt es diesem, die Gebühren selbst einzustellen und eine Transaktion im Bruchteil einer Sekunde zu erhalten. BitPay hat dieses Protokoll exzessiv eingesetzt. Bisher konnten User von Core BIP70 noch über eine Option aktivieren. Nun wird dies einen Error produzieren.
Ebenfalls endgültig entrümpelt wurde das Nachrichtensystem im Netzwerk mit BIP61. Es konnte beispielsweise genutzt werden, um anderen Nodes davor zu warnen, dass eine Transaktion oder ein Block ungültig ist. Allerdings gibt es keinen Grund, weshalb man den anderen Knoten trauen sollte, weshalb vorsichtige Entwickler es vermeiden, auf der Basis solcher Nachrichten aufzubauen. Schon seit Version 0.18.0 wurden die Nachrichten standardmäßig zurückgewiesen; nun wurde der Befehl, mit dem man sie akzeptieren kann, abgeschaltet.
Damit folgt Bitcoin Core einer Tendenz, die bereits in den letzten Veröffentlichungen deutlich wurde: Der Referenzclient wird entschlackt. Für einen kleinen Skandal sorgte die Entscheidung, in der Version 0.19.0 die Bloom Filter standardmäßig auszuschalten. Diese werden von SPV-Wallets wie dem Bitcoin Wallet für Android oder dem Breadwallet benötigt, um mit dem Bitcoin-Netzwerk zu kommunizieren. Der SPV-Entwickler Andreas Schildbach nannte es eine “desaströse Idee“, die die Wallets von mehr als 10 Millionen User entkoppeln kann. Grund für die Abschaltung der Bloom Filter waren potenzielle DoS-Angriffe auf Bitcoin-Knoten.
Die Strategie hinter diesen Änderungen ist es vermutlich, die Kerninfrastruktur von Bitcoin zu härten, während Transaktions-Innovationen auf andere Schichten wie Lightning migrieren. So bietet Lightning ein Nachrichtensystem, das BIP61 ersetzt, eine Vielzahl an Invoice-Optionen, die das Payment-Protokoll ersetzen, sowie mit Neutrino potenziell ein neues System für SPV-Wallets. Damit geht die grundsätzliche Strategie, Bitcoin zu einem “Settlement-Netzwerk” zu machen, das als Anker für höhere Transaktionsschichten dient, in die konkrete Software-Entwicklung ein.
Weil ich keinen anderen Ort weiß, versuche ich es mal hier. Ich hoffe, Ihr könnt/wollt mir helfen:
Wir betreiben einen “full node” (“bitcoind.nemox.net”) per “Bitcoin
Core” und haben diesen nun auf die neueste Version aktualisiert.
“Bitcoin Wallet” will sich aber nicht mehr damit verbinden, obwohl
“-peerbloomfilters=true” als Startparameter übergeben wird.
Habt Ihr eine Idee, was sonst noch fehlen könnte?
Entschuldigt bitte! Das hat sich erledigt. Mit „-peerbloomfilters=1“ geht’s besser. 🙂