Create 20231005-Adding-bluesign-as-multi-sig.md

[turbolent]

As asked on the previous FLIP PR, https://github.com/onflow/flips/pull/207#issuecomment-1747862178, the FLIP still doesn't explain what the "multi-signatory process on the Flow blockchain" is and what the role of a signer entails.

[KshitijChaudhary666]

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.

Added background on the multi-sig process

[vishalchangrani]

@bjartek mind reviewing this?

[turbolent]

@joshuahannan It falls under https://github.com/onflow/flips/tree/main/governance, no? What would be different in that other system?

[joshuahannan]

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

[turbolent]

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 https://github.com/onflow/service-account/pull/258 do not provide that information, and I cannot find any other public information about it.

[KshitijChaudhary666]

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.

Hey I added more details to the FLIP - please review. Also I'd like to add that we are not "modifying the process" at all - in this FLIP we are only proposing to add a new signatory.

[bjartek]

@bjartek mind reviewing this?

Sure

[turbolent]

@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.

[bjartek]

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.

[KshitijChaudhary666]

@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.

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.

[turbolent]

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?

[joshuahannan]

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

[KshitijChaudhary666]

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?

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!

[bluesign]

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?

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

[0] https://github.com/onflow/service-account/issues/66