Pages:
Author

Topic: Large Bitcoin Collider (Collision Finders Pool) - page 24. (Read 193404 times)

legendary
Activity: 1120
Merit: 1037
฿ → ∞
... I start to believe the pool has found way more addresses than we currently know of....
How?
Operators not noticing the found.txt, or error in the maths?

Operators not noticing or not getting a chance to notice.

I actually had #50 in mind when thinking about "not noticing" and you know your share about that.  Wink

As for the "not getting a chance to notice", I can remember having a LBC client running on an AWS Spot Instance. Without hook-find, when the instance got terminated, I never got the chance to see if there was a FOUND.txt or not. (Schrödingers cat again...)

So I had to redo the interval, but I cannot eliminate the possibility that something similar happened elsewhere. From the LBC Server logs I cannot see if block intervals that have been correctly delivered were delivered from a machine which then became unavailable to the operator.

The maths is sound as far as we know. Actually when integrating the arulbero-ECC it got checked way more than the original libsecp256k1. => I trust that code more than ever.

Quote
If the first: let users give a mail adress in the startup call, stored on the server like the btc adress, send a mail when theres an update for the program, the blf or the found.txt file.
That'll alert the operators on time.

Yes, the next LBC client version will have something like that and more.

I'm thinking about actually nagging the user on screen with some message IF there is no hook-find AND there is a FOUND.txt present.

Executive summary:

Set up your hook-find. And if you haven't done so, until I come up with something look in your collider directory like once every ... ?? at least 48? hours for the presence of a FOUND.txt. Seriously - what's the point driving a client when you ignore the results?



Rico
hero member
Activity: 588
Merit: 541
Have you guys found any address with significant amount to reward your efforts yet?
hero member
Activity: 686
Merit: 502
Cue Jeopardy theme song.....

Yeah - writeup (see above) finished. Phew.

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.


Rico

Could we not introduce an upload option for the found.txt when something is found, like ftp. found--

?
legendary
Activity: 1100
Merit: 1058
... I start to believe the pool has found way more addresses than we currently know of....
How?
Operators not noticing the found.txt, or error in the maths?
If the first: let users give a mail adress in the startup call, stored on the server like the btc adress, send a mail when theres an update for the program, the blf or the found.txt file.
That'll alert the operators on time.
If the second: dang. Can't be. LBC is far luckier than expected anyways.
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
Cue Jeopardy theme song.....

Yeah - writeup (see above) finished. Phew.

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.


Rico

How do we do a hook again?
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Cue Jeopardy theme song.....

Yeah - writeup (see above) finished. Phew.

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.


Rico
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
1    Unknownhostname    661507    31s ---- around 175 times more ... still I never find anything Smiley)

A quantum of solace may be that you are co-responsible for this find.  Smiley



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.

1CSnQ1LnY37rwz8ezJn5xQrCrifZxExpWV


Cue Jeopardy theme song.....

member
Activity: 114
Merit: 11
John Snow is a lucky name  Cheesy
legendary
Activity: 1120
Merit: 1037
฿ → ∞
How did you find out, Rico?
I thought atm the client does not notice the server of a found.txt?

It doesn't. This time, the story is ripe for a Hollywood movie. Main protagonists:

Janu$$
johnsnow1
unknownhostname
rico666
arulbero


If someone (and we all may guess who that someone will be), will again claim this was or might have been staged...  Roll Eyes
Also, I do not believe the address found is an "experimental" address this time.
Please wait a couple minutes more (slow rescanning when importing key)


Rico
legendary
Activity: 1100
Merit: 1058
Nice! Cheesy

How did you find out, Rico?
I thought atm the client does not notice the server of a found.txt?
legendary
Activity: 1120
Merit: 1037
฿ → ∞
1    Unknownhostname    661507    31s ---- around 175 times more ... still I never find anything Smiley)

A quantum of solace may be that you are co-responsible for this find.  Smiley



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/trophies

2017-03-30 01:18:00 UTC

The 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

Code:
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

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
Code:
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

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

Code:
  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*


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

Roll Eyes No! I am the victim here.  Cheesy


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) 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:

Code:
$ 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*  Shocked

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  Cheesy

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

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
member
Activity: 62
Merit: 10
I don't know it yet either. But supposedly some other user has also found it. We'll have to wait and see what Rico tells us.

Double found Smiley is better ^^
newbie
Activity: 1
Merit: 0
23    johnsnow    3822    4m23    johnsnow    3822    4m
1    Unknownhostname    661507    31s ---- around 175 times more ... still I never find anything Smiley)

You're not alone! Me too...even with less power  Wink
I wish rico has been searched for the owner of the ID RealDuke instead of johnsnow  Cool

I don't know it yet either. But supposedly some other user has also found it. We'll have to wait and see what Rico tells us.
legendary
Activity: 3486
Merit: 2287
Top Crypto Casino
23    johnsnow    3822    4m23    johnsnow    3822    4m
1    Unknownhostname    661507    31s ---- around 175 times more ... still I never find anything Smiley)

You're not alone! Me too...even with less power  Wink
I wish rico has been searched for the owner of the ID RealDuke instead of johnsnow  Cool
member
Activity: 62
Merit: 10
Could the user operating currently(!) under the Id "johnsnow" contact me ASAP?

#51??

Better. :-)

#52?? ^^

-------------------------------------------------------------------

23    johnsnow    3822    4m23    johnsnow    3822    4m
1    Unknownhostname    661507    31s ---- around 175 times more ... still I never find anything Smiley)
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin

I think even better. I'm waiting for confirmation from another user, then I will make an announcement.

*** This is not related to #51 ***

(however, we're over 50% search space, so this too any moment now - I think.)

Rico

Nice, excited to see what it is!

Jude
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Better. :-)

He tripped over a gold mine didn't he? lol

I think even better. I'm waiting for confirmation from another user, then I will make an announcement.

*** This is not related to #51 ***

(however, we're over 50% search space, so this too any moment now - I think.)

Rico
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
Could the user operating currently(!) under the Id "johnsnow" contact me ASAP?

#51??

Better. :-)

He tripped over a gold mine didn't he? lol
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Could the user operating currently(!) under the Id "johnsnow" contact me ASAP?

#51??

Better. :-)
Pages:
Jump to: