You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm always frustrated when we can't use proper multisig and contract-based accounts in NeoFS. This severely limits us, we can't have a container owned by a set of keys (hi, neo-project/neo#3463), we can't have users with dynamic keys managed by some contract.
Describe the solution you'd like
Looks like this can be retrofitted into the protocol relatively easily given the current definition of Signature. What we need in its essence is a good old pair of invocation and verification scripts, so the first one could go into key and the second one into sign fields. Then an additional scheme type would allow to distinguish between the two. The main thing is that we can add it without any additional binary fields, just extending the meaning of the old ones.
Then verification would be a standard N3 script run against the current state of the FS chain checking the hash of the payload (network id included).
Describe alternatives you've considered
I don't see a lot of them.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'm always frustrated when we can't use proper multisig and contract-based accounts in NeoFS. This severely limits us, we can't have a container owned by a set of keys (hi, neo-project/neo#3463), we can't have users with dynamic keys managed by some contract.
Describe the solution you'd like
Looks like this can be retrofitted into the protocol relatively easily given the current definition of
Signature
. What we need in its essence is a good old pair of invocation and verification scripts, so the first one could go intokey
and the second one intosign
fields. Then an additionalscheme
type would allow to distinguish between the two. The main thing is that we can add it without any additional binary fields, just extending the meaning of the old ones.Then verification would be a standard N3 script run against the current state of the FS chain checking the hash of the payload (network id included).
Describe alternatives you've considered
I don't see a lot of them.
The text was updated successfully, but these errors were encountered: