Die Gebühren sind niedrig? Macht eure Coins privater und (fast) quantensicher!

[Lakai01]

letzens hat Chaincode einen sehr aktuellen bericht zu dem thema Bitcoin und quantencomputer veröffentlicht
der besagte bericht ist 55 seiten lang und leider auch nur in englischer sprache verfügbar: https://chaincode.com/bitcoin-post-quantum.pdf

Danke für den Link!
Tools wie Grok oder ChatGPT können mittlerweile übrigens PDFs sehr gut zusammenfassen und übersetzen. Man braucht dort nur das PDF eingeben und per Prompt um Übersetzungen/Zusammenfassungen bitten.

Die Hauptbedrohung aus dem PDF wurde auch hier durch d5000 bereits angesprochen:

🔐 Hauptbedrohung: Exponierte öffentliche Schlüssel
Bitcoin-Adressen, deren öffentliche Schlüssel bereits offengelegt wurden – beispielsweise durch Adresswiederverwendung oder bestimmte Skripttypen aus der Satoshi-Ära – sind besonders anfällig für Quantenangriffe. Schätzungen zufolge könnten etwa 6,26 Millionen BTC (ca. 650 Milliarden US-Dollar) gefährdet sein. Diese Gefahr betrifft insbesondere große institutionelle und Börsenbestände

Quelle: Übersetzung aus ChatGPT

Auch die möglichen Migrationsstrategien sind recht interessant, vor allem hinsichtlich des Konklusios:

🔄 Migrationsstrategien
Die Umstellung auf quantensichere Systeme erfordert:

UTXO-Migration: Übertragung von Guthaben auf neue, quantensichere Adressen.

Commit-Delay-Reveal-Mechanismen: Verzögerte Offenlegung von Transaktionsdetails zur Erhöhung der Sicherheit.

Soft-Fork-Aktivierungen: Einführung neuer Funktionen ohne vollständige Netzwerkspaltung.

Eine koordinierte Vorbereitung aller Beteiligten – Entwickler, Börsen, Wallet-Anbieter und Nutzer – ist essenziell.

Quelle: Übersetzung aus ChatGPT

Gerade der letzte Satz wird hier sicherlich spannend, die Entwickler-Community ist ja eher etwas ... schwierig ... und sehr änderungsresistent. Solche Vorhaben sollten also lieber besser heute als morgen in die Wege geleitet werden um nicht unnötig verzögert zu werden wenn die Zeit dann mal tatsächlich drängt.

[bct_ail]

In besagtem Faden wurde auch die Möglichkeit erwähnt, mit einem 13ten Wort, das an die Seedphrase angehängt wird, sozusagen eine Seed für mehrere Wallets (ich meine es sind 2048 Wörter, also bis zu 2048 "Unter-Wallets") zu verwenden. Zumindest die Frage der Aufbewahrung der Seed bei vielen NoKYC-Wallets wäre damit gelöst.

Wie ist das genau gemeint? Seed A von Wallet 1 wird mit 13ten Wort "Wallet1" verlängert, für Wallet 2 nehme ich wieder den Seed A und hänge als 13tes Wort "Wallet2" ran, usw. ?

Beim rumprobieren mit Electrum ist mir wieder eingefallen, dass man auch nur den private key einer Adresse importieren kann. Wenn man also ein Wallet offline erstellt und dann auf einem anderen PC (oder VM) Electrum installiert und dort nur den private key von einer Adresse importiert, so werden  ja niemals alle sonst angezeigten Adressen auf den externen Server übertragen.
Einziger Nachteil ist, dass das Wechselgeld auf die importierte Adresse geschickt wird. Das sollte man dann natürlich gleich zu einer anderen Adresse weiterschicken.

Falls es zu Off-Topic wird, können wir auch gerne im Electrum Thread weiter diskutieren.

[d5000]

Wie ist das genau gemeint? Seed A von Wallet 1 wird mit 13ten Wort "Wallet1" verlängert, für Wallet 2 nehme ich wieder den Seed A und hänge als 13tes Wort "Wallet2" ran, usw. ?

Ja genau. Die entsprechende Funktion findest du wenn du mit Electrum eine neue Wallet erstellst und die Seed zum ersten Mal siehst, unter "Options". Dort bei "Extend the seed with custom words" Haken setzen. Die Wörter werden aber erst im nächsten Schritt eingegeben und bei der Wiederholung wird auch beides separat eingegeben. Für die zweite Seed "I already have a seed" angeben, Seed A eingeben und dann das Zusatzwort genauso wie bei der ersten Wallet eingeben und bestätigen.

