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>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201708292007.44679.luke@dashjr.org>
Subject: Re: [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount
	multisig HD wallets
Precedence: list

> 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