Thank you arhag. I appreciate the input. I feel this way too, but at the same time it seems most people want to get us  away from using delegate pay and become profitable on our own...so I'm doing very much what you are saying.  Testing it.

Now with that said. ..the average LTB show takes over a week to get to the public from the recording date and we are shooting for,  at most 48 hours. ..and if someone else attends, they can all record it too. Ultimately I want to see more of one thing: open participation.

It is unfortunate if people aren't willing to vote for a delegate to fund such an important function (IMHO) in our community as the Mumble hangouts. The costs aren't even that high (are they?). I am not talking about the cost of editing, creating transcripts, etc. I am only concerned about the cost of the infrastructure to allow people to run public hangout sessions, and the cost of recording those sessions and posting a raw recording (in MP3 or Ogg Vorbis format) on the internet for the people we weren't able to attend live. The cost of running a conversion from wav to mp3 or ogg is virtually nothing. The cost of upload and hosting is incredibly small these days. Mumble has functionality to record the wav file already in there. Anyone attending the hangout can do the recording, conversion, and uploading (they may just need a lesson on how to do it). The only significant cost is the cost of actually running the Mumble servers. How much do the servers cost? I doubt people aren't willing to fund delegates to pay for that (your 100% pay fuzzy.beyondbitcoin delegate is already elected after all).

Now all the other costs (your time as moderator, editing, etc.) are costs that can be covered through other means that you are attempting to develop (if the BTS community for some reason doesn't think it is worth covering those costs with delegate pay). But I don't think those costs should be paid for by attempting to hold the raw recording hostage. These are value added services on top of the raw recording. So the final edited audio is what you should be attempting to monetize (say through ads, or exclusive early access of the edited audio / convenient transcripts to UIA holders before it is eventually released to the public to maximize exposure to BitShares). 

arhag, I have developed a potential solution to yield and other issues, which I hope you will see in the next few days. So I hope you don't mind if I hang off from responding to your suggestions on yield harvest right now, as I still need time to complete this work.

Looking forward to it. 

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).

Very nice.

So I assume that if one UIA is trading against another UIA, and both have fees, that each one will be charged the appropriate fee prior to being sent to the appropriate party?

And I can imagine that we will see delegates able to specify a similar fee for trading the core asset (BTS or DVS) that can be collected in a similar way as all the other fees? And also a similar thing with private BitAssets which could be collected by the decentralized group that is responsible for making sure the BitAsset works: ensuring appropriate price feeds are available (and paying the price feed providers as necessary), being ready to vote to trigger a forced settlement if the longs are being unfair to the shorts, and perhaps even marketing the BitAsset and running market maker bots.

What would be even cooler is if the manager of the UIAs or private BitAssets was able to specify some conversion rate between the asset and the core asset of the blockchain to pay for transaction fees. For example, a UIA manager could have a pool of BTS from which to pay its users' transaction fees. The UIA manager chooses some (dynamic) UIA/BTS price p for transaction fees. If the user elects to pay the transaction fee with the UIA (also they could put a maximum bound on the UIA amount they are willing to pay as a fee to protect them from malicious managers), the blockchain will multiply the BTS fee the transaction fee f needs to pay (e.g. f = 0.5 BTS) with the price p to get the UIA fee it deducts from the user f*p. It then deposits f*p into the manager's fee pool which it can later collect and automatically deducts f from the UIA manager's BTS pool to collect into the BTS fees to later pay the delegates (or burn). All of this would of course also apply not only to UIA managers but also the decentralized group controlling private BitAssets.

Wait how do you prevent shorts to cover with owned (already) bitAsset. By completely removing such operation?

Well they can still cover with already owned BitAssets, but then they wouldn't really be short. I am assuming they don't own enough of the BitAsset to cover their existing short (so that they profit from BTS price increases). Then to rollover they would need to use their spare BTS to buy BitUSD to cover the existing short and to buy into their new short order. However these BitUSD buy orders would first match with the activated redeem orders (if any exist) before matching with any other sell (or short) orders.

Can you summarize for the less smart of us what your model achieves and or how it differs from the original proposal 3.0?

Mostly the same objectives as the ones listed in bytemaster's post. I have added some detail for a possible implementation. However there are a few notable differences.

First, I reintroduce a grace period where the shorts cannot be called. This is similar to our current system of expiration. I'm thinking it would be useful for shorts to have 2 weeks where they do not have to worry about being forced out of their position (assuming they maintain enough collateral to not get margin called). It is only after that grace period that they need to worry about their ranking in the regular call queue and keep track of any pending unactivated redeem orders they may potentially force call their short position in a day or two.

Since, the activated redeem queues have priority over any other order (especially shorts), there is no way for the existing shorts to roll over to a new short without first satisfying the activated redeem order. So it may, in the worst case, delay settlement of the redeem order from 2 days to 2 weeks, but I think that isn't a big deal for the long. I for one would find a 2 week grace period incredibly useful since I have often "purchased" BTS at (what I thought was) a nice price (via short) and then took my time to settle the payment with new BitUSD purchased using new Bitcoin (and that has delays associated with ACH transfers if you don't already have fiat stored with a Bitcoin exchange).

There are two other major differences that have to do with collateral requirements and margin calls. I would not force any particular initial collateral ratio, such as 200%. Instead the margin call ratio limit would be defined as part of the BitAsset (and if we have "privatized" BitAssets then each creator can specify their own), and the blockchain only requires the initial collateral ratio to not be less than the margin call ratio limit defined for the BitAsset. Other than that restriction, the short seller has freedom to specify the initial collateral ratio depending on how much margin call risk they are willing to tolerate. Also, even when a short position is margin called, it does not automatically buy up BitUSD up to a price of 10% above the feed price in my proposed tweaks. Instead the price limit it is willing to cover at grows monotonically from the feed price all the way to 20% above the feed price as the collateral ratio continues to drop lower and closer to 100%.

The system would automatically liquidate my position if it fell below a certain level where I wouldn't be able to pay my lender back. It is what Bitfinex does.

Right, that is the margin trading that you are asking for. I agree we should have that. It is (almost) as simple as taking the current BitAsset system, tweaking the margin limit from its current 200% (actually I think it is still technically 150%) to any percentage greater than 100% defined by the BitAsset creator, not putting any initial collateral requirements on shorting BitAssets, and instead of having the short expire 30 days after it is created, all shorts and corresponding BitAssets created between time (T0 + k*T) and time (T0 + (k+1)*T) should expire at time (T0 + (k+1)*T) for all non-negative integers k, where T0 is the time the BitAsset was created and T is parameter defined by the BitAsset creator at the time the BitAsset is created.

But in that case you wouldn't "borrow BitUSD with BitUSD as collateral", you would borrow one asset type with another asset type as collateral. For example, you borrow BitUSD with BTS as collateral. It wouldn't make sense to borrow asset A with asset A as collateral. Since the collateral amount would have to be greater than the debt (otherwise it would automatically be margin called and liquidated) it means the person putting up the collateral already has enough of the asset borrowed to not need to borrow it. And since they are the same asset, the collateral provider doesn't get to potentially profit from any price changes like they could if the asset borrowed was different than the collateral asset.