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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D64FAA88
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Aug 2017 20:08:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id E41B1E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Aug 2017 20:08:00 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 2A81338A9B2F;
Tue, 29 Aug 2017 20:07:50 +0000 (UTC)
X-Hashcash: 1:25:170829:bitcoin-dev@lists.linuxfoundation.org::5i4ccp+XcD3hJhxC:zNmf
X-Hashcash: 1:25:170829:simone.bronzini@chainside.net::NVDh0M5Rli069=yG:KzV4
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Simone Bronzini <simone.bronzini@chainside.net>
Date: Tue, 29 Aug 2017 20:07:43 +0000
User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; )
References: <8088fa79-8e77-8663-afb4-800a405a6182@chainside.net>
In-Reply-To: <8088fa79-8e77-8663-afb4-800a405a6182@chainside.net>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201708292007.44679.luke@dashjr.org>
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,
RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount
multisig HD wallets
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, 29 Aug 2017 20:08:03 -0000
> Status: Proposed
This should only be set after peer review and implementations are complete,
and you intend that there will be no further changes.
> As registered coin types we propose the ones already used for BIP44, which
can be found at the following page.
I suggest just referring to SLIP 44 directly.
You're missing the Backward Compatibility and Copyright sections.
On Tuesday 29 August 2017 10:19:10 AM Simone Bronzini via bitcoin-dev wrote:
> Hi all,
> last month we started looking for feedback (here and on other channels)
> about a proposal for a new structure to facilitate the management of
> different multisig accounts under the same master key, avoiding key
> reuse but still allowing cosigners to independently generate new
> addresses. While previously multiaccount multisig wallets were little
> used, now that LN is becoming a reality it is extremely important to
> have a better multiaccount management method to handle multiple payment
> channels.
> Please have a look at the draft of the BIP at the link below:
>
> https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki
>
> Any feedback is highly appreciated, but in particular we would like to
> collect opinions about the following issues:
>
> 1. coin_type level:
> this level is intended to allow users to manage multiple
> cryptocurrencies or forks of Bitcoin using the same masterkey (similarly
> to BIP44). We have already received some legit objections that, since we
> are talking about a Bitcoin Improvement Proposal, it shouldn't care
> about alt-coins. While we can agree with such objections, we also
> believe that having a coin_type level improves interoperability with
> muti-currency wallets (which is good), without any major drawback.
> Moreover, even a Bitcoin maximalist may hold multiple coins for whatever
> reason (short term speculation, testing, etc).
>
> 2. SegWit addresses:
> since mixing SegWit and non-SegWit addresses on the same BIP44 structure
> could lead to UTXOs not being completely recognised by old wallets,
> BIP49 was proposed to separate the key space. Since this is a new
> proposal, we can assume that wallets implementing it would be
> SegWit-compatible and so there should be no need to differetiate between
> SegWit and non-SegWit pubkeys. Anyway, if someone believes this problem
> still holds, we thought about two possible solutions:
> a. Create separate purposes for SegWit and non SegWit addresses
> (this would keep the same standard as BIP44 and BIP49)
> b. Create a new level on this proposed structure to divide SegWit
> and non SegWit addresses: we would suggest to add this new level between
> cosigner_index and change
>
> We believe solution b. would be better as it would give the option of
> having a multisig wallet with non SegWit-aware cosigners without having
> to use two different subtrees.
>
> This proposal is a work in progess so we would like to receive some
> feedback before moving on with proposing it as a BIP draft.
>
> Simone Bronzini
|
