Token Multisignature Support

[CriesofCarrots]

Downstream users would like to be able to ultilize multisignature on Token Accounts. A Multisig program would be an option down the road, when cross-program invocations are enabled.
In the meantime, the shortest path seems to be to add M-of-N multisig support in Token.

Instead of just one account owner, enable configuration of each Token account to have N authorities (1 <= N <= 11) and M required signers for transfers and updates to authorities and num-required-signers.

[jackcmay]

@mvines @CriesofCarrots
Rather than bloat the existing token State accounts with M Pubkeys, how about a new MultiSig account that contains a list of M signers? When doing an existing token operation, check to see if the "owner" account is a MultiSig account and if so, validate the instruction's signers against the list of Pubkeys in the MultiSig account.
Checking for MultiSig would entail checking the "owner" account:

• is owned by the token program
• is account data non-zero
• does account data deserialize to a MultiSig

Supporting multi-signature will entail up to M optional signer accounts...

Thoughts?

[CriesofCarrots]

I like it.

Supporting multi-signature will entail up to M optional signer accounts...

So use a byte in the Token account to mark it as supporting multisig?
We also need a byte somewhere to store how many of those stored authorities need to sign a given operation (M).

[mvines]

Currently we use the same account data size (State) for all the token program account types, so the additional M pubkeys in the Multisig account would still bloat up the other two account types. Do we want to move to variable-sized token program accounts instead of the state enum? Otherwise a new Multisig account type seems of limited value in terms of reducing bloat.

[jackcmay]

I was thinking `Multisig` would not be part of `State`, but it's own structure.

…

On Wed, Jul 1, 2020, 8:57 AM Michael Vines ***@***.***> wrote: Currently we use the same account data size (State) for all the token program account types, so the additional M pubkeys in the Multisig account would still bloat up the other two account types. Do we want to move to variable-sized token program accounts instead of the state enum? Otherwise a new Multisig account type seems of limited value in terms of reducing bloat. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJSLY6VANY6GDWMRBS5724TRZNMGTANCNFSM4OC7WGXA> .

[mvines]

We'd differentiate State from Multisig based on account data size? I think that's probably ok (and cheap). We might as well do the same for Mint as well then

[jackcmay]

Mint because its so much smaller than the Account enum variant?

[mvines]

Yeah, the Mint account then doesn't need to pay as much rent as an Account-sized account. But also for consistency with the new Multisig account data