Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-08-29 📝 Original message:> Status: Proposed This ...

📅 Original date posted:2017-08-29
📝 Original message:> 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