1 Unknownhostname 661507 31s ---- around 175 times more ... still I never find anything
)
A quantum of solace may be that you are co-responsible for this find.
Ladies, Gentlemen and becoin!
We are proud to announce a new genuine find of the LBC pool. Please stand by for the technical details while we move the funds to a custodial address.
https://lbc.cryptoguru.org/trophies2017-03-30 01:18:00 UTCThe pool found a private key to 7d89ad89cd10a3867b8f6bfc803838fa101b598b (1CSnQ1LnY37rwz8ezJn5xQrCrifZxExpWV) as 0x5e1667c899783. At the time of the find, there were 0.00001 BTC on that address.The funds were transferred to custody at 1Dg1XnH9BLKFf4XrWioYsxDJjSxr996Miq.
Finder is id Janussss (here user
Janu$$ - currently at position 46 with 881 delivered Gkeys, operating 3(?) LBC CPU-clients in the vmware appliance. (I may not be exactly right - just so you get an impression about the luck factor in this project.)
Best story: How did I find out? Because at 1:18 a.m. UTC I was snoring peacefully and still I knew sooner than him.
For this, we have to go back 24 hours: I am trying to make a GPU client for unknownhostname so it runs on these fucking Google/Amazon cloudshizz servers. I know that by providing unknownhostname with a decent GPU client, time and space will fold into a singularity, but still I want to see how the pool goes beyond 1Gkeys/s - so I try. Hard. Unfortunately no success, because the shizm is strong in the cloud.
I have a GPU client that does not print @ GPU, but it starts crashing elsewhere. Weird errors and I'm about to give up. I write a PM to arulbero and whine a little bit about the fact
Good news is, that the keyrate raise you see on
https://lbc.cryptoguru.org/stats is mostly due to your ECC arithmetics. It's users deploying the new clients. It's not more users.
I've been fighting for a day with a new GPU client for "unknownhostname" and his Tesla GPUs. While I do have a client that should not crash, libGMP is driving me crazy.
I see this error
root@LBC:~/collider/beta# time ./hrd-core -I 0000000000000000000000000000001111111111111111111111111111111111 -c 10000 -L 8 -p
Key given: 1111111111111111111111111111111111
but the first key must be in the range:
1 - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8ccf364141
Please retry with another key
real 0m0.046s
user 0m0.000s
sys 0m0.033s
root@LBC:~/collider/beta# time ./hrd-core -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -L 8 -p
Key given: 1
but the first key must be in the range:
1 - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8ccf364141
Please retry with another key
real 0m0.044s
user 0m0.004s
sys 0m0.030s
where I already have modified the printout and as you can see the key given is correct. So I assume there is something wrong with this code
if(mpn_cmp(kr, klim1r, 4)<0 || mpn_cmp(kr, klim2r, 4)>0 ){
but I'm not sure what???
One of the last things I do is to write a debug message in the code gmp_printf("Set privkey to: %Zx\n", k); and change the code to a
if(mpz_cmp(kr, klim1r)<0 || mpz_cmp(kr, klim2r)>0
. It works! I'm happy and thrilled, make a avx2+gpu client and write that to arulbero.
Then I try it on a Amazon AWS:
there is something wrong with this code
if(mpn_cmp(kr, klim1r, 4)<0 || mpn_cmp(kr, klim2r, 4)>0 ){I replaced it with what seemed to be the intuitive solution
if (mpz_cmp(k, klim1) < 0 || mpz_cmp(k, klim2) > 0) {
gmp_printf("Key given: %Zx\nbut the first key must be in the range:\n%Zx - %Zx\n", k, klim1, klim2);
printf("Please retry with another key\n");
return 0;
}
And now it's crashing elsewhere... *sigh*
root@LBC:~/collider/beta# time ./hrd-core -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -L 8 -p
hrd-core: malloc.c:3700: _int_malloc: Assertion `victim->fd_nextsize->bk_nextsize == victim' failed.
No! I am the victim here.
With that I give up and go to sleep.
Meanwhile... the LBC user with the Id johnsnow comes along and because he got a gpuauth=1 recently he downloads/updates (I guess, he may clarify exactly what happened) the GPU avx2+gpu client which - unfortunately - has still the debug message in it.
While he does LBC -x, he is probably not yet familiar with LBC and so when it starts to print "Set privkey to: 0x......" he is not alarmed and operates the client.
The night passes in Europe, I wake up and one of my 1st things is to check the logs. And I see in the logs for a particular client (that of johnsnow) <timestamp> <ip> invalid challenge response "Set privkey to 0x....." instead of a correct challenge response. I have long forgotten that it was actually me who had this debug message in the GPU generator(!). I thought WTF? and grepped for the string in the client. Nothing. In the server: Nothing.
I thought maybe the NSA was hacking/mocking me. (Not fully awake probably) So I tried one of the privkeys:
$ time gen-hrdcore-skylake+gpu-linux64 -I 0000000000000000000000000000000000000000000000000005e1667b699001 -c 10000 -L 8 -d 1
response: 30-54-0
7d89ad89cd10a3867b8f6bfc803838fa101b598b:u:priv:0000000000000000000000000000000000000000000000000005e1667c899001+0x782
response: 30-48-0
response: 30-14-0
response: 30-61-0
response: 30-26-0
response: 30-12-0
response: 30-2-34"3DUfw��
response: 30-73-0
real 0m23.895s
user 0m22.687s
sys 0m1.160s
*BAMM*
Now I was definitely thinking NSA was mocking me and I wrote the "may johnsnow contact me ASAP" message.
He did and was very helpful, sending screenshots what happened on his end, reassuring me he had not tampered with the code, so slowly I began to realize what had happened.
I had a look who got the block interval that should have found this key: Id Janussss
I wrote to Janu$$ asking if he was actually Janussss (which I assumed) and wanted him to please confirm he actually had something in his FOUND.txt.
After a while he answered confirming he was Id Janussss, but having no FOUND.txt. That was a shock! Was the generator not working
again? (some may remember the
episode with the win clients) And while I was struggling with life, Janu$$ wrote a PM titled
____TREFFER IN FOUND.txt____ (HIT IN FOUND.txt) - so he found FOUND.txt
The balance to the universe was restored.
Well - not entirely.
The pool found a 3rd genuine address with unspent outputs. Again uncompressed, again a minuscule amount. I seriously doubt though, that this address is an uncompressed address originally and I also doubt this is an experimental address. But I might be wrong and I would like to ask some independent party if he could perform some forensic analysis on the 3 addresses found.
edit: Also, I really am not comfortable with the fact, that we found out only by massive luck. While I do believe that Janu$$ would have found "FOUND.txt", I certainly would wish for something more failproof. Probably installing some kind of hook-find automatically or such.
Are they connected somehow?
How probable is it these from 2016 were originally actually uncompressed addresses?
Are they changes or are they the main transaction?
etc.
Because especially for this address I have a - call it feeling - that it was created as a compressed address and we found a privkey which resolves to this hash160 hashing the uncompressed pubkey. This would be a school book collision!
IMHO - if we could track down for
https://blockchain.info/de/address/1JwxZKTZiCqzBdYS38QM7ukKYqsSWQFRpT at least the info if that is a compressed or uncompressed address, then for a "compressed" answer we would have extremely strong indication of a collision.
Rico
