Token Multisignature Support about solana-program-library HOT 7 CLOSED

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

from solana-program-library.

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

from solana-program-library.

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.

from solana-program-library.

from solana-program-library.

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

from solana-program-library.

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

from solana-program-library.

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

from solana-program-library.