Re: Wann werden "Bitcoin relevante" Quantencomputer existieren?
Oben in der Abstimmung fehlt "möglicherweise/vielleicht/unentschieden". Ich bin mir nämlich nicht 100%ig sicher, ob Quantencomputer skalieren, d.h. ob beliebig viele verschränkte QBits möglich sind. IrgendwoAuf golem.de las ich mal, dass kontrollierte Quantenverschränkung quadratisch instabil ist (auf golem.de glaube ich, muss das mal raussuchenhttps://www.golem.de/1104/82516.html):
Das bedeutet, dass ein System mit doppelter Anzahl an verschränkten QBits vier mal instabiler ist ...
Wie auch immer, im worst case ist ein Quantencomputer in den nächsten Jahren möglich. Korrekt ist, dass SHA-256 dagegen relativ immun ist (soweit ich weiss). Mit einem Quantencomputer bekommt man keinen relevanten Vorteil beim Versuch SHA-256 umzudrehen (auch hier muss ich die Quelle noch rauskramenhttps://en.bitcoin.it/wiki/Quantum_computing_and_Bitcoin):
Korrekt ist deshalb auch, dass Coins auf Adressen ohne ausgehende Transaktion quantencomputersicher sind. Eine Adresse ist der mehrfach gehashte (SHA-256 und RIPEMD-160) Publickey und ohne ausgehende Transaktion ist dieser nur dem Besitzer des Privatekeys bekannt. Bei ausgehender Transaktion bzw. bei einer Signatur mit dem Privatekey wird der Publickey an ALLE veröffentlicht damit diese die Signatur validieren können, und wenn ECDSA gebrochen ist, dann sind auch die Coins auf der entsprechenden Adresse unsicher.
Die Frage ist für mich, ob das Bitcoin-Protokoll derart geändert werden kann, sodass man Coins nicht verschieben muss, wenn sie auf sicheren Adressen (also solchen ohne ausgehender Transaktion) befinden. Denn wenn ECDSA gebrochen bzw. unsicher ist, und man alle Coins nach einer Protokolländerung verschieben muss, dann sind diese nach einer Transaktion solange unsicher bis die Transaktion nicht in einem Block (besser mehrere) bestätigt wurde. Der Privatekey kann ja dann aus dem Publickey von einem Angreifer berechnet werden, welcher die aktuelle Transaktion, solange diese im Mempool hängt, durch eine andere mit größerer Transaktionsfee ersetzt.
Für eine aktuelle erfolgreiche Transaktion muss erfüllt sein: (1) Der veröffentlichte Publickey muss gehasht die Ausgangsadresse ergeben (öffentlich); und (2) die Signatur der Transaktion muss per Publickey als korrekt verifiziert werden (öffentlich). Die Argumentation im Bitcoin-Protokoll ist dann wie folgt: Aus (2) folgt, dass die Transaktion korrekt signiert ist (und das kann nur die Person mit dem dazugehörigen Privatekey) und zum gegebenen Publickey gehört; Aus (1) folgt, dass dieser Publickey zur entsprechenden Adresse gehört. Und somit wird die Verbindung zwischen Adresse (öffentlich) und Privatekey (geheim) hergestellt.
Wenn ECDSA aber gebrochen bzw. angreifbar ist, dann darf NIE der ECDSA-Publickey veröffentlicht werden!
Nach einer Protokolländerung mit einem quantencomputerresistenten Publickey/Privatekey-Algorithmus (QRA) könnte dies wie folgt aussehen: (0) Der QRA-Publickey darf veröffentlicht werden; (1)
; und (2) die QRA-Signatur der Transaktion muss per QRA-Publickey als korrekt verifiziert werden. Hier sehe ich jetzt nicht, wie eine sichere Verbindung zwischen öffentlicher Adresse und Privatekey hergestellt werden könnte ...
Quote
Allerdings ist so ein Quantenregister ein fragiles System: Die Physiker stellten fest, dass die Störungsempfindlichkeit mit der Anzahl der Teilchen quadratisch zunimmt. Bislang wurde angenommen, dass die Empfindlichkeit linear ansteigt.
Das bedeutet, dass ein System mit doppelter Anzahl an verschränkten QBits vier mal instabiler ist ...
Wie auch immer, im worst case ist ein Quantencomputer in den nächsten Jahren möglich. Korrekt ist, dass SHA-256 dagegen relativ immun ist (soweit ich weiss). Mit einem Quantencomputer bekommt man keinen relevanten Vorteil beim Versuch SHA-256 umzudrehen (
Quote
For example, finding some data which hashes to a specific SHA-256 hash requires 2^256 basic operations on a traditional computer, but 2^128 basic quantum operations. Both of these are impractically large.
Korrekt ist deshalb auch, dass Coins auf Adressen ohne ausgehende Transaktion quantencomputersicher sind. Eine Adresse ist der mehrfach gehashte (SHA-256 und RIPEMD-160) Publickey und ohne ausgehende Transaktion ist dieser nur dem Besitzer des Privatekeys bekannt. Bei ausgehender Transaktion bzw. bei einer Signatur mit dem Privatekey wird der Publickey an ALLE veröffentlicht damit diese die Signatur validieren können, und wenn ECDSA gebrochen ist, dann sind auch die Coins auf der entsprechenden Adresse unsicher.
Die Frage ist für mich, ob das Bitcoin-Protokoll derart geändert werden kann, sodass man Coins nicht verschieben muss, wenn sie auf sicheren Adressen (also solchen ohne ausgehender Transaktion) befinden. Denn wenn ECDSA gebrochen bzw. unsicher ist, und man alle Coins nach einer Protokolländerung verschieben muss, dann sind diese nach einer Transaktion solange unsicher bis die Transaktion nicht in einem Block (besser mehrere) bestätigt wurde. Der Privatekey kann ja dann aus dem Publickey von einem Angreifer berechnet werden, welcher die aktuelle Transaktion, solange diese im Mempool hängt, durch eine andere mit größerer Transaktionsfee ersetzt.
Für eine aktuelle erfolgreiche Transaktion muss erfüllt sein: (1) Der veröffentlichte Publickey muss gehasht die Ausgangsadresse ergeben (öffentlich); und (2) die Signatur der Transaktion muss per Publickey als korrekt verifiziert werden (öffentlich). Die Argumentation im Bitcoin-Protokoll ist dann wie folgt: Aus (2) folgt, dass die Transaktion korrekt signiert ist (und das kann nur die Person mit dem dazugehörigen Privatekey) und zum gegebenen Publickey gehört; Aus (1) folgt, dass dieser Publickey zur entsprechenden Adresse gehört. Und somit wird die Verbindung zwischen Adresse (öffentlich) und Privatekey (geheim) hergestellt.
Wenn ECDSA aber gebrochen bzw. angreifbar ist, dann darf NIE der ECDSA-Publickey veröffentlicht werden!
Nach einer Protokolländerung mit einem quantencomputerresistenten Publickey/Privatekey-Algorithmus (QRA) könnte dies wie folgt aussehen: (0) Der QRA-Publickey darf veröffentlicht werden; (1)
; und (2) die QRA-Signatur der Transaktion muss per QRA-Publickey als korrekt verifiziert werden. Hier sehe ich jetzt nicht, wie eine sichere Verbindung zwischen öffentlicher Adresse und Privatekey hergestellt werden könnte ...