Kommentar zu: Quantencomputer, BITCOIN und Bugs | Jörg Hermsdorf im Interview

Diskussionen
1

Ich habe versucht, diesen Kommentar in Youtube zu posten - der wurde leider immer wieder gelöscht (durch YT, nicht euch - ich sah in ein paar Minuten in meinem Verlauf, dann war er jeweils plötzlich fort, muss eine YT Macke sein). Darum poste ich das hier:

Ich fand das Video gut und informativ, aber was den Quantencomputer Teil anbetrifft finde ich, der es wird mehr Konfusion geschaffen als wirklich etwas geklärt. Ich stimme zwar der Meinung zu, Quantencomputer stellen kein unlösbares Problem für BTC dar, finde aber, man sollte das sauber darstellen. Man muss ganz klar unterscheiden zwischen:

  • Dem Mining, der Blockchain selber: hier kommen Hashfunktionen (SHA256) zum Zug, hier geht es um Proof of Work, um Thermodynamik, um Entropie und Energie, um Konsensfindung. Und hier stellen Quantencomputer klar KEIN Risiko dar, da sie für Hashfunktionen untauglich sind, diese nicht reversen können, egal of SHA256 oder SHA512 oder was auch immer. Das ist nichts Neues, war immer unbestritten, und können wir abhaken. Leider wird im Beitrag praktisch nur dieser eine Aspekt, der überhaupt kein Problem darstellt, diskutiert. Zwar korrekt und ich widerspreche den Argumenten mit keinem Wort - QC stellen für die Blockchain mit PoW selber kein Problem dar. Das ist aber nicht der springende Punkt…

  • Davon klar trennen muss man die Signaturalgorithmen selber (eliptische Kurven, Schnorrr Signaturen), mit denen dann die einzelnen Transaktionen signiert werden. Die haben NICHTS mit dem Mining oder der Blockchain selber zu tun, mit SHA256, mit Entropie, Thermodynamik, oder Energieaufwand. Das geht es um ein völlig anderes Problem. Denn HIER ist der theoretische Angriffspunkt von QC. Es ist essentiell, dass entweder nie QC gebaut werden können, die leistungsfähig genug sind, private Keys aus public Keys der Signieralgorithmen zu berechnen (es kommt dann noch die Frage, ob man die public Keys überhaupt kennt - in Taproot kennen wir diese wieder, im Gegensatz zu Segwit) - oder, falls es starke QC jemals geben wird (sehr spekulativ), dass man VORHER (!) quantensichere Algorithmen entwickelt, diese in einem neuen Adressformat in Form eines Soft Forks verfügbar macht, und den Usern genügend Zeit gibt, ihre Coins auf das neue Adressformat zu transferieren. Gelingt das nicht, besteht durchaus das Risiko, dass man keine sicheren Transaktionen auf der Blockchain mehr vornehmen kann. Die Blockchain selbst bliebe zwar unangegriffen, Mining wäre noch immer sicher, ein Konsens würde noch immer gefunden, aber sie böte trotzdem keine Sicherheit mehr, da sie gewissermassen die privaten Signatur-Keys „leaken“ würde, spätestens im Moment des Ausgebens. Man muss also zwischen der Sicherheit der Blockchain, und der Sicherheit der Transaktionen darin unterscheiden.

Es ist m.E. essentiell, sich mit diesen quantensicheren Algorithmen zu beschäftigen. Diese haben bis heute zwei Probleme: Erstens: wie wissen wir, dass ein Algorithmus „quantensicher“ ist? Wir wissen höchstens, dass es noch keinen Quantenalgorithmus zu einem Signierverfahren gibt. Zweitens: die bis heute bekannten (vermutlich) quantensicheren Algorithmen haben einen sehr grossen Speicherbedarf. Transaktionen würden damit sehr teuer werden. Meines Wissens kennen wir noch kein wirklich praktikables Verfahren (da kann ich mich aber täuschen). Schliesslich würde sich eventuell das Problem stellen, dass solche Algorithmen nicht alle praktischen Features von Schnorr Signaturen auch noch hätten, wie Signaturaggregation oder MAST. Es könnte also zu einem zwar quantensicheren, aber weniger funktionalen Adressformat führen, und dann würde es mit der Adoption schwierig.

Die Sache mit der 1-Million-Nakamoto-Coins stellt sich schon, ist aber eher ein psychologisches und vielleicht „Show“ Phänomen. Wenn der Bitcoin schon vollständig adoptiert ist, wäre es wohl kein existentielles Problem, wie du zu Recht auch sagst - zwar unschön, dass eventuell eine Person zum reichsten Menschen der Welt wird, die Funktion des Bitcoins würde es aber nicht gefährden. Es könnte aber trotzdem hässlich werden (Unruhen?), würde immerhin um 5% des gesamten Geldes der Welt gehen. Wenn wir Glück haben, ist Satoshi noch unter uns, hat seine Keys nicht vernichtet, und rettet diese Bitcoins rechtzeitig in einen zweites, jetzt hoffentlich wirklich sicheres „Grab“ (kann man da von Exhumation sprechen? :-). Problematischer wird es natürlich, wenn das schon in 5 Jahren oder so passieren würde, das könnte dann die Adoption des Bitcoins schon stark bremsen. Aber auch das Vertrauen ins gesamte Finanzsystem wäre dahin, darum habe ich da nicht so Angst.

10 „Gefällt mir“
2

