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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 975BFB4A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 10:29:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id F1B841BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 10:29:31 +0000 (UTC)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net
[217.70.183.198])
by slow1-d.mail.gandi.net (Postfix) with ESMTP id 6F57F47B2A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 12:25:22 +0200 (CEST)
X-Originating-IP: 178.19.221.38
Received: from [10.10.42.98] (unknown [178.19.221.38])
(Authenticated sender: thomasv@electrum.org)
by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id EF471FB8CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Sep 2017 12:25:18 +0200 (CEST)
From: Thomas Voegtlin <thomasv@electrum.org>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <43636dd6-ab9e-da15-59ae-f31eb11ff7ff@electrum.org>
Date: Tue, 5 Sep 2017 12:25:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [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 10:29:32 -0000
BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)
I would like to use additional version bytes to indicate the type of
output script used with the public keys.
I believe the change should be user visible, because users are exposed
to master public keys. I propose the following prefixes:
========== =========== ===================================
Version Prefix Description
========== =========== ===================================
0x0488ade4 xprv P2PKH or P2SH
0x0488b21e xpub P2PKH or P2SH
0x049d7878 yprv (P2WPKH or P2WSH) nested in P2SH
0x049d7cb2 ypub (P2WPKH or P2WSH) nested in P2SH
0x04b2430c zprv P2WPKH or P2WSH
0x04b24746 zpub P2WPKH or P2WSH
========== =========== ===================================
(source: http://docs.electrum.org/en/latest/seedphrase.html)
I have heard the argument that xpub/xprv serialization is a format for
keys, and that it should not be used to encode how these keys are used.
However, the very existence of version bytes, and the fact that they are
used to signal whether keys will be used on testnet or mainnet goes
against that argument.
If we do not signal the script type in the version bytes, I believe
wallet developers are going to use dirtier tricks, such as the bip32
child number field in combination with bip43/bip44/bip49.
Thomas
|
