Warum verwendet Bitcoin zwei Hash-Funktionen (SHA-256 und RIPEMD-160), um eine Adresse zu erstellen?

Warum verwenden wir 2 Hash-Funktionen (sowohl SHA als auch RIPEMD), um eine Adresse zu erstellen? Warum nicht einfach eine Hash-Funktion verwenden?

Antworten (3)

RIPEMD wurde verwendet, weil es die kürzesten Hashes produziert, deren Eindeutigkeit noch ausreichend gesichert ist. Dadurch können Bitcoin-Adressen kürzer sein.

SHA256 wird ebenfalls verwendet, da die Verwendung eines Hashs eines öffentlichen Schlüssels durch Bitcoin aufgrund unerwarteter Interaktionen zwischen RIPEMD und ECDSA (dem Signaturalgorithmus für öffentliche Schlüssel) einzigartige Schwachstellen hervorrufen könnte. Das Zwischenschalten einer zusätzlichen und sehr unterschiedlichen Hash-Operation zwischen RIPEMD und ECDSA macht es fast undenkbar, dass es einen Weg geben könnte, Adresskollisionen zu finden, der wesentlich einfacher ist als das Brute-Force-Probieren einer großen Anzahl geheimer Schlüssel.

Im Wesentlichen war es ein Ansatz mit Gürtel und Hosenträgern. Bitcoin musste etwas Einzigartiges tun und anstatt hoffen zu müssen, dass sie es genau richtig gemacht haben, haben sie es überdesignt.

Haben Sie einen Hinweis darauf, warum SHA256 besser mit ECDSA interagiert (oder bekanntermaßen/vermutlich interagiert) als RIPEMD160? Ohne Zitate oder zugrunde liegende Argumente könnte ich dasselbe argumentieren: RIPEMD160 könnte unerwartete Wechselwirkungen mit SHA256 haben. Nehmen wir außerdem an, dass RIPEMD160 kaputt war und nur einen Satz von 100 verschiedenen Hashes generiert hat. Dann wäre es trivial, dies zu brechen. Angenommen, SHA256 war stattdessen defekt. Dann könnten Sie zwei Schlüssel generieren, die denselben Hash haben (und einige Programme hängen möglicherweise davon ab, dass dies nicht möglich ist). Wenn entweder SHA256 oder RIPEMD160 defekt ist, ist dies auch dieses Adressschema?
@HaroldR.Eason Wir wissen, dass RIPEMD160 nicht so kaputt ist, wie Sie es vorschlagen. Die Frage ist, ob es bei Verwendung mit ECDSA möglicherweise beschädigt wird. Aber was Satoshi getan hat, ist SHA256 + RIPEMD160 mit ECDSA, das viel weniger wahrscheinlich kaputt ist. Es ist nicht so, dass einer besser interagiert als der andere, es ist so, dass ein Fehler in der Komposition der beiden fast unmöglich erscheint.
Aber wenn es einen Bruch in SHA256 gibt, um Kollisionen zu erzeugen, dann könnte man zwei Adressen mit demselben Hash konstruieren, wodurch Bitcoin-Adressen kein echter Hash mehr sind. Es ist plausibel, dass sich einige Codes auf die Kollisionsresistenz von Bitcoin-Adressen in ihrem Code verlassen würden, obwohl ich keine kenne.
@HaroldR.Eason stimmte zu. Diese Antwort ist falsch. Eine Kollision in einer der beiden Hash-Varianten erzeugt eine Kollision im zusammengesetzten Hash. Somit verschlechtert die Verwendung von zwei verschachtelten Varianten, wenn überhaupt, die Kollisionsbeständigkeit. Es gibt keinen zweiten Preimage-Sicherheitsvorteil mit einem doppelten Hash .
@HaroldR.Eason Das ist wahr, aber nicht sicher, warum Sie denken, dass dies für diese Frage relevant ist. Ich habe nie gesagt, dass es vor möglichen Brüchen in SHA256 schützt.

Außer Wo wird Double Hashing in Bitcoin durchgeführt?

Warum hasht er also zweimal? Ich vermute, es ist, um Längenverlängerungsangriffe zu verhindern.

SHA-2 leidet wie alle Merkle-Damgard-Hashes unter einer Eigenschaft namens "Längenerweiterung". Dadurch kann ein Angreifer, der H(x) kennt, H(x||y) berechnen, ohne x zu kennen. Dies ist normalerweise kein Problem, aber es gibt einige Anwendungen, bei denen die Sicherheit vollständig aufgehoben wird. Das relevanteste Beispiel ist die Verwendung von H(k||m) als MAC, wobei ein Angreifer leicht einen MAC für m||m' berechnen kann. Ich glaube nicht, dass Bitcoin jemals Hashes auf eine Weise verwendet, die unter Längenerweiterungen leiden würde, aber ich denke, Satoshi hat sich für die sichere Wahl entschieden, dies überall zu verhindern.

