search

rchain / pyrchain

Python 3 interface to RChain RNode RPC
GNU General Public License v3.0
10 stars 10 forks source link

client.deploy_with_vabn_filled returns depoly_id different than rnode_api #75

Closed w2vy closed 3 years ago

w2vy commented 3 years ago

https://developer.rchain.coop/rnode-api and deploy_with_vabn_filled seem to return deployId in different encoding

They differ in 10 characters

deploy = '9c585205899e989447681ad018e9e4616cc213ca02853130f095e8ad2e553e634166dd7706d87f65d852ecfc07ae39163c18d882864fe9da817d31faaf447e7d1c' deploy = '30440220587de52024402fe97b6437ebf52b6b4dad53ce8bfdc28d2e0fa962a0774360e6022002e42a48ee45063a016553b3fff382c2109302bdbd3fc20194b611cb35b7fa04'

I find it strange

Those deploy IDs are for different deploys, it is just that the length is different, which seems odd

w2vy commented 3 years ago

If I take the shorter deploy ID which was copied out of the http traffic I can fetch the deploy data via both rnode-api /data-at-name and pyrchain client.get_data_at_deploy_id

So maybe the deploy id returned by deploy_with_vabn_filled is not correct

w2vy commented 3 years ago

Looking closer at the signatures, the algorithm used is which when used with bitcoin or etherum expects a 65 byte hex string

In the rnode-api they call it secp256k1:eth and in the pyrchain simply secp256k1, but it is a binary field so may not show a difference

still 65 bytes vs 70 bytes is strange

zsluedem commented 3 years ago

rnode-api follow secp256k1:eth style signature while python use secp256k1 signature. The signature algorithm should be the same.The different point it that the encoding part after signature.

It is normal that these two api generate two different length of signature.

w2vy commented 3 years ago

@zsluedem I tried some simpler contracts and I was able to find my deploy data ok. Sorry I didn't try that sooner. It seems I have some rholang that appears to work via rnode-api that fails via pyrchain I'll close this since the subject is not the issue