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 54A8C7D for ; Fri, 13 May 2016 16:03:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.161.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3FE7E8 for ; Fri, 13 May 2016 16:03:11 +0000 (UTC) Received: by mail-yw0-f182.google.com with SMTP id g133so106852601ywb.2 for ; Fri, 13 May 2016 09:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Mlh4umI4fkTir1WA9aTa/QJlVgXWMP8++WoQ0bdT4Ec=; b=PTI4dLw3n+SRjJU7Bfnixm5nJ65FhDmVPom36o/tMlHbJ1ovw0vuvsbnw1NlwtKw8K gAd53JjQYOdJHrVclMGPk3yqqw1v/QoEOFKHL1JzPvgUZlO5X5bvRv5jlB6FTbjk3Glt /eucHtrgE5mw8i5RpVjL3uek1o1NdQjhC8FYPwXI3yTwQpkfLQQKYnNwe6A8Z629bN7L RFxwYbYXjK1eVD+RDsKZpvEz3cU9lSmX3AVXHnjLjsNRehx7MhEo+gAPSQpvPviLl32j xA+DVB0Fxhqb61dz9W6asomsHVTE/4wIEKhEIKhPeFKrYecVZlmTWb5g+MScnQlxzKfx 9+bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Mlh4umI4fkTir1WA9aTa/QJlVgXWMP8++WoQ0bdT4Ec=; b=ciTMfd/gBfHSXoAnMP7jRydy8SfSc2OlEqAHMnm9H4Kiu41EpHUjEBMdhD8+vz6WtA 1DXR2N9wnvNfNMN01euWXfYuIbl6ZMya5xhT1UV39sgIcyrYx2AViHbVDRxfNytUeyvY MVNgMMGW8qq65TpPlK+qPOdAjyfgAqoYQiojjuGtNESqJhT3OXGbVrRVbAaeAGt1cSEQ Ss4vlCtkjEhyqp9HGUjOwP7Y3w0Xi9oPTGzre/WhYqy3w6mjupp8+mOkQ0r8asheBXIZ olX0GZUjYG8JpvHOUv77U/2z8es9WfLBcetf+5T9saxVeVT4xLyNXgg2UAt4qOLLjUD2 81hA== X-Gm-Message-State: AOPr4FUyHJ43lR4o6CeM9uXVxvBF++dv/arWWTBGe46LVQ8mEiKUO3EM9wCkx/M1r3vMtjc/ipR62PPqFmXGIw== MIME-Version: 1.0 X-Received: by 10.129.154.77 with SMTP id r74mr8676394ywg.91.1463155391229; Fri, 13 May 2016 09:03:11 -0700 (PDT) Received: by 10.13.233.2 with HTTP; Fri, 13 May 2016 09:03:11 -0700 (PDT) In-Reply-To: <5735EC17.5040901@satoshilabs.com> References: <5735D3A4.7090608@mycelium.com> <5735EC17.5040901@satoshilabs.com> Date: Fri, 13 May 2016 09:03:11 -0700 Message-ID: From: Aaron Voisine To: Pavol Rusnak , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0b8ce4587f710532bb6944 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 X-Mailman-Approved-At: Fri, 13 May 2016 16:05:59 +0000 Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/... 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: Fri, 13 May 2016 16:03:13 -0000 --94eb2c0b8ce4587f710532bb6944 Content-Type: text/plain; charset=UTF-8 We use the default BIP32 wallet layout, mentioned in BIP43 as purpose "0". We were thinking of of having 4 chains below the "account" level, the original 0 and 1 for receive and change addresses, and then 0x40000000 and 0x40000001 for P2WPKH-in-P2SH versions of receive and change addresses. I like the idea of specifying the type of address as a bit field flag. 0x80000000 is already used to specify hardened derivation, so 0x40000000 would be the next available to specify witness addresses. This is compatible with existing accounts and wallet layouts. As Daniel mentioned, the downside is that trying to recover on non-segwit software will miss segwit receives, however it does avoid the problem of having to check multiple address types for each key. Aaron Voisine co-founder and CEO breadwallet On Fri, May 13, 2016 at 8:00 AM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote: > > 2) Define a new derivation path, parallel to Bip44, but a different > 'purpose' (eg. ' instead of 44'). Let the user > choose which account he want to add ("Normal account", "Witness account"). > > We had quite a long discussion in our team some time ago and we agreed > on that option #2 is much better and we'd like to implement this way in > myTREZOR. > > > +) Wallet needs only to take care of 1 address per public key > > True, if this BIP only supports P2WPKH. > > P2WSH should probably be handled by another account type and another > BIP, anyway. > > > Has any Bip44 compliant wallet already done any integration at this > point? > > We have something in the pipeline, but no visible results yet. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > SatoshiLabs.com > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c0b8ce4587f710532bb6944 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We use the default BIP32 wallet layout, mentioned in BIP43= as purpose "0". We were thinking of of having 4 chains below the= "account" level, the original 0 and 1 for receive and change add= resses, and then 0x40000000 and 0x40000001 for P2WPKH-in-P2SH versions of r= eceive and change addresses.

I like the idea of specifyi= ng the type of address as a bit field flag. 0x80000000 is already used to s= pecify hardened derivation, so 0x40000000 would be the next available to sp= ecify witness addresses. This is compatible with existing accounts and wall= et layouts.

As Daniel mentioned, the downside is t= hat trying to recover on non-segwit software will miss segwit receives, how= ever it does avoid the problem of having to check multiple address types fo= r each key.

= Aaron Voisine
co-founder and CEO
breadwallet
=

On Fri, May 13, 2016 at 8:00 AM, Pavol Rusna= k via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
> 2) Define a new derivation path, parallel to Bip44, but a different=C2= =A0 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44= '). Let the user choose which account he want to add ("Normal acco= unt", "Witness account").

We had quite a long discussion in our team some time ago and we agre= ed
on that option #2 is much better and we'd like to implement this way in=
myTREZOR.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0+) Wallet needs only to take care of 1 addre= ss per public key

True, if this BIP only supports P2WPKH.

P2WSH should probably be handled by another account type and another
BIP, anyway.

> Has any Bip44 compliant wallet already done any integration at this po= int?

We have something in the pipeline, but no visible results yet.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com
_____________________= __________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--94eb2c0b8ce4587f710532bb6944--