Discussion:
[bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets
Simone Bronzini via bitcoin-dev
2017-08-29 10:19:10 UTC
Permalink
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
Luke Dashjr via bitcoin-dev
2017-08-29 20:07:43 UTC
Permalink
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.
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.
https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki
Any feedback is highly appreciated, but in particular we would like to
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).
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
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
Simone Bronzini via bitcoin-dev
2017-08-30 12:22:30 UTC
Permalink
Thanks for your feedback, I fixed what you suggested. As for the purpose
how should we move on? We would be inclined to use 46, but of course we
are open to any other number.
Post by Luke Dashjr via bitcoin-dev
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.
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.
https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki
Any feedback is highly appreciated, but in particular we would like to
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).
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Thomas Voegtlin via bitcoin-dev
2017-08-30 10:07:24 UTC
Permalink
Post by Simone Bronzini via bitcoin-dev
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.
This will lead to old UTXOs not being recognized by NEW wallets, because
at some point new wallets will not care about implementing old standards.

The only way to address this is to get out of bip39 and bip43, and to
include a version number in the mnemonic seed.
Simone Bronzini via bitcoin-dev
2017-08-30 12:48:24 UTC
Permalink
Post by Thomas Voegtlin via bitcoin-dev
This will lead to old UTXOs not being recognized by NEW wallets, because
at some point new wallets will not care about implementing old standards.
Your observations make perfect sense. That's exactly why we endorse
option b. in my previous email.
Post by Thomas Voegtlin via bitcoin-dev
The only way to address this is to get out of bip39 and bip43, and to
include a version number in the mnemonic seed.
As for the idea of having a versioning on mnemonic seeds, I believe it
would be a very useful feature indeed. How about opening a new,
separate, topic about it?
Post by Thomas Voegtlin via bitcoin-dev
Post by Simone Bronzini via bitcoin-dev
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.
This will lead to old UTXOs not being recognized by NEW wallets, because
at some point new wallets will not care about implementing old standards.
The only way to address this is to get out of bip39 and bip43, and to
include a version number in the mnemonic seed.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...