📅 Original date posted:2014-07-15
📝 Original message:If the user creates a password on an iOS device with an astral
character and then can't enter that password on a JVM wallet, that
sucks. If JVMs really can't support unicode NFC then that's a strong
case to limit the spec to the subset of unicode that all popular
platforms can support, but it sounds like it might just be a JVM
string library bug that could hopefully be reported and fixed. I get
the same result as in the test case using apple's
CFStringNormalize(passphrase, kCFStringNormalizationFormC);
Aaron Voisine
breadwallet.com
On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net> wrote:
> Yes, we know, Andreas' code is indeed doing normalisation.
>
> However it appears the output bytes end up being different. What I get back
> is:
>
> cf930001303430300166346139
>
> vs
>
> cf9300f0909080f09f92a9
>
> from the spec.
>
> I'm not sure why. It appears this is due to the character from the astral
> planes. Java is old and uses 16 bit characters internally - it wouldn't
> surprise me if there's some weirdness that means it doesn't/won't support
> this kind of thing.
>
> I recommend instead that any implementation that wishes to be compatible
> with JVM based wallets (I suspect Android is the same) just refuse any
> passphrase that includes characters outside the BMP. At least unless someone
> can find a fix. I somehow doubt this will really hurt anyone.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:23:51
in reply to nevent1q…fush
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:23:51Event JSON
{
"id": "31bd9f4fd7247726b22e36c4f4c0592cf7e6b275bc9d327ab49cc16c465af5dd",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686151431,
"kind": 1,
"tags": [
[
"e",
"60726055f5690f49a0698605fd9e440f1a7b0fbf2e702b7f0382a84f86474ca9",
"",
"root"
],
[
"e",
"7c7f104b8ddac7f2b43a9506344d4c048953ef0dcecf2e4afc5344f49f446be7",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-07-15\n📝 Original message:If the user creates a password on an iOS device with an astral\ncharacter and then can't enter that password on a JVM wallet, that\nsucks. If JVMs really can't support unicode NFC then that's a strong\ncase to limit the spec to the subset of unicode that all popular\nplatforms can support, but it sounds like it might just be a JVM\nstring library bug that could hopefully be reported and fixed. I get\nthe same result as in the test case using apple's\nCFStringNormalize(passphrase, kCFStringNormalizationFormC);\n\nAaron Voisine\nbreadwallet.com\n\n\nOn Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Yes, we know, Andreas' code is indeed doing normalisation.\n\u003e\n\u003e However it appears the output bytes end up being different. What I get back\n\u003e is:\n\u003e\n\u003e cf930001303430300166346139\n\u003e\n\u003e vs\n\u003e\n\u003e cf9300f0909080f09f92a9\n\u003e\n\u003e from the spec.\n\u003e\n\u003e I'm not sure why. It appears this is due to the character from the astral\n\u003e planes. Java is old and uses 16 bit characters internally - it wouldn't\n\u003e surprise me if there's some weirdness that means it doesn't/won't support\n\u003e this kind of thing.\n\u003e\n\u003e I recommend instead that any implementation that wishes to be compatible\n\u003e with JVM based wallets (I suspect Android is the same) just refuse any\n\u003e passphrase that includes characters outside the BMP. At least unless someone\n\u003e can find a fix. I somehow doubt this will really hurt anyone.\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Want fast and easy access to all the code in your enterprise? Index and\n\u003e search up to 200,000 lines of code with a free copy of Black Duck\n\u003e Code Sight - the same software that powers the world's largest code\n\u003e search on Ohloh, the Black Duck Open Hub! Try it now.\n\u003e http://p.sf.net/sfu/bds\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "268e6b44d5c8f284d9b3e3f3d5bfb87b6876c3b6445aa5c4b35eed902cd754a37f1c223d4d9dd22fdcfe794a205625a2e5ae8a7e8abca97d83f6b4af4fdb3b20"
}