HBD->Hive conversion existed before the HF. This conversion is no longer a pegged conversion after the haircut line is reached (in other words, you get less than $1 of Hive for 1 HBD at the haircut

Is it the fact that HBD is limited to 10% of HIVE? Yes, this is the big one. Currently the proposal is to increase it to 30% with the next hard fork, but that's still a very conservative value. Could you

The HBD holder assumes the risk of a peg break in the event of a catastrophic fall in the price of Hive, assuming they don't exit their position before the haircut rule kicks in. But investors in HBD can

Back to the point, the only difference to hive is, that the underlying asset becomes not inflated that much, and the stable coin becomes worthless ( not stable). That's a huge difference. And in the normal

It is completely different from LUNA, it's not a matter of parameters. With a 30% haircut ratio, it is only possible to add 30% to the supply of Hive, no matter what price Hive drops too, because the haircut

The haircut rule is about more than just limiting how much HBD gets created. Even more importantly, it limits how much Hive can be created, regardless of how much HBD exists. With a 30% haircut rate, at

I don't see any real problems with the proposed increase from 10% to 30%. IMO such a ratio isn't particularly dangerous. It also doesn't really discourage me as far as the future prospect of HBD. HBD was

Here's another attempt at describing a death spiral that may help (I just read that one, before reading this one): The good news is, Hive community has long been aware of the potential threat of a death

What you're describing with LUNA is a scenario called a "death-spiral" (term originating from convertible bonds I believe, which can create similar effects on a stock's price). The reason Hive

Right now it takes 15 blocks before transactions in a past block are irreversible (transactions inside can't be canceled even if the computers processing hive transactions have network problems). This

I have some other work I need to do tonight, but I'll think about this proposal tomorrow.

Yes, its true that it makes it "worse" if multiple votes are cast and that was one of the considerations for avoiding it. But it would still take 50% of them doing so to get a 3/4ths majority

That was a pretty good estimate, actually. It's done as a regular transaction (eg. has TAPOS data, etc) and it looks like the transaction will vary between 98 and 115 bytes in size (depending on size of

It is definitely possible, based on things we've done to latency times in the p2p layer. But I suspect there would be a fair amount of work on the blockchain side of the code and it would need further

When we did the initial napkin design, we wanted a protocol that would allow for anything less than 1/2 of the witness to be behaving badly. So, the obvious worst case here would be 1/2 bad witnesses voting

Yes, he's talking about the case of a fork switch. And originally I was also thinking that we had implemented it so that a block producer would cast a new vote for a block during a fork switch (which I

The "force inherent in this protocol" was a broad hint...

I think block producer is a better name than witness, so when discussing the concept in a generic sense (as opposed to one where the duties are specific to block producers on Hive, such as voting for HBD

I wonder what kind of role it plays in your vision of a smart contract platform built on top of HAF. Is it a blocker, or a nice-to-see change? It's not a blocker per se as the smart contract system would

1-Isn't OBI basically what tendermint does? Don't know, haven't read about tendermint, although heard of it in passing. But several of the implementation details of OBI are pretty specific to the way Hive