Hello everyone !
You might have noticed that witnesses are updating to a new hive version, The witness I co-manage with @fredrikaa, @steempress is already on the new version.
I figured I would walk you through some of the changes that might impact you:
Recurrent transfer RC costs is going up slightly
https://gitlab.syncad.com/hive/hive/-/merge_requests/803
This change is there to better reflect the cost of the operation, the previous implementation did not take into account that you can attach a memo to a recurrent transfer. Realistically the change is minor and you shouldn't see any difference. But for us core devs it's important that everyone pays the correct RC price.
RC delegation now has a minimum of 0.001 HP worth of RC
https://gitlab.syncad.com/hive/hive/-/merge_requests/775 (I did this one ! :D)
After RC delegation was rolled out, we realized that the units were a bit confusing for developers (10 hp worth of rc is many many billions) so we some saw bad delegations come in (user delegate RC and nothing changes because the amount delegated is 1/100th of what is needed for a basic transfer). This was an issue for UX but also a concern for us as it forces the blockchain to store useless data (delegations that have no effect).
So a limit was added so that the minimum you can delegate is 1 HP worth of RC (1/3 the account creation fee). It's going to be a little more annoying for developers because they will have to calculate how much in vests is 1 HP but this was preferred to a hardcoded rules because the vests to hp ratio is constantly changing, see the discussion here: https://gitlab.syncad.com/hive/hive/-/merge_requests/775#note_112710
Note that existing RC delegations are not affected.
Fixed an api issue with the api call list_proposal_votes
https://gitlab.syncad.com/hive/hive/-/merge_requests/773
I wasn't involved in this one but my understanding is that there was an issue where you can list proposal votes and filter by proposal status (removed, expired etc). But that argument was not taken into account. It's now properly managed and filtering works.
Other changes:
Feel free to dig through the rest: https://gitlab.syncad.com/hive/hive/-/releases/v1.27.3
Most of the other changes are either changes in the way the chain works internally so it's not that relevant to users but feel free to dig on it and ask questions in the comment :)
Some corrections/supplements:
Correct link to recurrent transfer RC cost MR 803
Minimum RC delegation is not 0.001 HP but 1/3 of account creation fee, exactly like in case of HP delegations - currently 1 HP.
There was also a potential problem where user could set a lot of RC delegations over long period of time and then make one operation that would force chain to remove them all at once. Since one account can potentially delegate RC to all existing accounts, there was slight possibility that it could be used as attack vector. Setting it up would cost enormous amount of RC and take a lot of time, so it wasn't very serious threat, but better safe than sorry. So now we have a mechanism in place that if such situation happens, the delegations that would need to be removed in one go, are removed in batches in following blocks never taking too much processing time in any single block (by the way, there were already similar solutions for removing proposal votes when proposal is removed or when too many recurrent transfers are scheduled to execute in the same block).
The bug with
list_proposal_voteswas spotted by @asgarth 👍Thanks for the corrections ! I forgot the 1 hp because I spent too much time in the unit tests 😅
Maybe you should activley contribute to the core code :)
New feature idea:
Interest payments for HBD Savings (cold wallet) to be paid out to another account (hot wallet).
REAL REASON FOR THIS FEATURE:
I would like to setup family members as my interest-payment recipients.
That way, if I ever pass away (highly doubtful lol) they'll continue to receive funds forever.
That's a brilliant idea actually..
There are couple problems with it, the most important from my perspective is the fact that it goes against how I want HBD interest payments to be fixed. Current way is unnecessarily bloated and requires users to trigger payments by stirring their savings balance once a month (otherwise the interest won't compound) - from your perspective the key is that you can transfer to someone else's savings triggering interest payment on their account.
I think it should work exactly as vesting. Maybe we could even reuse mechanism of vesting routes that automatically tell where the output of "power down" should go (that would most likely not be necessary). However such change has a serious drawback from the perspective of what you want to achieve. While interest would be accumulating automatically without any user interaction, you'd have to use active key to pay out (even with defined routes), which means when you pass away without giving your family proper keys, they would not have access to the funds.
In conclusion, arrange your last will properly 😉
They(family) would have to trigger my account by sending 0.001 HBD to my savings.
My ACTIVE-KEY shouldn't be required for witnesses to credit them HBD instead of me. The only time I would need it is when I configure who gets the payout, as so:
We currently have two systems of getting interest.
One is from vesting. Aside from individual vest balances on user accounts it requires keeping only one additional global balance. There are no interest payments, only VESTS gain value over time automatically. No user action is required, no extra vops to track changes. Simple and efficient.
Second one is with HBD. Aside from balances it requires keeping two timestamps and a large number that accumulates balance multiplied by time it was held for - separately for each account. It requires users to send transactions in order to trigger interest payment. Such payments also need to have their own vops (extra data in account history), otherwise it would not be possible to track balance changes. Bloated nonsense.
From technical standpoint there is no contest. Vesting is much better :o)
good idea
Perhaps this can be done through automating the manual steps involved in claiming the interest, withdrawing from savings and making a transfer. I think the Hive Keychain team is interested in developing a system for automating all sorts of actions.
Sure, you can automate all of this with a simple script but that would only work as long as your computer is running. I wanted this to be a layer-1 feature so that it runs forever. #SetAndForget
Same here - cool idea
There's another way, which will work for ALL digital assets. It's called Bitwarden. It has an excellent feature (paid version only $10 per year, or even once only) to enable access to all your passwords, keys etc.
Hi @howo , I noticed that you are voting for the non-active/disabled wittnes @stem.witness which is a kind of waste of vote. If you could consider voting for me, I would really appreciate! Thanks! I would in turn vote for yours.
https://vote.hive.uno/@stayoutoftherz
Wen bonds?
Can we get more information on our past trades on the internal market?
Memos, when adding to savings of another account, don't encrypt.
I don't know who to ask about that that can fix it.
~~~ embed:1607495249290567682 twitter metadata:NzQyODc2NTI5NzU2MTEwODQ4fHxodHRwczovL3R3aXR0ZXIuY29tLzc0Mjg3NjUyOTc1NjExMDg0OC9zdGF0dXMvMTYwNzQ5NTI0OTI5MDU2NzY4Mnw= ~~~
The rewards earned on this comment will go directly to the people( @seckorama, @wilsonthe ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.
Thanks for the update!
Is it possible to increase VP voting power or value
I mean if someone have 1000 HP hive Power and its 100% vote value is equal to $0.05, is it possible same user have 1000 HP but we increase its VP or vote value to $0.10 per vote?
Hi, while technically we could it would not be healthy for the chain. The amount of money you get from a vote is directly derived from the inflation (how many tokens are in the reward pool), we could increase the reward pool to give out more value, but that would mean more inflation which would, in turn, decrease the token value (and eventually your vote value would decrease just as much)
Thank you explaining it for me in simple words now I understand it how it worked
But in the future when hive have thousands or may be millions of new users then how we can keep balance between rewards pool and Hive coin value? I mean how this thing works when users increased to 100x from here can we increase rewards pool or keep it same as it today?
In simple words how we adjust inflation when hive have millions of active users?
There will be no need to adjust because if we reach millions of active users the price of hive would probably be much higher, meaning that right now with hive at 0.3$ if your upvote distributes 0.5 hive, it's going to be equal to 0.15$, but if hive is up to 10$, the same upvote will be worth 5$
Congratulations @howo! Your post has been a top performer on the Hive blockchain And you have been rewarded with the following badge
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
Thanks for the updates
Sounds Great. Looking forward to see Good stuff happening on Hive this Year!
Do you know why the blockchain hasn’t updated yet with 19/20 top 20 witnesses running 1.27.3?