From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3027240A for ; 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 ; Sun, 17 Sep 2017 14:43:13 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id 199so3652488oii.11 for ; 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> <0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org> From: AJ West Date: Sun, 17 Sep 2017 10:42:52 -0400 Message-ID: To: Thomas Voegtlin , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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").

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).

Thanks,
A= J 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, Piete= r 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 pri= vate
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:
=C2=A01. Disable private keys export in Electrum Segwit wallets, until a common WIF extension has been agreed on.
=C2=A02. 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--