Ein Vorschlag, der nun unter Beiträgern zu Zcash, der auf Datenschutz ausgerichteten Kryptowährung, zirkuliert, würde den Mechanismus entfernen, der ausstehende signierte Transaktionen bei jedem Netzwerk-Upgrade (NU) ungültig macht – nachdem die jüngste Aktivierung Wallets bis zur Auslieferung neuer Releases oder Firmware am Ausgeben gehindert hatte.

Eine neue Beschwerde mit einem neuen Beispiel

In einem Forumsbeitrag vom 9. November führte der Entwickler ValarDragon die Entfernung von Konsens-Branch-ID-Updates unter sieben Zielen für NU8, das nächste Upgrade, an – mit dem erklärten Ziel, dem Muster ein Ende zu setzen, „bei jedem NU die Wallets zu brechen“.

Der Beschwerde liegt ein frisches Beispiel zugrunde. NU7 wurde letzte Woche bei Block 3.543.405 aktiviert, ohne das Transaktionsformat zu verändern, und doch brauchte, wie das Forumsmitglied strahncryptography im selben Thread anmerkte, jede Wallet vor dem nächsten Ausgeben ein neues Release oder neue Firmware. Jeder mit einem air-gapped Telefon oder einem nicht unterstützten Gerät war ausgesperrt.

Bis zum nächsten Morgen hatten sich im Thread drei Positionen herausgebildet: den Mechanismus streichen, ihn behalten, aber ein Opt-out erlauben, oder anerkennen, dass das eigentliche Problem veraltende Wallets und nicht ablaufende Signaturen sind. Ein Vault-Entwickler zeigte anschließend, warum diese Wahl nicht akademisch ist.

Was tatsächlich bricht

Jede Zcash-Signatur bindet sich an eine Konsens-Branch-ID, ein Label für den jeweils geltenden Regelsatz. ZIP 200, einer der Zcash Improvement Proposals (ZIPs), die die Regeln des Protokolls festlegen, führte sie ein, damit eine für eine Kette signierte Transaktion nicht auf einem Fork mit gemeinsamer Historie wiederverwendet werden kann. Bei Aktivierung eines Upgrades ändert sich die ID, und alles, was unter der alten signiert wurde, ist sofort tot.

Das NU7-Deployment-ZIP führt dies für das soeben erfolgte Upgrade aus: Transaktionen der Versionen 5 und 6 behielten ihre Struktur, aber eine Transaktion ist über die Aktivierung hinweg weiterhin nicht gültig, weil ihre Signaturen die Branch-ID binden. Gespeicherte und offline signierte Transaktionen, fügt das Dokument hinzu, benötigen dieselben Aktivierungsprüfungen wie live signierte.

Deshalb mussten Wallets Updates für ein Upgrade ausliefern, das nichts daran änderte, wie sie Transaktionen erstellen. Eine Wallet, die die neue ID nicht kennt, signiert für eine Kette, die nicht mehr existiert.

Der Vault, der nicht rechtzeitig signieren kann

Daniel Gorgonha, der den Konclave t-of-n Vault bei Deega Labs entwickelt, beschrieb später im Thread die praktischen Kosten. Konclave erstellt die Transaktion zuerst und sammelt danach Threshold-Signaturen, sodass jeder erforderliche Unterzeichner innerhalb des Ablauffensters der Transaktion handeln muss – rund 50 Minuten. Ein Upgrade mitten in diesem Fenster macht alles zunichte.

Die 50 Minuten stammen aus ZIP 203, das die Standard-Ablaufzeit durch drei Änderungen der Blockzeit bei etwa dieser Länge gehalten hat. Seit NU7 bedeutet das 120 Blöcke beim Zielabstand von 25 Sekunden. Es ist ein Wallet-Standardwert, pro Node konfigurierbar, und eine Transaktion kann mit vollständigem Setzen des Felds auf Null ganz ohne Ablauf erstellt werden.

Die Uhr ist also bereits lösbar, zumindest wo die Wallet die Einstellung preisgibt. Die Upgrade-Grenze nicht. Ein Vault könnte seinen Mitgliedern eine Woche zum Signieren geben und verliert die Transaktion dennoch im Moment des Umstellens der Branch-ID. Gorgonhas Anfrage galt dem Opt-out, das nuttycom gerade vorgeschlagen hatte, damit eine Gruppe Signaturen über Stunden oder Tage auf eigenes Risiko sammeln könnte.

Drei Wege heraus, jeder mit einem Haken

Die Branch-ID-Bindung entfernen. Das ist Valar Dragons ursprünglicher Vorschlag. str4d, Ingenieur bei Electric Coin Company (ECC), antwortete, Replay-Schutz sei beim Verfassen von ZIP 200 eine harte Anforderung von Börsen und anderen Ökosystem-Akteuren gewesen; jede Entfernung braucht daher einen Ersatz-Mechanismus, idealerweise einer, der auch feindliche Forks abdeckt, die rein zur Störung der Hauptkette geschaffen werden.

Als Standard behalten, Opt-out erlauben. nuttycom, ebenfalls bei ECC, schlug Signaturvarianten unter ZIP 248 vor, die sowohl die Branch-ID als auch die Ablaufhöhe weglassen. Nutzer, die sie wählen, geben etwas Replay-Schutz auf und erhalten Transaktionen, die ein Upgrade überleben. Der bestehende Algorithmus, der laut nuttycom für die große Mehrheit der Transaktionen gut funktioniert, bliebe der sichere Standard. str4d hatte bereits angemerkt, dass sich eine solche Variante einfach definieren ließe, sobald ZIP 248 aktiv ist.

