About the golang SDK call only contract problem

[Baixin.chain]

I want to use golangsdk to call the domain name transfer through the smart contract. According to the prompt in the document, I also called it according to the corresponding parameters. However, I found that one failed.

Golang SDK code

account, _ := models.SigningKeyHexStringAccount(“d03826de64d010f683b4aee0ac67e074e01725bb6f94c6d26942ab5a5671886a5e88d722246295cefec3143d2cf2212347aac960d0b3ea4abe03fba86ce0dc2e”)
nameHash, _ := binary.Blake2bHash(byte(“888888888888.chain”))
fmt.Println(“Address”, account.Address)
fmt.Println(“nameHash_string_hex”, hex.EncodeToString(nameHash))
signature := account.Sign(byte((account.Address + hex.EncodeToString(nameHash) + “ct_2Fzav4sEVaqS6UZNNkFjVSG29XownExNEjYnqZ1tTpckF2nYBE”)))
fmt.Println(“signature_string_EncodeToString”, hex.EncodeToString(signature))

print

Address ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF
nameHash_string_hex dc06aacb6abbc5a015af8c5f9c3e4a707f4eaf8af3b9e0aaa62e52be50834b45
signature_string_EncodeToString f3bdd3e516a4992313cdbd3e3dc49943e9b1162d38be4e5e0a930810086458c252c55ca931e83340b7ee41d7928c9c4e3020897cdc6e9939c592714161b1820f

Contract code

contract AENSTrans =

stateful entrypoint getBalance() =
Call.caller

stateful entrypoint signedTransfer( new_owner : address, name : string, sign : signature) : unit =
AENS.transfer(Call.caller, new_owner, name, signature = sign)

The parameter is

ak_QyFYYpgJ1vUGk1Lnk8d79WJEVcAtcfuNHqquuP2ADfxsL6yKx,dc06aacb6abbc5a015af8c5f9c3e4a707f4eaf8af3b9e0aaa62e52be50834b45,f3bdd3e516a4992313cdbd3e3dc49943e9b1162d38be4e5e0a930810086458c252c55ca931e83340b7ee41d7928c9c4e3020897cdc6e9939c592714161b1820f

[Baixin.chain]

Is anyone here? This problem has been bothering me for a long time

[hanssv.chain]

I guess name should be a name, like blafoo.chain.