Um diese Eigenschaft zu vermeiden, schlugen Ferguson und Schneier vor, SHA256d = SHA256(SHA256(x)) zu verwenden, wodurch Angriffe mit Längenerweiterung vermieden werden. Diese Konstruktion hat einige kleinere Schwächen (nicht relevant für Bitcoin), daher würde ich sie nicht für neue Protokolle empfehlen und stattdessen HMAC mit konstantem Schlüssel oder abgeschnittenem SHA512 verwenden.

Beantwortet von CodesInChaos

Ich formuliere meine Frage um. RIPEMD wird auch verwendet, um die Adresse zu erstellen, meine Frage ist, warum wir RIPEMD und SHA verwenden, warum nicht nur SHA verwenden?
Richtige Antwort, aber auf eine andere Frage. ;)
Längenerweiterungsangriffe sind in Bitcoin unmöglich, da Längenerweiterungsangriffe nur dort angewendet werden, wo die gehashten Daten geheim sind. Diese Antwort ist falsch.

Hier ist eine hochspekulative Idee, die weder endgültig noch sicher ist. Dies ist jedoch der einzige plausible Grund, den ich in Betracht gezogen habe, da ich die unvorstellbare Annahme zurückweise, dass Satoshi die Angriffe auf Längenverlängerung missverstanden oder „nicht darüber nachdenken musste“ . Längenerweiterungsangriffe sind in Bitcoin offensichtlich unmöglich, da Längenerweiterungsangriffe ( in Bitcoin niemals zutreffen und) nur dort gelten, wo die gehashten Daten geheim sind. Es ist für mich nicht nachvollziehbar, dass Satoshi so schlampig gewesen wäre. Obwohl durch die Verwendung des doppelten Hash überall (vgl) beabsichtigte er angeblich, uns zu dieser harmlosen Erklärung zu verleiten (dh uns genug Seil zu geben, um uns damit aufzuhängen). Das heißt, wenn er, wie ich spekuliere, nur eine Verwendung für den doppelten Hash für die Ausgabenfunktion hatte.

Außerdem erhöht doppeltes Hashing weder die Sicherheit gegen Kollisionen noch Second-Preimage - Angriffe, vgl . auch .

Stellen Sie sich also vor, dass 256-Bit-ECDSA in Zukunft realistisch nutzbar ist. Zwei Szenarien: 1) alle UXTOs sind trivial und kostengünstig ausnutzbar; oder vielleicht zuerst 2) nur hochwertige Ausgaben sind angesichts hoher Rechenkosten kosteneffektiv verwertbar.

Im letzteren Fall kann kein Gegner sicher sein, nicht von einem Konkurrenten in Bezug auf den Beuteprozentsatz, den er den Minern zusprechen muss, untergraben zu werden, da der Miner, der den Block gewinnt, die (gegnerische, Beutegraberei) Ersatztransaktion mit den höchsten Gebühren übernimmt . (Naive Leser sollten beachten, dass der Miner nicht zwischen einer gegnerischen und einer Transaktion ohne Beutegrab unterscheiden kann.) Dies scheint ein Gefangenendilemma zu sein, es sei denn, in dem scheinbar unwahrscheinlichen Fall können die Miner einen Konsens von 50+% Oligarchie bilden, um diese Beute durchzusetzen Prozentsatz, wobei alle Minderheits-Hashrate-Blöcke abgelehnt werden, die defekt sind. Man könnte argumentieren, dass der hoch bewertete einzige Szenario-Exploit die Bildung dieser Oligarchie erzwingt, aus Angst vor einem Modellscheint den Verlust der Kompatibilität der Anreize zu zeigen, die normalerweise auf eine einzelne längste (dh höchste Schwierigkeit) Kettenregel konvergiert. Aber Bergleute werden wahrscheinlich nicht ihre nicht wiederverwendbaren, versunkenen Mining-Hardware-Investitionen zerstören, noch hätten Hodler einen Anreiz, auf diesen Prozentsatz ihres ₿ zu verzichten, aus Gründen, die ich unten erkläre.

In beiden Szenarien gibt es UXTOs, die nicht ausgegeben werden können, ohne gestohlen zu werden, es sei denn, das Bitcoin-Validierungsprotokoll wird geändert, um Ausgaben mit einem nicht ausnutzbaren NIZKP (Beweis) eines der Urbilder des Hashs anzubieten .RIPEMD160(SHA256)

(HINZUGEFÜGT: Naive Leser bemerken, dass die Kompromittierung von ECDSA die stationären nicht ausgegebenen Transaktionsausgaben (UXTO) nicht beeinträchtigt, wenn die Hash-Funktion nicht ebenfalls beeinträchtigt wird. Diese UXTOs würden durch eine Drohung gestrandet, sie mit dem postulierten zukünftigen ECDSA-Exploit zu stehlen, wenn und iff Spend-Transaktion wird im Netzwerk veröffentlicht, da sie den öffentlichen ECDSA-Schlüssel offenbart, der ansonsten bis zur Ausgabe durch den Hash verdeckt und geschützt ist.)

