#52 search space entered. 0.3 in 30 x 0.01 from SlarkBoy and the 0.052 for #52 Good Luck! Rico |
|
|
|
What's going on with Unknownhostname? How did he het so many keys?  I think Unknownhostname is Jeff Bezos. Rico |
|
|
|
Oder machen wir das später nach?
=> Wir machen das später nach Wir haben das in den nächsten 10 Minuten nachgemacht. Wer gerade seinen Client anschauen mag, gleich gibt's einen Warp-Sprung von 1 Billiarde Keys  Rico |
|
|
|
Der Admin aus Albanien wollte eigentlich nur immer mehr Kohle verdienen und hat in mir wohl das perfekte Opfer gesehen  Da würde ich sagen, hast Du noch einmal die Kurve gekratzt. Sei froh darüber. Rico |
|
|
|
the number of strings that we cannot get is then:
k (1-1/k) ^n
where n=2^257 (input) and k = 2^256 (output).
The result is: 2^256 * (1 - 1/2^256) ^ (2^257) = 2^256 * ((1 - 1 / 2^256)^(2^256))^(2) = 2^256 * ((1/e)^2) = 0,135 * 2^256 so we can get at this stage the 86,5% of all the 256 bit strings.
I would have appreciated if we could have given this more time (especially me to wrap my head around it) - but sure, maybe someone else can chime in with some insight. All these models assume a hash function to behave like a random (or pseudo-random) number generator. Normally, a good hash function - by design - tries to map the expected inputs as evenly as possible over its output range. see https://en.wikipedia.org/wiki/Hash_function#UniformityAlso Note that this criterion only requires the value to be uniformly distributed, not random in any sense. A good randomizing function is (barring computational efficiency concerns) generally a good choice as a hash function, but the converse need not be true. I had a look at the referenced paper, but I'm still not convinced about the premises to model a hash function as a pseudo-random generator. Please don't forget, that I've been looking at the SHA256 and RIPEMD160 implementation for months! They are both very similar (RIPEMD160 being way more "light-weight") and I cannot see how these would qualify as pseudorandoms.
What's even more important, we have to be aware in the nomenclature about the probability context. Let's even assume for a moment that theorem holds true for both SHA256 and RIPEMD160. When you speak above of so we can get at this stage the 86,5% of all the 256 bit strings. it is not entirely clear whom you reference to with "we". Because it certainly should not be "we" in this project. It should be "we all BTC users". In short: The Bitcoin address generation process uses only 86.5% of the codomain (target space) of the SHA256. But this effectively means, these 86,5% become 100% (*), because this is the reachable codomain for everyone under all circumstances. The other 13.5% simply do not exist for BTC, as they are unreachable. Not only for our project, but for everyone. So I actually do not see how you could restrict the target space for our 2^161 strings to 86.5% a priori. Also, because we generate fewer keys, we have actually less collisions in the SHA256 codomain, meaning "less waste" for the RIPEMD160 domain. As I said, I have to give it more time and see if this has an effect for our reduced search space or not. (*) And of course do not take my 100% verbatim as in numerically. It's 100% because it's "the reachable world" for us BTC users. Rico |
|
|
|
Ja natürlich. Ich rede ja auch absichtlich nicht (nur) vom LBC und auch nicht von einem "Angriff".
Hätte ja aber trotzdem sein können, dass so ein Fall schon bekannt wäre.
Oder könnte man damit automatisch Bitcoin (in seiner jetzigen Form) als tot betrachten, wenn es diesen Fall gäbe?
Ich würde ja gerne antworten, aber die Antwort, die ich schreiben wollte produziert (edit: wiederholt) einen "Database Error" - Admin ist informiert. Kurzform: Nein. (sonst hätte der LBC ja auch keine Daseinsberechtigung) nochmal edit: Ganz wichtig: Bitte zwischen hash160 Kollision (Ende des P2PKH/P2PSH) und "Ende des Bitcoin" unterscheiden. Selbst wenn hash160 in die Ecke gedrängt wäre, bedeutet das noch lange nicht das Ende vom Bitcoin. Vielleicht bekommen wir ja dann hash224 oder Skein oder Keccak... Rico |
|
|
|
Can you just post how much money have you made?
 |