Ich habe erstmals ein Video vom Blocktrainer abgebrochen. Der Gast wirkte wirklich ziemlich demotiviert, lustlos und konnte die Themen schlecht rüberbringen.

3

@klaymen: Toller Beitrag! :+1:

Schade, dass er bisher etwas untergeht. Ich muss zugeben, dass ich das Video auch nicht komplett gesehen habe. Ich hatte mehrere deiner Gedanken auch schon, deshalb hier ein paar Überlegungen dazu:

Wahrscheinlich ist es zumindest kein großes Problem.

Ich habe mich da selbst noch nicht im Detail eingelesen und mir ist unklar, inwieweit Grover’s Algorithmus die Sicherheit von SHA-256 beeinträchtigt. Evtl. würde man damit wesentlich weniger Versuche benötigen, um einen gültigen Block zu finden. Aber das wäre kein Problem, wenn die HW irgendwann für jeden verfügbar wäre und man einen fließenden Übergang hätte.

Ich nehme an, dass die ersten dafür verwendbaren Quantencomputer so teuer wären, dass es sich nicht lohnt damit zu minen. Nehmen wir weiter an, dass die Kosten um mit einem Quantencomputer zu minen langsam im Laufe der Jahre fallen werden.
Dann kommt irgendwann der Punkt, wo die ersten Miner Quantencomputer einsetzen werden, weil es sich von da an lohnt. Wir hätten also einen halbwegs fließenden Übergang, der kein Problem darstellt.

Wenn man sich HIER mal die historische Bitcoin Hashrate ansieht (All Time, Logarihtmic Scale), haben die Übergänge von GPU zu FPGA (ab 2011) und von FPGA zu ASIC (ab 2013) relativ fließend stattgefunden (Quelle für Zeiträume: Google und Wikipedia).

Interessanter fände ich an der Stelle die mögliche Zentralisierung dieser neuen Geräte. Sobald es „mining-taugliche“ Geräte geben sollte, müssten diese auch für jeden verfügbar sein. Und am Anfang wird es wahrscheinlich wieder längere zeit nur einen Platzhirsch geben. Aber das sind keine Quantencomputer-spezifischen Probleme.
Schwieriger wird die Frage, von wem und wo so ein Gerät noch sinnvoll betrieben werden kann. Die Geräte sind sicher wesentlich empfindlicher und am Anfang sehr groß.

Was mich am meisten interessiert, ist der Proof of Work an sich.

Ob das Mining wirklich einen Proof of Work darstellt wissen wir erst, wenn wir das Landauer Prinzip irgendwann besser verstanden und validiert haben. Nur wenn für eine Bitoperation naturgesetzlich immer ein nicht unterschreitbares Minimum an Energie aufgewendet werden muss, bleibt der Proof of Work dauerhaft seinem Namen gerecht und sicher.
Es gibt Artikel zur Validierung des Prinzips, auch schon erste Versuche mit Qubits. Ich habe mich damit aber zu wenig beschäftigt, insbesondere ist mir nicht klar inwieweit Reversible Computing hier relevant werden könnte.

Das ist richtig. Ich sehe kein Problem darin, dass man schnell genug neue Verfahren findet. Allerdings gibt es neben den Satoshi Coins auch eine große Menge verlorener Coins, die dann plötzlich wieder ins Spiel kommen.
Theoretisch könnte der erste Betreiber des Shor-Algorithmus auf einem Quantencomputer ausreichender Größe sich all diese BTC sichern.

(Sorry, ich habe gesehen, du hast weiter unten etwas dazu geschrieben. Sehe ich genau wie du.)

Die Kryptographie bestand schon immer aus tickenden Zeitbomben, die auch in der Vergangenheit alle zuverlässig explodiert sind. Sowohl bei aktuellen als auch post-quantum Algorithmen kann man nicht beweisen, dass sie sicher sind. „Sicher“ bedeutet hier, dass es nur die schon bekannten Verfahren gibt um eine Verschlüsselung anzugreifen. Deshalb werden neue Verfahren auch üblicherweise 10…20 Jahre erforscht, bis man sie einsetzt.

Deshalb finde ich es eine ganz entscheidende Absicherung, dass Bitcoin Adressen mit drei unterschiedlichen Verfahren aus dem Private Key berechnet werden. Drei bewährte Verfahren wird man nicht gleichzeitig brechen.

Umso seltsamer ist deshalb der Punkt:

Ich habe das auch immer wieder gelesen und bin mir bis heute nicht sicher, ob ich das richtig verstanden habe.
Wenn es wirklich so ist, wäre das m.E. eine der dümmsten Entscheidungen, die in der Bitcoin Entwicklung jemals getroffen wurden. Bei extrem Sicherheits-relevanten Themen verlässt man sich niemals nur auf eine Technologie (Diversität: Gürtel + Hosenträger).

Allerdings weißt ich nicht, ob man sich als Laie hier täuscht. Hier wird das allerdings gut erklärt und es sieht so aus.

Soweit ich weiß gibt es noch kein Verfahren, von dem alle überzeugt sind. Der NIST Prozess zur Standardisierung von Pots-quantum Verfahren läuft ja auch noch.

Einen schönen Überblick bietet der NIST Bericht zur Runde 2 oder auch dieses Video auf dem 35C3 (schon drei Jahre alt, gibt es auch übersetzt).

Die Public Keys oder Signaturen dieser Verfahren sind teilweise einige Megabyte groß. Ein Lichtblick sind aus meiner Sicht die Supersingular Isogenies. Siehe z.B. auf Wikipedia oder in diesen Videos: 36C3 Vortrag, Microsoft Research.

Die Keys sind dabei nur ca. eine Größenordnung größer als heute. Der Rechenaufwand ist größer als bei anderen Post-Quantum Verfahren, aber das wäre bei Bitcoin schätze ich kein riesiges Problem.

Im NIST Verfahren ist auch ein Isogeny-basiertes Verfahren dabei (SIKE), in diesem Fall allerdings nicht für digitale Signaturen. Man forscht aber an Isogeny-basierten Signaturverfahren (z.B. CSIDH, SeaSign etc.). Es wird spannend wie klein die Signaturen sein werden können.
NIST schreibt im Status Bericht: „NIST sees SIKE as a strong candidate for future standardization with continued improvements“. Es ist also noch mehr Forschung und Bewährung notwendig.

Edit (Ergänzung):

Es gibt u.a. noch die gitter-basierten und die hash-basierten Verfahren, die man hier erwähnen sollte, weil sie seit langer Zeit die Post-Quantum-Kandidaten schlechthin sind.

Bei den hash-basierten Verfahren war das Problem soweit ich weiß, dass man mit dem Private Key nur wenige oder sogar nur ein Mal signieren kann, da man sonst auf ihn zurückrechnen kann. Man dürfte also jeden Public Key und jede Bitcoin-Adresse nur einmal verwenden.

Natürlich kann am Ende auch ein hash-basiertes Verfahren am besten für die Blockchain geeignet sein. Aber Iota hat z.B. erst vor kurzem von solch einem Verfahren (WOTS) zurück auf einen nicht quanten-resistenten Standard gewechselt. Grund waren das mehrfache Verwenden von Adressen, Rechenleistung, Signaturgrößen von einigen kByte und dass es kein Standard ist.

Auch ein Punkt, wo ich dir zustimme, und den ich bisher nicht nachvollziehen kann. Man kann sich nicht darauf verlassen, dass man schon irgendwann ein post-quantum Verfahren findet, das gleichzeitig auch die vorteilhaften Schnorr Features mitbringt.

Zweitens benötigen neue Verfahren wie schon gesagt mindestens 10…20 Jahre, bevor man sie scharf einsetzen sollte. Alle Verfahren im aktuellen NIST Auswahlprozess sind schon seit langem bekannt.

Wenn man also davon ausgeht, dass es in den nächsten 20 Jahren Quantencomputer geben wird, die den Bitcoin Signaturen gefährlich werden, dann werden die Schnorr-Features wohl zwangsweise wieder wegfallen.

13 „Gefällt mir“
4

Dem ist nichts hinzuzufügen. Sehr gut.

5

Danke, Super Beitrag, ich habe eine Menge gelernt :+1:

Eine Anmerkung zur Taproot Sache: in der Tat wird bei Segwit im UTX0 nur der Hash des Public Keys abgelegt, was diesen weitgehend quantensicher macht, und bei Taproot - wie auch in Legacy Formaten - direkt der public Key, was diesen für (theoretische) QC anfällig macht. Ich konnte dies zuerst auch nicht verstehen. Ein Grund mag darin liegen, dass man so etwas Platz in der BC spart, da man den public Key beim Ausgeben ja ohnehin angeben muss. Die Hauptmotivation für den Hash bei Segwit war meines Wissens, dass man dafür Platz im UTX0-Set spart, welcher wertvoller als der Bedarf in der BC ist, da der benutzte Hash mit 160 Bit kleiner als die 256 Bit für den public Key ist. Heute erachtet man die 160 Bit aber auch nicht mehr als optimal, so dass man ohnehin auf 256 Bit Hashes gehen müsste, und da würde dieser Vorteil wegfallen. Damit dreht sich das Platzbedarfs-Argument zugunsten des public Keys um.

Relevanter und für mich nachvolziehbarer finde ich aber das Argument, dass der Hash ohnehin nur eine Scheinsicherheit bietet. Man muss zum Ausgeben den public Key ja trotz Allem in den Mempool legen, und bis die Transaktion geminet wird, vergehen im Schnitt 10 Minuten, aber auch gerne mal ein paar Stunden. In diesem Zeitfenster wäre der Key für einen QC angreifbar, und - wenn der Angriff gelingt - könnte eine Transaktion mit höheren Fees in den Mempool gelegt werden, was die eigentliche Transaktion verdrängen würde. Die könnte jetzt vielleicht Fees nachschiessen, der Angreifer aber auch,und am Ende dieser Spirale würde der gesamte Betrag an die Miner fliessen (was letztlich auch bedeutet, dass nur Miner an einem solchen Angriff Interesse haben könnten - oder Akteure, die den BTC diskreditieren wollen). Man kann jetzt argumentieren, die paar Minuten reichten für einen QC dazu nicht aus. Wenn es aber möglich ist, einen QC zu bauen, der einen private Key in ein paar Tagen oder Wochen brechen kann, dann ist es auch im Bereich des Möglichen, dies in einer Stunde zu machen. Man hätte also das Problem, dass seine Coins in der Blockchain zwar erst mal sicher wären, aber man sie trotzdem nicht ausgeben könnte. Man kann über eine Lösung des Problems nachdenken, dass man die Transaktion nicht in den Mempool legt, sondern „direkt“ minet; dies würde eventuell in einem ähnlichen Murks wie bei Ethereum enden, wo man mit Flashbot Protokollen „private“ Zugänge zu Minern umsetzt, um das Frontrunning (MEV) zu verhindern. Das wäre auf jeden Fall Murks, und würde zumindest das permissionless-Versprechen von Bitcoin zerstören. Auch Lighnning wäre übrigens gefährdet, da man Kanäle nicht mehr sicher setteln könnte, was die ganze Spieltheorie über den Haufen werfen würde. Es wäre vergleichbar mit der Situation, dass man sein Geld zwar sicher zuhause im Tresor hat, aber sobald man damit auf die Strasse geht, mit hoher Wahrscheinlichkeit ausgeraubt würde, und man es daher nicht ausgeben könnte. Ich finde es daher nachvollziebar, wenn man sagt, das Hashen löst das QC Problem nicht und durch den Verzicht darauf erhöht man den Druck, eine echte Lösung für das Problem in Form sicherer Algorithmen zu finden. Das Problem wird damit sichtbarer gemacht. Scheinlösungen helfen im Allgemeinen nicht, einer echten Lösung des Problems näher zu kommen, weil der Druck dazu teilweise wegfällt.

Vielleicht noch ein kleiner spieltheoretischer Aspekt zu QC: Viele haben Angst, dass die Entwicklung von QC bei NSA etc viel weiter fortgeschritten sein könnte, als man momentan weiss, QC also früher kommen könnten als befürchtet. Selbst wenn dem so wäre (was ich nicht glaube): ein solcher staatlicher Akteur würde damit verschlüsselte Mails von geopolitischen Gegner brechen können, ein massiver strategischer Vorteil. Es wäre von ihm total hirnrissig, die Technologie gegen BTC einzusetzen - der dabei möglicherweise zerstört würde, aber gleichzeitig der strategische Vorteil des Akteur, weil damit sofort die Existenz solcher QC für die gesamte Welt erkennbar wäre. Damit dies geschieht, müsste BTC die grössere Bedrohung als der geopolitische Gegner sein, und davon sind wir noch sehr weit weg. Ein Akteur mit QC zieht den viel grösseren Vorteil daraus, dessen Existenz geheim zu behalten.

8 „Gefällt mir“
6

Für mich einer der interessantesten Threads seit Monaten, danke für die interessanten Anregungen!

:+1:

4 „Gefällt mir“
7

Das alles hört sich, genauso wie dein kompletter restlicher Beitrag, sehr plausibel an und hat mich doch ein bisschen zum Grübeln gebracht.

Auch wenn sich die ganzen spieltheoretischen Überlegung sinnvoll anhören, finde ich eine ausschließliche Abhängigkeit davon unbefriedigend. Ich habe selbst im Forum immer wieder geschrieben, dass man durch ECC, SHA256 und RIPEMD160 eine dreifache Sicherheit hat.

Aber das ist ganz offensichtlich entweder Bullshit, oder ich übersehe etwas. Ich fasse es nochmal mit meinen Worten zusammen.

Der Bruch eines kryptographischen Verfahrens findet nicht immer schön kontinuierlich statt, so dass man heute noch 100 Mrd, morgen 10 Mrd und übermorgen 1 Mrd Jahre braucht, um Keys zurückzurechnen.
Es gibt sehr wohl eine absolut nicht vernachlässigbare Wahrscheinlichkeit, dass ein neues Angriffsverfahren von heute auf morgen die Sicherheit auf praktisch 0 reduziert. Das ist keine FUD, sondern die Erfahrung der letzten Jahrhunderte, bis zu aktuellen Verfahren wie RSA. Nehmen wir also mal den schlimmsten Fall an.

Natürlich kommt erst einmal niemand an meine Coins wenn ECC morgen komplett gebrochen wird, was ich bisher als sehr beruhigend empfunden habe. Aber wenn man so wie du einen Schritt weiterdenkt, hat man davon nicht viel.

Sagen wir alle hätten ihre Coins auf PublicKeyHash oder ScriptHash Adressen, was bei Taproot schon nicht mehr der Fall wäre.
Die Coins sind sicher, aber niemand könnte sie mehr transferieren, da im Moment der Transaktions-Übermittlung an das Netzwerk der PublicKey veröffentlicht wird.

Was macht man nun?

Selbst wenn man innerhalb kürzester Zeit auf eine neues Verfahren umsteigen würde, bringt das nichts:

  • Bis zum Update auf eine neue Software vergehen sicher mindestens Wochen. Sollte solange der Zahlungsverkehr in einem Bitcoin-Standard stillstehen?
    → Mögliche Lösung (?):
    Man bleibt bis dahin in Second Layern. Allerdings bin ich mir nicht sicher, ob man die fehlende Möglichkeit für onchain Transaktionen in dieser Phase als Sicherheitslücke missbrauchen könnte.
    Insbesondere Lightning arbeitet ja auch noch mit vor-signierten Transaktionen, was wohl ein Problem wäre. Es könnte sein, dass alle Bitcoin in Lightning dann schon direkt unsicher wären.

  • Sobald die neuen Adress-/PublicKey-Typen implementiert sind, müsste man seine Coins dorthin transferieren.
    → Mögliche Lösung (?):
    Über diesen Punkt habe ich nun etwas nachgedacht, aber mir fällt nicht ein wie das funktionieren sollte.
    Ich leake durch die Transaktion schließlich meinen PublicKey. Dann dürften diese Transaktionen nur direkt an Miner übermittelt werden, was in einem P2P Netzwerk schwierig ist. Und man müsste diesen Minern vertrauen, dass sie aus Eigeninteresse in dieser schweren Zeit niemandem die Coins stehlen, sondern für einen reibungslosen Übergang sorgen.

Gerade der zweite Punkt erscheint mir sehr unrealistisch.

Falls ich nichts übersehe komme ich zu dem Ergebnis, dass man eine solche Abhängigkeit von Einzelfehlern bei einer Weltwährung nicht haben darf.

Mögliche Lösung:

Man verwendet in Zukunft neue PublicKey-Typen, bei denen der PublicKey durch zwei kryptographische Verfahren gebildet wird. Diese beiden Verfahren sollten möglichst diversitär sein, dürfen also durch denkbare Angriffe nicht beide betroffen sein (Common Cause Failure).

Die Schwierigkeit dabei ist üblicherweise, dass man sich nicht alle möglichen CCF im Voraus überlegen kann. Man muss also einfach auf möglichst viele unterschiedliche Grundprinzipien der beiden Verfahren achten. Dabei würden die ganzen komfortablen Schnorr-Features wahrscheinlich wegfallen, aber das wäre mir nach der Abwägung egal.

Bei der Bildung des PublicKeys gäbe es wahrscheinlich mehrere Möglichkeiten. Entweder er setzt sich schlicht aus den PublicKeys der beiden Verfahren zusammen, was allerdings den Speicherbedarf auf der Blockchain erhöhen würde. Oder man findet eine elegante Möglichkeit wie man die beiden Verfahren kombinieren kann.

So oder so bräuchte man wahrscheinlich etwas mehr Speicher und mehr CPU-Aufwand bei der Validierung der Transaktionen. Das wäre es aber m.E. absolut wert.

Was hältst du, oder auch jeder andere davon? Das hat man doch sicher irgendwann in der Vergangenheit schon einmal diskutiert?

6 „Gefällt mir“
8

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“? :grinning:). 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 :joy:) - 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.

6 „Gefällt mir“
9

Ich finde es sehr interessant, dass man die Wahrscheinlichkeit für einen „mathematischen Bruch“ so gering einschätzt.

Es gibt zwar viele Verfahren, die seit Jahrzehnten nicht gebrochen sind und heute verwendet werden. Aber auch dort wurden meines Wissens immer wieder Angriffsverfahren entdeckt, die zumindest in einem gewissen Teil des Parameterraums funktionieren, der dann ausgeschlossen werden muss.
Gleichzeitig ist es doch gerade in der Mathematik so, dass Probleme nach Jahren, Jahrzehnten oder gar Jahrhunderten plötzlich durch eine geniale Idee gelöst werden.

Aber eigentlich ist das hier off-topic, da es ja um QC ging. Sorry und trotzdem danke für deine ausführliche Antwort! Damit kratzt du allerdings an der Grenze meines Wissens zu diesen Themen und überschreitest sie auch teilweise. :sweat_smile:

Hört sich super an! Das wäre eine relativ unkomplizierte Umsetzung der Idee.

Mich würde immer noch interessieren, ob diese Idee von Signatur Diversität bei Bitcoin schon einmal diskutiert wurde.

Der Grundgedanke bei den zwei Signaturverfahren wäre ja gerade, dass man sich gegen Einzelfehler schützen kann. Ich bin mir aber nicht sicher, ob das hier ein Problem wäre. Vielleicht kannst du mir da helfen.

Bei den Segwit P2WPKH Adressen wird noch mit SHA256 und RIPEMD160 gehasht. Aber gerade bei den P2WSH Adressen nur noch mit SHA256. Das mag zwar insofern sicherer sein, dass man 256 Bit statt 160 Bit erhält, aber man verwendet eben nur ein einzelnes Hash-Verfahren.

Aber wäre das hier ein Problem? Ich denke nicht. Der Hash des Skriptes hat doch wahrscheinlich nur die Funktion, die Länge zu reduzieren. Könnte jemand SHA256 auf das Skript zurückrechnen, würde er doch auch nur den Skript-Typ und die Public Keys kennen.
Das wäre aber insofern kein Problem mehr, dass wir wegen der zwei Verfahren mindestens zwei unterschiedliche Public Keys verwenden. Man wird also hier nicht auf beide Private Keys zurückrechnen können.

(An anderer Stelle, beim Mining, wäre der SHA256 Bruch natürlich ein Problem. Aber darum geht es ja gerade nicht mehr. Allerdings sollte man sich auch hier nicht von einem Einzelverfahren abhängig machen. Genau wie bei den Signaturverfahren.)

Zu diesem Teil kann ich leider nichts beitragen, weil ich mich immer noch nicht ausreichend mit den Taproot Details beschäftigt habe. Aber danke für die Anregungen!

Falls du irgendwelche Quellen hast, wo man sich gut einarbeiten kann, dann gerne her damit. Anschauliche Prosa-Erklärungen oder die BIPs selbst sind nicht wirklich gut dafür geeignet.

Hier zumindest mein Verständnis:

Als zugrundeliegenden Zahlenraum für die Punkt-Koordinaten verwendet man einen endlichen Körper mit Primzahlordnung p (Ganze Zahlen modulo p), wobei p etwas geringer als 2²⁵⁶, also eine 256 Bit Zahl ist.

