diff options
| author | AJ West <ajwest@gmail.com> | 2017-09-17 10:42:52 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-17 14:43:18 +0000 |
| commit | a233bed432d3b17e95df475c45bb2a0fc7e5ef4b (patch) | |
| tree | b28b94ed0eae63ab22c4d78f0d7c14012f35c413 | |
| parent | 625aaffbcea4e30454cb6fac1f5183cd0bfa4345 (diff) | |
| download | pi-bitcoindev-a233bed432d3b17e95df475c45bb2a0fc7e5ef4b.tar.gz pi-bitcoindev-a233bed432d3b17e95df475c45bb2a0fc7e5ef4b.zip | |
Re: [bitcoin-dev] proposal: extend WIF format for segwit
| -rw-r--r-- | 71/907ee15899a87ef3e717b32356c15870d785da | 208 |
1 files changed, 208 insertions, 0 deletions
diff --git a/71/907ee15899a87ef3e717b32356c15870d785da b/71/907ee15899a87ef3e717b32356c15870d785da new file mode 100644 index 000000000..fe1ffa948 --- /dev/null +++ b/71/907ee15899a87ef3e717b32356c15870d785da @@ -0,0 +1,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-- + |