@Quroe I don't see why this would suddenly be a priority when everyone stonewalled and ignored it at a time when the site was actually getting frequent changes.

@Eliza But I want to know the probability!

Where Set/M.C. stands for Set or Multiple Choice. Any market that has an array of answers.

@EvanDaniel

Agh, misclick.

@Quroe

@Eliza

@Stralor

@NivlacM What constitutes an improvement in liquidity handling? Adding instantaneous liquidity rather than the drip over time liquidity?

@ShitakiIntaki dunno. I kinda thought this was already done. All I want is to be able to add liquidity to a market and get my money back when it resolves

@NivlacM That has been the case for a very very long time. You get a proportional share of the liquidity you put in returned from the pool's value upon resolution. That would not be a new feature.

would be cool if there was a mechanism allowing you to bet that a market would become popular in the future

like "market X currently only has 3 traders, but I bet it will have over 100 a year from now"

This would be really really good imo, is there a reason that this is structurally hard to implement? It would be great on large multiple choice markets like Dem/Rep nominee odds, TIME POTY, etc

EDIT: I assumed this meant decimal limit orders below 10% or above 90%, but I guess not?

@bens This is not a technical issue, it is a product decision. We used to be able to bet in those ranges.

@Eliza oh wait... I assumed this meant being able to set decimal limit orders... you already can bet YES on options below 1% on multiple choice markets and can't bet NO on them, that's fine although slightly odd... I think being able to set a 2.5% limit order on a random presidential candidate would be pretty helpful though

@bens yes, I meant decimal limit orders like 2.5% or 0.7% or whatever. Exact details don't matter for this market, as long as it's finer options than currently.

@Eliza why though? It doesn’t make sense to me that we can’t

@JasonMendoza2008 I personally found most of the 'product decisions' from the era of that decision very very hard to actually trace back to a core guiding idea. But in this case it's some combination of:

• sometimes people lost huge massive amounts of mana like 50,000, because they bet a 99.1% to 99.9% and it resolved against them and they didn't really understand the difference between 99.1% and 99.9% or how to do that safely

• the site overall was really bad at predicting things in this range and instead of making it better at that, they decided to just ignore it

@a_l_e_x would this have to be a formal feature made by the manifold team?

@realTomBayes not sure it's up to me but I would say yes based on the title/description

@realTomBayes "External PRs that have been merged will count" so no

@SG would it still have to be approved/implemented by the Manifold team though?

@a_l_e_x obviously, nobody can just push a random commit to main without authorization

@realTomBayes oh cool I thought so. I took your question as "does it have to be a built-in feature or can it be an unofficial user initiative" hence my answer. Sorry for any confusion

@a_l_e_x ohh yes I was wondering this also, I just thought you were talking about the codebase because of the word choices you used