32-Bit Coldwallet Checker

Prueft, ob ein aus einem 32-Bit-Seed erzeugter Schluessel zu einer Adresse der Zielliste gehoert Engine ... Kerne ...

1. Zielliste pruefe ...

...

2. Zeitraum

Kandidaten-

3. Ableitung

Geprueft wird immer compressed und uncompressed, und immer gegen BTC, BCH, Litecoin und Dogecoin gleichzeitig - alle vier teilen sich denselben hash160.
0.00 %0 Keys/s
0 / 0-
Nur fuer die Pruefung eigener Schluessel. Ein Treffer wird in index/TREFFER.json auf dem Server gespeichert.
Treffer
Zielliste
Einzelpruefung
Was hier passiert

Treffer

Noch kein Treffer. Der Scan stoppt automatisch, sobald einer auftaucht.

Was in der Zielliste steckt

Noch kein Index gebaut.

Einzelne Adresse gegen die Zielliste pruefen

Damit laesst sich nachweisen, dass der Index wirklich greift: eine Adresse eintragen, von der bekannt ist, dass sie in der Liste steht.

Was hier passiert

Die Idee. Wenn ein Wallet seinen Private Key nicht aus 256 Bit echtem Zufall zieht, sondern aus einem 32-Bit-Wert wie einem Unix-Timestamp, dann gibt es statt 2^256 nur noch 2^32 moegliche Schluessel. Das sind rund 4,3 Milliarden - eine Zahl, die eine einzelne Maschine in Stunden durchgeht.

Wie verglichen wird. Nicht ueber Adress-Strings, sondern ueber den 20-Byte-HASH160 darunter. BTC, BCH (auch CashAddr), Litecoin, Dogecoin und bech32 unterscheiden sich nur in der Verpackung - der Hash ist derselbe. Eine Ableitung deckt damit alle Ketten gleichzeitig ab.

Warum compressed und uncompressed. Aus einem Private Key lassen sich zwei verschiedene Public Keys serialisieren, und die ergeben zwei voellig verschiedene Adressen. Bis Bitcoin Core 0.6.0 (30.03.2012) war uncompressed der Normalfall. Wer bei einem Zeitraum ab 2010 nur compressed prueft, sucht garantiert am Ziel vorbei.

Modus 1 gegen Modus 2. Modus 1 nimmt den Seed direkt als Schluessel. Weil die Schluessel dann aufeinanderfolgen, laesst sich der naechste Kurvenpunkt durch eine Addition statt durch eine volle Multiplikation gewinnen - das ist rund viermal schneller. Modus 2 hasht den Seed vorher, die Schluessel springen dadurch zufaellig, und es bleibt nur die volle Multiplikation.

Falschtreffer. Der Index speichert die ersten 8 der 20 hash160-Bytes. Ein zufaelliger Fehltreffer hat eine Wahrscheinlichkeit von etwa 4 zu 10^12 pro Abfrage. Jeder Treffer wird deshalb zusaetzlich woertlich in der CSV nachgeschlagen, bevor er als bestaetigt gilt.