REST endpoint migration

[shivlim]

Hi,
I see REST endpoint /txs has been migrated now and replaced by /cosmos/tx/v1beta1/txs
And that needs enoded transaction string using protobuf. Any plans to support this?

https://docs.cosmos.network/master/migrations/rest.html

Thanks

[hukkin]

A PR is welcome! I may not have the time to do the migration in time myself.

[czarcas7ic]

Does anyone have a hacky fix for this? This issue has broke the discord faucet bot I am maintaining and would like to bring it back up someone. Any help would be much appreciated!

[ctrl-Felix]

It's not a small change imo.
it hasn't been migrated to /cosmos/tx/v1beta1/txs. It has more been removed. To quote the cosmos docs:

It is not possible to generate or sign a transaction using REST, only to broadcast one. In order to broadcast a transaction using REST, you will need to generate, sign, and encode the transaction using either the CLI or programmatically with Go.

I feel we will need some bigger changes here.

Broadcasting a transaction using the REST endpoint (served by gRPC-gateway) can be done by sending a POST request as follows, where the txBytes are the protobuf-encoded bytes of a signed transaction:

[hukkin]

Transaction generation and signing is done fully offline by cosmospy already, only broadcasting happens via REST endpoint. So IIUC I don't think the difference is that huge. The new endpoint just probably wants the transaction data in a different format. (I imagine, I still haven't looked into this.)

[ctrl-Felix]

Transaction generation and signing is done fully offline by cosmospy already, only broadcasting happens via REST endpoint. So IIUC I don't think the difference is that huge. The new endpoint just probably wants the transaction data in a different format. (I imagine, I still haven't looked into this.)

No you can't submit it by the rest api anymore. But I think we just can change to the rpc endpoint which is /broadcast_tx_async

The rest stays the same

[hukkin]

No you can't submit it by the rest api anymore.

What makes you think that? There's a mapping from legacy to new REST endpoints here https://docs.cosmos.network/master/migrations/rest.html#migrating-to-new-rest-endpoints. Why would it not be useful?

[czarcas7ic]

@ctrl-Felix I think you are right, but before it gets passed doesn't it have to manually be encoded with protobuf?

[ctrl-Felix]

I tried it @hukkin it's not working

[ctrl-Felix]

Please check #27
Please try it on your setup before

[hukkin]

I tried it @hukkin it's not working

Yeah because the new endpoint wants the transaction in a different format. It won't work without changes to cosmospy. That does not mean that the new endpoint is not working or can not be used.

[ctrl-Felix]

I didn't say that it can't be used and I figured out my first message might be wrong. What I actually tried is the rpc endpoint and it's definetly working

[czarcas7ic]

@ctrl-Felix You said

In fact it's post and working the same way /txs is

If that is true I will be so mad

And also thankful for you teaching me something haha

[ctrl-Felix]

I tried it on chihuahua because I needed it there. I will try it on other chains now

[ctrl-Felix]

Forget what I said. I messed something up. Lol
Sorry guys, I have to work out some things

[czarcas7ic]

No problem, please keep us updated if you can though. This issue has completely shut down our faucet which is not ideal, appreciate the work you are doing!

[ctrl-Felix]

@hukkin I don't know if they didn't update swagger ot if that's the new endpoint. But check out the docs at node.atomscan.com

This endpoint requires following data:
{ "tx_bytes": "string", "mode": "BROADCAST_MODE_UNSPECIFIED" }

[hukkin]

Yeah that's correct. Here's the official swagger btw https://v1.cosmos.network/rpc

We still need to know how "tx_bytes" is encoded and what the possible options for "mode" are.

[czarcas7ic]

@hukkin there is:

BROADCAST_MODE_UNSPECIFIED
BROADCAST_MODE_BLOCK
BROADCAST_MODE_SYNC
BROADCAST_MODE_ASYNC

And tx_bytes is encoded with gogoprotobuf

https://docs.cosmos.network/master/core/encoding.html

[shivlim]

I tried hard to get protobuf bytes but couldnt in python. So i ended up using cosmjs

[hukkin]

We're gonna need to depend on and use https://github.com/protocolbuffers/protobuf I expect.

This also seems relevant https://docs.cosmos.network/master/architecture/adr-020-protobuf-transaction-encoding.html

[ctrl-Felix]

Protobuf docs for python are a pain...

Everything's focussed on go

[ctrl-Felix]

I think I've a fixed version now.
I found the cyberai fork which already implemented all protibufs (https://github.com/SaveTheAles/cyberpy). I basically took that one and adapted it to accept custom coin denoms and prefixes.

[ctrl-Felix]

#28
That's the changes I would propose. Feel free to try it out

[meysamkheyrollah]

anyone got any solution for this problem ??
tnx

[czarcas7ic]

@meysamkheyrollah ctrl-Felix fix worked for me but had to slightly modify it for what I was using it for.

[meysamkheyrollah]

@czarcas7ic tnx

[meysamkheyrollah]

@czarcas7ic is ctrl-Felix solution works in general for sending transactions ??

[ctrl-Felix]

@meysamkheyrollah ctrl-Felix fix worked for me but had to slightly modify it for what I was using it for.

What did you change? Did you use the rpc endpoint?

[hukkin]

I believe this is what they changed #28 (comment)

I think we should make cosmospy agnostic of the endpoint used, and only return the tx_b64 transaction data that both of the endpoints share. And then document the use of both endpoints in README.md using the httpx library.

[ctrl-Felix]

I believe this is what they changed #28 (comment)

I think we should make cosmospy agnostic of the endpoint used, and only return the tx_b64 transaction data that both of the endpoints share. And then document the use of both endpoints in README.md using the httpx library.

Definetly a good idea. I hope to be able to do some further research this week

[mangekyousharingan]

Hey,

As I said before @ctrl-Felix solution works for me and tx is being send, but however when I'm trying to send tx with memo, the memo is not included in tx and then not visible on blockchain. Is there a way to fix it or I am missing somehting?

Appreciate the work here!

[ctrl-Felix]

Hey,

As I said before @ctrl-Felix solution works for me and tx is being send, but however when I'm trying to send tx with memo, the memo is not included in tx and then not visible on blockchain. Is there a way to fix it or I am missing somehting?

Appreciate the work here!

I will add that to the updated version. The current pull request is just a dirty workaround to get it working

[Bha91]

Hey,
As I said before @ctrl-Felix solution works for me and tx is being send, but however when I'm trying to send tx with memo, the memo is not included in tx and then not visible on blockchain. Is there a way to fix it or I am missing somehting?
Appreciate the work here!

I will add that to the updated version. The current pull request is just a dirty workaround to get it working

I am interested in solving this issue quickly, please lead me to how can I help? @hukkin

[hukkin]

@Bha91 This comment #24 (comment) and The PR #28 and the review there should give you lots of pointers. Unfortunately I don't have more time to dedicate to this (unless funded), but will review your PR if you make one.