Ich habe das ganze dann gecheckt und es gibt zwei unterschiedliche Sets von Adressen.

Beim rumprobieren mit Electrum ist mir wieder eingefallen, dass man auch nur den private key einer Adresse importieren kann. Wenn man also ein Wallet offline erstellt und dann auf einem anderen PC (oder VM) Electrum installiert und dort nur den private key von einer Adresse importiert, so werden  ja niemals alle sonst angezeigten Adressen auf den externen Server übertragen.

Das stimmt, interessante Idee. IMO kann man das auch auf dem gleichen PC tun, wenn man die Haupt-Wallet immer nur bei abgeschaltetem Internet aufruft (ist aber vielleicht nicht zu empfehlen ... es sei denn man bereitet alle Unter-Wallets schon im Voraus vor).

Ich denke trotzdem die Idee mit dem 13ten Wort ist weniger fehleranfällig (man läuft nicht Gefahr versehentlich die Wallet mit Internetverbindung aufzurufen) und du hast auch immer frische Wechselgeld-Adressen. Nur dass man die halt als zusammengehörig ansehen muss.

Einziger Nachteil ist, dass das Wechselgeld auf die importierte Adresse geschickt wird. Das sollte man dann natürlich gleich zu einer anderen Adresse weiterschicken.

Beziehungsweise einen zweiten Output mit "Pay to Many" hinzufügen (ist usability-mäßig bei Electrum nicht so toll gelöst, geht aber) und das Wechselgeld dorthin schicken. Man müsste dann natürlich die Adressen außerhalb von Electrum verwalten und am besten das irgendwie automatisieren ... da scheint mir fast eine Funktion wie in meiner möglichen Feature Request vorgeschlagen selbst zu programmieren einfacher zu sein ...

PS: Denke dass die Diskussion hier gut aufgehoben ist, bei anderen HD-Wallets gibt es ja die gleichen Privacy-Probleme und Lösungen, nur Interface ist halt anders.

[Etiquette.exe]

Guten Morgen d5000,

ich richte diese Frage mal an dich, weil ich grad vom Thema "Euer bester Ratschlag für Kryptowährungen" komme und da hast du diesen Ratgeber verlinkt und der hat sofort mein Hirn in Bewegung gesetzt. 

2) Wenn du die Coins von einer Adresse ausgibst, legst du deinen öffentlichen Schlüssel für diese Adresse offen und speicherst ihn in der Blockchain. In der Zukunft könnte dies Angreifern mit Quantencomputern ermöglichen, den privaten Schlüssel mit dem öffentlichen Schlüssel zu berechnen und deine Coins zu stehlen! [2] [3]

Ich würde jetzt mal sagen, dass ich schon ein bisschen was weiß über Bitcoin und Blockchain. Ich weiß zwar nicht viel über Quantencomputer, auch wenn es mich interessiert und ich auch darüber lese, aber da gehen die Meinungen so sehr auseinander und ich selbst habe Probleme, das einzuordnen.

Diese zitierte Stelle hat mich aber schon sofort aufhorchen lassen! Warum kann ein Hacker oder jemand anders denn eine Adresse nur entdecken, wenn ich von der Adresse etwas ausgegeben habe? Es ist doch bestimmt möglich, dass man die Blockchain scraped für alle Wallets größer 0 und dann sortiert und dann Ziele definiert. Dann habe ich doch sowieso sämtliche öffentliche Schlüssel oder wo ist jetzt mein Fehler?

Es stimmt, dass man mich ganz persönlich dann nicht so einfach identifizieren kann, aber meine persönliche "ID" ist doch sozusagen gar nicht notwendig, um Quantumberechnungen auf einen öffentlichen Schlüssel anzuwenden, der öffentlich für jeden einsehbar entsprechende Bitcoin Bestände enthält? Irgendwo reißt bei mir da der logische Faden.   

"Wenn du die Coins von einer Adresse ausgibst, legst du deinen öffentlichen Schlüssel für diese Adresse offen"

Ist nicht jede generierte Adresse bzw. jede Adresse die Bitcoin hält oder hielt automatisch öffentlich erfasst?

Ich bin wirklich auf die Antwort gespannt, ich nehme immer wieder gern was mit bzgl. der Bitcointhematik. Ich bin zwar ein Nerd und habe auch mal Wirtschaftsinformatik in der Universität gehabt, aber Bitcoin ist dann doch ein bisschen komplexer.

VG,
Chris

[d5000]

Diese zitierte Stelle hat mich aber schon sofort aufhorchen lassen! Warum kann ein Hacker oder jemand anders denn eine Adresse nur entdecken, wenn ich von der Adresse etwas ausgegeben habe? Es ist doch bestimmt möglich, dass man die Blockchain scraped für alle Wallets größer 0 und dann sortiert und dann Ziele definiert. Dann habe ich doch sowieso sämtliche öffentliche Schlüssel oder wo ist jetzt mein Fehler?

Dein Missverständnis liegt wahrscheinlich darin, dass die Adresse nicht genau dasselbe ist wie der öffentliche Schlüssel (Pubkey, siehe dazu falls nicht bekannt Asymmetrisches Kryptosystem). Die Adresse wird aus dem öffentlichen Schlüssel mit mehreren Hashing-Schritten erstellt [1]. Es ist aber selbst mit Quantencomputern nicht einfach so [2] möglich, von einer Adresse aus den öffentlichen Schlüssel "zurück" zu errechnen, und mit einem konventionellen Computer wohl in Jahrmillionen nicht.

Und aus der Adresse direkt können Quantencomputer auch keinen privaten Schlüssel errechnen. Aus dem vollständigen öffentlichen Schlüssel hingegen wahrscheinlich schon (irgendwann, in ob eher in Jahren, Jahrzehnten oder Jahrhunderten ist nicht ganz klar, ich tippe auf zweiteres).

Wenn du nun Bitcoins verschickst, wird in der Transaktion der öffentliche Schlüssel vollständig gespeichert -- als Teil der digitalen Signatur -- und landet damit nach der ersten Bestätigung in der Blockchain. Das heißt, von jeder Adresse, von der einmal auch nur ein einziger Satoshi verschickt wurde, ist der öffentliche Schlüssel einsehbar. Wenn eine Adresse aber nur Bitcoins empfängt, ist eine solche Signatur von dieser Adresse nicht vorhanden, und daher kein öffentlicher Schlüssel in der Blockchain.

Wenn du also Adressen niemals wiederverwendest, dann hat ein Quantenangreifer nur eine Chance: den öffentlichen Schlüssel genau dann abzugreifen, wenn du die Coins verschickst und daraus in ~10 Minuten (bis zur ersten Bestätigung) den privaten Schlüssel zu errechnen und deine Transaktion zu ersetzen. Das dürfte wesentlich weiter in der Zukunft liegen als der Fall, dass ein Angreifer lukrative Adressen aus einem Blockexplorer heraussucht, die bereits zum Senden verwendet wurden oder anderweitig den öffentlichen Schlüssel preisgegeben haben [3], und darauf tage- bis jahrelang seinen Quantencomputer ansetzt.

Gerne weiterfragen, falls noch was unklar ist!


[1] wenn du dich mit "Hashing" nicht auskennst: es sind einfach mehrere Rechenoperationen, die auf den öffentlichen Schlüssel angewendet werden, die aber nur in eine Richtung funktionieren. Man kann sich das ähnlich vorstellen wie verlustbehaftete Kompression von Daten: wenn du ein PNG-Foto zu JPEG komprimierst, kannst du nachher zwar ein dem Originalfoto ähnliches Foto ansehen, aber nicht das PNG-Originalfoto zurück errechnen lassen.

[2] Quantencomputer können das zwar mit Grovers Algorithmus schneller, aber sind dabei auch in mehreren Jahrzehnten oder Jahrhunderten immer noch vermutlich zu langsam, um das in absehbarer Zeit (maximal Jahre) hinzukriegen.

[3] das kann bei einigen Transaktionsverfahren vorkommen, z.B. dem inzwischen veralteten P2PK ("Pay to Public Key"), mit dem beispielsweise Satoshis geminte Coins (und generell die meisten geminten Coins der ersten Jahre) ausgezahlt wurden.

[cygan]

jetzt ist ein guter zeitpunkt um ein utxo-management zu machen!
denn momentan ist der mempool eer und die Gebühren liegen bei 0,10 sat/vb

 

[Lafu]

jetzt ist ein guter zeitpunkt um ein utxo-management zu machen!
denn momentan ist der mempool eer und die Gebühren liegen bei 0,10 sat/vb

