-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create 20231005-Adding-bluesign-as-multi-sig.md #209
Conversation
As asked on the previous FLIP PR, #207 (comment), the FLIP still doesn't explain what the "multi-signatory process on the Flow blockchain" is and what the role of a signer entails. |
Co-authored-by: Bastian Müller <[email protected]>
Changing the format of the table and adding background on the multi-sig process
Added background on the multi-sig process |
@bjartek mind reviewing this? |
Updating table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a FLIP? I feel like FLIPs should be reserved for technical changes and we should have some other system for operational changes like this
@joshuahannan It falls under https://github.com/onflow/flips/tree/main/governance, no? What would be different in that other system? |
I guess it kind of does, but it still seems kind of weird to do it in a FLIP, but i guess it is an easy way to track and document it |
I'd highly recommend sharing more details about the current process, before asking to vote on modifying the process. To be able to vote on such a proposal, I want to know what powers are given to signers. The FLIP and the PR onflow/service-account#258 do not provide that information, and I cannot find any other public information about it. |
Adding more to the description of the service accounts + links
Hey I added more details to the FLIP - please review. |
Sure |
@KshitijChaudhary666 You are saying the process is not changed, but isn't this the first time an addition to the signers is done through a FLIP? How did the existing signers get chosen? As before, I'd highly recommend documenting the existing process and status (in detail, outside of the FLIP), before asking the community to add new members, adding to the in-transparent process and situation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not against adding Deniz as a signer, but would like there to be necessary information provided to be able to make such a decision.
Are you looking for information on why we need a new signer (1) or why deniz was suggested (2)? 1: we need more signers since many current signers are not available for signing. They decline the invites. 2: I nominated deniz. |
Hey, here are my thoughts on this - the process for adding new signers has indeed evolved. Initially, the selection of early signers was less formal, mainly based on community involvement and interest. However, our approach is changing to a more robust and decentralized one, also based on community inputs. From now on, new signers will be added based on FLIPs, and these proposals will undergo a review by a sufficient number of current multisigners. Also note that the "removal" of a signer will continue to be a voluntary process and would not require the FLIP route as it should not be for the community to decide if someone no longer wishes to be part of the group. Hope this answers your questions. |
Thank you for adding some context, e.g. by describing the function of a signer, the current situation (existing signers), and the planned/new process of adding signers. That was all initially missing when the FLIP was opened. Like mentioned above, it would be great to have all of this documented, in greater detail. Currently, this is not documented anywhere other than in this FLIP (https://github.com/onflow/flips/pull/209/files#diff-98e3cc4754d94bd5c3b8037732be27eb454a8991a6e9734996667bb9d428114fR21), and it isn't very detailed. For example, how many signers are there in total at the moment? How many signers are there per "organization"? The description lists some names, but it is impossible to determine the impact of adding another signer. This might be clear for existing signers voting on this FLIP, but it isn't for the rest of the community. It seems odd to ask if someone should get elected even though it isn't even public information who is currently elected ... Unrelated to the documentation / process concerns: Are there any concerns with adding more signers and the potential power implications, and e.g. collusion? If the plan is to add more signers, through a simple process like this one, shouldn't the power of a single signer also be reduced? I don't know much about governance, but isn't it possible that signers just propose more signers and by adding 3 more they have significant powers, like minting new tokens? |
Agreed with Bastian that we need to have the service account information and signers better documented somewhere that isn't this FLIP. I'm not that concerned with adding Bluesign as a new signer this particular time though because he is a trusted community member |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q1: No concerns
Q2: Very excited to have @bluesign as a signer :) 🎉
Re: @turbolent and @joshuahannan 's above comments
how many signers are there in total at the moment? How many signers are there per "organization"? The description lists some names, but it is impossible to determine the impact of adding another signer. This might be clear for existing signers voting on this FLIP, but it isn't for the rest of the community.
Agreed with Bastian that we need to have the service account information and signers better documented somewhere that isn't this FLIP.
This post explains the structure of the service account:
https://forum.flow.com/t/flow-service-account-overview-and-explainer/2437
But we could also outline the exact signers on the service account repo:
https://github.com/onflow/service-account/
Would that address your concerns?
Sure. Will pull up this information and make it public in a separate doc. For now, it seems we have consensus on adding bluesign as a multi-signer. Merging this FLIP and requesting @vishalchangrani to officially add bluesign as a service account signatory. Thanks everyone! |
This will be addressed outside of this FLIP
Little ironic now but I raised a lot of concerns on this approx. 2 years ago. Even suggested some alternatives [0]. But it seems it is a bit problematic to organize people to sign something. I share the risk aware point of view too. Hopefully we will have soon service account not needed ( as far as I know it is a temporary measure ) PS: On next GWG meeting maybe we can discuss this a bit |
No description provided.