Ich stimme dir zu, falls ECDSA unerwartet gebrochen wird - egal ob durch QC oder auf eine mathematische Entdeckung (was noch unwahrscheinlicher als QC wäre, aber das ist halt so eine Sache mit unknown Unknowns) - dann haben wir ein ernstes Problem. Man wird dann m.E. auch nicht mit Lightning weiterfahren können, denn auch Lightning basiert ja auf dem p2p Austausch vorsignierter Transaktionen, und aus diesen könnte dann jede Seite den private Key der Gegenseite berechnen; einziger Unterschied ist, dass diese nicht publiziert werden. Das würde also kaum funktionieren, ausser ich bin mir sicher, dass mein Channel-Peer (noch) nicht über einen QC verfügt. Die Kooperation der Miner, das wäre schwierig, aber evtl. nicht total unmöglich, da Miner ja auch an einer Lösung interessiert sein müssten, sonst können sie ihre Hardware entsorgen - da sie aber gleichzeitig auf gegenseitige Kooperation angewiesen wären, habe ich keine Ahnung, wie das funktionieren könnte. Ich glaube daher, die einzige Möglichkeit besteht darin, alternative Algorithmen bereitzustellen, bevor dieser Fall eintritt.
Dabei muss Taproot aber nicht aufgegeben werden, denn es steht ja immer noch das alte Segwitt Format zur Verfügung. Dort gibt es ja neben P2WPKH (überweisung auf einen 20 Byte public key hash) auch das P2WSH (überweisung auf einen 32 Byte Script Hash). P2WSH kann nur ausgegeben werden, wenn ein Script vorgelegt werden kann, der auf diesen 256Bit Hash hasht (und dabei helfen weder ein QC noch gebrochener Signieralgorithmen), UND man den Script erfüllt; der Script selber kann dann beliebige Signaturen verlangen, die beim Ausgeben zur Verfügung gestellt werden müssen, wie man das heute schon z.B. bei Multisigs macht. Allerdings gibt es bisher halt nur Opcodes für ECDSA. Es spricht aber überhaupt nichts dagegen, in künftigen Softforks weitere Signieralgorithmen im Sinn von Templates zu implementieren. Damit sind Opcodes gemeint, die „bis jetzt“ immer als „erfüllt“ angeschaut werden, aber nach dem Softfork eine zusätzliche Signatur vom Stack nehmen und verifizieren würden. Sowas hat man ja bereits mehrere Male so gemacht, z.B. beim berühmten „OP0 pkh“, was alte Nodes als „alle können das ausgeben“ interpretieren, neue Nodes aber eben im Segwitt Sinn verifizieren. Dann könnte jeder, der will, seine Coins mit einer beliebigen Kombination dieser Signierverfahren schützen und im Output den Hash eines Scripts angeben, der diese Signaturen zusätzlich verifiziert - so wie Multisigs, aber mit unterschiedlichen Signieralgorithmen. Es würde also noch nicht einmal ein neues Adressformat benötigt, lediglich neue (template) Opcodes für neue Algorithmen. Natürlich verlassen wir uns hier trotzdem noch auf die Sicherheit der Hash-Algorithmen, aber die sind nach Allem was wir wissen tatsächlich quantensicher.
Man kann dann frei entscheiden, ob man Coins in einem dieser beliebig sicheren Formate aufbewahren will (die dann beim Ausgeben speicherintensiv sind, aber nicht beim Erstellen, es ist ja nur ein einziger Hash), was man wohl für langfristiges Aufbewahren machen würde, oder im langfristig etwas unsichereren aber halt viel flexibleren Taproot Format, was für den Alltagsverkehr wohl geeigneter wäre. Würde dann ECDSA unerwartet gebrochen, wären zwar alle Taproot Coins im UTXO gefährdet, aber nicht die „langfristig“ deponierten P2WSH Coins (wäre das dann ein „Icecold Wallet“? 
). Sie könnten auf gefahrlos wieder ausgegeben werden - wenn auch mit hohem Speicherbedarf - und man hätte Zeit, sich auf ein neues Format zu einigen.
Ich dachte zuerst, man könnte statt P2WSH auch direkt P2TR benutzen, denn das sind ja nicht einfache public Keys, sondern eigentlich eine aggregierte Kombination von public Key(s) und/oder (merkelized) Script Hash(es) im Sinne von MAST. Das wäre cool, weil man dann die langfristigen nicht von den „normalen“ Coins unterscheiden könnte (während man Segwitt Adressen natürlich von Taproot Adressen unterscheiden kann). Man könnte ja dann nur den Script Hash ohne public Key aggregieren, dann erreichte man Dasselbe. Leider vermute ich - bin mir da aber nicht 100% sicher -, dass es zu jedem Script Hash, den man in eine solche P2TR Adresse schreibt, auch einen private Key gibt, der sich bitmässig genau zu dem public Key berechnet, der dem Script Hash entspricht. Script Hashes sind bei Taproot ja einfach 256 Bit Zahlen, und public Keys ebenfalls. Normalerweise kombiniert („aggregiert“) man hier ein tatsächliches public/private Key Paar mit dem Script Hash, man kann aber natürlich auch nur Script Hashes benutzen. Aber selbst wenn man das tut und als Ersteller überhaupt keinen private Key benutzt, könnte ein QC aus dem Script Hash, den er einfach als public Key interpretiert, einen passenden private Key berechnen. Das hängt letztlich davon ab, ob die Transformation von private- auf public Keys bei ECDSA (was letztlich der Multiplikation mit den Generator G entspricht) surjektiv ist, ob also jeder Punkt der elliptischen Kurve damit erreicht werden kann. Auf einer „graphischen“ elliptischen Kurve - das sind diese liegenden Omega-artigen Dinger (ohne Bezug zu Corona 
) - ist das zweifellos der Fall. Ob das im diskreten Fall auch so ist (diese Kurven sind ja nur Visualisierungen), weiss ich leider nicht, aber vermutlich ist das der Fall; weiss da jemand mehr dazu? Dann könnte aus jedem beliebigen 256 Bit Wert ein passender private Key berechnet werden. Daher halte ich die Verwendung von Segwitt als den sichereren Weg - man bezahlt nur dadurch, dass man auf der Chain dann analysieren kann, welche Coins sich vermutlich in dem „langfristigen“ Speicherformat befinden.