RFC: proposition to extend BIP44 - extended HD Wallet

[redPanda]

I would like to here your comments about this proposition:

from BIP44: Multi-Account Hierarchy for Deterministic Wallets

Code:

We define the following 5 levels in BIP32 path:
m / purpose' / coin_type' / account' / change / address_index

With this definition, a (single) wallet can have multiple accounts:
account' = 0', 1', 2', ...

I'm working on a new wallet and I would like to have a full hierarchy a wallets
where

Code:

/account'/

will be replaced by a multiple level of wallets (all with hardened derivation)

Code:

/master wallet n'/sub wallet m'/.../sub wallet p'/

Something like this:

Code:

-- personnal wallet                      /0'/
    -- current account                   /0'/0'/
        -- restaurants                   /0'/0'/0'/
        -- beers                         /0'/0'/1'/
        -- food                          /0'/0'/2'/
    -- saving account                    /0'/1'/
        -- retirement                    /0'/1'/0'/
        -- next summer vacation          /0'/1'/1'/
        -- income taxes                  /0'/1'/2'/
    -- house expenditure                 /0'/2'/
    -- donations                         /0'/3'/
    -- kid's school                      /0'/4'/
-- personnal business                    /1'/
    -- North America                     /1'/0'/
        -- USA                           /1'/0'/0'/
            -- ...                       ...
        -- Canada                        /1'/1'/
            -- Quebec                    /1'/1'/0'/
                -- Montreal              /1'/1'/0'/0'/
                    -- 00 Ste-Catherine  /1'/1'/0'/0'/0'/
                    -- 99 St-Denis       /1'/1'/0'/0'/1'/
            -- British Colombia          /1'/1'/1'/
-- Joint account (with wife)             /2'/
    -- lawyers                           /2'/0'/

This proposition can be seen as an extension of a Multi-Account Hierarchy for Deterministic Wallets (BIP44).
An HD Wallet implementing BIP44 will be considered as containing only one master wallet /0'/
and will be compatible with this proposition. That's why I call it "Multi-Account Hierarchy for extended Deterministic Wallets"
or simply "extended HD Wallet" or "xHD Wallet".

[danda]

-- personnal wallet                      /0'/
    -- current account                   /0'/0'/
        -- restaurants                   /0'/0'/0'/
        -- beers                         /0'/0'/1'/
        -- food                          /0'/0'/2'/

What does this even mean?

Are you implying that "current_account" can access the keys of restaurants, beers, and food, in order to present a summary balance for all three?   ok, I can see that.    But then what if I try to make a spend from "current account"?  Does it use a key from restaurants, or from beers, or from food, or from itself?   what if "current account" does not have any keys with funds but "beers" does?

To me, the concept doesn't really make sense.

Now, if you call "restaurants" a wallet, and "current account" and "personal wallet" wallet groups, then that makes sense.  So a wallet group could aggregate wallet info in read-only fashion.    And the grouping data is basically app-specific and does not have to be portable between wallet software.

Admittedly, it would be nice if there were a common format for specifying wallet names, as well as wallet groups.  But that's outside the scope of Bip 44.

[redPanda]

Are you implying that "current_account" can access the keys of restaurants, beers, and food, in order to present a summary balance for all three?

Yes: All parent wallets have full access to all their child wallets and the balance will be the sum of itself and all its childs.

But then what if I try to make a spend from "current account"?  Does it use a key from restaurants, or from beers, or from food, or from itself?

from itself: the account's path for "current account" is /0'/0'/
so this account will use addresses like /0'/0'/change/address_index
Since the owner of "current_account" has full access to its childs he can indicate to use a child wallet to pay for restaurants.
Then the wallet will use the corresponding path for "current_account/restaurants": /0'/0'/0'/change/address_index

what if "current account" does not have any keys with funds but "beers" does?

In this specific case, the user will have to transfert money from one account to another involving a Tx in the blockchain.
This is not a very good example since the application can provide a simple way to give a tag to a Tx (you're right on this point:  it has nothing to do with bip44).

But let say you own few businesses: you create a sub wallet for each and you give the corresponding private key (and chain code)
to the managers so they can do any Tx they need and it is also possible for them to derive and create any child keys and wallets. They have no access to any parent wallets.
As the owner, you keep the total control over all sub wallets and you can have an instant financial report of all Tx. That's the aim of my proposition.

Thanks for your comments, I always appreciate