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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Return-Path: <kabuto@samouraiwallet.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 243E77A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 19:00:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com
[209.85.215.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52592406
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 19:00:47 +0000 (UTC)
Received: by mail-lf0-f46.google.com with SMTP id q132so12872357lfe.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 05 Sep 2017 12:00:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=samouraiwallet-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=4Uubnw5g/fKdrvobW0iF3B/+m/zy1sh0p95+QaHiguw=;
b=OdO0y7XGzM2Bq3OIz6XAFPaTZ2w/1a2xW3dCu9W9+E/FqWn5VDUfDBgLtfkb0to+N7
FTOZzlgguB4EXBMr4VsswqrbY/dXt1RLFjEpniL5xbD7/HiJP8VYTkPbYftlSopoeSgd
+nmTq75vQZ/3e8uGBGIZaFoW4cXpQTcrkWAokJlOzTuxylmYJK4bITzmL60Oxf4HbLy0
zj2GLQAiWnxShjA/wGKtiDfGJ6efSe+ny91ZSGu4jI5HACEB27jb/1UMZJG/eW/N0LdM
bVpsp5HWKhVnQaX1KOsJVuuppQ9ATHTvZKKmsfVrRJRyO277pmm9r+TmCcR/ByAwXEqX
t5PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=4Uubnw5g/fKdrvobW0iF3B/+m/zy1sh0p95+QaHiguw=;
b=ZmdjSfs8rSmiGSwKNe5DY2bOR27lRi3jpZkk7numoSx07bqx5mUAh2Oq5betl/V7CN
pNektHRg5KaijznOa14svRsOQxjh5y+RtprOckif1b05chPEgDMdtkDgWP6y9QT6VSOg
nRRXhKO+Q+3qr4warsXXvZE6NkX0CoyMpFcsAUMVxAW1hP6e1IDSgYK07Sauo3QdhvIE
iu5UKYoUMZTSWfk15rhx0kIRwCdJTmKXI9qKva0M/oLBFK3nqnbOB5jXQN8J/futT+of
9trVsQBW3r0rVv2HBQsczA/s8EUfT31jTjb4ELoLpevanRgwgxXU69qRWBsMWLsiCIEz
pqww==
X-Gm-Message-State: AHPjjUjDLRzedzjr5jRHbn4zEahrsEA5H2WCLgjM88kO7Ff14FYr87Wr
A5cIqldOavDb021oJFFhu70EY354PxID
X-Google-Smtp-Source: ADKCNb5nfxXyEfMyzNVwVJrdsN+aX2nH4GPrsxlPNNMFxuKFX+nUofxB2BEI9xS/+a/6sCRrLFaRqc0jvgqS9Luc6qw=
X-Received: by 10.46.69.134 with SMTP id s128mr11200lja.161.1504638045509;
Tue, 05 Sep 2017 12:00:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.148.23 with HTTP; Tue, 5 Sep 2017 12:00:04 -0700 (PDT)
From: Kabuto Samourai <kabuto@samouraiwallet.com>
Date: Tue, 5 Sep 2017 14:00:04 -0500
Message-ID: <CA+_kfXJPfbGD6cDiPZ+7Z_rwUVS6JQNW8Vb-YsgD2wsPhHoBjw@mail.gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114b0f8e37efcc055875d899"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 05 Sep 2017 23:47:33 +0000
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
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: Tue, 05 Sep 2017 19:00:48 -0000
--001a114b0f8e37efcc055875d899
Content-Type: text/plain; charset="UTF-8"
We support a change to the version bits of the HD serialization that will
inform the receiving utility of the exact derivation method used for the
pubkeys. Third-parties handling xpubs must not require additional
information from the user about the derivation path or serialization format
of the addresses under that xpub. When you have to ask, "Is this a SegWit
xpub?" then you've already lost.
Avoiding a total UX nightmare is in everyone's interests.
I think Luke and Thomas may be talking past one another. When exporting a
root master HD seed, encoding the {x,y,z}{pub,prv} distinctions makes no
sense, as the root seed should derive all paths for all coins. Wallets may
need additional code to discover which paths have been used when importing
a root seed. But when exporting / importing an account-level seed for
watch-only and receive address generation, changing the serialization
version bytes is appropriate and (in our view) essential to avoid loss of
funds.
The Electrum approach is nice but may not go far enough, as xpub and zpub
both list "P2PKH or P2SH." Why not expand the number of version prefixes to
eliminate the ambiguity?
On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On 05.09.2017 19:03, Luke Dashjr wrote:
>
> > It seems desirable to use the same seed for all different script
> formats...
>
> That does not seem desirable to everybody.
>
> If you want to guarantee that users will be able to recover all their
> funds from their mnemonic seed (and that is what they expect), then
> wallets must implement all script formats, even the ones that are
> deprecated. In addition, the list of script formats that must be
> supported is not defined in advance, but it keeps growing. This makes
> wallet implementation increasingly difficult. In the long run, seed
> portability is guaranteed to fail in such a system.
>
> > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> > really doesn't make sense to differentiate segwit specifically.
>
> That's not a reason. The fact that xpub/xprv can be used for both P2PKH
> and P2SH has already resulted in users receiving coins on addresses they
> do not control.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-Kabuto
PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99
--001a114b0f8e37efcc055875d899
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>We support a change to the version bits of the HD ser=
ialization that will inform the receiving utility of the exact derivation m=
ethod used for the pubkeys. Third-parties handling xpubs must not require a=
dditional information from the user about the derivation path or serializat=
ion format of the addresses under that xpub. When you have to ask, "Is=
this a SegWit xpub?" then you've already lost.<br></div><div><br>=
</div><div>Avoiding a total UX nightmare is in everyone's interests.</d=
iv><div><br></div><div>I think Luke and Thomas may be talking past one anot=
her. When exporting a root master HD seed, encoding the {x,y,z}{pub,prv} di=
stinctions makes no sense, as the root seed should derive all paths for all=
coins. Wallets may need additional code to discover which paths have been =
used when importing a root seed. But when exporting / importing an account-=
level seed for watch-only and receive address generation, changing the seri=
alization version bytes is appropriate and (in our view) essential to avoid=
loss of funds.</div><div><br></div><div>The Electrum approach is nice but =
may not go far enough, as xpub and zpub both list "P2PKH or P2SH."=
; Why not expand the number of version prefixes to eliminate the ambiguity?=
</div><div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <span d=
ir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 05.09.2017 19:03, Luke Dashjr wrote:<br>
<br>
> It seems desirable to use the same seed for all different script forma=
ts...<br>
<br>
That does not seem desirable to everybody.<br>
<br>
If you want to guarantee that users will be able to recover all their<br>
funds from their mnemonic seed (and that is what they expect), then<br>
wallets must implement all script formats, even the ones that are<br>
deprecated. In addition, the list of script formats that must be<br>
supported is not defined in advance, but it keeps growing. This makes<br>
wallet implementation increasingly difficult. In the long run, seed<br>
portability is guaranteed to fail in such a system.<br>
<br>
> As you note, xpub\xprv are already being used for both P2PKH and P2SH.=
It<br>
> really doesn't make sense to differentiate segwit specifically.<br=
>
<br>
That's not a reason. The fact that xpub/xprv can be used for both P2PKH=
<br>
and P2SH has already resulted in users receiving coins on addresses they<br=
>
do not control.<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">-Kabuto</div><d=
iv dir=3D"ltr"><br></div><div><font size=3D"1">PGP Fingerprint:=C2=A01A83 4=
A96 EDE7 E286 2C5A =C2=A0B065 320F B934 A79B 6A99</font></div></div></div><=
/div>
</div></div>
--001a114b0f8e37efcc055875d899--
|
