theta-testnet-001 relayers

[silk totem]

i guess if you previously had shielded assets on that address before the hardfork, this problem happens

[warped holly]

Ah that's also a possibility indeed

[cunning finch]

Same, I'm building the wrapped cli app for more than a week, and can't make them workable. Tried with low intervals of 30, 60, 120s (from latest block height - 1000) in a loop, but no succes on those transfers (shielded to shielded and unshielding)

[median island]

mebe this is the cause

[warped holly]

Yeah those two commands are a problem.

[silk totem]

is the wasm code used to enable shielded rewards available to download and test locally?

[cunning finch]

No 🙃

Well, assuming is a generalized issue most of us have, we will need just to make sure that internal flow is correct to make those transfers (rather than being functional)

[warped holly]

Yknow, the first part, if you're trying to create a shielded swap app there's probably only one way to test the flow now. It's by doing the first ibc transfer as a normal transparent tx to a counterchain. Since transferring from a shielded addr ain't possible atm.

Or does ibc shielded from namada to a counterchain work? Provsbly also gets rejected right?

Talking solely CLI here

[cunning finch]

Ah no, I wouldn't see shielded swap an original one hehe. Csn't say too much, but it will be a shielded action on other chain

[warped holly]

Right, right! Good luck man :)!

It's your final task?

[cunning finch]

I think they don't work? Both shielding and unshielding IBC transfers?

[cunning finch]

Yupp

[warped holly]

Don't think so either

[cunning finch]

So we are making "transparent" actions instead 🤣

[warped holly]

I still need a reanalysis of my submission. Based on the wording of this example:
Create a web application supporting a shielded action on an IBC chain

I believe mine checks out, but I don't know man...

[cunning finch]

Well, as SE isn't being developed anymore, yep, that's the only way

[warped holly]

Yeah it would literally just mean your submission would suffice if you just swapped the transparent first part out for a shielded tx

If you got the whole flow after that correct

[cunning finch]

Your IBC app could serve as a gateway to do shielded actions freely, so it's even more useful than a specific integration, just saying

[warped holly]

Thank you!

I like to keep functionality separate, that way it can work as puzzle pieces.

Though a shielded swap action in particular, would require a set of actions to be done atomically ofc.

😂 I also don't wanna spill too many beans here. I somewhat know what approach to take for that or what's needed.

Though I'm a solidity guy, which I HATE of myself looool

[cunning finch]

It has its difficulty ofc, and those integrations would come and be useful. But hey, all teams, all projects, are gonna integrate it...? Don't think, so a gateway is indeed needed

[warped holly]

Btw isn't the very act of sending to a shielded address already a shielded action? It interacts with the MASP. I only see people talk bout shielded swaps. And I also keep in mind that the subtasks are stated as EXAMPLES.

But I don't know. I only doubt it now cause of all the others who got accepted.

[cunning finch]

A shielded action involves the interaction with an external chain. Although the name of the category breaks the shielded action implication itself. "Shielded Application" could also mean to make available normal shielding transfers. But I would prefer to do whole flow for all type of txsz even though they don't work

[warped holly]

Ah got it! Yeah, hope you get it there man. You got enough time/hands on deck?

[quaint arch]

You should be able to see the tokens listed when you run namadac masp-reward-tokens so something is wrong, probably with the proposal wasm. I can't check logs right now but I wonder if there's anything in there around the start of epoch 79 or 80, like "invalid wasm, skipping" or something along those lines

[warped holly]

Ah, let me try finding that

[cunning finch]

Would we need a db dump I assume?

[cunning finch]

Thanks man! Yeah, it's funny, been hard working whole competition and close to end, moooar hard work 😂

[quaint arch]

Oh yeah good idea

[warped holly]

That final sprint

[cunning finch]

Even tho a wrapped cli isn't that difficult imo

[warped holly]

Hehe now it's just the time pressure mostly, you had to compromise and adapt to this method close to the end...🥵

Actually most who attempt this task

[silk totem]

could you share the proposal wasm source code , so we can get test it locally ?

[warped holly]

I got a bit of difficulty atm to find anything in the logs btw.

[quaint arch]

Certainly, not at my pc right now but I can share it later

[cunning finch]

Can anyone check if we can do a db dump of a specific height? Especially the one that begins an epoch (79 and 80)

Need to get back to keyboard

[ionic ravine]

is shielded rewards necessary to end the competition
Or not needed

[cunning finch]

7 more days? No, please 😭 haha

[turbid remnant]

If I remember correctly it was tested on campfire? Ya

[warped holly]

I'm not sure, but I think I heard them say this wasn't necessary for any ROIDs or whatsoever, so for the competition this isn't needed.

To make sure it does function well? Yeah probably needs to be tested. But can be done afterwards.

[cunning finch]

Really?

It worked there?

[turbid remnant]

I saw some announcement, that spork halt the chain trying to do so

Not sure if he accomplished

#🏕-testnet-campfire message

Here

[warped holly]

Thought that was because of the wasm not being correct and needing adjustments

Aah, you're talking bout the proposal wasm and this having been tested on Campfire?

Think Mandragora means the actual mechanism and if it works. So getting shielded rewards for a specific pair etc.

[turbid remnant]

Oh yeah I was referring to campfire

[warped holly]

Coming back to this for confirmation, my NAAN is still 1021, hasn't gone up or anything.

[turbid remnant]

So probably the channel doesn't work anymore?

[torpid blaze]

I am not being able to pass the memo signature to the keplr extension, do you guys know how do I do that ? when I pass the MEMO parameter, its copying the MEMO to the MEMO field inside the extenison which will originate a "MEMO" inside "TXBODY" object, but I want it to be inside "VALUE" object, filling in the "value" "memo" field
do you guys know what I am missing ?
thanks in advance

[quaint arch]

not needed (thankfully), won't effect the end date

[quaint arch]

yeah it worked on campfire (2nd time)

