Bitcoin-Miner leiten Taproot-Aktivierung ein
Die Wurzel eines Baumes. Bild von Wolfgang via flickr.com. Lizenz: Creative Commons
Eine Supermehrheit der Miner hat Taproot, das erste große Bitcoin-Upgrade seit SegWit, akzeptiert. Damit steht der Aktivierung nichts mehr im Wege.
Das Taproot-Upgrade kann man auch als Lektion dafür verstehen, welches Tempo Bitcoin-Upgrades haben müssen. Anfang 2018 hat Gregory Maxwell Taproot vorgeschlagen. Seitdem wurde das Update entwickelt, poliert und getestet, und, vor allem: es wurde nach einem Weg gesucht, es möglichst undisruptiv zu aktivieren.
Nach langen Diskussionen und Abstimmungen durch die Miner entschieden sich die Entwickler für die „Speedy Trial“ Variante von BIP8, des klassischen Mechanismus, durch den Softforks bisher aktiviert wurden. Mit Speedy Trial können die Miner drei Monate lang signalisieren, ob sie bereit für eine Softfork sind oder nicht. Sobald über einen Zeitraum von etwa zwei Wochen 90 Prozent der Blöcke ein „Ja“ enthalten, wird das Upgrade eingelockt.
Dies geschah am vergangenen Wochenende. Damit ist der Weg für Taproot frei. Bis zur Aktivierung wird allerdings noch etwas Zeit vergehen. Erst etwa sechs Monate nach dem „Lock in“, rund 24.000 Blöcke, wird Taproot im Bitcoin-Netzwerk live gehen. Dies wird vorausichtlich Ende November bis Mitte Dezember geschehen.
Mit der neuen Methode, Softforks zu aktivieren, wollen die Entwickler Erfahrungen umsetzen, die sie mit vorhergegangenen Softforks gemacht hat. Die sechsmonatige Verzögerung der Aktivierung soll dem Ökosystem Gelegenheit geben, die Software zu aktualisieren, um bereit zu sein, wenn es soweit ist. So sollen potenzielle Risiken von Verlusten, etwa durch Verwechslungen oder falsche Adressen, vermieden werden.
Taproot selbst ist so umfangreich wie komplex. Das Upgrade führt drei neue Features ein:
MAST (Merkelized Abstract Syntax Tree) wird Hashbäume (Merkle-Trees) nutzen, um die Bedingungen, nach denen ein Smart Contract erfüllt ist, in einem Baum von Hashes zu verbergen. Bisher haben Transaktionen, die Coins in einem Smart Contract ausgeben, sämtliche Bedingungen enthüllt, durch die dies möglich ist. Mit MAST verrät die Transaktion nur noch die Bedingungen, die auch erfüllt wurde. Alternative Bedingungen bleiben im Dunklen. Dies könnte es etwa schwieriger machen, Lightning-Transaktionen zu erkennen.
Darüber hinaus führt Taproot Schnorr-Signaturen ein. Diese sind ein seit langem gepflegter Wunsch der Core-Entwickler, den sich die Bitcoin-Cash-Community erfolgreich schon seit einiger Zeit erfüllt hat. Schnorr-Signaturen sind nativ multisig-fähig, wodurch sich die Unterschiede zwischen normalen und multisig-Adressen auflösen. Es wird etwa nicht mehr ohne weiteres zu unterscheiden sein, ob eine Adresse Teil eines Lightning-Channels ist oder nicht. Dies soll auch die Fungibilität von Bitcoins und damit die Privatsphäre stärken.
Daneben reduziert Schnorr die Größe von Transaktionen geringfügig, je nach Art um etwa 20 Prozent. Dies wird die Skalierbarkeit von Bitcoin verbessern, den Durchsatz erhöhen und potenziell die Gebühren senken.
Schließlich führt Taproot Tapscript ein, eine Modifizierung der bisherige Programmiersprache, um Skripte für Smart Contracts zu schreiben. Diese soll einerseits die Skriptsprache an MAST und Schnorr anpassen, und andererseits die Entwicklung von Smart Contracts verbessern.
Überhaupt hofft die Community sehr darauf, dass Taproot Smart Contracts auf Bitcoin beflügelt. Welche Macht Smart Contracts entfalten können, zeigt Ethereum, wo sie eine mittlerweile längst nicht mehr überschaubare Vielzahl dezentraler Anwendungen (dapps) ermöglichen. Ob Bitcoin hier durch Taproot wirklich Boden gewinnen kann, ist sehr fraglich, da die grundsätzlichen Unterschiede der Skripte in Bitcoin und Ethereum weiterhin bestehen bleiben.
Im Kern wird Taproot vielmehr die Privatsphäre von bestimmten eher nischenhaften Anwendungen eher geringfügig verbessern: So wird man nicht länger erkennen können, ob ein Smart Contract, den jemand durch mehrere Signaturen einlöst, auch erfüllt gewesen wäre, wenn eine bestimmte Anzahl Blöcke verstrichen wäre. Dies klingt nach einem Detail, kann aber potenziell Lightning-Transaktionen verschleiern.
Zunächst aber wird die Fungibilität von Bitcoin-Transaktionen durch Taproot abnehmen, da es ein weiteres Format gibt, durch welches sich Adressen und Coins unterscheiden lassen. Wenn die Bitcoin-User breitflächig auf Taproot umsteigen, wird dies jedoch zu einer Verbesserung der Fungibilität umschwenken, da sich dann die Unterscheidung zwischen den einfachen P2PKH-Adressen („1…“) und P2SH-Adressen („3…“) auflösen wird.
Auch die Erhöhung der Skalierbarkeit wird aufs Ganze gesehen erst bei weitreichender Nutzung von Schnorr einen spürbaren Effekt haben. Allerdings werden Schnorr-Signaturen schon zuvor Usern und Börsen die Chance geben, die Gebühren bei Bedarf zumindest ein Stückchen zu senken.
Insgesamt sollte man sich nicht zu viel von Taproot versprechen. Doch das Upgrade verbessert mehrere Bereiche der technischen Kerninfrastruktur – vor allem die Einführung eines neuen Signaturalgorithmus ist ein großer Sprung – und zeigt, dass Bitcoin auch im Jahr 2021 noch verändert werden kann. Die Aktivierung und die ihr vorhergegangene Diskussion zeigt schließlich, wie sorgfältig und in welch langsamem Tempo dies jedoch geschieht.
Erschreckend langsam die Entwicklungszeiträume. Ob sich da Bitcoin nicht selbst mittelfristig ins aus katapultiert.
Im Gegenteil, für etwas das Trilliarden Dollar an Wert speichern können muss kann mir die Entwicklung gar nicht sorgfältig, ruhig und ohne Eile genug durchgeführt werden.
Tolles Upgrade, gute Zusammenarbeit in der Community. WELCOME SCHNORR
Auch wenn ich Taproot spannend finde und Schnorr überfällig, fällt meine Freude gedämpft aus, auch weil es erst irgendwann Ende des Jahres aktiviert wird. Vereinfachung von Atomic Swaps zwischen Bitcoin und Monero (und vielen anderen Coins) sind nur ein Argument für Schnorr, welches für Bitcoin Maxis keines ist, da alles andere ja Shitcoins sind…
@Je
Leider wahr, es ist frustrierend insbesondere für Entwickler, die etwas beitragen wollen, wenn sie eh gefühlt zu 90% auf Spott durch andere Core Entwickler stoßen und wenn doch etwas Interesse findet, muss man jahrelang dafür kämpfen, damit es tatsächlich irgendwann aufgenommen wird.
@quintall
Wenn man sich die Entwicklung von Bitcoin ansieht, dann merkt man leider, dass da nicht mehr viel Positives zu machen ist. Der Status Quo ist auch die Zukunft, mit all seinen Vor- und Nachteilen. Solange Bitcoin als verlässliches Zahlungsnetzwerk nicht genutzt wird, weil es z.B. nicht kalkulierbare Fees inne hat, muss ich dem Ponzi Lager leider größtenteils Recht geben, dass der Kurs hauptsächlich darauf basiert, wie viele Menschen bzw. wie viel Kapital gerade bereit ist, nachzukommen. Und das leider aus reiner Spekulation und sehr wenig tatsächlicher Nützlichkeit.
Ich kann es mittlerweile nicht fassen, warum die Bitcoin Core Developer insbesondere nach den Blocksize Kriegen das „never Hard Fork“ Mantra weiterspinnen, auch wenn für jede kleine Optimierung ein Kopfstand und mit den Ohren klatschen benötigt werden und meist in einer Hard Fork viel effektiver implementiert werden könnten und eine solch gravierende Soft Fork praktisch die selben Probleme mitbringt…
Toll, man verhindert eine seit Ewigkeiten geplante Änderung als Hard Fork zu implementieren, auch wenn 90% der Miner zugestimmt haben (und damit ihre Systeme updaten müssen) zugunsten einer Soft Fork, die aber praktisch alle Akteure des Systems in Zugzwang sind, weil sie zwar nicht auf einer (nicht existierenden) Fork Chain landen, sondern weil sie mit den Transaktionsdaten nichts anfangen können. Gerade mit der Professionalisierung des Minings bei Bitcoin wird doch kein Miner nach Jahren Vorlaufzeit auf die Idee kommen, die Fork Chain zu minen, zumal er das bei gleich bleibender Difficulty alleine bewerkstelligen müsste. Ein paar Dussel, die das Update verpasst haben, werden höchstwahrscheinlich noch nicht einmal einen einzigen inkompatiblen Block finden. Es war schon bei SegWit der Fall, wo man einige Prozent Optimierung für die heilige Soft Fork verplempert hat und es ist scheinbar auch mit Taproot der Fall. Man sollte beachten, dass das nicht zur Sicherheit beiträgt, sondern im Gegenteil die Komplexität unnötig erhöht.
Etwas ist fungibel oder nicht, dazwischen gibts nichts. Bitcoin wird auch mit Taproot nicht fungibel, denn die öffentliche Historie jedes Satoshis läuft immer mit und bleibt für immer einzigartig.
Segwit hat ca. 50% Durchdringung, knapp 4 Jahre nach Aktivierung und das war durch die Abtrennung von Signaturen signifikanter als Schnorr für die Größe der Transaktionen. Man schleift also etliche Signaturschemen mit anstatt alte Zöpfe abzuschneiden, die Systeme zur Verifizierung der Transaktionen benötigen ja ohnehin ein Update, warum macht man dann einen Bogen um die Generierung von Transaktionen? Verschiedene Signaturschemen wirken sich übrigens negativ auf die Privatsphäre aus, denn anhand dieser zusätzlichen Metadaten kann man Transaktionen bestimmter Software zuordnen und so die potenziellen Nutzer eingrenzen. Monero macht (für manche vielleicht radikal) vor, wie es anders gehen kann. Neue optimierte Transaktionssignaturen, basieren auf Schnorr wie auch schon die Vorgänger, wurden zuletzt vor ein paar Monaten eingeführt. In einem Zeitfenster von 48 Stunden wurden alte und neue Transaktionen akzeptiert, danach von Minern verworfen. Auch das lief zwar nicht perfekt, da Clients Transaktionen im Mempool bereits als valide eingestuft haben und ein Miner hat eine solche in seinen Block aufgenommen, was bei Clients die das später validieren wollten zu Fehlern führte. Ein Hotfix war aber binnen Stunden veröffentlicht, das Netzwerk war zu keiner Zeit instabil, da alle ständig online Nodes (auch Miner) die Transaktionen bereits vor dem Block im Mempool validiert hatten. Aber eine Zeitspanne von wenigen Monaten sollte doch reichen, bis alle ihre Anwendungen anpassen (was sie ohnehin tun müssen)?
Die Eröffnung eines Lightning Channels kann bereits ziemlich sicher anhand der Lock Time erkannt werden, ein zusätzlicher Lightning Node dürfte eindeutige Zuordnung ermöglichen. Immerhin sind die Channels danach aufwändiger trackbar, denn das muss proaktiv in Real-Time geschehen. Chainanalyse Anbieter wird das eher freuen, da sie in der Regel über eine ausgebaute Infrastruktur und Vernetzung verfügen und mit der Qualität der erhobenen Daten tatsächlich Alleinstellungsmerkmale entwickeln können, im Gegensatz zur öffentlich verfügbaren Blockchain, die jeder neue Anbieter auch im Nachhinein analysieren kann.
Meine Meinung: Es geht gar nicht um das „Verschleiern“ von Transaktionen bzw. sollte es nicht gehen, es geht um grundlegende Privatsphäre, möglichst ohne Ausnahmen wie eben bei Bargeld. Warum viele Bitcoiner bei Taproot jetzt plötzlich mit besserer Privatsphäre werben, bleibt mir schleierhaft, denn die Verbesserung ist vielleicht im einstelligen Prozentbereich verankert und bringt nach wie vor keine Fungibilität. Man hat in dieser Richtung schon viel länger deutlich mächtigere Tools wie Confidential Transactions oder auch Stealth Adressen, die man aber nicht implementieren will.
Für Händler, die Bitcoin akzeptieren sind gerade Coinjoins oder auch Lightning Channels, die man eingehend akzeptiert und die mit den kürzlichen Ransomware Angriffen auf die Pipeline oder andere Infrastruktur ein Problem, denn die Behörden verfolgen alle Transaktionen, die mit diesen verbunden sind. Woher kann ich wissen, dass mein Kunde keine Coins daraus an mich verschickt hat? Analog zum Bargeld stelle ich Menschen immer wieder die Frage, ob sie wissen, ob ihr Schein in ein Drogengeschäft verwickelt war… Die Antworten reichen von „ist mir doch egal“ bis „wahrscheinlich ja“. Es ist aber anders als bei Bitcoin tatsächlich egal, denn Bargeld wurde durch den Gesetzgeber fungibel gemacht und auch ein flächendeckendes Seriennummerntracking existiert afaik nicht.
@Paul:
>> und, vor allem: es wurde nach einem Weg gesucht, es möglichst undisruptiv zu aktivieren.
> Ich kann es mittlerweile nicht fassen, warum die Bitcoin Core Developer insbesondere nach den Blocksize Kriegen das „never Hard Fork“ Mantra weiterspinnen, auch wenn für jede kleine Optimierung ein Kopfstand und mit den Ohren klatschen benötigt werden und meist in einer Hard Fork viel effektiver implementiert werden könnten und eine solch gravierende Soft Fork praktisch die selben Probleme mitbringt…
Es ging dabei wohl weniger um das Vermeiden von Hardforks, sondern um das Vermeiden von konfliktbehafteten Aktivierungstechniken wie die UASF, die ja vor allem die Miner – einem doch recht wichtigen Teil des Ökosystems – gezwungen haben, bei Segwit mitzugehen.
Also im Großen und Ganzen um einen Weg der Aktivierung, der weniger disruptiv auf die Community wirkt (sozial, nicht technisch), was bei diesem Thema scheinbar auch sehr erfolgreich war.
Der von Core maßgeblich „vorgegebene“ Konsens „never Hard Fork“ ist doch das größte Problem dabei. Ethereum oder Monero machen es seit Jahren vor, wie das doch funktionieren kann und Miner sowie alle anderen Akteure wie Börsen ziehen jeweils mit, auch wenn das mit Arbeit verbunden ist.
Bitcoin ist extrem träge geworden, wenn selbst eine nicht kontroverse Optimierung wie Schnorr / Taproot Jahre benötigt, um aktiviert zu werden. Wie sollen in Zukunft dann deutlich komplexere Dinge gelöst werden, selbst wenn man die Blocksize außen vor lässt? Lightning ist zum Beispiel ein Thema, welches nicht zu Ende gedacht wurde, denn sollte es sich vielleicht irgendwann tatsächlich durchsetzen und OnChain Transaktionen größtenteils obsolet machen, wer soll dann die Blockchain sichern, insbesondere da der Coinbase Reward gegen Null strebt? Von richtiger Privatsphäre ganz zu schweigen, denn die halte ich mittlerweile für so wahrscheinlich wie die Erhöhung der Kapazität.