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
|
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 64D93BBC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 13:48:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEF1F127
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Sep 2017 13:48:02 +0000 (UTC)
Received: by mail-lf0-f45.google.com with SMTP id d17so17868147lfe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 06 Sep 2017 06:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=samouraiwallet-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=1MuFQcexd84SHrikHUrcTcz/DcwcUJMEZU2XZEEDDPM=;
b=cIRNmDWTBzwfQCiaVUeXS5NOtMtUszVofF6aRqZCzzSYAJPH5/R2KnUxDoYtcVHYX/
4/84EhNkjoi4JP+SjftXSnn5/ONOo4T7U0xITZOdr5cIj+mF9sxx8Y5ngxGE4dS01eZH
r5WE1udXh9X09yVPsTKFEcy91LNry9Bj+ZxPPVYtxI/qufFxMFowQlHXMMeKOpPcJiyx
9ub9Al0rvL3zI+kkEi2NyLyDkq9hUV5QqsR53uTN6vqgKDBGhe2WlxTjAE+JUA/ck3RB
7PrXjqseHrq9vkd99LMFKnmkIJaxtpv1HUcTvZFzbVsWvZTuzK18gFDS57EZJXFnwjRH
8gQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=1MuFQcexd84SHrikHUrcTcz/DcwcUJMEZU2XZEEDDPM=;
b=swddJ6bKAUGZdoac0L29cZObuSt4oxBHcQsa20JmfiHaU60euovURUMF1NMRAdNFCY
9VXltdV5rrvPq/BWZWkrwirk4bNMK/CUgB/IrhwrlfaBN3jVqnjG+rr0QWzWEwxP8BCW
BN79FSTwYCscaWXS5Eb5ArkSDcNpW+bsxq8NKBFzSecuY7C3cXLhkcLAweSOhp1+fvXH
pzn3/S0ygTeVH2NDxvb+CT5BQu5DFi4KAvYDeITGlcqGHnBBUT8OyK+tGEs1uD3Wo6Mm
9miIO/xTXV0LrwLCJ4DzQnH4XmrOcWsg5isMGpt8qLCPGjC4UMTYV+m0kvceQ08k2im3
K5EA==
X-Gm-Message-State: AHPjjUiBP48cGV/4tTe+ywg4IgEe51ef1AysVx8hgmYO69Xz4fWe91D7
Hwy7SVOO4aIcZbARqdpQNSJDUthN1MXDqZJD7Q==
X-Google-Smtp-Source: ADKCNb5yN+KKo0HbTLqsUum2l6ccH6ImTjl+Szpp+0ZBddGIzig6VHyQTZMQT9G3zv8vLCddCQQOFCw/Zyi5kdSURfY=
X-Received: by 10.46.86.4 with SMTP id k4mr1073460ljb.8.1504705681116; Wed, 06
Sep 2017 06:48:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.148.23 with HTTP; Wed, 6 Sep 2017 06:47:20 -0700 (PDT)
In-Reply-To: <56a0c721-4bae-7b99-0ca3-d0834756fc31@electrum.org>
References: <CA+_kfXJPfbGD6cDiPZ+7Z_rwUVS6JQNW8Vb-YsgD2wsPhHoBjw@mail.gmail.com>
<56a0c721-4bae-7b99-0ca3-d0834756fc31@electrum.org>
From: Kabuto Samourai <kabuto@samouraiwallet.com>
Date: Wed, 6 Sep 2017 08:47:20 -0500
Message-ID: <CA+_kfXLO-bBoRR5fZeXXFz-Vi1w+jTEcp3VRCBfKXgijAkysOw@mail.gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1a60069d891305588597e6"
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: Wed, 06 Sep 2017 15:18:39 +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: Wed, 06 Sep 2017 13:48:06 -0000
--94eb2c1a60069d891305588597e6
Content-Type: text/plain; charset="UTF-8"
> In addition, consensus might be more difficult to reach on that
Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.
On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On 05.09.2017 21:00, Kabuto Samourai wrote:
> >
> > 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?
> >
>
> I agree that this would make sense if we had done it from the start.
> However, fixing that now might be difficult.
>
> My "xyz" proposal extends the current format in a way that is very easy
> to deploy, because existing software will require minimal changes.
> However, if we eliminate the p2sh ambiguity now, wallets will need to
> add extra safeguards, in order to prevent scenarios that are currently
> allowed, and they will need to handle legacy xpub/xprv differently than
> ypub and zpub. This would take much more time to deploy.
>
> In addition, consensus might be more difficult to reach on that; I guess
> not all developers will not agree that removing that ambiguity is
> useful. Since there is an infinity of possible P2SH scripts, it will
> never be possible to remove ambiguity from a master key associated to a
> P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
> strong.
> _______________________________________________
> 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
--94eb2c1a60069d891305588597e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">In addition, co=
nsensus might be more difficult to reach on that</span><div><br></div><div>=
<span style=3D"font-size:12.8px"></span>Let's move forward with the sim=
plest solution that solves the problem and achieves consensus! Version byte=
s {x,y,z} fits the bill.</div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitc=
oin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
<br>
On 05.09.2017 21:00, Kabuto Samourai wrote:<br>
><br>
> The Electrum approach is nice but may not go far enough, as xpub and z=
pub<br>
> both list "P2PKH or P2SH." Why not expand the number of vers=
ion prefixes to<br>
> eliminate the ambiguity?<br>
><br>
<br>
</span>I agree that this would make sense if we had done it from the start.=
<br>
However, fixing that now might be difficult.<br>
<br>
My "xyz" proposal extends the current format in a way that is ver=
y easy<br>
to deploy, because existing software will require minimal changes.<br>
However, if we eliminate the p2sh ambiguity now, wallets will need to<br>
add extra safeguards, in order to prevent scenarios that are currently<br>
allowed, and they will need to handle legacy xpub/xprv differently than<br>
ypub and zpub. This would take much more time to deploy.<br>
<br>
In addition, consensus might be more difficult to reach on that; I guess<br=
>
not all developers will not agree that removing that ambiguity is<br>
useful. Since there is an infinity of possible P2SH scripts, it will<br>
never be possible to remove ambiguity from a master key associated to a<br>
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as<br>
strong.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<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>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div><div dir=3D"ltr">-Kabuto</div><div dir=3D"ltr"><br></div><div=
><font size=3D"1">PGP Fingerprint:=C2=A01A83 4A96 EDE7 E286 2C5A =C2=A0B065=
320F B934 A79B 6A99</font></div></div></div></div>
</div>
--94eb2c1a60069d891305588597e6--
|
