LOT: Die letzte Hürde der Taproot Aktivierung

Dass Bitcoin mit "Taproot" ein großes Update bevorsteht, welches wortwörtlich die Wurzel des Protokolls, nämlich u.a. das Signaturschema verändert, wurde an vielen Stellen in den vergangen Wochen mehrmals thematisiert.

Mit dem Taproot-Update sollen neben den sogenannten Schnorr-Signaturen aber auch einige weitere Verbesserungen in das Bitcoin Netzwerk gebracht werden, die vor allem die Flexibilität und Privatsphäre von Bitcointransaktionen erhöhen sollen.

Von der Idee zur Integration

Das letzte große Bitcoin-Update war der "Segregated Witness" (SegWit) Softfork im Sommer 2017, welcher im Zuge des Aktivierungsprozesses hitzig diskutiert wurde und wahrlich ein Drama war. Damals konnten sich einige Teile der Miner und Teile der Fullnode Betreiber nicht über die Einführung von SegWit einigen. Dies führte dazu, dass die Fullnodebetreiber drohten, unter Anwendung eines sogenannten User Activated Soft Forks (UASF) das Update dennoch zu installieren. Da dies für die Miner große Verluste zur Folge hätte haben können, wurden sie von der Community also regelrecht unter Druck gesetzt das SegWit-Update ebenfalls zu aktivieren. Schlussendlich kam es dann aber nicht zum UASF, da die Miner sich dazu durchrangen das Update doch zu installieren.

Knapp ein halbes Jahr später, im Januar 2018 wurde vom ehemaligen Blockstream CTO und Bitcoin Core Entwickler Gregory Maxwell das Update mit dem Namen "Taproot: Privacy preserving switchable scripting" vorgeschlagen. Seitdem wurde dieses sehr ausgiebig überprüft und diskutiert, sodass es schließlich seinen Weg in die neuste Version von Bitcoin Core fand, der aktuellen Referenzimplementierung für das Bitcoin-Protokoll.

Wie updatet man ein dezentrales Netzwerk?

Der Tisch ist also gedeckt und das Update steht in den Startlöchern. Was jedoch noch aussteht ist dessen Aktivierung im Bitcoin Netzwerk. Und genau hierüber wurde (und wird noch immer) besonders in den letzten Wochen recht ausgiebig diskutiert.

Regeländerungen im Netzwerk bergen immer ein Risiko, da die Netzwerkteilnehmer (Fullnodes) nach diesen Regeln entscheiden, ob ein Block als gültig erachtet wird oder nicht. Sollte ein Teil des Netzwerks auf die neuere Softwareversion umsteigen, die nach anderen Regeln funktioniert als die alte, könnte es im schlimmsten Fall dazu führen, dass das Netzwerk auseinanderbricht. Dies macht Updates in einem dezentralen System wie Bitcoin zu einer echten Herausforderung. Das Risiko kann durch sogenannte Softfork-Updates jedoch etwas gemildert werden, da diese rückwärtskompatibel zu den vorherigen Versionen sind. Solange eine Mehrheit der Miner (mindestens 50% der Hashpower) die neuen Regeln durchsetzt, akzeptieren alle Fullnodes die Blöcke als gültig. Einerseits aktualisierte Fullnodes, weil die neuen Regeln ordnungsgemäß durchgesetzt werden und andererseits Fullnodes auf denen die alte Softwareversion läuft, weil keine der alten Regeln gebrochen wird.

Neben den Fullnodes sind also auch die Miner ein wichtiger Faktor bei der Durchführung derartiger Updates, denn wenn die Mehrheit der Fullnodes das Update zwar aktiviert, ein Großteil der Hashpower jedoch auf der alten Version verbleibt und die neuen Regeln nicht durchsetzt, dann büßt das Netzwerk einen großen Teil seiner Sicherheit ein.

Aus diesem Grund wurde sich bei früheren Softforks am Bitcoin Improvement Proposal 9 (BIP9) bedient und an den Minern orientiert, um die Änderungen in das Netzwerk zu bringen bzw. die Updates zu koordinieren. In der Regel wird darauf gewartet, dass die Miner in ihren neu geschaffenen Blöcken ihre Bereitschaft signalisieren. Sobald mehr als (i.d.R.) 95% der neu geminten Blöcke dieses Signal enthalten, beginnen die Fullnodes damit, die neuen Regeln durchzusetzen. Sollte dies innerhalb einer festgelegten Periode (laut BIP9 soll diese ein Jahr betragen) nicht geschehen, würde das Update stattdessen verfallen.