Ich habe auch eine Alternative in Betracht gezogen, bei der der Zahler zuerst mit einer niedrigwertigen (entweder nicht kosteneffektiv ausnutzbaren oder im ersten der oben genannten Szenarien durch den Miner außerhalb des Bandes mit farbigen Münzen anregenden Transaktion, sich nicht für die gegnerische Transaktion zu entscheiden) in die Blockchain aufzeichnet bei nullwertigen Outputs [1] oder OP_RETURN(vgl. Beispiel )[2] die hash(preimage||txn_hash)vor der Veröffentlichung erfolgende Finalisierung (dh Nachweis) der ansonsten höherwertigen verwertbaren Transaktion.

Obwohl beide Ideen ausreichen würden, wenn Satoshi nur einen einzigen Hash verwendet hätte, wollte Satoshi möglicherweise nicht von einem umstrittenen politischen Ergebnis (z. B. der Kontroverse um die Blockgrößenbegrenzung ) für die Änderung des Layer-Zero-Protokolls abhängen, um die Ausgaben nicht zu halten Geisel zwischenzeitlich. Die Miner würden sich wahrscheinlich jeder Lösung widersetzen, und wenn ich die tendenziöse Tatsache zum Ausdruck bringen darf, dass die 1%, die normalerweise entscheiden (weil die unantastbare Machtgesetz-Vermögensverteilung keine Ausnahmen hat), in beiden oben genannten Szenarien machtlos wären (und somit ein Machtvakuum öffnen würden).des fraktionierten Analogons von Warlord Chaos), wenn ihr UTXO nicht ausgegeben werden kann, ohne gestohlen zu werden. Mit anderen Worten, das Nash-Gleichgewicht ist so, dass Änderungen am Layer-Zero-Protokoll nur dann stabil sind, wenn die Interessen der wirtschaftlichen Mehrheit (dh der 1%) keine bessere Strategie haben. In dem unvorstellbaren Fall, dass Satoshi verfallen genug wäre, um so zu entwerfen, dass die 1 % vollständig veräußert werden könnten, würden die Miner zusammen mit Bitcoin zerstört werden .

Wenn stattdessen meine zweite Idee für die Exploit-Umgehung auf das Zwischen-Preimage des zusammengesetzten Hashs angewendet wird RIPEMD160(preimage||txn_hash), also eine ad hoc farbige MünzeAusgaben sind sofort möglich (und werden von der Schelling-Punkt-Konvention als einzige Option übernommen), ohne dass eine Änderung am Layer-Zero-Validierungsprotokoll erforderlich ist, das die Miner durchsetzen. Bei der Ausgabe mit dem Zwischen-Preimage wurde dann der ausnutzbare öffentliche ECDSA-Schlüssel niemals preisgegeben, wenn der Zahler seine öffentlich erhaltenen Ausgaben mit einem geheimen öffentlichen Schlüssel an sich selbst ausgegeben hatte, bevor der ECDSA-Exploit eintraf. Der doppelte Hash ist nur erforderlich, wenn der Zahler einen gewissen Anreiz hat, den öffentlichen Schlüssel (anstelle des genannten Zwischenprodukts) nicht als Urbild zu veröffentlichen, um die Ausgabe der farbigen Münze abzuschließen (dh zu beweisen). Diese farbigen Münzen bleiben nicht verwertbar und behalten daher wahrscheinlich trotzdem ihren Wert. Die Aussicht auf einen zukünftigen Hard Fork, der die Fähigkeit wiederherstellt, ₿ ungenutzt auszugeben,

Ich war motiviert, diese Idee als teilweise Widerlegung von Craig „Faketoshi“ Wrights unbegründeter Behauptung heraufzubeschwören , er habe den Grund für den doppelten Hash erklärt. Das heißt, wenn meine Idee das Kreuzverhör durch die breite Gemeinschaft übersteht.

[1] Nicht zu verwechseln mit öffentlichen Blackhole-Schlüsseln .

[2] Ignorieren Sie folgendes Gelaber: Nebenbei , damit ich nicht von der 1%-Wirtschaftsmehrheit, die die Wahrheit kennt, lächerlich gemacht werde, aber bitte, wenn Sie ein Gewissen haben, sollte Folgendes bei der Entscheidung, ob Sie zustimmen oder nicht zustimmen, nicht berücksichtigt werden Mit meiner Antwort ist meine persönliche Meinung, dass es OP_RETURNsich um eine ungültige Gabel handelt , die irgendwann zerstört wird .

Übrigens, ein verlinktes Video , in dem Faketoshi alle überprüfbaren technologischen Details für seinen mit der Hand winkenden, nichtssagenden Wortsalat vermied.
Ich plädiere dafür, dass intelligente Leser alle politisch motivierten Ablehnungen ignorieren , dh alle, die nicht mit einem sachlichen Kommentar untermauert sind, der erklärt, warum die Antwort falsch oder nicht relevant für die Frage ist.