1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1X77Ku-000159-3H
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 18:20:20 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.42 as permitted sender)
client-ip=209.85.219.42; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f42.google.com;
Received: from mail-oa0-f42.google.com ([209.85.219.42])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X77Kt-00007l-2K
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 18:20:20 +0000
Received: by mail-oa0-f42.google.com with SMTP id n16so6386681oag.29
for <bitcoin-development@lists.sourceforge.net>;
Tue, 15 Jul 2014 11:20:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.52.5 with SMTP id p5mr13701110oeo.55.1405448413537; Tue,
15 Jul 2014 11:20:13 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Tue, 15 Jul 2014 11:20:13 -0700 (PDT)
In-Reply-To: <CANg-TZAe2PO9nwQktmDSJFtaLsg6hogOw6mj0SaROdJJr33vog@mail.gmail.com>
References: <CANEZrP3ZzCBohXWZmZxE=ofP74Df4Hd-hCLH6jYn=JKbiqNQXA@mail.gmail.com>
<CAObn+gfbH61kyv_ttT4vsQuNFRWLB5H3xaux7GQ0co82ucO_eA@mail.gmail.com>
<CANg-TZAe2PO9nwQktmDSJFtaLsg6hogOw6mj0SaROdJJr33vog@mail.gmail.com>
Date: Tue, 15 Jul 2014 20:20:13 +0200
X-Google-Sender-Auth: DpMKaZyF5XT5nrC_Rs0-Qzq6beY
Message-ID: <CANEZrP3E2mdvOUHiW9W_hM3Z_kn9um8E6aX5vf-S9tA7KgnpUQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Brooks Boyd <boydb@midnightdesign.ws>
Content-Type: multipart/alternative; boundary=001a11332c8e706f3e04fe3f75b3
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.1 TRACKER_ID BODY: Incorporates a tracking ID number
0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1X77Kt-00007l-2K
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 38 NFC normalisation issue
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 18:20:20 -0000
--001a11332c8e706f3e04fe3f75b3
Content-Type: text/plain; charset=UTF-8
Yes, we know, Andreas' code is indeed doing normalisation.
However it appears the output bytes end up being different. What I get back
is:
cf9300*01*303430300166346139
vs
cf9300*f0*909080f09f92a9
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.
--001a11332c8e706f3e04fe3f75b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, we know, Andreas' code is indeed doing normalisat=
ion.<div><br></div><div>However it appears the output bytes end up being di=
fferent. What I get back is:</div><div><br></div><div><font face=3D"courier=
new, monospace" size=3D"4">cf9300<b>01</b>303430300166346139</font><br>
<div><br></div><div>vs</div><div><br></div><div><span style=3D"color:rgb(51=
,51,51);line-height:18.545454025268555px;background-color:rgb(248,248,248)"=
><font face=3D"courier new, monospace" size=3D"4">cf9300<b>f0</b>909080f09f=
92a9</font></span><br>
</div><div><br></div><div><div class=3D"gmail_extra">from the spec.=C2=A0</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I'm=
not sure why. It appears this is due to the character from the astral plan=
es. Java is old and uses 16 bit characters internally - it wouldn't sur=
prise me if there's some weirdness that means it doesn't/won't =
support this kind of thing.=C2=A0</div>
<div class=3D"gmail_extra"><br></div></div></div><div class=3D"gmail_extra"=
>I recommend instead that any implementation that wishes to be compatible w=
ith JVM based wallets (I suspect Android is the same) just refuse any passp=
hrase that includes characters outside the BMP. At least unless someone can=
find a fix. I somehow doubt this will really hurt anyone.</div>
</div>
--001a11332c8e706f3e04fe3f75b3--
|
