-
Notifications
You must be signed in to change notification settings - Fork 218
[Merged by Bors] - vm: multisig template #3429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
main question i have is about the design. why not implement single sig acct as 1-1 and we will just have one type of wallet?
genvm/sdk/multisig/tx.go
Outdated
} | ||
principal := core.ComputePrincipal(template, &payload.Arguments) | ||
|
||
tx := encode(&zero, &principal, &zero, &template, &payload) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the named variable here zero
really doesn't make the encoding sequence more readable.
maybe define one transaction type (0) and two method types (0 and 1).
func init() { | ||
TemplateAddress1[len(TemplateAddress1)-1] = 2 | ||
TemplateAddress2[len(TemplateAddress2)-1] = 3 | ||
TemplateAddress3[len(TemplateAddress3)-1] = 4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these template addresses should really be defined in the same place as with TemplateAddress
.
seem error prone to scatter them in different packages, and duplicate addresses are not checked.
perhaps worth adding a sanity check test too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i test for uniqueness in registry. i don't see any reason to set them in a single place, as long as uniqueness is enforced
if part.Ref >= uint8(len(ms.PublicKeys)) { | ||
return false | ||
} | ||
if i != 0 && part.Ref <= last { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you mean the signatures have to be in increasing order of Ref? why? is it a restriction on ed25519?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the most efficient way to guarantee that they are unique. not related to ed25519
i don't know yet if we will drop singlesig. will do what research will decide |
bors merge |
closes: #3268 depends on: spacemeshos/go-scale#16 vm: changed method signature for Verify from `Verify(ctx Context, raw []byte) bool` to `Verify(ctx Context, raw []byte, dec *scale.Decoder) bool` it simplifies decoding and enables variable sized fields in the signature. multisig: there are 3 multisig (K/N) variants 1/N, 2/N, 3/N N is a number of keys that own multisig, N is limited by 10 and provided when account is spawned. K is a number of signatures required to pass threshold, template can't have less keys than K. multisig relies on canonical ed25519 signatures. K owners needs to sign a hash of the payload. see type definitions in https://github.com/spacemeshos/go-spacemesh/blob/20f5a38aab38daff830b08f611ed5aef2e1bd53d/genvm/templates/multisig/types.go public keys for spawn are encoded as a variable sized collection of 32byte arrays. signature is encoded as a constant sized collection with tuples [(ref uint8, sig [64]byte)]. collection has to be sorted in the ascending order.
Build failed: |
bors merge |
closes: #3268 depends on: spacemeshos/go-scale#16 vm: changed method signature for Verify from `Verify(ctx Context, raw []byte) bool` to `Verify(ctx Context, raw []byte, dec *scale.Decoder) bool` it simplifies decoding and enables variable sized fields in the signature. multisig: there are 3 multisig (K/N) variants 1/N, 2/N, 3/N N is a number of keys that own multisig, N is limited by 10 and provided when account is spawned. K is a number of signatures required to pass threshold, template can't have less keys than K. multisig relies on canonical ed25519 signatures. K owners needs to sign a hash of the payload. see type definitions in https://github.com/spacemeshos/go-spacemesh/blob/20f5a38aab38daff830b08f611ed5aef2e1bd53d/genvm/templates/multisig/types.go public keys for spawn are encoded as a variable sized collection of 32byte arrays. signature is encoded as a constant sized collection with tuples [(ref uint8, sig [64]byte)]. collection has to be sorted in the ascending order.
Pull request successfully merged into develop. Build succeeded: |
closes: #3268
depends on: spacemeshos/go-scale#16
vm:
changed method signature for Verify from
Verify(ctx Context, raw []byte) bool
to
Verify(ctx Context, raw []byte, dec *scale.Decoder) bool
it simplifies decoding and enables variable sized fields in the signature.
multisig:
there are 3 multisig (K/N) variants 1/N, 2/N, 3/N
N is a number of keys that own multisig, N is limited by 10 and provided when account is spawned.
K is a number of signatures required to pass threshold, template can't have less keys than K.
multisig relies on canonical ed25519 signatures. K owners needs to sign a hash of the payload.
see type definitions in https://github.com/spacemeshos/go-spacemesh/blob/20f5a38aab38daff830b08f611ed5aef2e1bd53d/genvm/templates/multisig/types.go
public keys for spawn are encoded as a variable sized collection of 32byte arrays.
signature is encoded as a constant sized collection with tuples [(ref uint8, sig [64]byte)]. collection has to be sorted in the ascending order.