Background
Manifold held a charity drawing a couple days ago after a giveaway where users donated mana. I'm attempting to verify the results.
So far I have been unable to verify that the charity giveaway was fair.
They provided a nonce hash during the competition and I am satisfied that the nonce they have provided afterward is the one they used:
Pre-published hash: be763636dd84526263da5fcf76a5749f
Revealed nonce: 3ea815748b401ecf44e0565ff97577758861be9c4a4ce40e7e51bfec71b3e291
So far, this all checks out. The hash matches the revealed nonce. The hash did not change.
However, verifying that the draw was fair requires the timestamps of the last 10 purchases in order to generate the random number. I was able to use the get-charity-giveaway-sales API which happens to include the last 10 purchases and their timestamps:
1772344608000
1772311000000
1772286202000
1772257983000
1772256780000
1772256743000
1772249295000
1772237930000
1772203754000
1772192331000I used those timestamps and the code supposedly used to select the winner, and got a random value of 0.6683799368020045 which, with the published total ticket sales of 3434266.508031701 tickets would correspond to a winning ticket of number 2295394.831599469.
However, the winning ticket shown on the page is the 2nd to last ticket purchased. It should correspond to a random value of roughly 0.997 (or whatever, I didn't calculate it exactly).
Market resolution criteria:
If Manifold (or anyone, or myself) convinces me the charity giveaway was fair before the end of the month, I'll resolve Yes. If I am not convinced by the end of the month, I will resolve No.
If Manifold announces a new winner or announces there was an error, this resolves No. If they do not change anything and no one convinces me the giveaway was fair, it resolves No.
Possible ways to convince me:
The first likely way I could be convinced is to show me that I have made an error in interpreting the calculations. I have tried using the code from Manifold's published GitHub repository and also implementing my own take, and got the same 0.668 result both times. Show me that I have made an error in running the calculations and that running it the right way results in ~0.997.
Maybe I am interpreting the mapping of random value to ticket number incorrectly. Convince me that the 0.668 value corresponds to the shown winning ticket and I'll be happy.
Another way I could be convinced is if someone shows me that the timestamps I was using were incorrect and also presents a plausible case for what the real timestamps are. The get-charity-giveaway-sales API returns timestamps with ms precision but they all appear to be rounded to the nearest second (ending with 000). I assume this means the timestamps are only stored in the database to the second. If someone can show me that the database actually stores the timestamps to the ms or greater precision and come up with the true values that result in a random value of ~0.997, that would help. But the database table is not publicly readable. Manifold would probably be able to fake a result of 0.997 with this strategy so it has to be a believable case.
Perhaps there is some other error, like the API is not correctly returning the last 10 tickets, or anything else.
1,000🏅 Top traders
| # | Trader | Total profit |
|---|---|---|
| 1 | Ṁ12,915 | |
| 2 | Ṁ1,902 | |
| 3 | Ṁ1,432 | |
| 4 | Ṁ379 | |
| 5 | Ṁ70 |
People are also trading
For the final ticket purchased at 2026-03-01 05:56:48, there are 1000 possible millisecond values. For all of them, I have computed the corresponding value of randomValue with all other timestamps held constant.
The millisecond suffix that produces the highest possible randomValue is 289. Which also happens to be the millisecond suffix we are told was in the database the whole time, even though we were only able to observe it since after the winner was selected. Curious!
https://gist.github.com/DavidBuchanan314/3cf825f5b4f3e650446ba5890fd32d0f
@ian I am still waiting for someone to answer the insightful points of wasabipesto as I mentioned in a post below
Earlier in the year I published software for using networked GPU clusters to compute hash collisions: https://github.com/DavidBuchanan314/birthday_party
To compute a pair of colliding MD5 inputs matching the nonce format used here, it would cost approximately $8000 worth of rented GPU time (based on vast.ai 5090 pricing). Obviously, nobody is going to spend $8000 to rig a $1000 giveaway. But if you read the README for my project, you will note that I was considering performing an equivalent computation just for fun. Like how people calculate billions of Pi digits, or find new-largest prime numbers. It's a weird hobby, I know. The result of such a computation is a valuable object (to a nerd like me) in its own right.
(There are much cheaper ways to compute MD5 collisions in general (e.g. fastcoll), but these would not fulfil the length requirements of the nonce)
A pair of colliding nonces would allow the admins to freely choose between two outcomes, picking whichever is more favourable. Nobody can prove that this isn't what happened.
There is simply no excuse to use MD5 for anything, especially when secure hashes like SHA256 are used elsewhere in the process. There isn't even a good reason for an LLM to have selected it during a vibecoding session. LLMs know better than most humans not to use MD5, just ask one!
@retr0id also here you can see me spending real $ on GPU time to gain a market edge: https://manifold.markets/PeterSchmidtNielsen/are-the-majority-of-the-final-bits#c5kduak93a
@CourierSix - unrelated - who is the best non-bot trader that I can just copy their bets for profit?
@xjp When they posted a claim on the charity page at the very start of the event with a special hash and claimed it would be provable, I immediately made a note of the special hash so I could check on it later. When checking on it resulted in a discrepancy I thought it was fair to call this out.
@xjp That is likely the case, but I should point out that the market was not intended to ask whether they rigged it -- I had a genuine concern that the implementation/execution of the random selection had been botched and resulted in picking a 0.999-level winner through a software bug rather than through random chance. Even if they were not doing anything intentionally bad, they may have resulted in a draw that was always going to pick the 1000th-to-last ticket or whatever.
@retr0id not to my knowledge. Proving we have motive enough to rig the drawing seems a harder sell than that, though
@ian Why bother with the convoluted hashing scheme in the first place? Presumably, because you thought it would be insufficiently trustworthy otherwise.
@ian I believe that the aforementioned convoluted hashing scheme adds no real security, so in my view we're back at the "insufficiently trustworthy" scenario.
@ian The intentions may have been genuine but the end result is a scheme that, if I didn't know better, I'd say had been deliberately backdoored
@retr0id Right, even if they publish the complete last 10 timestamps at all times:
An insider can easily control the very last timestamp which in this case gives them pretty strong control over the final output
It would be very hard for someone to prove that an insider did not make any changes to the 'last 10' timestamps after the fact
A single party could purchase all of the last 10 tickets and exert control over the output
Does the database guarantee a deterministic sort if two orders have the same timestamp down to the precision it stores them at?
The list goes on and on.
I think this one is probably the most serious and in need of careful examination:
XOR with timestamps: in the timestamps, a bunch of the higher bits are always zero. Even the middle-level bits are going to always be the 'same' right? So in the end if we had a handful of very close (and carefully selected) timestamps then the timestamps are doing ~nothing.
But for this market I just need to be satisfied that this specific draw that did happen, was 'fair' to the level of my own satisfaction. If we show numerous ways that the drawing methodology could have been abused, but no evidence anyone actually did them, that wouldn't move the needle.
XOR with timestamps: in the timestamps, a bunch of the higher bits are always zero. Even the middle-level bits are going to always be the 'same' right? So in the end if we had a handful of very close (and carefully selected) timestamps then the timestamps are doing ~nothing.
So if someone was to stuff the box with 10 separate ticket purchases all within the last 1 second of the event, then all 10 timestamps would be within 1000 of each other -- only the lowest ~10 bits of them would be the part being XOR'd with the 'seed' material. Meaning basically that there would only be 1000 potential random values rather than 3.5 million.
Outsiders still wouldn't know WHICH 1000 potential values those are unless they had a lead on what the nonce value was, but they would at least be able to reduce the value of the timestamps to almost nothing very easily by attempting to stuff the entire box all within the last tenth of a second or as close to the end as they can get.
Basically, the 10 timestamps thing feels kinda dumb and I think you can do better for next time.
@Eliza it would also be possible to select the nonce in advance such that a higher-than-fair number of the ~2^10 possibilities lead to a favourable outcome (say, biased towards the first or last ticket)