📅 Original date posted:2017-08-29
📝 Original message:-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc.sig
Type: application/pgp-signature
Size: 566 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.sig>;
Simone Bronzini [ARCHIVE] /
npub1eu…6244x
2023-06-07 18:05:09
in reply to nevent1q…06z8
Author Public Key
npub1eutgkshv9qrfk005wypygy20svrhkz0f8sjnxp95pjm8y7ptxv4q96244xPublished at
2023-06-07 18:05:09Event JSON
{
"id": "41252cbf6e26a2a787e0babd2c2ae81fd911679ce11918900c3eab7405a94b25",
"pubkey": "cf168b42ec28069b3df4710244114f83077b09e93c253304b40cb672782b332a",
"created_at": 1686161109,
"kind": 1,
"tags": [
[
"e",
"4226676d217d0209465f4780759621ecdc1ce1537848685bc3d2fa36d82f3e9f",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2017-08-29\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nHi all,\nlast month we started looking for feedback (here and on other channels)\nabout a proposal for a new structure to facilitate the management of\ndifferent multisig accounts under the same master key, avoiding key\nreuse but still allowing cosigners to independently generate new\naddresses. While previously multiaccount multisig wallets were little\nused, now that LN is becoming a reality it is extremely important to\nhave a better multiaccount management method to handle multiple payment\nchannels.\nPlease have a look at the draft of the BIP at the link below:\n\nhttps://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki\n\nAny feedback is highly appreciated, but in particular we would like to\ncollect opinions about the following issues:\n\n1. coin_type level:\nthis level is intended to allow users to manage multiple\ncryptocurrencies or forks of Bitcoin using the same masterkey (similarly\nto BIP44). We have already received some legit objections that, since we\nare talking about a Bitcoin Improvement Proposal, it shouldn't care\nabout alt-coins. While we can agree with such objections, we also\nbelieve that having a coin_type level improves interoperability with\nmuti-currency wallets (which is good), without any major drawback.\nMoreover, even a Bitcoin maximalist may hold multiple coins for whatever\nreason (short term speculation, testing, etc).\n\n2. SegWit addresses:\nsince mixing SegWit and non-SegWit addresses on the same BIP44 structure\ncould lead to UTXOs not being completely recognised by old wallets,\nBIP49 was proposed to separate the key space. Since this is a new\nproposal, we can assume that wallets implementing it would be\nSegWit-compatible and so there should be no need to differetiate between\nSegWit and non-SegWit pubkeys. Anyway, if someone believes this problem\nstill holds, we thought about two possible solutions:\n a. Create separate purposes for SegWit and non SegWit addresses\n(this would keep the same standard as BIP44 and BIP49)\n b. Create a new level on this proposed structure to divide SegWit\nand non SegWit addresses: we would suggest to add this new level between\ncosigner_index and change\n\nWe believe solution b. would be better as it would give the option of\nhaving a multisig wallet with non SegWit-aware cosigners without having\nto use two different subtrees.\n\nThis proposal is a work in progess so we would like to receive some\nfeedback before moving on with proposing it as a BIP draft.\n\nSimone Bronzini\n\n-----BEGIN PGP SIGNATURE-----\nComment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n\niQIzBAEBCAAdFiEErS/wgXh5+C1vqPN/TXSJoN+7oQoFAlmlP2QACgkQTXSJoN+7\noQptgA/7B46/Why5h5/cxWyvgjmuUJ12Rkvh+EtfOUhMX+a8i4PJkLHGB2RibRfR\n/Li1F+QWd2yeqdNO97er8HDGSlouxB7twB0ZMnS/LRPsHTA3Zf4OoD7H/yjj3lcD\nGiJGy4MiHEOfjqaIwd0onUPX9ch5+Mm7aL34vBDdK0/8gm2v+HGO+GAefaUnZTQh\n/CIaM0Th9dDS0xs5wcP3ncNqs1e59MHXOWlh7+zAxfvFio+HHnCbULIe4uct6stC\nQxTNh8naQD4cB7tV9wsEeyuuJQ1gG8/pgN3WgRu5gW9CGpmpsySJgCCftkTZZHeL\neoqGJy5XFbI4CN2wEC2pbWW0xtDNyFq71wUPYNXINn8/7rnSjSl06OKISEk0u1yL\nvhFuR9RSxEge2cS1pDwIwHVNR6pCeZMRwo0tp1OEXnt5VGGpmKengtpcFkFlOVdd\navUueIe8OoFGODco4+f25foB/z/rzyg3REXYX36bZiS6UkUOx4TCGpAzY86i4fDJ\nSTeDy5KMLk1S9rvTNrygxR74DkFMiNkalF3g4VauUlCFmh8iOzEDdtOQ3mLu/pgq\nMXxfxq6ABxeCmQ7LsuBcFc+wN6AVLhrOhIPGyI8EAyaZNIGByqdgZGubvOl0J/gt\nYr4z5fViI7hjJijvooKzFtX0MNnaLBCOlggLpQO58t8En+BiNDE=\n=XgcB\n-----END PGP SIGNATURE-----\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0xB2E60C73.asc\nType: application/pgp-keys\nSize: 15541 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0xB2E60C73.asc.sig\nType: application/pgp-signature\nSize: 566 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.sig\u003e",
"sig": "6409c1a571d2316dca48e925dfd9e5b85da5114f7fcc6ef3f830b28365c618f0c3f100efa12e9862b6dac1bda5070d0f319d1c0bcfa0f886db50d3f42d4c735f"
}