Pass a Public key as argument to TEAL program

AlgoSDK
1

Hi everyone,
i was wondering if it could be possibile to pass a public key in input to a teal program in order to verify a signature. Examples online show only how to verify a signature hardcoding the pk inside the teal program. Any suggestion would be appreciated. Thanks!

PS: i cannot use Sender / Receiver addresses. I want to do something like that:

txn TxID
arg 0                                //this is the signature
arg1                                 //this is the public key
ed25519verify
2

Have you tried passing as a string and using the addr pseudo opcode?
https://developer.algorand.org/docs/features/asc1/sdks/#passing-parameters-using-the-sdks
https://developer.algorand.org/docs/reference/teal/specification/#flow-control

3

i tried but i have to encode the public key string to base64. Inside the TEAL i can encode again the string to base32 but i don’t know how to pass the result to addr after that

4

Welcome @Xeldaine to the Algorand Developer Forum. Please note the TEAL OpCodes reference docs for ed25519verify. Specifically:

  • for (data A, signature B, pubkey C) verify the signature of (“ProgData” || program_hash || data) against the pubkey => {0 or 1}

Your example signature is just the “data” TXID and does not prepend the concatenation of “ProgramData” || program_hash as expected.

5

You can also see an example of the ed25519verify function here: https://developer.algorand.org/articles/algorand-smart-contract-layer1-asc1-and-oracles/#signing-to-verify-with-ed25519verify

6 
To compare two addresses you simply just do this:
arg_0
addr "STF6TH6PKINM4CDIQHNSC7QEA4DM5OJKKSACAPWGTG776NWSQOMAYVGOQE"
==

Where are arg_0 is the address you passed in with b64encoding with goal or as a byte array with the sdks.

7

I tried the comparison encoding my public key using

echo "QRH4X2WEKPIY6KXPPX7J2L7MLQRC57TX37R7YQGX747LUST5QFF56WBD4A" | base64

and passing the result as an argument of a contract transaction with this TEAL:

arg_0
addr QRH4X2WEKPIY6KXPPX7J2L7MLQRC57TX37R7YQGX747LUST5QFF56WBD4A
==

As expected the values were completely different and the transaction was rejected. My aim is not to compare addresses though, but instead to dynamically pass the public key without hardcoding this line
addr QRH4X2WEKPIY6KXPPX7J2L7MLQRC57TX37R7YQGX747LUST5QFF56WBD4A
so that i can verify the signature of an arbitrary number of keys. The problem is that i cannot figure out how to turn arg_0 in a valid format for the addr opcode inside the teal program

8

Reminder: echo appends a new line. So, try:

printf "QRH4X2WEKPIY6KXPPX7J2L7MLQRC57TX37R7YQGX747LUST5QFF56WBD4A" | base64
9

@Xeldaine sorry, the above information is not correct for encoding an account for use as an argument :rage:

Unfortunately, we currently do not have any CLI Tools able to quickly convert the account string to a base64 encoded string (pending feature request). However, we can do it using the Python SDK.

Here is a bash script (requires python3 and py-algorand-sdk) which demonstrates evaluating the addresses:

# assign a funded account as $ACCOUNT_A
ACCOUNT_A="YOURACOUNTGOESHERE"

# Create a TEAL program ($TEMPDIR/addr.teal) comparing arg_0 with $ACCOUNT_A
#pragma version 1
arg_0
addr $ACCOUNT_A
==

# using python SDK, encode the account for use as an argument later
B64_ACCOUNT_A=$(printf $ACCOUNT_A  | python3 -c 'import base64;import sys;from algosdk.encoding import decode_address;\
                                 [print(base64.b64encode(decode_address(line.strip())).decode("utf8")) for line in sys.stdin]')

# sign the TEAL program to create the lsig
${GOAL_CMD} clerk compile $TEMPDIR/addr.teal --outfile $TEMPDIR/addr.lsig --sign --account $ACCOUNT_A

# write unsigned transaction
${GOAL_CMD} clerk send -f $ACCOUNT_A -t $ACCOUNT_B -a 10000 -o $TEMPDIR/addr.utxn 

# sign transaction file
${GOAL_CMD} clerk sign --infile $TEMPDIR/addr.utxn --argb64 $B64_ACCOUNT_A --outfile $TEMPDIR/addr.stxn --logic-sig $TEMPDIR/addr.lsig 

# dryrun
${GOAL_CMD} clerk dryrun --txfile $TEMPDIR/addr.stxn

I’m planning to write an article for release on Wednesday discussing further about using ed25519verify so stay tuned.

10

Thank you for the detailed reply. I will try this solution. A last question: can i achieve the same result using the java SDK? Thanks again.