DIP: aj-hd-mixing to define mix tracking via hdpath

[coolaj86]

TODO: add derivation and change to keywords.

In short

We need a way to do to track mixing across devices without special indexes or syncing. We can add some DASH-flavored progressive enhancement to HDPaths for that without breaking anything.

m/<bip44>'/<coin>'/<account>'/<mixcount>/<index>
m/44'/5'/0'/0/0 - newly denominated coin
m/44'/5'/0'/1/0 - coin which has been mixed once
m/44'/5'/0'/...
m/44'/5'/0'/16/0 - a fully mixed coin
m/44'/5'/0'/... - an overmixed coin

<mixcount> can safely overtake <usage> (internal / send vs _external / change) because mixed accounts don't deal with change.

[coolaj86]

See also:
https://github.com/dashpay/dips/blob/master/dip-0009.md

I prefer tacking on to the 44' style just because it's going to be easier to use with existing software.

All else being equal, I don't care. It's good for DASH to have its own standards rather than living in Big B's shadow.

However, that standard doesn't actually define a solution for this particular problem.

[HashEngineering]

Currently, the DIP9 format is being used for CoinJoin development on mobile, which is based on using number 4 from
https://github.com/dashpay/dips/blob/master/dip-0009/assignments.md.

For example with mainnet, the path is the following:
m/9'/5'/4'/x

This follows the following scheme.
m / 9' / coin_type' / feature' / *

Presently, what is used doesn't include the account number. This will need to be added in the mobile scheme.

[HashEngineering]

The usage 0 and 1 will "conflict" with the external and internal key usage. Perhaps this doesn't matter as 0 and 1 wouldn't be considered mixed. There is still a way to tell the differences between change and output that has been mixed once based on the TX history and the amount.

[coolaj86]

The usage 0 and 1 will "conflict" with the external and internal key usage.

A "CoinJoin" wallet wouldn't have change, so there would be no conflict.

That assuming that we use different account indexes for "CoinJoin" accounts than the legacy accounts. Tracking which is which would be a matter of indexing on the client side.

Example:

• 0 legacy account
• 1 savings account
• 2 CoinJoin account
• 3 shared account with wife

A specific metadata tag to relate an account's name, type, and any other metadata or notes about it would need its own DIP for the JSON format.

I suspect it would be something like this:

[
  {
    "nickname": "Primary",
    "wallet_id": "xxxxxxx", // as per DIP: Deterministic Wallet IDs
    "account_index": 0,
    "capabilities": ["coinjoin"],
    "desc": "Modern, Secure DASH Transactions",
  },
  {
    "nickname": "Legacy",
    "wallet_id": "yyyyyy", // as per DIP: Deterministic Wallet IDs
    "account_index": 0,
    "capabilities": [],
    "desc": "Fingerprinted Transactions for Legacy APIs and Apps",
  },
  {
    "nickname": "Marie",
    "wallet_id": "zzzzzz", // as per DIP: Deterministic Wallet IDs
    "account_index": 0,
    "capabilities": [],
    "desc": "Shared Account with Marie",
  }
]

[coolaj86]

Perhaps this doesn't matter as 0 and 1 wouldn't be considered mixed.

Off-by-one errors are hard enough as-is. I'd say 0 should be the denomination (or transfer of existing denomination) and 1 should be the first mix.

[coolaj86]

There is still a way to tell the differences between change and output that has been mixed once based on the TX history and the amount.

That was a poor choice and can't be relied on for future development.

As long as the DashCore requires the cutesy style of 100001[0000], you'll always have to de-mix coins to spend them.

Denominations detection needs to be redone (eventually) so that they carry the excess of the fee balance with them. I address that in #131 (though some of my understanding was incorrect, the core concept remains the same).

So (eventually) 100002000 and 100001800 need to both be considered a denomination of 100000000 with usable stamp values that can be spent many times before having to be redenominated and remixed - such that there is no clear distinction between a "mix" and a "spend" - denominations all the way down.