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
|
Return-Path: <Daniel.Weigl@mycelium.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A99667D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2016 13:32:02 +0000 (UTC)
X-Greylist: delayed 00:15:38 by SQLgrey-1.7.6
Received: from mx.mycelium.com (mx.mycelium.com [188.40.34.2])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93B851D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2016 13:32:01 +0000 (UTC)
Received: from 178-189-162-17.adsl.highway.telekom.at ([178.189.162.17]
helo=[10.0.0.77])
by mx.mycelium.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.82) (envelope-from <Daniel.Weigl@mycelium.com>)
id 1b1CxF-0000Nh-HZ for bitcoin-dev@lists.linuxfoundation.org;
Fri, 13 May 2016 15:16:33 +0200
To: bitcoin-dev@lists.linuxfoundation.org
From: Daniel Weigl <Daniel.Weigl@mycelium.com>
Message-ID: <5735D3A4.7090608@mycelium.com>
Date: Fri, 13 May 2016 15:16:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -101.0 (---------------------------------------------------)
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 13 May 2016 14:02:02 +0000
Subject: [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: Fri, 13 May 2016 13:32:02 -0000
Hello List,
With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.
I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
In my opinion there are two(?) different options:
1) Stay with the current Bip44 account, give the user for each public key the option to show it as a P2PKH-Address or a P2SH address and also scan the blockchain for both representation of each public key.
+) This has the advantage, that the user does not need to decide or have to understand that he needs to migrate to a new account type
-) The downside is that the wallet has to scan/look for ever twice as much addresses. In the future when we have a P2WPKH, it will be three times as much.
-) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").
m / purpose' / coin_type' / account' / change / address_index
+) Wallet needs only to take care of 1 address per public key
+) If you use more than one wallet on the same xPub/xPriv it will work or fail completely. You will notice it immediately that there is something wrong
-) User has to understand that (s)he needs to migrate to a new account to get the benefits of SegWit
+) Thus, its easier to make a staged roll-out, only user actively deciding to use SegWit will get it and we can catch bugs earlier.
3) other ideas?
My personal favourite is pt2.
Has any Bip44 compliant wallet already done any integration at this point?
Thx,
Daniel/Mycelium
|
