Large Bitcoin Collider (Collision Finders Pool)

[rico666]

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


Rico

[1714687247]

1714687247

[1714687247]

1714687247

[1714687247]

1714687247

[1714687247]

1714687247

[becoin]

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?

The correct question is:
How do we know it is not one of your own keys?

[rico666]

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#msg16523548

ff.


Also, as for the theory behind the pool: https://lbc.cryptoguru.org/man/theory
educate 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

[becoin]

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#msg16523548

ff.

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.

[UGMZ]

Let me get this right?  This is a project to gain private keys from wallets that have funds in them? correct?

[Haze]

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


Rico

This is nice since once the pool finds more we can extrapolate and glean some valuable information about the feasibility of this project.

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?

[rico666]

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

[rico666]

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

[rico666]

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:

Code:

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

Code:

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

[rico666]

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

[lizidev]

Well, Tokes uses Incent's ICO management platfrom while the others use Lisk's?
I'm not really sure though!

[becoin]

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"?

[rico666]

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 glory

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

[arulbero]

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

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

Code:

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 you seen this version of secp256k1 library?    https://github.com/llamasoft/secp256k1_fast_unsafe

[privatenode]

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#msg16523548

ff.


Also, as for the theory behind the pool: https://lbc.cryptoguru.org/man/theory
educate 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

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.

[rico666]

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

or

https://lbc.cryptoguru.org/stats


The 2nd is merely a nginx reverse proxy for the 1st.



Rico

[rico666]

Have you seen this version of secp256k1 library?    https://github.com/llamasoft/secp256k1_fast_unsafe

No I didn't, but I will look into it as it sounds promising. Thanks for the pointer.


Rico

[privatenode]

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

or

https://lbc.cryptoguru.org/stats


The 2nd is merely a nginx reverse proxy for the 1st.


Great, i'll send you two node's ssh runs lbc tmr , you can check the connection speed we were talked about , that condition is extremely horrible in my territory.

Rico

[arulbero]

Have you seen this version of secp256k1 library?    https://github.com/llamasoft/secp256k1_fast_unsafe

No I didn't, but I will look into it as it sounds promising. Thanks for the pointer.

Rico

Secp256k1 library has two key generation versions :

1) Default one is resistant to Side Channel Attack   :  secp256k1_gej_add_ge (7 mul+5 square)
2) Faster version uses 8M+3S :  secp256k1_gej_add_ge_var (8 mul + 3 square)

The secp256k1 gej add ge method which is also the default method for key generation, uses 6 secp256k1 fe cmov operations which has a cost approximately 0.2 M. The rationale for writing code in this way is stated by Wuille in the following comment:

” This formula has the benefit of being the same for both addition of distinct points and doubling”

The purpose of making addition and doubling using the same function is to prevent side channel attacks, as point doubling is otherwise much cheaper than point addition.

These 2 functions are defined here:
https://github.com/bitcoin-core/secp256k1/blob/master/src/group.h
https://github.com/bitcoin-core/secp256k1/blob/master/src/group_impl.h

What function do you use in your program?

source:
https://eprint.iacr.org/2016/103.pdf
http://www.nicolascourtois.com/bitcoin/paycoin_BrainWallet3br.pdf

[rico666]

What function do you use in your program?

secp256k1_gej_add_ge_var, and mainly in a descendant of the secp256k1_ecmult_gen2 function from here:

https://github.com/ryancdotorg/brainflayer/blob/master/ec_pubkey_fast.c

Which - meanwhile - looks like this in my code:

Code:

static void
hrdec_mult_gen2(secp256k1_gej *r,
                const uchar *seckey) {

  secp256k1_gej o1;
  secp256k1_gej s1, s2, s3, s4, s5, s6, s7, s8,
                s9,s10,s11,s12,s13,s14,s15,s16;


  secp256k1_gej_set_ge(&o1, &prec[      seckey[31]]);
  secp256k1_gej_add_ge_var(&s1, &o1, &prec[ 256 + seckey[30]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[512 + seckey[29]]);
  secp256k1_gej_add_ge_var(&s2, &o1, &prec[ 768 + seckey[28]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[1024 + seckey[27]]);
  secp256k1_gej_add_ge_var(&s3, &o1, &prec[1280 + seckey[26]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[1536 + seckey[25]]);
  secp256k1_gej_add_ge_var(&s4, &o1, &prec[1792 + seckey[24]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[2048 + seckey[23]]);
  secp256k1_gej_add_ge_var(&s5, &o1, &prec[2304 + seckey[22]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[2560 + seckey[21]]);
  secp256k1_gej_add_ge_var(&s6, &o1, &prec[2816 + seckey[20]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[3072 + seckey[19]]);
  secp256k1_gej_add_ge_var(&s7, &o1, &prec[3328 + seckey[18]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[3584 + seckey[17]]);
  secp256k1_gej_add_ge_var(&s8, &o1, &prec[3840 + seckey[16]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[4096 + seckey[15]]);
  secp256k1_gej_add_ge_var(&s9, &o1, &prec[4352 + seckey[14]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[4608 + seckey[13]]);
  secp256k1_gej_add_ge_var(&s10, &o1, &prec[4864 + seckey[12]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[5120 + seckey[11]]);
  secp256k1_gej_add_ge_var(&s11, &o1, &prec[5376 + seckey[10]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[5632 + seckey[9]]);
  secp256k1_gej_add_ge_var(&s12, &o1, &prec[5888 + seckey[8]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[6144 + seckey[7]]);
  secp256k1_gej_add_ge_var(&s13, &o1, &prec[6400 + seckey[6]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[6656 + seckey[5]]);
  secp256k1_gej_add_ge_var(&s14, &o1, &prec[6912 + seckey[4]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[7168 + seckey[3]]);
  secp256k1_gej_add_ge_var(&s15, &o1, &prec[7424 + seckey[2]], NULL);
 
  secp256k1_gej_set_ge(&o1, &prec[7680 + seckey[1]]);
  secp256k1_gej_add_ge_var(&s16, &o1, &prec[7936 + seckey[0]], NULL);

  secp256k1_gej t1;
  
  secp256k1_gej_add_var(&t1,  &s1,  &s2, NULL);
  secp256k1_gej_add_var(&s1,  &s3,  &s4, NULL);
  secp256k1_gej_add_var(&s2,  &s5,  &s6, NULL);
  secp256k1_gej_add_var(&s3,  &s7,  &s8, NULL);
  secp256k1_gej_add_var(&s4,  &s9, &s10, NULL);
  secp256k1_gej_add_var(&s5, &s11, &s12, NULL);
  secp256k1_gej_add_var(&s6, &s13, &s14, NULL);
  secp256k1_gej_add_var(&s7, &s15, &s16, NULL);


  secp256k1_gej_add_var(&s8, &t1, &s1, NULL);
  secp256k1_gej_add_var(&s1, &s2, &s3, NULL);
  secp256k1_gej_add_var(&s2, &s4, &s5, NULL);
  secp256k1_gej_add_var(&s3, &s6, &s7, NULL);

  secp256k1_gej x1,x2;

  secp256k1_gej_add_var(&x1, &s1, &s2, NULL);
  secp256k1_gej_add_var(&x2, &s3, &s8, NULL);

  secp256k1_gej_add_var(r, &x1, &x2, NULL);
}

I am highly dissatisfied with the code and the runtime still. All I managed by the tree-addition was to spare myself one secp256k1_gej_add_var call. All this EC arithmetic looks so clumsy...

I'll probably try to find some more efficient way how to form the sum of N secp256k1_gej values.


Rico