MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] proposal: extend WIF format for segwit
Precedence: list

--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&#39;t there an argume=
nt to be made where a wallet software should never attempt to figure out th=
e &#39;correct&#39; address, or in this case private key? I don&#39;t think=
 it&#39;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&#39;m just worried too much =
error correcting removes the burden of exactitude and attention of the user=
 (eg. &quot;I know I can have up to 4 errors&quot;).</div><div><br></div><d=
iv>I&#39;m pretty sure I read those arguments somewhere in a documentation =
or issue tracker/forum post. Maybe I&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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>
&gt;<br>
&gt; This has been a low-priority thing for me, though, and the computation=
 work<br>
&gt; to find a good checksum is significant.<br>
&gt;<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--