Short meeting this time but a decent amount of updates from @howo and @blocktrades
meeting tl;dr:
Dev sync
Listen to that one
Testnet setup
@gtg is still tweaking the mirror testnet, @imwatsi has a local testnet running for HAF, we are aiming aggressively (read: will probably slip) for end of march for hf26, so we have some time before we can run tests. As soon as the mirror testnet is live I'll create a guide on how to play with rc delegations, meanwhile I'll update the various libraries to work with it.
Transferable claimed account tokens with costs
Some back and forth here, basically blocktrades is against the feature altogether, the idea is that if we make them transferrable at a cost to burn hive, might as well burn hive by creating accounts. Feature is on hold unless the community really pushes to have it.
Additionnal topics here and there.
@arcange wished for a new option when creating accounts to set the recovery account while it's created, I created an issue on gitlab and will tackle it for hf27
Have a nice week :)
I have a question about RC delegation... is there a cooldown period on un-delegation? If so why and how long? If they get used then they get used but if they don't then why should there be a period of time to get them back. FOr an app like peakd we want to delegate to LOTS of users potentially tens of thousands of new users until they establish RC of their own. Being able to adapt quickly to RC needs of lots of users would be very important for us... so i'm pretty worried that it's using the logic of HP delegations which has multiple impacts that make sense for cooldown of the delegation but doesn't feel like RC needs or should have the same thing. So i'm just checking
There is no cooldown per se, but when you undelegate you have to regenerate the rc, which takes about a week, so basically if you delegate 70 rc, and then undelegate then wait one day because that amount would have regenerated, you could redelegate 10 rc the next day. So it's a lot more flexible than hive power delegations in that sense, but there is still some sort of "limitation".
Hahaha If that is not a "cool down" what do we call it a "burn"? So even if the RC never gets used when you want to undelegate it all just disappears without ever being used? If it's not a cool down then what? a "theft"? ... "Price of using the system"
Sounds worse than I expected to be honest... Unless I'm not understanding something correctly.
You could consider it a burn yeah, I understand that it's not good for your use case where you'd want to delegate rc to every user that logs onto peakd and then undelegate after a time, it's important to not give rc back because it opens up a lot of edge cases where an user can trick the system into having more rc than before (the rc system is not that stable, and a rogue witness not having the rc plugin enabled could leverage that, while working on this feature I found a bug that would allow someone to get a lot of rc for free). Additionally giving the rc back opens up an attack where someone can delegate rc to an user, wait for him to have less rc than the delegation and then undelegate, which means it would drain all of the receiver rc (rc is fungible so there isn't a way to tell if rc given is delegated or not).
In regards to it being better or worse than a cooldown, it's better than a cooldown because your rc starts to regenerate immediately as opposed to hive power delegations where you can't do anything with the hive power that you undelegated until the end of the cooldown
Trying to think how we'll phrase it to users who use our site to delegate RC to others
First draft hopefully we can make it much shorter
cc @asgarth
Can you delegate RC that is delegated to you?
No
Also something interesting is that delegating RC requires only posting auth, so I envision a service where you can "lend" your RC, you give give posting auth to that service and it would do rc delegations on your behalf. I know I would be more than happy to lend my rc to help newcomers/dapps like peakd. Realistically a few dolphins or a whale could probably power tens of thousand of users
I have one more question. There is a need for "undelegation" at all?
I mean ..the delegator will start regenerating RC right away, so why "undelegation" is required?
Why cannot we consider the RC as "sent" instead of delegated? At least this will make the whole thing easier to think about.
It's because the RC is not "sent", when you delegate you give max RC and current RC.
Current rc is the rc you use (the actual unit). Max rc is what is used to define up to how much rc you can have and at what rate you regenerate those.
So if I delegate 100 rc to you, you can use those 100 rc (current rc) and then they will also regenerate on your account for as long as you have the delegation on you.
So the delegator won't in fact start regenerating the delegated RC until he undelegates. I don't know if I'm making sense, if not tell me I'll add more examples :)
Make sense. Probably would have been easier to understand (or at least seems easier to me) if the only thing involved was the 'current' one. So you 'gift' RC and soon after that you start regenerating it.
Basically regeneration would only happen on the RC owner account. Never on the account that receive it. Seems easier to understand because no 'undelegate' is required.
Just to confirm what you said. If you delegate 100 RC to me and you undelegate right away (let's say in the next block) will I still be able to use the 100 RC? And you will start regenerating?
so is the idea to account creation not be free? looks like Hiveonboard is not working and looks like powering down. Ecency says my IP is not cool enough (or something like that).
Is the idea every app to find a solution for themselves?
logic tells me we would like more users, but i could be wrong.
You're not wrong, the issue is that having users has a cost, and free accounts goes against of the way of sustainability, if we let everyone have free accounts we'd end up in solana's or eos's shoes where node operators are spending 10k a month on nodes and the blockchain would no longer be sustainable and decentralized
is just an account creating that much strain on the chain? without HP you can do 1-3 transactions a day? (not sure if it is even that).
looking at the registration process yesterday i am sure that at least 80% of people that found Hive one way or another did not make an account only because it is complicated and on top of that we made it more complicated.
I mean i would pay 2$ for creation, but i am here for 4 years. most that have no idea what Hive is will not. and there are probably a number of people that can't even do that (didn't look how the payments are made, for 15 years paypal was not willing to work in my country, crypto should solve that)
is just an account creating that much strain on the chain? without HP you can do 1-3 transactions a day? (not sure if it is even that).
looking at the registration process yesterday i am sure that at least 80% of people that found Hive one way or another did not make an account only because it is complicated and on top of that we made it more complicated.
I mean i would pay 2$ for creation, but i am here for 4 years. most that have no idea what Hive is will not. and there are probably a number of people that can't even do that (didn't look how the payments are made, for 15 years paypal was not willing to work in my country, crypto should solve that)
Tentative march date sounds good, looking forward to the RC changes. While it might be nice for me to transfer my account tokens, I think I understand where blocktrades stands on the issue. The setting recover account idea I think does have some merit to it, this way the account creator has no need to play the part of account recovery also.
Great stuff! I like arcange's idea
wen next HF ? :)
Optimistically end of march
I'll read that as May :P hopefully RC delegations will be lucrative
Really very informative blog and glad that you shared the update on hive dev team activities. We hivers like to be informed what happen inside and out.