Pages:
Author

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

legendary
Activity: 1120
Merit: 1037
฿ → ∞
Grin Grin Grin 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
sr. member
Activity: 317
Merit: 251
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.

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

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


Quote
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


 Grin Grin Grin Haha, danke für die Erläuterungen... Dachte mir schon, dass es teilweise doch recht arg daneben lag
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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.

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

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


Quote
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
sr. member
Activity: 317
Merit: 251
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  Grin Grin
member
Activity: 143
Merit: 33
ich hab noch ein I7 4770K drauf gepackt 2 kerne 671 mkeys
legendary
Activity: 1120
Merit: 1037
฿ → ∞
vor zweitagen oder der erste platz Cheesy so wie es scheint welsche cpu war das ?

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

Rico
member
Activity: 143
Merit: 33
vor zweitagen oder der erste platz Cheesy so wie es scheint welsche cpu war das ?
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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
legendary
Activity: 1120
Merit: 1037
฿ → ∞
so mein lappy läuft Cheesy

319000 abgerunden macht mein cpu hoffe das ist gut Cheesy

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


Rico
member
Activity: 143
Merit: 33
so mein lappy läuft Cheesy

319000 abgerunden macht mein cpu hoffe das ist gut Cheesy

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


Spezifikation

Win 10
VMware Player 12

CPU i5 3210M 2,5ghz
Ram 16 GB
SSD Samsung 256 EvoPro
hero member
Activity: 658
Merit: 500
methodic madness
Hier wird ein mathematisches Talent vergeudet!  Grin

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


Ich mag mich irren!  Grin


Konkreter geht's nicht?

Doch, doch!
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Hier wird ein mathematisches Talent vergeudet!  Grin

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

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

Konkreter geht's nicht?


Rico
hero member
Activity: 658
Merit: 500
methodic madness

Hier wird ein mathematisches Talent vergeudet!  Grin

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

legendary
Activity: 1120
Merit: 1037
฿ → ∞
Danke für die Erläuterung Smiley DAs find ich verständlich. Da hat sich aber dann jemand Mühe gegeben, dieses "Frühwarnsystem" aufzubauen Wink 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
sr. member
Activity: 317
Merit: 251
Du meinst wohl eher 150x höher Wink Grin

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

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.


Quote
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"  Grin

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

Man rechne (251 - 2"durchsuchte bits") / (Pool Speed * 86400)


Rico


Danke für die Erläuterung Smiley DAs find ich verständlich. Da hat sich aber dann jemand Mühe gegeben, dieses "Frühwarnsystem" aufzubauen Wink 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?
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Du meinst wohl eher 150x höher Wink Grin

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

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.


Quote
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"  Grin

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

Man rechne (251 - 2"durchsuchte bits") / (Pool Speed * 86400)


Rico
sr. member
Activity: 317
Merit: 251
@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!
sr. member
Activity: 317
Merit: 251
Die Wahrscheinlichkeit innerhalb 24h auf eine Adresse mit Funds zu stossen sind derzeit

0.000000000000002005488413420504643341989521735159876506643936%.
Irgendwie musste ich etwas schmunzeln als ich das mal mit Wahrscheinlichkeiten anderer ... "Tätigkeiten" so verglichen habe Wink

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

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


Rico
Du meinst wohl eher 150x höher Wink Grin
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Die Wahrscheinlichkeit innerhalb 24h auf eine Adresse mit Funds zu stossen sind derzeit

0.000000000000002005488413420504643341989521735159876506643936%.
Irgendwie musste ich etwas schmunzeln als ich das mal mit Wahrscheinlichkeiten anderer ... "Tätigkeiten" so verglichen habe Wink

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

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


Rico
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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?  Cool


Rico
Pages:
Jump to: