Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[schnebihacked]

@rico666

Also ich find das Projekt bis jetzt sehr spannend und werd mich sobald wie möglich auch dran beteiligen. Ich habe allerdings mal 2 Fragen:

1. Was ist die "Puzzle transaction2
2. Auf der statistics seite steht: "OTOH - at current speed - the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS in roughly 321 days."

Wie ist es möglich, dass du eine Aussage darüber treffen kannst, wann der private key zu einer bestimmten Adresse gefunden werden wird?

Danke für die Antworten!

[rico666]

Du meinst wohl eher 150x höher

Jetzt ja 165x, aber da kommt ja keiner hinterher.  

1. Was ist die "Puzzle transaction"

Da hat wohl jemand 256 Beträge auf 256 Adressen gelegt, jede dieser Adressen hat eine Schlüssellänge in Bits, die dem Betrag in Millies entspricht.
Nach reiflich Diskussion und Überlegung handelt es sich wohl um eine Art Vorwarnsystem, bzw. Sicherheitsbeweis für/gegen das Knacken von Privatschlüsseln.

2. Auf der statistics seite steht: "OTOH - at current speed - the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS in roughly 321 days."

Wie ist es möglich, dass du eine Aussage darüber treffen kannst, wann der private key zu einer bestimmten Adresse gefunden werden wird?

Du meinst wohl eher "286 days"  

Betreffende Adresse ist #51 der puzzle Transaction, also hat sie (maximal) 51bit Schlüssellänge.

Man rechne (2⁵¹ - 2^{"durchsuchte bits"}) / (Pool Speed * 86400)


Rico

[schnebihacked]

Du meinst wohl eher 150x höher

Jetzt ja 165x, aber da kommt ja keiner hinterher.  

1. Was ist die "Puzzle transaction"

Da hat wohl jemand 256 Beträge auf 256 Adressen gelegt, jede dieser Adressen hat eine Schlüssellänge in Bits, die dem Betrag in Millies entspricht.
Nach reiflich Diskussion und Überlegung handelt es sich wohl um eine Art Vorwarnsystem, bzw. Sicherheitsbeweis für/gegen das Knacken von Privatschlüsseln.

2. Auf der statistics seite steht: "OTOH - at current speed - the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS in roughly 321 days."

Wie ist es möglich, dass du eine Aussage darüber treffen kannst, wann der private key zu einer bestimmten Adresse gefunden werden wird?

Du meinst wohl eher "286 days"  

Betreffende Adresse ist #51 der puzzle Transaction, also hat sie (maximal) 51bit Schlüssellänge.

Man rechne (2⁵¹ - 2^{"durchsuchte bits"}) / (Pool Speed * 86400)


Rico

Danke für die Erläuterung DAs find ich verständlich. Da hat sich aber dann jemand Mühe gegeben, dieses "Frühwarnsystem" aufzubauen WIe kommts denn, dass auf den bisherigen Adressen der Puzzle TRansaction (also bis #46) keine Beträge mehr drauf sind? Bedeutet dass dann, die wurden bereits von jemand anderem geknackt und abgezogen?

[rico666]

Danke für die Erläuterung DAs find ich verständlich. Da hat sich aber dann jemand Mühe gegeben, dieses "Frühwarnsystem" aufzubauen WIe kommts denn, dass auf den bisherigen Adressen der Puzzle TRansaction (also bis #46) keine Beträge mehr drauf sind? Bedeutet dass dann, die wurden bereits von jemand anderem geknackt und abgezogen?

Bis #50 wurde bereits geknackt und abgezogen: https://rya.nc/forensic-bitcoin-cracking.html

private rant on

Deswegen sehe ich ja die Notwendigkeit so eines Pools, der da öffentlich an die Sache rangeht. Aber das scheint wohl nicht allgemeiner Konsens zu sein. Viel besser ist es schliesslich das Mantra "unmöglich" zu wiederholen, ggf. mit der leichten Variation "Verschwendung" und wenn einem gar nichts mehr einfällt, dann ein "illegal" einzulegen.

Überhaupt ist in diesem Fall "die Bitcoin Community" schizophren, dass sich die Balken biegen. Irgendwelche im Geheimen operierenden GPU Farmen, die mit ziemlicher Sicherheit so etwas bereits machen sind ja kein Problem, weil was man nicht sieht, das tut einem nicht weh.

Ein öffentlicher Pool der so etwas tut und bei dem die Chance die evtl. gefundenen Bitcoins den rechtmäßigen Eigentümern zurückzugeben, bzw. wenn diese nicht mehr auffindbar sind gerecht zu recyclen (verlorene P2PK i.e. an die Poolmitglieder auszuschütten) - ne sowas geht ja gar nicht.

private rant off

Ich muss noch in der Pool Doku unbedingt etwas zur Theorie hinter dem Pool schreiben, weil die Meisten checken noch nicht einmal, dass der Suchraum gar keine 256bit groß ist. (Nicht einmal, wenn man es ihnen unter die Nase reibt)

Rico

[deadlock1]

Hier wird ein mathematisches Talent vergeudet! 

Es gäbe so viele interessante Sachen zu berechnen, gerade im Bereich BTC & Co.

[rico666]

Hier wird ein mathematisches Talent vergeudet! 

Die bisherige Erfahrung lehrt, dass Zweifel angebracht sind, ob hier überhaupt Jemand zugegen ist, der diese Einschätzung treffen kann. 

Es gäbe so viele interessante Sachen zu berechnen, gerade im Bereich BTC & Co.

Konkreter geht's nicht?


Rico

[deadlock1]

Hier wird ein mathematisches Talent vergeudet!  

Die bisherige Erfahrung lehrt, dass Zweifel angebracht sind, ob hier überhaupt Jemand zugegen ist, der diese Einschätzung treffen kann.  

Ich mag mich irren!  

Konkreter geht's nicht?

Doch, doch!

[Hardstyles]

so mein lappy läuft

319000 abgerunden macht mein cpu hoffe das ist gut

meine cpu läuft nur mit 33% geht auch mehr ? <---- selber gelöst


Spezifikation

Win 10
VMware Player 12

CPU i5 3210M 2,5ghz
Ram 16 GB
SSD Samsung 256 EvoPro

[rico666]

so mein lappy läuft

319000 abgerunden macht mein cpu hoffe das ist gut

Glückwunsch. 319 tausend ist für die CPU ok.
Festplatten-Speed spielt für LBC praktisch keine Rolle.


Rico

[rico666]

Ich hab da mal eine 100MKeys/s Maschine auf die vorherigen Keys der Puzzle Transaction losgeschickt.

http://lbc.cryptoguru.org:5000/trophies

#42 war extrem fies.


Rico

[Hardstyles]

vor zweitagen oder der erste platz so wie es scheint welsche cpu war das ?

[rico666]

vor zweitagen oder der erste platz so wie es scheint welsche cpu war das ?

2 x Intel Xeon Phi a.k.a. Knights Landing

Rico

[Hardstyles]

ich hab noch ein I7 4770K drauf gepackt 2 kerne 671 mkeys

[schnebihacked]

Ich versuche grad mal zu verstehen, warum der Suchraum deutlich kleiner als 2^256 ist. Wenn meine Überlegung falsch ist korrigiert mich bitte...

Also es gibt 2^256 Adressen, aber nur 2^160 Private Keys. Das heißt, ich muss swieso schon mal "nur" die 2^160 private Keys gegen die ~10.000.000 Adressen mit Founds drauf gegentesten. Das beschränkt den Suchraum schon mal auf 2^160... Soweit richtig?

Das ganze bedeutet, dass es für jeden Adresse 2^96 private keys gibt, mit denen ich Zugriff auf die BTC auf der Adresse bekommen kann. Von diesen 2^96 muss ich ja jetzt nur einen einzigen finden um tatsächlich den Zugriff zu bekommen.

Ich gehe jetzt davon aus, dass die Wahrscheinlichkeit immer die selbe ist, dass der passende private Key zu einer beliebigen Adresse

0000000000000000000000000000000000000000000000000000000000000001 oder
000000000000000000000000000000000000000000000000000022306e3f1a72 oder
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff fffffffffffffffffffffffff oder irgendein anderer ist.

Dementsprechend würde das ja bedeuten, dass die 2^96 passenden Keys sich statistisch gesehen "gleichmäßig" über die 2^160 verteilen. Bedeutet "rein statistisch gesehen" hat wahrscheinlich jede Adresse einen passenden private key im ersten 2^96stel des 2^160 keys umfassenden Suchraums. Bedeutet, eigentlich muss ich nur ein 2^96stel von 2^160 durchsuchen um zu jeder Adresse einen passenden key zu finden.

Da es aber ja nur darum geht den passenden key zu einer einzigen Adresse zu finden auf der founds liegen kann ich das Ergebnis davon nochmal durch die 10.000.000 Adressen teilen, auf denen BTC liegen und komme damit auf den effektiven Suchraum, den ich durchsuchen muss um mit annähernd 100% Wahrscheinlichkeit den passenden Key zu einer Adresse mit Founds zu finden. Also:

2^160 geteilt durch 2^96 geteilt durch 10.000.000 ist der effektive Suchraum....

Ist das soweit richtig??

Edit: Das würde dann nach meiner Rechnung einem Suchraum von 1.8446744073709551616 × 10^12 keys, oder 1844674407370 private keys bedeuten.... Das scheint mir daoch deutlich zu wenig 

[rico666]

Ich versuche grad mal zu verstehen, warum der Suchraum deutlich kleiner als 2^256 ist. Wenn meine Überlegung falsch ist korrigiert mich bitte...

Also es gibt 2^256 Adressen, aber nur 2^160 Private Keys. Das heißt, ich muss swieso schon mal "nur" die 2^160 private Keys gegen die ~10.000.000 Adressen mit Founds drauf gegentesten. Das beschränkt den Suchraum schon mal auf 2^160... Soweit richtig?

Nein. Es ist genau anders herum: Es gibt 2^256 private Keys, aber nur 2^160 Adressen.

Das ganze bedeutet, dass es für jeden Adresse 2^96 private keys gibt, mit denen ich Zugriff auf die BTC auf der Adresse bekommen kann.

Das stimmt nun magischerweise wieder. 

Von diesen 2^96 muss ich ja jetzt nur einen einzigen finden um tatsächlich den Zugriff zu bekommen.

Exakt. Der Public Key wird zwar ein anderer sein (die EC lässt sich so nicht austricksen), aber Zugriff auf die Adresse wird möglich sein.
Im Übrigen: Wenn der public Key bekannt ist, dann ist der Suchraum um den privaten Key zu finden nur noch 128 bit...

Dementsprechend würde das ja bedeuten, dass die 2^96 passenden Keys sich statistisch gesehen "gleichmäßig" über die 2^160 verteilen.

Nein - wieder knapp daneben: Die 2^96 Schlüssel sind gleichmäßig über die 2^256 verteilt, daher befindet sich in jeden 2^160 im Schnitt einer davon. (weil 2^160 ja 2^96 mal in 2^256 reinpasst)

Ab dann wirds arg daneben, daher gelöscht.


Rico

[schnebihacked]

Ich versuche grad mal zu verstehen, warum der Suchraum deutlich kleiner als 2^256 ist. Wenn meine Überlegung falsch ist korrigiert mich bitte...

Also es gibt 2^256 Adressen, aber nur 2^160 Private Keys. Das heißt, ich muss swieso schon mal "nur" die 2^160 private Keys gegen die ~10.000.000 Adressen mit Founds drauf gegentesten. Das beschränkt den Suchraum schon mal auf 2^160... Soweit richtig?

Nein. Es ist genau anders herum: Es gibt 2^256 private Keys, aber nur 2^160 Adressen.

Das ganze bedeutet, dass es für jeden Adresse 2^96 private keys gibt, mit denen ich Zugriff auf die BTC auf der Adresse bekommen kann.

Das stimmt nun magischerweise wieder. 

Von diesen 2^96 muss ich ja jetzt nur einen einzigen finden um tatsächlich den Zugriff zu bekommen.

Exakt. Der Public Key wird zwar ein anderer sein (die EC lässt sich so nicht austricksen), aber Zugriff auf die Adresse wird möglich sein.
Im Übrigen: Wenn der public Key bekannt ist, dann ist der Suchraum um den privaten Key zu finden nur noch 128 bit...

Dementsprechend würde das ja bedeuten, dass die 2^96 passenden Keys sich statistisch gesehen "gleichmäßig" über die 2^160 verteilen.

Nein - wieder knapp daneben: Die 2^96 Schlüssel sind gleichmäßig über die 2^256 verteilt, daher befindet sich in jeden 2^160 im Schnitt einer davon. (weil 2^160 ja 2^96 mal in 2^256 reinpasst)

Ab dann wirds arg daneben, daher gelöscht.


Rico

  Haha, danke für die Erläuterungen... Dachte mir schon, dass es teilweise doch recht arg daneben lag

[rico666]

Haha, danke für die Erläuterungen... Dachte mir schon, dass es teilweise doch recht arg daneben lag

No problem.

Der effektive Suchraum bis man statistisch irgendeine Adresse findet ist 136.75 bit, weil wir derzeit gegen ca. 11 mio Adressen prüfen

lg(11863283) = 23.5

2^160 / 2^23.5 = 2^136.75

Dass wir bereits eine Adresse gefunden haben und vor dem abknuspern von 136 bit noch potentiell mindestens weitere 80 Adressen finden werden ändert am effektiven Suchraum praktisch Nichts, denn dann wäre es lg(11863203) = 23.49999024646846237705, also immer noch 23.5

Rico

[rico666]

Wenn ich nochmal um den Faktor 1000 besser werde ist's nicht mehr ganz so kläglich, aber immer noch
ungefährlich für Bitcoin.

Im Übrigen sind wir soweit. Der Pool ist die letzten 2 Tage ca. um den Faktor 1000 schneller als die Keygenerierung zu der Zeit o.g. Zitats.
Einen Riesengrund zur Besorgnis gibt es natürlich noch nicht, allerdings spricht prinzipiell Nichts dagegen, dass der Pool in ca. 4 Monaten nochmal um den Faktor 1000 schneller wird, denn nachdem ja hier keiner zu Potte kommt, habe ich beschlossen einen GPU client zu schreiben.

https://youtu.be/lbDoZTs3NoY?t=65

Rico

[Hardstyles]

Hallo rico wie sieht es aus ?

verfolge den englischen Thread nicht so weil mein English noch nicht so gut ist .

[rico666]

verfolge den englischen Thread nicht so weil mein English noch nicht so gut ist .

Die schlechte Nachricht: Ich muss noch viel über OpenCL lernen.
Die gute (oder noch schlechtere - je nachdem wie man's sieht) Nachricht: Offensichtlich sind auch andere unfähig.

Als Erklärung zu letzterem:

Ich dachte mir ursprünglich, oclvanitygen so hinzubiegen, dass es tut was ich will. Das habe ich auch geschafft und ich habe bereits einen GPU generator am Laufen, der ca. 50% der Performance von oclvanitygen hat. Die 50% sind deswegen, weil für jeden Durchlauf (der Generator sieht sich 2^30 private keys pro "block" an) eigentlich 2 Durchläufe notwendig sind: Einer bei dem compressed public keys und einer bei dem uncompressed public keys generiert werden. Das Feld-Wald-Wiesen oclvanitygen generiert nämlich nur eine Art an public keys (habe vergessen welche).

Das ist natürlich Käse, weil man idealerweise beide keys gleichzeitig erzeugen sollte, müsste, hätte, könnte.

Wenn man denn könnte - da hapert's noch mit meinem OpenCL Wissen um den shitty code, der da in oclvanitygen herrscht zurechtzubiegen.

Dann gibt es da noch das Problem, dass oclvanitygen eigentlich auf andere Aufgaben hin getrimmt (naja - sagen wir "barock erweitert") wurde: Präfix-Suche und regex-Suche.

Die regex-Suche habe ich eh gleich geknickt, aber die Präfix-Suche ist da mit AVL Trees gelöst und das ist ja für unseren Bedarf so ziemlich das übelste was man machen kann.

Also versuche ich mich momentan an einem eigenen generator, der compressed und uncompressed keys in einem Durchgang erzeugt und diese gegen einen Bloom Filter abgleicht - alles auf der GPU.

Es geht alles sehr zäh, weil wie gesagt OpenCL Neuland für mich ist. Auf der anderen Seite ist Programmierung nicht so ein Neuland für mich und wenn es so klappt wie ich mir das vorstelle, dann sollte mein Generator oclvanitygen "im Staub hinter sich zurücklassen".

Dauert halt, weil ich auch noch andere Dinge zu tun habe und sonst leider keiner zugegen ist, der außer bla bla mal mit anfassen könnte.


Rico