Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 24. (Read 51057 times)

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

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

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


Das stimmt nun magischerweise wieder. 


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



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

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 

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

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

Rico

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

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

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


Rico

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

Ich mag mich irren!  


Doch, doch!

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


Konkreter geht's nicht?


Rico

Hier wird ein mathematisches Talent vergeudet! 

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

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

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?

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


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.



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

@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!

Du meinst wohl eher 150x höher

0.00000000000000200548% (damals)
0.00000000000017024754% (heute)
0.00000000000020353947% (heute)

Immerhin - ca. 85101mal größere Wahrscheinlichkeit.


Rico

Die News in Kürze:

• Ab Freitag 21., wird der Pool Client-Version 0.870 als Mindestvoraussetzung verlangen und so keine clients mit Go-Generatoren mehr akzeptieren.
• Der Pool hat heute Nacht ~ 2 Uhr GMT #46 der "Puzzle Transaction" gefunden - siehe Trophies
• Momentan macht der Pool ca 40MKeys/s, das wird noch steigen (plusminus auf 60MKeys), weil ich sehen möchte ob/wie der Server skaliert.

Vermutlich wird der Pool also in den nächsten 24h ca. 5 TKeys (5 Billionen Keys = 10 Billionen Adressen) checken.
Alle natürlich gegen die ca. 9 Millionen Adressen mit Funds drauf, also 90 Trilliarden checks.

Gut - ne? 


Rico