Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion dip-0009/assignments.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ Here is a table of current feature paths and any associated DIP. Future DIPs may
| ------------------ | ------------ | ------------------- | ---- |
| `3'` | Masternode Keys | [DIP 0003: Deterministic Masternode List](https://github.com/dashpay/dips/blob/master/dip-0003.md) | The masternode related keys are located in the following sub-paths: <br>`0'/*` - _Reserved_<br>`1'/*` - Voting Key<br>`2'/*` - Owner Key<br>`3'/*` - Operator Key<br>`4'/*` - [Platform P2P Key](../dip-0028.md#calculating-the-platform-node-id) (ED25519)<br><br>For example, the first voting key for Dash would be at `m/9'/5'/3'/1'/0` |
| `4'` | CoinJoin Keys | CoinJoin | The masternode related keys are located in the following sub-paths: <br>`0'/0/*` - Account 0 (external)<br>`0'/1/*` - Account 0 (change, not typically used)<br><br>For example, the first key of Account 0 for CoinJoin would be at `m/9'/5'/4'/0'/0/0`.<br><br>The main purpose of this using this path is to segregate CoinJoin-related keys from the BIP44 paths that are used to receive coins and change. CoinJoin derivation paths may require different lookup or gap values than the BIP44 paths that have much less transaction activity. Additionally, it may be possible to prune used keys from the BIP37 bloom filters used by mobile apps.|
| `5'` | Identity Keys | [DIP 0013: Identities in Hierarchical Deterministic wallets](../dip-0013.md) | The related keys are located in the following sub-paths: <br>`0'/key type'/identity index'/key index'` - Identity Authentication ([details](../dip-0013.md#identity-authentication-keys))<br>&nbsp;&nbsp;&nbsp;&nbsp;Key types:<br>&nbsp;&nbsp;&nbsp;&nbsp;`0'` - ECDSA (secp256k1)<br>&nbsp;&nbsp;&nbsp;&nbsp;`1'` - BLS (bls12381)<br>`1'/*` - Identity Registration Asset Lock Funding ([details](../dip-0013.md#identity-registration-funding-keys))<br>`2'/*` - Identity Top up Asset Lock Funding ([details](../dip-0013.md#identity-top-up-funding-keys))<br>&nbsp;&nbsp;&nbsp;&nbsp;`2'/funding index` - Not bound to a specific identity<br>&nbsp;&nbsp;&nbsp;&nbsp;`2'/registration index'/top up index` - Bound to a specific identity<br>`3'/*` - Identity Invitation Asset Lock Funding ([details](../dip-0013.md#identity-invitation-funding-keys))<br>`4'/*` - Asset Lock Address Top up Funding<br>`5'/*` - Asset Lock Shielded Address Top up Funding<br><br>For example, the first ECDSA authentication key for the first identity on Dash would be at `m/9'/5'/5'/0'/0'/0'/0'`<br>The first Identity Registration Asset Lock Funding key for Dash would be at `m/9'/5'/5'/1'/0` |
| `5'` | Identity Keys | [DIP 0013: Identities in Hierarchical Deterministic wallets](../dip-0013.md) | The related keys are located in the following sub-paths: <br>`0'/key type'/identity index'/key index'` - Identity Authentication ([details](../dip-0013.md#identity-authentication-keys))<br>&nbsp;&nbsp;&nbsp;&nbsp;Key types:<br>&nbsp;&nbsp;&nbsp;&nbsp;`0'` - ECDSA (secp256k1)<br>&nbsp;&nbsp;&nbsp;&nbsp;`1'` - BLS (BLS12-381)<br>`1'/*` - Identity Registration Asset Lock Funding ([details](../dip-0013.md#identity-registration-funding-keys))<br>`2'/*` - Identity Top up Asset Lock Funding ([details](../dip-0013.md#identity-top-up-funding-keys))<br>&nbsp;&nbsp;&nbsp;&nbsp;`2'/funding index` - Not bound to a specific identity<br>&nbsp;&nbsp;&nbsp;&nbsp;`2'/registration index'/top up index` - Bound to a specific identity<br>`3'/*` - Identity Invitation Asset Lock Funding ([details](../dip-0013.md#identity-invitation-funding-keys))<br>`4'/*` - Asset Lock Address Top up Funding (spec section pending in DIP 0013)<br>`5'/*` - Asset Lock Shielded Address Top up Funding (spec section pending in DIP 0013)<br><br>For example, the first ECDSA authentication key for the first identity on Dash would be at `m/9'/5'/5'/0'/0'/0'/0'`<br>The first Identity Registration Asset Lock Funding key for Dash would be at `m/9'/5'/5'/1'/0` |
| `15'` | DashPay - Incoming Funds | [DIP 0015: DashPay](../dip-0015.md#dashpay-incoming-funds-derivation-path) | The related keys are located in the following sub-paths: `/0'/account'/*`<br><br>For example, incoming funds for the first identity would be at `m/9'/5'/15'/0'/*` |
| `16'` | DashPay - Auto Accept Proof | [DIP 0015: DashPay](../dip-0015.md#auto-accept-proof-autoacceptproof) | The related keys are located in the following sub-paths: `16'/expiration timestamp'`<br><br>For example, the key for a proof expiring at a Unix epoch time of `1605927033` would be at `m/9'/5'/16'/1605927033'` |

Expand Down
19 changes: 10 additions & 9 deletions dip-0013.md
Original file line number Diff line number Diff line change
Expand Up @@ -166,15 +166,16 @@ For example, the first top up funding key for the first identity on Dash would b

If a wallet recovers an unused top up funding transaction, the wallet should attempt to reuse it.
This is done in a few steps. First, the wallet must recognise the key used in a returned identity
funding transaction as a top up funding key. Then the wallet must query Dash Platform to check if
the top up transaction has already been used and the balance transferred into credits. If this is
not the case, the wallet can then perform an identity top up transition as defined in DIP11 using
the top up funding key.

It is recommended that 30 address hashes of both unbound top up funding keys and bound top up
funding keys for each known identity be added to the bloom filter sent to peers. If transactions
containing 25 address hashes or more have been found for either category, the filter should be
regenerated with 30 more.
funding transaction as a top up funding key. If the recovered key is unbound (`m/.../2'/funding index`),
the wallet must identify and select the target identity before querying or performing a top up.
Then the wallet must query Dash Platform to check if the top up transaction has already been used
and the balance transferred into credits. If this is not the case, the wallet can then perform an
identity top up transition as defined in DIP11 using the top up funding key.

It is recommended that bloom filters include 30 address hashes per category: 30 for unbound top up
funding keys, and 30 for bound top up funding keys for each known identity. If transactions
containing 25 address hashes or more have been found for any category, the filter should be
regenerated with 30 more for that category.

# Identity Invitation Funding keys

Expand Down