Auch wenn das ein gut Information ist cygan ändert sich sich das Stündlich und ist abhängig von der Exchange oder wo du Coins hin sendest.
Meine Empfehlung hier ist sich einen Coin raus zu Suchen der eventuell für Transaktionen geringe Kosten verursacht wie zb DogeCoin in der Verganheit.
Keine Ahnung ob dieser momentan immer noch für dies der Richtige ist da ich schon lange keine Transaktion mehr darüber gemacht habe.

[Real-Duke]

Auch wenn das ein gut Information ist cygan ändert sich sich das Stündlich und ist abhängig von der Exchange oder wo du Coins hin sendest.

Hier steht im Vordergrund die Coins günstig an sich selbst zu schicken und nicht an eine Exchange
Manchen Menschen fällt sowas erst ein wenn die Gebühren (wieder) bei 30€ pro Byte liegen und jammern dann rum.

Daher jetzt Adressen mit mehreren Inputs gesund schrumpfen und bei der nächsten Gebührenschlacht nicht ganz so stark bluten wie viele andere.

[Lafu]

Hier steht im Vordergrund die Coins günstig an sich selbst zu schicken und nicht an eine Exchange
Manchen Menschen fällt sowas erst ein wenn die Gebühren (wieder) bei 30€ pro Byte liegen und jammern dann rum.
Daher jetzt Adressen mit mehreren Inputs gesund schrumpfen und bei der nächsten Gebührenschlacht nicht ganz so stark bluten wie viele andere.

Ich finde jetzt nicht das dies nur gut ist wenn man Coins an sich selbst schicken möchte.
Allgemein denke ich das man sich hier bestimmt einige Transaktionskosten spart , klar hat man bisschen mehr Streß diese wieder in Bitcoin umzuwandeln.
Ich selbst habe auch lange gebraucht um dies zu verstehen , dennoch bleibe ich dabei das man hier günstiger fährt.
Man kann natürlich auch andere Coins nutzen für das ganze vorhaben.

[d5000]

In diesem englischen Thread ab dem verlinkten Post findet ihr einige Infos wie Transaktionen unter 1 sat/vbyte bestätigt werden können. Kurzfassung: am besten direkt zu den Minern senden, ihr findet im Faden einige Links dazu, z.B: https://mempool.space/tx/push.

Ein Problem ist auch, dass zumindest über das grafische Standard-Interface einige Wallets wie Electrum eine solche Transaktion erst gar nicht erlauben, zu erstellen. Hier steht, dass es mit dem "Pay to many" Feature bei Electrum funktioniert. Ich werde es demnächst mal selbst ausprobieren, wenn ich wieder UTXOs zum konsolidieren habe.

[Coiner.de]

Die neue Trezor Suite 25.8.2 kann jetzt direkt Transaktionen mit Gebühren unter 1 sat/vbyte erstellen und senden.
Aber aufpassen, das haben Sie beim RBF "Speed up" noch vergessen und kann dann teuer werden.
Vorher bei https://mempool.jhoenicke.de/#BTC,24h,weight,0.2 die Lage prüfen. Heute gehen 0,4 sat locker durch.

[d5000]

Aber aufpassen, das haben Sie beim RBF "Speed up" noch vergessen und kann dann teuer werden.

Danke für die Info. Aber vielleicht bedarf dieser Teil einer Erklärung. Was genau kann "teuer werden"? Ist gemeint, dass die Transaktion am Ende doch festsitzt und man dann doch gezwungen ist, per RBF die Gebühr zu erhöhen? Eigentlich sind ja die "etwas höheren" Gebühren die wir zeitweise sehen (2-3 sat/vByte) immer noch traumhaft, wenn wir sie mit 2023/24 vergleichen.

[Coiner.de]

Erwischt! Ich habe mir hinterher auch gedacht, dass ich da noch einen Satz zur Erklärung hätte schreiben sollen.

Beim "Speed up" kann man auch bei erweiterten Optionen minimal nur 1 Satoshi einstellen. Man kann also die zu optimistische 0,1 sat/vbyte nicht durch realistischere 0,4 sat/vbyte ersetzen.

Aber, ja, immer noch günstig bei 1 sat/vbyte.

[ptrk]

2) Wenn du die Coins von einer Adresse ausgibst, legst du deinen öffentlichen Schlüssel für diese Adresse offen und speicherst ihn in der Blockchain. In der Zukunft könnte dies Angreifern mit Quantencomputern ermöglichen, den privaten Schlüssel mit dem öffentlichen Schlüssel zu berechnen und deine Coins zu stehlen! [2] [3]

Es gibt eine einfache Lösung: Verschiebe die Coins auf den wiederverwendeten Adressen einfach auf eine neu generierte Adresse! Sowohl Bitcoin Core als auch die beliebten SPV-Wallets wie Electrum oder Sparrow bieten einfache Möglichkeiten, dies zu tun.

Mal eine Frage zu dem Punkt: Die Bitcoin Adresse ist doch eine Ableitung bzw. quasi Verkürzung des öffentlichen Schlüssels. Ist es nicht möglich davon auf dem eigentlichen öffentlichen Schlüssel zu schließen? Davon bin ich eigentlich immer ausgegangen, dass die BTC-Adresse nur eine Vereinfachung dessen ist. Falls dem so sei, dann wäre es doch egal, ob man eine Transaktionen ausführt, die dann den ganzen öffentlichen Schlüssel freilegt, da über die BTC-Adresse die Bitcoin enthält und in der Chain ist, auch darauf geschlossen werden kann  

[d5000]

Mal eine Frage zu dem Punkt: Die Bitcoin Adresse ist doch eine Ableitung bzw. quasi Verkürzung des öffentlichen Schlüssels. Ist es nicht möglich davon auf dem eigentlichen öffentlichen Schlüssel zu schließen?

Nein, und das ist so natürlich gewollt.

Ich kenne die Details der Mathemathik dahinter nicht, aber es ist bei Hashes gerade so, dass es sich grundsätzlich um eine Einbahnstraße handelt, also man kann nur vom öffentlichen Schlüssel auf die Adresse schließen.

Eine Adresse wird generiert, indem mehrmals SHA-256 und RIPEMD-160 - Hashoperationen auf den öffentlichen Schlüssel ausgeführt werden.

Was es allerdings gibt, sind sogenannte Kollissionen - d.h. es gibt mehrere mögliche öffentlichen Schlüssel, die zur gleichen Adresse gehören können. Bei der extremen Anzahl möglicher Adressen fällt dies aber nicht ins Gewicht. (2¹⁶⁰).

Es gibt übrigens wesentlich mehr mögliche Private Keys / Public Keys (2²⁵⁶) als Adressen (das ist auch der Grund für die Kollisionen). Die Anzahl der privaten Schlüssel ist größer als die Atome im Universum, während die der Adressen "nur" die aller Sandkörner auf der Erde entspricht (so formuliert es zumindest Google).

[Lakai01]

Ich kenne die Details der Mathemathik dahinter nicht, aber es ist bei Hashes gerade so, dass es sich grundsätzlich um eine Einbahnstraße handelt, also man kann nur vom öffentlichen Schlüssel auf die Adresse schließen.

Die Mathematik dahinter ist ECDLP = Elliptic Curve Discrete Logarithm Problem.

Vereinfacht erklärt ist das so:
Der Private Key ist eine Zufallszahl, bspw. 256 Bit.
Der Public Key entsteht nun dadurch, dass man als Grundlage eine elliptische Kurve nimmt. Diese hat einen festen Startpunkt G. Du nimmst nun deinen Private Key k und berechnest k * G, was außerordentlich einfach ist und gleichzeitig auch einen Punkt auf dieser Kurve ergibt ... das ist der Public Key P.

Das Rückwärtsrechnen, also von P auf k, ist mit derzeitigen technischen Mitteln nicht möglich. Es gibt zwar Angriffsmuster wie Pollards Rho, diese sind aber exponentiell in der Bit-Länge. Bei unserem 256 Bit Schlüssel ist das quasi unmöglich zu berechnen - derzeit.

[ptrk]

Es gibt übrigens wesentlich mehr mögliche Private Keys / Public Keys (2²⁵⁶) als Adressen (das ist auch der Grund für die Kollisionen). Die Anzahl der privaten Schlüssel ist größer als die Atome im Universum, während die der Adressen "nur" die aller Sandkörner auf der Erde entspricht (so formuliert es zumindest Google).

Danke für die Erklärung

Noch ein kleiner Exkurs:
Für jemand der eine Art Astronomie-Nerd ist, kann ich die letzen beiden Sätze so nicht stehen lassen Die Anzahl entspricht ungefähr dem Teil des Universum, den wir sehen können, auch das beobachtbaren Universum genannt. Da sich aber das Universum immer schneller ausdehnt, die Lichtgeschwindigkeit aber begrenzt ist, erreicht uns von einem immer größer werdendem Teil des Universums kein Licht mehr. Von diesem unbeobachtbaren Teil wird angenommen, dass es ein Vielfaches größer ist als das was wir sehen können. Somit trifft 2²⁵⁶ nur auf ein relativ kleinen Teil des Universums zu  