Bei Taproot läuft es etwas anders

Für den Prozess der Aktivierung des Taproot-Updates wird sich nicht am BIP9, sondern am BIP8 bedient. Dieses funktioniert zwar grundsätzlich relativ identisch, enthält jedoch einen Parameter über den derzeit stark diskutiert wird, nämlich das sogenannte "lockinontimeout" (LOT).

Dieser Parameter kann zwei Werte annehmen, entweder LOT=true oder LOT=false. In beiden Fällen haben die Miner ein Jahr Zeit, Taproot durch die Signalisierung in den Blöcken zu aktivieren. Wenn innerhalb dieses Jahres 90% der Hashpower (1815 von 2016 Blöcken pro Periode) die Unterstützung für das Update signalisieren, werden die Fullnodes beginnen, die neuen Regeln durchzusetzen. In diesem Fall wäre es also egal, welcher Wert LOT zugeschrieben wurde. Relevant wird lockinontimeout erst für den Fall, dass die Miner nach Ablauf eines Jahres die Aktivierung nicht signalisiert haben.

Wo sind die Unterschiede zwischen LOT = true & LOT = false?

Ausgehend von der Prämisse, dass während der Aktivierungsperiode nicht mindestens 90% der Blöcke das entsprechende Signal enthielten, wollen wir uns zunächst den Fall LOT=false ansehen. Würde die Aktivierungsperiode ablaufen und der lockinontimeout wäre auf false gesetzt, würde Taproot schlicht und einfach nicht aktiviert werden und verfallen. Das Bitcoin-Protokoll würde dann ohne das Update weiterlaufen wie bisher. Anschließend könnte man sich darüber Gedanken machen, ob man einen neuen Versuch startet. Diesmal dann natürlich mit LOT=true. Es sollte jedoch abgewogen werden warum die Miner nicht aktiviert haben und ob es Sinn macht, dass man sie mehr oder minder dazu zwingen sollte.

Damit kommen wir zum Fall LOT=true. Diese Option führt nämlich dazu, dass das Ende der Aktivierungsperiode keine Art Verfallsdatum ist, sondern eher eine Deadline für die Miner. Wie bei einem UASF würden die Fullnodes in den letzten Wochen vor Ende der Aktivierungsperiode damit beginnen Blöcke, die keine Bereitschaft für Taproot signalisieren, als ungültig zu betrachten und abzulehnen. Durch diese Maßnahme würde das Update demnach forciert werden, da auf diese Weise zwangsläufig der Schwellenwert von 90% erreicht werden würde. Voraussetzung dafür ist natürlich, dass es überhaupt Blöcke gibt, die das Signal zur Aktivierung enthalten. Davon ist nach aktuellem Stand jedoch auszugehen.

Wie ist das bisherige Sentiment?

Um zu überprüfen und zusammenzufassen wie denn so die allgemeine Stimmungslage bei den Minern bezüglich des Taproot Updates überhaupt ist, wurde die Webseite taprootactivation.com ins Leben gerufen. Auf dieser ist dargestellt, ob und welche Miner bereits ein Statement zum anstehenden Update abgegeben haben. Die untenstehende Liste zeigt, dass zum Zeitpunkt der Erstellung dieses Artikels schon Miner mit knapp 90% der Hashrate öffentlich ihre Unterstützung für Taproot bekannt gegeben haben. Über den Parameter für das lockinontimeout haben sich bisher leider erst wenige Miner geäußert. Im Grunde ist jedoch davon auszugehen, dass eine Mehrheit der Miner für "LOT=false" stimmen würde.

Twitter Post

Neben den Minern gibt es natürlich auch noch andere wichtige Interessensgruppen, deren Meinung man einholen sollte. Die Meinung der Fullnode-Betreiber ist leider kaum messbar, da man nicht wissen kann, ob nur diejenigen laut schreien (z.B. bei Twitter), die für oder gegen die Aktivierung sind. Auch dies sollte in der Debatte um LOT=true vs. LOT=false beachtet werden. Mitte Februar gab es ein Entwickler-Meeting bei dem sich zum Thema Taproot-Aktivierung ausgetauscht wurde. In einer Liste wurde festgehalten, wie bei den Anwesenden die Stimmungslage bzgl. der Optionen LOT=true bzw. false ausfällt:

Nickname	LOT=true	LOT=false
belcher	X	X
benthecarman	X	X
waxwing	X	X
hsjoberg	X
fjahr		X
devrandom	X	X
darosior		X
andrewtoth		X
luke-jr	X
enzy	X	X
viaj3ro	X	X
achow101		X
virtu		X
proofofkeags	X	X
nickler	X	X
satosaurian	X
eeb77f7f26eee	X
gg34	X	X
harding		X
jonatack		X
pox	X	X
Billy	X	X
evankaloudis	X	X
virtu		X
criley	X	X
prayank	X
debit		X
Murch		X
ghost43		X
roasbeef		X
elichai2	X	X
TOTALS	19	26

Welche Argumente sprechen für true/false?

LOT=false

Wie bereits weiter oben im Text erwähnt, sollte es gut überlegt sein, ob man die Aktivierung erzwingt, obwohl es anscheinend Kontroversen gibt. Für LOT=false spräche also, dass die Verwendung von lockinontimeout gar nicht nötig wäre, wenn es bei der Aktivierung sowieso kaum Meinungsverschiedenheiten gibt. Und die obenstehende Tabelle von taprootactivation.com lässt dies zumindest vermuten.

Darüber hinaus ähnelt LOT=false mehr den früheren Aktivierungsmechaniken, die mit der kleinen Ausnahme von SegWit bisher auch recht reibungslos funktioniert hatten.

Die Befürworter von LOT=false argumentieren außerdem, dass die Miner ohnehin keine Chance hätten die Taproot Aktivierung zu blockieren, falls die Mehrheit der Fullnodes dafür wäre. Die User könnten nichtsdestotrotz auf LOT=true Clients updaten und dies auch schon vor Ablauf der Aktivierungsperiode, falls sich abzeichnen sollte, dass der Schwellenwert von 90% nicht erreicht wird. Notfalls könnte, wie bereits erläutert, außerdem einfach ein neuer Aktivierungszeitraum geplant werden.

Ein wichtiger Punkt für viele LOT=false-Verfechter ist außerdem die Option, einfacher auf möglicherweise auftretende Probleme mit Taproot zu reagieren. Sollte der (zugegebenermaßen sehr unwahrscheinliche) Fall eintreten und ein Fehler würde entdeckt, könnte man die Frist einfach verstreichen lassen, ohne dass alle Nodes ein weiteres mal ihre Software updaten müssten.

Für LOT=false spricht auch, dass man nicht den Anschein erwecken sollte, dass die Bitcoin Core Entwickler die Macht haben, eigenständig Veränderungen im Bitcoin Protokoll zu forcieren. Da LOT=true die Taproot-Aktivierung garantieren würde, würde ihr Code diese Änderung der Protokollregeln "erzwingen". Diese Wahrnehmung könnte unerwünschte Aufmerksamkeit auf die Rolle der Entwickler im Bitcoin Ökosystem lenken. Ein "ihr macht was wir sagen" darf und wird es bei Bitcoin nicht geben.

LOT=true

Für lockinontimeout spricht laut der Befürworter, dass Taproot bereits mehr als ausreichend geprüft sei, Fehler unwahrscheinlich sind und auf diese Weise die Anreize am besten ausgerichtet wären, um sicherzustellen, dass die Miner tatsächlich das Update aktivieren. Man könne sich bei so einem wichtigen Schritt nicht einfach auf Absichtserklärungen verlassen.

Außerdem argumentieren einige, dass man den Minern diese Art von Veto nicht gewähren sollte. Man hört bzw. liest in Diskussionen Aussagen wie "Miner sind Dienstleister, die dafür bezahlt werden Transaktionen in die Blockchain zu schreiben. Sie sind da, um zu lenken und nicht, um zu denken." Tatsächlich wäre es äußerst ärgerlich, wenn trotz breitem Konsens für die Aktivierung, eine kleine Minderheit das Update scheitern lassen könnten (z.B. weil sie sich einfach nicht die Mühe machen ihre Software zu aktualisieren, weil ihnen so oder so kein Nachteil dadurch entstünde). Mit LOT=true würden es sich die Miner nicht leisten können, die Änderung zu ignorieren und werden gezwungen sein, aktiv zu handeln, wie es die User verlangen. Würden sie sich dennoch dagegen stellen, würden schließlich ihre Blöcke als ungültig abgelehnt und sie damit eine Menge Hashpower bzw. Geld verschwenden.

LOT=true wäre quasi der direkte und somit schnellste Weg, um das von vielen ersehnte Taproot-Update nach jahrelanger Debatte nutzbar zu machen.

Welche Gefahren gibt es?

