Hive Multisig Continuation Proposal - Decentralization, 2FA, Key granularity and Oboarding

in HiveDevslast year (edited)

Our Hive Multisig proposal just expired and we're proud to have achieved what we set up to do (read more about this below). After discussing with community members and major Hive dApps, we realize that there is still some work to be done, that could make a big difference in the ecosystem.

What is Multisig?

An account set to use multisignature (or multisig) will require one or more signatures to perform a transaction, as opposed to traditional accounts that only require one signature.

I encourage you to read this article to better understand how this works on Hive. It was written for S***m at the time but the principles are the same on Hive.

TL;DR
For owner, active, and posting authorities, instead of having only one key, you can set several, or also set other accounts as having authority. Each of these keys or accounts has an associated weight, and the authority has a threshold. For the transaction to be broadcasted successfully, the combined weights of the keys and accounts used for signing need to reach the threshold.

Example
If your posting authority has 1 key (weight set to 2) and 3 other accounts (all weights set to 1)and its threshold is set to 3, you can either require the three other accounts to sign (1 + 1 + 1 = 3), or sign with your key and one other account (2 + 1 = 3)

Why is this important?

Here are a few use cases of multisig wallets on Hive:

Enhanced security

With a multisig account, even if one of your keys is compromised, your funds are still safu.

2 Factors Authentication (2FA)

One way this could be used on Hive is by creating a 2FA using a desktop and mobile wallet (Keychain for instance ;p). You could sign once with an account present on your computer, and be prompted to sign a second time on your mobile wallet.

Community decisions

Hive is based on communities, and multisig is a very powerful tool for them to make decisions based on consensus.

DHF Proposals

I see two possible applications of multisig linked to the DHF :

  • For "umbrella proposals" that ask for funds in advance (marketing, petty cash, etc.), it could be used to distribute the funds based on consensus.
  • Because we fear abuse, it is currently quite hard for new developers to fund their projects on the DHF, without a reputation to back them up. With multisig, we could assign them reviewers who would unlock the funds upon reaching milestones.

Authority granularity

How to allow someone to vote with your account but not to post?
Give that user an insufficient posting authority, and run a bot to complete the signature only for voting.

What we've achieved so far

We started working on Hive Multisig about a year ago and achieved everything we originally proposed in our first DHF proposal. @krios003 worked on the frontend and @tshiuan worked on the backend, while I managed the project.

Hive Multisig dApp

Our dApp allows users to do everything related to Multisig:

  • Change/Add/Remove keys or accounts authorities
  • Change the authorities weights and threshold
  • Build transactions and start the multisig process
  • Receive multisig signature requests initiated by another user/key
  • Decrypt, sign, and broadcast requested transactions
  • Receive notifications about the multisig transactions status

Backend and infrastructure

Our backend takes care of passing encrypted data to the potential signers, without ever knowing what the transaction is about, for security purposes.
Using WebSockets, potential signers are notified in real-time if they are already online, or at their next connection within the transaction expiration frame.

After a sufficient number of signatures is collected, the last signer broadcasts the transaction.

Other signers are then notified of the result of the transaction.

A video is worth a thousand words
- Confucius

A step-by-step explanation of the process can be found here.

SDK, Documentation, and Dev Support

Although our own dApp works great for punctual usage, if we want to really unleash the potential of multisig in the ecosystem, we need to get other dApps onboard.

For this, we created and published a Software Development Kit (SDK), along with its documentation to make it easy for developers to integrate Hive Multisig in their project.

Repositories

Links

New Proposal

What we want to build

As shown above, the groundwork has been laid and we have a working multisig system already, but there's still work to do for it to have a profound impact on our Hive ecosystem.
What we are proposing here are three different features that improve the security, the onboardability, and the granularity of the system.
On top of this, we also want to work on decentralizing our backend to make it more robust, and support developer integration.

Decentralizing the backend

If we want to have Multisig features used across the ecosystem, we cannot afford to have a single point of failure. That is why we plan to work on having multiple nodes rather than one centralized backend in the future.

Authority granularity

With four different keys (owner, active, posting, memo), the Hive blockchain already has a much better key granularity than most other blockchains.
Multisig allows us to go further and create keys that obey certain rules and share them with others.

Here's an example of a use case:

We regularly run HP delegations giveaways for our Hive Keychain followers on X. I could assign our Community Manager an active key that would only work for delegations, and would be capped to a certain amount / daily amount / monthly amount.

It would work as follows:

  • Assuming that the key threshold is 1 for our active key, an authority of 0.5 would be given to both our Community Manager and an account managing granularity, let's call it @multisig-bot.
  • On the Multisig dApp, the parameters of the CM authorities are selected to only allow delegations, up to 10k HP a month.
  • Each time the CM is using his active authority to sign an operation on our behalf; since he has insufficient authority, the bot will receive a request.
  • The bot checks if the operation is within the authorized scope.
  • If yes, the bot also signs, and the operation is successfully broadcasted. If not, the operation will expire and nothing will happen.

Other use cases could include:

  • Giving curation teams access to your voting rights only, possibly capped to a certain amount of votes per day, and limited to some tags/authors/communities
  • Only authorizing the signature of some types of custom JSON for giving specific access to some game tools
  • The two applications described below
  • Basically any use case you might think of, in which you need to give narrow access to someone else, or to yourself in a specific device

2FA Module

Having multisig means that we can now work on applying 2FA to our keys to add security to our wallets. Here is how this would work:

  • The account active keys are updated to necessitate both signatures from the current active key and @multisig-2fa
  • The 2FA code is created and imported into the user's preferred 2FA App (Authy, Google Authenticator, etc.)
  • When sending a transfer, the 2FA code must be entered
  • If the 2FA code is correct, @multisig-2fa will also sign the transaction and broadcast it, if not, the transaction is canceled

Combining this with the key granularity system described above, we can go even further and only require 2FA in some cases, for example:

  • for transfers, but not for delegations
  • only for transfers that exceed a certain daily limit

Onboarding Module

By using multisig, and a referral generation App, anyone with account creation tickets (or 3 HIVE to spare) could create accounts for people around them, without ever seeing their private keys, and while ensuring that the broadcasted keys have not been tampered with.
This can actually be done without multisig, but the broadcast request can be more efficiently passed to the signer through the Hive Multisig communication layer.

Example:

  • User A has account creation tickets and wants to invite his friend newUser to use Hive
  • User A gives a small weight authority to the referral dApp. That small-weight authority doesn't allow the dApp to do anything by itself, rather it allows it to make signature requests. (On Hive Multisig, only authorized accounts can make such requests)
  • User A generates a referral code in the dApp
  • newUser creates his keys on the dApp and uses the referral code to submit a request for broadcast
  • The dApp approves the referral code, signs the transaction, and passes it to User A
  • User A signs the account creation operation and broadcasts it
  • newUser is now the proud owner of a Hive account

Developer support

We will keep our SDK and documentation up-to-date and support any dApp wishing to integrate Hive Multisig.
We have already been in touch with Peakd, Ecency, SPK Network, Splinterlands, InLeo and OneUp Cartel, to discuss potential integrations. We are happy to discuss it with any other dApp that would like to know more about it. Of course, this will be integrated into Hive Keychain as well to further improve the experience.

Budget

For this proposal, we will continue working with a budget of 230 HBD/day for a year. This will cover the salaries of the two developers (part-time) who have done a great job so far, and the growing infrastructure costs. A small part of the funding will be kept in the savings to cover server costs during a potential funding interruption and after the end of the proposal.

/!\ NOTE: This proposal is totally independent of the Hive Keychain proposal, and the teams will not overlap. I will just put in a few extra hours to manage our devs and support other dApps integrations.

Commitments

  • We commit to keeping all the code produced through this funding opensource (see the list of repositories above).
  • We also commit to writing regular updates to keep the community updated.

What if the proposal doesn't get the funding?

We believe these new features would add value to the ecosystem. If that's not the general consensus though, we will continue hosting and supporting the current features for as long as possible.


Support Hive Multisig Development by voting for this proposal on Hive Keychain, PeakD or HiveSigner.

Sort:  

Multisignature wallets offer a number of advantages, especially in terms of security. Moreover, such wallets are less likely to be hacked. Great proposal and nice detailed discussion . thank you.

You're welcome! Thanks for your support!

Thank you for sharing about hive multisig, it is informative topic.🙋🙋🙋

You're welcome! I think this could open many doors in our ecosystem!

Thank you for the opportunities that you will share to everyone❤️❤️❤️ have a good day🙋🙋

It was very much informative and your efforts on this post is appreciated👍

I would like to have a significant amount of HP to always support the proposals of people who have participated in KeyChain, it is a great tool and essential for people who use Hive on iOS like me. Multisig is following the same path.

Thanks! And don't worry about the HP, they ll accumulate over time ;)

Done!

Thanks for your support!

Only a pleasure to help building hive :)
!BEER

Thanks for your valuable contribution and for making hive a better and more secure place for all of us stoodkev 😍

Thanks, doing our best!

Vote for the proposal, DONE!

Thanks for your support!

Supported!

Thanks!

Thanks for sharing about the multisig system, definitely learn something from this post! 👏

Glad you did!

Hive will surely be a better place for all moving forward with these initiatives!
Thank you again for putting in the hard work 😊

Thanks for your hard work and dedication to the Hive blockchain. Supported!

Thanks for your support!

Ready proposal supported @stoodkev. May the successes continue... ✨

This is well thought out and very detailed. I like the security aspect but I am curious about onboarding new members to Hive. Would it be necessary for new members to do this right away?
I appreciate more security myself though.

Yeah, in that case, since we're using a signed transaction, there's a 10-minute expiration window, so it's more about a use case where you're onboarding people you're currently talking to. There are ways to work around this though.

So, working with them in real-time to help get them on board might work out better?

It is good to have different keys although I do not find it easy to get access to them if needed.
To be honest I never used the memo key. At times it feels to me it is too much.

I also noticed that if (an app) tells you to sign in with the posting key the active is needed after all.

Keeping posting and wallet separated is a good thing. I wonder how many extras are needed. Most users will not understand it just like this article.

