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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <ajwest@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3027240A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 14:43:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
[209.85.218.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB05A203
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 14:43:13 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id 199so3652488oii.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 07:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=KETFVaKj0XxA/Pp2ixK+rOfZgwRXGnGP6Ycy6TryjG0=;
b=f1rVKF06xL+0ccV1viC82KAWH04kG5hPOGDTs+Dsix17ycZJ5NEwrh6fDNT2P/qfwg
oFp/GMhrFOSs+AZkM6HGGLtgq1xKCurUYKSAvGblZegX9wyIiufW//42Q+WwPuOXwKeP
Ea0g1ZDaYQAkC0G7B1Olka+Is5Km2epu6DhOtRSQiQnpFz6kR7HmPwHLySmgwa0mlQJq
vROeNin1hO87rVBlf021iKUwcav1Z9YKdqrcr3W4Pzbk0WP1kNSWhmB/uOD2A8aKp1HJ
2SSPBCql9n8PdVAVWZRt6RUTsttdBTS69VqfKjXthLy4MOWWdbDV7ORKwVJUr1kGqRQx
pEFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=KETFVaKj0XxA/Pp2ixK+rOfZgwRXGnGP6Ycy6TryjG0=;
b=S6OFcGPVV+pSh8a1x1X6m1q6hMoBSQpfPn/cOEboWFimOzqtkzGQaepUHbzGxGXv27
cI+X7+9aMdj1XUle3zZy/2xNwMrSlAL7s+13KMBsptflFSzCjpEYJSALm/F/NWziYwpW
97HudJSyrgu1DuB4cfRI+0zbrhLAjDmGrM5VZ3ldT9VYv+zwXF3OJe5UVUI641WVgnfG
ylvbVYaZ7Bm+SjfwoulTEGLuOva44u1cMclRTFrXBjvgTxMmgjEZIEd1KqzM3G6i1e9v
WwkPKG1uVrTCd4eOA0hCHHVmbY5wlM1Y7ymV7CEZQ1yhceqKiXIM2G/RoMEPHpaNBjT4
6T8w==
X-Gm-Message-State: AHPjjUhng8ZwSQTMgWIzhyorp8ka00pU8Qbiy8keaPs665AK8cYlRYPy
E/WQTHdc+d87gFpsrS1muBeLOytvgbzx8pm5kbxS2mnG
X-Google-Smtp-Source: AOwi7QBhxl2B6pS98u9b7VmpTuREEi7AqGDPPqATocj7QyUKQQGBkRNVi1jQb+BrgH4SgA1OZN+Ufx3/9ikt/PZqDQ4=
X-Received: by 10.202.214.143 with SMTP id n137mr35204856oig.231.1505659393152;
Sun, 17 Sep 2017 07:43:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.68.217 with HTTP; Sun, 17 Sep 2017 07:42:52 -0700 (PDT)
In-Reply-To: <0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org>
References: <34198916-cde9-c84d-ca41-9feb8956bd80@electrum.org>
<CAPg+sBgukwdRvfFcgdusrXoo8RiXm8OEL-WvHzjpiD8_HU5KmQ@mail.gmail.com>
<0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org>
From: AJ West <ajwest@gmail.com>
Date: Sun, 17 Sep 2017 10:42:52 -0400
Message-ID: <CABXVU6YKLwr-zev_=AmGDqwZ6ZkMwa=2ooPoDWv22XU8-QzajA@mail.gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113df360481b9f055963a5aa"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 17 Sep 2017 14:49:45 +0000
Subject: Re: [bitcoin-dev] proposal: extend WIF format for segwit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Sep 2017 14:43:18 -0000
--001a113df360481b9f055963a5aa
Content-Type: text/plain; charset="UTF-8"
Hi I have a small interjection about the point on error correction (excuse
me if it seems elementary). Isn't there an argument to be made where a
wallet software should never attempt to figure out the 'correct' address,
or in this case private key? I don't think it's crazy to suggest somebody
could import a slightly erroneous WIF, the software gracefully
error-corrects any problem, but then the user copies that error onward such
as in their backup processes like a paper wallet. I always hate to advocate
against a feature, I'm just worried too much error correcting removes the
burden of exactitude and attention of the user (eg. "I know I can have up
to 4 errors").
I'm pretty sure I read those arguments somewhere in a documentation or
issue tracker/forum post. Maybe I'm misunderstanding the bigger picture in
this particular case, but I was just reminded of that concept (even if it
only applies generally).
Thanks,
AJ West
On Sun, Sep 17, 2017 at 4:10 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 17.09.2017 04:29, Pieter Wuille wrote:
> >
> > This has been a low-priority thing for me, though, and the computation
> work
> > to find a good checksum is significant.
> >
>
> Thanks for the info. I guess this means that a bech32 format for private
> keys is not going to happen soon. Even if such a format was available,
> the issue would remain for segwit-in-p2sh addresses, which use base58.
>
> The ambiguity of the WIF format is currently holding me from releasing a
> segwit-capable version of Electrum. I believe it is not acceptable to
> use the current WIF format with segwit scripts; that would just create
> technological debt, forcing wallets to try all possible scripts. There
> is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it
> makes it unambiguous.
>
> I see only two options:
> 1. Disable private keys export in Electrum Segwit wallets, until a
> common WIF extension has been agreed on.
> 2. Define my own WIF extension for Electrum, and go ahead with it.
>
> Defining my own format does make sense for the xpub/xprv format, because
> Electrum users need to share master public keys across Electrum wallets.
> It makes much less sense for WIF, though, because WIF is mostly used to
> import/sweep keys from other wallets.
>
> I would love to know what other wallet developers are going to do,
> especially Core. Are you going to export private keys used in segwit
> scripts in the current WIF format?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113df360481b9f055963a5aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi I have a small interjection about the point on err=
or correction (excuse me if it seems elementary). Isn't there an argume=
nt to be made where a wallet software should never attempt to figure out th=
e 'correct' address, or in this case private key? I don't think=
it's crazy to suggest somebody could import a slightly erroneous WIF, =
the software gracefully error-corrects any problem, but then the user copie=
s that error onward such as in their backup processes like a paper wallet. =
I always hate to advocate against a feature, I'm just worried too much =
error correcting removes the burden of exactitude and attention of the user=
(eg. "I know I can have up to 4 errors").</div><div><br></div><d=
iv>I'm pretty sure I read those arguments somewhere in a documentation =
or issue tracker/forum post. Maybe I'm misunderstanding the bigger pict=
ure in this particular case, but I was just reminded of that concept (even =
if it only applies generally).</div><div><br></div><div>Thanks,</div><div>A=
J West</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Sun, Sep 17, 2017 at 4:10 AM, Thomas Voegtlin via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On 17.09.2017 04:29, Piete=
r Wuille wrote:<br>
><br>
> This has been a low-priority thing for me, though, and the computation=
work<br>
> to find a good checksum is significant.<br>
><br>
<br>
</span>Thanks for the info. I guess this means that a bech32 format for pri=
vate<br>
keys is not going to happen soon. Even if such a format was available,<br>
the issue would remain for segwit-in-p2sh addresses, which use base58.<br>
<br>
The ambiguity of the WIF format is currently holding me from releasing a<br=
>
segwit-capable version of Electrum. I believe it is not acceptable to<br>
use the current WIF format with segwit scripts; that would just create<br>
technological debt, forcing wallets to try all possible scripts. There<br>
is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it<br>
makes it unambiguous.<br>
<br>
I see only two options:<br>
=C2=A01. Disable private keys export in Electrum Segwit wallets, until a<br=
>
common WIF extension has been agreed on.<br>
=C2=A02. Define my own WIF extension for Electrum, and go ahead with it.<br=
>
<br>
Defining my own format does make sense for the xpub/xprv format, because<br=
>
Electrum users need to share master public keys across Electrum wallets.<br=
>
It makes much less sense for WIF, though, because WIF is mostly used to<br>
import/sweep keys from other wallets.<br>
<br>
I would love to know what other wallet developers are going to do,<br>
especially Core. Are you going to export private keys used in segwit<br>
scripts in the current WIF format?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a113df360481b9f055963a5aa--
|
