Does it need to be accepted by Manifold?

Since creating a PR to do so where the fix for the difficult part (handling wrong resolutions) is just "ok no more unresolving" should be ~fairly straightforward, but writing that code is not the blocker for Manifold. (Unresolving things has become a pretty fundamental part of Manifold culture. It's a big problem if people are accustomed to the ability to undo things and then that changes on them.)

@Ziddletwix It does not need to be accepted (as I mentioned in the description), but I'm not going to submit anything that I'm not convinced should be acceptable. In this case, that means I would likely do a deep dive on what the exact difficulties are, and only take an easy path if those difficulties end up scaring me.

That being said, even my proposed easy path would only disallow un-resolving these partial resolutions, while the standard pick-the-right-answers full resolutions would still be un-resolvable (unless I find that's not possible when I actually work on the implementation). Right now, partial resolutions can't be made in the first place, so there would not be any regression to existing functionality.

Also, by "communicate to the resolver", I'm talking about doing something like making the resolver type "it is impossible for this answer to be correct", in addition to explaining the consequences of getting it wrong.

Since I could otherwise submit a sub-par PR in order to make profit from this market, I'm just not going to bet in this market whatsoever.

James almost did this in 2023 but he got sidetracked made a dating site instead.

As far as convincing Manifold to do it in 2025, it's mostly just about coming up with a reasonable rationale for whatever preference you have regarding handling errors in resolution or other unforeseen events.

I don't think the primary reason it hasn't been done is "implementation is difficult".

@Eliza Good to know! What do you think of the solution to that I suggested in the event I don't come up with anything better?

> It may be necessary to solve this by communicating to the resolver that the whole market will need to be resolved N/A if they mistakenly resolve an option to NO.

@SimonWestlake Among the possible options, this is a good one. But based on what I know about the median market creator's ability to manage a market, it seems like something where we would still run into issues on a regular basis.

That goes for both fat-fingering the resolution button and also "the state of the world and all possible future outcomes was not quite in line with what I thought it was at the time I took that action"

@Eliza Copy/pasted from a different response:

> By "communicate to the resolver", I'm talking about doing something like making the resolver type "it is impossible for this answer to be correct", in addition to explaining the consequences of getting it wrong.

For date markets, we could also remind the resolver that a date passing doesn't mean the event did not happen on that date.

@traders I made the options for 2029 and later consistent with the others.

Also, I will not be betting NO on this market, to keep incentives aligned.