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
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=simone.bronzini@chainside$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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