📅 Original date posted:2015-04-09
📝 Original message:Hello Alan,
Your scheme is basically the same as the BIP45 scheme, except that you
have collapsed the "cosigner_index" and "change" fields into a single
field with the formula:
combined = 2*cosigner_index + change
This removes one level from the hierarchy, but ultimately produces the
same number and type of chains as BIP45 (just addressed differently).
I kinda like the BIP45's approach of giving each field has its own
dedicated purpose. What is the motivation behind flattening the
hierarchy?
I ask because the wallet I work on, Airbitz, will be adding multi-sig
at some point in the future, and we need to figure out what kind of HD
tree structure we will be using. Our ideal structure would basically
be BIP 44 plus some "no-collision" logic:
m / purpose' / coin_type' / wallet' / cosigner_index / change /
address_index
I feel like interoperability with Copay would be worth the extra HD
branch. Assuming Kefkius adds similar no-collision logic, his proposal
is pretty close to our ideal:
m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
Of course, I am open to hearing your thoughts on this as well.
-William
On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> BTW, I had originally proposed a "no-collision" scheme for
> multi-signature wallets, which doesn't require modifying the key tree
> structure at all, except for adding new internal and external chains
> (2*N chains). All siblings watch all chains, but only generate
> receiving and change addresses on their two chains.
>
> The original document is here, which might be educational for the
> purposes of understand precisely the problem that needs a solution (and
> mine is a different solution than BIP45).
>
> https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf
>
> I prefer not adding even more levels to the key tree, and (IMO) it makes
> more sense to add more chains to the wallet instead of adding a new tree
> level (as it allows for a simpler tree in the event that you don't need
> separate cosigners). But I suspect that there's a certain momentum
> behind the cosigner-index method already in BIP45? Just throwing it out
> there.
William Swanson [ARCHIVE] /
npub159…jtxgs
2023-06-07 15:32:22
in reply to nevent1q…jjcl
Author Public Key
npub159u2fkxuq00hvmtypwllna99xh0vk9k9jkk5w89taev70au0gwwsmjtxgsPublished at
2023-06-07 15:32:22Event JSON
{
"id": "7b965153d176fc3b7f884ea53997b1b695c0382265aeae4bcb16932ca3e46993",
"pubkey": "a178a4d8dc03df766d640bbff9f4a535decb16c595ad471cabee59e7f78f439d",
"created_at": 1686151942,
"kind": 1,
"tags": [
[
"e",
"a3eafd4a0eb465d4acd06fbd4c0710e302efa659d70aadc00e533ecbab060a60",
"",
"root"
],
[
"e",
"6e85051078624f099fa4cba540c68dbe0026e5fb34acc99b639a416aced9ba3f",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2015-04-09\n📝 Original message:Hello Alan,\nYour scheme is basically the same as the BIP45 scheme, except that you\nhave collapsed the \"cosigner_index\" and \"change\" fields into a single\nfield with the formula:\n\n combined = 2*cosigner_index + change\n\nThis removes one level from the hierarchy, but ultimately produces the\nsame number and type of chains as BIP45 (just addressed differently).\n\nI kinda like the BIP45's approach of giving each field has its own\ndedicated purpose. What is the motivation behind flattening the\nhierarchy?\n\nI ask because the wallet I work on, Airbitz, will be adding multi-sig\nat some point in the future, and we need to figure out what kind of HD\ntree structure we will be using. Our ideal structure would basically\nbe BIP 44 plus some \"no-collision\" logic:\n\n m / purpose' / coin_type' / wallet' / cosigner_index / change /\naddress_index\n\nI feel like interoperability with Copay would be worth the extra HD\nbranch. Assuming Kefkius adds similar no-collision logic, his proposal\nis pretty close to our ideal:\n\n m / purpose' / wallet' / coin_type / cosigner_index / change / address_index\n\nOf course, I am open to hearing your thoughts on this as well.\n\n-William\n\nOn Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e BTW, I had originally proposed a \"no-collision\" scheme for\n\u003e multi-signature wallets, which doesn't require modifying the key tree\n\u003e structure at all, except for adding new internal and external chains\n\u003e (2*N chains). All siblings watch all chains, but only generate\n\u003e receiving and change addresses on their two chains.\n\u003e\n\u003e The original document is here, which might be educational for the\n\u003e purposes of understand precisely the problem that needs a solution (and\n\u003e mine is a different solution than BIP45).\n\u003e\n\u003e https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf\n\u003e\n\u003e I prefer not adding even more levels to the key tree, and (IMO) it makes\n\u003e more sense to add more chains to the wallet instead of adding a new tree\n\u003e level (as it allows for a simpler tree in the event that you don't need\n\u003e separate cosigners). But I suspect that there's a certain momentum\n\u003e behind the cosigner-index method already in BIP45? Just throwing it out\n\u003e there.",
"sig": "c18d91e8696bb3a2d2b7e2d3b6d2d7b56ee396b212d85d4e837a240063db04571a65a14ba8f4db4a6127ed1b0a783dff3ef2e087766a093e418ea8d87b1969af"
}