And the signature should be over the binary address, not the base58 encoded version of the address (and the same for contract address). I’m pretty sure []byte((account.Address + hex.EncodeToString(nameHash) + “ct_2Fzav4sEVaqS6UZNNkFjVSG29XownExNEjYnqZ1tTpckF2nYBE” is not 96 bytes as I told you yesterday it should be.

[Baixin.chain]

Thank you. How do I get the binary address from the address
For example: ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF
What should his binary be?

[hanssv.chain]

(aeternity_ct@localhost)48> aeser_api_encoder:safe_decode(account_pubkey, <<"ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF">>).
{ok,<<94,136,215,34,36,98,149,206,254,195,20,61,44,242,
      33,35,71,170,201,96,208,179,234,74,190,3,251,168,
      108,224,220,46>>}
ok

[Baixin.chain]

I found a way to convert the current address to binary in the golang SDK, but I didn’t find out how to convert the contract address, do you know?
The address conversion method is this:
Public: = account. SigningKey. Public ()
The print is the same as yours
[94 136 215 34 36 98 149 206 254 195 20 61 44 242 33 71 170 201 96 208 179 234 74 190 3 251 168 108 224 220 46]

[hanssv.chain]

Well that isn’t a conversion, that is rather not doing the base58check encoding but yes you’ll get the binary address.

No sorry, I know nothing about Go or the Go SDK

[Baixin.chain]

I found the method of golangsdk decoding and got the following results

Address: ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF
[94 136 215 34 36 98 149 206 254 195 20 61 44 242 33 71 170 201 96 208 179 234 74 190 3 251 168 108 224 220 46]

Name: 888888888888. Chain
[220, 170, 203, 106, 187, 197, 160, 21, 175, 140, 95, 156, 62, 74, 127, 78, 175, 138, 243, 185, 224, 170, 166, 46, 82, 190, 80, 131, 75 69]

Ct: ct_2Fzav4sEVaqS6UZNNkFjVSG29XownExNEjYnqZ1tTpckF2nYBE
[165 189, 58, 120, 179, 23, 80, 251, 74, 125, 30, 46, 183, 149, 131, 87, 126, 99, 134, 97, 183, 29, 191, 10, 83, 20, 173, 54, 203]

Combined results:
[94, 136, 215, 34, 36, 149, 206, 254, 195, 61, 242, 33, 35, 170, 201, 96, 208, 179, 234, 74, 190, 251, 168, 224, 46, 220, 203, 106, 187, 197, 160, 21, 175, 127, 78, 175, 138, 243, 185, 224 170 166, 82, 190, 80, 131, 75, 69, 165, 189, 58, 120, 179, 23, 251, 74, 125, 30, 46, 183, 158, 131, 87, 137, 99, 134, 97, 183, 29, 191, 10, 83, 20, 173, 54, 203]

You then get the result of the account.sign () call with the signature

[114 240 132 80 188 1 90 200 181 201 200 238 189 203 200 53 47 202 219 37 122 224 80 9 126 8 65 142 168 0 17 144 100 233 169 191 39 141 141 32 222 100 233 169 42 226 236 19 127 118 59 211 211 38 54 25 91 92 92 245 2]

After hex.EncodeToString:

72f08450bc015ac8b5c9c8eebdcb5dc8352fcadb257ae050097e08418ea800119027478d20de64e9a9bf272294d86a152ae2ec137f763bd32636195b5c5cf502

Name_hash: dc06aacb6abbc5a015af8c5f9c3e4a707f4eaf8af3b9e0aaa62e52be50834b45

Parameters of the calling contract:

ak_QyFYYpgJ1vUGk1Lnk8d79WJEVcAtcfuNHqquuP2ADfxsL6yKx,dc06aacb6abbc5a015af8c5f9c3e4a707f4eaf8af3b9e0aaa62e52be50834b45,72f08450bc015ac8b5c9c8eebdcb5dc8352fcadb257ae050097e08418ea800119027478d20de64e9a9bf272294d86a152ae2ec137f763bd32636195b5c5cf502
Still report the same error:
"Invocation failed: cb_Xfbg4g==. Decoded:]

Is something wrong?

[hanssv.chain]

For the third time… You should not pass the name hash to AENS.transfer you should pass the name, so the second argument should be 888888888.chain. The rest looks plausible.

[Baixin.chain]

ak_QyFYYpgJ1vUGk1Lnk8d79WJEVcAtcfuNHqquuP2ADfxsL6yKx,888888888888.chain,72f08450bc015ac8b5c9c8eebdcb5dc8352fcadb257ae050097e08418ea800119027478d20de64e9a9bf272294d86a152ae2ec137f763bd32636195b5c5cf502

The same parameter I replaced is also an error. I hope the team can have more examples of this kind

[hanssv.chain]

Well, there is crypto involved - it isn’t rocket science, but everything needs to be correct for it to work

So let’s check all the parameters again.

• Call.caller is ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF and this is the current owner of 888888888888.chain
• ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF is [94,136,215,34,36,98,149,206,254,195,20,61,44,242,33,35,71, 170,201,96,208,179,234,74,190,3,251,168,108,224,220,46]
• The name hash of 888888888888.chain is [220,6,170,203,106,187,197,160,21,175,140,95,156,62,74,112, 127,78,175,138,243,185,224,170,166,46,82,190,80,131,75,69] and in hex: #DC06AACB6ABBC5A015AF8C5F9C3E4A707F4EAF8AF3B9E0AAA62E52BE50834B45 (but that shouldn’t be needed anywhere.
• The contract is ct_2Fzav4sEVaqS6UZNNkFjVSG29XownExNEjYnqZ1tTpckF2nYBE, i.e. [165,189,58,120,179,23,80,251,74,125,30,46,183,170,158,149,131,87,137,126,99,134,97,183,29,191,10,83,20,173,54,203]
• So what should be signed is [94,136,215,34,36,98,149,206,254,195,20,61,44,242,33,35,71,170,201,96,208,179,234,74,190,3,251,168,108,224,220,46,220,6,170,203,106,187,197,160,21,175,140,95,156,62,74,112,127,78,175,138,243,185,224,170,166,46,82,190,80,131,75,69,165,189,58,120,179,23,80,251,74,125,30,46,183,170,158,149,131,87,137,126,99,134,97,183,29,191,10,83,20,173,54,203] (96 bytes).
• I don’t have the private key for ak_idkx6m3bgRr7WiKXuB8EBYBoRqVsaSc6qo4dsd23HKgj3qiCF so I can’t test the signing but the result should be 64 bytes and they should be converted to hex.

[Baixin.chain]

Thank you so much for your earnest help. I’ll buy you a drink if I have the chance
This is the private key of the test, which is also 8888888888. The owner of the chain:

d03826de64d010f683b4aee0ac67e074e01725bb6f94c6d26942ab5a5671886a5e88d722246295cefec3143d2cf2212347aac960d0b3ea4abe03fba86ce0dc2e

You can try your signature with this and see if we get the same result

[hanssv.chain]

I think I owe you beer instead, I (again) forgot about the network Id

Since the signature is public it has to be tied to the network (long story, but you shouldn’t be able take a signature from testnet and use it on mainnet - if you are stupid and reuse addresses, etc this could be a real problem), so the material to sign should be prefixed with network name. In this case ae_mainnet - i.e. the thing to sign is really: [97,101,95,109,97,105,110,110,101,116,94,136,215,34,36,98,149,206,254,195,20,...] (106 bytes). (since "ae_mainnet" == [97,101,95,109,97,105,110,110,101,116])

And yes, your signature looks correct… If I add ae_mainnet I get the signature: “209004F79739108CF32A8771853BA127A20A231157021FC22CF0DA2E0446EE7E1A16B43B36DE3BB3B814C64097C307A390231E50976F231C742439D7F9A3750F”

There, really, should be a reminder about this in the Sophia documentation - I’ll try to have that updated as soon as possible.

[hanssv.chain]

Improve docs on signatures

Let’s not forget about it this time - right @marco.chain and @noandrea

[Baixin.chain]

Thank you brother, I have been able to successfully invoke through the contract, but I have faced a new problem. I have posted a new post here, if possible, I hope you can have a look

The problem of who owns a domain name

Hi brothers I am currently in aens transfer through intelligent contract, now can be successful transfer, but found that after I transfer aens, I don’t know whether or not and confirm that the domain name to a new account, I also query node API, but could not find, if through the middleware data query data is wrong. How can I confirm a domain name on the ownership of the person who is he? If you want to solve this problem, do you want to open up more name apis for nodes?