{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-07-16\n📝 Original message:I'm all for fixing bugs, but I know from bitter experience that outside the\nBMP dragons lurk. Browsers don't even expose Unicode APIs at all. You end\nup needing to ship an entire pure-js implementation, which can be too large\nfor some use cases (too much time sunk on that issue in my last job).\n\nI'm hoping BIP 38 doesn't get widely used anyway, to be frank. People\nmoving private keys around by hand has caused quite a few problems in the\npast, sometimes people lost money. It's better to work at the level of a\nwallet and ideally ask people to move money using regular transactions. Way\nless potential for errors.\n\nRegardless, I'll file a JVM bug and see what the outcome is.\n\n\nOn Wed, Jul 16, 2014 at 12:23 AM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\n\u003e If the user creates a password on an iOS device with an astral\n\u003e character and then can't enter that password on a JVM wallet, that\n\u003e sucks. If JVMs really can't support unicode NFC then that's a strong\n\u003e case to limit the spec to the subset of unicode that all popular\n\u003e platforms can support, but it sounds like it might just be a JVM\n\u003e string library bug that could hopefully be reported and fixed. I get\n\u003e the same result as in the test case using apple's\n\u003e CFStringNormalize(passphrase, kCFStringNormalizationFormC);\n\u003e\n\u003e Aaron Voisine\n\u003e breadwallet.com\n\u003e\n\u003e\n\u003e On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e \u003e Yes, we know, Andreas' code is indeed doing normalisation.\n\u003e \u003e\n\u003e \u003e However it appears the output bytes end up being different. What I get\n\u003e back\n\u003e \u003e is:\n\u003e \u003e\n\u003e \u003e cf930001303430300166346139\n\u003e \u003e\n\u003e \u003e vs\n\u003e \u003e\n\u003e \u003e cf9300f0909080f09f92a9\n\u003e \u003e\n\u003e \u003e from the spec.\n\u003e \u003e\n\u003e \u003e I'm not sure why. It appears this is due to the character from the astral\n\u003e \u003e planes. Java is old and uses 16 bit characters internally - it wouldn't\n\u003e \u003e surprise me if there's some weirdness that means it doesn't/won't support\n\u003e \u003e this kind of thing.\n\u003e \u003e\n\u003e \u003e I recommend instead that any implementation that wishes to be compatible\n\u003e \u003e with JVM based wallets (I suspect Android is the same) just refuse any\n\u003e \u003e passphrase that includes characters outside the BMP. At least unless\n\u003e someone\n\u003e \u003e can find a fix. I somehow doubt this will really hurt anyone.\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Want fast and easy access to all the code in your enterprise? Index and\n\u003e \u003e search up to 200,000 lines of code with a free copy of Black Duck\n\u003e \u003e Code Sight - the same software that powers the world's largest code\n\u003e \u003e search on Ohloh, the Black Duck Open Hub! Try it now.\n\u003e \u003e http://p.sf.net/sfu/bds\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140716/c9ab11cb/attachment.html\u003e"}