Number: SLIP-0025
Title: Key derivation for CoinJoin accounts
Type: Standard
Status: Draft
Authors: Andrew R. Kozlik <andrew.kozlik@satoshilabs.com>
Created: 2022-04-04
This document defines a logical hierarchy for deterministic wallets based on the algorithm defined in BIP 32 and SLIP 10 and the scheme described in BIP 43. The purpose of this document is largely the same as BIP 86, however the keys derived using the present hierarchy are meant to be used in so called CoinJoin accounts, which are managed by CoinJoin wallets.
A CoinJoin wallet allows its users to participate in a special kind of transaction which mixes the user's UTXOs with the UTXOs of other participants in order to obfuscate the ownership of the resulting CoinJoin outputs to external observers. Each user receives the same amount from the CoinJoin transaction as they put in, minus a small coordination and mining fee. Each UTXO that is managed by a CoinJoin wallet is assigned an anonymity rating based on its CoinJoin history and the user typically chooses to spend only those UTXOs which have achieved a sufficient level of anonymity. The way in which the account keys and XPUBs are managed requires greater care than in the case of ordinary cryptocurrency accounts based on BIPs 44, 49, 84 or 86, which is why we define this domain-separated hierarchy.
We define the following 6 levels in the BIP 32 derivation path:
m / 10025' / coin_type' / account' / script_type' / change / address_index
' in the path indicates that hardened derivation is used.
A key derived with this derivation path pattern will be referred to as derived_key further in this document.
The value of coin_type MUST be one of the coin types defined in SLIP 44.
The keys derived for a particular coin type SHOULD only be used in connection with the cryptocurrency specified in SLIP 44.
One master node (seed) can be used for multiple cryptocurrency networks.
Sharing keys between different cryptocurrency networks or between mainnet and testnet may be especially dangerous if the cryptocurrency does not implemented strong replay protection, e.g. via SIGHASH_FORKID.
For example if a testnet application is allowed to access mainnet keys, then an attacker may be able to coerce the user into spending Bitcoin by signing a seemingly harmless testnet transaction.
This level creates a separate subtree for every cryptocurrency, avoiding key reuse between networks and improving privacy.
The value of account SHOULD be in the range from 0 to 100.
Accounts are numbered from index 0 in a sequentially increasing manner.
This level splits the key space into independent user identities. Users can use these accounts to organize their funds in the same fashion as bank accounts for better overview of their operations, e.g. a business account and a personal account. Some users may also choose to segregate coins into multiple identities as a fail-safe in case CoinJoin doesn't offer the advertised level of anonymity.
Wallet software should prevent spending coins from different accounts in one transaction. It should also prevent the creation of an account, i.e. accessing the new account's addresses, if a previous account does not have any transaction history.
The value of script_type MUST be 1.
All other values are reserved for future use.
The inclusion of this field is inspired by BIP 48. Being able to manage multiple script types under a single account may be especially useful in other privacy-focused applications such as BIP 78 PayJoin when the sender's script type needs to be matched by the receiving wallet.
The value of change MUST be 0 or 1.
All other values are reserved for future use.
The value 0 is used for the external chain and the value 1 for the internal chain (also known as change addresses or internal addresses).
The external chain is used for addresses that are meant to be visible outside of the wallet, e.g. for receiving payments.
The Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used either for returning transaction change or for outputs of CoinJoin transactions.
The value of address_index SHOULD be an integer in the range from 0 to 1000000 (inclusive).
Addresses are numbered from index 0 in a sequentially increasing manner.
If script_type = 1 then the derived key MUST be used to generate a P2TR address.
The scriptPubKey is defined exactly as specified in the Address derivation section of BIP 86:
internal_key: lift_x(derived_key)
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
scriptPubKey: 0x51 0x20 {32_byte_output_key}
The UTXOs from a CoinJoin account SHOULD only be spent by a wallet that is able to rate the anonymity of the UTXOs and select the ones satisfying the user's anonymity threshold.
Wallets MUST require user confirmation before releasing the XPUB to any node in the BIP 32 subtree of m / 10025'.
Wallets SHOULD NOT display an address belonging to the internal chain (change = 1) of a CoinJoin account.
This SLIP is not backwards compatible with earlier derivation schemes by design due to the special requirements for handling XPUBs and addresses. An incompatible wallet will not discover these accounts, however the scheme is sufficiently similar to existing schemes, so that adding it to current implementations does not require any significant amount of new code.
TODO
- BIP 32: Hierarchical Deterministic Wallets
- SLIP 10: Universal private key derivation from master private key
- BIP 44: Multi-Account Hierarchy for Deterministic Wallets
- SLIP 44: Registered coin types for BIP 44
- BIP 48: Multi-Script Hierarchy for Multi-Sig Wallets
- BIP 49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
- BIP 84: Derivation scheme for P2WPKH based accounts
- BIP 86: Deterministic Entropy From BIP32 Keychains
- BIP 78: A Simple Payjoin Proposal