I'm getting pretty bored of continually talking about the fine details of HIVE >> HBD conversions, and I'm sure my readers are much more bored than I am. I'll try to keep this brief.
But I do have some more corrections and revelations to make on this topic.
This may be presumptuous of me to say, but I believe the way that I thought it worked in my previous post is superior in every way to how it actually works as described above...
Indeed it was VERY PRESUMPTUOUS. Durp!
The way it works is fine, which was confirmed when I actually figured out how min(price_median) is calculated. The Hive blockchain aggregates median price once every hour (presumably for efficiency). Given the 3.5 day window it looks at for conversions, that's 84 data points, all median averages from the top 20 consensus witnesses.
min(price_median) is simply the lowest number out of all those 84 averages. To be fair I was told this before, perhaps multiple times over the time I've spent trying to figure this thing out. It just wasn't clicking, but it makes perfect sense to me now.
So the death-spiral scenario I talked about has a way smaller chance of happening than I originally thought. If the price of Hive is crashing, then the blockchain is going to record a new min(price_median) every hour rather than having to wait days for it to move.
While I guess it's possible that some crazy shit happens in between the hourly ticks... it's pretty unlikely that something like that could ever happen non-organically (like a liquidity hack from a centralized agent). In the event that it happened just because a bubble popped (which is most likely)... HBD would break its peg to the downside a little temporarily, which is something this network is more than used to. Buy the dip, as they say.
But what of perspectives?
When I was reading @blocktrades' description about how these conversions work... everything seemed backwards. The logic was backwards. The terms were backwards. The equations presented were backwards. Last night I was thinking about why this would be, and then it hit me.
@blocktrades was not thinking about this topic from a user's perspective. He was thinking about it as though he was the Hive blockchain himself; Putting himself in the blockchain's shoes and working from that vantage point. As a Hive Core dev, that perspective makes a lot of sense. After all, if one is programming the network and tinkering with things, we'd want them to be coming at it this way. Protect the network first and think about the users second. That's the safe way to approach these things, and I think it really shows within the given text.
I find it interesting that there are such massive differences between how I interpret HIVE >> HBD conversions vs the devs who actually built the thing approach it... even though all these interpretations inevitably lead to the same final result.
All roads lead to Rome
In any collateralized loan based system, we tend to think about the collateral first. Not only is this not the case in the above description, but the conversion itself is not even thought of at a loan at all, but rather as a point of sale. The language of the code itself describes it as a trade rather than a loan. While I lean toward this perspective being semantically inaccurate, again it all makes sense why it would happen this way.
Who is @blocktrades? Both a person and a company really. And that company has humble beginnings as a lesser known exchange. All exchanges are basically arbitrage factories, and they allow one asset to be traded for another on the books. It's not a surprise why HIVE >> HBD conversions would be framed in that same narrative.
So while I'm looking for logic that starts with the collateral and moves from there, what I'm given is logic that starts with the loan and works backwards, which I found jarring at first. Honestly looking at it right now it still does not logically flow in muh brain. Thinking about it in way is totally foreign to me considering how much research I've done on collateralized loans, in addition to actually using them.
For me the most logical flow starts with the collateral. We find the value of that collateral, and then draw() a loan from it based on that estimated value. The official description starts with the HBD "purchase" and then calculates a "collateral price" for that HBD, with a "final price" to be calculated 3.5 days later. I find this odd because the user never chooses how much HBD they want to borrow and the network calculates that for them after the fact. It all has a definitively reverse-engineered feeling to it.
From my point of view this "final price" is actually a forced liquidation of collateral, which is very common in both centralized and decentralized margin trading and loan architecture. Again I find it weirdly interesting that my perspective on this topic is basically the polar opposite of the explanation given. No wonder why I had such a hard time understanding it.
Conclusion
Polarized perspectives can surprisingly lead to the same final result.
I'm done talking about conversions for at least 12 months.
No more.