Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ACA4A98C for ; 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 ; Sun, 17 Sep 2017 15:36:51 +0000 (UTC) Received: by mail-pf0-f182.google.com with SMTP id q76so3637740pfq.2 for ; 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 X-Mailer: iPhone Mail (14G60) In-Reply-To: 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> <0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org> To: AJ West , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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.

On Sep 17, 2017, at 7:42 AM,= AJ West via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Thanks,
AJ West

On Sun, Sep 17, 2017 at 4:1= 0 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.
>

Thanks for the info. I guess this means that a bech32 format for priv= ate
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.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev

____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-B8104D8E-3CB1-4523-AC5D-D06284394BA9--