Wenn die Elliptische-Kurven-Kryptografie sicher genug ist, um einen öffentlichen Schlüssel weitergeben zu können, ohne befürchten zu müssen, dass jemand unseren privaten Schlüssel daraus berechnen kann, was ist dann der Grund dafür, unseren öffentlichen Schlüssel für die Verwendung in P2PKH zu hashen?
Mit anderen Worten, was ist der Vorteil eines komplexeren Systems zum Sperren und Entsperren von Bitcoins, wenn eine einfache P2PK-Transaktion sicher genug ist?
Ich bin nicht gegen zusätzliche Sicherheit, aber warum wird sie nicht als überflüssig angesehen?
Der ursprüngliche Grund, warum Adressen Public-Key-Hashes waren, müssen Sie Satoshi fragen. Ich vermute jedoch, dass es nur kürzer und bequemer war (beachten Sie, dass komprimierte öffentliche Schlüssel zu diesem Zeitpunkt noch nicht bekannt waren).
Als komprimierte öffentliche Schlüssel entdeckt wurden, war es einfach einfacher, sich an das bestehende Adressschema zu halten (es erforderte überhaupt keine Änderungen; Wallet- und Node-Software unterstützten bereits komprimierte öffentliche Schlüssel). Es wäre fast unmöglich gewesen, das Ökosystem davon zu überzeugen, ein neues Adressschema einzuführen, das für den Absender teurer war (34 Bytes Ausgabeskript statt 25), wenn man bedenkt, dass die Bereitstellung von P2SH sogar mehrere Jahre gedauert hat.
Ein oft wiederholtes Argument dafür ist der Quantenwiderstand. Ich glaube, das ist nebensächlich. Wir haben keine Ahnung, welche Eigenschaften eine hypothetische Maschine haben wird, die sich auf eine noch zu erfindende Technologie stützt. Angesichts des Ausmaßes der Wiederverwendung von Schlüsseln im Netzwerk (es gibt also Adressen mit bekannten öffentlichen Schlüsseln) ist die Existenz eines Systems, das ECDSA brechen kann, wahrscheinlich ein Todesstoß für Bitcoin. Eine echte Lösung dafür besteht darin, eine echte quantenresistente Kryptographie vorzubereiten und einzusetzen, bevor es zu spät ist. Sich auf die seltsame Hoffnung zu verlassen, dass diese hypothetischen Maschinen irgendwie zu langsam sind, um unbestätigte Transaktionen zu stehlen, bevor sie abgebaut werden, ist ein Ablenkungsmanöver.
Der öffentliche Schlüssel wird zuerst SHA256-gehasht und dann RipeMD160-gehasht. Eine Bitcoin-Adresse ist eigentlich ein verschlüsselter Hash des öffentlichen Schlüssels.
Ein öffentlicher Schlüssel ist 65 Bytes lang (0x04 + 64 Bytes öffentlicher Schlüssel) oder komprimiert 33 Bytes (0x02 | 0x03 + 32 Bytes öffentlicher Schlüssel).
Aber warum nicht RipeMD160 und kürzer machen? Es würde 20 Bytes werden. Natürlich wäre es toll, wenn es kürzer wäre, eine Adresse sollte nicht lang sein.
Warum RipeMD160? Die RipeMD-Kollision wurde 2004 gemeldet ( Ref ), also kann die NSA vielleicht auch RipeMD160 brechen? Also entschied sich Satoshi, es zuerst mit SHA256 und dann mit RipeMD160 zu hashen, was bedeutet, dass es für einen Angreifer viel schwieriger wäre, ein Preimage zu finden, um Bitcoins zu stehlen.
TL;DR kürzere Adressen sowie Schutz für Quantencomputer der fernen Zukunft. (Sogar D-Wave besitzt jetzt keinen Quantencomputer. Es ist ein Quantenglüher. ref )
Was ist der Grund für das Hashing unseres öffentlichen Schlüssels zur Verwendung in P2PKH?
Es gibt keine Verbindung zu ECDSA, außerdem erzeugt ein Privatschlüssel einen Pub-Schlüssel. Aber in der Transaktion würden Sie die Signatur und den Pubkey sehen. Hier sprechen wir also über mehr Privatsphäre (nicht ECDSA-Sicherheit). Wenn ein TX mit einem „Pay to Public Key“ erscheint, dann sieht das TX-Spending-Skript so aus:
ScriptPubKey= <Public Key> OP_CHECKSIG
ScriptSig= <Signature>
während P2PKH dies verwendet:
ScriptPubKey= OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
ScriptSig= <Signature><Public Key>
Im ersten Beispiel sehen Sie den verwendeten öffentlichen Schlüssel beim Generieren der Transaktion (im Feld ScriptPubKey). Miner würden diese Art von TX häufig verwenden. Im P2PKH-tx sehen Sie den Pubkey nur, wenn er ausgegeben wird.
Beachten Sie auch den Unterschied bei den Ausgabebedingungen und fügen Sie eine Sicherheitsebene hinzu. Der Stapel führt das Skript des ScriptPubKey aus, indem er OP_DUPdas letzte Element auf dem Stapel ( ) kopiert ( <Public Key>). Dieser öffentliche Schlüssel wird dann gehasht ( OP_HASH160) und geprüft ( OP_EQUAL). Das bedeutet, wenn Sie diese Transaktion ausgeben möchten, müssen Sie zeigen, dass Sie Ihren öffentlichen Schlüssel (in der ScriptSig) in denselben Hash konvertieren können, den der Absender als Referenz in den tx (den Pubkey-Hash) eingegeben hat. Da Hashes eine Einwegfunktion sind, ist dies nicht umkehrbar und Sie können keine Transaktionen "stehlen". Stellen Sie sich vor, ECDSA wäre irgendwie kaputt, dann ist Hashing noch nicht kaputt ... Sie könnten vielleicht einen TX signieren, aber Sie müssten immer noch den richtigen Hash bereitstellen. Das ist nach heutigem Kenntnisstand unmöglich. Obwohl mit defektem ECDSA alle anderen seltsamen Dinge passieren könnten ...
inersha
pubkeyhash | pubkey, signature) als ein P2PK (pubkey | signature) einnehmen wird, war das Motiv für das Hashing des unkomprimierten Schlüssels, ihn bequemer weiterzugeben?Pieter Wuille