fix fail amino sign verify with special chars

[loin3]

this PR is for #1367

I found that there is a problem with escaping special chars in keplr-wallet. If you follow this method, the value is still escaped when you check memo of tx in mintscan. Because cosmjs sends memo through protobuf, the value needs to be escaped only when signed with amino. So escaping is done only on values ​​encoded for amino signatures. This way, even if you look up the tx, the memo will not be escaped.

[webmaster128]

Thank you for this PR. Since we only care about JSON strings and not the whole JSON document, I think it is cleaner and safer to use the replacer argument in JSON.stringify.

Here is some example how this can be used to manipulate the inner strings as part of the stringification: https://gist.github.com/Tanapruk/4ab1505ead2491229235c886b6fbfaac

[NoahSaso]

hey @loin3, thanks for doing this :)

eagerly awaiting this over at DAO DAO because our users run into this bug all the time

[webmaster128]

@NoahSaso if you need this quickly as part of the upcoming 0.30.0 release, have a look at #1367. We should implement this differently. If you are in the mood, feel free to jump in.

[webmaster128]

Sorry, I mixed up issue and PR here. I was referring to

Thank you for this PR. Since we only care about JSON strings and not the whole JSON document, I think it is cleaner and safer to use the replacer argument in JSON.stringify.

Here is some example how this can be used to manipulate the inner strings as part of the stringification: https://gist.github.com/Tanapruk/4ab1505ead2491229235c886b6fbfaac

[loin3]

I agree that this implementation should be changed to something tidy way. because modifying the byte code directly is very ugly.

here is the reason why I should modify byte code directly.
utf8 byte code of character & is 38 and unicode of byte codes is 92, 117, 46, 46, 50, 54 (\u0026).
json marshaller in go automatically escape the character & to unicode. so when signature verifying, incoming messages's byte code should contain 92, 117, 46, 46, 50, 54 (\u0026) rather than 38.
but the problem is JSON.stringfy authmatically change unicode (\u0026) to character &. so even though I used unicode, for example {memo: "alice \u0026 bob"}, unicode authmatically changed to "alice & bob".

[webmaster128]

Oh, I see. This makes sense, thank you. In this case the current implementation makes sense. I'll have another look and throw a bunch of low level unit tests on the implementation to better understand it.

Thanks a lot!

[webmaster128]

Oh damn, sorry, wrong PR. I did not aim to merge this yet. Reverted the merge. I'll look into this ASAP.

[webmaster128]

I used this work in #1388. There I migrated from binary to string based replacement and increased low level test coverage. Reviews appreciated.