The same six steps every week, at the same times. Every time below was set before the draw, and none of them moves on the day. If a step cannot happen when it should, we stop and reschedule.
“How do I know it was not rigged?”
We publish the whole ticket list hours before the winning number exists. Then anyone can run the draw again themselves and land on the same name.
Times are Manila. This describes each weekly draw and the grand draw on 5 December.
The last time we tell people to pay. Mark or Bits still has to open the payment, match it to an order and issue the ticket, so the advertised deadline sits three hours ahead of the cut-off to give them room.
BuyersOur two payment verifiers stop. Whatever is verified by now is in this draw. Whatever is not moves to the next one, automatically, with nobody deciding anything.
Mark & BitsOne click takes every verified ticket, gives the whole list a short code, and puts it online. From this moment the list is fixed. Add or remove a single ticket and the short code changes, the two stop matching, and the file stops being served at all.
The same file names the random number this draw will use, hours before that number exists, and carries one that already existed — so the moment it was written can be checked rather than taken on trust.
For seventeen hours nobody verifies a payment, so nothing can enter or alter the list while the draw is running. People can still buy. Those tickets are checked after 5:00 PM and join the next draw.
The whole thing takes about a minute, and it is the same three moves every week.
Nobody chooses anything at any point. Give the same two files to a stranger and they land on the same ticket, which is the whole reason we publish them. See those three moves worked through with real tickets ↓
Verification restarts, into the following draw. The completed record goes online, and this draw's ticket list stays at its own permanent address so the draw can still be checked months later.
PublishedPeople worry that we pick someone we like. That is fair. If we read out a name, you are taking our word for it. A livestream settles it no better: someone once rigged a giveaway on camera by showing a fake result from a well-known number-picker site, and the people watching could not tell.
So we took the choice out of our hands. Those two things decide the winner between them, and you can check that for yourself: there is a button further down this page that runs the whole draw on your phone and shows you who won.
Follow the two lines out of the top box. Its short code goes left, into the mixing. The list itself goes right, all the way down, because it is the thing being shuffled. Those are two different jobs, and it is the part people usually miss.
It is a hat draw. All 1,003 tickets go in a hat. Pull one out for first place, pull the next from whatever is still in there, and keep going. Nothing goes back in.
Every ticket still in the hat has the same chance of being the one you pull — that is what makes it fair. The method is not new; it was written down in 1938, for people doing it by hand. The code lays the tickets in a row and swaps them into place instead. Here it is on six.
Scramble the long code together with a counter — 0, then 1, then 2 — and each time you get 32 fresh numbers. That is the endless page. Ours begins:
Those run 0 to 255, but with 40 tickets we only want 1 to 40. So we cut each one down to a number between 0 and 63, and throw away anything that lands over 39:
Throwing them away is what keeps it fair. 40 goes into 256 six times with 16 left over, and those 16 leftovers would hand the first 16 tickets an extra chance. Dropping them instead costs a fraction of a second and leaves every position exactly as likely as every other.
Imagine a book filled with millions of random digits, the same in every copy. The long code tells you which page to open. Everybody who opens that page reads the same digits in the same order. Open a different page and you get completely different digits.
Our page starts: 69 242 168 167 148 13 241 32 …
Now you shuffle exactly the way you would shuffle cards, except that instead of picking at random with your hand, you read the next number off the page.
That is the whole method. Every swap is decided by the next number on the page, and the page was decided by the frozen list and the number from outside. Anyone with the same two files opens the same page, makes the same swaps, and lands on the same winner.
One detail worth having: when the page hands over a number that is too big for the tickets left, we throw it away and read the next one, rather than folding it back into range. Folding it back is what would make the low-numbered tickets win slightly more often.
Every ticket is equally likely to be the one on top. Buying early puts you higher in the frozen list, and nowhere else. The list is locked before the random number exists, so no position can be aimed at, and the shuffle treats every position alike.
And this is the part that settles it. Anyone can download the two published files and run the draw again themselves. For a rigged result to hold, those files would have to produce the winner we announced. They would produce a different one, in front of everybody.
Real output from the sample files, which stay up all season on the check page. You can try this now, without waiting for a draw.
One honest thing first. Nobody can prove a single number is random. Any number looks like any other one. So instead of claiming that, we test the things that can be tested, and publish what came back.
Us telling you our own tests passed would prove nothing. So press the button and your own device will download our published files, work everything out, and check our answer against what we wrote down beforehand.
This is the real draw, running on your phone. Nothing is sent anywhere. Press the button and see who wins.
Imagine sharing 256 sweets between 40 children. Everyone gets six, and sixteen sweets are left over.
Hand those sixteen spares to the first sixteen children and they end up ahead of everybody else. That is what the easy way of picking tickets does:
Across all forty tickets:
So we put the spares back. When one of those leftover numbers turns up we ignore it and read the next one. Everyone gets six. Nobody gets extra.
You would never catch it by eye. Here are twelve picks from each way:
Both look like nonsense, and that is the trouble. The unfairness never shows in the numbers you can see. It shows up over hundreds of draws, and by then somebody has already won.
The draw needs a number, and it has to come from somewhere outside this batch. A computer here could make one up, but then we made it, and you would be back to taking our word for it.
So we take one from outside, from a service that has published a fresh number every few seconds since 2019, for anyone in the world who needs one. It runs for its own reasons, on the other side of the world, for anyone who needs a number.
The key is split before anything runs. When the network was set up, the members jointly generated one key and split it, so each member ends up holding a fragment and nobody, at any point, holds the whole thing. There is no master copy sitting somewhere.
Each round is signed by many. Every three seconds the members each sign the next round number with their fragment. Enough fragments combine into a single signature, and that signature is hashed into the random value. A minority of members going offline, or going bad, changes nothing.
Each round has exactly one right answer. A member who tried a different value would have it rejected by everyone else, so the only thing they can do is help produce the real one. The number can be produced, or the round can be missed. Those are the only two outcomes.
Anyone can check a value is genuine. The network published its collective public key years ago. Any round’s value can be verified against it, which is why we can read the number from two independent websites and know we are looking at the real one rather than something either site invented.
None of this is ours. It runs whether or not we hold a raffle, it was running long before we planned one, and it will keep running afterwards. We name a round and wait.
But a new one comes out every three seconds. Could you not just keep trying?
That is the right thing to worry about. If we grabbed whichever number happened to be current, we could run the draw, look at who won, wait three seconds, run it again, and keep going until we liked the answer.
Real codes. We ran the engine over the sample list and changed one character of the random number. Both runs check out, so from outside you could not tell which one we were supposed to use.
Our file names both, so it had to be written after the first appeared and before the second did. That pins it inside a window neither we nor anyone else can widen, and it does so without anyone trusting our clock or our word.
So we name which one, in advance. Sixteen hours before the draw we publish the exact round we will use, while its value still does not exist. There is no shopping around: one number is named, and everyone works out the same winner when it appears.
At midnight the whole ticket list gets turned into one short code. (The technical word for it is a fingerprint, and that is all it is.) Publish the code in the morning, and anyone can make it again from the list in the afternoon. If the two match, it is the same list.
cc6a5a29e2cb0748…
31aa2abe05264da4…
4a84e189b6140698…
Real values from the published sample list. Touching one row out of forty changes every character, and there is no way to work backwards from a code to a list that produces it. So a list that still matches its morning code is the list that was frozen.
Real values you can reproduce. The code is always the same length, it always comes out the same for the same input, and it runs one way: from a code alone there is no route back to the list that made it. So publishing the code in the morning gives away no part of the list, and still catches one that changed.
The code is a SHA-256 hash. It is a published public standard, written down by the US National Institute of Standards and Technology as FIPS 180-4, and it is the same function that protects the padlock in your browser, checks that software downloads are genuine, and gives every change in Git its name.
Mechanically: the file is chopped into 512-bit blocks. A 256-bit running value starts from a fixed constant and each block is stirred into it over 64 rounds of additions, bit rotations and exclusive-ors, using constants taken from the cube roots of the first 64 prime numbers. What falls out at the end is 256 bits, which we print as 64 hexadecimal characters.
It runs one way because the stirring throws information away: a 100-megabyte file and a single letter both leave 256 bits behind, so most of the input cannot still be in there. Reversing it would mean searching roughly 2256 possibilities. Written out, that is a 78-digit number, in the same territory as the count of atoms in the observable universe. Nobody has ever found two different files with the same SHA-256, and people have been trying since 2001.
Run it yourself. Download the list, then on a Mac or Linux
machine type shasum -a 256 pool-01.csv, or on Windows
certutil -hashfile pool-01.csv SHA256. Compare what it prints
with the code we published that morning. You are not taking our word for
the method either: it is the same command, on the same standard, that the
rest of the internet uses.
The site checks this for you. If the two ever disagreed, the ticket list would stop being served at all rather than serve a different one.