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
|
Return-Path: <gcbd-bitcoin-development-2@m.gmane.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8CAA0256
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2016 07:00:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC80813A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2016 07:00:42 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development-2@m.gmane.org>)
id 1b1TYw-00007r-FE for bitcoin-dev@lists.linuxfoundation.org;
Sat, 14 May 2016 09:00:34 +0200
Received: from x55b3774d.dyn.telefonica.de ([85.179.119.77])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2016 09:00:34 +0200
Received: from andreas by x55b3774d.dyn.telefonica.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2016 09:00:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Sat, 14 May 2016 09:00:27 +0200
Message-ID: <nh6ieb$tq0$1@ger.gmane.org>
References: <5735D3A4.7090608@mycelium.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: x55b3774d.dyn.telefonica.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.7.2
In-Reply-To: <5735D3A4.7090608@mycelium.com>
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
RCVD_IN_DNSWL_LOW,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
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: Sat, 14 May 2016 07:00:43 -0000
The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
define balance retrieval never changes. This is to make sure you always
see the same balance on "same BIP" wallets (and same seed of course).
So if you want to add paths, it has to be a new BIP.
On 05/13/2016 03:16 PM, Daniel Weigl via bitcoin-dev wrote:
> 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
>
|
