Pages:
Author

Topic: Large Bitcoin Collider (Collision Finders Pool) - page 44. (Read 193484 times)

legendary
Activity: 3431
Merit: 1233
A legit collision?  Shocked Shocked

To prove there is a collision you've to prove two different inputs result in same output. Finding the private key for an existing address generated with insufficient entropy has nothing to do with finding a collision! See how carefully Rico avoids using the word collision except in the title of this 'project'?
legendary
Activity: 1442
Merit: 1186
A legit collision?  Shocked Shocked

I would be interested to know what method was used by the original user of
https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N to generate that address.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Transaction is from 2016-04-21 (around 3 months before the LBC project started)
Was found by someone else - not me this time
The funds are still on that address (it's only 0.0001 BTC)

Stay tuned.

https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N
https://lbc.cryptoguru.org/trophies

*93a2*

Oh and BTW: it is an uncompressed address, as was the only other one with funds on it.
All other hash160 the pool has found (puzzle transaction) are compressed addresses.


Rico
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
You broke it....

Best generator chosen: gen-hrdcore-sse41-linux64
Ask for work... Not an ARRAY reference at /usr/local/share/perl/5.22.1/Math/BigInt/Calc.pm line 1180.

Kind of. Let me guess: You are updating from .899 to .960
There are some things broken along the path, because I fixed so many things.  Smiley

  • libgmp can be completely ditched now.
  • instead of Math::BigNum::GMP it uses core modules - no need to install anything
  • but it needs recent versions of Math::BigNum[::Calc]
  • You also will need LWP::Protocol::https because of the SSL communication

Code:

> make sure you have openssl-devel (or equivalent) installed

> cpan

cpan> upgrade
cpan> install LWP::Protocol::https


Sorry for the hassle, but this fixes a nasty bug in bignum computations, where all block numbers above 40 digits were rounded - thus computed wrong. Fortunately we are still in the 12-15 digit space. It also will lower installation footprint and hassle in the future.



Rico

You fixed it....
legendary
Activity: 1120
Merit: 1037
฿ → ∞
You broke it....

Best generator chosen: gen-hrdcore-sse41-linux64
Ask for work... Not an ARRAY reference at /usr/local/share/perl/5.22.1/Math/BigInt/Calc.pm line 1180.

Kind of. Let me guess: You are updating from .899 to .960
There are some things broken along the path, because I fixed so many things.  Smiley

  • libgmp can be completely ditched now.
  • instead of Math::BigNum::GMP it uses core modules - no need to install anything
  • but it needs recent versions of Math::BigNum[::Calc]
  • You also will need LWP::Protocol::https because of the SSL communication

Code:

> make sure you have openssl-devel (or equivalent) installed

> cpan

cpan> upgrade
cpan> install LWP::Protocol::https


Sorry for the hassle, but this fixes a nasty bug in bignum computations, where all block numbers above 40 digits were rounded - thus computed wrong. Fortunately we are still in the 12-15 digit space. It also will lower installation footprint and hassle in the future.



Rico
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
You broke it....

Best generator chosen: gen-hrdcore-sse41-linux64
Ask for work... Not an ARRAY reference at /usr/local/share/perl/5.22.1/Math/BigInt/Calc.pm line 1180.


legendary
Activity: 1120
Merit: 1037
฿ → ∞
Test check failed! Expected 4 hits and got 2!

This happens at the moment. Probably it's the test itself failing (I had the generator showing uncompressed/compressed keys swapped.)

Basically if you do

Code:
./gen-hrdcore-avx2-linux64 -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000

on the command line, it should spill out 4 lines (with hash160 and priv keys +  1 line challenge response). This is proof that all still works. I expect this to be fixed in the next version.

Rico
member
Activity: 62
Merit: 10
root@soft:~# ./LBC -x
Will use 24 CPUs.
Best generator chosen: gen-hrdcore-avx2-linux64
New generator found. (DL-size: 0.51MB)
New BLF data found. (DL-size: 191.37MB)
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 399037 keys/s per CPU core.
Test check failed! Expected 4 hits and got 2!
Ending test run.


------------------------------------------------
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Yay!

Thanks to LBC I had the motivation to look into the secp256k1 lib and could make two subroutines faster by 6 to 7 orders of magnitude (that's 1 to 10 million times faster)

https://github.com/bitcoin-core/secp256k1/pull/437

Quote
field_get_b32: min 0.647us / avg 0.666us / max 0.751us
field_set_b32: min 0.551us / avg 0.571us / max 0.624us

becomes

field_get_b32: min 0us / avg 0.0000000477us / max 0.000000238us
field_set_b32: min 0us / avg 0.0000000238us / max 0.000000238us

So some day your dear bitcoin client will be faster thanks to this.

Seems I was wrong and secp256k1 hackers actually are interested in improving secp256k1, which motivates me to look at some other parts of secp256k1 where I sense more code smell... If only the docs were better (a.k.a. existent), I could spend more time on code than doing detective work.


Rico
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Benchmark info not found - benchmarking... 'gen-hrdcore-sse42-linux64' not found/executable.

You could also try ./LBC -u  which should perform a couple of auto-updates.
If all fails, there is still the manual way. LBC has recognized the sse4.2 generator to be best for your CPU, so you can:

  • go to http://ftp://ftp.cryptoguru.org/LBC/generators/
  • fetch the newest one with sse42 in it (170105-5aef41bea5c64dbf8c977195b67ba796.gen-hrdcore-sse42-linux64.bz2 as of now)
  • bunzip2 it
  • rename it to gen-hrdcore-sse42-linux64
  • make sure it's executable


Rico
member
Activity: 114
Merit: 11
wget http://ftp://ftp.cryptoguru.org/LBC/client/LBC
chmod +x LBC
./LBC -h


then ./LBC -x
Benchmark info not found - benchmarking... 'gen-hrdcore-sse42-linux64' not found/executable.

help pls
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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
legendary
Activity: 1948
Merit: 2097
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)

Quote
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
newbie
Activity: 23
Merit: 0
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

legendary
Activity: 1120
Merit: 1037
฿ → ∞
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
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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
newbie
Activity: 23
Merit: 0
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://bitcointalksearch.org/topic/m.16523548

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.
legendary
Activity: 1948
Merit: 2097
legendary
Activity: 1120
Merit: 1037
฿ → ∞
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:

Quote
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
legendary
Activity: 3431
Merit: 1233
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"?
Pages:
Jump to: