📅 Original date posted:2017-08-30
📝 Original message: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.
On 29/08/17 22:07, Luke Dashjr via bitcoin-dev wrote:
>> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- 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/20170830/8b886086/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/8b886086/attachment-0001.sig>;
Simone Bronzini [ARCHIVE] /
npub1eu…6244x
2023-06-07 18:05:09
in reply to nevent1q…nkk8
Author Public Key
npub1eutgkshv9qrfk005wypygy20svrhkz0f8sjnxp95pjm8y7ptxv4q96244xPublished at
2023-06-07 18:05:09Event JSON
{
"id": "8f41dc75a458583d952d5686553d93c0be7e18001cc9249a1cd54797963c09d1",
"pubkey": "cf168b42ec28069b3df4710244114f83077b09e93c253304b40cb672782b332a",
"created_at": 1686161109,
"kind": 1,
"tags": [
[
"e",
"4226676d217d0209465f4780759621ecdc1ce1537848685bc3d2fa36d82f3e9f",
"",
"root"
],
[
"e",
"7ce9a53f0a0bdf55f3e61b030ea227acc7fe8aabbcd3e1b81437b608006c37c2",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-08-30\n📝 Original message:Thanks for your feedback, I fixed what you suggested. As for the purpose\nhow should we move on? We would be inclined to use 46, but of course we\nare open to any other number.\n\n\nOn 29/08/17 22:07, Luke Dashjr via bitcoin-dev wrote:\n\u003e\u003e Status: Proposed\n\u003e This should only be set after peer review and implementations are complete, \n\u003e and you intend that there will be no further changes.\n\u003e\n\u003e\u003e As registered coin types we propose the ones already used for BIP44, which \n\u003e can be found at the following page.\n\u003e\n\u003e I suggest just referring to SLIP 44 directly.\n\u003e\n\u003e You're missing the Backward Compatibility and Copyright sections.\n\u003e\n\u003e\n\u003e\n\u003e On Tuesday 29 August 2017 10:19:10 AM Simone Bronzini via bitcoin-dev wrote:\n\u003e\u003e Hi all,\n\u003e\u003e last month we started looking for feedback (here and on other channels)\n\u003e\u003e about a proposal for a new structure to facilitate the management of\n\u003e\u003e different multisig accounts under the same master key, avoiding key\n\u003e\u003e reuse but still allowing cosigners to independently generate new\n\u003e\u003e addresses. While previously multiaccount multisig wallets were little\n\u003e\u003e used, now that LN is becoming a reality it is extremely important to\n\u003e\u003e have a better multiaccount management method to handle multiple payment\n\u003e\u003e channels.\n\u003e\u003e Please have a look at the draft of the BIP at the link below:\n\u003e\u003e\n\u003e\u003e https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki\n\u003e\u003e\n\u003e\u003e Any feedback is highly appreciated, but in particular we would like to\n\u003e\u003e collect opinions about the following issues:\n\u003e\u003e\n\u003e\u003e 1. coin_type level:\n\u003e\u003e this level is intended to allow users to manage multiple\n\u003e\u003e cryptocurrencies or forks of Bitcoin using the same masterkey (similarly\n\u003e\u003e to BIP44). We have already received some legit objections that, since we\n\u003e\u003e are talking about a Bitcoin Improvement Proposal, it shouldn't care\n\u003e\u003e about alt-coins. While we can agree with such objections, we also\n\u003e\u003e believe that having a coin_type level improves interoperability with\n\u003e\u003e muti-currency wallets (which is good), without any major drawback.\n\u003e\u003e Moreover, even a Bitcoin maximalist may hold multiple coins for whatever\n\u003e\u003e reason (short term speculation, testing, etc).\n\u003e\u003e\n\u003e\u003e 2. SegWit addresses:\n\u003e\u003e since mixing SegWit and non-SegWit addresses on the same BIP44 structure\n\u003e\u003e could lead to UTXOs not being completely recognised by old wallets,\n\u003e\u003e BIP49 was proposed to separate the key space. Since this is a new\n\u003e\u003e proposal, we can assume that wallets implementing it would be\n\u003e\u003e SegWit-compatible and so there should be no need to differetiate between\n\u003e\u003e SegWit and non-SegWit pubkeys. Anyway, if someone believes this problem\n\u003e\u003e still holds, we thought about two possible solutions:\n\u003e\u003e a. Create separate purposes for SegWit and non SegWit addresses\n\u003e\u003e (this would keep the same standard as BIP44 and BIP49)\n\u003e\u003e b. Create a new level on this proposed structure to divide SegWit\n\u003e\u003e and non SegWit addresses: we would suggest to add this new level between\n\u003e\u003e cosigner_index and change\n\u003e\u003e\n\u003e\u003e We believe solution b. would be better as it would give the option of\n\u003e\u003e having a multisig wallet with non SegWit-aware cosigners without having\n\u003e\u003e to use two different subtrees.\n\u003e\u003e\n\u003e\u003e This proposal is a work in progess so we would like to receive some\n\u003e\u003e feedback before moving on with proposing it as a BIP draft.\n\u003e\u003e\n\u003e\u003e Simone Bronzini\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\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/20170830/8b886086/attachment-0001.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 898 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/8b886086/attachment-0001.sig\u003e",
"sig": "d71247cc140dc81e91f9c5792be51f9a776bcd045394d65a50d2c3e9da0d53581cef2f991b5dbf5730ce43a77b4c1913f81ed292159c6b077b9be9dbdb279bed"
}