I wish I was a witness...
But that's hard to do when I'm not even running a node and have no dapplications to offer the network. Perhaps I'll get my act together one of these days.
In any case, witnesses on Hive can be viewed as our politicians. We are the great nation of Hive, and they secure out great nation and make it a better place to live.
All politicians need a platform...
A set of standards and principals that they stand by that are indicative of the population they represent. Make no mistake, DPOS is a crypto republic. The witnesses represent our interests. We vote them in; we vote them out.
The problem I'm seeing is that we are so new that witnesses don't even have platforms yet. Steemit Inc was pretty much controlling everything development-wise, so there was no need to actually form political parties. All that changes with Hive. There will be many arguments going forward about what direction we should head in, and we no longer have any centralized leadership to bear the burden of that responsibility.
It all falls on the witnesses.
And that's fine;
that's the way it's supposed to be;
that's how republics work.
If I were a witness
Below I will describe the direction I'd like to see the platform go it. If I was a witness, this is the platform I would stand on. I suggest the other witnesses start thinking carefully about the political issues this platform has, and figure out what direction they want this platform to go in. Not having a political platform underneath your feet as a witness makes you look unprepared... although it seems like none of the witnesses do so from a relative perspective they are all currently on even ground.
Issue #1: Destroy the ninjamine.
This became issue #1 just yesterday, when @justineh created a worker proposal granting 500 HBD per day for 60 days ($30000). This would be for executive services rendered for getting us listed on exchanges and the like.
You know, if that $30000 was spread out over a year instead of two months I would of had no problem with it. When people see that number ($30000) that looks like a yearly salary, not something you would get after 2 months. Even $40000 or $50000 for a year would be much more justifiable. Already we are seeing the backlash to this proposal. Judging by the massive support the proposal has, it will be approved and create even more backlash.
Wasn't this supposed to be about the ninjamine?
This is why I wrote this post immediately after Hive was forked into existence:
You see, now that the ninjamine has been funneled into the proposal system, it looks like we stole it. Now that proposals like this are going to get approved, it looks like the Hive elite is funneling the ninjamine into their own pocket without really having done enough work to earn it.
@justineh is asking for more money than pretty much all of the devs are asking at the moment. Who should make more money? Devs or public relations? Or perhaps I'm downplaying the work and it should be considered more of an executive function?
I have to be honest, I'm extremely biased here, as some of the cliques I've been involved with here do not like @justineh, and that's putting it lightly. I don't know her and I've had no interaction with her.
On the other hand, there seems to be a bias in the opposite direction when we look at the core elite group of Hive; they all seem to support her. It stands to reason the proposal will get approved no matter what.
If I thought this problem wasn't going to get worse, I wouldn't even mention it, but it's obvious to me that this problem is going to escalate x100 over time, or at least has the potential to.
Solution: destroy the ninjamine!
Obviously obviously obviously. We need to destroy the ninjamine 100%. Even from a development standpoint, this makes the most sense. Why would we go through the trouble of figuring out how to turn that Hive into HBD when we can just destroy it and create more HBD later with inflation?
I'm not sure how many people know this, but our inflation is not set in stone. We are not Bitcoin. We can do whatever the witnesses agree to do, as should be obvious by now. We could just as easily destroy the ninjamine and bump our inflation rate back up from 8% to 10% and pump that extra 2% into the proposal system. Sorted.
Doing it this way would give us the advantage of making it appear as though we didn't steal anyone's money. We destroyed it (or rather they simply weren't airdropped the coins, and as a temporary measure they were stored in @steem.dao to be dealt with during the next HF). That's the end of that.
Issue #2: one to one witness voting.
Looks like I'm going to order these issues as most contentious to least. Currently we can all vote for 30 witnesses with full power. All of our tokens count for all 30 votes. The second I got to this platform in 2017 I felt that this was wrong and foolish.
I still stand by 1:1 witness voting, no matter how much largely theoretical math that's thrown at me. This is the policy that makes the most logical sense. 1 coin can vote for one witness (not 30). Which coins go to which witnesses is up to the user. End of story.
Not end of story (witness downvotes)
The push/pull of this issue should be made known. The more witnesses that a single coin can vote for, the more likely it is that there are zero bad actors in the top 20. It becomes a polarizing issue. Either they are all solid or they are all sockpuppets, which JSun showed us very clearly.
1:1 witness voting makes is so a very rich person could probably pay for themselves to be a witness (which is why we should probably consider witness downvoting).
However, that same rich person would not be able to elect multiple witnesses, which is clearly the biggest threat. 1:1 witness voting is more secure against complete security failure, while multiple votes defends against a few bad actors ascending the ranks.
Again, I think a policy of 1:1 voting with a 25% downvote pool would be the best of both worlds, and it would mimic how upvoting and downvoting already work when it comes to reward pool distribution, lowering the bar for understanding the platform and improving the UX. In my mind, this is the obvious logical conclusion to the adversity we recently faced.
Issue #3: Stabilizing HBD with DeFi CDP loans.
Now begins my push to show which development paths for the Hive blockchain have the most value. I have many many posts on this issue.
My biggest fear with bringing DeFi to Hive is that the developers of such a thing would get greedy and implement interest rates to funnel money into the platform (or even their own pockets). This would be a huge mistake.
It's very obvious that if a user is collateralizing their own debt by more than 100% they should not be charged an exploitative interest rate. Charging 0% interest secures Hive's race to the bottom and allows us to leech the Maker community into our own. It will also undermine Tron, which is making a similar technology.
I've outlined very clearly that there are only 2 levers that need to be implemented in order to make this thing work:
required_collateral_percent is much more important than
liquidation_percent. It determines how much collateral a CDP can dip down to before it is no longer allowed to create more HBD. I personally would start it out at something very high like 300%-500%.
Hive's debt cap is extremely conservative due to how poorly HBD functions as a stable-coin. MakerDAO has a
liquidation_percent of 150%. This means technically loans must only be over-collateralized by an extra 50% of their face value.
Meanwhile, HBD has a debt cap of 10% of Hive, which means that HBD is collateralized by a MINIMUM of 1000%. This is ridiculous, because even at 1000% collateralization we see that HBD can't maintain the peg. Nobody trusts in its ability to remain stable, and rightfully so.
By implementing CDP DeFi we could greatly raise our debt cap, or better yet eliminate the debt cap completely and let it be determined by the free market (baby steps on this front to make sure we don't wreck the system). Instead of having a hard-capped debt cap (currently 10%) we could employ a dynamic debt cap using governence voting.
Governance voting dynamic debt-cap.
Imagine we remove the 10% hard-cap from Hive. This removes the HBD haircut, which in turn puts our platform at risk if we print too much HBD and it ends up getting burned for Hive.
However, with CDP loans we ensure that too much HBD doesn't get printed in the first place. We'd never be in a situation where HBD is trading for $13, in fact the MakerDAO system shows us that the most extreme ranges fluctuate from $1.05 to $0.95, while the more normal range is around $1.02 to $0.98.
The key to solving this problem lies in the
required_collateral_percent. Imagine our HBD debt percent skyrockets up to something scary like 30% due to free-market demand. We can lower that number simply by voting to increase the
required_collateral_percent. If more Hive is required to generate HBD out of thin air, then less HBD will be generated, thus lowering the supply of HBD and increasing it's value. Locking more coins also increase the core value of Hive, again lowering the debt percent.
We may find that 30% debt is not scary at all, and the free market has dictated that this level is completely stable and healthy for the platform based on the demand for a stable asset. If there are dozens of legitimate businesses on Hive, this could very well be the case.
How would we know if a high debt % is acceptable?
Quite simply, it all comes down to supply and demand. If our debt percentage is high that is risky, but this is only the case when HBD is trading UNDER $1. If our debt percent was 50% but HBD was still trading at $1.05, this would imply that we could allow our debt percent to ascend even higher.
A high debt percent is a good thing.
Having a lot of HBD is an amazing thing for the platform if the demand we've garnered at that level is in fact stable. For one, it increases liquidity.
The more value we keep in our debt (HBD) the less supply Hive has and the more valuable it becomes. With CDP loans, that value becomes magnified because if we have a
required_collateral_percent of something like 300% that means a lot of the HBD out there is being collateralized by triple that value in Hive coins that are frozen into the smart contract.
Like I said before, this is the secondary variable that matters a lot less and is much less prone to argument, as it has much less effect on the network. However, it is still a very important variable.
liquidation_percent (say 125%) puts the burden of risk on the CDP makers of HBD and keeps the price of HBD stable even in the event of a Black Swan event. They are risking getting low bid during such an event for 100% of the collateral, and thereby losing 25% of their funds to the "vulture capitalist" that made the bid and took the risk to buy the bad debt.
A low liquidation percent (say 105%) puts the burden of risk on the stable-coin holders (those who hold HBD). If the liquidation percent is low and a Black Swan event occurs, the price and liquidity of Hive might fall and cause all the remaining bad debt up for auction to become unprofitable. This would leave bad debt on the platform, and the peg to HBD could fall well below $1 until we made a recovery.
As a witness I would be in favor of a low
liquidation_percent because we've already had plenty of experience with the peg dropping (sometimes even as far down as 50 cents). As we've seen time and time again, Black Swan events in crypto are usually met with a strong recovery, so I don't think it would be a big deal to let the price dip once and a while and give users the opportunity to buy back debt cheap and pay off their loans at a discount. It would at least be worth testing out and raising this percent after the fact if it didn't work out via governance voting.
Dichotomy of the system.
Unlike MakerDAO, Hive already has a system of stabilizing HBD. CDP loans would be added on to this system, making it x100 times more stable. However, it's important to note that the combination of the two system will create emergent economic effects that are impossible to occur on other systems that are only collateralized in a single manner.
Imagine HBD dips to 80 cents a coin. Now Hive users have incentive to lock Hive and use CPD loans to create HBD and either hold it or burn it immediately for more Hive. They also have incentive to buy HBD straight up and pay off their current outstanding loans for cheap (but this is also true for other platforms).
What I'm getting at here is that the system becomes immensely more robust.
There is a synergy at play here that can't even be predicted.
The whole is greater than the sum of its parts.
Modifying the peg
Here's something that no one is talking about. What if we were to modify the peg of our stable coin to account for inflation? This would make it even more stable than USD itself. Nothing is stopping us from re-pegging the value of HBD to $1.05-$1.10 and beyond over time. The logistics and economics of this idea are enough to write a complete dissertation on, so I'll table this topic for now.
Why do I personally need DeFi on Hive?
My primary objective is to create games on the Hive blockchain. I believe that burning assets and sending them to @null will be a great way to guarantee in-game assets have value.
If I were to have a game that burned Hive this would not be an ideal situation. What if the value of one Hive coin was $1000 in ten or twenty years? The games I create that require you turn burn 0.001-0.01 coins to generate in-game assets would no longer be viable. There are many many reasons why this network requires a stable asset. I require a stable asset to do these things, and burning the debt of the platform itself makes the most sense.
If we do not enable DeFi CDP loans and I were to make a popular game that burned HBD, guess what would happen? The supply of HBD would run out because our liquidity is razor thin (collateralized 1000%). The value of HBD would spike and the network would have no recourse to print enough to meet demand. We'd see the return of what we saw in 2017; millions of HBD getting printed that aren't going to get liquidated for Hive until the price of Hive has crashed into the dirt and the ratio of HBD to Hive is at a vastly incorrect level.
Just as a reminder
If HBD is $20 a coin and Hive is $10 a coin, millions of HBD are going to get printed out on blog posts because the value of Hive is so high. However, as HBD and Hive crash together, HBD should be getting liquidated for Hive, but isn't because the value is vastly inflated. HBD does not get liquidated until it trades under $1.
So a monster post might pay out 100 Hive and 1000 HBD. The Hive in this case is worth $1000 and the HBD is worth $20,000. If you were to trade the HBD for Hive you'd get $1000, so no one's going to do it. By the time HBD crashes to 99 cents, Hive has also crashed to 99 cents or less, meaning that 1000 HBD that got printed is AUTOMATICALLY going to generate 1000 Hive eventually even though it was only supposed to create 100 Hive. HBD instability tricks the network into printing way way more inflation than it should during the big pumps.
With CDP loans this never happens, as the price of HBD will never go higher than $1.20, and if it does the crash will be swift instead of taking a year. Demand can be instantly met with supply provided by the community.
Well, I've talked about this topic entirely too much.
Onto the next.
Issue #4: Reallocate interest rates to bank accounts.
This one is a no-brainer to anyone who understands the issue. Unfortunately, even the top 20 witnesses apparently do not understand the issue. I find this concerning.
I got into it with @therealwolf the other day on Twitter, which really shows exactly what I'm talking about. I was pretty rude, and I regret that. However, when I'm talking to someone who's greatest contribution to the platform was a bid-bot, I lose a bit of respect.
I explained this issue in detail in November:
We are currently foolishly allocating 15% of our inflation to stake holders. This is absolutely unacceptable. We have bank accounts that are going fully unused because there is no incentive to use them. We have inflation already built in to the network to provide this incentive, yet we are allocating that inflation to the wrong place.
Here's how it works: Hive has a certain amount of yearly inflation (APR). Well, not really. Every certain number of blocks at lower that inflation by 0.1% or whatnot. I'm looking for our current inflation rate on
getDynamicGlobalProperties() but it doesn't appear to be listed there. Seems like it should be but whatever. For the sake of simplicity say the current inflation rate is 7.5%. 15% of that inflation currently goes to stakeholders (huge mistake).
Why is it a huge mistake?
Because 0.15 * 0.075 = 0.01125.
No one cares about the 1% interest rate we are giving to stakeholders. It is meaningless to them and doesn't sway the actions of our users into any kind of meaningful direction. Nobody powers up more Hive because they're going to get an extra 1% APR; They do it for the increased upvotes. That's where the irony kicks in!
Everyone forgets about the multiplier!
That's right! Stake holders get significantly more than APR than what I have outlined. This is due to the fact that not all of the coins on the network are powered up, while all coins on the platform do indeed create inflation.
Yes, I am right (for once).
The multiplier is calculated from the ratio of coins that the interest rate is applied to divided by the total amount of coins.
The current multiplier of stakeholders to total coins is x2.23
351,958,634 / 157,713,249 = 2.23163644...
Using "reverse engineering" we can calculate current inflation
AKA basic algebra.
0.15 * x * 2.23 = 0.0282
x = 0.08430
Therefore our total APR inflation rate sits at 8.43%.
How big does that multiplier get when you allocate it to the bank accounts?
One word: gigantic.
Because we know that when we transfer inflation to the bank accounts, most users will want to keep their coins powered up so they have strong upvotes. With 10% of our inflation going to witnesses, another 10% going to HPS and 15% going to interest rates, that still leaves 65% that is allocated via upvotes (50/50 author/curation).
So what's the multiplier of the bank accounts?
It's variable dependent on how much money is in the bank accounts. If there were 5M coins in the bank accounts, they would have a multiplier of 352M/5M (x70.4!!!). This would give an interest rate of 89% APR! (70.4 * 0.012645)
But we have to assume that an 89% APR on the bank accounts would be way way too much incentive to deposit more coins. So we know for a fact that more than 5M coins are GUARANTEED to stay locked in the bank accounts FOREVER.
How much more?
|Millions of Hive||APR|
Maybe you're thinking these numbers aren't accurate because our inflation is going down over time. Remember that the total number of coins is also going up over time, increasing the multiplier. I'm not going to do that math, but you get the idea. We are leaving free money on the table for absolutely no reason.
Wow wow wow wow wow!!!!!11
Look at those numbers!
It stands to reason that anywhere between 30M and 40M Hive would be GUARANTEED to enter the bank accounts if we implemented this minor change. Where does this Hive come from?
If it comes from the exchanges, our liquidity and supply are lowered and the price goes up. If it comes from the powered up supply, the value of upvotes goes up; this is where the irony comes in.
We are allocating interest rates to the stakeholders to incentivize powering up, but that exact action is causing upvotes to be worth less money, imposing the opposite effect.
If we were to allocate the interest rates to the bank accounts, it's quite possible that our upvote value would increase MORE than the amount of money we lost from the interest rates. Think about that for a second.
More then Possible: Probable.
How much are we making from interest rates again? PeakD says 2.82%. I can believe that. That means only 2.82% of the powered up stake has to exit to the bank accounts for us to break even on the deal as stake holders (assuming the move has no other value to the network; which is obviously false).
2.82% of current powered up stake is 4.44M coins. How many coins did we think were going to enter the bank accounts if we implemented this thing? 40M at least for a passive income of 11%? Is it reasonable to assume that at least 4.44M of those coins would come from powerdowns? Obviously yes.
This is how you seal the deal:
Combining bank account APR with CPD smart contracts.
The problem here is that if 40M coins were to enter the bank accounts and start generating 11% interest, some turd in the punch bowl would come around and do the math and show why that wasn't worth it.
Instead it would be more worth it for one to power up those coins and simply self-upvote themselves with it. However, this leaves one open to being downvoted, and it also locks the coins up for 13 weeks instead of 3 days.
Streamlining the UX:
The way to fix this "problem" is to combine witness issues #3 and #4. Any Hive in the bank accounts receives the interest rate bonus, however, any Hive in the bank accounts also functions as an AUTOMATIC collaterallized CDP.
So the smart contract that creates CPD collateral would simply be combined into the bank accounts. For example, if you had 1000 Hive in the bank accounts (locked for 3 days) that bank account would automatically count as a CPD with collateral inside it and it would also earn interest at the same time. This would streamline the UX and take the complexity of all these new features out of the platform.
Do not reinvent the wheel.
No need to create a separate CPD smart-contract system when we already have bank accounts right there that lock up coins as part of the smart contract anyway. The only thing we would need to change are the rules for unlocking Hive from the bank accounts. If you have outstanding HBD loans and you are trying to withdraw too much Hive (pushing your collateral percentage below
required_collateral_percent) the transaction would be denied by the network and you'd have to buy/destroy HBD to free up some collateral.
Please contact your favorite witnesses.
I didn't even get a response back from @therealwolf on Twitter. I assume it's because I was a dick about it, but this is a serious issue that the witnesses seem to not even understand. I find it very frustrating. We are leaving free money on the table for absolutely no reason. We are hamstringing the value of bank accounts for absolutely no reason. We are lessening the value of upvotes for absolutely no reason.
Let's get this fixed in the next hardhark!
I have to assume that the code to get this done would be extremely trivial compared to other developments (like CPD smart contracts or SMT).
I spoke to this issue very recently. I didn't even know what reset accounts were until a few days ago. If an account goes inactive after 60 days the reset account can change the Owner key of that account to any one they see fit.
This adds a slight attack vector to the network, allowing reset accounts to steal accounts that go inactive. However, there is no reason to not enable this 100% optional feature that is opt-in by design (all reset accounts are @null by default).
By enabling this feature, we could set up services whereby reset accounts are alt accounts that have their owner key posted to the cloud or some other place. The idea here is that security of the alt account goes down, while the accessibility of the alt account goes sky high (can't be destroyed / accessed all around the globe).
If a user was ever to lose the keys to their main account, the alt reset account would be the only means to recover it. This feature would set Hive security above every other network out there, even ones based on Condenser and Graphene.
However, I think we should consider taking this feature even once step further, and allow the users to determine how much time must pass before their account becomes "inactive". For security reasons, there would obviously have to be a minimum (likely 30 days). However, I could see situations where users wouldn't want to be considered inactive for as long as a year or even two. There's no reason Hive can not or should not provide this completely optional opt-in functionality.
Issue #6: Clean up loose ends (SMT/RC pools)
This is a no-brainer and obviously has the support of the vast majority of the network already. We need to finish SMTs, but arguably more so we need to finish RC pools. If another crypto boom happens and we have millions of accounts trying to transact, without RC pools we will be quite lost on that front. I'd like to stop playing this reactionary game of needing to develop these things in the moment and get in front of this one.
Issue #7: Permanent Vesting
This is an issue I have talked about previously. I believe we should add a simple smart contract that allows users to transfer liquid coins to other users, and those coins become powered up PERMANENTLY.
This ensures that coins transferred in this way will never again appear as liquidity on the exchanges. It allows users to host contests and giveaways with the knowledge that the reward will not be dumped. It allows coins to be sold at a discount knowing that they will not be immediately sold at a profit.
I believe that reputation of accounts will be a big thing going forward. With the rise of DeFi and CDP smart contracts, credit scores will eventually be created for the platform. Other forms of reputation will arise as well.
These developments will make it difficult for users to part with their accounts, as the reputations they've amassed over the years may turn out to be more valuable than the coins they hold themselves. Also, locking ones own coins on purpose to their own account permanently would be seen as yet another way to show they support the network, and subsequently another way to gain reputation in said systems.
I've been met with resistance on this idea, and like reset accounts and bank account APR, I'm completely flabbergasted by said resistance I encounter. These are optional features that no one is being forced to use. Adding them to the network simply adds value no matter what. Someone will use them; that usage adds value.
Issue #8: Documentation
Originally this post was going to be another tirade about how poor our documentation is right now. I'm currently in a battle trying to figure out how to calculate
ref_block_prefix in order to sign transactions offline and broadcast them without exposing my keys to the Internet.
I need to find it again, but my last post about this issue even got the attention of Ned and he was commenting on my blog. He spent so much time pushing SMTs and other complex BS that he never got around to cleaning up the code and helping people like me help build here. This is a huge problem that we've had since day one.
We absolutely need to clean up this code, document it better, and have far more resources and tutorials. This is also a no-brainer.
Issue #9: Who's going to do the work?
It's very disappointing to see all the devs who used to work on this stuff start another project. I'm sure OpenSeed and the like will be worth it, but we are constantly spreading our resources here razor thin and not getting enough done.
I have no solutions to this problem, I only note that we clearly need more devs, which goes back to issue #8. Clean, well documented code with tutorials and solid explanations will go a long way.
These nine issues are the current foundation of my political positions on the Hive blockchain. It might not seems like traditional politics, and it isn't. These online governance structures are obviously quite new and fledgling. They will get much more complex when we begin to form physical communities in the real world. Imagine Hive providing things like healthcare or insurance. These issues could escalate quite quickly.
I wish I was a witness.
I wish I had proven myself much more than I have.
I await the day that Hive moons once again and I have the resources to kick my ideas into high gear.