It's great to read you are enthusiastic about what you do.
🍀💕

I agree that it can be complex, but the good thing is that it can be implemented at the dApp level, and the end user doesn't really need to understand exactly how it works, it just does.

Thanks for explaining/answering.
💕🍀

@stoodkev
With this a new user could simply install keychain with a referral code (provided to him by an owner of an account creation token) and he could directly start with hive? If this would be possible, you will have my full support

Yep, that's one of the things we want to do =)

That's cool, thanks!

Voted for this proposal.👍 You did every good work 👏! And you explained very well what this budget is needed for!

Thanks for your support!

Multisig 284 supported

Hive Multisig Proposal #284 supported

This is very nice discussion and article you make, I really impressed and this will help to our fellow hivers. You have 💯 support in this Sir.

Voted for the proposal and thanks for the notification 👍

Supported.
Thank you for all you here

Real Question:
Is it going to end with this proposal or you will need few more?

After this one, we'll have developed everything that we need to take advantage of the multisig capabilities of the chain, and it will be fully decentralized, so there will be no reason to make 'few more' after that.

Congratulations @stoodkev! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)

You received more than 84000 HP as payout for your posts, comments and curation.
Your next payout target is 86000 HP.
The unit is Hive Power equivalent because post and comment rewards can be split into HP and HBD

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 STOP

Check out our last posts:

LEO Power Up Day - November 15, 2023

This could allow the disabled account reset feature to be enabled so in the occurrence that an account is hacked the owner can reset the keys.👍👍

This will definitely help with the crime rate of hacking accounts becomes higher.
(Like ma recent list of my metamask wallet)
Especially maybe transfer large amount requires that , 0.001 micro transfers not needed?

Thank you for sharing. Great info!

Hey. I'm late to the party for this post but have added a vote to your already approved proposal. Well done and thank you for all your work on Hive, Happy New Year!

You don't specify the s...t platform so as not to give them additional advertising, or are there other reasons why you shouldn't do it? Perhaps today I made a mistake mentioning them out loud as a negative example.
Thank you for the convenience you have created for our use of the variety of Hive features!

I see you stopped posting... Did you lose interest...???

Not at all, there's been good progress on the 2FA part and I'll be posting about it soon =)

I hope you send me a reminder, because i'm sure to miss it, if you don't...

Hi @stoodkev, Can I ask you for a witness vote please. I am running a witness node, on my private server, hosted here in Adelaide, it would be great to have your support.

First time, hearing about the app. I just join the hive not long ago. Your efforts in sharing this valuable information are commendable! 👍

That's great, and happy to have support from senior ❤️

Wow... I sure wish I had someone like you, up-voting those who leave comments on my Posts...

Hello @stoodkev
How are you :-)

I'd like to ask you about this account - gnericvibes

We have noticed that you have been heavily upvoting it since it showed up 2 weeks ago and the account already reached reputation 60.

Have you maybe onboarded or verified it?

This acount seems to be delegating to 3 accounts that spam plagiarism and AI content.

Screenshot 2024-05-08 at 10.23.40.png

Hi, part of my curation is automated, I'll check this account and will blacklist it if that's the case.
Thanks for notifying me.

OK, thanks a lot.

Hey bro 👋

Let's go! @stoodkev

Such an important step for devs. Thanks for building this!

Voted

The security and collective decision-making of the Hive Multisig community have greatly enhanced. The plan aims to empower developers, improve onboarding, strengthen security with 2FA, and further decentralise the backend. Cast your vote in favour of the ecosystem's further enhancement and incorporation of Hive Multisig capabilities.

Wow such effort into Hive thanks for all you do brother. It's an honor to be friends.. I use the Keychain all day checking values. Especially now that the dip happened I'm checking regularly and I always use the HBD savings feature. So grateful for all the work. Happy to learn about the Multisig brother

Long time, but what is the latest right now?

Howdy.

Information/limitations of a multi-signature accounts is something that has held my interest for a while. For my thinking, it is purpose. A security feature of prevention is how I interpret the advantage offered.

What if I want more from a multi sign system. Is it possible to develop something more detailed/layered.

A multi sign is a great tool. This would not work for the grandiose image I gave. A multi sign system where several people may sign but 75% of the signature must sign for an action to take place. This system is still just as vulnerable when the amount of finance reached could be in the multi millions. No reason not to imagine more.

The internal details are too vast for a comment.
A summary.
The lowest layer makes requests and receives. The lowest layer is physical local group.
All other layers are to ensure abuse is not in play.
Lowest makes a request to the first rung.
The first rung examines the request and gets estimates from local or surrounding local business. The first rung will agree or deny.
With agreement.
The proposed request is sent to layer two. Here verification of value and confirmation of existence. Evaluation of possible returns and/or other advantages both locally and overall. Local advantages or disadvantages over ride all decisions, always in favour of the local people.
This is then forwarded to layer 3. Further verification of all previous effort can be carried out here.

Each layer can not perform its assigned task unless the signatures from all previous layers are present?

I hope that reads in some manner of sense to you. That is the best I have to describe my question.

Have a nice day my friend😘