Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

change "bech32" prefix for bitbadges #5493

Merged
merged 3 commits into from
Oct 26, 2024
Merged

Conversation

trevormil
Copy link
Contributor

It has come to my attention via X that using the bech32 prefix "cosmos" has broken some services that depend on this registry. BitBadges is showing up where the Cosmos Hub is expected or causing other problems due to the collision.

To avoid confusion and breaking anything, I would like to remove this line from the registry. I noted that "bech32_prefix" is not required in the schema file, so for the time being, I would like to remove it.

I think this is a better solution because:
-Collisions are avoided.
-If not having the "bech32_prefix" causes issues, this would only occur for BitBadges and we will handle accordingly (rather than affecting other projects).
-Anyone can still just view the BitBadges documentation to get our Cosmos prefix.

I still plan to migrate to a personal prefix, but that may require a complete chain restart or some other difficult feat of engineering.

@trevormil
Copy link
Contributor Author

Ok, after seeing the validation checks fail, I will just simply update it to "bb" which is the future prefix I plan to migrate to.

I will elevate this and work on handling the migration from "cosmos" to "bb" on my end as soon as possible. Again, sorry for any confusion or inconveniences this caused.

@trevormil trevormil changed the title remove "bech32" prefix for bitbadges change "bech32" prefix for bitbadges Oct 21, 2024
@Cordtus
Copy link
Contributor

Cordtus commented Oct 22, 2024

Yeah typically this is something relating to or identifiable by your chain name or project name or something. bb is probably fitting, or badge or something like this..

What you were trying to do by ensuring it was the same wallet address across chains (if I am not mistaken) is something you actually don't need to do, this is not EVM.

When you create a wallet, the bech32 prefix is actually part of the derivation of the resulting wallet address.
As long as you know one of them (and they were derived using the same HDpath of course), you can determine any of the others. You can test it for yourself here.

@trevormil
Copy link
Contributor Author

@Cordtus Yea, I understand how they work.

The reasoning isn't exactly as explained. The original idea was more that we didn't want to have our own addresses because we can be thought of as a hub and are supportive of every ecosystem. So, we support Solana, Ethereum, Bitcoin addresses, and in a similar manner, we wanted to make it seem like we support Cosmos ecosystem as well (thus using "cosmos" addresses). See https://docs.bitbadges.io/for-developers/accounts.

You are right. We can just map "cosmos" addresses to "bb" addresses too. It was just a design decision we made that we will now have to change. I do not actually think it breaks anything on the blockchain level, but it adds confusion / breaks dependent apps on the registry level.

@Cordtus
Copy link
Contributor

Cordtus commented Oct 22, 2024

ah I see I was understanding this part differently:

To enable interoperability between different blockchains, each individual L1 blockchain will have its native addresses mapped to an equivalent Cosmos bech32 address. We use the mapped cosmosAddress as the universal base address whenever needed. 

so yeah in this case you can actually choose whatever (standard, cointype 118-derived) wallet address you want here, whether it's osmosis, cosmos, stargaze, juno, etc..

@JeremyParish69 JeremyParish69 merged commit 0e5b998 into cosmos:master Oct 26, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants