Here's another method which addresses your concern about not getting the HBD right away and still prevents gaming or undesirable disincentives to convert by using a future price, by combining the conversion mechanism with a short term collateralized loan.
I'll describe it by example (for simplicity of description, the 5% fee is omitted here).
You request to convert 1000 HIVE. The most recent median price is 0.25. This is further divided by the overcollateralization ratio, say 2 (could be 3 or even higher without causing major problems, but I think 2 might be sufficient, especially if the window is reduced to 24 hours). You then receive 125 HBD immediately, as a loan. In addition, a request is made to convert your HIVE into 125 HBD, which will pay back the loan. At the end of the median window (currently 3.5 days, but maybe changed to 24 hours), let's say the median price is now 0.20. Your 125 HBD conversion requires 625 HIVE at that future price, which is kept by the blockchain and the remaining 375 HIVE collateral is returned to you.
There is some risk that if the price of HIVE falls by more than the collateralization ratio (below 0.125 in the above example with a collateralization ratio of 2), there won't be enough HIVE to repay the loan, and the blockchain could suffer a loss. However, I think short duration of the loan combined with the 5% fee is probably enough to make this an acceptable risk.
I like the idea, and it would work well in combination with a 24 hour delay. And, importantly, the mechanics still look fairly simple to implement.
After considering this a bit more, the initial price should use either your method of the minimum of the most recent and median price, or perhaps even better, the minimum of all the prices in the feed history (currently 3.5 days or 24 hours if this were changed).
While temporarily pumping the price doesn't affect the conversion rate in this model, it does reduce the collateral required, increasing the risk of the blockchain taking a loss (which would be a benefit to the converter), so we should defend against that. Using the minimum of the entire feed increases the collateral required when recent price volatility has been higher, which is probably desired.
The converter's "collateral price" in this case is already a 3.5 day median. So it's presumably a reasonable price, unless you're concerned about the price of Hive being persistently pumped over a 3.5 day interval.
At 2x collateral, the converter already has to deal with being exposed to a price 2x his "expected" price (i.e. the median price at the time of the transfer), so it kind of feels like enough risk to me.
And a minimum over a 3.5 day period, or even a 24 hour period could potentially be very low, especially if there was one malicious witness feeding a low price. A single witness could effectively negate use of the conversion mechanism in this case.
My proposal above was the use the most recent price. Using the 3.5 day median isn't great because it may be a lot higher than the current price at the time the conversion is initiated just due to market fluctuations, which may result in very low collateral, even without any manipulation. (This was the motivation for your use of minimum with a recent price; the same logic applies here.)
I meant minimum of the hourly medians, so any individual witness with a bad price would be filtered out. This is already the current mechanism in the code.
If the price has really risen a lot over 1-3.5 days (say 2-3x), then I would say there is enough volatility to be "suspicious" (not suspicious in the sense of manipulation, necessarily, just that it may not last), and not give credit for that new, higher price right away, in terms of collateral required.
Overall I'm not very concerned with requiring more collateral. Locking up HIVE for a short time (1-3.5 days) is a very small cost if there is direct profit to be made from the conversion itself (particularly if the profit is large). Arguably, giving people a reason to hold and lock up more HIVE could even be good, but that's not my primary motivation for suggesting a more conservative collateral calculation in this case.
With a 2x collateral requirement, the risk for too low collateral would require the 3.5 day price to be more than 2x the current price (and the likely price at the time of the conversion). But admittedly crypto prices can be quite volatile.
Ok, minimum of the hourly medians sounds more reasonable, since it shouldn't be subject to manipulation by a single price oracle. Since I've never reviewed this code, I didn't know these were calculated.
I'm still a little concerned about using a single data point over the entire period though, since flash crashes do happen. What about using the min (total period median price, most recent median price)?
Now, this doesn't protect against a trade performed right after the current price has dropped below that value, but neither does using the worst case during the period. There is a fundamental issue because we just don't have the current price to reason about due to the rate at which oracles are feeding in the price. So if we accept that limitation, the only way to mitigate it would be to further increase the collateral ratio (e.g 3x collateral).
Using the minimum of all the history of median prices provides the maximum degree of protection. The most recent median would be included in that history, so if that happened to be the lowest price, it would set the minimum and the collateral required. If another earlier price were lower, collateral required would be higher.
I'm not worried about this resulting in "too much collateral". Let's say the price doubles or even tripled. That multipled by an 2-3x overcollaterallization ratio would require collateral of 4x-9x. I don't see why people wouldn't post that for a short 1-3.5 day conversion period in order to make even a 1-2% profit, and certainly for a larger profit. The cost of posting collateral for a short time which you then get back just isn't that high. For ease of calculation let's say 1% profit, 10x collateral and 1 day of conversion delay. That's 0.1% per day profit on the posted collateral which is 36% per year not even compounded (compounded would be much higher). This is easily enough to motivate people to do it, and is somewhat of a worst case calculation.
You are correct since we don't know the real time price there is still a risk of undercollateralization. We need to set the overcollateralization ratio high enough to provide reasonable protection as you say, and also just accept some risk of loss in exchange for all the fees collected along the way (not necessarily just from that one conversion request; overall the fees may be quite profitable if overvaluation happens regularly).
Also
Not exactly. That would be the risk of the collateral being insufficient to cover the conversion from the start (obviously very bad), but you definitely want some extra collateral, not just barely enough to cover the conversion. The latter still gives the blockchain a good chance of a loss and the converter a good chance of a corresponding gain (if the HIVE price were to drop still more during the conversion process).
One interesting aspect to the delayed mechanism is it sort of gives a useful application for temporary lockup of Hive as per @tarakzp request: it's useful for Hive holders that want to make a profit by participating in support of the HBD peg.
Again, collateral as a staking opportunity isn't a new idea, BitShares had some of this same idea as well, although the implementation here is a bit different (and considerably simpler to implement from a blockchain and UI perspective).