bytemaster said 0.4.10 "switches to price feeds rather than moving average" here:  https://bitsharestalk.org/index.php?topic=8011.msg105611#msg105611

Does anyone know exactly how the price feeds will be used, and what they'll be used for?

There was some discussion that the median price feed might be used as the margin call price, and/or as a basis for floor / ceiling on trading.  Is the feed used for one of these purposes?

If the median is going to be used in one of these roles, or otherwise seriously affect my trading activity, the UI needs to show it.  By "accessible" I mean some way to filter red (outdated) feeds, sort the remaining price feeds, and put some kind of bar where the median is.

If price feeds need constant and accurate updates to make the market work, we need to make sure delegates are educated about their new responsibilities to maintain a current price feed, and give them a little time to set up scripts or other procedures to make that happen.

If price feeds have a major role in 0.4.10, information about the change needs to be a lot more accessible than a single post buried many replies deep that simply says "we've switched to price feeds."

Just to see what would happen, I sent 15 USD to cover a short with only 10 USD of value.  The extra 5 USD seems to have disappeared!  What happened to it?  (Log attached, I edited it to only show relevant parts.)

EDIT:  This is on dry run 12 testnet.

I always thought:

- A short would be implemented by allowing an address to carry a negative USD balance, in which case (some portion of) the positive XTS balance representing the collateral would be locked to that address.
- Covering a short can be done by sending USD to the short address, if the wallet controls another address that has a positive USD balance.
- Covering a short can also be done by issuing a market order to buy USD for XTS, the order is allowed to use XTS from the collateral in proportion to the negative balance that would be erased.

I have some USD from a successful ask order, so I thought the wallet_market_cover command would simply send USD from one address's positive balance to erase another address's negative balance.  This is apparently not what happened, since my balance declined by 15 USD.

The USD disappearing makes no sense!

default (unlocked) >>> wallet_market_order_list USD XTS
TYPE        QUANTITY            PRICE                         BALANCE             COST                COLLATERAL          ID
================================================================================================================================
short_order 11,271.64557 XTS    0.0079 USD / XTS              11,271.64557 XTS    89.0460 USD         N/A                 XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
cover_order 224.55088 XTS       0.00445288836098081 USD / XTS 0.9999 USD          0.9998 USD          299.40118 XTS       XTSFnFEATWvtgcpVoncesBWygRJ317EkgPEH
cover_order 22,455.08982 XTS    0.00445332888007125 USD / XTS 99.9999 USD         99.9998 USD         29,940.11976 XTS    XTSArZdx8nJayA8z4WrCQjE21mf5v5r7Y5ng
cover_order 189.87340 XTS       0.00526614049150644 USD / XTS 0.9999 USD          0.9998 USD          253.16454 XTS       XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
cover_order 1,890.00000 XTS     0.00526666666666666 USD / XTS 9.9540 USD          9.9539 USD          2,520.00000 XTS     XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
default (locked) >>> wallet_market_cover drltc 1 USD XTSFnFEATWvtgcpVoncesBWygRJ317EkgPEH
default (unlocked) >>> wallet_market_order_list USD XTS
TYPE        QUANTITY            PRICE                         BALANCE             COST                COLLATERAL          ID
================================================================================================================================
short_order 11,271.64557 XTS    0.0079 USD / XTS              11,271.64557 XTS    89.0460 USD         N/A                 XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
cover_order 22,455.08982 XTS    0.00445332888007125 USD / XTS 99.9999 USD         99.9998 USD         29,940.11976 XTS    XTSArZdx8nJayA8z4WrCQjE21mf5v5r7Y5ng
cover_order 189.87340 XTS       0.00526614049150644 USD / XTS 0.9999 USD          0.9998 USD          253.16454 XTS       XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
cover_order 1,890.00000 XTS     0.00526666666666666 USD / XTS 9.9540 USD          9.9539 USD          2,520.00000 XTS     XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
default (unlocked) >>> wallet_market_cover drltc 15 USD XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
default (unlocked) >>> wallet_account_transaction_history drltc USD 2 17000
 RECEIVED            BLOCK     FROM                TO                  AMOUNT                  MEMO                                        BALANCE                 FEE                 ID
================================================================================================================================================================================================
|2014-08-10T23:48:32 17286     drltc               COVER-FnFEATWv      1.0000 USD              payoff COVER-FnFEATWv                       0.0000 USD              0.00000 XTS         ae2f47b1|
|                              COVER-FnFEATWv      drltc               299.30118 XTS           cover proceeds                              299.30118 XTS                                       |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|2014-08-10T23:55:36 17327     drltc               COVER-2886bmzN      15.0000 USD             payoff COVER-2886bmzN                       0.0000 USD              0.00000 XTS         bb116fb6|
|                              COVER-2886bmzN      drltc               2,519.90000 XTS         cover proceeds                              2,819.20118 XTS                                     |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
default (unlocked) >>> wallet_market_order_list USD XTS
TYPE        QUANTITY            PRICE                         BALANCE             COST                COLLATERAL          ID
================================================================================================================================
short_order 11,271.64557 XTS    0.0079 USD / XTS              11,271.64557 XTS    89.0460 USD         N/A                 XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF
cover_order 22,455.08982 XTS    0.00445332888007125 USD / XTS 99.9999 USD         99.9998 USD         29,940.11976 XTS    XTSArZdx8nJayA8z4WrCQjE21mf5v5r7Y5ng
cover_order 189.87340 XTS       0.00526614049150644 USD / XTS 0.9999 USD          0.9998 USD          253.16454 XTS       XTS2886bmzNNa4ajh3o6eVvVYo9mc2Ca2RZF


I dislike the trustee concept.  But the more I thought about it, the more I realized that we really don't know any technical details.  So far, the only information I've seen is that the new system will involve a single centralized entity. 
Countless words on this forum have already been devoted to the various strengths and weaknesses of the trustee from legal, regulatory, and marketing perspectives.  Those are surely worthy issues, but if you'd like to pursue them, please do so in a different thread.  I'd like this thread to be solely about technical specification and analysis of cryptocurrency designs that incorporate the trustee concept (with perhaps a little economic analysis as well).

This is a very recent direction change, and I'm not sure that bytemaster or anybody else has publicly discussed detailed technical mechanisms that might be used in a trustee-based BitShares X.  The goal of this thread is to begin that discussion.  Legal, regulatory, marketing, and economic perspectives are off-topic (but may be tolerated if they inform technical decisions).  The primary focus is discussing the practical engineering concerns of trustee-based cryptocurrencies, with a focus on how BitShares X should work.

If you like my analysis in this thread, and want to know my thoughts on how a non-trustee-based BitShares X should look, you can read all about that at https://github.com/drltc/xts-proposal -- and you can also donate PTS to the address there.

In the thread about margin requirements, I made a detailed post about the mechanics of the market, which bytemaster said is not accurate [1].

The concern I'd like to raise is that, AFAICT, information at that level of detail exists nowhere, except perhaps in the code itself.

I believe that launching the BitShares network without a detailed specification of the intended mechanics of the market will unnecessarily endanger the security, stability, and reliability of the BitShares network.  Perhaps the specification will need to be revised as issues come up in the implementation, and perhaps parts of the specification can be developed by describing the behavior of the current code.

I firmly believe that it should be possible to understand the detailed mechanics of the market without diving into the code.  For example, I have strong objections to the proposed increase in margin requirement.  Bytemaster doesn't seem to be persuaded by my concerns.  If we had a common understanding of the market mechanics, I'm certain we could resolve this disagreement fairly efficiently.  However, without a specification, we are forced to make detailed explanations of each others' mental models of how the market works, find mismatches, and then analyze each mismatch in detail.  Also, there are many I3 or bytemaster videos, forum posts, etc., floating around.  Some of these are outdated or contradictory.  (In the linked thread, I discuss how there are currently no less than three mutually contradictory I3 / bytemaster claims about what interest short positions are charged, if any.)

It would be nice to have a single place to collect all of the currently official market mechanics.

After the specification is written, I would also like to ask for some time for the community to study and discuss it, before the launch.  Even if this means delaying the launch.  Because currently, I think only bytemaster really understands the detailed mechanics of the market.  Some changes (e.g. changing margin from 2x to 10x or vice versa) would be trivial to implement before launch, but really hard to implement after launch.  In particular, in the case of changes to the mechanics which will cause some investments to benefit and others to suffer, would be very politically risky for the maintainers to implement after launch.  Fixing bugs is an entirely appropriate task for the developers after launch; changing the terms of the system's financial instruments after people have bought them is not.

[1] https://bitsharestalk.org/index.php?topic=3015.msg42198#msg42198
 

This will be partly an explanation of my understanding of short sales, then I'll develop some detailed ideas for liquidation mechanics.  This is in response to the following threads:

https://bitsharestalk.org/index.php?topic=3015.0  (I am explaining the issue raised in this thread's OP)
https://bitsharestalk.org/index.php?topic=3130.0  (I propose anti-short-squeeze measure which will make Slingshot attack impractical)

I will reserve some posts at the beginning of the thread, because I'm long-winded and I want to logically break up what I have to say into multiple posts without later posts getting buried in replies.

If you find my explanation helpful, please send PTS to PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z