|
|
|
Greetings, 6 months ago, in post on reddit, Ryan Castellucci referenced his article about analyzing how someone (or a group of someones) in the course of cracking the puzzle transaction was searching 500 tn keys. 15days ago, I posted on reddit a reference to this, mentioning that the LBC has searched over 1000 tn keys. (Where the above 500 tn keys meant 500 tn addresses, namely just the compressed ones and for LBC it means 2000 tn addresses). Today, the LBC will have searched 2000 tn keys ( 4000 tn addresses). I will refrain from posting that on reddit. Rico |
|
|
|
Dann bin ich wohl raus mangels CPU
Ich habe natürlich so kurz angebunden geantwortet, weil ich das ja schon an mehreren Stellen erklärt habe. Der LBC Pool ist in vielen Dingen dem Bitcoin-Mining sehr ähnlich: Er durchläuft eine ähnlliche Evolution CPU->GPU->(FPGA und ASIC sind wirtschaftlich fraglich, technisch aber logische Konsequenz), man könnte theoretisch Bitcoins schürfen etc. Je mehr Power/Speed man hat, desto wahrscheinlicher ein Fund. Wirklich ähnlich. Bis auf eine Sache. Die Difficulty. Wir haben mit der maximalen Difficulty angefangen. Je länger das läuft, desto einfacher wird die Geschichte und ich finde, die early Supporter, die mit angefangen haben "den Karren aus dem Dreck zu ziehen" mit 13000 keys/s und entsprechend in Wochen und Monaten eine Gkeys-Nummer aufgebaut haben, die heute jemand mit dem GPU client an einem Tag hat... die sollten nicht schlechter gestellt sein als "Frischlinge". Ja ne sorry, da fällt für mich "Mit CPU fange ich gar nicht erst an" unter die Kategorie "Diva". Der LBC ist auch kein Pool wo man mal eben für ein Stündle ausprobiert ob man nicht eine kliztekleine Kollision zu einer 100000 BTC Adresse findet. Ergo: Willst Du GPUAuth, acker Dich in die Top30 hoch, oder latz 0.1 BTC ab (der dann an alle außer mir verteilt wird) oder mach was besonderes für den LBC (ISO bauen, ECC Library hacken, ... findet sich noch bestimmt was). edit: Damit das klar ist - die Gkeys nummer ist sozusagen das "Gewicht" das man in die Waagschale der erledigten Arbeit eingeworfen hat. Das bestimmt auch wieviel man bei der Ausschüttung von Bounties bzw. nicht-reklamierten Funden bekommt. Ja, Unknownhostname ist ein Verrückter, der über 50% der Poolkapazität stellt, mit CPUs, also wird der auch viel abbekommen. => Meritokratie und eigentlich so wie bei einem Mining Pool Rico |
|
|
|
Wie komme ich an die GPU Funktion?
Mit CPUs fange ich nicht an, wenn dann GPUs
Warum soll das nicht gehen? Warum beschränkst du das?
Weil im Pool nur harte leidensfähige Kerle mitmachen sollen... Rico |
|
|
|
Rico Herzlichen Glückwunsch zu dem neusten puzzel fund ich beobachte da ja schon seit deinem start hab auch mal mit gemacht geht vmware mit rx480 ? dann würde ich mal wieder rein schauen Nein, OpenCL geht nur auf der richtigen Hardware - nicht in der VM. (Außer wohl bei Google und Amazon - die auch die GPUs virtualisieren, aber so richtig toll ist das dort auch nicht). Mit dem ISO image war wir hoffentlich bald haben kann man dann von USB/CD booten ohne das lokale System zu beeinträchtigen. Aber vorsicht Leute: GPUauth gibt's bei uns nicht einfach so mal wer Lust und Laune hat. Wir sind eine Meritokratie. :-) Rico |
|
|
|
Ich hätte im Keller einen Rig in dem Platz für 6 GPUs ist, die würde ich gerne mal testen, also wenn du ein ISO hast, das auch GPUs statt nur CPU macht, lass es mich wissen.
Der Ansatz das dein Projekt in den falschen Händen zum BTC Problem werden kann ist schon etwas erschreckend, aber viel erschreckender ist das du es geschafft hast, also andere es auch schaffen können und werden. ---> das erschreckt mich viel mehr ....
Das ist ein AMD GPU Rig? Haben wir hoffentlich bald ein ISO. Hinsichtlich "andere schaffen das auch" ... prinzipiell ja, aber ich hege ja noch die Hoffnung, dass wenn das jemand aus "wirtschaftlichen Interessen" heraus machen möchte, lässt er's bleiben weil er anderweitig Profitableres findet. Es sind ja zumindest bei mir bislang so 6 Mannmonate Entwicklung reingeflossen. Wenn so jemand natürlich die Entwicklung auf dem Silberteller bekäme... Dafür musste ich mir auch schon im englischen Thread anhören, dass das kein Geschäftsmodell ist.  Rico |
|
|
|
Ich wollte eigentlich gleich mit dazu schreiben, das ein solches Projekt als Ein-Mann-Show in dem Umfang natürlich nicht zu realisieren ist...
Ganz klar. Ich überlege ja schon, was ich vom Projekt für Mitarbeit öffnen könnte. Beim Generator/Client/Server habe ich aber ehrlich richtig Angst, dass wenn das in die falschen Hände gerät, dass wir dann gar nicht so schnell schauen wie die Funds von den Adressen verschwinden. Ich meine seht mal was ein Unknownhostname - mit CPUs - ausrichten kann! Der Zweite in den Top30 hat mal eben eine dedizierte 100Mkeys/s Maschine besorgt. Beim Gedanken, dass da irgendwo eine Fabrikhalle mit GPUs gefüllt mit billigem Chinastrom Keys erzeugt - ohne, dass da einer im Zweifelsfall den Not-Halt Knopf drücken kann (und das würde ich machen, wenn der BTC in Gefahr wäre). Nicht gut. Also den Source rücke ich so schnell nicht raus. Aber langsam bildet sich ja so eine kleine lose Truppe von Leuten. Mit Arulbero werden wir vermutlich zusammen an der EC Bibliothek hacken (Subversion Server, Trac Server - wie bei BOINC ) - das könnte man anderen Interessierten auch öffnen. User Icanscript will ISOs bereitstellen, also für Leute die wirklich einen Win-only Rechner haben, aber vielleicht mal über Nacht LBC laufen lassen möchten (mit GPU Unterstützung) - Live-CD rein: Los! Morgens Windows booten und Excel starten  Einen GPUauth zu bekommen wird auch immer schwieriger, also denke ich über Assignments nach - Aufgaben für deren Erfüllung es den GPUauth gibt. etc. etc. - wird schon. Rico |
|
|
|
Der Pool Speed könnte mit Sicherheit noch um einiges höher sein, wenn der LBC so einfach zu verwenden wäre wie der BOINC client https://boinc.berkeley.edu/ Ich kenne BOINC... Initial release 10 April 2002; 14.99 years ago
The following people have contributed to the development of the BOINC software:
Tolu Aina, Bruce Allen, Nicolás Alvarez, Jonathan Armstrong, Matt Arsenault, Sharov Artyom, Noaa Avital, David Barnard, Don Bashford, Lars Bausch, Christian Beer, James Bercegay, Oliver Bock, Frederic Bor, Brian Boshes, Nils Chr. Brause, Jens Breitbart, Tim Brown, Karl Chen, Carl Christensen, Pietro Cicotti, Jeff Cobb, Seth Cooper, David Coss, Markku Degerholm, Aycan Demirel, Glenn Dill, James Drews, Urs Echternacht, Liu Fan, Mike Fleetwood, John Flynn III, Joachim Fritzsch, Jan Gall, Michael Gary, Marco Gazzoni, Gary Gibson, Gabor Gombas, David Goodenough, Walt Gribben, John F. Hall, John Hallissey, Jim Harris, Volker Hatzenberger, Ian Hay, Eric Heien, Josh Highley, Darrell Holz, Thomas Horsten, Daniel Hsu, Bartosz Kaszubowski, Takafumi Kawana, John Keck, Andre Kerstens, David Kim, Nathan Kinsinger, John Kirby, Derrick Kondo, Eric Korpela, Robert Kreß, Janus Kristensen, Tim Lan, Egon Larsson, Gilson Laurent, Matt Lebofsky, Pav Lucistnik, Bernd Machenschalk, Nicolas Maire, Christopher Malton, Attila Marosii, Sebastian Masch, John McLeod VII, Michael Melanson, Evandro Menezes, Clive Messer, Kenichi Miyoshi, Steffen Möller, Don Mullis, Tony Murray, Eric Myers, Harold Naparst, Kjell Nedrelid, Hien Nguyen, Nikos Ntarmos, Rob Ogilvie, J.R. Oldroyd, Carlos Orellana, Alex Owen, Ron Parker, Jakob Pedersen, Stephen Pellicer, Reinhard Prix, Tetsuji Maverick Rai, Andy Read, Kevin Reed, Thomas Richard, Michael Roberts, RustyBSD, Slawomir Rzeznicki, Nikolay Saharov, Alex A. dos Santos, Steven Schweda, Josef W. Segur, Jens Seidler, Rytis Slatkevičius, Peter Smithson, Dr. M.F. Somers, Jon Sonntag, Christian Søttrup, Michael Tarantino, Michela Taufer, Frank S. Thomas, Michael Tyka, Thibaut Varene, Hendrik Verhoek, Roberto Virga, Mathias Walter, Oliver Wang, James Wanless, Frank Weiler, Derek Wright Sie verstehen schon: Aber danke - der Vergleich ehrt mich. Rico |
|
|
|
Dem schließe ich mich an Ist schon beeindruckend zu sehen, wie stark die Geschwindigkeit des LBCs in den letzten Monaten --> und vor allem in den letzten Wochen <-- zugelegt hat! Ich stelle gerade fest, dass ich über die Phase hinaus bin. Momentan beeindruckt mich, wie normal mir 1+ Gkeys/s erscheinen. Hätte mir vor 6 Monaten jemand gesagt, man würde bald 10 mio Seiten auf directory.io pro Sekunde abklopfen, hätte ich ihn wohl am Kopf getätschelt und "Is scho recht" gesagt. Also Willi: 10 mio mal schneller Gefährlich für Bitcoin? IMHO noch nein, aber wir begehen seit #51 offensichtlich neues (unkartiertes) Gelände. Rico |
|
|
|
And a PLUSONE!!! for automatic updating of either executable and Filter file.
Once a day or so, so we all work with the latest data, even on headless machines.
So I hope you have set up an "Eternal Run" configuration: https://lbc.cryptoguru.org/man/user#eternal-runRico |
|
|
|
Search debt from #50 search space: 751927328-999999998 ~240 MBlocks <--- we are here now ... well 752008095 ... I mean 753478383 ... ah f* it 1000752001-1073740223 ~ 73MBlocks <-- I'm testing here (so you will see a small 1Mblock jump when done above) [then sudden jump of 1000 MBlocks ] Rest of #51 search space: 2004489776-2053318784 ~48 MBlocks 2053937985-2147481087 ~93 MBlocks Start of #52 search space 2147483649-infinity_and_beyond So ~ 450 MBlocks until #52 search space. Let's see if we find something in these. So actually if you get a hit before your client shows 2147483649, it will certainly be a more interesting hit than #52. Rico (1 Mblock ~ 1Tkey = 1000 Gkey) |
|
|
|
|
Show Posts