Die Punkte auf der Kurve, welche durch die Vielfachen des Generators erreicht werden können, bilden eine zyklische Gruppe und werden als Schlüsselraum für die Public Keys verwendet. Die Ordnung n dieser Gruppe ist hier nur geringfügig kleiner als die des Körpers.

Bei Bitcoin wird Secp256k1 mit folgenden Ordnungen verwendet:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Da die Ordnung n in guter Näherung p und 2²⁵⁶ entspricht, gibt es auch nahezu 2²⁵⁶ PublicKeys. Allerdings gibt es für jeden gültigen PublicKey mit den Koordinaten (x,y) auch einen zweiten gültigen PublicKey mit (x,-y) = (x,p-y) mod p, der zu dem negierten PrivateKey gehört. Den einen Spezialfall y=0 kann man vernachlässigen.
Zu einer x-Koordinate kann es aber auch nicht mehr als zwei PublicKeys geben. Also gibt es für ca. die Hälfte aller möglichen x-Koordinaten keinen gültigen PublicKey.

Bei Taproot werden die PublicKeys nur noch durch ihre x-Koordinate repräsentiert. Die zufällige 256 Bit Zahl, zu der du einen PrivateKey suchst, soll einen gültigen PublicKey darstellen.
Das wird sie aber nach obiger Überlegung nur ungefähr in der Hälfte aller Fälle sein. Ergo müssten ungefähr die Hälfte aller Script Hashes in dem Sinne sicher sein, dass sie keinen gültigen PublicKey darstellen.

Ich hoffe ich rede mich mit meinem Halbwissen hier nicht um Kopf und Kragen. :slightly_smiling_face:

10

Übrigens hier noch ein Nachtrag zum Thema Sicherheit bei bekanntem Public Key.

@stadicus hatte hier vor einem Jahr schon einmal nebenbei erwähnt, dass der PublicKey bei Taproot Transaktionen nicht mehr gehasht wird. Da konnte ich noch nicht so viel mit anfangen.

Er hatte einfach nur das BIP341 zitiert, was man bzgl. Taproot vielleicht doch mal als erstes durchlesen sollte. Hier steht unter „Rationale Nr. 2“:

Quelle: BIP0341: Taproot: SegWit version 1 spending rules

2 . Why is the public key directly included in the output?

While typical earlier constructions store a hash of a script or a public key in the output, this is rather wasteful when a public key is always involved. To guarantee batch verifiability, the public key must be known to every verifier, and thus only revealing its hash as an output would imply adding an additional 32 bytes to the witness. Furthermore, to maintain 128-bit collision security for outputs, a 256-bit hash would be required anyway, which is comparable in size (and thus in cost for senders) to revealing the public key directly.

While the usage of public key hashes is often said to protect against ECDLP breaks or quantum computers, this protection is very weak at best: transactions are not protected while being confirmed, and a very large portion of the currency’s supply is not under such protection regardless.

Actual resistance to such systems can be introduced by relying on different cryptographic assumptions, but this proposal focuses on improvements that do not change the security model.

Der zweite Absatz ist besonders interessant, da er genau unserer Diskussion von oben entspricht.

Außerdem verweist Peter Wuille hier auf einen seiner Tweets (Link „large portion“), in dem er erwähnt dass ca. 5-10 Mio Bitcoin in diesem Sinne aktuell sowieso nicht zusätzlich gesichert sind.
Also Bitcoin auf Adressen, deren Public Key schon bekannt ist, oder alte, ungehashte P2PK Outputs. Das ist schon enorm.

Außerdem würde mich interessieren, was er im dritten Absatz meint. Ist das die gleiche Idee von diversitären Signaturen wie wir sie diskutiert haben?

2 „Gefällt mir“
11

Moin,
ich stelle mir die Frage, ob das Bitcoinnetzwerk durch Quantencomputer zerstörbar ist. Leider kenne ich mich technisch nicht so gut mit Quantencomputern aus, sodass ich mir die Frage leider nicht beantworten kann. Würde mich freuen, wenn es dazu paar Infos gäbe:)

Liebe Grüße

12

Willkomm im Forum!

Bitte immer erst die Suchfunktion nutzen (Lupe rechts oben). :slightly_smiling_face:

→ Suchergebnisse für „Quantencomputer“ - Blocktrainer Forum

Bei weiteren Rückfragen zum Thema Quantencomputer einfach hier bzw. im jeweiligen Thread posten.

2 „Gefällt mir“
13

Obwohl das Thema aus physikalischer Sicht sehr komplex ist und die zukünftigen Entwicklungen kaum einzuschätzen sind, gibt es doch recht viele Leute, die die Fähigkeiten von Quantencomputern entweder stark relativieren oder aber überstrapazieren. Dafür dass es noch viele Wissenslücken gibt sind es oft ziemlich zuversichtliche Standpunkte.

Es gibt keine Sicherheit die alle Zeiten überdauern kann. Niemand kann sämtliche Möglichkeiten der Zukunft vorhersehen. Trotzdem muss man nach dem heutigen Wissenstand Entscheidungen treffen und auch Risiken eingehen. Es ist anders gar nicht möglich.

