Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C1B6A84 for ; Thu, 7 Sep 2017 20:39:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 291AC1D7 for ; Thu, 7 Sep 2017 20:39:20 +0000 (UTC) X-Originating-IP: 77.179.200.97 Received: from [192.168.1.26] (x4db3c861.dyn.telefonica.de [77.179.200.97]) (Authenticated sender: thomasv@electrum.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B613BA80DF for ; Thu, 7 Sep 2017 22:39:18 +0200 (CEST) To: "bitcoin-dev@lists.linuxfoundation.org" References: <0d405f5d-c0a4-bad7-b6c3-08ba4424bf17@satoshilabs.com> <8b4831a4-791e-c03e-baa4-16d9e5ead442@electrum.org> <84f4a4b8-fcbd-433b-9556-174ec5475f61@satoshilabs.com> From: Thomas Voegtlin Message-ID: <9e74dc17-105c-b43c-7780-4fa690043fe2@electrum.org> Date: Thu, 7 Sep 2017 22:39:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <84f4a4b8-fcbd-433b-9556-174ec5475f61@satoshilabs.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW autolearn=disabled 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: Extended serialization format for BIP-32 wallets 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: Thu, 07 Sep 2017 20:39:20 -0000 On 07.09.2017 18:23, Pavol Rusnak wrote: > On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote: >> A solution is still needed to wallets who do not wish to use BIP43 > > What if we added another byte field OutputType for wallets that do not > follow BIP43? > > 0x00 - P2PKH output type > 0x01 - P2WPKH-in-P2SH output type > 0x02 - native Segwit output type > > Would that work for you? > > The question is whether this field should be present only if depth==0x00 > or at all times. What is your suggestion, Thomas? > well, in my initial proposal, I wrote that this value should be user visible. That is why I used version bytes. If you create an extra byte field, and then use base58 or bech32 encoding, the value will not be user visible anymore. The initial implementation of segwit xpub/xprv in Electrum used a flag that was not user visible (I added 1 to the bip32 version bytes, which leaves the xpub/xprv prefix unchanged). I have experimented with that invisible flag for more than 6 months now, and I am now convinced that it is better to make that flag user visible. The reason is that when users create wallets with multisig scripts, they need to combine several master public keys. However, these master public keys should all be of the same type: it would not make sense to create a 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By imposing that all master keys are of the same type, we ensure that all cosigners agree on the script type that will be used to derive addresses. In other words, if users are exposed to master keys and need to manipulate them, it is better to let them see what they are doing. OTOH if you do not plan to expose your users to these keys, you probably do not need a serialization format.