About the LBC (FAQ)
Behold! The Large Bitcoin Collider
What is LBC?
The "Large Bitcoin Collider" (LBC - a homage to LHC) is a distributed effort to find at least one collision of private Bitcoin keys by creating addresses to private keys in a continuous 2160 range. These are checked against the list of known BTC addresses with funds on them. In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.
*Gasp* That's Illegal! Racist! Impossible!
It's neither of these. For the history and reasons why this project started, see this topic on bitcointalk. For the distributed effort, see also this. It is not illegal to search for colliding private keys. It may be illegal - depending on the jurisdiction you are in - to actually claim possession of funds found that way. It is also not impossible and actually the pool has already found several private keys - see pool trophies.
Why doing this?
Because current consensus is "that's impossible" and that is a gauntlet thrown down. It is a technical challenge and in mankind history, many things deemed impossible later turned out to be perfectly possible. This project is the practice part of the theory behind Bitcoin encryption and protection of funds. See our take at the theory behind all this.
Why should I use a Pool instead of going Solo?
The pool raises your chances significantly. If you put the client in auto mode, it gets only the work from the pooling server that hasn't been done yet anywhere else. So instead of solo crunching some blocks that might have been inspected already (and therefore your chance to find something is ZERO), you know your client gets unchartered territory. At least within this project.
I heard the Server can Remote-Execute Code on my Client? WTF?
Yes, the server can do that and the server uses that only for client consistency checks and dealing with client inconsistencies. Despite security-experts turning blue in their face, this is actually a security feature: namely security of the server and validity of the data sent to the server. In order to ensure this data consistency in this specific use case, the server has to have the power to execute turing-complete checks on clients to trust them. As proof of validity, the client submits itself to the server. Let us rephrase it in simple terms: If you want to board a plane, for the planes' - and thus also your security, you have to undergo certain scanning procedures and comply to restrict some of your freedom or you will not board that plane. Same story.
How do I know the Pool doesn't scam me?
All key search operations are decentral and done on the client. There is no way a single central instance (the server) could keep up monitoring all that work in real time. If your client finds something, it prints this on your screen and into a local file "FOUND.txt". There is no server communication required and you can check easily: Start LBC with some range you know there are finds, pull your computer off the network. See?
If I find a private key, I will keep the funds!
See above. Depending on your jurisdiction, this may be considered theft and is therefore illegal. However, there are many jurisdictions where you could perfectly legally claim 5-10% of the value found. So you should consider if you want 100% and become a criminal or if you get 10% and still be a law abiding citizen. Having said all that please consider though, IANAL. Also, even taking aforementioned 10% from addresses like e.g. 1Archive1n2C579dMsAu3iC6tWzuQJz8dN would make you an unconditional jerk. There are Bitcoin addresses of non-profit organizations you should contribute to - not seize any part of the funds.
Ok, how to proceed if I find something?
You transfer the funds to some custodial address and immediately after that transaction is confirmed announce
this publicly in the LBC thread
@bitcointalk here. Why? Because as the pools'
forefront (i.e. current search space) is known, a mere notice of find might allow an attacker to find the
private key also on his own.
While it is left to the pool clients what they do with a find and how they notice the public about it, please be aware, that the pool logs which client did when which interval and the pool also knows the IP address of the client at that time.
Should - in retrospect - someone prove his rightful ownership to funds which evidently must have been discovered by the pool, he may be provided with that information.
For specific find-events, when the pool actually found something, please go to the Trophies page.
- 2017-04-09: 51bits, 2140 tn keys searched
- 2017-03-25: 50bits, 1120 tn keys searched, >500 Mkeys/s
- 2017-03-23: over 1000 tn keys searched
- 2017-03-09: 49bits, 560 tn keys searched
- 2017-01-27: 48bits, 280 tn keys searched
- 2016-11-11: 47bits, 140 tn keys searched
- 2016-10-21: 46bits, 70 tn keys searched, ~70 Mkeys/s
- 2016-10-09: 45bits, 35 tn keys searched
- 2016-10-01: 44bits, 17.65 tn keys searched
- 2016-09-27: 43bits, 8.75 tn keys searched, 23.5 Mkeys/s
- 2016-09-25: 42bits, 5 tn keys searched, 18.8 Mkeys/s
- 2016-09-23: 41bits, 3 tn keys searched
- 2016-09-21: 40bits searched
- 2016-09-20: Testing new client prototype 13x speedup
- 2016-09-19: 2nd bounty found (claimed some 20h later)
- 2016-09-18: observed and fixed a nasty Windows bug. Pool rollback!
- 2016-09-17: stats with 24h find probability
- 2016-09-14: 500 bn keys (1 tn addresses) searched
- 2016-09-10: New client available 3x speedup
- 2016-09-07: Windows clients - although quite bad - available
- 2016-08-29: 1st "real" pool bounty found
- 2016-08-10: pool inception - roughly 0.15 Mkeys/s
- 16 Jul/Aug: stand-alone experiments, then client and pool development
- 2016-07-28: standalone client: 36bits searched