Re: [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets
> 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
[bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEErS/wgXh5+C1vqPN/TXSJoN+7oQoFAlmlP2QACgkQTXSJoN+7 oQptgA/7B46/Why5h5/cxWyvgjmuUJ12Rkvh+EtfOUhMX+a8i4PJkLHGB2RibRfR /Li1F+QWd2yeqdNO97er8HDGSlouxB7twB0ZMnS/LRPsHTA3Zf4OoD7H/yjj3lcD GiJGy4MiHEOfjqaIwd0onUPX9ch5+Mm7aL34vBDdK0/8gm2v+HGO+GAefaUnZTQh /CIaM0Th9dDS0xs5wcP3ncNqs1e59MHXOWlh7+zAxfvFio+HHnCbULIe4uct6stC QxTNh8naQD4cB7tV9wsEeyuuJQ1gG8/pgN3WgRu5gW9CGpmpsySJgCCftkTZZHeL eoqGJy5XFbI4CN2wEC2pbWW0xtDNyFq71wUPYNXINn8/7rnSjSl06OKISEk0u1yL vhFuR9RSxEge2cS1pDwIwHVNR6pCeZMRwo0tp1OEXnt5VGGpmKengtpcFkFlOVdd avUueIe8OoFGODco4+f25foB/z/rzyg3REXYX36bZiS6UkUOx4TCGpAzY86i4fDJ STeDy5KMLk1S9rvTNrygxR74DkFMiNkalF3g4VauUlCFmh8iOzEDdtOQ3mLu/pgq MXxfxq6ABxeCmQ7LsuBcFc+wN6AVLhrOhIPGyI8EAyaZNIGByqdgZGubvOl0J/gt Yr4z5fViI7hjJijvooKzFtX0MNnaLBCOlggLpQO58t8En+BiNDE= =XgcB -END PGP SIGNATURE- 0xB2E60C73.asc Description: application/pgp-keys 0xB2E60C73.asc.sig Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
