Ich kann dir leider nicht sagen, was die bedeutenderen Core Entwickler seit Anbeginn von Bitcoin sich dazu gedacht haben. Aber man kann bei diesem Punkt durchaus unterschiedlicher Meinung sein.
Das zusätzliche Hashen bietet meines Erachtens natürlich einen zusätzlichen Schutz ggü. einem Bruch von ECDSA, egal ob durch Quantencomputer oder aktuelle Rechner.
Die Vertreter der Ansicht, zusätzliches Hashen sei unnötig, bestreiten wahrscheinlich nicht diese Aussage an sich. Aber sie sagen die zusätzliche Sicherheit sei aus folgenden Gründen irrelevant:
-
Viele Bitcoins liegen auf Adressen mit schon bekanntem Public Key, d.h. ein ECDSA Bruch würde Bitcoin ins Chaos stürzen und den Wert ins Bodenlose fallen lassen.
-
Spätestens beim Ausgeben eines UTXOs muss der Public Key veröffentlicht werden.
Bei diesen Argumenten könnte man allerdings erwidern:
-
Ein ECDSA Bruch muss nicht dramatisch sein, sondern es könnten im Laufe der Zeit einfach nur immer bessere Angriffe gefunden werden.
D.h irgendwann würde es sich lohnen, die Adressen mit bekanntem Public Key und den meisten Bitcoin mit enormen Rechenaufwand und entsprechenden Kosten anzugreifen. Falls die ersten Angriffe auf „große“ Adressen bekannt würden, aber gleichzeitig auch klar wäre, dass sich ein Angriff bei „kleinen“ Adressen noch lange nicht lohnt, wäre ich mir nicht sicher, ob die Kaufkraft stark leiden würde.
-
Dasselbe Szenario ist auch hier relevant. Bei unbekanntem Public Key oder bei wenig Bitcoin pro Adresse hätte man noch lange Zeit um zu reagieren.
Der Zeitraum zwischen Veröffentlichen und Minen einer Transaktion wäre auch viel zu kurz für einen Angriff.
Lange Rede, kurzer Sinn:
Wenn man nicht von einem ECDSA-Endzeit-Szenario ausgeht, bietet das zusätzliche Hashen sehr wohl eine zusätzliche Sicherheit.
Ich wage auch zu bezweifeln, dass die Kollisionsresistenz ausschließlich von der Länge des Public Keys bzw. der Adresse abhängt. Das wäre nur bei stupiden Bruteforce-Angriffen so.
Ich gehe also mal davon aus, dass ein gehashter Public Key mehr Kollisionsresistenz bietet, als ein ungehashter gleichlanger Public Key.
Die Kollisionsresistenz ist allerdings ohne Hashen besser, ja sogar perfekt, da jeder (gültige) Private Key sicher zu genau einem eigenen Public Key führt.
Bei den Adressen mit RIPEMD-160 Hash ist das soweit ich weiß eine Intention gewesen. Allerdings gilt das nur unter der Prämisse, dass der Public Key im Output schon alleine aus Sicherheitsgründen mindestens einmal gehasht werden soll (z.B. mit SHA-256).
Der Public Key muss immer genau einmal veröffentlicht werden:
- Entweder im Output → Dann braucht man ihn aber später im Input nicht mehr veröffentlichen (Taproot).
- Oder erst später im Input → Dann kann man vorher im Output Platz sparen, indem man den Public Key nochmal hasht.
In Bezug auf die Blockchain Insgesamt würde man also naiv betrachtet am meisten Platz sparen, wenn der Public Key ungehasht im Output steht, und dafür nicht mehr im Input. Somit spart man sich ja auch den zusätzlichen (verkleinerten) Hash.
Allerdings hängt es in der Realität u.a. davon ab, ob in Transaktionen im Gesamt-Durchschnitt mehr Inputs oder Outputs stehen. Die stetig wachsende Anzahl von UTXOs deutet darauf hin, dass es im Mittel mehr Outputs als Inputs gibt. Dieser Faktor läuft also dem vorherigen Argument entgegen.
Wo alles in allem das Optimum für die Blockchain als ganzes liegt und ob es dazu Analysen gibt weiß ich nicht. Ich habe auch sicher Aspekte vergessen, weil ich nicht so tief in Thema drin bin. Eventuell haben ja andere hier mehr Infos: @sutterseba, @Cricktor, @mowtan ?
