# Understanding ed25519verify Capabilities

**URL:** <https://forum.algorand.co/t/understanding-ed25519verify-capabilities/1336>\
**Category:** General\
**Created:** [January 30, 2020, 7:28pm UTC](https://forum.algorand.co/t/understanding-ed25519verify-capabilities/1336 "2020-01-30T19:28:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ryanRfox](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.algorand.co/ryanrfox/32/364_2.png) [@ryanRfox](https://forum.algorand.co/u/ryanRfox)\
**Post date:** [January 30, 2020, 7:28pm UTC](https://forum.algorand.co/t/understanding-ed25519verify-capabilities/1336/1 "2020-01-30T19:28:34Z")

</div>

In my [recent post](https://forum.algorand.co/t/how-to-sign-data-using-multisig/1335) I requested help signing some data and provided the following TEAL code sample to use it with:

```auto
arg_0 // data
arg_1 // signature
TMPL_PUBKEY_MULTISIG_ACCOUNT
ed25519verify

```

Looking more closely at the [documentation for ed25519verify](https://github.com/algorand/go-algorand/blob/87aecab84df1656972e7485cb1e706417bbb8ac7/data/transactions/logic/doc.go#L128) 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:

```auto
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](https://developer.algorand.org/docs/teal) size limitation. Perhaps it would be possible to supply the _msig_ components as arguments:

```auto
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.

---

<div class="post-metadata">

**Author:** ![fabrice](https://avatars.discourse-cdn.com/v4/letter/f/5fc32e/32.png) [@fabrice](https://forum.algorand.co/u/fabrice)\
**Post date:** [January 30, 2020, 8:34pm UTC](https://forum.algorand.co/t/understanding-ed25519verify-capabilities/1336/2 "2020-01-30T20:34:20Z")

</div>

What do you think of [How To: Sign Data Using Multisig](https://forum.algorand.co/t/how-to-sign-data-using-multisig/1335/2) ?

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.

---

<div class="post-metadata">

**Author:** ![ryanRfox](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.algorand.co/ryanrfox/32/364_2.png) [@ryanRfox](https://forum.algorand.co/u/ryanRfox)\
**Post date:** [January 30, 2020, 9:02pm UTC](https://forum.algorand.co/t/understanding-ed25519verify-capabilities/1336/3 "2020-01-30T21:02:39Z")

</div>

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

```auto
arg_3 // msig signatures_supplied

```

But, that’s too late. _ed25519verify\_msig_ must know when called. Therefore, something closer to:

```auto
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.