Adding this grace period risks the security of the network -- protected shorts aren't providing liquidity to longs at the price feed (which is the entire point of having BitAssets in the first place, right?) and can get undercollateralized without being called.
My proposed tweaks with the grace period are nearly identical to the current BitAsset system with expiration except where the the expired shorts are ordered by collateral ratio rather than whatever order they use today. People complain about expired shorts and how this system gets rid of that restriction, but the reality is that making shorts callable from the beginning is nearly equivalent to reducing the expiration period from its current 30 days to 0 days (and setting expired cover orders at 99% of the price feed, ordering those expired cover by collateral ratio, and other smaller tweaks).
Also, I think you misunderstood my proposal. All short positions (whether in the grace period or not) are still subject to margin calls as before. It doesn't matter if the short is only one day old. If the collateral ratio falls below the margin call ratio limit, it will be margin called and the cover order will be offered above the feed price.
This is impossible if you always call the lowest collateral shorts (we'll always improve the strength of the average short's books by settling the short with the weakest books). With arhag's "grace period" scheme it is possible, however, if shorts protected by the grace period have worse-than-average books.
Undercollateralization is still possible with the new system. If the short position with the lowest collateral ratio is undercollateralized, the matching order will not get the full value back (at current price feed) for their BitAssets. However, if someone takes one for the team and removes that short with a redemption, other people will be able to get their full value back. Therefore, no one will be willing to redeem first and take the penalty all on themselves. You still need black swan liquidation when undercollateralization occurs in order to be fair to all BitAsset holders.
Also, again I think you misunderstood the matching rules of my proposal. Before a short can become undercollateralized, it must first be margin called. If it is margin called it is ahead of the queue of any other non-margin-called short position. There is no difference between my tweaked version and bytemaster's original version regarding this particular issue.
This simply doesn't work. The whole point of collateral is that it's a "backstop" for the system that the shorts need to cover to liberate. "Removable collateral" doesn't meet the definition of the word "collateral" which is "property used to guarantee a loan." Collateral has to be only allowed to increase. It's okay for a short to increase his collateral level because that increases the security of the system. However, if a short wants to drop his collateral level, he needs to cover and re-short.
The margin call limit is what protects BitAsset holders from undercollateralization. In my view initial collateral requirements are unnecessary (other than obviously being larger than the margin call limit). In a system where the short can choose any initial collateral greater than the margin call limit, there is no difference in terms of risk whether you allow removing margin (while still meeting minimum limits) or not. However, it does make things far more convenient for the short owner. The short owner could always short to themselves at the lower collateral ratio and use it to cover the old short. So why force them to do that rather than just adjusting the margin of an existing short. Also this IMHO flawed idea of never allowing collateral to decrease is the reason we have a broken implementation of partial cover operations and why we need to have hacks like breaking up short orders into small pieces to minimize the amount of free collateral to keep in order to be able to cover. If you could, as an example, partially cover half the debt and take back half the collateral, you wouldn't need hacks like that.
As for whether we should have a minimum limit on initial collateral that is greater than the margin call limit, I personally think it isn't necessary. From a risk perspective, we should mostly be considered with how much the price can fall in a short amount of time before undercollateralization occurs. This means you need to look at the case where the price has slowly dropped causing the collateral ratio of a short position to slowly drop from its initial collateral ratio to a ratio just above the margin call limit. That process can be incredibly slow. As long as the collateral ratio is above the margin call limit, the blockchain isn't going to force the short to cover above the price feed. What we should care about is how much leeway there is after the moment the blockchain has authority to force cover the short. This means we should care about how large the difference is between the margin call ratio limit and 100%, but not as much about the initial collateral ratio.
Also, you can view the assignment of a redemption request to the lowest short as having the short holders "bid" against each other in an "auction" which is "selling" the right to remain in the market when the long wants to settle. Auction-style systems only work when bidding requires at least the winning bidder to sacrifice something of value (i.e. pay a price proportional to their bid). Tying up their capital for a few minutes when the redemption is actually processed, is not requiring sacrifice of a very meaningful amount of value (there's an incentive to add a ton of collateral a few minutes before a redemption request is due to be processed, then pull out your collateral a few minutes after). Tying up capital for an indefinite period of time (until covered or redeemed) is definitely a big enough sacrifice of value to be meaningful, tying up capital for a few minutes is not.
Redemption requests can come at any time. Yes they have a delay which gives the short enough warning to adjust their collateral, but the question is what are they going to do with the free collateral if they need to have it ready (in as little as 24 hours) to get them to the back of the queue whenever a new redemption request comes in? Since you cannot predict the quantity of redemption request that may pop-up, the short owners are basically going to have to effectively treat the free collateral as locked collateral. They wouldn't risk putting it towards some bond that lasts a month. They will have no ability to pull it out in time to protect themselves from a redemption request.
Also, even if you forbid removing collateral from a short, people could still simulate it by rolling over their short. So let's say the price of BTS went up so that the short is excessively collateralized. The short may want to use the excess BTS for other purposes, e.g. compound gains by using it to short more BitAssets. So they self-short with spare BTS at the lower initial collateral ratio for a larger amount of BitAsset debt than they already owe, use a fraction of the BitAssets collected to fully cover the old short, and then sell the remaining BitAssets on the market. Or alternatively, they could just pull the excess BTS out of the existing short position and use that to create a new short order for the additional BitAsset debt they want to be exposed to. Why not allow them to do it the easier way that doesn't involve self-shorting?
This post is specifically addressing a portion of Arhag's proposal with multiple queues. If I understand that proposal correctly, Arhag is essentially saying that "A settlement offer is the long requesting to trade their long for a certain amount of BTS. Why don't we just let the system use the market to give the long what they are asking for, if someone in the market is willing to provide it? That will give the settlement process a chance to be completely voluntary, and only resort to involuntary settlement when no one is willing to serve as a counterparty to the redeeming long holder."
The answer is that the 24-hour period between the filing and execution of the redemption request actually has a purpose that hasn't been mentioned in this thread as far as I can see. There is no technical obstacle to processing redemption requests immediately. However, such a scheme would suffer from a critical economic flaw: The long is free to view the feed's data sources (external exchanges, etc.), and is able to react to changes in these external data sources much faster than the feed.
Thus, with instantaneous requests, a long holder would know (through their own observations of the external data sources used to produce the feed) that the settlement value of their long position is going to go down in the near future -- and then settle immediately, before the feed has a chance to update.
The delay period prevents this attack. It forces the long holder to say "I'm going to redeem" without knowing exactly what the redemption price will be.
So if I understand what you are saying correctly, you are basically saying that once you make a redemption request you are not allowed to cancel it during the 24 hour waiting period. If you were able to cancel it, you could effectively convert a redemption request with an arbitrarily long waiting period into a instantaneous request by simply deciding whether to cancel or not just prior to the end of the waiting period, based on which is the more profitable action given what you know about the near future feed price.
So with my proposed tweaks that would mean that redeem orders could not be cancelled unlike all other orders in the system.
Which brings us to Arhag's system. We can't match the long holder against a market order until we know the redemption price, and a fundamental feature of the system, which I included in the system because I believe is economically necessary for it to function, is that we don't know the redemption price until the redemption time.
The unactivated redeem orders would be just like regular relative ask orders and would match (if possible) at the current price with any bid order but not with the callable short positions in the regular call queue (however they would match with margin called shorts in the margin call queue). It is only when they become activated redeem orders after the waiting period that they can force the short position at the head of the regular call queue to match with it. It is only in this case where you need to worry about feed price prediction attacks since, ignoring margin calls, these are the only situations in which the fund owner hasn't given explicit permission to offer their order at the price it is offered at (technically relative orders are also at risk to feed price prediction attacks, but that is a risk they willing took on by choosing a relative order and you have to assume they account for that risk by adding enough spread to protect their orders). However, if redeem orders cannot be cancelled, the only action the owner of that order could have possibly done in response to information they had was at least 24 hours before the match occurred (meaning they couldn't predict the match price at the time they still had the ability to influence the order).