@silk totem
campfire proposal wasm (worked): https://gist.github.com/iskay/717286300790bf48e025890bb0c08048
shielded-expedition wasm (didn't work): https://gist.github.com/iskay/45792900203decdfaae0a330df47ff1c

only difference between the two should be the channel number and values for some of the constants... (hope it's not something dumb/embarrassing like a typo)

[turbid remnant]

Oh yeah nice to know!!

[silk totem]

ah thanks
I'll try to test it locally

[torpid blaze]

any idea why "memo" value inside message gets ignored by signAndBroadcast on Keplr? even though I have configured the memo for the tx, KEPLR extension is still showing me the memo field as empty not including my memo... thanks guys

do I need to format the memo in any way for it to get aknowledged by the extension ?

[warped holly]

Yeah everything looks the same, except for those constant values and also the implicit "as u64" in the locked_amount value .

Is it correct that on SE it's:

• shielded_locked_amount: 10_000_000_000_000 naan vs 100_000_000_000 atom
• kp_gain_key: 1200 shielded naan vs 120000 shielded atom

While on campfire it's:

• shielded_locked_amount: 10_000_000_000_000 naan vs 1_000_000_000 atom
• kp_gain_key: 120000 shielded naan vs 120000 shielded atom

[warped holly]

There are two different memo fields, in CLI it's called --note and --memo. I'll check just a sec.

[torpid blaze]

I am using the KEPLR web extension with stargateclient

thanks man for your help

[warped holly]

Yes, once it gets to Keplr does it fill out the visible memo, the one you can adjust in the keplr extension itself?

[torpid blaze]

no

[warped holly]

Which one gets filled out? Or neither?

[torpid blaze]

to fill that one in I use this :
const response = await client
.signAndBroadcast(
source,
messages,
fee,
memo // tx memo)

this "memo" will fill that one, the manual one

but I am trying to fill the one inside the "value" object

so I am doing it like this:

const messages = [
{
typeUrl: "/ibc.applications.transfer.v2.MsgTransfer",
value: {
memo: memo, ..... }}]

please ignore that "v2" - I did it for testing purposes xD

so the TX its forming looks like

    "extensionOptions": [],
    "memo": "0203020C02046A457FA003C163DF96B50D3.....",
    "messages": [
      {
        "typeUrl": "/ibc.applications.transfer.v1.MsgTransfer",
        "value": {
          "memo": "",
          "receiver": "....",
          "sender": "....",.....```

so it gets the "memo" on "txBody" , but not the "memo" inside the "value" object

[warped holly]

That looks somewhat correct, not seeing anything different in particular for me:

          address,
          msgs,
          fee,
          memo, // This one should be open for the user to fill in, e.g. their public key
          undefined
        );

Inside msgs you have an array of msg objects of type:

    typeUrl: string;
    value: MsgTransfer;
}```

Inside `value.memo` you need to add ICS20 memo's, so the ibc-gen-shielded for instance.

Wait let me double check.

Yep, that's about right.

[torpid blaze]

yeah so thats pretty much what I am doing

right ?

I can't understand why its ignoring it for me :S

[warped holly]

Yeah, just not understanding why the memo isn't getting inside messages.

[torpid blaze]

yeah same here

[warped holly]

Just a sec, let me console log it.

[torpid blaze]

I've already tried updating keplr extension , that didn't fix it

[warped holly]

What are you trying btw? What type of tx?

[torpid blaze]

osmos > shielded naan

[warped holly]

IbcTransfer?

[torpid blaze]

yeah

[warped holly]

Ah right okay

[torpid blaze]

would it be ok if I PM you about this ?

[warped holly]

I prefer keeping convo's here, my DMs is wild

[torpid blaze]

ahaha I get that no worries at all

just wanted to share the code with you

but I do understand that xD

[warped holly]

Yeah haha, many have been contacting me for getting info XD, but I'm shooting myself in the foot if I go that route.

Not only my feet, others as well

[torpid blaze]

ahaha I do get that man

I am nearly frying my brain with this specific TX to be fair

[warped holly]

So apologies, I think it's the typeUrl btw, but not sure. Double-check if there's an actual value in memo by console.log' as well

[torpid blaze]

there is yes, I have all that console logged xD

[warped holly]

Just a moment btw

[torpid blaze]

{
"typeUrl": "/ibc.applications.transfer.v1.MsgTransfer",
"value": {
"memo": "0203020C02....",
"receiver": "znam1.....",
"sender": "osmo18.....",
"sourceChannel": "channel-....",
"sourcePort": "transfer",
"timeoutTimestamp": {
"low": 2024493056,
"high": 398725064,
"unsigned": false
},
"token": {
"amount": "2",
"denom": "ibc/5872CF7B67F1699BE386B2C577B95C6AC2A268D09FCB345335A875B239EE0174"
}
}
}

I cant paste the whole object for size restritions but thats the message array

that I am passing to signAndBroadcast

like this

        .signAndBroadcast(
          source,
          messages,
          fee,
          "" // tx memo
        )
        .catch((e) => {
          return Promise.reject(e);
        });```

[warped holly]

Okay I'm back, just a sec let me run my stuff

[torpid blaze]

Sure thing man thank you very much for your help once again. But I really feel like I'm missing something as Keplr extension should recognise this memo and show me "forwarding data" before the tx raw data...

[warped holly]

Everything is literally the same for me lol. Except for the timeoutTimestamp, I went the BigNumber route. Uhm, can you omit that field, just to check if it works?

[torpid blaze]

sure thing

testing it now

[warped holly]

It's necessary to have though, but just to get everything similar.

[torpid blaze]

ok done

TX data on KEPLR :

      {
        "typeUrl": "/ibc.applications.transfer.v1.MsgTransfer",
        "value": {
          "memo": "",
          "receiver": "znam1...",
          "sender": "osmo18...", ...```

messages array :

    "typeUrl": "/ibc.applications.transfer.v1.MsgTransfer",
    "value": {
        "receiver": "znam1...",
        "sender": "osmo18...",
        "sourceChannel": "channel-...",
        "sourcePort": "transfer",
        "token": {
            "amount": "1",
            "denom": "ibc/5872CF7B67F1699BE386B2C577B95C6AC2A268D09FCB345335A875B239EE0174"
        }
    }
}```

[warped holly]

Might this be related to being on an older version? Where this memo field isn't properly set yet? You on typescript? You see that it's possible to add memo in the value object right?

[torpid blaze]

yeah, I am on TS

    memo: string | undefined;
    receiver: string;
    sender: string;
    sourceChannel: string;
    sourcePort: string;
    token: {
        amount: string;
        denom: string;
    };
}

I am using the latest master branch on namada-interface

should I be using an older one maybe ?

[warped holly]

Ah, I haven't used anything of the namada-interface, I wouldn't know, I'd have to check it out

[torpid blaze]

oh I see

[warped holly]

(I get overwhelmed if I work from other code haha that's why)

[torpid blaze]

"@cosmjs/stargate": "^0.29.5",

thats the stargate version I am currently using

should be ok I reckon

[warped holly]

I'm on v0.32, it might be the reason tho

Try upgrading and check if it works

[torpid blaze]

oh my that would be so dumb xD

let me try that

[warped holly]

XD hahaha, everything looks the same, I'm not really seeing a mistake on your side

Let me check their github tho

Is this related?
https://github.com/cosmos/cosmjs/issues/1493

[torpid blaze]

looks like it

[warped holly]

I'm always a headless chicken when I need to navigate inside of github pff XD.

I hope updating to a higher version doesn't break a lot though.

I started from scratch so I didn't have to deal with compatibility issues

I have to go afk tho! Good luck man. May the force be with you 🤓

[torpid blaze]

thank you very much man

have a great sunday

[warped holly]

Ty, you too man!

[torpid blaze]

Hey man just to let you know that the update worked. Just by updating thst one package and everything started to working properly. Once again thank you very much for your help man.
Hope you've had a nice Sunday

[warped holly]

Glad to hear man! Thank you man, again have a nice one as well :)!

[warped holly]

Oh you said hope you had a nice day. Man sometimes my eyes...yes, I had a good one man! Thank you, hope yours was good as well yo!

[vernal palm]

hey,friends

I have some questions

root@web3-dev:~/.hermes# hermes health-check
2024-04-08T05:00:27.615063Z INFO ThreadId(01) using default configuration from '/root/.hermes/config.toml'
2024-04-08T05:00:27.615652Z INFO ThreadId(01) running Hermes v1.7.4+38f41c62-dirty

2024-04-08T05:00:31.714405Z WARN ThreadId(15) health_check{chain=theta-testnet-001}: Will use fallback value for max_block_time: 30s. Error: response error: Internal error: genesis response is large, please use the genesis_chunked API instead (code: -32603)

SUCCESS performed health check for all chains in the config
root@web3-dev:~/.hermes# hermes --config $HERMES_CONFIG
create channel
--a-chain shielded-expedition.88f17d1d14
--b-chain theta-testnet-001
--a-port transfer
--b-port transfer
--new-client-connection --yes
2024-04-08T05:00:43.239829Z INFO ThreadId(01) running Hermes v1.7.4+38f41c62-dirty
2024-04-08T05:00:43.972521Z INFO ThreadId(01) Creating new clients, new connection, and a new channel with order ORDER_UNORDERED
2024-04-08T05:00:47.536304Z ERROR ThreadId(01) foreign_client.create{client=theta-testnet-001->shielded-expedition.88f17d1d14:07-tendermint-0}: failed to create client: error raised while creating client for chain shielded-expedition.88f17d1d14: failed sending message to dst chain : Namada error: Namada error: Could not retrieve from storage the gas cost for token tnam1qq9m9ga5jmv4jfjmkfdfxypeugn7u5lykye8qrtj
ERROR error raised while creating client for chain shielded-expedition.88f17d1d14: failed sending message to dst chain : Namada error: Namada error: Could not retrieve from storage the gas cost for token tnam1qq9m9ga5jmv4jfjmkfdfxypeugn7u5lykye8qrtj

what should I do, @warped holly can you help me

[cunning finch]

You are inputting a wrong NAAN denom

At config

[vernal palm]

Hey Daniel,if I completed the relayer, how can i know is it right?

2024-04-08T05:26:04.308314Z INFO ThreadId(01) # Chain: theta-testnet-001

• Client: 07-tendermint-3587
  • Connection: connection-3673
    | State: OPEN
    | Counterparty state: OPEN
    • Channel: channel-4157
      | Port: transfer
      | State: OPEN
      | Counterparty: channel-1217

Chain: shielded-expedition.88f17d1d14

• Client: 07-tendermint-3706
  • Connection: connection-1845
    | State: OPEN
    | Counterparty state: OPEN
    • Channel: channel-1217
      | Port: transfer
      | State: OPEN
      | Counterparty: channel-4157

And how can i submit it

[cunning finch]

Send funds from/to and provide the respective recv txs and ack txs (on Cosmos side), and the balance of the destination address at Namada. Anyway, I don't know what's the standard submission you need to follow now, take a look at S class spreadsheet for further reference

[vernal palm]

Thank you Daniel

[warped holly]

Ah I was in dreamville, thank you @cunning finch!

Up till now this workaround method seems to work btw! Both of the channels on the site are up and still functioning. Believe I'm the only one relaying on those channels.

[minor solstice]

do we have any canonical/stable channel atm, or did we skip that idea?

asking for a friend lol

[molten drum]

we do not have canonical atm, there are stable enough, you can start updating any of them to be sure in them

[minor solstice]

anyone got channels they're maintaining that I can use?

[molten drum]

just configure update to them, literally you will maintain them ))

[minor solstice]

aye maybe I'll just make my own so I have complete control 🙂

[molten drum]

what is the difference? you do not control channels/clients/connections at all 😄 you can just create and work with them (e.g. update to don't allow to expire)

it is not like this is your channel, you just create it in the chain, that's all

[stark mesa]

channel 4157 works from cosmos to namada.
and ,also works channel 1217 namada>cosmos.
nice work! 👍
dont forget to update the channel periodically, otherwise it will freeze.

[vernal palm]

after run a relayer

so what should i submit ?

[turbid remnant]

Go to mintscan paste the address of the cosmos you used during the channel creation.

Submit those, Txn that gas ibc create client and ibc transfer / received that has your memo

Also make sure to submit theta channel and namada channel id.

Your receiver address where did you get that I never seen in my entire life. 😆

• use cosmos address *

[minor solstice]

I'm aware but then I know it's freshly created today 🙂

[molten drum]

what does that knowledge give to you? 🤔

[minor solstice]

how long it will take before expiring 🙂 also there is something I can better control in tx flow when they're exclusively my channels - unless others start relaying too

[molten drum]

update it on your own and it will depend on you only)
there are no exclusive channels that's the thing, anyone who will find it working can use it
it is just in Namada that everyone wants to create their own channels, it should not be like this
the list of working channels must be limited to the canonical list

[minor solstice]

how do you guys check ibc assets received on let's say cosmos?

[molten drum]

mintscan and cli q balance

[cunning finch]

Denom tracer is also useful

To know where the asset comes from

[warped holly]

Indeed, very useful

That's where I saw how many denoms were actually made for SE on all these chains...😂

There's this allDenomTraces method that just pours out a whole list of denoms, osmo and theta were filled with naan variants

[cunning finch]

Haha I think we were the testnet with most high activity in that sense. Stressing out ibc-rs like crazy, and that's good, because now is almost broken till 0.52 update

[warped holly]

HEhehe for sure, we took this testnet to the next level. Rightfully so XD!

[minor solstice]

thanks!

nobody can get osmo to work atm, is that correct?

[minor solstice]

@molten drum that there are no osmosis channels on your ibc page, is that by choice/rpc issue, or due to there not being any left?

think zen has one running if I'm not mistaken?

[warped holly]

Yeah got one running

[cunning finch]

I just tried the one in LiveRaven's site, but seems to be run out of funds (relayer addresses I assume)

Or mb info it's not up to date

Cosmos one worked well

[warped holly]

channel-6738 <=> channel-1235 is still up

https://zenode.app/explorer/namada/ibc

[cunning finch]

Gonna try it in my sh app

hehe

Thanks ❤️

[warped holly]

Don't think that one is listed on LiveRaveN

Hehe, I'm doing the same XD..

Building one as well here cause of my own uncertainty

Seeing stuff in my hermes hehe.

[carmine trail]

 
channel_id: 
                "channel-1147"

Osmosis

  channel_id:
                "channel-6691"```
may still be up

[cunning finch]

Hope shielded sync thing is resolved after SE, balances fetching delay a bit. @warped holly it worked 🫡

Last committed epoch: 87
transfer/channel-1235/uosmo : 666
transfer/channel-1259/uatom : 666
transfer/channel-1263/udvpn : 2180```

[warped holly]

Nice :)!

[minor solstice]

you got an osmo rpc for use by any chance? 😏

[cunning finch]

https://rpc.testnet.osmosis.zone:443

[minor solstice]

thanks but it keeps failing with certain things

[cunning finch]

This one is maintained by OSL team https://rpc.testnet.osl.zone:443, mb it works

[minor solstice]

thanks!

[median island]

I did some shielded transfer from osmo to namada but i didn't see uosmo in my wallet

[warped holly]

Likely the viewing key isn't synced then

[median island]

Syncing every minute

[warped holly]

Double check the vk you sent it to

Also what works for me is to shielded-sync using --viewing-keys

Let me double check for ya though.

Ugh, now what. something's up with my site though, it fails at times to generate.

It can't keep up with the requests lol.

My rpc node is having a hard time

It's working again though, but this has nothing to do with the abovee (cause you wouldn't be able to send anything if you had the same issue I had)

I received it btw (shielded). So everything is working.

[cunning finch]

In my case I have noticed that some rpcs are few blocks behind sometimes

[warped holly]

Keep thinking my rpc is getting spammed 😂

[minor solstice]

possible

[molten drum]

it is due to the problems with RPC, it is limited by the number of requests, I didn't refactor the code specifically for osmosis yet
and will spin up own testnet rpc for osmosis soon

[molten drum]

restored osmosis info 🤓
https://services.liveraven.net/cosmos-testnets/namada/ibc-channels#greater-than-osmosis-testnet it's alive 🤪

[minor solstice]

got an ibc question

let's say in production, that tokens are transfered to a network via ibc. channel dies. can't be restored. are those tokens forever orphaned on that other network, or can they be recovered somehow?

[unique aspen]

That crossed my mind when I read how bridged tokens are non-fungible.

Let me find that

[minor solstice]

because afaik they can only get back to origin via same channel..

[unique aspen]

https://github.com/anoma/namada/issues/2908#issuecomment-2003298286

Super good explanation by Krewedk0

I just have to quote it

When any token is transferred via IBC it gets wrapped in channel id that was used for this transfer, path part of denom trace: {"denom_trace":{"path":"transfer/channel-902","base_denom":"uosmo"}}
To get it unwrapped this token needs to get transferred back to native chain using same channels pair.

If it transferred via any other channel it gets wrapped once again using same logic.
In your 3.1 example it became {"denom_trace":{"path":"transfer/channel-6345/transfer/channel-902","base_denom":"uosmo"}}
So to unwrap it to native uosmo denom you need to transfer it back in reverse order:

osmo -> namada via channel-6345
namada -> osmo channel-902

REST endpoint to decode denom and get token's path:
https://lcd.testnet.osmosis.zone/ibc/apps/transfer/v1/denom_traces/F27AC8A6C4221C89F17F2F0045F2A981AC0F38309F42AD1D0CC24CF13BEC0C63

So you can end up with a token named transfer/channel-6345/transfer/channel-902/uosmo

In that case I guess you have to revive all the channels.

Which is annoying enough if you are a participant in this event, let alone a normal user that only uses the frontends.

[minor solstice]

and there is my question - can dead channels be revived?

[minor solstice]

in practice ibc will probably be by official channels that are tightly managed imo

[unique aspen]

Apparently that is not possible.

Reusing channel IDs are prevented in order to avoid replay of packets. Every packet is uniquely identified by its port ID, channel ID, and sequence. When a new channel opens, the packet sequence is reset to zero. Therefore, using the same port ID and channel ID can cause packets that were processed earlier to be replayed again.```

Nice, just froze 100 billion transfer/channel-6345/transfer/channel-902/uosmo for all of eternity.

https://medium.com/simplystaking/reviving-an-ibc-client-with-governance-hermes-relayer-362a1da4814d

[minor solstice]

this is what I was wondering. seems a monumental flaw

unless there is some way to remedy

@molten drum any thoughts?

[unique aspen]

It takes a governance proposal.

Our situation is a bit non-standard, having tens of ephemeral channels just for the sake of getting that S Class. Like you said, the assumption is a tightly managed channel.

[minor solstice]

I mean if a gov proposal can do it, not the biggest deal in the world

[unique aspen]

It is also not not a big deal

https://ibc.cosmos.network/main/ibc/proposals.html

Need to pay for the proposal, need the proposal to pass... looking at my proposal 657 sitting pretty

[cunning finch]

That's called fungibility, I mean, it's not a mystery 😅

Let's say you send naan to Osmosis testnet, then to Cosmos testnet, and finally back to Namada. Those naan will lose its fungibility unless they go through the origin route

i.e. Namada to Cosmos testnet, then to Osmosos testnet and finally, voilà, they end up in Namada as native NAAN

[cunning finch]

That's for ibc-go, we are using ibc-rs. This is likely to be implemented with 0.52 of ibc-rs (we'll need the specific gov type, ofc)

[minor solstice]

I don't see why that is intuitively a good or right thing

I can see it's how the protocol needs to work, but

[cunning finch]

It's how IBC has been designed. Some people suggested other models that would remove that need, like path unwinding

Apart from using it to enable fee middleware, channel upgradability allows you to upgrade application modules, such as upgrading ICS-20 token transfer from v1 to v2.

We are currently in the process of researching ICS-20 v2 which might include features like supporting multiple denoms within a single packet and having path unwinding natively within the protocol. By leveraging channel upgradability, your chain can use new ICS-20 features upon launch (planned for later this year).```

https://www.ibcprotocol.dev/blog/introducing-ibc-channel-upgradability

[molten drum]

hm, need to read all above 😄 🧐

[minor solstice]

you are late to the party sir 🙂

[molten drum]

crap, so am I free to don't read? 🤓 🤔

[minor solstice]

you should, because it's interesting

but yes problem discussed and kinda resolved kinda not

[molten drum]

ok, making coffee )

[molten drum]

walked through
so, yeah, the client can be revived using gov prop and that is why each mainnet chain must use canonical channels with their clients
otherwise, it is hard to convince ppl to vote for each "private" client
if the chain has a canonical list which is maintained and can be frozen only in case of malfunctions, you will not lose them or it will be easy to revive them by the project team request (prop)

[warped holly]

Yess, totally right!

You happen to know if a frozen channel could also be revived though? I only know of expired ones being able to get revived using the updateClient proposal on both chains. But never encountered frozen ones getting revived.

[molten drum]

frozen can be as well, afaik )

just could be if it was closed coz of malfunction it should be fixed before to don't get it frozen again

how it was here, you found the problem

[warped holly]

Oof, better!

Yeah this was my only concern. Though the issue is provsbly fixed next version around.

[molten drum]

just no reason to unfreeze testnet channels, if only it is not one-sided then it is much easier

no chance to unfreeze smth on osmo or gaia testnets 😄

[warped holly]

Yeah for sure haha, all these testnet stuff should be forgotten.

😂 With 5 min proposals

[molten drum]

someone said that there is some kind of limit like 65k channels per chain, and then you get banned 😄 chain I mean

[warped holly]

The vote period is super short right?

[warped holly]

Oh shit. Let's make more.

😏.

[molten drum]

maybe that ban means that you just not able to create more and need to revive the old ones

[warped holly]

You know how many we've made?

Ah we can see this with the counter huh.

We were roughly against 2000?

Or more like 1500 I guess.

Last channel I made was 1235, but others have surely made in the meantime as well.

[molten drum]

will tell you exactly in a couple of mins)) just need to wait a query to complete

smth like 2k yeah

or mb 1300+, as I see in my list of active

transfer/channel-1313

the last 😄

shielded-expedition.88f17d1d14: transfer/channel-1313 --- theta-testnet-001: transfer/channel-4189

double 13 😄

[silk totem]

guys do we have a working channel between namada and osmosis ?

[molten drum]

would be funny if this one could not have a counterparty side, then we could name it as the channel to the hell 😄 😈
shielded-expedition.88f17d1d14: transfer/channel-666 --- osmo-test-5: transfer/channel-6160

[molten drum]

https://services.liveraven.net/cosmos-testnets/namada/ibc-channels#greater-than-osmosis-testnet
feel free to select any from 33 😄

[silk totem]

thank you sir

[minor solstice]

ok so guys, I don't understand how shielded ibc transfers back to namada from other chains gets registered on points, as the memo does not include our pk anywhere?

[urban stag]

hey @here, thanks so much for engaging and running relayers/scripts, trying to keep the channel alive, and troubleshooting all the weirdnesses 🙌

sorry for not messaging sooner, but you're okay to take down your relayers and scripts (if you haven't already)

[turbid remnant]

Thanks for the info

[atomic tendon]

Will keep channel by 95 epoch

[minor solstice]

can we also take down validators, indexers, rpcs and so on or should we leave those up for now?

[urban stag]

ideally leave the rest up until Epoch 95 🙏

[woven sky]

Channel for SE <=> Which Cosmos is recommended until epoch 95?

[warped holly]

I made one yesterday again, you can use it via my site or manually (channel-4194 theta-testnet-001 <=> channel-1322 namada). I think it's still working.

Just make sure not to relay on it, there's a bug that could potentially freeze it if more people relay.

Also just try not to spam it, I dunno exactly when it goes into freeze-mode 😅.

[stark mesa]

Why are you creating new channels? I got tired of it after creating 10 channel from namada

[cunning finch]

ibc-rs version we still use is broken and clients are getting frozen randomnly from time to time. Upgrading ibc-rs to 0.51 will solve that and, doing so to 0.52, will let us upgrade expired clients via gov

Refer to https://github.com/anoma/namada/issues/3011

[minor solstice]

we still doing stuff on the testnet?

[warped holly]

I only got it open for my submissions

[minor solstice]

imma unjail my validators anyways lol

are there any proposals to be voted on? 😂

[carmine trail]

gonna be hard to get anything to pass without Sporks vote 😄