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


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

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


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

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. 

• 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

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

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

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

ok, 1st, im stupid. with that in mind please go easy on me.

this project is trying to find private keys to random public addresses with btc in it, is it not?

i thought that was, for all intents and purposes, impossible due to the truly astronomical odds.

so how is this finding them?

or do i have the whole purpose and results of this project wrong.

btw love the name.

Time since inception: 6 months
Number of keys generated: 250 trillion
Number of unspents found: 2 (genuine, no bounties etc.)
Total collisions confirmed:   0
Current generation speed:  23.71 Mkeys/s (*)

Updated BLF on server. Upon restart, your clients should auto-update.


(*) The equivalent of about 185000 pages on directory.io  where each address (compressed and uncompressed) checked against ~ 9000000 addresses with unspent outputs - per second.


Rico

If you have something, by all means code and advice is welcome.

I have an unpublishable GPU prototype based on vanitygen. It's basically half the speed of vanitygen (which has 15 MKeys/s on my notebook), as it uses 2 passes, one for compressed and one for uncompressed public keys. Also, it requires around 4GB RAM on startup until the AVL data structures are fiddled up. So on my notebook, the GPU prototype needs around 4GB memory on startup and 3.4 GB in GPU RAM and gives around 7MKeys/s.

Compared to this, SHA256 and RIPEMD160 code from hashcat 3.2 indicates around 150 Mega-hash160(x) per second and I am working on bringing the private key -> x (a.k.a. EC arithmetics) to the GPU also. For that, I need to strip down everything not relevant to generation, wrap my head around OpenCL distribution of the RMD160(SHA256(EC(private key))) x 2

Then I have a GPU implementation I got some time ago from a user - allegedly working, but (according to his own claims) with a bad performance. This solution seems Windows and AMD GPU only, and quite honestly I have not even been able to compile it.

All in all I agree that what we currently see as total pool speed, in a few weeks may come from one mid-range GPU.


Rico

If anyone's interested, from this article:


Almost 2 MKeys/s (without sha256/ripmed160) and on another curve (Curve25519).

Is it possible to do better on secp256k1?