📅 Original date posted:2014-03-26
📝 Original message:This might be tangential, but the comment about "refund" chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1. Your spouse's
phone would use chains 2 and 3.
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan
On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/35055a7c/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:16:13
in reply to nevent1q…y7cw
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:16:13Event JSON
{
"id": "c19812e7383379d91ad7997368fe32c453481a8704786793f96275cb01caca5b",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150973,
"kind": 1,
"tags": [
[
"e",
"d9ddea79394f356d989e65ab112610cc90e9929cf3c160da3cfe266aeba22200",
"",
"root"
],
[
"e",
"ef699d5b54eca9c510aa3530e5e4c56747ed281f4f54b6dc2c24587ebb2dc48f",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-03-26\n📝 Original message:This might be tangential, but the comment about \"refund\" chains reminded\nme. Armory will be implementing multi-sig/linked wallets where a each\ndevice has a parallel HDW branch and produces P2SH addresses. For those\ntypes of wallets, I plan to allocate two chains /per signing\nauthority/. If you have a shared 2-of-2 wallet split between your phone\nand your spouse's phone, your phone would distribute addresses on P2SH\nchain 0 and generate change addresses on P2SH chain 1. Your spouse's\nphone would use chains 2 and 3.\n\nSo if you and your spouse switch to a new app that supports M-of-N\nlinked wallets, it should search for coin history along the first 2*N\nchains.\n-Alan\n\n\n\nOn 03/26/2014 07:37 PM, Andreas Schildbach wrote:\n\u003e Thanks for starting the discussion on finding a better structure.\n\u003e\n\u003e For me, the most important thing is either we're 100% interoperable or\n\u003e 0%. There should not be anything inbetween, as users will delete seeds\n\u003e without knowing there is still money in them on another implementation.\n\u003e I heard from multiple sources that using this standard some wallets will\n\u003e only see a subset of the addresses/keys of some other wallets.\n\u003e Implementation differences can always happen (and should addresses as\n\u003e bugs), but I think its unacceptable that this source of issues is by design.\n\u003e\n\u003e I suggest we agree on an even simpler least common denominator and\n\u003e wallets that want to implement some feature on top of that can do but\n\u003e are encouraged to pick a totally different \"cointype\". I guess that\n\u003e would mean removing reserved and account.\n\u003e\n\u003e I'm still thinking it might be a good idea to have a separate chain for\n\u003e \"refunds\". Refunds will be rarely used and thus need a much slower\n\u003e moving window than receiving addresses or change.\n\u003e\n\u003e\n\u003e On 03/26/2014 09:49 PM, Mike Hearn wrote:\n\u003e\u003e Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure\n\u003e\u003e our BIP32 wallet structures would be compatible - and I discovered that\n\u003e\u003e only I was planning to use the default structure.\n\u003e\u003e\n\u003e\u003e Because I'm hopeful that we can get a lot of interoperability between\n\u003e\u003e wallets with regards to importing 12-words paper wallets, we\n\u003e\u003e brainstormed to find a structure acceptable to everyone and ended up with:\n\u003e\u003e\n\u003e\u003e /m/cointype/reserved'/account'/change/n\n\u003e\u003e\n\u003e\u003e The extra levels require some explanation:\n\u003e\u003e\n\u003e\u003e * cointype: This is zero for Bitcoin. This is here to support two\n\u003e\u003e things, one is supporting alt coins based off the same root seed.\n\u003e\u003e Right now nobody seemed very bothered about alt coins but sometimes\n\u003e\u003e feature requests do come in for this. Arguably there is no need and\n\u003e\u003e alt coins could just use the same keys as Bitcoin, but it may help\n\u003e\u003e avoid confusion if they don't.\n\u003e\u003e\n\u003e\u003e More usefully, cointype can distinguish between keys intended for\n\u003e\u003e things like multisig outputs, e.g. for watchdog services. This means\n\u003e\u003e if your wallet does not know about the extra protocol layers\n\u003e\u003e involved in this, it can still import the \"raw\" money and it will\n\u003e\u003e just ignore/not see the keys used in more complex transactions.\n\u003e\u003e\n\u003e\u003e * reserved is for \"other stuff\". I actually don't recall why we ended\n\u003e\u003e up with this. It may have been intended to split out multisig\n\u003e\u003e outputs etc from cointype. Marek, Thomas?\n\u003e\u003e\n\u003e\u003e * account is for keeping essentially wallets-within-a-wallet to avoid\n\u003e\u003e mixing of coins. If you want that.\n\u003e\u003e\n\u003e\u003e * change is 0 for receiving addresses, 1 for change addresses.\n\u003e\u003e\n\u003e\u003e * n is the actual key index\n\u003e\u003e\n\u003e\u003e For bitcoinj we're targeting a deliberately limited feature set for hdw\n\u003e\u003e v1 so I would just set the first three values all to zero and that is a\n\u003e\u003e perfectly fine way to be compatible.\n\u003e\u003e\n\u003e\u003e The goal here is that the same seed can be written down once, and meet\n\u003e\u003e all the users needs, whilst still allowing some drift between what\n\u003e\u003e wallets support.\n\u003e\u003e\n\u003e\u003e Pieter made the I think valid point that you can't really encode how\n\u003e\u003e keys are meant to be used into just an HDW hierarchy and normally you'd\n\u003e\u003e need some metadata as well. However, I feel interop between wallets is\n\u003e\u003e more important than arriving at the most perfect possible arrangement,\n\u003e\u003e which feels a little like bikeshedding, so I'm happy to just go with the\n\u003e\u003e flow on this one.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/35055a7c/attachment.html\u003e",
"sig": "c51beb1c4f94545929f09448bc1090fb7babb3e33b8234a0e8392b6a9a8bec024b4fef0cb6edc35cc239137b2dc29eb5eca638e36f92fab2b72a6810ecd57687"
}