rico666cz

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

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

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

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

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.) 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

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

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) Immer her mit den Prognosen. Ist Mangelware heutzutage. Mining = richtiges Leben. *daumen-hoch-emoji* 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. 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

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

Wird noch spannender. Der Pool hat heute Nacht seinen dritten Fund gemacht. Details folgen bald. Die "Puzzle"-Transaktion ist nicht von uns. Da hat vermutlich jemand ein "Frühwarnsystem" aufgestellt. Ich vermute in weniger als zwei Wochen werden wir #51 gefunden haben (https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS) und wir greifen die nicht an. Die liegt einfach nur auf dem Weg. Näheres dazu ist hier zu finden: https://bitcointalk.org/index.php?topic=1306983.0 Die Trefferwahrscheinlichkeit steigt natürlich mit der Anzahl der verwendeten Adressen. Doppelt so viele Adressen - doppelt so hohe Trefferwahrscheinlichkeit. Aber ich möchte gleichzeitig beruhigen: Ich selbst habe natürlich Bitcoins und sehe noch keine Veranlassung die irgendwo panikartig anderweitig zu deponieren. Erstens wüsste ich nicht wohin, zweitens sind die Wahrscheinlichkeiten so gering, da ist die Gefahr beim BTC-Transfer durch irgendeinen Fehler BTCs zu verlieren millionenfach höher. Rico

Die "Experiment"-Hypothese gibt es natürlich, wobei diese genauso unbewiesen ist wie die "Kollision nur fehlt uns der 'Originalschlüssel' zum Beweis"-Hypothese. Momentan haben wir nur Indizien die mal die eine, mal die andere Hypothese stützen. Ergo: Wir sind momentan so schlau als wie zuvor. 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/(296)² auch nicht ohne. Die Vorstellung "kleine kurze Schlüssel" seien "ganz weit weg" von "guten langen Schlüsseln" ist wegen Kollisionen eben falsch. Zahlen stimmen nun nicht, aber es spricht prinzipiell nichts dagegen, dass 0000000000000000000000000000000000000000000000000005c3aaf3f00001 (kurzer "schlechter" Key) in den gleichen hash160 zeigt wie 8724876a87f87e8768d780c002378abe28494323259879bc6c6e7887f2a0021a (langer "guter" Key) (am Rande sei bemerkt das Copy&Paste in den WYSIWYG-Editor hier mächtig schei*e ist) Warum? Durch den sog. Avalanche-Effekt sowohl der sha256 wie auch der ripemd160 Funktionen der eben besagt, dass 1 bit Änderungen in den Eingangsdaten gut 50% der Bits in den Ausgangsdaten flippen sollen. Das ist eine gewollte Eigenschaft guter Hashfunktionen. Bedeutet aber in letzter Konsequenz: Es gibt keinen numerischen Sicherheitsabstand! Rico

Kommt darauf an. Manchmal sucht einer auch den bereits abgegrasten Suchraum nochmal ab: Siehe z.B. auf https://lbc.cryptoguru.org/trophies die Passage "2016-10-20 15:00:00 GMT A manual revisit of the 38-42 bit search space revealed these private keys..." Natürlich nicht. Das Thema hatten wir auf bitcointalk.org. Gegen den LBC wäre wohl ein Schlüssel im Bereich 2^159 + rand(2^158) am besten. Eine Schnitzeljagd veranstalten wir ab und zu, damit uns nicht langweilig wird. Dann gibt es ja noch die Puzzle transaction als globalgalaktische Schnitzeljagd. Ansonsten geht's schon hart zur Sache: Gefunden werden kann prinzipiell der Zugriff zu jeder Adresse. Mit übersichtlicher Wahrscheinlichkeit - da hast Du schon recht. 2 Verschiedene Keys für 1 Adresse: Nein - bislang noch nicht, da wäre sicher ein größerer Rummel nicht zu vermeiden. Wir arbeiten daran. Allgemein zum Sinn vom Pool: Wenn man wüsste, was der schon so an Erkenntnisgewinn und technologischen Nebenprodukten abgeworfen hat, würde man sich die Sinnfrage nicht stellen. Bevor jetzt wieder die "unschuldige Frage" Was denn? kommt: Zu viel in den letzten 6 Monaten um es hier in annehmbarer Zeit niederzuschreiben. Rico

Detailiertere Funktionsweise siehe hier https://lbc.cryptoguru.org/man/theory Es wird einmal getestet (selten zweimal - wenn sich die Clients gegenseitig überprüfen) und fertig. Theoretisch könnte man also Bitcoins auf einem Privatkey < 250 ablegen, aber das wäre unklug, da wenig Entropie. Allerdings hat kein Privatkey eine höhere Entropie als 160bit. Leider. Ist so. Siehe auch den Link warum. Jetzt schauen wir erstmal, dass der neue GPU client an die Leute rausgeht (wesentlich schneller als oclvanitygen), und dass wir endlich bald #51 finden (https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS) - in weniger als 1 Monat sollte es ja soweit sein. Rico

Privkeys alleine suchen macht keinen Sinn, weil man ja dann nicht weiß

Ok, dann so: Ja, der LBC hat zwei "echte" Adressen mit BTCs drauf gefunden (Nein, eine Kollision wurde noch nicht bewiesen) P2PSH ist nicht sicherer als P2PKH Es gibt in der LBC Software keine Viren/Trojaner/Malware/Adware/... (Liste hinreichend aber nicht vollständig) Privkeys alleine suchen macht überhaupt keinen Sinn und als Bonus kleiner Seitenhieb auf Axiom0815 Rico

Nö - warum? Understatement ist doch cool. Es gibt zwar mehrere axiomatisch fundierte und konsistente Logiken, aber Deine gehört nicht dazu. Klar kannst Du alleine suchen, aber noch schlimmer als beim Solo-Mining weisst Du hier nicht, ob der Suchraum nicht bereits von jemandem abgegrast worden ist und Du somit 0% Chance hast etwas zu finden. Der LBC Pool stellt ja genau sicher, dass nicht Arbeit doppelt gemacht wird. Ergo werden da auch nicht irgendwelche Privatkeys zufällig ausgekotzt, sondern man läuft systematisch durch. Die Software macht genau das was draufsteht: Sie generiert so schnell es geht aus privkeys aus einem bestimmten Bereich hash160 und gleicht diese gegen alle Adressen ab auf denen Unspents sind. Im Übrigen auch P2SH. Weiterhin im Übrigen sind P2SH nicht sicherer als P2PKH, siehe https://bitcointalk.org/index.php?topic=1581701.msg16344155#msg16344155 So viel zu Deinem "fast unendlich ³" - der Brüller. Die Software braucht zu ihrem Betrieb weder irgendein privaten Key von Dir, noch eine wallet.dat noch eine Blockchain auf dem Rechner. Installier' das auf einem nackten System oder sonstwie. Ich finde es gut, wenn Du einen Thread startest und Dich mit dem Thema beschäftigst, aber bevor Du weiter im Trüben stocherst - frag doch jemanden, der sich mit sowas auskennt. Rico