isn't that implied by the name "BitUSD"? I thought it was...

My understanding is that the description is intended for things like gold, silver or gas, where it can be used to describe which of multiple available price metrics are considered normative.

TLDR, ticket in OP is still under discussion.

Some history.  A feature which has been on our road-map for some time is relative orders, where people can place a bid or ask at a given percentage of the feed, like "I want to buy at 95% of the feed and I want to sell at 105% of the feed," without having to run scripts and spam the blockchain with a ton transactions.

I was tasked with implementing relative orders (more specifically, rehauling bytemaster's implementation to use percentages of the feed instead of absolute difference from the feed, and thoroughly testing it in preparation for release).

During the testing, I found certain fundamental architectural limitations of our matching algorithm prevented us from properly matching relative orders.  The same limitations also prevent certain combinations of existing order types from matching correctly in certain circumstances, which subsequently occurred on the main network.  A community contributor (pmconrad) advised us of this, which I already suspected due to what I knew about the architecture, and confirmed in testing.

My solution was to embark on a significant refactoring of our market engine to make orders execute the way we always intended them to.  I had hoped to have it ready for initial testing this week, however I've been hugely distracted upgrading my own delegate for the 0.6.x hardfork.

bytemaster thinks I am being overly optimistic about the timetable for my refactoring, and thus is looking for a change that will fix the problems but be much less expensive (in terms of developer time).  This ticket is the solution he's hit upon.

What we need to do is sit down and discuss the options, which will happen just as soon as I finish dealing with my obstreperous delegate VPS.

how about a calendar

The internal working calendar for core development is available at https://github.com/bitshares/bitshares/milestones

I don't know if understand your preorder idea. If the orders are placed but don't execute how will the market maker adjust the price?

The market maker won't adjust the price until it opens its doors.

If it doesn't adjust the price doesn't that mean all preorder buyers will be forced to buy at a price of 0.33 BitUSD/{A,B,C} for all three assets?

Yes, but only the first $1 (actually, the math effectively uses infinitesimal fractions, so it's more like 1 satoshi) will execute at that price.  If people only buy A and B at that price, then A and B will start to rise and C will start to fall.  Then eventually either A or B will be pushed to a price that exceeds what people are willing to pay (or buy orders for them will run out of money).  Likewise C may fall cheap enough that buy orders for C become active (there may be takers for C willing to pay $0.05 or $0.03 or $0.001).

But what if the market's prior expectation of the probabilities for the three outcomes is not uniform?

What I mean by the market maker being "dumb" is that his prior expectation for the probabilities is always uniform.  Then he updates those prices based on the total of what he's bought and sold and how much money he has left to help pay out winners (if someone buys a million tickets when the market maker only has $1000, the tickets might cost $0.9997 each and most of the payout will be the buyer getting his own money back, but the market maker does "help" by adding $1,000,000 - $999,700 = $300 to the pool).

That means people only buy the assets corresponding to outcomes with better than uniform probabilities at a nice discount price (granted at the cost that 5% of their orders will instead be forced into a speculative asset which gets its value from the outcome being contrary to the market's expectation of the outcome immediately prior to the outcome being known to the blockchain).

Yes, this is true -- but the discount quickly vanishes after only a small fraction of the orders are filled, because the market maker's funds dwindle.

That brings up another question. Won't the market always adjust to make the true outcome most favorable faster than a super majority of the judges can put the outcome into the blockchain?

Yes.  If everyone saw on TV that Ron Paul won, but it'll be a few days before the official result comes in and the judges input it into the blockchain, then everybody'll be buying C at $0.99 and trying to unload A or B at $0.001.  The $0.01 discount on C would be basically because some people with C might want the convenience of cashing out now instead of in a few days, and they want it so bad they're offering to give 1% of their payout to somebody else if that's what it takes to make it happen.  The A and B assets would probably be completely illiquid -- whoever ended up with them is stuck with the assets and their $0 payout, because the supply of fools willing to buy assets known to be worthless is usually quite limited, and all the people willing to sell to them at any price will quickly part them from their money.

In other words, while we're watching who various states went for on TV, people will be trying to buy the winner before he's all the way in the $0.90 range and sell the loser before he's totally worthless.  They'll be trading to contrarians, people trying to sell an overvalued lead horse and trying to pick up shares in the underdog on the cheap.  In the course of those madly gyrating market conditions, somebody will end up with all those A and B shares and be unable to unload them, their orders will go unfilled and they'll end up with worthless assets.  Traders who prefer a calmer style could simply pick their horse at more stable prices earlier in the week, then simply hold the shares until it's all over.

So isn't the market maker pretty much always going to lose?

Yes.  Which is why in the paper he suggests it be funded by someone who derives value from having the prediction, because they can expect a loss from funding the market maker.

I say the market maker should be funded by equity investors, and everyone who places a pre-order becomes an equity investor in the amount of 5% of their order.  Everyone who places a pre-order gets a piece of the action when the market maker has their dumb initial position with A, B, C all at $0.34.  The +EV of that piece cancels out the -EV of investing in someone who only makes money when a free market doesn't work.  It has to cancel because there's nowhere else for the money to go!

I spent some time looking into it.  Bookie stands to lose in some cases, but how much does he stand to gain?

If asset X wins, the bookie's leftover funds are the difference between his cash reserves and the float of asset X.  So the biggest win for the bookie is if the least popular option ends up winning.  In other words, the bookie's betting against the market; the bookie will make a profit when the market is wrong!

In the paper he talks about the bookie being altruistically funded by someone who derives value from knowing the prediction.  E.g. a newspaper wanting a poll result to sell papers, a business wanting a prediction to help place investments, etc.

I think a better way is to have the bookie funded by orders themselves.  I.e. have a preorder period, let the market open happen some time after the asset's been defined.  In the preorder period, orders can be placed but don't execute (in fact they can't execute because the bookie is initially the only seller of all the assets, so the market has to be closed until he's funded).  Then at some defined point in time, the market opens -- 5% is taken from every order and used to fund the bookie operations.  I think the 5% should not be a fee, the users should get an equity position in the bookie, which will make bank if the decision has a float much lower than the bookie's cash reserves.  So all funds used to buy A, B, and C, except for normal transaction fees (and maybe some functionality-specific fees), will be returned to holders of A, B and C.

What I've wanted to do for a long time is implement UIA with custom feed authority.  Let anyone register a market-based UIA and let the issuer specify a feed authority, an account or set of accounts that can set the feed value.  Shorts and longs then bet against each other on the feed.  Then have a process for transitioning that to a delegate-based feed when the market is big enough.

Let good feed ideas enter the system without having to convince a majority of delegates.  Anyone with a feed and an idea should be able to put it out there, and people who like it can trade on it as long as they can find a counterparty.  As long as the DAC collects fees from the whole business and delegates aren't overburdened, we should enable people who want to trade BitLTC or BitDOGE or BitFloridaSwampland.  The current system is bottlenecked on the delegates having to all run a feed script for every market-based asset.

Yes, relying on un-accountable non-delegates to provide the feed requires centalization and trust -- perhaps too much centralization and trust -- but people will know up front that those are the rules for MBUIA and should invest accordingly.

But we have to balance between getting 1.0 out and dreaming up new features.  If we keep on adding new features, then the Big Release will be really awesome but it won't happen 'til 2025 and Ethereum, Ripple and everybody else will have eaten our lunch.

For those who haven't been following, the following changes are planned:

- minebitshares.com will pay out in BitUSD
- minebitshares.com will eliminate its pool fee
- The payout will be subsidized ("juiced") by our marketing budget

Essentially, we're allowing people to merge-mine the juice, but only if they use our pool and accept BitUSD payouts.

If our target pool volume is $1000 / day, that works out to $30,000 / month new capital, for which the budget would be funding "juice" at which would be $1500 / month or $50 / day (comparable to a traditional marketing campaign).

I think it would be better to simply split $50 / day among all miners who show up.  If the pool volume is more less than $1000 / day, then they get better than returns.  Since our pool volume is tiny at the moment, this would lead to fantastic returns for people who switch early which would be a great boost to our marketing (we might get several people saying "switch to this pool, I did and quadrupled my returns OMG").  More importantly, if we exceed our target, then we can save a lot of money.  If we hit $2000 / day, then our budget would still be capped at $50 a day and the miners simply get 2.5% instead.

Offering a fixed juice budget is basically a no-reserve single-price auction for the capital inflow, which allows the market to efficiently discover the "right" juice percentage.  Which in theory should be pretty close to zero, i.e. if we're the only pool willing to operate at a loss, we should be able to capture the entire market.

Offering a fixed juice percentage of is still buying capital inflow, but like any scheme where you have a price that doesn't respond to market signals, it's likely the price will be too high (we'd be paying more than we need to, exceeding the target and busting the budget) or too low (we could be offering a higher return and attracting more people while remaining within the budget).