Topic: Large Bitcoin Collider (Collision Finders Pool) - page 60. (Read 193481 times)

The absence of proof is not proof of absence, so I don't think that by not finding a single collision, it could somehow boost the Bitcoin price. On the other hand, the very existence of such a project, its active development and progress in and of itself could be a factor that would negatively affect the Bitcoin price (even if it is not given to succeed)...

And if this project gains a bit of publicity, it might, in fact, have a somewhat depressive effect on the price

The "Large Bitcoin Collider" is now in open beta: http://lbc.cryptoguru.org:5000/download

The download link for the 0.803 client should now work for everybody.

Thanks to the beta testers of the closed beta for their help finding and eliminating some bugs.
Installation of the client is still some command line munging, but should be doable for any Linuxer out there.

I'm really curious who will find the 1st bounty (https://blockchain.info/address/1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq) 

Rico

I got stats working.  

Some 4 lonely clients are munging blocks, so let's see if we've tomorrow glorious 37bits of the search space done.

Rico

edit:

Well - almost - some new clients claimed large chunks, so the stats went to 41.x bits of search space, but the server rejected these blocks later for missing POW, so we are at 36.93 bits.

First successful 'auto' work distribution today!

Started up two clients on two different machines, each of them asked the server for 10 minutes of work, depending on the overall speed of the client (number of CPUs * benchmarked block generation time). Which resulted in client1 geting 50 blocks for its 10 CPUs and client2 got 36 blocks for its 4 - evidently faster - CPUs. Each block is 2²⁰ compressed and 2²⁰ uncompressed addresses. Checking against all addresses (up to 1 Satoshi) with funds.


at the same time:


So within 10 minutes, these two clients checked the equivalent of 704512 pages on directory.io (180355072 addresses so ~ 300k addresses per second).


Rico

I'm using neither vanitygen nor oclvanitygen. Tried to get a grip on the code, but gave up for now.
Instead I hacked a C-Implementation of some bitcoin library, but it's slower than

https://github.com/saracen/bitcoin-all-key-generator

which I am using with slight modifications right now.

I also started to hack a pooling server, so if someone with a 64bit Linux box is interested to try the beta (available - say - next week), drop me a PM with your HW specs. I think we'll try it with 10 beta testers in the 1st wave.


Rico

What is the issue with applying your code to oclvanitygen instead of vanitygen? From what I understand you're unloading a pre-determined list into RAM and checking to see if any match, right?

Also, i LOVE the name haha

This.

~1820 “Rail travel at high speeds is not possible because passengers, unable to breathe, would die of asphyxia.” - Dionysius Lardner
~1950 "Continental drift is impossible ... young scientists shouldn't work on such a stupid idea" - MIT geology courses for undergrads
~1960 "A Proton/Neutron is indivisible" - Physics consensus
~1990 "You cannot have structures smaller than half of the light wavelength." - Physics consensus photolithography
[...]
~2016 "The DAO is safe" - slock.it


Of course one can assume the task is infeasible. And at the moment I have no indication of the contrary. On the other hand not doing something because everyone says it's infeasible seems just wrong. The list above would not seem ridiculous to us today if people were like that. If nothing else, I have learned in the past month a lot of things about efficient computation of the privkey -> pubkey -> *munge* *munge* -> address

That's why I agree with the GPU requirement. If someone could hack oclvanitygen to do certain bidding (throw out a list of uncomressed and compressed addresses for a given privkey-range), that would certainly leverage the project by at least 3 orders of magnitude.

As I started to explore how to efficiently distribute the work on several computers of mine, I did some more hacking towards a user-friendly client. I hope at least those interested in physics do like the name:





Rico

Without GPUs, i feel like this will take too long and people would lose interest. Really need to get this working with GPUs instead of CPUs. We really need to decide on a number, say 0.0001% of possible keyspace or something, and see how many collisions are found. We could extrapolate that number to the rest of the available keyspace and determine how feasible and attack would i.e. how much money would need to be spent, what type of equipment, etc.

I think we'll find that it's very infeasible, but I (and presumably you) could not find any actual data on this which is why it makes it interesting!

As for this code being dangerous, i mean i guess, but a quick search on Google shows that tools for hacking loaded keys already exist for free (Hashbasher is shared on this forum) and I haven't heard of anyone ever having coins taken from cold storage. However, if someone did win the cosmic lottery then it would be difficult to prevent them from taking the coins. I have never heard of a cold wallet being drained so I think the chances of this are similar to the chances of finding a collision in the first place.

Difficult to say, many lifes have been wasted doing much more ridiculous things.

I would start more basic.
I would take an "easy" algo like MD5 and try to learn how to efficiently and quickly create an endless amount of collisions for MD5, and then slowly (veeeeeeery slowly) move to harder algorithms.


 

Whether you do it or not, I have a perfect name for your project:

cracking_pots@home

.

The Large Bitcoin Collider (LBC - a.k.a. Collision Finders Pool) is a distributed effort to find private keys to BTC addresses that have funds on them.
See also https://lbc.cryptoguru.org/man/theory#what-we-do
It was using clients that have been developed in the Collision Attack Feasibility Study and later also a derivative of brainflayer (called "HRD-core"). Meanwhile, HRD-core is a complete re-implementation of the BTC address generation process and as such the fastest program on the planet!

Project homepage: https://lbc.cryptoguru.org
Downloads: https://lbc.cryptoguru.org/download
Statistics: https://lbc.cryptoguru.org/stats
Twitter: https://twitter.com/LBC_collider

News:

!!!Visit the New Thread 2.0!!!

• 2017-03-27: CPU generators with arulbero-ECC released with up to 79% speed increase
• 2017-03-25: again 250% speed increase with a new CPU/GPU hybrid generator! (Arulbero-ECC)

TODO:

Pending work/development on the LBC components.

Generator (hrd-core):

• unified generator (one binary for CPU and GPU)

LBC client

• More elaborated benchmark (not just maximal performance, but adaptive, also in relation to number of CPUs used)
• Aggregator: manage several generators even on remote servers by just one LBC client (postponed)

LBC server

• manual updates & extensions (GPU/OpenCL)

----

German thread: https://bitcointalksearch.org/topic/large-bitcoin-collider-collision-finder-pool-deutscher-thread-1581701