Will there be an easy way to generate secure, verifiable public randomness for Manifold by end of 2022?
Basic
33
Ṁ8925
resolved Dec 29
Resolved
YES

See https://manifold.markets/post/public-randomness-sources for my post on current methods. To resolve YES, there must be an easy-to-use method that allows generating random numbers quickly (within at most 1 minute), and it must be possible for everyone to be fairly confident in the fairness of the random numbers with little effort, and highly confident in the fairness with more effort.

Note - this is deliberately a pretty high bar. A simple bot that generates random numbers on request with a local RNG, run by a trusted operator (e.g. Manifold itself), would be perfectly sufficient for most purposes, and people are already planning to write one, but this question asks whether we'll be able to go one step farther and not have to rely on the security of that bot.

Security criteria: the RNG must be reasonably robust to exploitation by any actor or group of actors with a budget of less than $1m USD. (So something based on a popular blockchain, Cloudflare's drand, or NIST would probably provide sufficient security.) Exploitation here includes leaking RNG info in advance or manipulatability of RNG.

Verifiability criteria: For example, showing a record of previous random numbers on a website, or posting them in an automated comment, would suffice for low-effort verification. Using a cryptographic mechanism like in blockchain, drand.love or https://beacon.nist.gov/home would mean that anyone can (with high effort) verify with high confidence.

Also note - it is entirely possible that something satisfying these requirements already exists somewhere. For this to resolve YES, someone must find it and let me know about it.

Related question that does not require strong security:

Get
Ṁ1,000
and
S3.00
Sort by:
predictedYES

I expect to resolve this YES unless someone presents a convincing counterargument. I believe it satisfies my resolution criteria, and implements pretty much what I suggested in my post.

(Don't take this as criticism, I'm just being ornery.)

It might cost $1m to test the question of "can this supposedly secure cryptographic protocol be broken for under $1m". (My strategy would be something like: spend $900k to pay some cryptography people to think for several months about whether the protocol can be broken for $100k.)

As an example of potential exploitation: How much would it cost to ensure that the next block on your favorite blockchain has hash ending in a given eight-bit string?

@Boklam I think the cheapest way to break is to just edit the commitment comment. So $5 for a wrench plus a few hundred bucks for the 2-way flights to where your (least) favorite Manifold employee lives.

@Yev By nature of how "bot on manifold" is defined, something along these lines would always be possible (Manifold could just replace the question description saying "we will use secure bot XYZ for resolution" with "we will use insecure bot ABC for resolution") so not sure it's really in the spirit of the question...

predictedYES

I did say "reasonably robust to exploitation". The part about the budget was more meant as a limit on "brute-force" methods. But I'm actually reasonably confident about the general approach (it's very similar to what I had in mind as well) - it's using cryptographic building blocks (drand) that are probably reasonably secure. It would not surprise me at all if it was exploitable, in something like the way that OpenSSL is exploitable, but that would still count as "reasonably robust"

As an example of potential exploitation: How much would it cost to ensure that the next block on your favorite blockchain has hash ending in a given eight-bit string?

I'm pretty sure quite a lot more than $1m! At a rough estimate, each block rewards about 20k USD, and to get a specific 8-bit string requires you to compute about 2^8 = 256 blocks which should therefore cost roughly $5m.

Also the part about editing comments - people who have email notifs on will get it via email, so this is pretty robust.

predictedYES

Currently my market predicts ~10% chance of it being insecure.

predictedYES

Turns out that notifications for bot comments are disabled (because of Manifold Dream). This should probably be fixed because notifications from FairlyRandom bot commenting in reply to you are clearly useful.

@Yev I think that market depends a lot on how much effort people invest into verifying the randomness - in fact, that might be the main thing the bet hinges on. My criteria requires high robustness only with someone actually running code to verify the randomness (because if nobody is checking it would to be pretty easy to slip something by).

predictedYES

@jack I imagine if someone rolls 1337 and buys a lot of YES, there'll be a big incentive for others to verify it.

hmm I guess people have yet to create reddit style bots where you just put /roll d6 in a comment and a bot replies with a link to random.org / bitcoin hash / etc.

predictedNO

@Sinclair Yeah, I was just suggesting that in Discord earlier today and sounds like it is going to happen soon!

@jack Is someone already working on it then?

predictedNO

@MichaelWheatley said he was interested in working on a RNG bot, which is why instead of just asking whether there would be any RNG bot I made this market to ask about a highly secure one.

predictedYES

Ideal implementation:

  1. Make an HTTP request

  2. Bot replies with random number

  3. 1 minute later, bot posts in comments

This gives enough time for resolution to occur before the information is given to generic traders. You can't rely on it just being closed, because some markets are about events which happen at an unpredictable time

Note: I just updated the market description with some more fleshed-out criteria for what I'm looking for.

Will there be an easy way to generate secure, verifiable public randomness for Manifold by end of 2022?, 8k, beautiful, illustration, trending on art station, picture of the day, epic composition

© Manifold Markets, Inc.Terms + Mana-only TermsPrivacyRules