Taproot wird innerhalb der nächsten 2 Wochen aktiviert. Was könnte schief gehen und was könnte getan werden, um die Wahrscheinlichkeit eines dieser schlimmen Szenarien zu verringern?

Szenarien, die keinen Anlass zur Sorge geben

Szenario: Eine gültige oder ungültige Taproot-Ausgabe gelangt vor der Aktivierung in einen abgebauten Block (Block 709632). Es wird einfach so behandelt, als ob jeder ausgeben kann, da niemand im Netzwerk die Taproot-Regeln bis Block 709632 durchsetzt. Dies ist bereits geschehen (ausgeführt von 0xB10C).

Schlechte Fall-Szenarien (treten wahrscheinlich nicht auf)

Szenario: Eine Mehrheit der Miner (obwohl sie bereits vor Monaten Bereitschaft signalisiert haben) führt kein Upgrade auf eine Vollknotenversion durch, die die Taproot-Regeln zum Zeitpunkt der Aktivierung erzwingt. Eine ungültige Taproot-Ausgabe macht sie nach der Aktivierung zu einem geminten Block und erstellt eine große Neuorganisation, wenn sie neu organisiert wird.

Monitor: Es ist möglicherweise nicht klar, welche Mining-Pools für Vollknotenversionen ausgeführt werden. Wenn sie jedoch gültige Taproot-Ausgaben in einen Block (ohne ungültige Taproot-Ausgaben) aufnehmen, den sie nach der Aktivierung abbauen, deutet dies darauf hin, dass sie die Taproot-Regeln korrekt durchsetzen.

Szenario: Bei Protokollen der zweiten Schicht treten aufgrund des Taproot-Upgrades unvorhergesehene Probleme auf, die behoben werden müssen. Laolu Osuntokun diskutierte kürzlich ein Taproot-bezogenes Problem mit dem Neutrino-Light-Client-Protokoll, das im Testnet auf der bitcoin-dev-Mailingliste beobachtet wurde.

Überwachen: Es hängt wirklich von der Frage ab, was überwacht werden soll, aber alle Probleme werden wahrscheinlich auf den Bitcoin-Dev- und Lightning-Dev-Mailinglisten diskutiert.

Worst-Case-Szenarien (sehr unwahrscheinlich)

Im Taproot-Implementierungscode wurde ein Fehler gefunden, und wir benötigen einen Hard Fork, um entweder den Fehler zu beheben oder die Soft Fork-Änderung rückgängig zu machen.

Welche schlimmen Szenarien sind in der Vergangenheit bei früheren Soft-Fork-Aktivierungen aufgetreten?

Bitcoin Optech geht hier die Geschichte der Soft-Fork-Aktivierungen durch . Es gab eine Reihe von Notaktivierungen von Konsensänderungen, um Fehler zu beheben, obwohl dies keine vorgeplanten Soft Forks wie Taproot waren. Und obwohl der SegWit-Soft-Fork 2017 schließlich reibungslos aktiviert wurde, verliefen die Monate bis zu dieser Aktivierung alles andere als reibungslos (Sie können über die Monate vor der SegWit-Aktivierung in The Blocksize War von Jonathan Bier nachlesen ). Die einzige vorgeplante Soft-Fork-Aktivierung, die zum Zeitpunkt der Aktivierung auf Probleme stieß, war die BIP 66-Soft-Fork im Jahr 2015. Wie Optech feststellt:

Die 75%-Schwelle wurde bei Blockhöhe 359.753 erreicht. Am 4. Juli 2015 wurde die 95-%-Schwelle bei Block 363.725 erreicht und alle Knoten, auf denen Bitcoin Core Version 0.10.0 oder höher (oder eine kompatible Implementierung) ausgeführt wurde, begannen mit der Durchsetzung der neuen Regeln. Bei Blockhöhe 363.731 produzierte ein nicht aktualisierter Miner jedoch einen Block, der nicht die richtige Blockversion enthielt und daher gemäß den neuen ISM-Aktivierungsregeln nicht gültig war. Andere Miner bauten auf diesem ungültigen Block auf und produzierten schließlich eine Kette mit sechs ungültigen Blöcken. Dies bedeutete, dass nicht aktualisierte Knoten und viele Lightweight-Clients die 96 Transaktionen im ersten ungültigen Block so behandelten, als hätten sie sechs Bestätigungen, obwohl sie zu diesem Zeitpunkt nicht einmal in einem gültigen Block bestätigt worden waren. Schließlich konnten Entwickler Poolbetreiber kontaktieren und sie dazu bringen, ihre Software manuell zurückzusetzen, um zur gültigen Kette zurückzukehren. Ein zweites Ereignis dieser Art trat am nächsten Tag auf und gab Transaktionen drei falsche Bestätigungen. Glücklicherweise wurden alle regulären Transaktionen sowohl aus den ungültigen Ketten mit sechs als auch mit drei Blöcken später in gültigen Blöcken bestätigt, was bedeutet, dass keine regulären Benutzer Geld verloren haben.