[d5000]

Die Mathematik dahinter ist ECDLP = Elliptic Curve Discrete Logarithm Problem.

Das stimmt zwar für den Public/Private-Key, aber nicht für die Adressen, die mit mehreren Schritten SHA-256 und RIPEMD-160 berechnet werden und dann am Ende noch in das Adressformat, also entweder Base58 (legacy) oder bech32 konvertiert werden.

Da mich das gerade mal interessiert hat habe ichs mir mal angeschaut wie diese Algorithmus arbeitet. Der Wikipedia-Artikel dazu ist auch eher was für Mathematiker.  

SHA-256 (eine Variante von SHA-2 mit 256 bits) ist ein fünfstufiger Prozess bei dem das Ziel ist, dass der Hash (also das Resultat der Rechenoperation) genau 256 Bit hat.

1) Zuerst wird an die Originalzahl in binärer Form (also in diesem Fall den Public Key in Nullen und Einsen) eine 1 angehängt, und dann so viele Nullen, dass das Ergebnis in Blöcke von genau 512 bits Länge teilbar ist (sog. Padding). Ganz am Ende werden 64 bit reserviert um die Länge der originalen Zahl zu kodieren.

2) Nachricht wird in Blöcke von 512 bit Länge geteilt.

3) In 64 Runden werden mehrere Rechenoperationen auf den ersten Block angewendet. Dieser wird dabei in 16 Blöcke mit je 32 bit aufgeteilt. Als Startwerte werden Konstanten genommen die von Primzahlen abgeleitet werden, diese und die 32-bit-Blöcke sind die Grundwerte der Rechenoperationen. Das Wichtige dabei: Einige dieser Operationen sind Modulo-Operationen. Das Ergebnis ist auf 32 bit begrenzt, die Operationen können aber zu Zahlen führen, die "zu groß" ausfallen - dann werden nur die letzten 32 bit berücksichtigt. Das heißt, dieser Prozess ist destruktiv, man kann die Rechenoperationen nicht umkehren. Am Ende erhält man nur noch 8 (nicht meht 16) 32-bit-Blöcke.

4) Ist mehr als ein 512-bit-Block vorhanden, dann sind die 8 Endwerte der Operationen auf den ersten Block die Startwerte für die Operationen des zweiten Blocks, und so weiter, bis der letzte Block verarbeitet wurde. Das stellt sicher dass der Hash unterschiedlich wird, selbst wenn nur irgendwo ein Bit der Originalnachricht verändert wurde. Sind z.B. 5 Blöcke vorhanden und im 2. Block wird ein Bit verändert, dann für das schon dazu, dass der Endwert der 64 Runden des 2. Blocks sich stark ändert und der 3. Block schon einen ganz anderen Startwert erhält.

5) Nach der Verarbeitung des letzten Blocks werden die acht 32-bit-Blöcke des Ergebnisses aneinandergereiht und ergeben den 256-bit-Hash. Der wird meistens als hexadezimale Zahl mit 64 Stellen angezeigt.

RIPEMD-160 arbeitet grundsätzlich ähnlich, aber die Runden sind anders organisiert.

Man kann also selbst als Laie erahnen, warum der Hash eine "EInbahnstraße" ist und nicht zurückgerechnet werden kann, und warum es so schwierig ist, genau einen gleichen Hash mit einer anderen Zahl zu ezeugen, weil winzige Änderung der Originalzahl irgendwo in einer "Runde" ein komplett anderes Ergebnis ergeben, das dann für alle anderen Schritte als Startwert gilt und damit den ganzen Hash "durcheinanderbringt".

Interessant ist, dass SHA2 aus den USA stammt (2001 von der NSA entwickelt) während RIPEMD europäisch ist (1993/96 von RIPE entwickelt), genauer gesagt stammt der Algorithmus aus Belgien.

[cygan]

@Lakai01 @ptrk @d5000 die diskussion um das ganze private-keys thema, könnt ihr gerne auch in dem folgenden faden fortführen:
Es gibt 2^256 private Schlüssel: Wie groß ist diese Zahl?
dort ist alles sehr schön beschrieben und erklärt und etwas mehr diskussionen würde dem faden auch wieder gut tun