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
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ACA4A98C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 15:36:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com
[209.85.192.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AF643F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 15:36:51 +0000 (UTC)
Received: by mail-pf0-f182.google.com with SMTP id q76so3637740pfq.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2017 08:36:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=iNnz39A8EvUTEsMmGU4hPBjwwL96uILD9heyMl4ohwY=;
b=AJW04CSKgvkvxj7C/yJXHSPFwdQXXDZG4++P5LNrMMvyRbg6grZRvlFJsnMNyulDVp
BC2dhgjfZQpr0u/gS2spqtOVs2XWTG3nXl2FyxO+7ZlwI+95iTElRazZ3FQZGSKheItO
TD5UMNNsKGseENWCx+kFfmRP2iqJWrw6PxB7lEXE35fki59yzF47H++k62PwSQxuzGdF
PhEP8L1U78WhRuJAlhUIT3MlNOW/x+m7NyOglZz/han1IlXcYpV+Xl9F1SxbYBvZgMZr
fMYlFkP15X7M/pgJxact+027is6dXucA3EiA5Dj71wJQb8qYGw/jcPcoY4bdEdZaerP2
vjvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=iNnz39A8EvUTEsMmGU4hPBjwwL96uILD9heyMl4ohwY=;
b=q4bLfTP+IRhnAJJ/cEukfGEVn9qBcbiU1cMIJFMDPZffhyl1Z1cFwLJC/F4OjUFq7X
FXz7vx+nfUxphIeDbtiamcLJ0K4NZ+PRZilVij3PKQIePjqGtpyJhDkrTdrPQpmi/hiI
YPSaPe2DHCGuYf31KyluoKeVJtqBPK2lGt4hv69jUONWl9CZW7PkDUQzgj00MKKi2cBz
b6HMKyyBOiHNC8eqNUW+lVsYSAqXCDKFdY4YVg4oVZbB7SuHzektejsOxio8+b+2dpWH
8NmxE7QC5Fm3RQWR7uA3cN8AZ1pWZnukoYgnq54mHTgv1uN9rOIJ8UHxUWMHcYBSxSOq
bocA==
X-Gm-Message-State: AHPjjUjcq5UXHm1FKvz4j6vgDdMCsm4PpB2lQBPXsu6kBLx8uY+ZuftX
14hynPvL3bg+gT1N
X-Google-Smtp-Source: ADKCNb5PWzDK8DSlS+lJkCGwGL/eeJOV6MWnH07y/0ddDxmLIXGZGqyOQ83N2C6yY4oqisEzr1kQIQ==
X-Received: by 10.98.158.26 with SMTP id s26mr29193547pfd.284.1505662610765;
Sun, 17 Sep 2017 08:36:50 -0700 (PDT)
Received: from ?IPv6:2607:fb90:8256:9233:980a:d5bd:d807:76eb?
([2607:fb90:8256:9233:980a:d5bd:d807:76eb])
by smtp.gmail.com with ESMTPSA id
u31sm9908596pgn.70.2017.09.17.08.36.49
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 17 Sep 2017 08:36:49 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-B8104D8E-3CB1-4523-AC5D-D06284394BA9
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CABXVU6YKLwr-zev_=AmGDqwZ6ZkMwa=2ooPoDWv22XU8-QzajA@mail.gmail.com>
Date: Sun, 17 Sep 2017 08:36:48 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <0071EC0D-44D4-47D0-8211-2158B288CC19@friedenbach.org>
References: <34198916-cde9-c84d-ca41-9feb8956bd80@electrum.org>
<CAPg+sBgukwdRvfFcgdusrXoo8RiXm8OEL-WvHzjpiD8_HU5KmQ@mail.gmail.com>
<0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org>
<CABXVU6YKLwr-zev_=AmGDqwZ6ZkMwa=2ooPoDWv22XU8-QzajA@mail.gmail.com>
To: AJ West <ajwest@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
HTML_MESSAGE,MIME_QP_LONG_LINE,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 15:40:43 +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 15:36:55 -0000
--Apple-Mail-B8104D8E-3CB1-4523-AC5D-D06284394BA9
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Bech32 and WIF payload format are mostly orthogonal issues. You can design a=
new wallet import format now and later switch it to Bech32.
> On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>=20
> 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 wall=
et software should never attempt to figure out the 'correct' address, or in t=
his case private key? I don't think it's crazy to suggest somebody could imp=
ort a slightly erroneous WIF, the software gracefully error-corrects any pro=
blem, but then the user copies that error onward such as in their backup pro=
cesses 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").
>=20
> I'm pretty sure I read those arguments somewhere in a documentation or iss=
ue 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 a=
pplies generally).
>=20
> Thanks,
> AJ West
>=20
>> 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 w=
ork
>> > to find a good checksum is significant.
>> >
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-B8104D8E-3CB1-4523-AC5D-D06284394BA9
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Bech32 and WIF payload format are most=
ly orthogonal issues. You can design a new wallet import format now and late=
r switch it to Bech32.</div><div><div><br></div>On Sep 17, 2017, at 7:42 AM,=
AJ West via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div>=
<blockquote type=3D"cite"><div><div dir=3D"ltr"><div>Hi I have a small inter=
jection about the point on error correction (excuse me if it seems elementar=
y). Isn't there an argument to be made where a wallet software should never a=
ttempt to figure out the 'correct' address, or in this case private key? I d=
on't think it's crazy to suggest somebody could import a slightly erroneous W=
IF, the software gracefully error-corrects any problem, but then the user co=
pies 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 err=
or 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><div>I'm pretty s=
ure I read those arguments somewhere in a documentation or issue tracker/for=
um post. Maybe I'm misunderstanding the bigger picture in this particular ca=
se, but I was just reminded of that concept (even if it only applies general=
ly).</div><div><br></div><div>Thanks,</div><div>AJ West</div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Sep 17, 2017 at 4:1=
0 AM, Thomas Voegtlin via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">On 17.09.2017 04:29, Pieter Wuille wrote:<br>
><br>
> This has been a low-priority thing for me, though, and the computation w=
ork<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 priv=
ate<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>
1. Disable private keys export in Electrum Segwit wallets, until a<br>=
common WIF extension has been agreed on.<br>
2. 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" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=
--Apple-Mail-B8104D8E-3CB1-4523-AC5D-D06284394BA9--
|