Why should one understand BIP when using a hardware wallet?

What are BIPs (Bitcoin Improvement Proposals)?

BIPs (Bitcoin Improvement Proposals) are standards for proposing changes to be collectively accepted by everyone and every node in the network (Consensus). In the early days, Bitcoin used a method of randomly generating private key and public key pairs one by one (e.g., paper wallets) and could not leverage this data to support new technologies for quick and convenient user access, which led to the development of BIPs. Understanding BIPs means understanding the "evolution" of Bitcoin. This article will provide a superficial overview to help you navigate if you decide to delve deeper into the various aspects of Bitcoin technology fundamentals.

Private Key and Seed Protection Category

BIP-38 Passphrase-protected Private Key

Before this standard, if you wrote down your Private Key (starting with 5 or K/L) on paper, anyone who saw or photographed it could instantly steal your money. BIP-38 solves this problem by "encrypting" the Private Key with a passphrase you create. The result is a new string of characters that always starts with "6P...". This string itself is not a Private Key that can be used to spend money immediately; it requires the "passphrase" to unlock it.

BIP-39 Mnemonic Code

Building on the principles of BIP-32, converting a difficult-to-remember hexadecimal Seed into the "12 or 24 words" (Seed Phrase) we use today makes it easier to remember or write down. Most users are already familiar with this.

BIP-32 Hierarchical Deterministic Wallets

Creating a key structure, from a single Seed, can branch out infinitely. We will have a set of Master keys called Root key.

• We use the Root key to calculate via HMAC-SHA512 and get Xprv and Chain code.
• We use the obtained Xprv to calculate via Trapdoor function (secp256k1) and get Xpub.
• We use Xpub, Chain code, and Derivation path to calculate via HMAC-SHA512 and get individual private and public key pairs. Each pair only differs in the Derivation path, but Xpub and Chain code are used identically.

The Derivation path structure is m / account(0) / address_index(i) (starting with 1).

BIP43 The Purpose Pillar

This principle builds upon and works in conjunction with BIP-32, by splitting a single set of data into multiple versions. This is the origin of the principle of using a Derivation path. Technically, BIP-43 proposes using "Purpose" as the first level (Level 1) of the Path structure and always as a Hardened Derivation, for security reasons, to prevent hackers from exploiting the chain code via the Xpub key. (The standard structure defined by BIP-43 is: m / purpose' / *)

Wallet Derivation Path Standard Category

BIP-44 Legacy

This applies the principles of BIP-43 and is considered the "main standard" that allows wallets worldwide to communicate effectively. It creates Legacy addresses, which have the highest fees. BIP-44 is the origin that laid the foundation for the "key derivation path" for all subsequent cryptocurrency standards, and almost all crypto projects today still use this standard. [In this format, addresses start with 1] The Derivation path structure is m / 44’ / coin_type' / account' / change / address_index

BIP-49 Nested Segwit(P2SH-P2WPKH)

The mechanism is to embed SegWit (BIP-141) inside P2SH (BIP-16) so that we can use SegWit (BIP-141) technology even if the sender or receiver is still using an old wallet that doesn't recognize SegWit. [In this format, addresses start with 3] The Derivation path structure is m / 49' / coin_type' / account' / change / address_index

BIP-84 Native SegWit (P2WSH)

Originally, BIP-49 addresses used the Base58Check format, but this version uses the Bech32 address format according to BIP-173 standards to reduce errors and increase address accuracy. [In this format, addresses start with bc1q] The Derivation path structure is m / 84' / coin_type' / account' / change / address_index

BIP-86 Pay-to-Taproot (P2TR)

This is the practical implementation of BIP-340, 341, 342, and 322. The result is that transactions look like ordinary, uncomplicated transactions because most of the script is hidden and only partially revealed. [In this format, addresses start with bc1p] The Derivation path structure is m / 86' / coin_type' / account' / change / address_index

Script, Multisig, and Basic Smart Contract Category

BIP-13,16 Pay to Script Hash (P2SH)

This is a principle created to support complex transactions using "scripts," such as creating a Multisig wallet (requiring multiple signatures for approval) or creating a TimeLock transaction (a time-locked transaction). It would not be wrong to understand this as a "smart contract" in the Bitcoin system.

BIP-45 P2SH Multisignature Wallets

This is a standard designed for "multisignature wallets" in the early days. Once we have the basics of creating scripts from BIP13,16, we can create this script format for multiple signature approvals to enhance the security of funds in the wallet. The derivation path structure is m / 45' / cosigner_index / change / address_index.

BIP-48 Multi-Script Hierarchy

Building on BIP-45 by adding script types, it can be used with both Nested Segwit (Base58) and Native Segwit (Bech32) addresses, depending on the script type. The derivation path structure is m / 48' / coin_type' / account' / script_type' / change / address_index. Nested Segwit is m / 48' / coin_type' / account' / 1' / change / address_index. Native Segwit is m / 48' / coin_type' / account' / 2' / change / address_index.

SegWit, Transaction, and PSBT Category

BIP-141 Segregated Witness (SegWit)

Building upon BIP-13 and 16, this involves separating the "signature" (Witness) from the main transaction data, allowing the original 1MB block to accommodate more transactions (theoretically expanding to 4MB). This resolves the Transaction Malleability issue and facilitates network scaling. It also serves as the foundation for the Lightning Network. The Derivation path structure is m / account(0) / address_index(i) (starting with 3).

BIP-174 Partially Signed Bitcoin Transaction(PSBT)

PSBT is a "standard file" that enables us to sign transactions offline or collaboratively with multiple parties, ensuring everyone communicates in the same language. It significantly enhances the convenience and security of Hardware Wallets and Multisig transactions. Imagine you need to create a transaction that requires 3 people to co-sign (Multisig). In the past, you'd have to exchange complex raw transaction files, which was prone to errors and difficult to read. BIP-174 solves this by creating a PSBT that acts as a "form" containing all necessary information for each party to sign without directly connecting to the blockchain.

TimeLock and Lightning Network Category

BIP-65 CHECKLOCKTIMEVERIFY (CLTV)

Building on BIP-13 and 16, we have something called nLockTime, which locks at the "transaction" level. This means the transaction cannot be broadcast to the network until a specified time. However, a drawback is that if you change your mind or lose your key during that period, it becomes very difficult to manage. BIP-65 (CLTV) solves this problem by moving the time lock to the "Script (payment conditions)." This means you can send Bitcoin to an address immediately, but those coins will be "immovable" until the time specified in the Script is reached.

BIP-68 Relative Locktime

This is the practical application of BIP-65 by specifying the time in advance as a date and time format, or as a Block height.

BIP-112 CSV - CheckSequenceVerify

Continuing from BIP-65, this is very important for creating Lightning Channels because it involves "Relative Timelock." For example, it might state, "These funds can be withdrawn 1,000 blocks after this transaction is recorded on the blockchain."

Address Format and Encoding Category

BIP-173 (Bech32)

Originally, data in the Bitcoin system was transmitted in Base58Check format, which had several drawbacks that developers wanted to fix, leading to the development of Bech32 for data transmission.

• Superior Error Detection
• Case Insensitivity
• QR codes are less dense, easier and more accurate to scan.
• More cost-effective than the previous method.

Taproot and Schnorr Category

BIP-340 Schnorr Signatures Scheme

Building upon BIP-13, 16, and 173, Bitcoin previously used ECDSA signatures (Native Segwit). However, BIP-340 introduces Schnorr Signatures, which offer superior features such as Signature Aggregation. This merges signature data, saving space, reducing fees, and making it impossible for external observers to identify multisignature transactions.

BIP-341 Taproot

Building on BIP-13, 16, and 173, this involves the evolution of message transmission from Bech32 to Bech32m, utilizing a structure called MAST (Merklized Alternative Script Trees) and Taproot Output. This allows complex transactions to appear as ordinary transactions, leading to significant space savings and excellent privacy for transaction conditions, which was not possible with Native Segwit.

BIP-342 Tapscript

Building on BIP-341 and 342, to support Schnorr and Taproot, the system needed an updated scripting language called Tapscript. Op_codes added new commands to enable faster Schnorr Signature verification. The flexibility of this technology unlocks previous Script limitations, making it easier for Bitcoin to upgrade new features in the future without requiring a Hard Fork.

Message Signing and Advanced Usage Category

BIP-322 Generic Signed Message

The most important thing in the final step is to sign the transaction. Previously, Bitcoin had a method called "Legacy Message Signing," which was often found in common wallet applications. The problem was that it didn't support Segwit and Multisig, and its security was low. BIP-322 was introduced to solve this problem, allowing it to support all address types, including Legacy, SegWit (P2SH), Native SegWit (Bech32), and Taproot (Bech32m).

Advanced Seed Management Category

BIP-85 Deterministic Derivation of Keys across Wallets

This uses the principles of BIP-32, allowing you to keep only one Master Seed and then command it to generate new Child Seeds to put into mobile apps. Previously, if you wanted to use multiple wallets, you had to keep separate sets of 12-24 word Seed Phrases, which carried a risk of loss or theft. Thus, Master Seed directly solves this problem. The Derivation path structure is m / 83696968' / setup_code' / index'. Generate 12-24 word Seed: m / 83696968' / 0' / index'. Generate WIF Seed: m / 83696968' / 1' / index'. Generate generic message: m / 83696968' / 2' / index'.

Notes

There may be some BIPs not mentioned, such as BIP-152, 157, 158, 176, which are backend mechanisms that Bitcoin users interact with daily without realizing it. Also, some BIPs may have been missed from this article. Readers are welcome to add comments.