Even that will fail if the price moves quickly before the hourly feed updates. Moving more than 5% within an hour is hardly unprecedented or even unusual. It's also simply not desired to create more HBD just because the price of HIVE happened to be different over a backward looking period, say from 1-2 days ago. If we had a feed of HBD, then indeed looking at an average price might be helpful, since this would indicate whether the peg had been held and if not, in which direction, but if basing it on the HIVE price, this sort of backward averaging makes no sense.
3.5 days in the future is just a more economically sound method, and the code to implement it already exists. The justification for it is the same in either direction.
I guess the issue is I was assuming that witnesses will publish any adverse price move during the last hour (including at the current time). In such as case, I don't believe it can be gamed.
If they aren't doing that (ie. if they were only posting on some time basis without publishing faster when there is price change of say more than a few percent), using the worst case price in an hour would fail (since we wouldn't really have the worst case price). However, I still don't see how it would be gamed if we are correctly getting the worst case price during the past hour. But if your argument is that we can't count on that happening, that's a different situation.
I think there's a tradeoff here: having the conversion take 3.5 days means it's won't be possible to stop short price rallys in HBD. But instant conversions do increase the possibility of gaming, if witnesses aren't able to provide fast enough price change data.
Another option is to compromise at some intermediate point, for example setting the conversion delay to something like a couple of hours, and keeping the worst case price check during the hour prior to the operation plus some additional small period of time after the conversion to ensure the current price would likely be included in the "worst price during hour" calculation. EDIT: after thinking about it, I guess we can't reasonably use any pricing after the operation is requested, because then that could potentially be used to attack converters.
The 3.5 day method has been proven pretty effective in handling price drops whenever we haven't been close to the haircut being hit.
I don't believe you need the conversion mechanism itself to handle every short term price swing, and if you do, then why are short term increases above the peg more important than decreases below the peg? Short term trading and market making can handle short term swings as long as there isn't a persistent imbalance.
Also, in proposing the 5% spread (which I agree with), you are implicitly designing this to NOT handle short term swings, but instead of address large persistent imbalances. In that case, 3.5 days should work just fine to get the supply moving in the right direction (even if not instantly), as it does on the down side.
Likewise the minimum function in your formula which will penalize (discourage) conversions if the price was lower in the past. This has to be seen as a longer term measure to adjust supply.
This would be a significant change in the existing practice for price feeds and would significantly increase the number of updates required (every time a new low is reached).
Also, no matter how often witnesses update, currently the median is only updates once per hour. That would either need to be changed, or you would need to use individual witness updates rather than the median, which increases vulnerability to deliberate or accidental bad feeds from a witness.
I wasn't aware that the median was only updated once per hour. I definitely don't think we should rely on one witness price. So maybe it is too difficult with the current price feed to reasonably get the worst price in the last hour.
I'm still a little worried about effectively fighting pumps though with a 3.5 day delay in the conversion time. I could easily see converters getting their HBD right about the time the price pump ends.
Maybe we could reduce the delay to something like 8 hours. It's probably sufficient to prevent price gaming, and it would still allow for effective deterrence of the typical price pump.
I don't think it's that big a problem. People who already hold HBD can sell it immediately and initiate a conversion to get it back (with an expected profit) in three days. If there were a lending market, you could even borrow HBD, sell it, and then use the conversion proceeds to pay back the loan (with some risk). If this happens regularly it makes holding even more HBD and waiting for such a pump to be more profitable, meaning more people will do it.
We could also just reduce the 3.5 days in both directions to say 24 hours, or even as you say 8 hours. It's basically the same argument that was made when reducing it from 7 days to 3.5 days: reduced defense against manipulation (which maybe is currently overkill still even at 3.5 days) in exchange for more responsiveness.
But we haven't really had a problem with HBD price dumps (that aren't so large as to involve the haircut) taking 3.5 days to correct. People are pretty willing to tie up capital and take a bit of price risk for 3.5 days. I don't think we necessarily need to go from having no HIVE->HBD conversion mechanism at all to assuming that a slow one won't work. It can only make matters better even if not perfect, and if it turns out not to be sufficient we can do more.
That's an interesting point, but I admit I'm a bit concerned that a lot of that HBD may be held by "uninformed users" that aren't aware of this possibility. Part of that is just that I have absolutely no idea who is really holding most HBD at any given time, since it typically seems to be mostly held on exchanges. And I have the vague feeling that most of these holders don't really track what's happening on Hive.
I guess I'm still in favor of setting the new conversion time lower than the reverse conversion time, and seeing how that goes. Maybe 24 hours would be a good starting point. I also need to doublecheck that adding the delay won't complicate the implementation of the new conversion too much (my guess is that it won't, but best to be sure).
EDIT: as a side note, BitShares used a 24 hour delay for it's conversion time, and it never lead to any problems. Although it's worth noting that it also had a cap on how much could be converted in one day (not that I want to implement that, just trying to mention all pertinent details).
It complicates things slightly to have two different delays, since you would then need two different historical median calculations, although they could work off the same feed history.
24 hours to me seems like it would be fine. I'm not really sure what problem was allegedly solved by changing it from the 24 hours in Bitshares, particularly since as you say there wasn't any.
BTW, on your earlier comment about the pump ending in 3.5 days (or one day or whatever) just as the conversions come through, if that did happen I would consider that a success! The bigger issue we've had is pumps that persist for weeks or months. If we're reduced to worrying about 3.5-day pumps, then we are well on the way to getting the price stabilized.