Large Bitcoin Collider (Collision Finders Pool)

[rico666]

May I ask, do you guys store private keys on a server? Because the chance of a collision is currently so miniscule, but if bitcoin picks up, someone generating and using an address in the future it's much more probable.

There is no way the server could keep up with the generated private keys. All PK generation and checking occurs on the client and after the client has checked the keys, they are discarded. All the server does is distributing chunks of work to the clients, receiving ACKs for work done and performing multi-interval arithmetic to ensure nothing is left out and nothing is done (unnecessarily) twice.

The main reason for the offline processing is speed and scalability - of course. But I also like to leave the decision what to do with a PK found in the clients hands to not get involved in case the client decides to ... hmm ... reward himself.

Right now, the pool is just getting warm. There are still few clients and - to be honest - the pool is not yet searching in the optimum keyspace (and yes: I know where that is   )

As for the pk storing: I do such a thing too, see this german post: https://bitcointalk.org/index.php?topic=1587485.msg15941399
But it's only an experiment for efficient PK storage and the server I run the experiment on has to recompute the PKs again - these from the pool cannot be reused. (Well - actually I plan to have a feature in the LBC client where it will also store the generated keys on disk instead of discarding them after checking... but time oh time... So theoretically I could let run a LBC client on the PK storing machine and kill two birds with one stone.)

Rico

[Jude Austin]

Maybe I am being super duper optimistic but on the Statistics page of your website there should be a column for "Collisions" next to "Blocks done" for the client ID.

Also, could you add an option to LBC to write any collisions to a text file? This way if my computer crashes, power goes out, etc etc then I don't lose the "Collision".

I would add it but I absolutely hate Perl and refuse to even look at it, haha.

Thanks,
Jude

[rico666]

Maybe I am being super duper optimistic but on the Statistics page of your website there should be a column for "Collisions" next to "Blocks done" for the client ID.

The clients stats will be extended (like client speed etc.), but for the "found" information there will be a separate page. LIke "What has the pool found so far, when which client had the hit, type of find (bounty/true collision) etc.

Also, could you add an option to LBC to write any collisions to a text file? This way if my computer crashes, power goes out, etc etc then I don't lose the "Collision".

Great idea. I will add that - as default behavior.

edit: although I believe some Linuxers at least solve that by doing something like ./LBC -c x -t blah | tee file.txt
but I will add it nonetheless.

I would add it but I absolutely hate Perl and refuse to even look at it, haha.

  I have the same feelings for Python and PHP.

Seriously - if someone has ideas what to do, I will be happy to pick them up.


Rico

[DebitMe]

Sweet to see you have a Windows version out.  I will try to get it tried out this weekend, but I may be a little busy since tax day is coming up, in that case I will try next week at some point.

[rico666]

Hi all,

this is a rather large announcement and I am very excited about this. So consider all of the following text in ALL CAPS, bold, with emphasis and underlined.  

I have pushed out the new version 0.823 of the client for Linux and Windows, 64 and 32 bit. This version is a significant step towards serious collision attempts as it:

• is about 3 times faster than the previous version!
• however, it uses less space in memory and on disk
• has the "persistent-found" feature as suggested by Jude Austin

The pool also offers a new bounty (1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP) and with current search speeds it is within comfortable reach of the pool.

The pool will also have searched the equivalent of 3 billion pages on directory.io anytime soon now. Imagine clicking through that!  

edit: As of tonight (2016-09-14 CET), the pool has searched one trillion addresses.

Rico

[Jude Austin]

Hi all,

this is a rather large announcement and I am very excited about this. So consider all of the following text in ALL CAPS, bold, with emphasis and underlined.  

I have pushed out the new version 0.823 of the client for Linux and Windows, 64 and 32 bit. This version is a significant step towards serious collision attempts as it:

• is about 3 times faster than the previous version!
• however, it uses less space in memory and on disk
• has the "persistent-found" feature as suggested by Jude Austin

The pool also offers a new bounty (1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP) and with current search speeds it is within comfortable reach of the pool.

The pool will also have searched the equivalent of 3 billion pages on directory.io anytime soon now. Imagine clicking through that!  



Rico

Yay, downloading the new version now!

3 times faster!!! Woo!

Just curious, what did you do to get 3X the performance?

[rico666]

Yay, downloading the new version now!

3 times faster!!! Woo!

Just curious, what did you do to get 3X the performance?

Basically I got rid of the whole base58 processing. The generator now simply creates a hash160 from uncompressed and compressed public keys.
The missing base58 munging, four SHA256 computations less per PK and the constant length of hash160 contrary to base58 (which allowed some more optimizations) summed up pretty good.

I still believe more can be done, especially with GPUs - but it's still an open quest.

