Upgrade bank/Send to handle IBC transactions

[robert-zaremba]

Currently, the IBC transaction is not user friendly:

1. User has to know the channel ID.
2. Tooling is poor. Kepler has a button for doing "IBC transfer"
3. I failed to find a tutorial for doing IBC using CLI.
   NOTE: after asking around I was pointed to the ts-relayer readme with an example:

wasmd tx ibc-transfer transfer transfer <channel-id> $(iris keys show -a receiver) 200usponge --from $(wasmd keys show -a sender) --node http://rpc.oysternet.cosmwasm.com:80 --chain-id oysternet-1 --fees 2000usponge --packet-timeout-height 0-0

EDIT: later, I was pointed to this tutorial as well: https://hermes.informal.systems/tutorials/local-chains/relay-paths/multiple-paths.html

At the same time, all tools / wallets support bank/Send messages. Any more tech heavy users are well familiar CLI bank/Send.

Proposal

Last week I had a chat with @sunnya97 and he mentioned that they are looking for a ways to make it easier for users to get on IBC and jump to Osmosis.

Basically, we can utilize bank/Send to interpret the bech32 prefixes and do the IBC transaction.

Currently the types.AccAddressFromBech32 function only accepts the app with only one (chain level) bech32 address prefix (it fails if the prefix is different). We could extend that functionality by:

1. having a mapping between bech32 adress prefixes and IBC channels. That mapping can be controlled by x/bank gov param (new params design).
2. Adding new function: IBCAccAddressFromBech32 which will return IBC channel ID, address (and error).
3. Update bank/Send to accept IBC transfers (this can be either enabled always if IBC is active or using a switch controlled by x/gov or module constructor param).

To discuss

1. Is mapping a good idea?
2. Handling conflicting prefixes? I think x/gov should work well here by either not accepting weird / susceptible addresses.
3. Any integration with CNS (chain name service)?

[alexanderbez]

I love the proposal and steps 1-2 make sense, but (3) isn't clear. AFAIU, what we're aiming to do is automatically do the IBC packet submission. I do not think x/bank would have to be modified? In other words, ICS-20 would be modified to see if the receiver is a non-native address and if so, try to find the mapping and automatically do the additional IBC hop for that recipient.

[sunnya97]

The goal is that we want to make it so any existing wallet or integrator that already knows how to make Send txs, can also make IBC txs by default.

They don't have to learn how to make a new tx type or anything

[alexanderbez]

Right, but you could implement this both on-chain and off-chain. Which are you proposing? e.g. client/wallets could also do this.

[sunnya97]

I'm proposing doing this on-chain so it minimizes the work that client integrators have to do (especially already existing ones)

[alexanderbez]

ACK 👍

[robert-zaremba]

doing it on chain = solve the pain for all tools (unless there is some roadblock, or unwanted performance / technical penalty).

[sunnya97]

+1 to this idea (obv)

SatoshiLab’s SLIP repo (which contains the official mapping for BIP44 paths) also has a SLIP-173 registry for bech32 prefixes of chains

We should use that as a reference standardization mechanism.

Turns out, currently only a few Cosmos chains registered their prefixes. I made a PR adding the bech32 prefixes for as many of the Cosmos chains I could think of (sorry if I forgot yours)

satoshilabs/slips#1149

[sunnya97]

Surprisingly, from what I could find, only 1 chain reuses the cosmos prefix, Likecoin. Are they mainnet yet? Can we ask them to consider changing it?

I was also scared that Starname and Stargaze might re-use the same prefix, but luckily they don't 😄

[robert-zaremba]

thank you for taking care of it!

[jackzampolin]

I think having this information on every chain is highly error prone. The desired UX can be taken care of on the UI layer and doesn't require anything on chain.

[sunnya97]

Mimicking this functionality is a huge burden on every single integrator. Solving once and easily at the state machine level would be a massive UX win, as it by default makes it so any integrator that knows how to "send tokens" can use IBC

[robert-zaremba]

this is a super small information on chain - it will also be handled by a x/gov to avoid spam etc... So only "verified" mapping will be added.

Relaying on tools is less secure, more prone for manipulation, and needs to be repeated by every single tool

[robert-zaremba]

Alternative solution would be to have a registry on something like a Hub.

[anilcse]

This would definitely improve the UX for clients. One question I have is, it's not about single client/channel. There could be multiple IBC channels. Not sure how we gonna chose one automatically for IBC transfers.

If we are planning to use on-chain service, may be CNS could be a solution. But it won't solve the problem I mentioned above.

[robert-zaremba]

Good question. Maybe we can add one more attribute to Send, which is optional (by default the first one will be used).

[aaronc]

Seems like this may be a way to achieve the goals of #9589. This would basically involve each chain setting up its own gov controlled chain name <-> IBC resolver for IID's. Maybe that's a reasonable approach??

[robert-zaremba]

Yes, we need mapping name <-> channel ID. We can't have one "recommended" mapping (eg on Hub), because each chain will have different channel IDs for a given recipient chain.

[sunnya97]

We have an implementation here: https://github.com/osmosis-labs/bech32-ibc