LBC History
From Perl Script to GPU-Accelerated Distributed System
The Large Bitcoin Collider has evolved significantly since its inception. What started as a simple experiment has grown into a sophisticated distributed computing project. This page chronicles the major milestones and technical evolution of the project.
The Early Days (2016)
Genesis
LBC began as a simple Go address generator paired with a Perl script that checked generated addresses against a hash table. Performance was modest: approximately 10,000-20,000 keys per second on a single CPU core.
First Optimization: C + Bloom Filter
A Bitcoin developer contributed a C-based generator with bloom filter checking, boosting performance to 300,000-500,000 keys per second. This represented a 25-50x improvement and proved the concept was worth pursuing further.
The Pooling Era (2016-2017)
Distributed Computing
The LBC Pool was established to coordinate parallel computation across multiple contributors. The server (Perl/Dancer2) partitions the search space and distributes work intervals to clients, ensuring no duplication of effort.
First Finds
The pool celebrated its first collision finds, proving that the search methodology was sound. These early successes attracted more contributors and motivated further optimization efforts.
GPU Acceleration (2017)
OpenCL Integration
The introduction of GPU support via OpenCL marked a major leap forward. The hybrid CPU+GPU architecture achieved approximately 22 Mkeys/s on a Lenovo P50 (Xeon E3-1505M v5 + Quadro M2000M), representing another order of magnitude improvement.
Architecture: ECC on CPU, Hash160 on GPU
The initial GPU implementation kept elliptic curve computations on the CPU while offloading hash160 computation and bloom filter checking to the GPU. This division of labor, while effective, left room for further optimization.
Notable Achievements
| Date | Milestone |
|---|---|
| 2016-09-21 | Start of LBC Pool |
| 2016-10-11 | 50 bits covered |
| 2016-12-18 | Puzzle #52 found |
| 2017-01-07 | Puzzle #53 found |
| 2017-01-18 | 51 bits covered |
| 2017-05-11 | Puzzle #54 found |
| 2017-11-07 | 52 bits covered |
The SAGAN Era (2025-Present)
SAGAN
The client was rewritten as "SAGAN" (named after Carl Sagan, continuing the tradition of the previous generator "Kardashev"). SAGAN is written in Rust with OpenCL for GPU computation and some advanced ECC routines remaining in C. The key improvement is unification: generator and client are now a single binary, eliminating the previous architecture of a Perl wrapper script around a C binary.
Benefits include:
- Unified codebase (generator + client in one binary)
- Memory safety from Rust
- Improved cross-platform support
- Simplified deployment
Server Modernization
The server infrastructure was overhauled with improved database and administration capabilities, streamlined operations, and preparation for multi-currency support.
n-k Symmetry
SAGAN leverages a mathematical property of elliptic curves: for every private key k, the key n-k (where n is the curve order) produces a related public key. This effectively doubles the search rate — each key computation checks two points in the keyspace simultaneously.
This also means we now search both the first and last 160 bits of the 256-bit keyspace, rather than just the lower range. See Theory for the mathematical details.
Future Directions
The roadmap includes:
- Full GPU Pipeline: Moving ECC computations to GPU for complete on-device processing
- Multi-Currency Support: Extending search to LTC, DOGE, and other compatible cryptocurrencies
Technical Evolution Summary
| Era | Technology | Performance* |
|---|---|---|
| 2016 Q1 | Go + Perl | ~15 Kkeys/s |
| 2016 Q2 | C + Bloom Filter | ~400 Kkeys/s |
| 2017 | C + OpenCL (KARDASHEV) | ~22 Mkeys/s |
| 2025 | Rust + OpenCL (SAGAN) | ~48 Mkeys/s |
* All speeds measured on reference machine: Xeon E3-1505M v5 + Quadro M2000M