Read to understand how derivation paths help with key management, and enhance security. Their most significant use case being efficient wallet backup and recovery.
quotingParman's wallet tips...
note12t2…wzzn
On Bitcoin keys and Derivation paths.
A Bitcoin private key is a number. It's big and should be random so no one can guess it by brute force. It generates a public key - also a number.
This is a KEY PAIR and fundamental to public-private key cryptography.
Key pairs can "birth" more key pairs. Eg if you take a key pair and multiply it by some number, you get another number (there's more to it than that, but that's the concept).
A derivation path is just a system of agreement (a protocol) on how these infinitely possible keys can be derived from the first key pair.
A derivation path begins with "m". This is the master key pair, or the first key pair generated from your seed phrase. We don't usually make wallets with this key. Think of it as "Adam" from the Bible for now.
Next in the derivation path has a number, eg...
m/84'
This represents the 85th child (counting from zero) key of Adam. When the 85th key is signalled to be used, the wallet software knows it's ultimately going to be a bip84 Native Segwit wallet. There's nothing special about the 85th key, they all look the same, and they all have the same properties, it's just a signal. Don't worry about the apostrophe for now (sometimes signalled as an 'h')
The next number in the derivation path is typically 0. Eg:
m/84'/0'
This third field is a protocol for the coin type. It is the grandchild of Adam, and the first child of the 85th child of Adam. When using this key in a wallet, it signals the coin to be used is Bitcoin (rather than testnet).
The next field, the great grandchild of Adam, is the account field. It's best to leave this as zero to not confuse your heirs.
m/84'/0'/0'
The next field, the great great grandchild of Adam, is the field where a choice between receiving or change is made. Zero is receiving and One is for change. Also called "internal/external" for reasons unknown to me. This key typically won't have an apostrophy:
m/84'/0'/0'/0
And finally, the children of the change or receiving key will be used for address generation. (Note, ANY of the previous keys can generate address against protocol; remember they have no different properties). Here is the representation of the 100th address...
m/84'/0'/0'/0/99
The last integer in computer speak is held in memory as an unsigned integer, which is held in 32 bytes of memory, with a max size of 2^32, or 4.29 billion. That's plenty of children/addresses for the wallet, but that's only from one parent keypair. So the number of addresses at your disposal is effectively infinite.
Something to note is that all these keys are reproducible and already exist in mathematical space. Just because you put a seed into a software wallet and make some addresses does not mean you "created" addresses - instead, you "accessed" or "viewed" them. They are disposable until you decide to put bitcoin in them (technically, LOCK bitcoin to the address).
Anyway, the wallets software looking at the derivation path then knows which calculations and protocol to follow from the great great great grandchild key to make a Segwit address. Theoretically, it COULD ignore the protocol and use the same key to make a Legacy address, or Taproot. It's against BIP protocol, but not against BITCOIN protocol - a very important difference. The address generated is still valid as far as my node goes, but not valid in terms of wallet interoperability.