Here's my explanation.  I'm pretty sure this is correct, but not 100% sure.  I've been hinting in multiple threads that I'd like the developers to confirm I have all the details right, and/or publish an official or semi-official explanation of the new mechanics.  Interest was expressed, but I guess they haven't had time to do it quite yet.  So my explanation is probably the best that's going to be available for a bit.

The behavior for several versions has been to cancel short orders below the feed.

In 0.4.16, that is changing; short orders below the feed now execute at the feed.

You can view the feed as "pushing up" the price for all the shorts that fall below it, to the level of the feed.  If a short is pushed up so far that the shorter's collateral is less than 1/2 (i.e. order.collateral < feed_price * order.quantity) then the short won't execute.

Before 0.4.16, short collateral was always price times quantity.  Now, the shorter can optionally set collateral to be more than price times quantity.  Why would the shorters want to do this?  There are two incentives:

- A higher collateral short is able to be pushed up by the feed instead of being unable to execute when the feed tries to move up through it.
- When bidders try to buy through the short wall, the system prefers higher collateral shorts to execute first.

Here is the thread discussing these changes:  https://bitsharestalk.org/index.php?topic=9029.0

I just saw this thread, ran "info" twice and happened to see it cross back below 2 billion!  Here's a copy-paste with block numbers for posterity:

default (locked) >>> info
{
  "blockchain_head_block_num": 555311,
  "blockchain_head_block_age": "10 seconds old",
  "blockchain_head_block_timestamp": "2014-09-22T21:32:20",
  "blockchain_average_delegate_participation": "92.66 %",
  "blockchain_confirmation_requirement": 1,
  "blockchain_delegate_pay_rate": "2.19309 BTSX",
  "blockchain_share_supply": "2,000,000,001.77099 BTSX",
  "blockchain_blocks_left_in_round": 88,
  "blockchain_next_round_time": "at least 15 minutes in the future",
  "blockchain_next_round_timestamp": "2014-09-22T21:47:10",
  "blockchain_random_seed": "f328415b9decc04a75b559f9c2148d42f90d81c2",
  "client_data_dir": "/home/cc/btsx/.BitSharesX",
  "client_version": "v0.4.16",
  "network_num_connections": 12,
  "network_num_connections_max": 200,
  "ntp_time": "2014-09-22T21:32:30",
  "ntp_time_error": -0.019689999999999999,
  "wallet_open": true,
  "wallet_unlocked": false,
  "wallet_unlocked_until": null,
  "wallet_unlocked_until_timestamp": null,
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": null,
  "wallet_block_production_enabled": null,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null
}
default (locked) >>> info
{
  "blockchain_head_block_num": 555312,
  "blockchain_head_block_age": "8 seconds old",
  "blockchain_head_block_timestamp": "2014-09-22T21:32:30",
  "blockchain_average_delegate_participation": "93.52 %",
  "blockchain_confirmation_requirement": 1,
  "blockchain_delegate_pay_rate": "2.19307 BTSX",
  "blockchain_share_supply": "1,999,999,999.79720 BTSX",
  "blockchain_blocks_left_in_round": 87,
  "blockchain_next_round_time": "at least 14 minutes in the future",
  "blockchain_next_round_timestamp": "2014-09-22T21:47:00",
  "blockchain_random_seed": "72a2e5b13c7efa04310038145f8951f62ab50043",
  "client_data_dir": "/home/cc/btsx/.BitSharesX",
  "client_version": "v0.4.16",
  "network_num_connections": 12,
  "network_num_connections_max": 200,
  "ntp_time": "2014-09-22T21:32:38",
  "ntp_time_error": -0.019691,
  "wallet_open": true,
  "wallet_unlocked": false,
  "wallet_unlocked_until": null,
  "wallet_unlocked_until_timestamp": null,
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": null,
  "wallet_block_production_enabled": null,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null
}


Amateur cryptographers...sigh...

First of all, MD5 is insecure.  Don't use it.  Just don't.  For new applications, I recommend sha256 or SHA-3.

Second, the hash does no good unless you also digitally sign the hash.

Third, a signature does no good unless people can verify the key used to produce the signature belongs to a known trusted signer.

I believe the client has a command to sign a hash with the private key associated with a TITAN account.  I recommend using this to sign the sha256 and sha3 of each released executable.  And also the commit hash of each git tag.

I believe there is a way to actually include the signature with the tag so it can be automatically verified by git, but I think it uses GPG PKI.  Getting our own TITAN PKI to integrate with Git in a similar way would be a good bounty idea if there are any Git experts lurking in this forum.

We could also send an email newsletter subscription request to all bitsharestalk.org subscribers. That way very important announcements get to everybody.

Please don't rely on this.  I used a throwaway email to register, so I never check it.  Something publicly accessible like a forum thread would be better.

For those of us who run on multi-core systems (probably everybody except those running on VPS servers), it would help if those intense calculations were done on all cores.

In fact, some clever person seems to have filed a ticket suggesting this exact fix...24 days ago [1].

[1] https://github.com/BitShares/bitshares_toolkit/issues/718

Users are frustrated by the lack of communication surrounding the new v0.4.16 shorting mechanics:

yea it would be nice to know things like this BEFORE or at least once they are implemented......idk maybe under some kind changes to this version or something like that.

I realize developer time is at a premium, but there should be some official announcement channel to tell us about the changes in upcoming Mandatory Upgrades [1], such as the new shorting mechanics.

I am aware of two existing channels for this purpose, but one of them does not mention short issues at all [2], and the other merely says "Revised consensus market engine shorting mechanics" [3].

If we want traders and investors to take our markets seriously and make investments in our ecosystem, we need to provide a channel to tell them about major changes like this one.  Without requiring them to wade through many pages of irrelevant forum discussion, of which only a small handful of posts will contain accurate, up-to-date information.

IMHO such a channel should have an RSS feed and anyone should be able to submit improvements to the descriptions, but the description should be approved by the developers for accuracy, brevity and clarity before it can be posted.  I like the idea of using a Github repo with version-controlled Markdown files and accepting pull requests.  But a wiki, forum thread, or documentation file(s) in the main BitShares repo would also be reasonable choices.

My post in the pre-change discussion [4] or the help that I gave to the above frustrated user [5] contains the sort of description of the mechanics I'm thinking about.  But before the project adopts content from either of those posts as an official or semi-official description of how the system works, I would want the description to be reviewed for accuracy by bytemaster, vikram or another developer who's actually written or reviewed the patches which implement the new mechanics.

[1] The term "Mandatory Upgrade" is preferred to "Hardfork" for marketing reasons.

[2] https://bitsharestalk.org/index.php?topic=7067.30

[3] https://github.com/dacsunlimited/bitsharesx/releases

[4] https://bitsharestalk.org/index.php?topic=9029.msg117125#msg117125

[5] https://bitsharestalk.org/index.php?topic=9159.msg118819#msg118819

I've seen your updated proposal. The concept of "deadline transaction" is doable in the updated document (It couldn't be implemented in the initial variant without BTC hardfork). However Alice/Mike should be able to control the transaction fee and nLockTime variable. So this should be included in the initial orders (or mandatory specified by the protocol).
I'll update the proposal with reference to your description of "deadline transaction".

Your description of the deadline transaction currently states:

7. If the “Deadline Transaction” is confirmed all the funds instantly released.
8. If the “Deadline Transaction” is rendered invalid (due to Richy’s other transactions spending some of the same inputs) -> This is the same as Richy failing to fulfill the deal => Richy’s collateral is lost.

This sounds backwards.  If the deadline transaction is confirmed, it's treated the same as Richy spending the same inputs; the deal is cancelled and Richy loses collateral.  In fact, in my protocol there is no need to scan the BTC network for the deadline transaction specifically.  Instead, you scan the BTC network for any transaction sending the BTC anywhere but Mike's address.  Upon finding such a transaction, trigger a failure-to-deliver, resulting in Richy's losing collateral, and Mike's BTSX being returned to him from escrow.  If we just let the failure-to-deliver trigger be based on the actual wall-clock time of day, we risk screwing over Richy if he's honest and the Bitcoin network is just being slow.  The point of the deadline transaction is to allow Mike to trigger the failure-to-deliver logic after some amount of time, using a trigger event that is guaranteed to return Richy's BTC.

Also, how do Mike and Richy establish that delivery will use particular inputs?  The deadline transaction requires the parties to designate specific BTC inputs as the coins to be delivered.  When and how do the parties make this designation in your protocol?