Dem ist nichts hinzuzufügen. Sehr gut.
Danke, Super Beitrag, ich habe eine Menge gelernt 
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“
Für mich einer der interessantesten Threads seit Monaten, danke für die interessanten Anregungen!
3 „Gefällt mir“
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?
5 „Gefällt mir“
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.
5 „Gefällt mir“
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. 
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. 
Ü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“
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
Willkomm im Forum!
Bitte immer erst die Suchfunktion nutzen (Lupe rechts oben). 
→ Suchergebnisse für „Quantencomputer“ - Blocktrainer Forum
Bei weiteren Rückfragen zum Thema Quantencomputer einfach hier bzw. im jeweiligen Thread posten.
2 „Gefällt mir“
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.
1 „Gefällt mir“
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“
2 Beiträge wurden in ein neues Thema verschoben: Bitcoin Angriffsvektor durch Manipulation der Raumzeit
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“
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“
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“
Die Auswirkungen der Quantencomputer auf Bitcoin bleiben unklar:
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“
Eventuell auch von Interesse, ein YT Video von einer theoretischen Physikerin, die ich sehr kompetent finde (Sabine Hossenfelder) zu dem Thema QC, natürlich hier nicht direkt mit BTC Bezug: The Quantum Hype Bubble Is About To Burst - YouTube - sie hat allerdings ein bisschen den Ruf, eine „Spielverderberin“ zu sein, genau darum wirkt sie auf mich wahrscheinlich auch kompetent 
Ihr Fazit geht ein bisschen in die Richtung, dass QC momentan extrem gehyped sind und eine Menge der Projekte in diesem Bereich wohl wieder verschwinden werden - quantum winter is coming …
2 „Gefällt mir“
Ich schaue ihre Videos auch sehr gerne.
Bzgl. „Quantum Hype Bubble“ und Quantencomputer hatte ich sie bisher immer so verstanden, dass sie die bekannten potentiellen Vorteile natürlich nicht abstreitet. Also solche Algorithmen wie wir sie hier diskutieren, aber auch andere wie z.B. den Quantenschlüsselaustausch.
Sie stört es nach meinem Verständnis nur, dass zum Einsammeln von Drittmitteln erstens utopische Vorteile skizziert werden, die so vielleicht niemals eintreffen werden, und zweitens die Anwendung mancher Technologien in Bereichen untersucht wird, in denen das Overkill ist und die Kosten in keinem Verhältnis zum Nutzen stehen.
Die sogenannte „Quantum Supremacy“ wird z.B. sicher in spezifischen Anwendungsfällen irgendwann existieren oder existiert schon heute geringfügig.
Allerdings wurde sie von Google ja angeblich vor einigen Jahren schon praktisch demonstriert, wobei der Quantencomputer um viele Größenordnungen schneller gewesen sei als heutige Supercomputer. Abgesehen davon, dass das aber eine rein konstruierte, künstliche Anwendung war, kommt heute langsam heraus, dass man auf Supercomputern mit den richtigen Algorithmen fast genauso schnell gewesen wäre (Quelle).
Diese ständigen Übertreibungen, um sich „besser“ zu präsentieren und Investoren zu überzeugen, nerven einfach, gehören heute aber leider dazu.
Die Diskusion erinnert mich sehr an die Unknown Unknowns und die Known Unknowns.
Viele der Quantencomputer-Vorteile bzw. deren Angriffssenarien sind bekannt aber noch nicht wirklich realisierbar. Wie und wann das realisierbar wird ist unbekannt. das sind die known Unknowns, also die bekannten Unbekannten. Dinge die denkbar/durchdacht sind aber (noch) nicht realisierbar sind.
Dann gibt es die Unknown Unknowns, also Dinge die wir uns noch garnichts vorstellen können, zB. weil uns einfach Wissen fehlt. ZB. wusste vor 200 Jahren noch niemand was ein Schwarzes Loch ist und deswegen konnte noch keiner darüber nachdenken. Oder wie Elektrizität oder Halbleiter funktionieren war im Mittelalter schlicht undenkbar oder hexerei.
Das Problem von Bitcoin ist, dass einige der Sicherheitsmerkmale nicht bewiesenermaßen sicher sind. Beispiel der Hashalgorithmus. Nur weil es noch keiner geschafft hat ihn zu knacken bedeutet das nicht dass dieser nicht knackbar ist. In erster Linie ist das ein bekanntes unbekanntes Problem, da wir darüber Nachdenken können und uns schonmal andere Algorithmen zurechtlegen können für den Fall dass zB: Quantencomputer eine Sicherheitsbedrohung darstellen.
Aber solange wir Algorithmen verwenden, die nicht Bewiesenermaßen sicher sind, dann kann es immer ein unbekanntes und/oder unbedachtes Ereigniss geben, dass die Sicherheit von Bitcoin gefärdet.