All orders will survive the fork, but after the fork they will execute relative to price feeds rather than the average. 

So I assume you're referring only to margin call orders.

What if the BitUSD price is going up (that is, the real price, determined by what people are willing to trade at) -- but that is not reflected in the feed until some time later?  I wonder if that delay might exceed the moving average delay long enough to increase the risk of getting into an FDIC situation, where some shorts' collateral is totally wiped out and they need to be "rescued".  Did the BitFDIC idea ever make it into production, anyway?  How does the BitFDIC deal with needing to print BTSX?

[1] I prefer avoiding the term "fork" or "hard fork" because that implies something awful.  Another thread proposed "Mandatory upgrade" to be the terminology for any change to the blockchain validation algorithm.

No.  BitAssets like BitUSD are on the same blockchain as BTSX.  Have you discovered yet that there's an exchange built into the wallet?  The blockchain itself enforces the ownership changes that happen as a result of the orders on the built-in exchange.  The only way the blockchain can do that, is if BitUSD is on the same blockchain as BTSX.

Suppose there are two possible policies (P or Q) that the network could follow at the choice of the delegates.

Suppose 40% of the network will vote for delegates who support policy P but never those who support policy Q, while 60% of network will vote for delegates who support policy Q but never policy P.

I think bytemaster's goal in proposing this change is to incentivize delegates to move from policy P to policy Q in this situation.  With the intent of creating consensus -- reaching equilibrium when all delegates support Q.  [1]

I thought at first that this would happen -- delegates would always be incentivized to move from P to Q in order to raise their max payout.  Because moving from P to Q would always increase your approval rating from 40% to 60%, regardless of how many delegates currently support P or Q.

But I thought a little more and realized this is not actually the case.  While the GUI tells the user they can vote for any number of candidates, in actuality each BTSX can only vote for up to some maximum number of delegates K (to keep bytes per transaction reasonable).  The Q supporters have 0.6 * M * K total votes, while the P supporters have 0.4 * M * K total votes, where M is the total number of BTSX in circulation.  If there are N_P delegates who support P, and N_Q delegates who support Q, the average number of votes per delegate for each faction would be:

    A_P = 0.4 * M * K / N_P
    A_Q = 0.6 * M * K / N_Q

At equilibrium we must have A_P = A_Q (otherwise delegates would switch to the other faction to increase their payout):

    0.4 / N_P = 0.6 / N_Q

Which simplifies to:

    0.4 / 0.6 = N_P / N_Q

In other words, the equilibrium actually occurs when the factional proportions of the delegates reflects the factional proportions of the population.  I think this will happen as long as the number of approvals is limited by K, which in turn is a fundamental consequence of limited bytes per transaction and large pool of delegates, which cannot be overcome without increasing bytes per transaction (increasing bandwidth and storage requirements for everyone) or decreasing the number of live delegates from 100 to K (greatly increasing centralization).

One solution to the conundrum might be to allow transactions that ignore the limit K and vote for up to a full slate of 101 delegates (or 151 if we increase the delegate count), but requiring such transactions to pay R times the normal fee, where R is equal to the size of the transaction divided by the size of a normal transaction.  Thus, K becomes a "soft limit" where exceeding K merely leads to an increase in fees, whereas AFAIK currently K is a "hard limit" (transactions which attempt to vote for more than K delegates are simply rejected).

[1] Under the simplifying assumption that delegates always set their payout to 100%, are thus actually paid proportional to their approval rating, and only care about their payout rate.  I.e. this model doesn't consider delegates who set lower payouts to gain approval, or delegates who believe in a minority opinion for ideological reasons and are willing to accept a lower payout as the price of keeping their principles (although both of those are quite plausible real behavior of real delegates; indeed, enabling the first option is the reason why the client allows delegates to set their pay rate!)

Suppose I bought BitUSD by accepting somebody's short. If they close the original short will my BitUSD be converted to BTSX?

Closing a short is a two-step process for the short seller:

- Obtain BitUSD.
- Destroy the BitUSD to free the collateral (e.g. by clicking "Cover" in the GUI wallet).

In general, if you bought Alice's short for 100 BitUSD, and later she closes her short position, in between those things happening Alice must have provided $100 worth of value to some BitUSD holder in order to obtain the 100 BitUSD she used to close the position.  Likely this $100 value was provided in the form of BTSX in an order on the BitUSD / BTSX market, but it could just as easily be Bob's payment to Alice for painting his fence.

So if they close the original short, *somebody's* BitUSD was "converted" into whatever consideration Alice gave to buy back the BitUSD (but this was a mutually voluntary free market transaction).  The only exception is Alice's BitUSD can be converted involuntarily into BTSX if the price rises and the network enforces a margin call, but that's Alice's problem -- short holders (like Alice) can be forced out of their positions by the margin call, but long BitUSD holders (like you) cannot.

Is there any way to make a market order to cover?  If I'm short BitUSD, there's no economic reason I shouldn't be able to use the collateral to issue a Buy order at any price lower than the margin call (and if the order is filled, the BitUSD cover the position).

And there's an excellent reason to have this functionality:  If someone's entire wallet consists of short positions and they have no BTSX outside of collateral, it allows them to liquidate in an orderly fashion instead of being subjected to a margin call.  Even when not at the keyboard.

The limiting algorithm is   average price * 10 / 9... average price gets updated every time a trade occurs...  this limits new shorts, but strait up USD vs BTSX can trade at any price.   This is a birthing problem... working to increase the average price.

The minimum short price should be in the GUI.  I need to take a while to think about the economic implications of this limiting scheme and possible failure modes...

For those of us who build from source, please make a 0.4.8-a tag.  I am assuming current master is 0.4.8-a (853499ca3c7926286d2aa1e35eead6ffc39133aa).