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