<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-07-15&#xA;📝 Original message:Yes, we know, Andreas&#39; code is indeed doing normalisation.&#xA;&#xA;However it appears the output bytes end up being different. What I get back&#xA;is:&#xA;&#xA;cf9300*01*303430300166346139&#xA;&#xA;vs&#xA;&#xA;cf9300*f0*909080f09f92a9&#xA;&#xA;from the spec.&#xA;&#xA;I&#39;m not sure why. It appears this is due to the character from the astral&#xA;planes. Java is old and uses 16 bit characters internally - it wouldn&#39;t&#xA;surprise me if there&#39;s some weirdness that means it doesn&#39;t/won&#39;t support&#xA;this kind of thing.&#xA;&#xA;I recommend instead that any implementation that wishes to be compatible&#xA;with JVM based wallets (I suspect Android is the same) just refuse any&#xA;passphrase that includes characters outside the BMP. At least unless&#xA;someone can find a fix. I somehow doubt this will really hurt anyone.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140715/fe65167b/attachment.html&gt;</html></oembed>