I'm hearing that one of your key issues is this - That in the current system there are the immediate profit incentives for shorts to respond to changes in bitAsset demand, by being able to trade favourably to the price feed (above it, when buyers demand new creation, or below it, when sellers demand supply destruction). In the proposed system, this profit incentive is removed, because all trading is at the price feed, and the regulating mechanism to match supply and demand is purely the interest rate.

Not really. In the current system there is no immediate profit incentive (for either case). In fact, in your proposed system there is an immediate profit incentive (through arbitrage) when the BitAssets are trading (presumably on an external exchange) below the BTS/BitAsset price feed: buy the cheap BitAssets with your BTS and then use it to withdraw more BTS then you paid from the bank. In the current system this is not immediate because of the 30 day minimum before shorts can be called (assuming margin call isn't triggered). Since the BTS/BitAsset feed price may shrink below the price you purchase the BitAssets at within that max 30 day waiting period, there no guarantee of profit by buying the BitAsset selling well below the feed and then using those BitAssets to place a sell order maintained just slightly under the price feed. But one of my main points in the previous post was that neither the current system nor your proposed system help the peg in the case when the BitAssets are trading above the BTS/BitAsset feed price.

The other main point was that despite the fact that making the short positions callable before 30 days (even if they maintain margin) helps the peg in the case where BitAssets are trading below the feed price, I don't consider this to be a significant enough issue to make the drastic change of taking away the guarantee to the shorts that as long as they maintain enough collateral to avoid margin calls, they won't have to realize losses in less than 30 days.

I believe the ability of the interest rate to mediate supply and demand would be fairly strong in most circumstances. It seems an unlikely circumstance that when bitCurrency demand is strong, with the longer term implications that has for BTS, nobody is willing to borrow freely to buy BTS.

And yet right now there is a bid (BitUSD buy) order above the feed price (highest bid is 115.9433 BTS/BitUSD and feed price is 115.5082 BTS/BitUSD) and the lowest ask is 116.1030 BTS/BitUSD and the lowest short sell order is at 117.0000 BTS/BitUSD. Granted that isn't very strong demand, but I remember situations where the highest bid was more significantly larger than the feed price and yet the shorts weren't bothering to sell to them. The problem is that there is no guarantee that someone will later sell the needed BitUSD to the short seller at a price below the price they entered the short at. In your proposed system this means that even in the case where the feed price in BTS/BitUSD goes down lower than the borrow price and the borrower submits a loan repayment order, there is a risk that by the time the loan repayment order is matched by a withdrawal or new borrower the feed price would have gone back up above the price the borrower originally got the borrow order matched. Even if the borrower cancels the loan repayment order if the feed price goes up above the original borrow price, there is then the risk that the feed price will continue going up until the loan is margin called or more likely that the loan will be called at a time when feed price is above the original borrow price because someone wants to withdraw and there are no margin calls, new depositors, or loan repayments left in the queue. These risks may prevent the borrower from taking a 0% loan.

And this also needs to be weighed against the tremendous benefit that bitAsset owners get by being guaranteed to exit at any time at the fair price.

I just want to be clear that those are orthogonal concerns. The benefit to BitAsset owners of being guaranteed to exit immediately at any time at the feed price comes from making the loans callable before 30 days even when margin requirements are maintained. The disadvantage discussed above is not a result of making the loans callable. It exists in both your proposed system and the current system.

There are advantages to shorts of the proposed system too - they can hold shorts indefinitely as long as they are willing to improve collateral and interest, and they are always guaranteed to enter and exit at the feed price even when being called. It's best to weigh the risks in both systems:

- In the proposed system there are no expiries. Expiries in the current system create risks for shorts - they force buying even if liquidity is thin (in which case the market is not really demanding this action anyway), and they force the short out of position for an unknown time.

Actually expiration is not a big deal in the current system when compared to your proposed system. If a short expires and there is not enough BitUSD sells at or below the feed price, it will just sit at the feed price until it gets matched. If no one sells at or below the feed price, it can just sit there indefinitely. Similarly, with your proposed system, if no one makes a withdrawal, the loans can just sit there indefinitely without being called (assuming they aren't margin called). However, if anyone withdraws (equivalent to BitUSD sell just slightly under the feed price) and there are no other margin calls (equivalent to margin call orders), deposits (equivalent to BitUSD buy at feed price), or loan repayments (equivalent BitUSD buy at feed price or expired cover orders), then the system will call a loan. In the current system, if there already is an expired cover order sitting in the order book and someone does a BitUSD sell just slightly under the feed price, the BitUSD sell will match with the expired cover order (forcing the expired short position to at least partially exit from the position). The only difference is that a BitUSD sell order won't cause short positions that haven't yet expired (and have enough margin) to be called, whereas a withdrawal in your system can force a brand new short position to exit. So there is actually more risk for shorts (borrowers) in your system. If I short at the current feed price in the current system, I know that as long as the feed price does not grow larger than 150% of the current feed price then my short position will not be called in the next 29 days. I have no such guarantee with your proposed system.

Actually to make it equivalence better we would require that given two orders (a BitUSD buy order and expired cover order) at the same price, the BitUSD buy order is preferentially matched over the expired cover order, and given two expired cover orders at the same price, the expired cover order corresponding to the short position with the lower interest rate is preferentially matched over the expired cover order corresponding to the short position with the higher interest rate.

- In the proposed system, the loans are callable at any time (according to market demand), but the queue of callable shorts is rank-able. That is, every short knows where they stand in this queue, and if they are unhappy with their position, they can lift the interest rate or collateral. Essentially if they are keen to continue carrying the short, they can continue to do so indefinitely, as long as bitCurrency demand supports this. Those less keen to hold are the shorts at risk of call. There is a risk though that if they are not actively monitoring the queue, that they may unexpectedly fall in the queue and get called, so this may require an alert mechanism.

I think allowing shorts to raise the interest rate they pay after getting matched is a nice addition to the current system. This would be useful with the matching priority changes described above to make it less likely that their expired short gets matched. To reiterate, the callable shorts in your proposal are equivalent to expired shorts in the current system. Non-expired shorts in the current system are something that does not exist in your proposed system. Essentially your system is like setting the expiration period for shorts to 0 days and setting up the matching order for expired cover orders to be in the ascending interest rate order. Expired shorts would still be capable of being manually covered. To get the BitUSD needed to manually cover, the short position owner would get BitUSD the same way a "depositor" would (buy BitUSD just slightly above the feed price).

- In the proposed system, any transaction, including being called, is transacted at the feed price. There is zero price risk. In the current system, there is price risk when shorts are called or expired, that could work out favourably or result in loss.

What do you mean by price risk?

Regarding the BTS bull Pool proposal:

I'll have to spend time thinking about your BTS bull pool proposal later and get back to you on it.

My preference would be something like the following:
BitUSD : BTS [flip]      Call price       Last price       Spread   Total BitUSD Supply   Total BTS Supply
                         100 BTS/BitUSD   105 BTS/BitUSD   0.905%    433,000.00 BitUSD     2,503,706,843 BTS
------------- -----------
| Orderbook | | History |
| --------- | |         |
----------------------------------------------------------------------------------------------------------------------------------
|   |                         
|   |                                                   [Orderbook Chart]
|   |
|   | Show quantity in: (*) BitUSD  ( ) BTS
|   |
|   | Bids                                                           Asks
|   | ----------------------------------------------------------     ----------------------------------------------------------
| l | | Type          | Quantity (BitUSD) | Price (BTS/BitUSD) |     | Price (BTS/BitUSD) | Quantity (BitUSD) | Type          |
| e | ------------------------------------------------------------   ------------------------------------------------------------
| f | | Margin Call   |         12,000.00 |           111.1111 |^|   |           112.0000 |          1,215.00 | Short Sell    |^|
| t | | Buy BitAsset  |            600.00 |           101.2500 |||   |           120.0000 |            750.00 | Sell BitAsset |||
|   | | Expired Cover |          1,601.32 |           100.0000 |||   |           120.0000 |          5,000.00 | Short Sell    |||
| c | | Buy BitAsset  |            512.34 |            99.9091 | |   |                    |                   |               |||
| o | | Buy BitAsset  |            200.00 |            99.0000 |v|   |                    |                   |               |v|
| l | ------------------------------------------------------------   ------------------------------------------------------------
| u |
| m | [*] Display detailed short information
| n | ------------------------------------------------------------------------------------------------------------------
|   |
|   | Margin Call Orders                                                       
|   | ---------------------------------------------------------------------------------------------------------------
|   | | Call Price (BTS/BitUSD) ^2 | Interest Rate (APR) -- | Owed (BitUSD) -- | Expiration      ^3 | Condition  v1 | 
|   | -----------------------------------------------------------------------------------------------------------------
|   | |                   110.0000 |                   0.00 |        12,000.00 | 6 Days             | Margin Called |^|
|   | |                   130.0000 |                   2.00 |         1,501.32 | 2 Days Ago         | Expired       |||
|   | |                   135.0000 |                   0.00 |           100.00 | 1 Day Ago          | Expired       |||
|   | |                   130.0000 |                   0.00 |        10,000.00 | 10/25/2015 9:18 AM | Active        |||
|   | |                   165.0000 |                   1.10 |         3,000.00 | 30 Days            | Active        |v|       
|   | -----------------------------------------------------------------------------------------------------------------
|   |
|   | Short Sell Orders
|   | -------------------------------------------------------------------------------
|   | | Price Limit (BTS/BitUSD) ^1 | Interest Rate (APR) v2 | Quantity (BitUSD) -- |     
|   | ---------------------------------------------------------------------------------
|   | |                    112.0000 |                   1.00 |             1,100.00 |^|   
|   | |                    112.0000 |                   0.50 |               115.00 |||   
|   | |                    120.0000 |                   0.00 |             5,000.00 |||   
|   | |                             |                        |                      |||
|   | |                             |                        |                      |v|   
|   | ---------------------------------------------------------------------------------
|   |
|   | ------------------------------------------------------------------------------------------------------------------
|   |
----------------------------------------------------------------------------------------------------------------------------------
The left column under the "Orderbook" tab would be similar to what you have in the left column in your layout (the box with tabs to Buy, Sell, and Short and the respective open orders tables underneath), however there would be an addition Cover tab which would include the "Open Margin Orders" table (renamed "Open Margin Call Orders"). Later I can imagine the Cover tab supporting functionality like partial covers and adding collateral. Also the BitUSD balances and BTS balances would be shown in the left column (on top of the buy/sell/short box) and not in the right column (because they are user-specific information not market-specific).

There are two main tabs in my proposed interface: "Orderbook" and "History". The "History" would show the price history chart and the "Blockchain Orders History" table underneath it in the right column, and it would put the "Account Orders History" table into the left column. The "Orderbook" tab looks as I have laid out in ASCII above. I will explain it in more shortly. Despite this tabbed interface, if the screen is large enough, I think it makes sense to instead pull out the history tab contents and put it on the right side next to the orderbook tab contents. In this case I think the "Account Orders History" table should not be in a column by itself but rather underneath the "Blockchain Orders History" table. So the layout for large screens would be a three column layout in which the left column is the same as the left column described above, the middle column is the contents of the right column in the mockup above, and the right column is the price history chart followed by the "Blockchain Orders History" table followed by the "Account Orders History" table.

The tables have removed the two quantities (Quantity and Total) and kept only one. The asset that is used to display the quantity is the one that is selected in the "Show quantity in:" option box. The user change that selection at any time and it will update the Quantity columns of all of the tables appropriately. The market can be flipped as usual using the [flip] button. If the [flip] button is pressed in a "BitUSD : BTS" market, it will replace it with a "BTS : BitUSD" market and make appropriate changes in the rest of the interface. In general, the market is "Quote : Base". The prices will be given in Quote/Base. So if the market was flipped to "BTS : BitUSD" all the prices in BTS/BitUSD would be replaced with prices in BitUSD/BTS (also the ascending/descending sort of a price column would be flipped). By default the quantity to show is selected as the Quote asset, but of course it can be changed with the "Show quantity in:" option box.

The "Display detailed short information" checkbox toggles whether the "Margin Call Orders" table and "Short Sell Orders" table will appear underneath it. By default this checkbox can be unchecked (meaning not showing the tables).

When looking at a "Quote : Base" market in which neither Quote nor Base is BTS or alternatively one of Quote or Base is BTS and the other is not a BitAsset, the layout would look the same except there would be no "Display detailed short information" checkbox (and no "Margin Call Orders" table or "Short Sell Orders" table), and the Type columns from the "Bids" and "Asks" table would be removed.

When looking at a "Quote : Base" market in which Base is BTS and Quote is a BitAsset, the "Margin Call" type and "Expired Cover" type would be under the "Bids" table and the "Short Sell" type would be under the "Asks" table (as demonstrated in the example above). On the other hand, when looking at a "Quote : Base" market in which Quote is BTS and Base is a BitAsset, the "Margin Call" type and "Expired Cover" type would be under the "Asks" table and the "Short Sell" type would be under the "Bids" table.

The orderbook chart should always show the order types that fall into the "Asks" table on the right side and show the order types that fall into the "Bids" table on the left side. They should also be color coded to match the color of the titles of the "Asks" and "Bids" tables appropriately. The orderbook chart should allow one to zoom in/out and define the domain to be smaller than [lowest bid price, highest ask price]. Also the quantity shown in the orderbook chart should be of the asset selected from the "Show quantity in:" option box. The orderbook chart should of course visualize the feed price as a line as it currently does.

As can be seen by my mockup, the short sell orders are combined with the sell orders into one table. The "Short Sell Orders" table would include detailed information about the short sell orders that are not included in the combined table (such as interest rate offered), but would also differ from the combined order in that the price limit column would be the price limit set by the short (even if it is less, in BTS/BitAsset price, than the current price feed). The number shown for short sell orders in the price column of the combined table is instead max(price limit in BTS/BitAsset, feed price in BTS/BitAsset) if the Base asset is BTS or min(price limit in BitAsset/BTS, feed price in BitAsset/BTS) if the Quote asset is BTS. Also, short sell orders and sell orders at the same price are not coalesced together in the combined table to show that there are two different types of orders offered at the same price (my hope is that the market engine would actually match sell orders before short sell orders at the same price so that this visual distinction actually has important meaning, but until then it is just an aesthetic choice). However, multiple short sells orders at the same price are coalesced together and multiple sell orders at the same price are coalesced together. Similarly, expired cover orders, margin call orders, and buy orders are not coalesced together in a way that mixes types in the combined table (again it would be nice if the market engine guaranteed that given three orders of different types at the exact same price, the margin call order was matched before the expired cover order which was matched before the BitAsset buy order). However, orders of the same type and at the same price are coalesced together.

The collateral column is removed from the tables because it is redundant information (it can be calculated from the given columns and knowledge about the initial collateral requirements, margin call requirements, and expiration period of the BitAsset system). However, this information and any other detailed information (such as the precise time that a short position expires or the principal BitAsset owed not counting the interest) can be included in tooltips when hovering over a specific order in any of the "Margin Call Orders", "Short Sell Orders", "Blockchain Orders History", "Account Orders History", and "Open * Orders" tables. The tooltip over orders in the "Bids" and "Asks" tables could not provide the same level of information because in general orders can be coalesced together in those tables. However, the tooltip could still provide a calculation of the Quantity in units of the other asset type that is not already displayed as a column in the table.

The "Bids" and "Asks" tables should highlight orders for which one of the user's orders are coalesced into. Also, orders exactly at the price feed should also be highlighted in a different color.

The "Margin Call Orders" table adds a Condition column to show whether the short position is Active, Expired, or Margin Called. The expiration column also shows the expiration date even if the short position has already expired ("1 Day Ago" to "30 Days Ago" to a timestamp if older than 30 days). An "Expired" short position can become "Margin Called" but a "Margin Called" position can never become "Expired". The Expired and Margin Called items in this table are not removed until their BitAsset debt with interest (which is the Owed column) is fully paid off. Margin Called orders might have a Call Price larger than the current feed price, as shown in the mockup example. This can happen since the Margin Call would have been triggered when the call price was lower, but partially covering the short through the margin call could increase the call price. For example, if the short in that example originally owed 15,000 BitUSD and had a call price of 99 BTS/BitUSD, then the price feed updating to 100 BTS/BitUSD would trigger a margin call on that short which would cause it to purchase asks up to a price of 111.1111 BTS/BitUSD. Let us pretend there was only one ask order below that price: a short sell order for 3,000 BitUSD at 0% interest and a price limit at 110 BTS/BitUSD. Then the margin call would match against that order (fully matching the short sell order), pay 330,000 BTS from its collateral of 2,970,000 BTS, and reduce its debt owed from 15,000 BitUSD to 12,000 BitUSD. Thus the new collateral would be 2,640,000 BTS and the new debt owed would be 12,000 BTS, which correspond to a call price of 110 BTS/BitUSD. But just because the new call price is higher than the feed price doesn't mean the order is no longer margin called; the margin call order stays (and in fact moves with the price feed maintaining its 10% difference) until the remaining 12,000 BitUSD is fully matched.

Finally, the ^N and vN indicators on the "Margin Call Orders" and "Short Sell Orders" table indicate table sorting rules. The arrow direction indicates whether the column is sort in ascending or descending order. The number is a priority in sorting. The items in the table are sorted according to the column that has the first priority in sorting order, then any items with the same value are sorted according to the column that has the second priority in sorting order, and so on. Clicking on the sorting indicator toggles between ascending, descending, and neutral. Whenever a sorting indicator that had priority N is toggled to neutral, any existing columns with non-neutral sorting indicators that have priority greater than N in the table have their sorting priority decremented by one automatically. Whenever a sorting indicator that was neutral is toggled to a non-neutral setting, it gets a sorting priority that is one larger than the current largest sorting indicator priority of the table.

I don't know about changing potentially consensus breaking parameters like the block interval, but I agree that other parameters (like fees) should be dynamic.

Perhaps before requiring binding proposals it makes sense to use non-binding proposals to figure out stakeholder wishes and let the authenticity of the change come from a super majority of the delegates. So if more than 75% of delegates agree to a particular dynamic parameter change (for example, changing the asset registration fee or transaction fee) then the blockchain will accept the new parameter (no need to download new binaries compiled with a changed constant).

@Xeroc, I haven't actually designed a manipulation algorithm to exploit feed price prediction, but isn't it obvious that a noisy feed would be better than a predictable one? I'm working from this principle: if I can execute trades on btc38 and predict exactly what that will do to the price feed, then I can make money moving the price feed around. Probably a fraction of a percent per trade, but the fact is I'll be taking money from the system without providing any benefit. Doesn't that sound like something we should try to prevent?

It isn't obvious to me. I don't see how a deterministic price feed opens up any new attack vectors.

Let's say you could predict what the price feed would be within the next hour with perfect precision and greater than 99% confidence. What could you do with that information over someone who knows nothing about the price feed other than what it currently is? It doesn't allow you to predict how the bids and asks on the DEX will change. It allows you to know how short sells with a price limit below the feed price will change (assuming they do not get cancelled). So if you can predict that the price feed will shrink (in BTS/BitUSD) in the next 30 minutes, then maybe you decide to sell BitUSD right below the price feed and then wait for 30 minutes and then buy back more BitUSD from the short wall at the lower price. I just view this as similar to profiting from arbitrage and find it to be totally legitimate market behavior. Of course it isn't without risk since the short sell at the price feed might be cancelled after you sell the BitUSD but before the 30 minutes has passed. It also is even less of a serious issue if the delegates incorporate the most recent outside exchange info into their price feed just prior to publishing. In that case, you cannot predict the price feed very far into the future (less than 8 minutes if delegates update their price feeds each time they produce a block) since you can't predict how bids and asks will change on outside exchanges.

Trimming the blockchain is a feature I look forward to eventually seeing in BitShares. I don't expect it will happen anytime in the near future though.

I've written my thoughts on how this could be done here.

I hope the new version protect all automatic execute cover order, include expired order and margin call order.
don't sell the collection BTS  at price less than feed price

I'm not sure if the current implementation of the code as of v0.6.2 has the expired cover order set a price limit at the feed price as it is supposed to (I thought the recent expired short not buying up BitUSD sell orders at a BitUSD/BTS price below the feed price showed that it in fact does do this?), but the margin call cover order is supposed to have a price limit that is 10% lower than the BitAsset/BTS feed price. Why do you want margin call cover orders to get the benefit of being limited only to the feed price? With the 5% margin call fee gone that would mean there would be no disadvantage at all to letting a short get margin called (meaning no motivation to add collateral to a short position to prevent margin calls).

We're still trying to actually get withdrawals through. Once we have our gold and bitUSD out we will do a full calculation of losses and liabilities. Right now it looks as if about 30% of all CFSGOLD and CFSUSD funds have been turned into bter BTC IOU's that cannot be withdrawn from bter but supposedly will become real BTC over time through income from trading fees. We then have to figure out a way we can allow people to withdraw both their bitgold/bitusd and their portion of the IOU, something that can't yet be done with UIA's.

I think you will have to create new UIAs CFSGOLDB and CFSUSDB and sharedrop those on a snapshot of their respective UIAs. So CFSGOLDB would be distributed to a 100% snapshot of CFSGOLD and CFSUSDB would be distributed to a 100% snapshot of CFSUSD. CFSGOLD would then become a claim on the amount of BitGold you can get out of BTER while CFSGOLDB will be a claim on the amount of BTC you can eventually get from BTER from the BTC IOUs on the 30% of BitGold they took. Similarly, CFSUSDB would become a claim on the amount of BitUSD you can get out of BTER while CFSUSDB will be a claim on the amount of BTC you can eventually get from BTER from the BTC IOUs on the 30% of BitUSD they took. Alternatively, perhaps you could instead combine  CFSGOLDB and CFSUSDB into one UIA and just sharedrop that on a combined snapshot. Either way, when you finally received the BTC you will gradually need to convert the BTC to BitBTC (perhaps as a part of making the BTC/BitBTC markets?) so you can buy back and burn the CFS*B assets in the CFS*B/BitBTC market(s) on the BitShares DEX.