BIP54: „Consensus Cleanup“ – Bitcoin Core will alte Schwachstellen schließen

Das BIP54 trägt den Titel „Consensus Cleanup“ und ist als Softfork-Vorschlag formuliert. Ziel ist es, wie eingangs erwähnt, mehrere bekannte Schwachstellen und technische Altlasten im Konsensregelwerk gleichzeitig zu beheben.

Es geht dabei um vier Kernbereiche:

1. Fix des sogenannten „Timewarp“-Angriffs
2. Begrenzung potenziell ausführbarer Signature-Operationen
3. Eliminierung einer Merkle-Tree-Mehrdeutigkeit
4. Bereinigung historischer Coinbase- und TXID-Sonderregeln

Alle Änderungen sind dabei aber defensiver Natur. Sie erweitern Bitcoin nicht funktional, sondern machen das System im Grunde nur robuster.

Bitcoin passt seine sogenannte „Mining-Difficulty“, also die Schwierigkeit, einen gültigen Block zu generieren, alle 2016 Blöcke an. Grundlage dafür ist die gemessene Zeitspanne zwischen dem ersten und dem letzten Block einer Periode. Diese Mechanik sorgt dafür, dass im Durchschnitt alle zehn Minuten ein Block gefunden wird, unabhängig davon, wie viel Hashrate im Netzwerk aktiv ist.

Die Konsensregeln erlauben jedoch eine gewisse Flexibilität bei den Zeitstempeln der Blöcke. Ein Block muss lediglich einen Zeitstempel besitzen, der größer ist als der Median der letzten elf Blöcke. Das schafft Spielraum. Theoretisch könnten Miner innerhalb einer Difficulty-Periode die Zeitstempel so wählen, dass die gemessene Zeit künstlich verzerrt wird. Über viele Perioden hinweg ließe sich so die Difficulty manipulieren beziehungsweise langsam absenken. Dieses (zugegebenermaßen recht unwahrscheinliche) Szenario wird als „Timewarp-Angriff“ bezeichnet.

In einem großen, global verteilten Mining-Netzwerk, wie bei Bitcoin, ist ein solcher Angriff praktisch kaum umsetzbar. Dennoch existiert er als theoretische strukturelle Schwäche im Regelwerk. BIP54 adressiert nun unter anderem diesen Punkt, indem es eine zusätzliche Konsensbedingung einführt: Innerhalb einer Difficulty-Periode darf kein Block einen Zeitstempel besitzen, der vor dem ersten Block dieser Periode liegt. Damit wird eine kumulative Zeitverschiebung schon technisch unterbunden. Die Difficulty bleibt enger an die reale Zeit gekoppelt und eine schleichende Manipulation wird damit mathematisch ausgeschlossen.

Die Änderung betrifft Miner ohnehin nicht im normalen operativen Alltag, stabilisiert aber das Fundament der Difficulty-Logik langfristig.

Ein zweiter Punkt betrifft historische Besonderheiten im Umgang mit Transaktions-IDs (TXIDs). In der Frühphase von Bitcoin war es möglich, dass zwei unterschiedliche Transaktionen dieselbe TXID besitzen, insbesondere bei den sogenannten „Coinbase-Transaktionen”, also den TX, mit denen neue Bitcoin in einem Block ausgeschüttet werden.

So kam es z. B. im Jahr 2010 dazu, dass die TXID der Coinbase-Transaktion des Blocks 91842 identisch war mit der im Block 91812 und damit zu einem Verlust von 50 BTC führte.

Um dieses Problem zu adressieren, wurde später eine Sonderregel eingeführt (bekannt als BIP30), die doppelte TXIDs in bestimmten historischen Blöcken verhindert.

Diese Sonderbehandlung ist bis heute im Konsenscode enthalten. Sie stellt zwar keine Gefahr dar, aber sie ist mehr oder weniger auch technischer Ballast. Jede Sonderregel erhöht schließlich langfristig die Komplexität des Protokolls.

BIP54 verschärft die Regeln für Coinbase-Transaktionen so, dass zukünftige TXID-Duplikate strukturell ausgeschlossen werden. Damit könnte die alte Sonderlogik perspektivisch entfallen und der Konsenscode würde konsistenter und für die Entwickler auch leichter wartbar.

Ein weiterer Bereich betrifft die Validierung von sogenannten Scripts. Bitcoin begrenzt bereits heute die Anzahl der tatsächlich ausgeführten Signaturprüfungen innerhalb eines Blocks. Dennoch gibt es Konstruktionen, bei denen sehr viele Signaturprüfungen potenziell ausführbar wären, selbst dann, wenn sie im konkreten Ausführungspfad nicht aktiviert werden.

