This market refers to obfuscation schemes such as indistinguishability obfuscation, not normal program obfuscation which just makes it difficult to reverse engineer.

An example application of a scheme which works on complex programs would be: offer a prize for providing a proof of a mathematical theorem by publishing a program which outputs a cryptocurrency private key if given a correct formal proof. The obfuscation would make it impossible to extract the key from the program without having a correct proof.

It's fine if reverse engineering is not completely impossible as long as it can be made difficult enough to be impractical (same as brute forcing the private key for a public key is theoretically possible but impractical). However there should be consensus among cryptographers that it really is impractical to break the scheme.

It's not necessary to have a full formal proof of the reverse engineering difficulty, the same as many cryptography algorithms rely on hardness assumptions, and AES has no actual formal security proof, but is regardless justifiably considered secure. If a proof exists but requires some hardness assumption which cryptographers consider reasonable, that's also fine.

I don't require specifically an iO construct to resolve YES, weaker schemes exist which would be enough for "output a secret if input matches function f", but none of the existing general enough constructs are efficient enough to be usable with existing hardware.

Note that schemes for zero knowledge proofs (verifiably proving a theorem without revealing the details of the proof) do not suffice because you'd still need a trusted party to hold the secret cryptocurrency key and release it to someone if they provide a valid ZK proof. Additional obfuscation constructs would be needed to be able to just publish a program that does this and cannot be reverse engineered (the release mechanism).

This market isn't specifically about a scheme that's efficient enough for proof checking, but it must enable some interesting practical use cases not possible today. I'll draw the line at a program outputting a secret string given the correct password. That's not enough for YES, it should be able to do something more complex than that, such as custom logic to check if the input is a message signed by a public key, without revealing said key. "Custom logic" is important, if it can do this for only one specific public key signature system that's not enough. Some degree of flexibility, such as arbitrary circuits of some reasonable size, is needed.

Existing white-box cryptography such as that used in DRM does not count because it's not based on provably secure cryptography and is often broken.

If a scheme that seems to match these criteria is released, I'll wait for cryptographers to assess it before resolving YES. If it remains controversial for a long time, or just doesn't attract much academic interest for some reason, I may do my own research, but in that case I will ask for arguments in the comments, search for arguments from both sides, and wait a while, before resolving regardless of controversy. If cheap enough, I'll try testing it myself to see that it works.

There already exist schemes which theoretically can obfuscate arbitrary programs (iO obfuscation), but there would need to be orders of magnitude efficiency improvements before 2035 to resolve YES.

I don't strictly require that it can run on consumer hardware. If you need to rent cloud GPUs to verify your proof for around ~1000$ in 2035 cloud compute costs that's acceptable. Something around this level of efficiency would count. However if it does something less interesting than arbitrary theorem proof checking, it should be cheaper than the equivalent of 1000$ cloud compute per run. Also, if compute prices in 2035 are over 1000 times cheaper than now, I'm capping it at that.

If it requires specialized hardware you can't rent from a normal cloud provider, this is a downside, since you'd need to trust them (unless the scheme also efficiently supports some kind of homomorphic encryption which prevents the provider from seeing your input or the result). But it's not a deal breaker.

An issue with schemes like this is that they work on circuits, not Turing machines, so you need to account for worst case time and memory bounds, which is very inefficient. If a new scheme bypasses this entirely with something like a O(log n) penalty for time or memory usage (would leak some information, but that could be mitigated such as by rounding to only 100 MB increments or a billion cycles to hide precise control flow details), that would be a huge point in favor of YES, but not strictly necessary, and such an improvement may come later after a simpler circuit based scheme is found which might regardless be enough to resolve this market YES.

If you're wondering about some resolution edge case or you believe some criteria doesn't mean what I intend it to mean, please ask in the comments before betting, otherwise it's at your own risk, but I won't intentionally resolve this in some “exact words” way.