Ich meine hat jemand mal daran gedacht, das eine intelligente Spezies, die lange genug existiert, irgendwann die Technologie entwickelt um Raum und Zeit zu manipulieren? Dass es möglich ist wissen wir ja dank Relativitätstheorie bereits heute. Es fehlt nur die Technologie um es praktisch nutzen zu können.
Was wenn es in einer solchen Zukunft Recheneinheiten gibt, die in einer raumzeitlich geschlossenen Umgebung laufen, wo die Zeit viel schneller abläuft als in unserer Umgebung. Das würde bedeuten das ein Rechner der beständig genug ist extrem lange dauernde Berechnungen durchführen kann. Der Computer läuft dann in der „Zeitkapsel“ vielleicht Millionen von Jahren aber für uns sind es dann nur ein paare Sekunden oder Minuten. Plötzlich ist der Zeitfaktor dann für eine Berechnung keine große Hürde mehr.

Aber sollen wir heute Bitcoin aufgeben weil in Zukunft möglicherweise Quantencomputer oder in noch fernerer Zukunft Zeitmanipulation ein Sicherheitsproblem darstellen könnten? Sicher nicht. Bitcoin ist vielleicht auch nicht für die Ewigkeit bestimmt. Es ist aber das beste dezentrale Geldsystem was wir heute besitzen.

2 „Gefällt mir“
14

Da hast du Recht.

Dazu gehört aber eben auch, dass man die kontinuierliche Leistungsverbesserung der „normalen“ Computer, sowie komplett neue Technologien im Auge behält.

Hier im Forum wird immer wieder mal behauptet, dass Quantencomputer entweder überhaupt kein Problem seien, oder dass es zumindest noch ewig dauern wird und man sich deshalb keinen Kopf machen müsse.

Die Bitcoin Nutzer müssen sich tatsächlich nicht unbedingt einen Kopf machen. Aber diejenigen, die an der Entwicklung mitwirken, bzw. diejenigen die in der Kryptographie arbeiten, müssen das sogar. Ansonsten werden sie irgendwann in 20 Jahren überrascht und stehen ohne erprobte Lösung da. Wurde aber alles schon weiter oben diskutiert.

Man kann also insofern Entwarnung geben, dass Bitcoin in den nächsten Jahren sehr wahrscheinlich nicht von Quantencomputern bedroht ist. „Sehr wahrscheinlich“, da ich nicht weiß was für Rechner irgendwelche Behörden im Geheimen betreiben.

Gleichzeitig muss man aber jetzt an quanten-resistenten Verfahren arbeiten und tut das auch, da diese vor dem Einsatz noch über Jahre erprobt werden müssen.

Übrigens gehört gerade der Shor Algorithmus zu den ersten bekannten Algorithmen, die nur auf einem Quantencomputer implementierbar sind, und eine Aufgabe wesentlich schneller als ein konventioneller Computer lösen können. Dieser löst das Faktorisierungsproblem und das Diskreter Logarithmus Problem in polynomieller Laufzeit. Genau durch diesen Algorithmus wären z.B. RSA oder ECC nicht mehr sicher, also auch die Bitcoin Kryptographie auf dem aktuellen Stand.

Die heutigen Quantencomputer sind noch viel zu „klein“ und zu teuer. Man bräuchte u.a. wegen der hohen Fehlerrate vermutlich im Bereich von Millionen bis Milliarden Qubits; steht alles im Wikipedia Artikel .

Ich bitte aber jeden vor weiterer Diskussion in diesem Thread, auch erst einmal alle Beiträge zu lesen. Sonst drehen wir uns im Kreis.

2 „Gefällt mir“
15

2 Beiträge wurden in ein neues Thema verschoben: Bitcoin Angriffsvektor durch Manipulation der Raumzeit

16

Ich stimme auch zu, Risiken gibt es immer. Ich vermute, das Risiko, dass ein genialer Mathematiker eine Lösung des Problems der diskreten Logarithmen findet, ist grösser als ein QC - nicht nur in Sachen Wahrscheinlichkeit, sondern v.a. weil es ein plötzliches „Black Swan“ Ereignis wäre, während QC sich über Jahr(zehnte) entwickeln würden. Uebrigens, wenn ein Staat ein QC entwickeln würde, wäre er dumm, damit Bitcoin anzugreifen und die Existenz eines QC zu offenbaren - er würde gescheiter im Verborgenen verschlüsselte Mails im Netz entschlüsseln und abhören - natürlich auch kein beruhigender Gedanke, aber kein Bitcoin Problem. Noch grösser ist übrigens vermutlich das Risiko eines noch nicht entdeckten, schlummernden Bugs im Bitcoin Core Code (hat nix mit QC zu tun). Aber Entwickler müssen sich damit befassen - momentan gibt es eben noch keine brauchbaren quantensichere Alternativen. Die Entwicklungen auf dem Gebiet laufen aber.

Was ich aber noch anmerken möchte und was sich Viele nicht bewusst sind: eine der Hauptunterschiede zwischen klassischen und QC ist, dass klassische Computer „Kopiermaschinen“ sind, und QC „Translationsmaschinen“. QC können QBits eben NICHT kopieren, sondern nur verschieben. Das Original muss dabei zwingendermassen zerstört werden, ein bisschen wie beim Beamer bei Startrek. Deshalb müssen auch neue Algorithmen her. Und merkt ihr etwas? Diese Eigenschaft wäre eine Lösung des Double-Spend Problems. QC würden also gleichzeitig ein Risiko für dezentrales digitales Geld wie BTC darstellen, aber gleichzeitig auch eine Alternative zur Blockchain, die ja vor allem wegen des Double-Spend Problems konstruiert wurde. Ich könnte mir vorstellen, dass man dann die Blockchain auf einem finalen Zustand einfrieren würde (das sichert die Seltenheit), zu jedem Bitcoin-Satoshi des UTXO ein „Quantensatoshi“ erstellt, welches auf seinen finalen Ort im UTXO verweist, und ab da diese Quantensatoshis dezentral nutzt, die sich dann betreffend Double-Spend wie physikalische Objekte verhalten würden, aber mit Lichtgeschwindigkeit über Glasfaser übertragbar wären. Natürlich gäbe es dann noch eine Menge zusätzlicher Probleme (wie bei Münzen) - wie testet man auch Echtheit, und wir würden in unseren Quantenwallets wieder die originären Quantensatoshis aufbewahren statt nur Keys, die wir so auch verlieren könnten, und vor allem ist das Science Fiction. Aber konzeptionell auf jeden Fall interessant.

2 „Gefällt mir“
17

Unabhängig davon, dass es Science Fiction ist, bin ich mir nicht sicher ob das ein Fortschritt wäre. Aus meiner Sicht ist es gerade ein Feature des aktuellen Systems, dass man nur die Keys bzw. eine Mnemonic aufbewahren muss, die man redundant sichern und sogar auswendig lernen kann.

Sobald man wieder echte Münzen, d.h. einmalige Token in einer digitalen Wallet aufbewahren würde, ist das Risiko von Verlust durch Verlieren, Zerstörung oder auch durch Konfiszierung wieder größer. Die verschiedenen Backup Varianten wie Multisig, Split und Passphrase mit ihren Vorteilen stehen dann nicht mehr zur Verfügung.

Aber vielleicht ist das zu klein gedacht und man löst das durch andere Quantenmechanismen. Auf jeden Fall ist es sehr ferne (aber interessante) Zukunftsmusik, dass man Quantenzustände ohne weiteres über lange Zeit und in portablen Geräten erhalten kann.

Weil es hier gut passt (s.u.), würde ich gerne an der Stelle einen YouTube Kanal für alle mathematische Interessierten mit und ohne Vorwissen empfehlen, den ich persönlich seit langer Zeit wirklich exzellent finde:

→ Weitz / HAW Hamburg - YouTube Kanal

Einerseits sind die populärwissenschaftlichen Videos von Prof. Weitz ohne, aber auch mit tieferem Vorwissen sehr unterhaltsam und lehrreich. Immer wird die zugrundeliegende Schönheit der mathematischen Aussagen deutlich, und diese werden im aktuellen, aber auch im historischen Kontext eingeordnet. Es wird eine spannende Geschichte erzählt.

Eine Übersicht findet man neben YouTube z.B. auf seiner Website unter Videos / Populärwissenschaftliche Videos, oder im Speziellen besonders empfehlenswert unter Weihnachtsvorlesungen:

→ Weitz / HAW Hamburg - Website mit Video Übersicht

Wer tiefer einsteigen möchte, findet aber auch Vorlesungen der Mathematik und theoretischen Informatik sowie Videos, die zwischen Populärwissenschaft und Wissenschaft angesiedelt sind.

Zu letzteren gehört z.B. seine neue Reihe über Quantencomputer:

→ Weitz / Playlist Quantencomputer - YouTube

Diese Reihe sollte man eher mit grundlegenden MINT Vorkenntnissen ansehen; ohne Vorwissen ist es schwierig. Dafür erhält man aber eine Einführung, die relativ tief in die Details geht, ohne dass man Physiker sein muss, z.B.:

  • Qubits, Quantenregister, Gatter
  • Verschränkung, No-Cloning-Theorem
  • Grover und Shor-Algorithmus
  • Quantenfehlerkorrektur
4 „Gefällt mir“
18

Da stimme ich dir voll zu, das wäre ein Rückschritt. Es erfüllt aber die Grundbedürfnisse der Dezentralität und nicht-Zensierbarkeit von Zahlungen (was nicht dasselbe wie nicht-Konfiszierbarkeit des Gutes selber ist). Dass das reine Wissen eines Passphrases Zugang zum Gut gibt, ist eigentlich ein „positiver Nebeneffekt“ des Ledgers und kommt auch mit ein paar Nachteilen (z.B. Pseudonymität statt Anonymität) einher. Aber das liegt alles soweit in der Zukunft (ich schätze mal 100 Jahre, wenn überhaupt), dass sich da noch viel tun kann. Ich wollte eigentlich nur auf den Punkt hinaus, dass die Eigenschaft von QC als reine Translationsmaschinen für digitales Geld wie geschaffen zu sein scheint.

Danke für die Youtube Links, da werde ich auf jeden Fall reinschauen!

1 „Gefällt mir“
19

Die Auswirkungen der Quantencomputer auf Bitcoin bleiben unklar:

20

Es bleibt unklar wie lange es noch dauert, bis Quantencomputer den verwendeten Kryptossystemen gefährlich werden. Dass sie es tun werden, ist aber vollkommen klar. Deshalb ja auch die Arbeit an „Post-Quanten“ Alternativen (siehe oben).

Im Artikel steht nichts neues. An den unsauberen und nach meiner Einschätzung teilweise falschen Formulierungen merkt man auch leider, dass die Autoren nichts vom Thema verstehen. Bei finanzen(.)net aber auch nicht verwunderlich.

4 „Gefällt mir“