I think it's better to stick with the 3.5-days-in-the-future model that used for the existing HBD->HIVE conversion. This can be implemented using effectively the exact same code as the existing HBD->HIVE conversions, except at the end of the 3.5 day period, instead of dividing the quantity of HBD converted by the median price to calculate the quantity of HIVE delivered, multiply the quantity of HIVE converted by the median price to determine the amount of HBD delivered.
This prevents gaming after a big price change, as well as manipulation, since (setting aside manipulation) no one knows what the price is going to do over the next 3 days. The best estimate is simply the current price.
As proposed, there will be situations when the backward looking average higher than the current price. In fact, if it is >5% higher, then it will make sense to generate new HBD even when HBD is >$1.05. That's not desired.
The 3.5 day forward process like the converting HBD to HIVE, with the 5% spread, is pretty safe and sound IMO.
Also, I think the haircut threshold should be increased, but I guess that is a separate issue.
I added the worst case price in the last hour term in the formula to prevent just this issue.
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).
Also, this is undesirable if the HIVE price was lower in the past, but has risen say in the past day or so, which will regularly happen due to typical price fluctuations. It will discourage creating new HBD even if HBD is overvalued and more is needed, since the minimum will take the lower price, not the current price, and the converter is penalized.
Now in this case, is is clearly no worse than simply not having the function at all (which is where we are now) so in that sense it can't be seen as an objection to the proposal.
But I see see no gain to using this proposed method over inverting the existing conversion mechanism, which has proven to be quite effective (apart from situations where the haircut is hit, which of course is a different issue).
Everything you've said here I generally agree with, but I think you wrote this prior to my last comment, so just to note as per my last comment, the reason I favored this over the 3.5 day delay method is ability to respond quicker to a price pump. But there is definitely the tradeoff that you mention in your first paragraph with the worst-case price in last hour term.
Yeah, I think rather than wondering about different tradeoffs, we should just start with the inverted 3.5 day mechanism. That addresses the fundamental supply imbalance issue. If it then turns out we need something faster to provide more stabilization against short term moves than what people doing short term trading and market making provide, then we can add something else.
Let's start with the proven mechanism and see if it is enough. It think it might be.
(Yes I wrote the above before your last comment.)