Für einen Angreifer entsteht dabie ein asymmetrisches Szenario. Er kann Transaktionen konstruieren, die für Nodes besonders aufwendig zu analysieren sind, ohne selbst hohe Kosten zu tragen. Zwar ist auch dieser Angriffsvektor eher theoretischer Natur, doch er widerspricht dem Grundprinzip, Validierungskosten möglichst deterministisch zu halten.

BIP54 reagiert darauf, indem nicht nur ausgeführte, sondern auch potenziell ausführbare Signature-Operationen pro Transaktion begrenzt werden. Die Scripts werden statisch analysiert, und wenn eine Struktur eine definierte Obergrenze überschreiten könnte, wird sie als ungültig betrachtet. Dadurch wird die maximale Validierungszeit besser kalkulierbar. Die Gefahr, dass einzelne Transaktionen Nodes unverhältnismäßig belasten, sinkt damit deutlich.

Für normale Nutzer, Node-Betreiber und übliche Transaktionen ändert sich dadurch aber nichts. Die Anpassung betrifft primär theoretische Extremkonstruktionen.

Ein weniger bekanntes, aber technisch interessantes Detail betrifft die Struktur der sogenannten „Merkle-Trees” in Bitcoin. Um zu verstehen, worum es hier geht, muss man zuerst wissen, wie Bitcoin überprüft, ob Transaktionen wirklich in einem Block enthalten sind.

Jeder Block enthält viele Transaktionen. Damit man später beweisen kann, dass eine bestimmte Transaktion tatsächlich Teil dieses Blocks war, werden alle Transaktionen in einer Art kryptografischer Struktur („Merkle-Tree") zusammengefasst.

Man kann sich das wie einen digitalen Prüfbaum vorstellen. Jede Transaktion bekommt einen eindeutigen Fingerabdruck (Hash). Diese Fingerabdrücke werden paarweise zusammengefasst, erneut gehasht und so lange kombiniert, bis am Ende ein einziger Hash übrig bleibt. Dieser eine Wert repräsentiert alle Transaktionen im Block.

Das Problem:
In dieser Struktur wird nicht unterschieden, ob ein Hash ursprünglich von einer echten Transaktion stammt oder ob er aus der Kombination zweier anderer Hashes entstanden ist. Beides sieht technisch gleich aus.

Normalerweise ist das kein Problem. Es gibt jedoch einen sehr speziellen Sonderfall. Wenn eine Transaktion exakt 64 Byte lang ist, kann sie (vereinfacht gesagt) unter bestimmten Bedingungen so aussehen wie die Kombination zweier Hashes. Das kann theoretisch zu einer Mehrdeutigkeit führen. Besonders relevant wäre das für sogenannte Light-Wallets, die nur vereinfachte Nachweise prüfen.

Dieses Szenario ist allerdings ebenfalls extrem unwahrscheinlich. Und doch existiert es als theoretische Schwachstelle.

Die Lösung in BIP 54 ist bewusst simpel gehalten. Transaktionen mit exakt 64 Byte Länge werden künftig einfach als ungültig definiert.

Da solche Transaktionen in der Praxis faktisch nicht vorkommen, betrifft diese Regel normale Nutzer überhaupt nicht. Gleichzeitig verschwindet aber die mögliche strukturelle Mehrdeutigkeit vollständig.

Es sollte hoffentlich klar geworden sein, dass BIP54 keine ökonomischen Parameter, keine Script-Funktionalität und keine monetären Eigenschaften von Bitcoin verändert. Es erweitert das System nicht, aber es stärkt und schärft es.

Solche „Cleanup“-Vorschläge sind natürlich weniger spektakulär als neue Features, aber sie sind für die langfristige Stabilität eines dezentralen Protokolls wie Bitcoin essenziell.

Je älter ein System wird, desto wichtiger wird es auch, historische Sonderfälle zu bereinigen und theoretische Angriffsflächen präventiv zu schließen.

Ob und wann BIP54 aktiviert wird, hängt, wie immer, vom weiteren Diskurs unter Entwicklern, Minern und Node-Betreibern ab. Jede Konsensänderung, selbst eine rein defensive, wie diese, erfordert Koordination und breite Zustimmung.

Im Gegensatz zu anderen derzeit diskutierten Vorschlägen (wie z.B. BIP110) ist BIP54, technisch betrachtet, jedoch kein radikaler Eingriff, sondern eine konservative Weiterentwicklung.

Bitcoin würde dadurch zwar nicht schneller oder funktionaler – aber eben ein Stück robuster.