public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Simone Bronzini <simone.bronzini@chainside.net>
Subject: Re: [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets
Date: Tue, 29 Aug 2017 20:07:43 +0000	[thread overview]
Message-ID: <201708292007.44679.luke@dashjr.org> (raw)
In-Reply-To: <8088fa79-8e77-8663-afb4-800a405a6182@chainside.net>

> 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


  reply	other threads:[~2017-08-29 20:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29 10:19 [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets Simone Bronzini
2017-08-29 20:07 ` Luke Dashjr [this message]
2017-08-30 12:22   ` Simone Bronzini
2017-08-30 10:07 ` Thomas Voegtlin
2017-08-30 12:48   ` Simone Bronzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201708292007.44679.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=simone.bronzini@chainside.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox