Every day, shortly after midnight UTC, I'll roll a 64-sided die to get a number from 0 to 63. If I roll a 0, the market resolves. If there was a nuclear weapon detonation (as defined in /jack/will-a-nuclear-weapon-be-detonated-d8af7cf07475) between the start of 2022 and that midnight UTC, the market resolves YES. Otherwise it resolves NO.
As long as the market hasn't resolved yet, the expected time until resolution is always 64 days.
Public randomness source: I will look at the last hash before midnight UTC here and take it mod 64.
Edit: starting with Oct 30, I will instead use first hash after midnight UTC instead.
Close date updated to 2022-11-05 10:13 pm
Related questions
🏅 Top traders
| # | Name | Total profit |
|---|---|---|
| 1 | Ṁ105 | |
| 2 | Ṁ10 | |
| 3 | Ṁ9 | |
| 4 | Ṁ6 | |
| 5 | Ṁ4 |
Can someone please check that this is the right block? https://www.blockchain.com/explorer/blocks/btc/761902
(Public randomness source: I will look at the last hash before midnight UTC here and take it mod 64)
This could be improved in future iterations - this incents people to check if the latest hash shortly before midnight would be 0 mod 64, and if it is to bet towards NO as it gets closer to midnight without another block being mined. So it would create some large volatility near midnight sometimes.
The problem is that the RNG effectively leaks some information (probabilistically) before midnight. It's better to take the first block after midnight so that the RNG is immediate instead.
It would be even better to use something like a public randomness beacon instead of blockchain. Blockchain has the problem that it generates random numbers intermittently and at unpredictable times, public randomness beacons generate them predictably at regular intervals. Examples include:
https://avkg.com/en/daily-random/ (the first google result for "daily random number") - downsides are that I don't know when the new daily numbers are published each day, and it's definitely not suitable for high-security applications (but it should be fine for manifold markets)
drand.love which would be great except I couldn't actually get the client set up
https://beacon.nist.gov/home which would be great except it seems broken for the last months
I changed to first hash after midnight. According to archive.org, avkg seems to update between 6 and 8 am UTC (I suspect it's midnight pacific time). I'm supposed to be asleep at that time.
@Gigacasting I'm not sure what you mean by seed phrase.
The median is 45 days, but the mean is 64 days (in general, the median of an exponential distribution is ln 2 ≈ 0.69 times the mean ).
@LivInTheLookingGlass Placing limit orders on Yes the way you did is a bit dangerous with these resolution criteria, since someone could check if the market is about to resolve using the public hash, and then place a large No bet since at that point it is "will a nuclear weapon be detonated before Yev checks the hash." If you want to eliminate this effect, you could pick a integer x from [0,63], a large random nonce, publish hash(concat(x, nonce)), and then resolve when (public block-chain hash + x) mod 64 = 0.
I suppose this would gradually leak information about x, so publishing hash(secret) and resolving based on hash(concat(secret, public-random)) might be better. This lets you prove you are honest at the time of resolution. There is probably some more clever scheme that also manages to prove that you have not lied to delay resolution, but I am not sure what it would be.
Why not just:
Make a key for each market
Make sure you are signing in a way that you control the nonce, is the same way each time
Set nonce to be a generic public source of randomness with a timestamp
Sign concat(prev_sig, slug, nonce)
Comment this signature
If test(signature), resolve
Go to step 3
I did a fair amount of research into how to do publicly verifiable randomness for markets like this, and yeah it's definitely possible to do it but it's just a surprisingly large amount of work to do it right with the services I've found so far. I'll make a post about the methods I tried, but you can find some of my previous info here: https://manifold.markets/jack/what-are-the-best-ways-to-operate-a#f7X6mltyeV6QopuBs6MX
Ideally, I think there should be an automated script that uses a public randomness beacon combined with a market ID or nonce to generate a random number at the desired times. We can define the random number generator function as hash(concat(public randomness beacon value at current timestamp, market slug)). The automated script checks the RNG value at midnight every day (or whatever other schedule you want) and closes if the RNG falls in the specified range. To prevent front-running, you may want to close the market like 1 second before midnight, then check the RNG value, then either resolve or reopen.
@jack to prevent front-running, you can also generate a secret that you'll use for random number generation, post its hash when you create the market, and then reveal it after you close the market.
@Yev That still leaves open the risk of front-running by the market operator. If that's not a concern, then yeah, that works fine.
