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 1FBB2D1C for ; Wed, 4 Apr 2018 06:06:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9693456 for ; Wed, 4 Apr 2018 06:06:43 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 3186D14C0BF for ; Wed, 4 Apr 2018 15:06:42 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 4 Apr 2018 15:06:42 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 262CB4C079 for ; Wed, 4 Apr 2018 15:06:42 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw25.oz.hdemail.jp (ip-10-125-14-250.ap-northeast-1.compute.internal [10.125.14.250]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 23F6214C0BF for ; Wed, 4 Apr 2018 15:06:42 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qt0-f200.google.com (lb06.oz.hdemail.jp [54.238.50.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw25.oz.hdemail.jp (Postfix) with ESMTP id 85ABE148C13D for ; Wed, 4 Apr 2018 15:06:41 +0900 (JST) X-Received: by mail-qt0-f200.google.com with SMTP id w2so6247514qti.8 for ; Tue, 03 Apr 2018 23:06:41 -0700 (PDT) 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=xETn43RMCRAhSH8V0/SO6JIsFiczZY2CkwvVcHg5sLA=; b=crhp7ayk+wTNTvZTtsyKhb8Ko9utp7O8y+MzMlfwPpDIMxu4sP6ARLCxxYqZwwOd+0 ePBUmhu6nmmCLbII22wBSDq+7MdcVb3agdCrlQuxqc2lN3ks1QVWOco1uQcB2kTZ2acq 6FFVaPtWPLWfNYhfpGLMzh8OStPPSGA//noNUGFBBxKloN+2c9Sgre4WKbZ9nHBbPV1S Y2Aq5lO8ZNR5qgvX6y2IvbG/zecTptGRNj9e4wUPFaOFJ2/M6PJmonBhbNB2C/tObOGy 6vUneVeSOAejgWuq0a+ErTxTD6y8yqTFho3xE1Iz9+MUmJV+LpUbsivMFg2j5RyrNst9 Jptw== X-Gm-Message-State: ALQs6tCOdnf3m6w3eLf0/XPDHlv0Azjr7k4ewcNVy2usyedNFyn+yCwG PCAO0acZEXCaOVEhRrFigauqrpELR2+4+sGiGoeDDW1UnAZLJFKV920yMfPDeQcqmWIy1wks5Xg cVVrCA2BiNg5E0ujyZWdoD8OUI8N8VGHHqg4zR56SpGx8g4EAVQxpJuDYoyvhL28Kbcr2wRofTM l0OUbnQLvfsxkW9KZKVMni8Y9vKwhdeIRKREmL2TtnW5eGa+YuQPZzoj/+8rgeWeiH/kJiyx/oA 1gWZfXbUpYumoSR9dIX24pMy8THDz09lhhFmIhxGawYQdtwrrQf3XBuBSU8eJvxN3g4DMNt5bmY y8N8BlRNrERT4lXJFOuB2n8y1oE= X-Received: by 10.55.31.17 with SMTP id f17mr21588382qkf.266.1522821999898; Tue, 03 Apr 2018 23:06:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+0yila4ZHVRMNfyrUVsfvLryZXY7OZHPxisv9wIH3emEybu1bXkT5lnYA/PhvJeE2eh/yfEiDb7Fy9KB/ZZgg= X-Received: by 10.55.31.17 with SMTP id f17mr21588351qkf.266.1522821999429; Tue, 03 Apr 2018 23:06:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.12.208.26 with HTTP; Tue, 3 Apr 2018 23:06:19 -0700 (PDT) In-Reply-To: <0071EC0D-44D4-47D0-8211-2158B288CC19@friedenbach.org> References: <34198916-cde9-c84d-ca41-9feb8956bd80@electrum.org> <0dc0336b-d590-ffe9-8689-6ae06e98a39d@electrum.org> <0071EC0D-44D4-47D0-8211-2158B288CC19@friedenbach.org> From: Karl Johan Alm Date: Wed, 4 Apr 2018 15:06:19 +0900 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Wed, 04 Apr 2018 06:06:45 -0000 I took the liberty of turning this into a BIP proposal -- the formatted version can be seen here: https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki 
  BIP: XXX
  Layer: Applications
  Title: Typed Private Keys
  Author: Karl-Johan Alm 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
  Status: Draft
  Type: Standards Track
  Created: 2018-04-04
  License: CC0-1.0
== Abstract == An extension to the private key (WIF) format to specify what kind of public key the private key corresponds to. == Motivation == There are several types of public keys which can all be associated with a given private key: P2PKH (legacy 1... format), P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc. While private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (0x01) or not (0x00), there is no way of knowing what kind of public keys were associated with the private key. As a result, when importing a private key, the wallet has to assume all kinds, and keep track of each possible alternative. By extending the suffix, we can specify what kind of public key was associated with the given private key. == Specification == Currently, private keys are stored as a uint256 (private key data) followed by a uint8 (compressed flag). The latter is extended to specify the public key types: {|class="wikitable" style="text-align: center;" |- !Value !Type !Compr !Clarification |- |0x00||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public key. Unknown public key format |- |0x01||P2PKH_COMPRESSED||Yes||Compressed legacy public key. Unknown public key format |- |0x80||P2PKH||Yes||Compressed legacy public key. Legacy public key format (1...) |- |0x81||P2WPKH||Yes||Bech32 format (native Segwit) |- |0x82||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH (3...) |- |0x85||P2SH|| — ||Non-Segwit BIP16 P2SH (3...) |- |0x86||P2WSH|| — ||Native Segwit P2SH |- |0x87||P2WSH_P2SH|| — ||Native Segwit P2SH nested in BIP16 P2SH |} When a wallet imports a private key, it will have two outcomes: * the key is using one of the legacy types, in which case all types must be accounted for * the key is using one of the extended types, in which case the wallet need only track the specific corresponding public key == Rationale == TODO == Compatibility == This proposal is not backwards compatible, in that software that does not recognize the new types will not understand the compressed flag. It would be trivial to change this, by keeping the 'uncompressed' state as it is (0) and changing 'compressed' to be 'anything not 0', as opposed to 'the value 1'. The proposal *is* backwards compatible in that new wallet software will always understand the old WIF format, however. It will, as it does today, assume that any kind of public key is possible, and will have to track all of them, as it has to today. == Acknowledgements == This BIP is based on the initial proposal by Thomas Voegtlin on the Bitcoin Dev mailing listhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html and the Electrum 3.0 implementationhttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108 == Reference implementation == There is a partial implementation which adds, but does not use, the types described in this BIP here: https://github.com/bitcoin/bitcoin/pull/12869 == References == == Copyright == This document is licensed under the Creative Commons CC0 1.0 Universal license. On Mon, Sep 18, 2017 at 12:36 AM, Mark Friedenbach via bitcoin-dev wrote: > 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: > > 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 > 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >