# Supported BIPs

BIP 21: URI Scheme

BIP 32: Hierarchical Deterministic Wallets

BIP 38: Password-Protected Private Key

BIP 39: Mnemonic Code for Generating Deterministic Keys

BIP 44: Multi-Account Hierarchy for Deterministic Wallets

BIP 72: bitcoin: uri extensions for Payment Protocol

BIP 84 defines a standard derivation scheme for hierarchical deterministic wallets BIP 32, specifically for segregated witness P2WPKH BIP 173. This allows to generate one root master seed that can derive a tree of public keys with different paths BIP 44. m / purpose' / coin_type' / account' / change / address_index. Wasabi specifically uses this standard m/84'/0'/0'. On the TestNet and on the RegTest Wasabi deviates from the standard and uses m/84'/0'/0' instead of m/84'/1'/0'.

BIP 141: Segregated Witness (Consensus Layer)

BIP 142: Address Format for Segregated Witness

BIP 143: Transaction Signature Verification for Version 0 Witness Program

BIP 144: Segregated Witness (Peer Services)

BIP 158 Block filters are the reverse of BIP 37 Bloom filters - the client will connect to a Bitcoin node and say "Hey, for every block, I would like a condensed list of addresses that were affected." What would happen next is that a Bitcoin node would give the same filter that it gives to every client, because the client has thus far revealed nothing! Once a block filter has come in and the client believes that there is a transaction that affects the client, the client pings a single random node for a single full block. It then parses the block, and finds the transaction. This has been proven to be by far the best way to do light clients privately, and is the way Wasabi works today.

BIP 173: Base32 address format for native v0-16 witness outputs

BIP 174: Partially Signed Bitcoin Transaction Format

Hardware Wallet Interface

BIP 47 defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.

This BIP is a particular application of BIP 43 and is intended to supplement HD wallets which implement BIP44.

BIP 156 Dandelion is a transaction routing mechanism that provides formal anonymity guarantees against attacks on Bitcoin's transaction spreading protocol. When a node generates a transaction without Dandelion, it transmits that transaction to its peers with independent, exponential delays. This approach, known as diffusion in academia, allows network adversaries to link transactions to IP addresses.

Dandelion mitigates this class of attacks by sending transactions over a randomly selected path before diffusion. Transactions travel along this path during the "stem phase" and are then diffused during the "fluff phase" (hence Dandelion). We have shown that this routing protocol provides near-optimal anonymity guarantees among schemes that do not introduce additional encryption mechanisms.

BIP 157 describes a new light client protocol in Bitcoin that improves upon currently available options. The standard light client protocol in use today, defined in BIP 37, has known flaws that weaken the security and privacy of clients and allow denial-of-service attack vectors on full nodes. The new protocol overcomes these issues by allowing light clients to obtain compact probabilistic filters of block content from full nodes and download full blocks if the filter matches relevant data.

New P2P messages empower light clients to securely sync the blockchain without relying on a trusted source. This BIP also defines a filter header, which serves as a commitment to all filters for previous blocks and provides the ability to efficiently detect malicious or faulty peers serving invalid filters. The resulting protocol guarantees that light clients with at least one honest peer are able to identify the correct block filters.

BIP 322 is a standard for interoperable generic signed messages based on the Bitcoin Script format.

BIP Schnorr is a digital signature scheme which has many benefits over the status-quo ECDSA. One advantage is that any N-of-N and M-of-N multisignature can be easily made to look like a single-sig when included on the blockchain.

BIP Taproot is a way to combine Schnorr signatures with MAST. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as Lightning Network, CoinSwap, multisignature, etc would appear indistinguishable from regular single-signature on-chain transaction.

The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.

BIP Tapscript defines a slight variation on Bitcoin’s existing Script language to be used in BIP Taproot merkle spends.

BIP 37 Bloom filters are filters that a client will send to a Bitcoin full node which says "Hey, if you see any transactions that get caught in these filters, they may or may not be mine!". What would happen next is that a Bitcoin node would start sending tons and tons of transactions to the client, and the client would proceed to distinguish the 99% irrelevant transactions against the 1% relevant ones. This was quite brilliant of an idea at the time, but has since been proven to not protect user privacy, at the expense of wasting a ton of bandwidth and subjecting users to other risks.

BIP 69: Lexicographical Indexing of Transaction Inputs and Outputs

BIP 70: Payment Protocol

BIP 125: Opt-In full Replace-by-Fee Signaling