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

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: