Large Bitcoin Collider (LBC)

[Axiom0815]

Ach ist doch einfach.

 

Erst werden ALLE normalen Adressen geprüft, dann die anderen

 

eins nach dem anderen, in der Ruhe liegt die Kraft

 

Ja, Zahlen und Größen sich realistisch vorzustellen, ist gar nicht so einfach.

 

 

Axiom

 

PS: Kurz vor den Wahnsinn verliert der Mensch das Gefühl für Raum und Zeit.

Bearbeitet 2. April 2017 von Axiom0815

[Axiom0815]

Nachtrag:

 

Bildschirmfoto (zum Verständnis)
https://www.dropbox.com/s/77mkxnn0tof0dmy/sichere-Wallet-1.0.4.png?dl=0

 

Als Beispiel eine Electrum-Wallet zum spielen. Passwort coinforum.de (Vorsicht, kann jetzt jeder nutzen, also auch Bitcoin stehlen.)

https://www.dropbox.com/s/q8596uplvns3n0u/wallet_Axiom_Multi-Key_%28Forum%29?dl=0

 

Viel Spaß beim testen.

 

Axiom

[rico666cz]

 

Schön zu hören, dass ihr die Zeit als Größe noch nicht verstanden habt.

Jede Putzfrau ist da klüger, weil eben über die frische gewischten Böden wieder Leute laufen.

Wer denkt, ein Hochhaus "systematisch" von oben nach unten durch zu wischen und dann ist alles fertig, sollte sich mal auf ein U- oder S-Bahnhof stellen und Dynamik verstehen lernen.

 

In Eurer Software geht ihr nur von Single-Keys aus, richtig? Was ist mit den Multi-Keys-Adressen?

 

Schon klar, dass Du nach meinem Seitenhieb ein wenig hippelig reagierst. 

 

Das Thema Zeit - insbesondere das Nutzen von Adressen nach der LBC Suchfront haben wir bereits im deutschen bitcointalk.org Forum durchdiskutiert - vor geschätzt 4-5 Monaten. Habe ich jetzt keine Lust das nochmal auf Putzfrauen-Niveau durchzukauen.

 

Die hash160 von Multi-Key Adressen suchen wir seit neuestem auch (en-passant ohne Zeitverlust), aber das knacken selbiger machen wir mal eben zum Nachtisch wenn wir welche gefunden haben. Schliesslich ist ja so eine P2SH praktisch überhaupt nicht gegen Brute-Force abgesichert sobald man den privkey zum betreffenden hash160 hat.

 

 

Rico

Bearbeitet 2. April 2017 von rico666cz

[Axiom0815]

Die hash160 von Multi-Key Adressen suchen wir seit neuestem auch (en-passant ohne Zeitverlust), aber das knacken selbiger machen wir mal eben zum Nachtisch wenn wir welche gefunden haben. Schliesslich ist ja so eine P2SH praktisch überhaupt nicht gegen Brute-Force abgesichert sobald man den privkey zum betreffenden hash160 hat.

 

 

Die Bitbreite von 160 ist unumstritten (https://www.coinforum.de/topic/4003-wie-ist-eine-offline-paperwalleterstellung-m%C3%B6glich/page-2?do=findComment&comment=65913), aber es ist eben auch diese Breite systematisches durchprobieren...

 

Mit der Motivation, paar Fundstücke im Suchbereich zu legen, könnte noch eine Zeitlang Mitspieler bei der Stange bleiben.

Aber wie im richtigen Leben, beim Mining, verursacht es auch Kosten. Wenn es dann langweilig wird und mehr Kosten als Gewinn raus kommt, sollte sich die Begeisterung bei der Mehrzahl legen.

 

Sonst Kryptografisch, RIPEMD-160 ist aus den Jahre 1996, also ein altes Eisen. Damals nur als zusätzliche Sicherheit zu SHA256 mit zugenommen.

Sollte es zu wirklichen technischen Fortschritten kommen, könnte man den Code komplett überarbeiten, oder eben "nur" auf SHA512 / RIPEMD-320 umsteigen.

Den Hardrock macht dann jeder mit, wenn es ernsthafte Drohungen mit LBC gibt.

 

Axiom

 

PS: Wer seine Electrum-Wallet mit 2^160 Adressen füllt, hat die selben Trefferwahrscheinlichkeit.

Aber nur theoretisch, weil physikalisch "leichte Schwierigkeiten" sich in den Weg stellen werden.

 

PPS: Vielleicht ne neue Grafikarte? https://www.amazon.de/HPE-NVIDIA-Tesla-Dual-Module/dp/B00TWFEIWA/ref=pd_sbs_147_1?_encoding=UTF8&psc=1&refRID=BPGR27YZWEBCHBS8MYR2

Bearbeitet 2. April 2017 von Axiom0815

[rico666cz]

Die Bitbreite von 160 ist unumstritten (https://www.coinforum.de/topic/4003-wie-ist-eine-offline-paperwalleterstellung-möglich/page-2#entry65913), aber es ist eben auch diese Breite systematisches durchprobieren...

Der referenzierte Artikel ist ja ziemlich falsch. Was du als public key bezeichnest, ist der hash160.

Der public key hat (uncompressed) 512bit, bzw. 256 bit (compressed).

Erst das wird durch den RIPEMD160(SHA256(public key)) gejagt und man bekommt den hash160 mit 160bit Entropie.

Ein wenig mehr Sorgfalt bei der Nomenklatur emfehle ich (multi-key statt multi-sig habe ich ja noch durchgehen lassen

aber das wird langsam zu bunt)

 

Mit der Motivation, paar Fundstücke im Suchbereich zu legen, könnte noch eine Zeitlang Mitspieler bei der Stange bleiben.

Aber wie im richtigen Leben, beim Mining, verursacht es auch Kosten. Wenn es dann langweilig wird und mehr Kosten als Gewinn raus kommt, sollte sich die Begeisterung bei der Mehrzahl legen.

Immer her mit den Prognosen. Ist Mangelware heutzutage. Mining = richtiges Leben. *daumen-hoch-emoji*

 

Sonst Kryptografisch, RIPEMD-160 ist aus den Jahre 1996, also ein altes Eisen. Damals nur

als zusätzliche Sicherheit zu SHA256 mit zugenommen. Sollte es zu wirklichen technischen Fortschritten

kommen, könnte man den Code komplett überarbeiten, oder eben "nur" auf SHA512 / RIPEMD-320 umsteigen.

Den Hardrock macht dann jeder mit, wenn es ernsthafte Drohungen mit LBC gibt.

Ich sage ja immer jedem, dass der LBC keinesfalls eine Bedrohung für Bitcoin ist. Zwar wäre der Umstieg auf einen neuen

Adresstyp m.E. wünschenswert, aber nicht so ohne weiteres möglich - erstmal bräuchte es da ein entsprechendes BIP, dann

verstehe ich nicht, warum man sich wieder ein Folding würde antun wollen tun (512 -> 320 bit), aber das mögen

irgendwelche Coredevs auskarteln.

 

Was ich stark bezweifle, dass "verlorene Adressen" einen entprechenden Umstieg mitmachen würden und ich

bezweifle auch, dass sich ein Konsens fände diese Adressen zu invalidieren. Im "schlimmsten" Fall also, würde

der LBC alte (verlorene) Adressen recyclen.

 

PPS: Vielleicht ne neue Grafikarte? https://www.amazon.de/HPE-NVIDIA-Tesla-Dual-Module/dp/B00TWFEIWA

Neu? K80 bah... haben wir etliche im LBC laufen - viel zu alt, viel zu lahm.

Der neue Generator läuft da auch nicht drauf, stiefmütterliches Nvidia OpenCL.

Wenn schon, dann eine Maxwell oder besser noch Pascal GPU - am besten im Verbund

mit einer AVX512-fähigen CPU.

 

 

 

Rico

[Axiom0815]

Ich sage ja immer jedem, dass der LBC keinesfalls eine Bedrohung für Bitcoin ist. Zwar wäre der Umstieg auf einen neuen

Adresstyp m.E. wünschenswert, aber nicht so ohne weiteres möglich - erstmal bräuchte es da ein entsprechendes BIP, ....

 

 

Na dann ist ja alles gesagt.

 

Schönen Abend noch

Bearbeitet 2. April 2017 von Axiom0815

[joho]

Es geht bei LBC nicht um eine Kollisionsattacke, sondern eine Preimage-Attacke.  Auch wenn der Name anderes vermuten lässt.  

 

Bei einer Kollisionsattacke erzeugt man 2^80 Schlüssel und schaut dann, ob man zweimal den gleichen Public Key hat.  Aufgrund des Geburtstagsparadoxons ist die Wahrscheinlichkeit dafür recht hoch. Nur bringt einem das nichts, weil man dann lediglich eine Addresse hat, für die man zwei verschiedene Schlüssel hat.  Man muss immer noch jemanden dazu überreden sie auch mit Bitcoins zu füllen   Bei multisig-Addressen kann das problematisch sein, denn wenn Malleroy eine Kollision für eine Multisig-Adresse berechnet kann man Malleroy Alice davon überzeugen, dass die Addresse mit Alices Key gesichert ist, aber Malleroy hat noch einen Zweitschlüssel, der Alices Key nicht benötigt. Daher wird segwit die Multisig-Addressen auf 256 bit erweitern, um 128 bit Security zu bekommen.

 

Hier versucht aber jemand eine der existierenden 100 Millionen Bitcoin-Addressen zu treffen.  Dazu muss man aber im Mittel 2^160/10^8 ~= 2^133 Schlüssel ausprobieren.  Das ist schwieriger als die Public Keys mit dem altbekannten Giant-step-little-step Verfahren zu knacken.  Elliptische Kurven mit 256 bit haben nur 128 bit Security.

 

Die Exponential-Funktion ist teuflisch, eine Erhöhung des Exponenten um 10 macht das ganze 1000 mal aufwändiger.  Das Bitcoin-Netzwerk kann mit seiner gesamten Mining Power ca. 2^83 Hashes im Jahr durchprobieren.  Für 2^133 Hashes würde es aber eine Billiarde Jahre brauchen, das ist 100'000 mal länger als das geschätze Alter des Universums.

[rico666cz]

Es geht bei LBC nicht um eine Kollisionsattacke, sondern eine Preimage-Attacke.  Auch wenn der Name anderes vermuten lässt.  

 

Es geht um gar keine Attacke, es geht darum eine Kollision zu finden. Aber wenn jemand unbedingt sehen möchte wie ich eine Attacke fahren würde, dann kann ich mich dem auch mal für 6 Monate widmen.

 

Wenn ich die Wahl habe 2^133 Schlüssel ausprobieren praktisch ohne Speicherbedarf und 100% parallelisierbar, oder 2^80 hash160 zu erzeugen und zu speichern(wie ?) und dadurch der Parallelisierbarkeit weitestgehend verlustig zu gehen, wähle ich ersteres.

 

Das Beispiel mit dem Bitcoin-Netzwerk ist ja formal nicht falsch und dennoch ein ganz schlimmer Selbstbetrug (den im übrigen 99,9999% aller "Experten" begehen).

Ich frage mal ganz naiv - in anbetracht der Billiardzichtillionen Jahre - wie viele Jahre hat das Bitcoin-Netzwerk zum Aufbau dieser Mining Power gebraucht?

Rhetorische Frage - keine Antwort nötig.

 

 

 

Rico

Bearbeitet 4. April 2017 von rico666cz

[joho]

 

Wenn ich die Wahl habe 2^133 Schlüssel ausprobieren praktisch ohne Speicherbedarf und 100% parallelisierbar, oder 2^80 hash160 zu erzeugen und zu speichern(wie ?)  und dadurch der Parallelisierbarkeit weitestgehend verlustig zu gehen, wähle ich ersteres.

 

 

Speichern ist nicht nötig, siehe https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012204.html

Benötigt 4-fachen Rechenaufwand, aber dafür nur ein paar 100 byte Speicher.

 

nicht parallelisierbar: Das ist zwar richtig, aber mit Parallelisierung wird es nicht 2^53-mal schneller, außer jede Person auf dem Erdball lässt das Programm auf einer Millionen Cores parallel laufen.

 

Das Beispiel mit dem Bitcoin-Netzwerk ist ja formal nicht falsch und dennoch ein ganz schlimmer Selbstbetrug (den im übrigen 99,9999% aller "Experten" begehen).

Ich frage mal ganz naiv - in anbetracht der Billiardzichtillionen Jahre - wie viele Jahre hat das Bitcoin-Netzwerk zum Aufbau dieser Mining Power gebraucht?

 

 

Es gibt auf jeden Fall einen guten Anhaltspunkt über die Kosten für 2^86 Hashes.  Da die Miner einen Umsatz von derzeit 630'000 Bitcoin im Jahr machen, können wir grob sagen, dass es mehrere 100'000 Bitcoin kostet so viele Hashes zu berechnen.  Public Keys zu berechnen ist zwar 100-1000 mal auwändiger, aber das lassen wir mal kurz außer acht.  Wenn man jetzt interessiert  ist fremde Bitcoins zu stehlen, indem man Addressen zu privaten Schlüssel berechnet und schaut, ob die Addresse Bitcoins enthält, dann ist es für den durchschnittlichen Gewinn unerheblich, ob alle Bitcoins auf einer Adresse liegen, oder jeder Satoshi auf einer anderen. In beiden Fällen ist der Erwartungswert weniger als 21'000'000 Bitcoin pro 2^160 Hashes, oder mit der gesamten Hashpower aller Miner 0.0000001 Satoshi pro Jahr (wenn Moore's Law anhält und die Miningpower weiter steigt, sind es in 5 Jahren vielleicht 0.0001 Satoshi pro Jahr).

 

Diese Zahlen sollten deutlich zeigen, dass alle "Kollisionen", die bisher gefunden wurden auf unsicheren Schlüsseln beruhen und keine echten Kollisionen sind.  Der originale private Schlüssel stimmt mit dem gefunden Schlüssel überein.

 

 

 

Die Adressen sind nicht irgendwie als Experimental-Adressen auffällig. Im Gegenteil, beide sehen wie reguläre Changes aus.

Die Wahrscheinlichkeit für eine Kollision ist gering, aber die Wahrscheinlichkeit zweimal exakt den Originalschlüssel zu treffen ist mit 1/(2⁹⁶)² auch nicht ohne.

 

 

Ich weiß jetzt nicht wie du auf jetzt auf 1 zu (2^96)^2 kommst, aber die Wahrscheinlichkeit, dass jemand einen 50 bit langen Private-Key erzeugt hat, ist deutlich größer als dass jemand einen zufälligen Private Key erzeugt hat und es eine Kollision mit einem 50 bit langem Schlüssel gibt.   Die Wahrscheinlichkeit, dass es zu einem zufällligen Schlüssel einen 50 bit langen Schlüssel mit dem selben Hash gibt ist leicht zu berechnen: Eins zu 2^110 und damit kleiner als die Wahrscheinlichkeit, dass 5 Wochen lang jeden Mittwoch die gleichen Lottozahlen mit der gleichen Superzahl gezogen werden.

[rico666cz]

Speichern ist nicht nötig, siehe https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012204.html

Benötigt 4-fachen Rechenaufwand, aber dafür nur ein paar 100 byte Speicher.

 

nicht parallelisierbar: Das ist zwar richtig, aber mit Parallelisierung wird es nicht 2^53-mal schneller

Wie kommst Du jetzt auf 2^53? ;-)

 

(halb-rhetorisch um auf Deinen Rechenfehler aufmerksam zu machen, den Du natürlich zur

Grundlage weiterer Überlegungen machst.)

 

Es gibt auf jeden Fall einen guten Anhaltspunkt über die Kosten für 2^86 Hashes.

Ich habe doch explizit geschrieben: "Rhetorische Frage - keine Antwort notwendig"

 

Rhetorische Fragen des Gegenüber sind dazu da, dass man über die Sache nachdenkt, ergo ein wenig in sich geht. Und so...

Was machst Du? Du wechselst flugs die Kategorie. Nun ist es nicht mehr die Zeit (Billionen Jahre), sondern die Kosten.

 

Ja was nun? So diskutieren hysterische Weiber (oder wie ich immer sage: Argumentationskette wie ein Flohzirkus).

 

Mein Punkt war, dass Du durch die Angabe mit "Billionen Jahre" den Hauch der Unmöglichkeit deutlich machen möchtest. Ich wollte dagegenhalten, dass die Hashkapazität - lass es in 4 Jahren sein (aber vermutlich früher) - doppelt so hoch sein wird. Ha! 500 Milliarden Jahre gespart! In 4 Jahren! Magie!

 

Ich erlaube mir auf die anderen Sachen gar nicht erst einzugehen, weil eine Implikationskette nunmal ab der ersten Fehlimplikation wertlos ist.

 

Aber ich finde es gut, wenn ausführlichst dargestellt wird, warum dieses Projekt eigentlich

unmöglich ist, haben wir später mehr zu lachen. In der Zwischenzeit freue ich mich über den

Fund von #51.

 

 

Rico

[joho]

Wenn ihr #52 gefunden habt, kannst du ja mal den public key (im Format "028c6c67bef9e9eebe6a513272e50c230f0f91ed560c37bc9b033241ff6c3be78f") schicken, ohne den private key zu verraten.

 

Ich würde gerne mein kleines C-Programm testen:

>time ./a.out 
Found private key 2: fffffffffffffffd or                3
Found private key 3: fffffffffffffff9 or                7
Found private key 4: fffffffffffffff8 or                8
...
Found private key 48:     ade6d7ce3b9b or     ade6d831c465
Found private key 49:    174176b015f4d or    174176cfea0b3
Found private key 50:    22bd43bd16cac or    22bd43c2e9354
Found private key 51:    750709e5ff62c or    75070a1a009d4

real	8m34.117s
user	8m32.756s
sys	0m1.092s

Nein, keine Monstermaschine, nur mein zwei Jahre alter Laptop mit Core-i5 Prozessor und ohne angeschlossenes Netzteil.  Das Programm funktioniert aber leider nur, wenn man den public key hat, der hash reicht nicht  .

[rico666cz]

Wenn ihr #52 gefunden habt, kannst du ja mal den public key (im Format "028c6c67bef9e9eebe6a513272e50c230f0f91ed560c37bc9b033241ff6c3be78f") schicken, ohne den private key zu verraten.

 

Ich würde gerne mein kleines C-Programm testen:

...

Nein, keine Monstermaschine, nur mein zwei Jahre alter Laptop mit Core-i5 Prozessor und ohne angeschlossenes Netzteil.  Das Programm funktioniert aber leider nur, wenn man den public key hat, der hash reicht nicht  .

 

Oha? Ein EC^-1 ? So richtig?

 

Jedenfalls spannend. Für #52 bitte ca. 1 Monat gedulden - wir haben noch etwas Suchschuld abzuarbeiten.

Aber auch wenn die Suchrate etwas runtergeht - über 30 Tage sollte es nicht werden.

(edit: meine Antwort sollte natürlich implizieren: ja - natürlich bekommst Du von mir den pubkey vorab

und ich hoffe, ich bekomme dann innerhalb von ... 20 Minuten? Eine von N privkey-Alternativen für N < 10)

 

Rico

Bearbeitet 5. April 2017 von rico666cz

[rico666cz]

...so viele Hashes zu berechnen.  Public Keys zu berechnen ist zwar 100-1000 mal auwändiger, aber das lassen wir mal kurz außer acht.

 

Darauf möchte ich noch kurz zurückkommen. Der aktuelle LBC Generator (die CPU Version, nicht die GPU Fassung)

braucht auf meinem Notebook für 16,7M Keys (= 2 x 16,7M Adressen) aufgerundet stolze 19 Sekunden (pro Kern).

 

Davon entfallen 3 Sekunden auf die pubkeys und 16 Sekunden auf die 2 SHA256 + 2 RIPEMD160.

 

Die GPU Fassung braucht 3 Sekunden für Alles...

 

Rico

Bearbeitet 5. April 2017 von rico666cz

[joho]

Oha? Ein EC^-1 ? So richtig?

 

Jedenfalls spannend. Für #52 bitte ca. 1 Monat gedulden - wir haben noch etwas Suchschuld abzuarbeiten.

Aber auch wenn die Suchrate etwas runtergeht - über 30 Tage sollte es nicht werden.

(edit: meine Antwort sollte natürlich implizieren: ja - natürlich bekommst Du von mir den pubkey vorab

und ich hoffe, ich bekomme dann innerhalb von ... 20 Minuten? Eine von N privkey-Alternativen für N < 10)

 

 

Genau gesagt ECDLP mit der Babystep-Giantstep Methode.

Für #52 würde es ca. 12 Minuten und 1GB Speicher brauchen. Die zwei Fällle ergeben sich, weil ich das Vorzeichen des Babysteps nicht überprüfe (baue ich vielleicht später ein).

 

Aber ob ich 20 Minuten response-time schaffe ist unwahrscheinlich    Nur wenn ich zufällig online bin, die Nachricht rechtzeitig sehe und den Laptop bereit habe.

 

Es ist schade, dass die Puzzle-Transaktion nicht pay to pubkey outputs benutzt, sondern hashes.  Andererseits wäre sie dann aber wahrscheinlich schon längst bis ca. #80 geleert.

[rico666cz]

Genau gesagt ECDLP mit der Babystep-Giantstep Methode.

Für #52 würde es ca. 12 Minuten und 1GB Speicher brauchen. Die zwei Fällle ergeben sich, weil ich das Vorzeichen des Babysteps nicht überprüfe (baue ich vielleicht später ein).

 

Aber ob ich 20 Minuten response-time schaffe ist unwahrscheinlich    Nur wenn ich zufällig online bin, die Nachricht rechtzeitig sehe und den Laptop bereit habe.

 

Viel länger kann ich aber nicht warten mit der Veröffentlichung, Abgesehen muss dann die Transaktion schon laufen, bevor Du den privkey bekommst.

 

Was die Laufzeit anbelangt: Vielleicht könnte ich es ja schneller machen? 

Oder gar eine OpenCL Fassung? (wobei sich da EC traditionell etwas spreizt)

 

 

Rico

[joho]

Ich habe mal mein Programm auf gist.github gelegt: https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89

 

Es ist ein wenig buggy, z.B. wenn der private key mit zu vielen Nullen endet

Auch fängt es false positives nicht ab und gibt dann eventuell den falschen Key aus.

Es ist ein quick hack und das erste Mal, dass ich libsecp256k1 benutze.

 

Es gibt viel Verbesserungspotential:

• fe_inv_all_var statt fe_inv_var benutzen
• parallelisierung der beiden Schleifen
• man kann sich ein gej_add_ge_var sparen, wenn man sich auf einen public key konzentriert.
• eventuell bessere Hashtabellenimplementierung

[segeln]

Die ganze Mathematik (und Statistik) und das Vorgehen bei dieser Sache verstehe ich nicht (wegen meiner schlechten Statistik-und Mathematikenntnisse)

Daher simple Fragen:

Sind meine BTC (noch) sicher?

Wie werden sie sicherer gemacht?

Kann das BTC-Ökosystem durch all dies (LBC) gefährdet sein? Und ab wann (zeitlich gesehen)?

Danke schon mal für verständliche Antworten!

Segeln

[fjvbit]

Die ganze Mathematik (und Statistik) und das Vorgehen bei dieser Sache verstehe ich nicht (wegen meiner schlechten Statistik-und Mathematikenntnisse)

Daher simple Fragen:

Sind meine BTC (noch) sicher?

Wie werden sie sicherer gemacht?

Kann das BTC-Ökosystem durch all dies (LBC) gefährdet sein? Und ab wann (zeitlich gesehen)?

Danke schon mal für verständliche Antworten!

Segeln

Alles ist gut, keine Gefahr

[rico666cz]

Sind meine BTC (noch) sicher?

Wie werden sie sicherer gemacht?

Kann das BTC-Ökosystem durch all dies (LBC) gefährdet sein? Und ab wann (zeitlich gesehen)?

Ja, Deine BTCs sind prinzipiell noch sicher - ungefähr so sicher wie Deine Rente, vielleicht sogar noch sicherer.

 

Momentan ist die sicherste Vorgehensweise GAR NICHTS zu machen (wer anfangen sollte hektisch seine

BTCs auf viele Adressen zu splitten läuft eher Gefahr irgendwas zu vermasseln und rein rechnerisch

erhöht er das Risiko für einen Fund. rechnerisch - nicht praktisch)

 

Riesige Beträge auf einer BTC Adresse halten sollte man eh nicht - unabhängig vom LBC.

Da muss jeder wissen wo für ihn die Grenze ist.

 

Sollte irgendwann durch den LBC das BTC Ökosystem gefährdet sein, würde ich mit Vorlauf

Bescheid geben, oder den Not-Aus Knopf drücken.

 

Also, wie oben von fjvbit gesagt: "Alles ist gut, keine Gefahr".

 

 

Rico

[Kitfisto]

Gibts eigentlich ne Website die mir aus den privaten Schlüssel den öffentlichen Schlüssel und die Bitcoinadresse berechnet und anzeigt ?

[fjvbit]

Gibts eigentlich ne Website die mir aus den privaten Schlüssel den öffentlichen Schlüssel und die Bitcoinadresse berechnet und anzeigt ?

http://directory.io

 

Man will den privaten Schlüssel in keine Website engeben...

Das geht besser offline...

Bearbeitet 9. April 2017 von fjvbit

[Axiom0815]

http://directory.io

 

Man will den privaten Schlüssel in keine Website engeben...

Das geht besser offline...

Oh, oh...

 

Nimm lieber www.bitaddress.org und lade dir die Seite runter. Dann offline nutzen!

 

Axiom

[fjvbit]

Oh, oh...

Nimm lieber www.bitaddress.org und lade dir die Seite runter. Dann offline nutzen!

Axiom

Ich würde Client wie Elektrum empfehlen dafür...

[Axiom0815]

Ich würde Client wie Elektrum empfehlen dafür...

 

Ist die bessere Wahl!

[Kitfisto]

Mir gings eigentlich nur darum ne Website zu finden die aus einen privaten Schlüssel den öffentlichen Schlüssel und die Bitcoinadresse berechnet.

sowas wie:

http://hashgenerator.de/

ist natürlich klar das man nicht seine eigenen privaten keys berechnen läßt.die hat man ja schon sowieso in der eigenen Wallet mit dessen Adressen liegen.