Closed CriesofCarrots closed 4 years ago
@mvines @CriesofCarrots
Rather than bloat the existing token State
accounts with M Pubkey
s, 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 Pubkey
s in the MultiSig
account.
Checking for MultiSig
would entail checking the "owner" account:
MultiSig
Supporting multi-signature will entail up to M optional signer accounts...
Thoughts?
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).
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.
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 notifications@github.com 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 https://github.com/solana-labs/solana-program-library/issues/49#issuecomment-652504053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJSLY6VANY6GDWMRBS5724TRZNMGTANCNFSM4OC7WGXA .
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
Mint
because its so much smaller than the Account
enum variant?
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
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.