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 552BF884 for ; Sun, 15 May 2016 17:36:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.161.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 618A11A4 for ; Sun, 15 May 2016 17:36:55 +0000 (UTC) Received: by mail-yw0-f178.google.com with SMTP id o66so163373701ywc.3 for ; Sun, 15 May 2016 10:36:55 -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; bh=+pNIc2nAWm7oTHuPd5H4Djjy7a4W+nnAcgHlI1jtF10=; b=PrdxZvSKL2NcHcLraCnM4yqlIKWzA4YkoFRMTtiHfx0MipfqCCgQpm/qdN3WBnFvot ql3SPGEtfQlM8nUHG2upUOmNZY29ovgHli1wB2TIaydwnRjO1ZFdRByaQ5atif9V6TPd lkr/bsmjPYHjDuJHbLtsozupPqrLp03XlO44ddpAhuwcsN7iGxfU7+mcrJ+t61R2Qs54 BH6R6wv5dAe3sObGEcdWaINMEaunklRoKRF0UaHnOqI8wafHHo7dTPNjrVUgLatzugNq Meaees+Fogw6axOPIJqEFYwqgoRyXWcA38W82xey8DcUlkGQnUWTN2ThNbnLSwQOS8Bs lCLg== 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; bh=+pNIc2nAWm7oTHuPd5H4Djjy7a4W+nnAcgHlI1jtF10=; b=WlzRZz1oxuVoYSCHK/7ikO9kPmlaHqkeVPcd+Gpxdx8DDvRI75lUCisjqXza9jUXJl 5mxM2GU+xS5f9VxVsmBwwL/3e9pm3+df/wL68yAuparieAY9veBd6k9nFggWdVWk1+hq fpXSeKB3pJNWaZxsFikaQVoCXh30XRtyuzMiPTB8eh+V0mYmVuxIYFGDmwUpC52iPto+ Lwvl27HstzFRt+m+Qhgq+b/a5cWNh/gKr7NzcJrgp9os5nxwsG7Umm9N/Y6oX7HukG9y ntYh4/YIB3pjQYY0nwzWM2eEZQR32LBgX0BNQhaue+hQMLwW+IHWfnByFKCnLdRoUBdk qu1A== X-Gm-Message-State: AOPr4FWtkPPIHPfAT/82BKED3lqY/QeEiMC2op9J7TWJuQbuSL4zvTgaM4T0yyL9CuLwHEV5NRIV3IjrPJ5M9w== MIME-Version: 1.0 X-Received: by 10.37.210.201 with SMTP id j192mr12325634ybg.144.1463333814495; Sun, 15 May 2016 10:36:54 -0700 (PDT) Received: by 10.13.233.2 with HTTP; Sun, 15 May 2016 10:36:54 -0700 (PDT) In-Reply-To: <573866AE.9070205@mycelium.com> References: <5735D3A4.7090608@mycelium.com> <5735EC17.5040901@satoshilabs.com> <573866AE.9070205@mycelium.com> Date: Sun, 15 May 2016 10:36:54 -0700 Message-ID: From: Aaron Voisine To: Daniel Weigl , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c065a3833751a0532e4f488 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 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: Sun, 15 May 2016 17:36:56 -0000 --94eb2c065a3833751a0532e4f488 Content-Type: text/plain; charset=UTF-8 On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > 0x40000000 would be the next available to specify witness addresses. > > This is compatible with existing accounts and wallet layouts. > > my main concern here is that > -) every Bip-compatible wallet in the future will have to > implement all (then probably) legacy derivation and tx schemes. > I can see the advantage of a segwit only scheme, but we will need to support old derivations anyway for many decades if not indefinitely. People are using it to store value for the long term. > -) it does not fail in a deterministic way, if I import a seed or > xPriv/xPub across different capable wallets. > It is more visible if one account has [no funds/does not show up] > at all after an import than if something shows up but you need to make sure > that the balance is what you might expect. > This is certainly a downside. It has to be weighed against the benefit of being able to upgrade existing wallets in place. Asking users to create a new wallet, and replace their recovery phrase backups is an even bigger problem in my estimation. What do you think of doing both? A new BIP43 purpose number for segwit only wallets, but that also specifies 0x40000000/1 for the change/receive index so that the scheme is compatible with other schemes for upgrade existing wallets in place? There will certainly be wallet developers who decide to upgrade in place, but we can standardized both how to indicate segwit chains, independent of segwit only schemes or upgrade schemes, and still have the advantages of a new segwit only BIP43 purpose number. Aaron Voisine co-founder and CEO breadwallet --94eb2c065a3833751a0532e4f488 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 15, 201= 6 at 5:08 AM, Daniel Weigl via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:

> 0x40000000 would be the next available to specify witness addresses. > This is compatible with existing accounts and wallet layouts.

my main concern here is that
=C2=A0-) every Bip<this-bip>-compatible wallet in the future will hav= e to implement all (then probably) legacy derivation and tx schemes.

I can see the advantage of a segwit only sche= me, but we will need to support old derivations anyway for many decades if = not indefinitely. People are using it to store value for the long term.
=C2=A0
=C2=A0-) it does not fail in a deterministic way, if I import a seed or xPr= iv/xPub across different capable wallets.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 It is more visible if one account has [no funds= /does not show up] at all after an import than if something shows up but yo= u need to make sure that the balance is what you might expect.

This is certainly a downside. It has to be weighed = against the benefit of being able to upgrade existing wallets in place. Ask= ing users to create a new wallet, and replace their recovery phrase backups= is an even bigger problem in my estimation.=C2=A0

What do you think of doing both? A new BIP43 purpose number for segwit onl= y wallets, but that also specifies 0x40000000/1 for the change/receive inde= x so that the scheme is compatible with other schemes for upgrade existing = wallets in place? There will certainly be wallet developers who decide to u= pgrade in place, but we can standardized both how to indicate segwit chains= , independent of segwit only schemes or upgrade schemes, and still have the= advantages of a new segwit only BIP43 purpose number.

=
Aaron Voisine
co-founder and CEO
breadwallet
<= /div> --94eb2c065a3833751a0532e4f488--