Rico

[rico666]

Attention! Windows version crashes if you try to use more than 1 CPU. And it also crashes if you want to use 1 CPU for longer periods  Workaround: start in as many windows as you have/want-to-use CPUs

Code:

perl LBC -c 1 -t 1

. It's super-paranoia and super-annoying, but at the moment your best bet to participate with Windows.

I'm figuring out better ways around this situation.


Rico

[rico666]

Most people have used the client with the implicit/default "auto" mode for search page assignment.

I have just added this to the README FAQ which will be in the next release:
(next release will allow to run on small Amazon EC2 instances and finally, finally the Windows client is stable!)

Code:

Q: What if I want to check a specific range on directory.io?

A: Each page on directory.io lists 128 private keys and the
   corresponding uncompressed and compressed addresses. The LBC checks
   in blocks/pages of 20bit size (1048576 PKs) and is therefore like
   checking 8192 pages on directory.io
   Say you would like to use LBC to check all that is on the pages
   569716666483 to 569716830323 on directory.io, you would call
   LBC -p 69545491-69545512 -c 0
   because 69545491 = int(569716666483/8192) and
           69545512 = int(569716830323/8192) + 1
   Takes a little over 2 minutes on a modern notebook and in fact
   you have checked a bigger range 569716662272-569716834304
   (172032 pages) on directory.io

So basically, you would like to check - just for fun of course - some 100000 pages on directory.io for addresses with funds on them. You cannot do that by clicking around, unless you're a real immortalist type person. Also wget-ing doesn't even qualify as snail attempt and the LBC "auto" mode doesn't quite cut it.

Enter the above FAQ:

Because every block checked in LBC is exactly as big as 8192 pages on directory.io, all you have to do is to compute the lower and upper bound of your search interval by computing

Code:

lbc_from = int(directory.io_from/8192)
lbc_to   = int(directory.io_to/8192) + 1

and then just start LBC with

LBC -p lbc_from-lbc_to -c <num of cpus unless you're on windows in which case it's 1>

Et Voila! - you may check hundreds of thousands of pages against millions of addresses with funds on them within minutes.

A little warning:

Some people have done this already with insane numbers/ranges. This is a shortcut to the client-blacklist. Count and think before you
enter some numbers there. If you have trouble with counting and thinking, also wait for the new release, which does that for you and limits max. work to 1 day.


Rico

[rico666]

I've added a new stat to http://lbc.cryptoguru.org:5000/stats

The effective search space until something (except bounties) is found is 136.75 bits. Given current search speed, the probability to find an address with funds on it within the next 24h is 0.0000000000000000004524764939984744324231018884855317923702%.

2 hours later...

The effective search space until something (except bounties) is found is 136.75 bits. Given current search speed, the probability to find an address with funds on it within the next 24h is 0.0000000000000000004556237169019694490259313869322519435127%.

Now you may think that number is ridiculously small. For me, it is surprisingly high. First off, before the project started, it was 0, but let's assume it was
0.0000000000000000000000000000000000000000000000000000000001%. Then today, when I started this stats computation, the probability of a collision within the next 24h is 4524764939984744324231018884855317923702 times bigger than when the project started.

You still may think the number is small. Even if nothing happens and the pool remains at its current capacity, this number will grow. Because that's actually the effect you can observe in the "2 hours later" probability. If the address generation capacity of the pool rises (better clients x more clients), this number will start to exhibit geometric growth.


Rico

[johan11]

find something on the Collider is a better chance than solo mining

[ryanc]

FWIW, I just posted this: https://rya.nc/forensic-bitcoin-cracking.html

The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.

[STT]

Attention! Windows version crashes if you try to use more than 1 CPU. And it also crashes if you want to use 1 CPU for longer periods  Workaround: start in as many windows as you have/want-to-use CPUs

Code:

perl LBC -c 1 -t 1

. It's super-paranoia and super-annoying, but at the moment your best bet to participate with Windows.

I'm figuring out better ways around this situation.


Rico

Is that threads or actual physical cpu.   Theres cpu with 44 threads or 22 cores now and quite a few old server chips with about half that so maybe thats a useful source of power.   Not sure its all minor compared to gpu parallel processing power though I couldnt even crack a secure rar password nevermind something as involved as this

[rico666]

FWIW, I just posted this: https://rya.nc/forensic-bitcoin-cracking.html

The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.

Congrats, that's an HD wallet you hit.


Rico

[becker]

Nevermind downloaded the latest version and now no error.

C:\Users\Worker1\Downloads\LBC-latest_w64\LBC-client>perl LBC -c 4 -t 10:0
Reading balances... storable found - using that (faster)...  done.
Fetching adequate work... got block interval [669627-669682]
..Attempt to free unreferenced scalar: SV 0x1537d6978, Perl interpreter: 0x14662
bca8 at C:/Strawberry/perl/vendor/lib/Term/ReadKey.pm line 334.
..........Free to wrong pool 21b86ce50 not 2c69badf0 at C:/Strawberry/perl/vendo
r/lib/Term/ReadKey.pm line 334.


Get that every time I run it, and the perl interpreter crashes.  Windows 7 64 bit, installed the strawberry perl.

[rico666]

Is that threads or actual physical cpu.   Theres cpu with 44 threads or 22 cores now and quite a few old server chips with about half that so maybe thats a useful source of power.   Not sure its all minor compared to gpu parallel processing power though I couldnt even crack a secure rar password nevermind something as involved as this

On windows, it's threads, but you should - on windows - assign each thread it's own CPU. So on aforementioned server, for max performance, start around 20 times perl LBC -c 1

AND

use  http://62.146.128.45//download/LBC-0.827_w64.zip

as this is a Windows version without the aforementioned instability. Several clients with this version ran for over 48h now.

Or wait a couple of hours, as I will put a more polished windows 0.830 (or so) in the download section today.

Rico

[rico666]

And - BTW - we seem to have quite some new clients, the pool capacity is rising  

Which means, the bounty will be found definitely today - probably within the next 6-8 ~2 hours like now.

edit: Thriller! Some client already claimed the block containing the bounty, but did not deliver it back, so the server will reissue it again...

edit2: Unbelievable. Do you know that scene from pulp fiction? https://youtu.be/Vr6aIURrFvE?t=77

I am being reminded of that. Congrats to client 273870c7c71bfe2e82e2a537580e63cf you threw away the 2nd chance the pool gave you.
So pool is reissuing again.   Hey! We have time.

Rico

[rico666]

Pool halted for emergency fix. Sorry for the inconvenience. More info soon.

Sun Sep 18 19:17:59 CEST 2016

Shitty bug in Windows client which caused it not to find all matches. I found out after client got a block containing the bounty, delivered it back and no bounty was claimed. In the binary stream, Windows replaced some "0a" with "0a0d" - or whatever. So yeah, it's official: I'm an idiot for relying on UNIX default behavior. Now that stream is set unconditionally to ":raw". => Bug found and fixed, new versions in the making. Pool will demand at least version 0.831 which you will find for download shortly.

Sun Sep 18 19:36:55 CEST 2016

Packages are available for download.
Would the operator of client 06be1b85e82e538529d23390c6fd06c5 contact me via PM: I will give you the bounty out-of-band, because you would have found it
Please everyone do a LBC -x first. This should simulate 3 hits under various conditions. Only then you can be 100% sure you will find everything. (needs to be done only once)

Sun Sep 18 19:48:53 CEST 2016

Had to roll back 25000 blocks. We all know how small the chance is that they contained something an old buggy windows client overlook, but just to be sure.
1 day of work lost.  


Rico

[mistercoin]

PS: The LBC Pool found it's 1st bounty.

Why didn't the Bitcoin price crash already?

Because a Bounty is supposed to be found? Especially if it has been placed/planted intentionally in the pools vicinity?

Next Bounty: https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8

Well, let us know when you find something worthy of general public's attention. Or, rather, let me be the first to know so that I could safely and timely get rid of my Bitcoin stash (however small it might be) before the markets implode on hearing the news...

Or even try to short some coins

The price of Bitcoin will not budge because of this project. Even if >100BTC was found, nobody is going to worry about this I think the developer here is just having a bit of fun and giving anyone who wants to join in a chance of finding a small bounty. Projects like this have existed since BTC was born. If you have nothing constructive to contribute and all you post is pure negativity and FUD, then I am sure you can find another thread/forum that you can vent in. We get it, you disapprove. Now move on and stop being a nuisance (no offense intended).

Mistercoin-

[rico666]

The price of Bitcoin will not budge because of this project. Even if >100BTC was found, nobody is going to worry about this I think the developer here is just having a bit of fun and giving anyone who wants to join in a chance of finding a small bounty. Projects like this have existed since BTC was born. If you have nothing constructive to contribute and all you post is pure negativity and FUD, then I am sure you can find another thread/forum that you can vent in. We get it, you disapprove. Now move on and stop being a nuisance (no offense intended).

While I do have fun with this project (at least when all runs well), I take it seriously and it's not just meant as some weird kind of faucet. I think I know statistics pretty well.
I also think I know the speed of my ZX Spectrum (1982) and of my GTX 1080 (2016). That's 34 years and the speedup is ... homework for everyone interested.
Let's see if this pool, or bitcoin or we all are here in 34 years before we speak of the "age of the universe".


Rico