> 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev