Project Overview

[Dingo]

I only started to use this Project as it uses the Radioactive@home detectors on the sub project Yarrow (radiation monitor): I have opted out of all the other sub projects.  This is a personal choice and not a recommendation do what you like here.
 
Project Summary

Kampylos: gravitational microlensing
A distributed-computing effort to exhaustively model binary-lens gravitational microlensing events -- a background star's light bent by a foreground pair of masses -- using the same donated compute as the rest of this project. Full project details, source code, and published results are at the Kampylos repository.

Finding every viable solution for one of these events requires an expensive search over the lens parameters (mass ratio, separation, source trajectory angle) -- the fit landscape often has several genuinely different parameter combinations that explain the same observed light curve almost equally well, and it's easy to miss one if you're not looking hard enough. Public sky surveys (OGLE, MOA, KMTNet) have alerted on tens of thousands of these events since the 1990s, and only a fraction of the ones showing this kind of binary-lens behavior have ever gotten a full, exhaustive treatment -- it's normally too computationally expensive for any one research group to do for every event, so most published analyses stop at whichever solution was found first, not a complete accounting of the parameter space.

This is exactly the kind of problem donated volunteer compute is good at that a single research group's own compute budget isn't: running the same exhaustive grid search across a far wider parameter range, over far more archival events, than any one group could normally afford.

What this can realistically produce
In order of how confident we are in each:

A full solution-map dataset for tens of thousands of archival events -- this doesn't currently exist anywhere, and simply completing the search produces it. Published openly, not kept private.

Real corrections to the published literature -- for at least some events, an exhaustive search will very likely turn up a better-fitting or additional solution than what's currently published, since the standard approach is known to sometimes miss a genuine alternative.

Possibly a genuine new discovery -- an anomaly nobody has fully modeled turning out to be a planet signal, for instance. Real, but not something we can promise in advance out of tens of thousands of events.

The Nancy Grace Roman Space Telescope has already launched, in August 2026, eight months ahead of its original schedule; its own dedicated microlensing survey starts science operations around 2027, and is expected to add thousands more binary-lens events a year at a rate current per-event analysis methods can't fully keep up with. This search runs against today's archival events already -- it doesn't wait on Roman -- but is built to fold Roman's much larger stream of events in as they start arriving.

Why should I trust this one?
Unlike the Bitcoin puzzle hunt described elsewhere on this page, there's no money or wallet involved anywhere in Kampylos -- the trust question here is about data and methodology, not fund custody. The source photometry comes entirely from public survey archives (linked in the repository), the search code is open source, and results (including the full solution-map data, not just whichever answer looks most interesting) are published openly rather than cherry-picked. Nothing about running this app is any different, risk-wise, from running Potamos or Keraunos -- same sandboxed BOINC app, same "reads a small work packet, writes back a result" model, nothing else on your machine.

Nostos: where do interstellar objects come from?
In 2017 the first object ever seen to come from outside the Solar System, 1I/'Oumuamua, swept past the Sun on a path no planet, asteroid or comet of our own could have. Two years later came 2I/Borisov, an interstellar comet, and in 2025 a third, 3I/ATLAS. All three were born around some other star and have been drifting through the Milky Way for millions, perhaps billions, of years. Nostos (Greek for "homecoming") tries to find which star that was.

The idea is simple; the scale is not. Take the object's measured path, run it backwards through the gravity of the Milky Way, and do the same for the stars around us: wherever the object once passed very close to a star, and slowly, that star is a candidate for its birthplace. Gaia DR3 gives a full 3D position and velocity for about 33 million stars, and Nostos follows the object back 100 million years against every single one of them. Because an orbit is never known perfectly, each star is checked against 100 slightly different copies of the object, spread the way its measurement uncertainty allows.

The best earlier searches (Bailer-Jones and colleagues, 2018 and 2020) used the roughly 7 million stars with radial velocities in Gaia's previous data release. Gaia DR3 has about 33 million, measured more precisely, and Nostos runs every one of them, for each interstellar object in the search, with the orbit uncertainty included for every star. That is about 2.4 CPU-years of computing per object -- far beyond one research group's budget, and exactly what donated computers are good at. Each task follows one object against 1500 stars and reports only the stars that came within 50 parsecs; everything else is discarded so results stay small.

What this can realistically produce
In order of how confident we are in each:

A complete catalogue of close stellar encounters for 'Oumuamua, Borisov and 3I/ATLAS over the last 100 million years, covering every Gaia star with a measured radial velocity. This doesn't exist yet, and finishing the search produces it. It will be published openly.

A check of the candidate origin stars proposed in the literature, with newer Gaia data and a full uncertainty treatment -- some will hold up, some won't.

Possibly a convincing birthplace: a star the object passed slowly and very close to, recently enough for the trajectory to still be trustworthy. Honestly, this may never be possible for objects that have been travelling for billions of years; finding that no star fits is a real result too. And the Vera C. Rubin Observatory is expected to find many more interstellar objects in the coming years, each of which can be added to the same search.

Why should I trust this one?
There is no money involved anywhere in Nostos. Everything it uses is public: the Gaia DR3 catalogue (with the official parallax zero-point correction), the published orbits of the interstellar objects, and a standard, published model of the Milky Way's gravity. Before a single task went out, the pipeline had to reproduce the published results of independent studies: the closest known encounters of 'Oumuamua with HIP 3757 and HD 292249, and of Borisov with Ross 573, all come out inside the published uncertainty ranges. Every close encounter the volunteers find is checked again with the star's own measurement errors before anything is claimed, and the progress and closest stars found so far are public on the Nostos page.

Phygas: where were the runaway stars born?
Most stars are born in clusters and drift away from them gently. Some leave in a hurry: when a massive star in a binary explodes as a supernova, its companion is flung out as a runaway star, and the neutron star left behind -- a pulsar -- gets a kick of hundreds of kilometres per second. Close encounters in crowded young clusters throw stars out too. Phygas (Greek for "fugitive") traces these fugitives back to the cluster they came from: which one, when they left, and how fast they were thrown out.

Every Gaia DR3 star with a full 3D velocity (33 million) and every pulsar with a measured proper motion (about 700) is run backwards through the Milky Way together with more than 4,000 young star clusters and moving groups (Hunt & Reffert 2024), both sides drawn many times from their measurement errors. Pulsar radial velocities are never measured, so they are drawn from the known spread of neutron-star birth velocities. Stars are first screened against every cluster in a fast linear pass; promising pairs and every pulsar get the full Monte Carlo.

What this can realistically produce
An all-sky catalogue of the stars and neutron stars that may have left each young cluster, with the time and the ejection speed of each departure. Studies so far have covered one region or a few dozen stars at a time; a pulsar census against open clusters was published in 2025 for the 145 pulsars with independent distances, and Phygas extends it to every pulsar with a measured motion. Pulsar birthplaces give the time and place of the supernova and the speed of the kick, which is still poorly understood. Runaway-star and pulsar pairs that leave the same place at the same time would mark a binary disrupted by a supernova. Everything, raw data included, will be published openly.

Why should I trust this one?
No money is involved, and everything Phygas uses is public: Gaia DR3, the ATNF pulsar catalogue, the Hunt & Reffert cluster catalogue and the same Milky Way model as Nostos. The pipeline reproduces published results before anything new is claimed: the binary pulsar J1302-6350 comes out as a member of the cluster UBC 525, ranked first of more than 4,000 clusters, and the double pulsar J0737-3039 points to Theia 58, as recent studies found. Most stars that cross a cluster do so by chance, so every cluster's candidates are compared against a control run in which the stars' velocities are shuffled; only an excess over that chance level counts. Progress and the best candidates so far are on the Phygas page.

Bitcoin puzzle hunt: Potamos & Keraunos
Searches for the private keys of well-known, long-unclaimed Bitcoin "puzzle" addresses, using donated CPU and GPU time from volunteers all over the world.

Back in 2015, someone created a series of Bitcoin addresses, each funded with an amount of BTC, and each with its private key deliberately restricted to a known, sequentially-numbered range: puzzle #1's key is somewhere in a 1-bit range, puzzle #2's in a 2-bit range, and so on up to puzzle #160's 160-bit range. It was set up as a public challenge: whoever finds the key for an address can claim the coins in it, using nothing but publicly available information. Most of the small, early puzzles were solved years ago. Many of the larger ones are still unclaimed today, some holding real value, and that's what Potamos and Keraunos are for.

This is not Bitcoin mining. Mining creates new coins by competing to extend the blockchain, and it never stops. This project does nothing of the sort: it searches a fixed, famous set of addresses whose creator deliberately left them as an open challenge years ago, for anyone who finds the matching key to claim. No new coins are created, no blocks are mined, and the work has nothing to do with Bitcoin's network or its security.

Is this legitimate? Why should I trust it?
This is a fair question to ask before you donate real compute time and electricity to any project, and we'd rather answer it directly than leave you to wonder.

First: nothing about running this puts YOUR computer, YOUR files, or YOUR own wallets at any risk. The app only ever reads the small work packet the server sends it (a key range and a target address) and writes back a result file saying whether it found a match in that range. It never touches your disk outside its own BOINC slot directory, never opens a network connection of its own (all networking is BOINC's own client, the same one every other BOINC project uses), and never asks for or needs anything from you besides spare CPU/GPU cycles.

Second: the part that matters most -- what happens if a key is actually found -- is deliberately built so that no single moment of automation can move funds anywhere. See "If a key is found" below for exactly how that works, in real technical detail, not just a promise.

Third: bitboinc is one project in the Athena network, a set of independent open-source projects run by the same person under the same name, with a public track record you can look at independently rather than take on faith. This isn't a project that appeared out of nowhere to ask for your compute time.

If something here still looks unclear or you want to verify a specific claim, ask on the message boards -- questions about exactly how any part of this works are welcome, and we'd genuinely rather explain it than have you guess.

How it works
1. Two apps, two methods. Potamos scans a range of private keys sequentially, one by one, checking each against the target address. It's simple and exhaustive, but only practical for smaller ranges. Keraunos runs Pollard's kangaroo algorithm instead, which is vastly faster than brute force -- but it only works on a puzzle whose public key has already been exposed on-chain (which happens if that address has ever sent a transaction, not just received one). Most of the still-unclaimed puzzles don't have an exposed public key, which narrows down what Keraunos can actually target at any given time.

2. Volunteers work together, not just in parallel. A kangaroo search doesn't just split a range into pieces and hand each piece to a different computer -- that would throw away most of the algorithm's advantage. Instead, every volunteer's computer runs its own randomized search over the same range, and periodically reports the distinguishing points it finds back to the project. The moment any two of those points -- from any two computers, possibly on opposite sides of the world -- collide, the private key can be computed directly. More volunteers genuinely means faster progress on the same target, not just more redundant work. Sphinx (below) reuses this exact same collaborative-search mechanism for a different target.

3. One active target at a time. Only one puzzle is worked at a time per app, so effort isn't spread thin. Solving a puzzle is detected automatically the instant a real collision happens (no polling, no delay): the server immediately stops generating any more work for that puzzle -- both Potamos and Keraunos -- and automatically activates the next queued target so volunteers' computers don't sit idle waiting for a human to notice. If someone outside the project claims a target's coins first (racing us to the same puzzle, which does happen -- these are public, famous addresses other groups also search), that's caught the next time the project owner checks the target's on-chain balance, and the switch to the next target follows the same automatic path.

4. Checking results. Every result your computer sends back is independently checked before it is accepted, the same way any BOINC project validates work, and you're credited for it.

If a key is found
This is the part most worth being precise about, so here is exactly what happens, in order:

1. The moment two distinguished points collide (or, for Potamos, the moment a direct match is found), the server encrypts the raw private key immediately, in the same process that discovered it -- using RSA-4096 with OAEP padding, a well-established, standard encryption scheme, not anything custom. Only the encrypted result is ever written anywhere: to the database, to the project's logs, and to a notification email sent to the project owner. The plaintext key exists only for a moment, in memory, during that one encryption step, and is never written to disk or logged.

2. The matching decryption key -- the only thing in the world that can turn that ciphertext back into a usable private key -- is not on this server, has never been on this server, and is not in any code repository. It exists only on hardware the project owner personally controls, offline.

3. Nothing moves automatically. There is no code path, anywhere in this project, that takes a found key and sends a transaction. The server's job ends at "store the encrypted result and tell a human." A person then manually retrieves the encrypted value, decrypts it offline on their own machine, verifies with independent math that the decrypted key actually corresponds to that puzzle's known target address (so a corrupted or wrong decryption can never be mistaken for a real find), and only then manually sweeps the funds to a hardware wallet. Each of these is a deliberate, separate, manual step -- not an automated pipeline with a human rubber-stamp at the end.

4. Once the funds are confirmed safely moved, they are split four ways: a share to keep the platform running, a share to science projects, a share to nature and environmental protection, and a share to the volunteers themselves. The volunteers' share is not divided evenly among everyone who ever ran the project -- it is given out by a random drawing among the people who contributed valid work on that specific puzzle recently, weighted by how much they contributed. A bigger contribution means better odds, not a bigger guarantee.

We don't publish exactly which sub-ranges have already been searched -- that information would let other, unrelated search efforts skip straight past the parts our own volunteers already covered. What we do publish is aggregate progress: how many distinguishing points have been found so far and roughly how many keys that represents, without revealing the map of where. See the puzzle progress page for the current numbers.

Sphinx: not Bitcoin, a separate cryptography challenge
Sphinx has nothing to do with Bitcoin. It targets Certicom's ECCp-131 discrete-logarithm challenge -- a deliberately unsolved cryptography problem published for anyone to attempt, with no coins, wallet, or address of any kind involved. It reuses the same collaborative kangaroo search as Keraunos above (every volunteer runs an independent random walk over the same target, and a collision between any two volunteers' distinguished points solves it directly), just applied to a completely different, non-Bitcoin elliptic curve. A solution here is a piece of mathematics, not a claim on money, so none of the "if a key is found" fund-handling process described above applies to it. We haven't independently reconfirmed whether Certicom's own historical prize for this challenge is still being honored; treat solving it as a genuine cryptographic achievement in its own right, not a guaranteed payout.

Planodia: planets in TESS light curves
Planodia searches the light curves of millions of stars observed by NASA's TESS space telescope for the small, regularly repeating dips in brightness that a planet makes when it passes in front of its star. TESS watches one patch of sky for about 27 days at a time, and every such sector adds about a million light curves. Each task gives your computer 2,000 of them; it removes the slow trends of the star and the telescope and scans thousands of trial periods between half a day and two weeks for a repeating dip. Every task is computed by two different volunteers and the results are compared, so a single faulty computer cannot put a false signal into the data.

Planodia Deep is the second, deeper stage of the search: it looks for several planets around the same star.

What this can realistically produce
In order of how confident we are in each:

A complete, openly published list of the strongest transit signals of every sector we search, checked against the known planets and candidates, eclipsing binaries and instrumental effects. The full results are published on Zenodo, as for Kampylos.

Possibly new planet candidates: shallow transits of small planets are exactly what a search with more computing time than the standard pipeline can find. Real, but not something we can promise in advance.

Why should I trust this one?
There is no money involved anywhere in Planodia. Everything it uses is public: the light curves come from the MAST archive, the search code is open, and a task only reads a small data packet and writes back a result, like every other app of the project. Volunteers whose results contribute to a published candidate are credited by their project user name.

Yarrow: a radiation monitor network
Natural background radiation is tiny and different everywhere: the ground, the buildings and the altitude all change it. Yarrow builds a live map of it from volunteers' Geiger counters. A small monitor program reads the counter you plug into your computer (the FNIRSI GC-03 pocket counter with the open Yarrow firmware, the USB counters of the old Radioactive@Home project, and GQ Electronics GMC counters) and sends a measurement every ten minutes or more. You tell the project your country and city, and optionally the type of detector you use.

What this can realistically produce
A live, city-by-city map and table of the natural dose rate, with history pages and CSV downloads, and a statistics page of the network. One counter per city is where it starts; the more cities join, the more useful the map becomes. Yarrow does not claim to replace official monitoring: it shows how large the natural differences between places are.

Why should I trust this one?
The monitor only reads your counter and sends the counts. Only your city is shared, never a more exact place, and on the public pages volunteers appear by their user name and are never shown together with a place. Yarrow needs a counter, so it is never started unless you select it yourself in your computing preferences. There is no money involved.

Map: Radiation map · Yarrow statistics

Mnemosyne: saving the web with the Archive Team
Websites, forums and video services are shut down every day, and their pages disappear with them. The Archive Team is a group of volunteers that copies such sites into the Internet Archive before they are gone, using a program called the Warrior. Mnemosyne, named after the Greek goddess of memory, runs the official Warrior for you in a container (Docker or Podman): a task is one four-hour session that uses one CPU core, at most 1.5 GB of memory and your internet connection. Your work counts for the Archive Team under the nickname BitBoinc; your own name is never sent to them.

What you should know before you tick it
Mnemosyne is never started unless you select it yourself in your computing preferences. The websites being saved see requests from your IP address, like any visitor, and the content is whatever is about to disappear, which can include things that are unpleasant. It needs Docker or Podman, about 1 GB of disk space, and a recent BOINC client (the BOINC packages of some Linux distributions are too old to run container apps).

Docker, Podman and VirtualBox. Docker and Podman need virtualization features that VirtualBox also wants. On Windows, Docker runs through WSL 2, which uses Hyper-V, and VirtualBox-based BOINC projects on the same computer may then fail to start or run much more slowly. If you run VirtualBox applications with BOINC, do not select Mnemosyne on that computer. Docker and VirtualBox normally live side by side on Linux.

Windows. install the current BOINC client, turn on WSL 2 (Microsoft has a guide), then download the latest boinc-buda-runner-wsl-installer.exe from the Releases page of github.com/BOINC/boinc-buda-runner-wsl and double-click it. It sets up Podman inside WSL for BOINC. Restart BOINC; its event log should then report WSL and Podman as detected. Docker Desktop is not needed. If BOINC says it cannot use the docker CLI from the docker-desktop distribution, use this runner instead.

Statistics: Mnemosyne: saving the web (Archive Team)

Faros: general test and development
Faros is the project's general test and development application: new builds, new ideas and new kinds of tasks are tried here before they get a place of their own. Its tasks can fail more often than those of the research apps above, and their credit and length can change without notice. If you only want production research, leave Faros unticked in your computing preferences.


© 2026 Alperen Yavuz
Part of the Athena network

See this page for the full list as it might change over time.

Applications
The following applications are supported:  There are both CPU and GPU apps.

Please see their Applications page as they change with ne applications HERE

Connecting to the Project

Connect to the project with this url https://bitboinc.athena.org.tr/

Don't forget to join BOINC@Australia at home Team following your registration.

Statistics

There are no Statistics that I could find at this stage