Wie eingangs erwähnt, bergen derlei Updates immer auch Gefahren für das Netzwerk, vor allem für den Fall, dass keine Einigkeit über gewisse Vorgehensweisen etc. herrscht. In diesem Fall könnte es zu gewissen Szenarien kommen, die das Netzwerk instabil werden lassen und gar eine Aufspaltung zur Folge hätten. Wenn z.B. weniger als die Hälfte aller Miner LOT=true verwenden und die Signalisierungsperiode abläuft, könnte sich die Bitcoin-Blockchain zwischen LOT=true und LOT=false Nodes "aufspalten". LOT=true Fullnodes würden nur signalisierende Blöcke akzeptieren, auch wenn die Blöcke ohne das Aktivierungssignal die eigentlich längere Blockchain bilden. Sie würden im Wesentlichen auf ihrer eigenen "LOT=true chain" weiterarbeiten. LOT=false-Nodes hingegen würden die LOT-true-Kette zugunsten der längeren LOT=false-Kette ablehnen, da eine der Grundregeln im Bitcoin Netzwerk schließlich lautet: "Die längste/schwerste Kette gewinnt!"

Ähnlich wie beim Chainfork von Bitcoin und Bcash im Sommer 2017 könnte es dazu kommen, dass es zu zwei Ketten mit eigener Transaktionshistorie und eigenen Coins kommt. Da es jedoch irgendwann dazu kommen könnte, dass die LOT=true-Kette länger wird als die false-Kette und dann alle Coins und Transaktionen auf der false-Kette gelöscht würden (schließlich gewinnt ja die längere Kette), weil die LOT=false-Nodes im Gegensatz zu den true-Nodes die andere Seite ebenfalls als gültig anerkennen würden. Ebenso erginge es den Fullnodes, die, aus welchen Gründen auch immer, überhaupt nicht am Update teilgenommen haben und noch immer eine alte Softwareversion laufen lassen. Auch diese User würden in diesem Fall viel Geld verlieren, weswegen dieses Szenario unbedingt vermieden werden sollte.

Die Befürworter von LOT=true sind deswegen der Meinung, dass der beste Weg, solchen Schaden zu vermeiden, darin besteht, LOT=true in einer Bitcoin Core Version direkt einzusetzen. Sie glauben, dass ein Teil der Nutzer einen LOT=true-Client benutzen wird, auch wenn er nicht in Bitcoin Core enthalten ist. Und obwohl dies eine kleine Gruppe sein mag, könnte sie groß genug sein, um eine Kettenspaltung zu verursachen und das wäre nun wirklich der Super-GAU.

Da Bitcoin Core die Referenzimplementierung des Bitcoin Protokolls und somit auch mit Abstand am weitesten verbreitet ist, würde ein Beinhalten von LOT=true in der neuen Bitcoin Core Version wahrscheinlich dafür sorgen, dass die ökonomische Mehrheit des Netzwerks LOT=true verwendet. Auf diese Weise wäre sichergestellt, dass die Miner auf jeden Fall auf Taproot updaten würden, da sie sonst Gefahr laufen würden in oben genanntes Szenario zu geraten.

Beide Seiten also sowohl Befürworter von LOT=true als auch die Gegenseite beanspruchen für sich die Tatsache, dass ihre präferierte Lösung die potenziell weniger riskante sei.

Bitcoin Governance

Die Debatte rund um Taproot und lockinontimeout ist ein wunderbares Beispiel für die dezentrale Governance, die Verwaltung, des Bitcoin Netzwerks. Es gibt nicht wie bei andern Projekten eine zentrale Person, Firma, Stiftung oder Partei, die Regeländerungen mehr oder minder alleine bestimmen kann. Das Bitcoin Ökosystem ist ein Zusammenspiel aus vielen einzelnen Interessensgruppen und Entitäten.

Die Developer können zwar Software bereitstellen, jeder Fullnode-Betreiber und auch jeder Miner entscheidet jedoch selbst nach welchen Regeln gehandelt werden soll. Dies ist es, was Bitcoin in seiner Weiterentwicklung zwar langsam, aber dafür unglaublich mächtig und sicher macht.

Shoutout an die Fullnode-Betreiber

Gerade in solchen Zeiten ist es besonders wichtig, dass ihr euch damit auseinandersetzt, was hier geschieht und welche Optionen man hat. Eine Fullnode zu betreiben bedeutet ein Teil des Bitcoin-Netzwerks zu sein und somit auch einen Teil der Verantwortung zu tragen. Versucht dieser Verantwortung gerecht zu werden und befasst euch mit der Thematik ruhig etwas näher. Denn "wir sind alle Satoshi"! :-)

Abstimmung

Hier kannst du abstimmen, welche Option du als geeigneter empfindest:

Twitter Post