Zuerst möchte ich mich einmal entschuldigen, dass ich das Fass hier aufmache, aber ich habe die Antworten nirgends gefunden.
Man hört ja immer diese FUD von wegen „Bitcoin wird wegen Quantum Computern in x Jahren sterben“ und so weiter. Aber gibt es eigentlich eine Schätzung von einem Experten, welcher wirklich weiß, wovon er redet und nicht solchen „Journalisten“ in wie vielen Jahren man sich um eine Implementierung von Quantum-resistenter Algorithmen Gedanken machen sollte?
Sagen wir, in x Jahren würden Quantum Computer eine potenzielle Bedrohung darstellen, was müsse man am Netzwerk ändern, also müsste man „nur“ neue Adressen implementieren oder müsste man auch etwas am Mining ändern. Wäre das ein Hard- oder Softfork?
Ich bin weder Experte noch Journalist. Aber da die Quantencomputer eine potentielle Bedrohung auf einer Zeitskala von Jahrzehnten darstellen, gleichzeitig aber kryptographische Verfahren am besten auch schon Jahrzehnte vorab bekannt und untersucht sein sollten, muss mann sich die Gedanken jetzt machen.
Und genau deshalb macht man das auch schon mindestens seit den 2000er Jahren:
53:28 „In zuruft, wenn Bitcoin angreifbar werden wird, muss ich sie (die Bitcoin) halt mit jemanden lagern, welcher sich gegen Quantum Computer verteidigen kann.“
Was er damit mein verstehe ich nicht, wie soll diese Drittpartei in der Lange sein, sich gegen Quantum Computer zu verteidigen?
Gute Frage, eigentlich wollte ich alle Folgen mit ihm ignorieren, aber hab mir dann heute diese auch angeschaut! Über dies bin ich auch gestolpert, insgesamt auch wieder viel FUD und Niko hat halt auch nicht den technischen Background. Solche Interviews sollte man lieber mit Leuten wie Antonopoulos führen welche sich technisch mit der Materie auskennen.
Wenn ich denen meine Coins gebe wie er vorschlägt bringt das dan ja auch nichts wenn Bitcoin nicht Quantenresistente Adressen hätte. Sein Argument macht keinen Sinn.
An dieser Stelle hat er das glaube ich einfach nur sehr unglücklich ausgedrückt.
Er vertritt im gesamten Interview die Meinung, dass vorerst kein Fork mit neuen Adresstypen notwendig ist. Stattdessen reiche es, wenn man seine Bitcoin in kleinen Häppchen auf mehrere Adressen verteilt. Und zwar so kleine, dass es sich einfach nicht lohnt diese mit einem beliebigen neuartigen Computer zu knacken.
Sollte es außerdem irgendwann praktisch möglich sein, Public Keys zurückzurechnen, würde das sowieso zuerst bei Adressen mit größeren Beträgen angewendet werden. Und selbst dort würde man den Angriff evtl. gar nicht wirklich öffentlichkeitswirksam durchführen, sondern das anderweitig ausnutzen. Schließlich sind die Eigentümer oft bekannt.
Er sieht das alles ziemlich cool und meint, ein Hard Fork würde nur von denjenigen gefordert, die sich nicht wirklich selbst um ihre Coins kümmern wollen.
Man kann die Argument grob nachvollziehen, aber ich persönlich sehe das nicht ganz so locker wie er. Ich gebe ihm aber insofern recht, dass die Bedrohung durch neuartige Computer kontinuierlich wächst. Irgendwann wird dann der Punkt erreicht, wo es sich gerade so lohnen würde die Public Keys mit den größten Beträgen zu knacken.
Es wird nicht von heute auf morgen wirtschaftlich sein und es wäre schon gar nicht intelligent, viele Adressen auf einmal leer zu räumen. Gerade auch der letzte Aspekt, die Abschätzung und Abwägung des entstehenden Vertrauens- und Kursverlustes gegen die mögliche Beute, ist eine interessante Fragestellung.
Zum Thema Post-Quantum-Verfahren…
Man redet immer etwas leichtfertig von einem möglichen Fork, mit dem ganz einfach auf Post-Quantum-Adressen übergegangen werden soll, sobald ein neuer Standard gefunden wurde. Unabhängig von der Sicherheit hat man aber ein potentielles Größenproblem mit den Signaturen.
Dazu habe ich im verlinkten Thread schon etwas geschrieben, aber hier ein kleines Update zum NIST-Auswahlprozess (37C3, NIST):
Die aktuelle Bitcoin (ECDSA) Signatur, die man für das Ausgeben eines UTXOs benötigt, ist 64 Byte groß.
Die Signaturen der letzten Kandidaten im Post-Quantum-Auswahlverfahren sind größer als ein Kilobyte (FALCON, gitterbasiert), mehrere Kilobyte (CRYSTALS-DILITHIUM, gitterbasiert) bis zu mehreren 10 Kilobyte (SPHINCS+, hashbasiert).
Der Rechenaufwand zur Verifizierung ist bei FALCON und DILITHIUM allerdings sogar geringer als aktuell bei ECDSA (Quelle).
Edit:
Ich habe gerade gesehen, dass Algorand zu FALCON beigetragen hat und plant, dieses Verfahren einzusetzen (Quelle). FALCON bietet auch bisher den besten Kompromiss aus Key-Größe, Signatur-Größe und Verifikationsdauer.