Infragestellen, ob das für Wallets etwas löst. strahncryptography argumentierte, die Varianten beheben die Langlebigkeit der Transaktion, nicht die Obsoleszenz: Ist die Branch-ID nicht fest codiert, muss der Nutzer die korrekte angeben, was dieselbe Last wieder auf die Wallet-Software legt. Replay-Schutz gegen freundliche Forks habe Wert, schrieb er, aber die Vorteile sollten abgewogen werden.

Der Thread hat die Meinungsverschiedenheit nicht aufgelöst. Er hat die Frage jedoch eingegrenzt: ob sich eine Opt-in-Variante für die Nutzer, die sie brauchen, lohnt – und was diese Nutzer aufgeben würden.

Was ein Opt-out kosten würde

Das Replay-Risiko lässt sich am besten am gerade erfolgten Upgrade veranschaulichen. Nur für NU7 hat ZIP 259 die übliche Anforderung ausgesetzt, dass alte Node-Software sich vor der Aktivierung selbst deprecatet; Betreiber, die nie aktualisierten, können also online bleiben und einem Pre-NU7-Zweig folgen. Eine Transaktion, deren Signatur nicht an einen Zweig gebunden ist, ist genau die Art, die auf beiden akzeptiert werden könnte.

Die Exposition ist der Umfang einer Autorisierung, nicht die Schlüssel dahinter. Eine wiederverwendete Transaktion gibt dieselben Inputs auf einer anderen Kette aus, die der Unterzeichner nie nutzen wollte; ein Fälschen einer neuen ist damit nicht möglich.

Das Weglassen der Ablaufhöhe aus der Signatur hat einen zweiten Effekt: Eine autorisierte Zahlung kann so lange unbestätigt bleiben, wie ihre Inputs unverbraucht sind. Das ist die Funktion, die ein Vault will – und das Risiko, das ein einzelner Nutzer möglicherweise nicht bemerkt.

nuttycom wies zudem auf eine mögliche Verkleinerung der Anonymitätsmenge hin. In einem shielded System hängt der Datenschutz davon ab, dass eine Transaktion aussieht wie jede andere; eine mit einer selten genutzten Variante signierte Transaktion bot eine kleinere Menge, in der man sich verstecken kann. Der Beitrag quantifizierte den Effekt nicht, und keine Variante ist bisher spezifiziert.

Eine langlebigere Signatur aktualisiert kein altes Gerät

ZIP 248, das erweiterbare Transaktionsformat, von dem all dies abhängt, ist noch ein Entwurf. str4d sagte, sein Design sei seit über einem halben Jahr stabil, und er habe die vergangene Woche damit verbracht, es an seitdem eingespielte Konsens-Änderungen anzupassen. Es ist keinem Upgrade zugewiesen, und die Opt-out-Varianten existieren darin noch nicht.

Selbst einmal vorhanden brauchen Hardware-Wallets oder Offline-Signer weiterhin Software, die das neue Format versteht. ZIP 248 verbietet Wallets, Komponenten zu erstellen oder zu signieren, die sie nicht parsen können. Der Kompatibilitätsvorteil ist real, aber er kommt über Wallet-Releases – genau der Schritt, der laut strahncryptography immer wieder scheitert.

Keines davon hilft auch Transaktionen in einem ausgemusterten Format. ZIP 259 stellt fest, dass das NU7-Verbot von Version-4-Transaktionen transparente und Sapling-Spendings ebenso wie Sprout umfasst und dass Re-Signieren sie nicht retten kann; die einzige Lösung ist der Neuaufbau der Zahlung in einer unterstützten Version. Coindoo behandelte letzte Woche den schwierigeren Fall – Sprout-Coins ohne jegliches Ersatz-Format.

Konclave hat zudem sein eigenes unvollendetes Stück. Sein offenes Issue zu asynchronem Signieren trennt über Zeit gesammelte Freigaben von der interaktiven Threshold-Zeremonie, die der Vault heute betreibt. Eine Transaktion, die ein Upgrade überlebt, beseitigt ein Hindernis; der Workflow, der Mitgliedern Beiträge bei ihrem Online-Kommen ermöglicht, muss noch geschrieben und geprüft werden.

Praktische Hinweise

Wenn Sie eine Gruppen-Wallet betreiben:

• Die Aktivierung ist eine Blockhöhe, kein Datum; das Deployment-ZIP jedes Upgrades veröffentlicht sie im Vorfeld.
• Eröffnen Sie keine Signierrunde, die diese Höhe überschreiten könnte.
• Alles, was vor der Aktivierung vorbereitet wurde, muss danach neu erstellt werden, auch wenn noch niemand signiert hat.

Wenn Sie Coins auf einem alten Gerät halten:

• Prüfen Sie vor dem Ausgeben, ob die Firmware oder App NU7-Support ausgeliefert hat.
• Ein blockiertes Spending aus einem unterstützten Pool ist ein Wallet-Problem, kein Verlust von Mitteln.
• Vor dem 6. November gespeicherte Version-4-Transaktionen können nicht durch Re-Signieren gültig gemacht werden.

Coindoos früherer Blick auf zahlungsseitige Wallet-Verbesserungen behandelte die Lücke zwischen dem Erstellen einer Transaktion und ihrer Bestätigung. Dieser Thread fügt dazwischen eine dritte Stufe hinzu: die Autorisierung am Leben halten, während Menschen und Geräte aufholen.

Wie es weitergeht

Ende Januar ist Valar Dragons Ziel, kein Zeitplan. str4d hinterfragte im selben Thread, ob zweieinhalb Monate für den Tachyon-Pool auf derselben Liste ausreichen, und der Branch-ID-Punkt hat von allen sieben die schärfste Gegenwehr erfahren. Ob NU8 mit einem Opt-out, einem Ersatz für Replay-Schutz oder beidem nicht ausgeliefert wird, wird im ZIP-Prozess entschieden – nicht im Forum.