1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <voisine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 552BF884
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 May 2016 17:36:55 +0000 (UTC)
Received: by mail-yw0-f178.google.com with SMTP id o66so163373701ywc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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>
<CACq0ZD4BvvCryYmO-J9Rof-ogQJ1wNLgmUEU596nuTH=-U8Hag@mail.gmail.com>
<573866AE.9070205@mycelium.com>
Date: Sun, 15 May 2016 10:36:54 -0700
Message-ID: <CACq0ZD6boG_eFU+2eAiqduYq++E5ofH+VD7Gzvzh3jsemyqw8A@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Daniel Weigl <Daniel.Weigl@mycelium.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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<this-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 <http://breadwallet.com/>
--94eb2c065a3833751a0532e4f488
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
ure"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Sun, May 15, 201=
6 at 5:08 AM, Daniel Weigl via bitcoin-dev <span dir=3D"ltr"><<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>></span> wrote:<br></div></div></div></di=
v></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><br>
> 0x40000000 would be the next available to specify witness addresses.<b=
r>
> This is compatible with existing accounts and wallet layouts.<br>
<br>
</span>my main concern here is that<br>
=C2=A0-) every Bip<this-bip>-compatible wallet in the future will hav=
e to implement all (then probably) legacy derivation and tx schemes.<br></b=
lockquote><div><br></div><div>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.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">
=C2=A0-) it does not fail in a deterministic way, if I import a seed or xPr=
iv/xPub across different capable wallets.<br>
=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.<br></blockqu=
ote><div><br></div><div>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</div><div><br></div><div=
>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.</div><div><br></div>=
<div><div>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://b=
readwallet.com/" target=3D"_blank">breadwallet</a></div></div></div></div><=
/div>
--94eb2c065a3833751a0532e4f488--
|
