also das macht mir echt spass. ich denke ich sollte mir auch mal einen linux rechner zulegen.
also ich denke es läuft. im taskmanager ist mein cpu mit 80% belegt.
...
jetzt frage ich mich, angenommen er findet etwas, wie bekomme ich dann bescheid?
Ja, das sieht einwandfrei aus. die 80% sind plusminus 75% von den 3 CPUs, 5% vermutlich VM overhead und Dein host-OS. Wenn er was findet, sieht das dann so aus: $ LBC -c 1 -p 139000-141000
Loop off! Work on blocks [139000-141000] (2097 Mkeys)
Best generator chosen: gen-hrdcore-skylake-linux64
Estimated duration: 1057s
ooooooooooooooooooo
b190e2d40cfdeee2cee072954a2be89e7ba39364:c:priv:00000000000000000000000000000000000000000000000000000022382fb001 - 0x331
oooooooooooooooooooooooooo
Sprich zwischen den 'o' erscheint dann mal eine Zeile mit dem hash160 der gefunden wurde, gefolgt vom privaten key. O.g. Beispiel ist die #38 der Puzzle transaction #38: b190e2d40cfdeee2cee072954a2be89e7ba39364 -> 22382facd0 Liegt bei 140160, Rico |
|
|
|
hallo rico,
das passiert jetzt bei mir.
Ok - nicht mehr weit vom Ziel entfernt.  Die LBC Appliance ist ein wenig älter und war bei Erstellung schön aktuell und vorinstalliert. Mittlerweile sollte ich aber eine neue Version machen (werde ich auch wenn ich Zeit habe). Aktuelles LBC kommuniziert mit dem Server über https. Die Fehlermeldung die Du siehst, besagt, dass ein Perl Modul benötigt wird um eben https zu können. Hierzu auf der Shell cpan starten und dann in der CPAN shell entsprechendes Modul installieren: > cpan
cpan> install LWP::Protocol::https
Etwas Textgekrösel plätschert den Bildschirm runter, auf alles was sich bewegt mit "Y" antworten. Nun sollte Alles tun. Optional: ggf. als root(user: root pw: osboxes.org) mal ein machen, damit wird das OS auf neueste Versionen von Programmen upgegradet. Rico |
|
|
|
super danke. jetzt steht da use 1 CPU, habe aber doch noch drei ;-)
und was passiert jetzt genau?
Wenn man auf sowas antworten soll, helfen Screenshots immer am besten.  Prinzipiell solltest Du mal ein wenig in den Einstellungen des VMware Player spielen. Da kann man das Netzwerk im "bridged" Modus fahren, dann horcht die VM auf der gleichen IP wie der Rechner. sollte Klarheit verschaffen ob man in der VM Netzwerk hat oder nicht. Ansonsten kann man dem VMware Player auch sagen wieviele CPUs er nutzen soll (ich glaube Default ist da bei N cpus immer N-1, also bei einer 4 Kern Maschine eben 3). 1 CPU dem Host OS zu lassen macht Sinn, wenn man die Maschine nicht komplett blockieren will. Also angenommen Du hast Netz und 3 CPUs in der VM, dann eben Evtl. fährt LBC dann ein paar selbst-Updates (neuere Version des Client, neueres BLF file,...), und dann sollte das in etwa so aussehen: Ask for work... got blocks [224556089-224557752] (1744 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [224570009-224571672] (1744 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [224588121-224589784] (1744 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
etc. Rico |
|
|
|
login kann ich schon eingeben, aber nicht das pw
Das pw ist "osboxes.org" (ohne die Anführungsstriche). Ich verstehe nicht ganz, was Du mit "kann ich nicht eingeben" meinst. Das pw wird bei der Eingabe nicht angezeigt, entsprechend muss man es blind tippen und dann halt return drücken. => Der Shell-Prompt sollte erscheinen Da auch kein Z/Y vorhanden ist im pw, sollte deutsche/englische Tastatur nichts ausmachen. ggf. mal im login checken ob die Tasten von denen man glaubt sie seien entsprechend belegt auch so tun wie man das glaubt. Also ob bei . (Punkt) wirklich ein Punkt kommt und kein Komma. Ansonsten sollte der Login eigentlich keine Hürde sein. Rico |
|
|
|
Hallo und guten morgen,
ich habe mir jetzt Diskinternals geladen. Nun meine frage.
wie bekomme ich es jetzt ans laufen?
1) Lösche Diskinternals wieder 2) https://lbc.cryptoguru.org/man/admin#installation(VMware, LBC-Appliance, ggf 7zip ... einfach die Punkte abarbeiten) Rico |
|
|
|
I am also interested in a faster secp256k1. Unfortunately, it seems Pieter Wuille et al. were neither serious about providing a fast secp256k1 nor about documenting it well.  I have done some hacking to some pretty basic functions in there https://bitcointalk.org/index.php?topic=1573035.msg17365068#msg17365068- which alone made the LBC generator about 10% faster overall - and later also changing the field_5x52 code in secp256k1_fe_set_b32 to r->n[0] = (uint64_t)a[31]
| (uint64_t)a[30] << 8
| (uint64_t)a[29] << 16
| (uint64_t)a[28] << 24
| (uint64_t)a[27] << 32
| (uint64_t)a[26] << 40
| (uint64_t)(a[25] & 0xF) << 48;
r->n[1] = (uint64_t)((a[25] >> 4) & 0xF)
| (uint64_t)a[24] << 4
| (uint64_t)a[23] << 12
| (uint64_t)a[22] << 20
| (uint64_t)a[21] << 28
| (uint64_t)a[20] << 36
| (uint64_t)a[19] << 44;
r->n[2] = (uint64_t)a[18]
| (uint64_t)a[17] << 8
| (uint64_t)a[16] << 16
| (uint64_t)a[15] << 24
| (uint64_t)a[14] << 32
| (uint64_t)a[13] << 40
| (uint64_t)(a[12] & 0xF) << 48;
r->n[3] = (uint64_t)((a[12] >> 4) & 0xF)
| (uint64_t)a[11] << 4
| (uint64_t)a[10] << 12
| (uint64_t)a[9] << 20
| (uint64_t)a[8] << 28
| (uint64_t)a[7] << 36
| (uint64_t)a[6] << 44;
r->n[4] = (uint64_t)a[5]
| (uint64_t)a[4] << 8
| (uint64_t)a[3] << 16
| (uint64_t)a[2] << 24
| (uint64_t)a[1] << 32
| (uint64_t)a[0] << 40;
I have been pointed to https://github.com/llamasoft/secp256k1_fast_unsafe but am not sure if that is still maintained/developed. Is there any place where R&D discussion about further development is ongoing? Before I'd start reimplementing that mess from scratch I'd prefer to participate in some "official endeavor". However, I have little hope that will make sense: Signature verification isn't really the limiting factor in Bitcoin Core performance anymore in any case.
Together with other statements from gmaxwell @ github ("this is alpha/, don't expect other doc shan source.." - something like that from memory) I see there seems not much motivation in further development from the "official side". Rico |
|
|
|
No I didn't, but I will look into it as it sounds promising. Thanks for the pointer. Rico |
|
|
|
Actually remove the SSL , so those who doesn't believe can sniff their nose into those packets. because there's nothing to hide. end of all rumor and guesses.
We were running up to now without SSL and the feedback I got was, that if someone wants to try out some manual search range (which may or may not indicate "something he knows"), then over an unencrypted line this is a no go. Actually, at the moment we run both. The new client 0.960 uses SSL, there is no change in the API whatsoever, older clients still use plain old unencrypted. You get to the same site when you call e.g. http://lbc.cryptoguru.org:5000/statsor https://lbc.cryptoguru.org/statsThe 2nd is merely a nginx reverse proxy for the 1st. Rico |
|
|
|
any news an deinem Projekt
Jo. Ich habe den CPU Generator nochmal etwas schneller gemacht, weil sich herausgestellt hat, dass Pieter Wuille es mit der Performance bei der libsecp256k1 nicht so ganz ernst nimmt. Naja - Bitcoin Core Programmierer und Open Source ... kennt man ja. Nachdem ich nun also die schnellste RIPEMD160 CPU-Implementierung habe, die schnellste EC CPU-Implementierung habe und die vorerst schnellste SHA256 CPU-Implementierung verwende, ist die Skylake Version des Generators mal eben doppelt so schnell wie supervanitygen. Ich mache auf einem Kern bei mir ca. 720000 keys/s - aber im Gegensatz zu Supervanitygen eben compressed UND uncompressed public keys (also 1.44 mio hash160 pro Kern pro Sekunde gegen 11 mio hash160 gecheckt). Einen haarigen Bug habe ich heute behoben (alle Block-Zahlen über 50 Ziffern wurden falsch berechnet), glücklicherweise hat das auf die abgelieferte Arbeit keinen Einfluss, weil wir noch irgendwo bei 15 Ziffern rumkrebsen. Für den Bugreport danke an einen asiatischen Nutzer, der im Übrigen in den nächsten Tagen ca. 1200 CPU Kerne auf den Pool loslassen will, weil - jetzt kommt's: Er nur noch ungefähr den Bereich kennt, wo er seine Bitcoins deponiert hat, aber die konkreten privaten Keys nicht mehr hat.   LBC als recovery tool! Ich schmeiß mich weg. Rico |
|
|
|
Arguments followed like date of deposit on the address in question, start of the LBC project (2 years later) etc.
LOL... How does date of deposit prove you "have nothing to do with this address"? Another 1-liner from my favorite... We talked about it in length. In order to support your weak memory, I'll just quote here: Ok - here comes the evidence your honor:
The unspent output is from May 2014. If you think I staged this up 2 years before I even thought about starting the project, I feel flattered. You must certainly think I am some long-term planning mastermind genius. Thank you. Unfortunately, that doesn't change what I think about you - sorry.
Not only would I have to do this at a time when I was doing completely different things, I would also have to rely on a shitty 50bit 45.x bit PK to hold for over 2 years. So I would not only be a long-term planning mastermind genius, I would also have ballz of steel. Again, thank you, thank you. But no - I didn't.
Instead of your Dunning-Kruger-induced LOLs, you might wanna make some suggestions how I should prove to have nothing to do with that address in the 1st place. Oh ... right ... we talked about that too. No answer from you so far. So let's get this straight: your most favored hypothesis right now is - I deposited some $4.x value in BTCs in May 2014
- I used a very bad PK (with 211 leading zero-bits)
- Despite that key, the funds were untouched for 2 years
- So I waited over 2 years, then I started the LBC project (3 man-months programming and all)
- When the project generated some 35 trillion keys, it found aforementioned key
=> Finally I could reap this fruit and bath the pool and myself in everlasting gloryWow. Just wow. Unfortunately, since then, the pool has generated over 190 trillion keys and not made another find like this. Except the puzzle transaction hashes. But who knows? Maybe I am also the initiator of the puzzle transaction? Maybe I am even Putin? Rico |
|
|
|
On the other hand, it appears that the private key was communicated to you so in theory you could swipe any funds the pool finds. This is concerning. Am I missing something?
As I wrote, my client found the colliding hash160, so naturally my client communicated the private key to me. It's actually a little bit unfortunate, because if it had been found by someone else, we might have another indication (still no proof), that I was not involved with that address in any way. In other cases (e.g. the puzzle transaction), it's up to the client operators if they give feedback to me about the private keys found. AFAIK they did so - albeit sometimes with 1 week delay - so far. I mean it is something to brag about - isn't it? Rico |
|
|
|
I'd like to point the fellow readers' attention to my signature. If you care to remember, you saw there around 500000 keys/s per CPU core, today maybe shortly some 617 000 keys/s per CPU core and now we are at ~ 712000 keys/s per CPU core. It's all on the same machine (my notebook E3-1505M CPU). So what's the reason for the speed bump? It's simple. Pieter Wuille can't program. Or RyanC or both. Exaggerating - of course. There's nothing wrong with their programming skills - mine are just better. The secp256k1 library wants to convert a field element to a 32-byte big endian value like this: static void secp256k1_fe_get_b32(unsigned char *r, const secp256k1_fe_t *a) {
int i;
#ifdef VERIFY
VERIFY_CHECK(a->normalized);
secp256k1_fe_verify(a);
#endif
for (i=0; i<32; i++) {
int j;
int c = 0;
for (j=0; j<2; j++) {
int limb = (8*i+4*j)/52;
int shift = (8*i+4*j)%52;
c |= ((a->n[limb] >> shift) & 0xF) << (4 * j);
}
r[31-i] = c;
}
}
This seems a little bit awkward to me. All these computations and n(i|y)bble bashing must certainly eat up CPU cycles. My take on it (5x52 field): static void hrdec_fe_get_b32(uchar *r, const secp256k1_fe *a) {
r[31] = a->n[0] & 0xFF; // i = 0
r[30] = (a->n[0] >> 8) & 0xFF; // i = 1
r[29] = (a->n[0] >> 16) & 0xFF; // i = 2
r[28] = (a->n[0] >> 24) & 0xFF; // i = 3
r[27] = (a->n[0] >> 32) & 0xFF; // i = 4
r[26] = (a->n[0] >> 40) & 0xFF; // i = 5
r[25] = ((a->n[0] >> 48) & 0xF) // i = 6
| ((a->n[1] & 0xF) << 4);
r[24] = (a->n[1] >> 4) & 0xFF; // i = 7
r[23] = (a->n[1] >> 12) & 0xFF; // i = 8
r[22] = (a->n[1] >> 20) & 0xFF; // i = 9
r[21] = (a->n[1] >> 28) & 0xFF; // i = 10
r[20] = (a->n[1] >> 36) & 0xFF; // i = 11
r[19] = (a->n[1] >> 44) & 0xFF; // i = 12
r[18] = a->n[2] & 0xFF; // i = 13
r[17] = (a->n[2] >> 8) & 0xFF; // i = 14
r[16] = (a->n[2] >> 16) & 0xFF; // i = 15
r[15] = (a->n[2] >> 24) & 0xFF; // i = 16
r[14] = (a->n[2] >> 32) & 0xFF; // i = 17
r[13] = (a->n[2] >> 40) & 0xFF; // i = 18
r[12] = ((a->n[2] >> 48) & 0xF) // i = 19
| ((a->n[3] & 0xF) << 4);
r[11] = (a->n[3] >> 4) & 0xFF; // i = 20
r[10] = (a->n[3] >> 12) & 0xFF; // i = 21
r[9] = (a->n[3] >> 20) & 0xFF; // i = 22
r[8] = (a->n[3] >> 28) & 0xFF; // i = 23
r[7] = (a->n[3] >> 36) & 0xFF; // i = 24
r[6] = (a->n[3] >> 44) & 0xFF; // i = 25
r[5] = a->n[4] & 0xFF; // i = 26
r[4] = (a->n[4] >> 8) & 0xFF; // i = 27
r[3] = (a->n[4] >> 16) & 0xFF; // i = 28
r[2] = (a->n[4] >> 24) & 0xFF; // i = 29
r[1] = (a->n[4] >> 32) & 0xFF; // i = 30
r[0] = (a->n[4] >> 40) & 0xFF; // i = 31
}
Have fun. Rico |
|
|
|
Let me get this right? This is a project to gain private keys from wallets that have funds in them? correct?
No, this is a project to compute compressed and uncomressed hash160 for all private keys in the 1st 2^160 bits search space. There is no "finding" private keys, as the private keys are simply 256bit numbers being incremented. If by "finding" you mean finding a "hit" where the generated hash160 corresponds to some hash160 with unspent balance, then yes. Rico |
|
|
|
A discussion can't happen if there are no arguments presented. Your claim is backed only by underlined bold fonts: I swear I have nothing to do with this address - except my client found its private key tonight!
Arrogance is a primitive defense caused by the lack of arguments. Your arrogance is quite amusing, my dear friend. No my little retard. The bold text was just the initial statement. Arguments followed like date of deposit on the address in question, start of the LBC project (2 years later) etc. The only "amusing" thing here is, that you managed to get a legendary (...) account status by vomiting countless worthless 2-line contributions all over the place. IMHO your account would give a perfect test case for the account price estimator like "pathological account detected! value: 0 BTC" Rico |
|
|
|
The correct question is:
How do we know it is not one of your own keys?
Yo my fellow retard becoin! We had that discussion already. Remember? See https://bitcointalk.org/index.php?topic=1573035.msg16523548#msg16523548ff. Also, as for the theory behind the pool: https://lbc.cryptoguru.org/man/theoryeducate yourself 1st if you want to participate in the discussion. If you have real issues with the pool, articulate yourself clearly. Present facts, arguments, examples, counterexamples or whatever. If you do not want to lead a funded discussion, open your own thread and vomit there and do not pollute this thread as it seems you cannot help yourself from time to time. Merry Christmas. Rico |
|
|
|
Right now, the pool has had only one true find after searching 35 trillion keys. How do we know? Is it on the stats page? It's on the trophies page: https://lbc.cryptoguru.org/trophiesRico |
|
|
|
-rwxr-xr-x 1 antonio antonio 34671 dic 18 16:06 LBC
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: error 0x567.
Another error... Then we are back at the "you have tampered with the LBC source code" hypothesis. $ wget ftp://ftp.cryptoguru.org/LBC/client/LBC
$ ll LBC
-rwxr-xr-x 1 rico rico 34675 Dec 20 13:30 LBC
LBC should be 34675 bytes long - not 34671 Rico |
|
|
|
What would YOU want from that coin?
To give me more Bitcoins, or - at least - to make my Bitcoins worth more. Rico |
|
|
|
Hi, My test is ok:
Ok. Ask for work... Server doesn't like us. Answer: malformed request.
what does ./LBC -v say? You should have version 0.899 If you do have version 0.899, then the messages simply say you have tampered with the LBC source code. If you haven't - which is the better alternative - the file "bench.pst" is simply not readable to LBC. In that case, it should be sufficient to do a "sudo chown antonio *" on the files. Rico |
|
|
|
Not 100% sure what you're implying...
In cases like these, one would suggest to ask for clarification if you are not sure and not to start with a load of Cpt. Obvious statements. I am not implying, I am merely stating a fact. It takes a certain time (cannot say exactly for this case, because the balance graph @eligius does not show sufficient history for me) IIRC about 2-3 weeks until your estimated reward hits a saturation. In specific cases like this (extremely long round time), you may hit that even if you came quite late to the party. I'm neither talking about pool hopping, nor did I say luke-jrs statement was wrong. It's just not entirely true for a very specific case: Clients joining the pool long after a round has begun and long before it ends (and staying until the end). Of course to take any profit from this, one would have to foresee the future (how long the round will take), which most of us can't. So even at this very moment, people could speculate and join eligius and if the current round still took - say- another 400 hours, they'd get overproportionally rewarded. If the round took less, they wouldn't. Because they do not know the future: Yes, practically pool hopping has no benefit. Theoretically - if you knew the future/round length, or had luck - there is benefit of late join. Rico |
|
|
|
|
Show Posts
