-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
support denoms custom validation #7450
support denoms custom validation #7450
Conversation
Codecov Report
@@ Coverage Diff @@
## launchpad/backports #7450 +/- ##
======================================================
Coverage ? 50.23%
======================================================
Files ? 338
Lines ? 17548
Branches ? 0
======================================================
Hits ? 8815
Misses ? 7945
Partials ? 788 |
Hey! Just rebase this against |
@ethanfrey @clevinson |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks clean enough to me. And all that change are private (package-internal) variables, just adding some public variables.
I guess you could set this in app.go
to allow different denoms, but I am unclear if that is actually useful? Keeping them strict and consistent is nice in the lead-up to IBC. Why do we want people to allow emoji denoms? (Show me the use case and I may approve it)
@@ -70,6 +70,31 @@ func TestCoinIsValid(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestCustomValidation(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part I get
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
) | ||
|
||
func returnDecCoin() *regexp.Regexp { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And so if I write the global CoinDenomRegex
it will let me override all these checks done inside of Coin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FTR @okwme, I've taken care of this ->
👍 |
We made a kudos blockchain where users can mint one emoji denom coin a day: http://github.com/interchainberlin/pooltoy I had to fork the SDK just to allow use of emojis. I can see why it's important for IBC denom management to be consistent but when the logic is just internal to the application it should be up to the application to make those design choices. We might go as far and actually make denom recommendations (in the form of default values maybe like now) but it's always going to be up to the app developer to make those final calls. We'd be better to give them a clean method of doing so rather than forcing them to fork the SDK and potentially fall out of sync with updates. Do you think it's a strong enough security threat that we should be making it as difficult as possible to make custom denoms validation @ethanfrey ? |
Thank you for explaining the use case. Sounds like a fun toy. I would just ask you to check with the IBC team on this one if it is an issue (or if they can add emoji support to ICS20). If they give it an okay, then I will too. This is more important for the merge to master, I guess this can go in, but then if we disable emojis in stargate, that would suck. |
@cwgoes i think you’d confirmed previously that this wouldn’t be a problem,
is that still correct?--
billyrennekamp.com
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking a bit more, it shouldn't not stop an IBC transfer for an emoji from a chain to a non-emoji chain, as the tokens are described with hashes. It would just block displaying it properly on the remote chain. And that being that IBC doesn't add emoji support.
I actually see other use-cases changing lengths or casing or special chars per chain.
I just need to think on it a bit, but I approve this. Happy to see them pool toys
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go (pending merge of #6755 - that should go in first)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a changelog entry for this (e.g. https://github.com/cosmos/cosmos-sdk/pull/6755/files#diff-4ac32a78649ca5bdd8e0ba38b7006a1eR166)
@alessio updated the changelog, is that the correct format? |
@okwme looks good to me |
Backport of #6755
Closes: #6744
Origin: #6755
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes