#hive

Hive core developer meeting #20

@howo@howo (76)1973d

Timestamps

0:00 - Intro Slide 4:48 - Meeting Starts / Dev Updates 10:45 - Owner's Key Discussion -- Does Key Do Too Much? 12:00 - What about the master password? 14:20 - Account Recovery Settings 15:40 - Beem Mirror 22:40 - Python Unit Tests vs. Node Unit Tests 27:08 - RC Delegations on Hard Fork 25 30:20 - Miscellaneous End Talk

If you're listening to the whole thing, please post timestamps as a comment, the first one to do so (and correctly) will get a 100% upvote from me :)

meeting tl;dr:

Dev sync

as usual it's better to listen to this part

Limiting owner key's role to only changing keys

The owner key can basically do everything, that's a problem because it really only should be used for updating the other keys, we are thinking to drastically reduce it's capabilities in hf26 so that you can only use the owner key/authority to update your keys. It's basically security by design, if you can't use your owner key, there are less chances of you losing your owner key because you entered it on the wrong website.

Then the discussion went on the master password which can be used to derive all the other keys, which is obviously an even bigger security risk. We are thinking of just removing the capacity from libraries to generate keys from a master password so that front ends won't feel enclined to offer a "login with a master password" feature. But there are UX tradeoff where now the user has to juggle with multiple keys, although that's less relevant now that we have great key management systems in place like keychain.

set_reset_account_operation doesn't prevent you from setting yourself as a recovery account

Response from @gtg: "it's a feature not a bug" 😄

basically setting yourself as a recovery disables the recovery (which is intended) and you can't set @null because then witnesses would still be able to recover your account.

beem mirror

@holger80 will be happy, this whole discussion is about how we are mirroring the github beem instead of using our own version. There are still a few things the @blocktrades team need to do but we should soon have a great setup.

python unit tests vs node unit tests

I recommend that you listen to this one, it's hard to summarize (and not that interesting)

Rc delegations on hf25

It's still a question mark whether we include it in hf25 or not. I will test it for a week with others (@good-karma has shown interest). And we will then see if it's stable enough to be included or not.

Support what I'm doing

If you like what I'm doing, please consider voting on my new proposal: https://peakd.com/proposals/167 hivesigner

Comments · 8

@jarvie(75)· 1973d
Yet one more person hoping for RC delegations to be included. I would see to it that Peakd quickly create some UI for that new tool set... I'm hoping even during the testing period.

Maybe we don't NEED rc delegations right this moment or within the next 2 months. But we are very certain we are going to need it before the following HF which sounds like could be 4-6months after this next one which is 1-2? Months away.

We would like to launch or pretty big marketing project we are saving up to do and we think RC pools will be a huge win.

It seems Rc pools helps to avoid the abuse inherent in creating delegation bots that give accounts voting power.

Also can you break down what the proposed changes to the keys may be? I think I get it but want to be clear
@rishi556(72)· 1973d

Limiting owner key's role to only changing keys

What happens to the people who have the same key set for everything? A quick hivesql query(SELECT * FROM Accounts WHERE owner=posting AND owner=active;) shows that there are 18080 accounts like that. A lot of them were threespeak related, and changing the query to skip those(SELECT * FROM Accounts WHERE owner=posting AND owner=active AND owner NOT LIKE '%threespeak%';) still results in 15606 accounts like that. Will they be forced to change their keys? I'm sure that some people are actively doing that to use the same key. Checking accounts created in the last year(SELECT * FROM Accounts WHERE owner=posting AND owner=active AND owner NOT LIKE '%threespeak%' AND created > '2020-04-01';) results in 24 accounts. While thats not a lot(less than 2 per month on average), leaving the option for advanced users(I saw that marky and deathwing made a few of the accounts that have the same keys) to have more control over their keys would be best would it not?
@bashadow(70)· 1973d
Good to hear the dead witness vote is done, still one year later and still finding dead code, you guys certainly had your work cut out for you.

At about 9:50 - The two system approach, c and sql, sounds like a bit of extra work, but also sounds like a good safety approach. It shows how safety is a priority to the folks at blocktrades. Two approaches and find the most effective one to use.

One to two weeks to test and hopefully include the RC work in the code freeze would be great, also good to hear not long before the code freeze and testing to begin for the hard fork, it has been a good year, here's hoping for a solid second year also.

thank you for the post and vid link.
@quixoticflux(65)· 1973d
Timestamps

0:00 - Intro Slide 4:48 - Meeting Starts / Dev Updates 10:45 - Owner's Key Discussion -- Does Key Do Too Much? 12:00 - What about the master password? 14:20 - Account Recovery Settings 15:40 - Beem Mirror 22:40 - Python Unit Tests vs. Node Unit Tests 27:08 - RC Delegations on Hard Fork 25 30:20 - Miscellaneous End Talk
@rabbi711711(58)· 1973d
Nice review
@borislavzlatanov(65)· 1973d
Like others have said, I'm also hoping RC delegations can be included. If it means delaying the hardfork for a couple of weeks so more testing can be done, then no big deal.
@tobetada(77)· 1973d
great suggestions. Hope that RC delegation can bee included!
@bluerobo(70)· 1973d
Getting rid of the master key and limiting the owner key to only key generation is a great idea. It cuts down on key complexity and prevents use of the owner key in everyday use.