In my recent post I requested help signing some data and provided the following TEAL code sample to use it with:
arg_0 // data
arg_1 // signature
TMPL_PUBKEY_MULTISIG_ACCOUNT
ed25519verify
Looking more closely at the documentation for ed25519verify I’m realizing this op_code evaluates the 64-byte signature s for a single pub_key pk. I believe a new op_code may be required to evaluate a multisig signature msig comprised of subsigs, threshold, version. Therefore the TEAL code may resemble:
arg_0 // data
arg_1 // msig
TMPL_PUBKEY_MULTISIG_ACCOUNT
ed25519verify_msig
However, I’m concerned the above would not be possible because arg_0 msig would be greater than 64-bytes, the stack size limitation. Perhaps it would be possible to supply the msig components as arguments:
arg_0 // data
arg_1 // msig version (e.g. 1)
arg_2 // msig threshold (e.g. 2)
arg_3 // msig signatures_supplied (e.g. 2)
arg_4 // msig pk_1
arg_5 // msig s_1
arg_6 // msig pk_2
arg_7 // msig s_1
TMPL_PUBKEY_MULTISIG_ACCOUNT
ed25519verify_msig
This may allow a new ed25519verify_msig to load the required bits for evaluation.
If this seems plausible, I can open a feature request on GitHub. If I’ve missed something obvious and existing tooling exists to perform msig verification, please guide me to an example/documentation.
What do you think of How To: Sign Data Using Multisig ?
I am curious: which limitation prevents you to have arguments larger than 64 bytes?
Regarding your proposal, it may be difficult for ed25519verify_msig to know how many elements to read from the stack.
@fabrice I do like your proposed solution in the other thread to evaluate the msig components separately within the TEAL code, add the results, define the threshold and evaluate if greater than or equal. I’m still testing it.
Check the OP above for a link to “the stack” which indicates the 64-byte limitation for the stack and scratch space. I’ve never tried sending anything larger to test, having read the docs. However, even if the stack could handle a full msig, a new op_code would be needed to parse the variable length components.
Very true on your point about my proposed ed25519verify_msig not knowing how many elements to pop from the stack. I had envisioned:
arg_3 // msig signatures_supplied
But, that’s too late. ed25519verify_msig must know when called. Therefore, something closer to:
arg_0 // data
arg_1 // msig pk_1
arg_2 // msig s_1
arg_3 // msig pk_2
arg_4 // msig s_1
TMPL_PUBKEY_MULTISIG_ACCOUNT
ed25519verify_msig 2 2 1 // sigs threshold version
This would require ed25519verify_msig to implement accepting exactly three variables for the number of signatures supplied, the msig threshold and the version. In the example above, it would pop 5 elements. It would also pop 5 using your 2:3 example.