# UTXOHub — every answer > Every glossary term's answer and every BIP's explainer, as utxohub.com gives them. For the API surfaces — the MCP server and the JSON endpoints — read https://utxohub.com/llms.txt. ## Glossary ### What is a satoshi (sat)? The smallest unit of bitcoin: one hundred-millionth of a bitcoin. 100,000,000 sats make 1 BTC. Bitcoin amounts are recorded in whole satoshis, named after Bitcoin's creator, Satoshi Nakamoto. People usually call them sats. Small amounts and fees are easier to read in sats: 0.00021 BTC is 21,000 sats. Page: https://utxohub.com/glossary/satoshi ### What is a Bitcoin address? A string of letters and numbers that tells someone where to send you bitcoin, a bit like an account number for one payment. An address is made from your wallet's keys, so only your wallet can spend what's sent to it. Depending on its type, it starts with 1, 3, bc1q or bc1p. The sending and receiving wallets or services must support that address type. A fresh address makes payments harder to link. Public-key exposure is separate: legacy and SegWit v0 addresses usually keep the key hidden until spending, while a Taproot address includes an output public key from the start. Sources: - Bitcoin Improvement Proposals: BIP-341: Taproot: SegWit version 1 spending rules. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Page: https://utxohub.com/glossary/address ### What is a transaction ID? A 64-character code that identifies one Bitcoin payment, so anyone can look it up. Every payment has an ID, also called a txid or hash, worked out from the payment's own data. Your wallet or exchange shows it once you've sent. Paste it into UTXOHub to see its current confirmation status, outputs and other public transaction details. Page: https://utxohub.com/glossary/transaction-id ### What is a UTXO? An unspent transaction output: an amount of bitcoin left by a transaction, with rules for spending it. A transaction creates outputs, each with an amount and spending conditions. A UTXO is an output that has not been spent. An ordinary wallet adds up the outputs it controls to show a balance; pending payments and other restrictions can affect what is available to send. A payment spends whole UTXOs and creates new outputs. If an input is larger than the payment and fee, the wallet usually creates another output for the change. The old output is spent once; the change is a new UTXO. This is where UTXOHub gets its name. Unspent does not always mean spendable now. An output may have a time lock, require several signatures, or belong to someone who has lost the keys. Many outputs use addresses, but an address is not the output itself and can receive several separate UTXOs. Sources: - Bitcoin Developer Guide: Transactions. https://developer.bitcoin.org/devguide/transactions.html - Bitcoin Core 30.0: getbalances. https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/ - Bitcoin Improvement Proposals: BIP-65: Time-locked outputs. https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki Page: https://utxohub.com/glossary/utxo ### What is the UTXO set? The unspent outputs a Bitcoin node keeps track of to check new payments against its accepted blockchain. The UTXO set records the current unspent outputs, identified by the transaction that created each one and its output number. It leaves out outputs that are provably impossible to spend. As a node connects a block, it removes outputs spent in that block and adds the new ones that remain unspent. The blockchain retains the transaction history; the UTXO set is the current state needed to check spending. The confirmed set is separate from the mempool, where a node also tracks waiting transactions and their effects on which outputs can be spent. Sources: - Bitcoin Core 30.0: Adding and spending coins in the UTXO cache. https://github.com/bitcoin/bitcoin/blob/v30.0/src/coins.cpp Page: https://utxohub.com/glossary/utxo-set ### What is coin control? A wallet feature that lets you choose which unspent outputs to use in a payment. Wallets normally choose a payment’s inputs automatically. Coin control lets you select particular UTXOs instead. Not every wallet exposes this choice. The choice affects the transaction’s size and fee, and which parts of your history are linked together. Selecting coins does not hide the transaction or guarantee privacy. Sources: - Sparrow Wallet: How do I use coin control?. https://sparrowwallet.com/docs/faq.html#how-do-i-use-coin-control - Sparrow Wallet: Spending Privately. https://sparrowwallet.com/docs/spending-privately.html Page: https://utxohub.com/glossary/coin-control ### What is UTXO consolidation? Spending several outputs into fewer outputs in your own wallet, paying a fee now to simplify later spending. Consolidation combines several UTXOs in a transaction back to your own wallet. The new outputs total less than the inputs because of the fee. Having fewer outputs can reduce the inputs needed in a later payment. Whether this saves money depends on the fees now, the fees later and what you actually spend. Combining outputs also publicly links their histories, so it has a privacy cost. Sources: - Bitcoin Developer Guide: Transactions. https://developer.bitcoin.org/devguide/transactions.html - Sparrow Wallet: Spending Privately. https://sparrowwallet.com/docs/spending-privately.html Page: https://utxohub.com/glossary/utxo-consolidation ### What are inputs and outputs in a Bitcoin payment? Ordinary payments spend previous outputs as inputs and create new outputs. Coinbase transactions, which create miner rewards, are the exception. In an ordinary payment, each input points to an earlier output and carries proof that the sender may spend it. Each output gives an amount and spending conditions, often through an address. The coinbase transaction in a block does not spend a previous output. For an ordinary payment, any difference between the input total and the output total is the fee, which the miner can claim. Sources: - Bitcoin Developer Guide: Block Chain. https://developer.bitcoin.org/devguide/block_chain.html Page: https://utxohub.com/glossary/inputs-and-outputs ### What is change in a Bitcoin payment? The part of a payment that goes back to the sender, because wallets spend whole pieces of bitcoin, like getting change from a note. If your wallet holds a 0.1 BTC piece and you pay 0.03 BTC, it spends the whole piece and sends the rest, minus the fee, back to a new address of yours. A payment can have a recipient output and a change output, but transactions can also pay several recipients, consolidate inputs or create data outputs. Nothing on the blockchain labels which output is change. Page: https://utxohub.com/glossary/change ### What is a fee rate (sat/vB)? The fee a payment offers for each unit of block space, in satoshis per virtual byte. Miners can evaluate related transactions together. Read 4 sat/vB as “4 satoshis per virtual byte”. Space in a block is limited, so the fee depends on a payment's size, not on how much it sends. In a made-up example, a 140-vB payment at 4 sat/vB pays 560 sats. A virtual byte is a measure of block space. Since the SegWit upgrade, witness data counts at a quarter of its real size, so its contribution to virtual size is smaller than its byte size. When lots of people are sending at once, the rate needed to get into the next block can rise. UTXOHub shows fees in dollars first, then sat/vB. Most wallets let you set the fee in sat/vB (some write sat/vbyte), so that's the number to compare with yours. Miners can evaluate related unconfirmed transactions together, so a payment's own rate is not always the whole picture. A higher individual or package fee rate can improve the chance of selection, but cannot guarantee it. Sources: - Bitcoin Improvement Proposals: BIP-141: Segregated Witness (Consensus layer). https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki - Bitcoin Core: Package Mempool Accept. https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md Page: https://utxohub.com/glossary/fee-rate ### What is the mempool? The waiting room for Bitcoin transactions that have been sent but aren't in a block yet. Each Bitcoin node keeps its own list of valid transactions that haven't confirmed: its memory pool, or mempool. Miners can evaluate related transactions together, rather than simply taking the highest individual fee rates first. Bitcoin Core's default mempool expiry time is two weeks. Expiry removes a payment from that node's waiting list; it does not cancel the payment. Other nodes may keep it, and a wallet may broadcast it again. Until a conflicting transaction confirms, it can still be included later. A payment with zero confirmations is not final. Sources: - Bitcoin Core: src/kernel/mempool_options.h Source File. https://doxygen.bitcoincore.org/mempool__options_8h_source.html Page: https://utxohub.com/glossary/mempool ### What is a Bitcoin block? A batch of transactions added to Bitcoin's shared record, about every 10 minutes on average. Miners compete to add the next block. Each block links to the one before it, which is why the record is called a blockchain. Changing an old block would mean redoing all the work since. Blocks are numbered by height, starting from 0 in 2009. Each one has room for a few thousand payments. Page: https://utxohub.com/glossary/block ### What is a Bitcoin confirmation? A payment has one confirmation once it's in a block, and one more for each block after. The more it has, the harder it is to reverse. With no confirmations, a payment is still waiting and is not final; it may be replaced. Once it's in a block, a chain reorganisation can still remove it. Reversing it would mean out-mining the rest of the network, and that gets harder with every block added. Each service chooses how many confirmations it requires before crediting a deposit, and may apply other checks. Follow the recipient's policy rather than assuming one number fits every payment. Sources: - Bitcoin Developer Guide: Block Chain. https://developer.bitcoin.org/devguide/block_chain.html Page: https://utxohub.com/glossary/confirmation ### What is a Bitcoin miner? A computer, or a pool of them, that bundles waiting transactions into blocks and secures the network, paid in new bitcoin and fees. Miners race to find a block whose fingerprint, its hash, is small enough. It takes enormous trial and error, and that work is what makes rewriting Bitcoin's history so costly. The winner earns the block reward: new bitcoin, plus the fees of the payments it included. Most miners join pools that share the work and the rewards. Page: https://utxohub.com/glossary/miner ### What is Bitcoin's hashrate? How many guesses a second all of Bitcoin's miners make together. More hashrate makes the network harder to attack. Each guess is a hash: a fingerprint of a possible block. The network's total is measured in exahashes a second (EH/s), each a billion billion guesses, and above a thousand of those in zettahashes a second (ZH/s). Whatever the hashrate, Bitcoin adjusts its difficulty so that blocks keep arriving about every 10 minutes. Page: https://utxohub.com/glossary/hashrate ### What is Bitcoin mining difficulty? How hard it is to mine a block. Bitcoin resets it every 2,016 blocks, about two weeks, so blocks keep coming about every 10 minutes. If the last 2,016 blocks came faster than every 10 minutes on average, difficulty goes up; if slower, it goes down. Each change is limited to a factor of four either way. A rise means each hash has a lower chance of meeting the target. It does not directly change the block subsidy or the fees paid by transactions. Sources: - Bitcoin Developer Guide: Block Chain: Proof Of Work. https://developer.bitcoin.org/devguide/block_chain.html#proof-of-work Page: https://utxohub.com/glossary/difficulty ### What is the Bitcoin halving? Every 210,000 blocks, about every four years, the new bitcoin created in each block is cut in half. Miners earned 50 bitcoin per block in 2009. After four halvings, they earn 3.125. The next halving is due at block 1,050,000. The subsidy eventually falls to zero because amounts are recorded in whole satoshis. This limits total issuance to just under 21 million bitcoin; uneven block times mean there is no exact calendar end date. Sources: - Bitcoin Core: GetBlockSubsidy in src/validation.cpp. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp - Bitcoin Core: nSubsidyHalvingInterval in src/kernel/chainparams.cpp. https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp Page: https://utxohub.com/glossary/halving ### What is a Bitcoin node? A computer running Bitcoin software that checks every payment and block against the rules, and passes them on to others. Nodes need no permission and trust no one: each checks everything for itself. That's what stops anyone, miners included, from breaking the rules. Running your own node lets you check your own payments without relying on anyone else's word. Page: https://utxohub.com/glossary/node ### What is Bitcoin Core? The most widely run Bitcoin software: a full node that checks every block and payment, with a wallet built in. It grew from Satoshi's first version. Bitcoin Core is free, open-source software that runs a full node: it downloads every block, checks it against Bitcoin's rules and passes valid payments on to other nodes. It also has a wallet and a desktop app. The project calls it “a direct descendant” of the program Satoshi Nakamoto released in 2009. No company owns it. Anyone can propose a change on GitHub, and other contributors review and test it. A few maintainers can merge changes, a job the project describes as “janitorial”: merging what contributors agree on. Running it is voluntary, so a new version only changes anything for the people who install it. Bitcoin Core aims for a major release every six or seven months, such as 31.0 in April 2026 and 32.0 on 27 October 2026, with maintenance releases such as 32.1 for fixes in between. The latest three major versions get fixes. A change to the consensus rules always ships first in a maintenance release. Its defaults shape what most nodes relay, so changes to them get argued over: 30.0, in October 2025, raised the limit on OP_RETURN data from 83 bytes to 100,000. On 8 November 2026, 18,480 of the 20,645 reachable nodes Bitnodes counted ran Bitcoin Core. Sources: - Bitcoin Core: About. https://bitcoincore.org/en/about/ - Bitcoin Core: Software life cycle. https://bitcoincore.org/en/lifecycle/ - Bitcoin Core: Bitcoin Core 30.0 Release Notes. https://bitcoincore.org/en/releases/30.0/ - Bitnodes: Reachable Bitcoin nodes (snapshot of 8 November 2026, 12:50 UTC). https://bitnodes.io/nodes/ Page: https://utxohub.com/glossary/bitcoin-core ### What is Bitcoin Knots? A version of Bitcoin Core, led by Luke Dashjr, that filters more kinds of data by default. Since September 2026 its new releases follow a separate chain. Bitcoin Knots is a full node and wallet built from Bitcoin Core's code, with changes of its own added. Luke Dashjr, who has worked on Bitcoin's software since 2011, is its lead maintainer. Most of its code still comes from Core: development “generally takes place as part of Bitcoin Core, and is merged into Knots for each release”, its README says. Its default relay policy is stricter than Core's. Knots keeps an 83-byte limit on data and applies it “to all known datacarrier methods”, not only OP_RETURN outputs. It refuses to relay or mine what it calls “parasitic overlay protocols” and “transactions involving non-bitcoin tokens”, and passes on nothing under 1 sat/vB, where Core's floor is 0.1. Dashjr calls this data spam, and argues filters make it “unwelcome and costly” even if they don't stop all of it. Thirty-one Bitcoin Core contributors answered in June 2025 that refusing transactions miners “would include in blocks anyway” pushes people to send them to miners directly, and that the filters are “relatively easy” to get round. Each node's operator chooses its policy. Dashjr also wrote the first draft of BIP-110, a temporary limit on data written into the rules themselves, and its code was built on Knots. Miners didn't adopt it, and nodes enforcing it split off on 8 August 2026. Knots 29.4.1, released on 2 September 2026, is a hard fork with a new proof of work, so from that version on Knots follows a different chain from Bitcoin Core. Its release notes call the chain most miners kept “a new altcoin”; more than 99% of mining power stayed on it, Crowdfund Insider reported, and UTXOHub shows that chain. Older Knots versions follow it too: of the 2,097 reachable nodes Bitnodes counted as Knots on 8 November 2026, almost all ran versions from before 29.4.1, at the same block height as Core. Sources: - Bitcoin Knots on GitHub: README: What is Bitcoin Knots?. https://github.com/bitcoinknots/bitcoin/blob/v29.5.knots20260508/README.md - Bitcoin Knots on GitHub: Relay defaults in src/policy/policy.h (29.5). https://github.com/bitcoinknots/bitcoin/blob/v29.5.knots20260508/src/policy/policy.h - Bitcoin Knots on GitHub: Relay settings in src/init.cpp (29.5). https://github.com/bitcoinknots/bitcoin/blob/v29.5.knots20260508/src/init.cpp - Bitcoin Core: Bitcoin Core 29.1 Release Notes. https://bitcoincore.org/en/releases/29.1/ - Bitcoin developers' mailing list (0xB10C's mirror): Luke Dashjr, reply on removing OP_RETURN limits (26 April 2025). https://mirror.b10c.me/lists/bitcoindev/03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org/ - Bitcoin Core: Bitcoin Core development and transaction relay policy (6 June 2025). https://bitcoincore.org/en/2025/06/06/relay-statement/ - Bitcoin Improvement Proposals: BIP-110: Reduced Data Temporary Softfork. https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki - Bitcoin Knots on GitHub: Bitcoin Knots v29.4.1.knots20260508 (release notes). https://github.com/bitcoinknots/bitcoin/releases/tag/v29.4.1.knots20260508 - Crowdfund Insider: BIP-110 fork restarts after stall, shrinks block sizes to 300 KB (1 September 2026). https://www.crowdfundinsider.com/2026/09/304479-bitcoin-improvement-proposal-bip-110-fork-restarts-after-stall-shrinks-block-sizes-to-300-kb/ - Bitnodes: Reachable Bitcoin nodes (snapshot of 8 November 2026, 12:50 UTC). https://bitnodes.io/nodes/ Page: https://utxohub.com/glossary/bitcoin-knots ### What is a private key? The secret number that lets you spend your bitcoin. Whoever knows it controls the coins, so it must never be shared. Your wallet signs each payment with your private key. The signature proves you may spend the coins without revealing the key itself. For many single-signature wallets, one set of recovery words can regenerate its derived keys. Imported keys, multisig setups and some account or wallet metadata may need separate backups. Page: https://utxohub.com/glossary/private-key ### What is a public key? The partner of a private key. It lets anyone check a signature without revealing the private key under current computing assumptions. Your public key is made from your private key with one-way maths on an elliptic curve. No known ordinary-computer method can reverse it efficiently; in theory, a large enough quantum computer could. Legacy and SegWit v0 addresses generally show a fingerprint until a spend reveals the key, including while that spend is unconfirmed. Taproot addresses include an output public key from the start. Sources: - Bitcoin Improvement Proposals: BIP-341: Taproot: SegWit version 1 spending rules. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Page: https://utxohub.com/glossary/public-key ### What are recovery words (a seed phrase)? A list of 12, 15, 18, 21 or 24 words that can restore wallet keys. Anyone who has them can take your bitcoin. Many wallets follow BIP-39, which permits those five lengths. The words encode a random number from which the wallet's seed and derived keys are made. Write them down and keep them offline. Never give them to a support agent, explorer or unsolicited website. Enter them only when you have deliberately chosen to restore your own wallet in trusted software, and check that the software is genuine first. Sources: - Bitcoin Improvement Proposals: BIP-39: Mnemonic code for generating deterministic keys. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Page: https://utxohub.com/glossary/recovery-words ### What is a Bitcoin wallet? An app or device that holds your keys and makes, signs and sends payments. The bitcoin itself stays on the blockchain. A wallet doesn't store coins. It stores the keys that can spend them, and works out your balance by adding up the pieces of bitcoin those keys control. If an exchange holds the keys for you, you're trusting the exchange. With a self-custody wallet, only you hold them. Page: https://utxohub.com/glossary/wallet ### What is an xpub (extended public key)? An extended public key for one branch of a wallet. It reveals addresses and payments in that branch, but cannot by itself spend them. Defined in BIP-32, an xpub lets a wallet or watch-only app derive the non-hardened public keys below it without holding the private keys. A wallet can use several xpubs and other key material, so one xpub does not necessarily cover every account. Treat it as private: it can reveal the history, balance and public keys for its own derivation subtree. Sources: - Bitcoin Improvement Proposals: BIP-32: Hierarchical Deterministic Wallets. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki Page: https://utxohub.com/glossary/xpub ### What is address reuse, and why avoid it? Receiving bitcoin more than once to the same address. It links those payments together publicly and can harm your privacy. Wallets can make a fresh address for every payment. Reusing one makes its payments easier to link, although the blockchain alone does not prove who controls it. Public-key exposure depends on the address type. Legacy and SegWit v0 addresses normally reveal the key when spending, while Taproot output keys are already visible. Exposed keys would be among the first at risk if quantum computers ever become powerful enough to break them. Sources: - Bitcoin.org: Protect your privacy. https://bitcoin.org/en/protect-your-privacy - Bitcoin Improvement Proposals: BIP-341: Taproot: SegWit version 1 spending rules. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Page: https://utxohub.com/glossary/address-reuse ### What is replace-by-fee (RBF)? A way to replace an unconfirmed payment with a conflicting version that pays a higher fee. Only one can remain in the same valid chain. Wallets call it Speed up or Bump fee. The replacement spends at least one of the same inputs, so it conflicts with the original. Once one version confirms, the other cannot be added to the same valid chain. Bitcoin Core 28.0 made full RBF the default, so its mempool permits replacement even when the original did not signal opt-in RBF. Wallet support and other policy rules still apply, and the original may confirm before the replacement. The replacement has a new transaction ID. Compare its outputs and status; a replacement is not necessarily only a fee increase. Sources: - Bitcoin Improvement Proposals: BIP-125: Opt-in Full Replace-by-Fee Signaling. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki - Bitcoin Core: Bitcoin Core 28.0 Release Notes. https://bitcoincore.org/en/releases/28.0/ Page: https://utxohub.com/glossary/rbf ### What is child pays for parent (CPFP)? A way to make an unconfirmed parent and a child that spends it more attractive to miners as a package. Confirmation is not guaranteed. The child pays enough fee to raise the fee rate of the parent and child together. Miners can evaluate the package, so both may be selected even if the parent's own fee rate is low. A receiver may be able to create the child if their wallet supports spending the unconfirmed output. Senders can sometimes use CPFP too. Wallet support, the available output, fees and network policy all matter, and no package is guaranteed to confirm. Sources: - Bitcoin Core: Package Mempool Accept. https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md Page: https://utxohub.com/glossary/cpfp ### What is SegWit? Segregated Witness: a 2017 upgrade that moved signatures into a separate part of each payment, making room for more payments. It switched on in August 2017, at block 481,824. Addresses starting bc1q are SegWit addresses, and payments from them cost less in fees. It also fixed transaction malleability, the way a payment's ID could be changed before it confirmed, which helped later layers like the Lightning Network. Sources: - Bitcoin Improvement Proposals: BIP-141: Segregated Witness (Consensus layer). https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki Page: https://utxohub.com/glossary/segwit ### What is Taproot? A 2021 upgrade that added Schnorr signatures and addresses starting bc1p, making complex payments cheaper and more private. It switched on in November 2021, at block 709,632. A Taproot payment can keep its spending conditions hidden unless they're used, and a payment signed by many people can look like one signed by one. Taproot addresses put a public key straight on the blockchain, so they're among the outputs a powerful quantum computer could attack first. That's one reason for proposals like BIP-360. Sources: - Bitcoin Improvement Proposals: BIP-341: Taproot: SegWit version 1 spending rules. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki - Bitcoin Improvement Proposals: BIP-340: Schnorr Signatures for secp256k1. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki Page: https://utxohub.com/glossary/taproot ### What is a Schnorr signature? A kind of digital signature Bitcoin added with Taproot in 2021. Several people can combine keys so their joint signature looks like one person's. A digital signature proves that the owner of a private key approved a payment. Bitcoin used a method called ECDSA from 2009, and the Taproot upgrade of November 2021 added Schnorr signatures, named after the German mathematician Claus Peter Schnorr and defined for Bitcoin in BIP-340. They work with the same keys, and each one is a fixed 64 bytes. Their most useful property is that keys and signatures can be added together. With a scheme such as MuSig2 (BIP-327), a group who must all sign can make one shared key and one joint signature, so their payment looks like an ordinary one from a single person and costs less. Like ECDSA, Schnorr signatures rely on elliptic-curve maths that a large enough quantum computer could, in theory, undo. Sources: - Bitcoin Improvement Proposals: BIP-340: Schnorr Signatures for secp256k1. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki - Bitcoin Improvement Proposals: BIP-327: MuSig2 for BIP340-compatible Multi-Signatures. https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki - Bitcoin Optech: Schnorr signatures. https://bitcoinops.org/en/topics/schnorr-signatures/ Page: https://utxohub.com/glossary/schnorr-signature ### What is a soft fork? A change that tightens Bitcoin's rules, so nodes that haven't upgraded still accept the new blocks. Because older software keeps working, a widely adopted soft fork doesn't split the network. SegWit and Taproot were both soft forks. Proposing one is easy. Switching one on needs very wide agreement among users, node operators and miners, and has usually taken years. Page: https://utxohub.com/glossary/soft-fork ### What is a BIP (Bitcoin Improvement Proposal)? A public document describing a proposed change to Bitcoin, or a standard that wallets can follow. Anyone can write one. BIPs are discussed openly, numbered and given a status, such as Draft or Final. Being published doesn't mean a change is happening: rule changes need very wide agreement. Some are rules for every node, like Taproot. Others are standards wallets choose to follow, like recovery words. Sources: - GitHub: bitcoin/bips: Bitcoin Improvement Proposals. https://github.com/bitcoin/bips Page: https://utxohub.com/glossary/bip ### What is pay-to-public-key (P2PK)? The earliest kind of Bitcoin payment, which locked coins straight to a public key and left that key on show. Early mining rewards, including the coins thought to be Satoshi's, were paid this way. Many later address types hide the key behind a fingerprint until spending; Taproot addresses instead include an output key from the start. Because the key is visible, P2PK coins would be among the first a powerful quantum computer could target. About 1.7 million bitcoin sit in them, by one developer's count. Sources: - Delving Bitcoin: Hourglass V2 Update. https://delvingbitcoin.org/t/hourglass-v2-update/2246 Page: https://utxohub.com/glossary/p2pk ### What is a digital signature in Bitcoin? Proof, made with a private key, that the owner approved a payment. Anyone can check it; practical forgery is infeasible under current assumptions. Bitcoin has used a signature scheme called ECDSA since 2009. Since Taproot it also uses Schnorr signatures, which are simpler and let several signers combine into one. Both rely on elliptic-curve maths that, in theory, a large enough quantum computer could undo. Sources: - Bitcoin Improvement Proposals: BIP-340: Schnorr Signatures for secp256k1. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki Page: https://utxohub.com/glossary/digital-signature ### What is secp256k1, Bitcoin's elliptic curve? The curve y² = x³ + 7, whose maths turns a private key into a public key that ordinary computers cannot reverse efficiently. Bitcoin uses an elliptic curve called secp256k1, from a 2000 standard by an industry group. Its numbers were chosen in a predictable way, not from an unexplained seed. It isn't one of the NIST curves that many websites use. Sources: - Certicom Research, Standards for Efficient Cryptography Group: SEC 2: Recommended Elliptic Curve Domain Parameters, version 2.0. https://www.secg.org/sec2-v2.pdf Page: https://utxohub.com/glossary/elliptic-curve ### What is a quantum computer, and what is a qubit? A computer that uses quantum physics to solve some problems far faster than ordinary ones. Its working parts are called qubits. Ordinary bits are 0 or 1. Qubits can hold a mix of both, which lets some calculations, including the one behind Bitcoin's keys, be done in a radically different way. Practical machines have limits in qubit count and error rates. In March 2026, Google estimated that breaking a Bitcoin-style key would take fewer than 500,000 physical qubits. That was an estimate of future requirements, not a demonstration. Sources: - Google Research: Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly. https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/ Page: https://utxohub.com/glossary/quantum-computer ### What is Shor's algorithm? A method, published by Peter Shor in 1994, that would let a large quantum computer work out a private key from its public key. Shor's algorithm would let a sufficiently large, reliable quantum computer solve the maths behind a Bitcoin public key far more efficiently than known ordinary-computer methods. The 1994 paper does not provide a running-time estimate for any present-day machine. That's why Bitcoin developers are debating new kinds of signatures and addresses that don't rely on elliptic curves. Sources: - Peter W. Shor, arXiv: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. https://arxiv.org/abs/quant-ph/9508027 Page: https://utxohub.com/glossary/shors-algorithm ### What is the Lightning Network? A network built on Bitcoin for payments through channels, without recording every payment as its own blockchain transaction. People route payments between linked payment channels. Opening or closing a channel can create a Bitcoin transaction, but the payments inside the channel usually do not appear individually on a Bitcoin explorer. A Lightning invoice or payment hash is not a Bitcoin transaction ID. Check the payment in the Lightning wallet or service used, and confirm which network the sender chose. Sources: - Lightning Labs: Payment Channels. https://docs.lightning.engineering/the-lightning-network/payment-channels Page: https://utxohub.com/glossary/lightning-network ### What is the difference between Bitcoin mainnet and test networks? Mainnet is Bitcoin's live network. Test networks let people try software with coins that are not intended to have real value. Bitcoin Core uses mainnet unless you select another network. Testnet and signet are public test networks with separate chains and coins; regtest is a local testing mode. Check the network shown by both wallets before sending or searching. A test-network transaction is not a mainnet transaction, and test coins are not mainnet bitcoin. Sources: - Bitcoin Developer Examples: Testing Applications. https://developer.bitcoin.org/examples/testing.html - Bitcoin Improvement Proposals: BIP-325: Signet. https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki Page: https://utxohub.com/glossary/mainnet ### What is a Bitcoin chain reorganisation (reorg)? A replacement of recent blocks when nodes switch to a valid chain with more accumulated work. Recent confirmations can change. Competing valid blocks can appear at the same height. Nodes follow the valid chain with the most accumulated proof of work, so a previous chain tip can be replaced. A transaction in a replaced block may return to the mempool or appear in the new chain. More confirmations make this kind of reversal harder; zero confirmations is not final either. Sources: - Bitcoin Developer Guide: Block Chain: Block Height And Forking. https://developer.bitcoin.org/devguide/block_chain.html#block-height-and-forking Page: https://utxohub.com/glossary/chain-reorganisation ### What is proof of work? A puzzle that takes a computer real effort to solve, so the answer proves the effort was spent. Bitcoin’s miners use it to add each block. To add a block, a miner has to find a version of it whose fingerprint, its hash, begins with enough zeros. The only way is to keep trying, so miners make enormous numbers of attempts every second. Anyone can check a winning answer with a single try. That effort is what protects Bitcoin’s history. Nodes follow the valid chain with the most accumulated work, so to change an old block an attacker would have to redo its work and the work of every block after it, and overtake everyone else. The white paper calls proof of work “essentially one-CPU-one-vote”. The idea came from hashcash, which Adam Back invented in 1997 to make each email cost its sender a little computing effort, to deter spam. The Bitcoin white paper builds on “a proof-of-work system similar to Adam Back’s Hashcash”. The same race meters out new bitcoin: whichever miner wins a block claims its reward. Sources: - Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf - hashcash.org: Hashcash. http://www.hashcash.org/ Page: https://utxohub.com/glossary/proof-of-work ### What is a double spend? An attempt to spend the same bitcoin twice. The accepted chain can hold only one of the conflicting transactions. Each piece of bitcoin can be spent only once. A double spend is two conflicting transactions that try to spend the same piece. The accepted chain can include only one of them; nodes drop the other. While a payment has no confirmations, replacing it is sometimes possible. Once confirmed it is much harder to replace, but not impossible: in a chain reorganisation, recent blocks are swapped for a longer chain, and a conflicting transaction can confirm there instead. Each further confirmation makes that less likely, which is why people wait for more of them on large amounts. Sources: - Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf - Bitcoin Developer Guide: Block height and forking. https://developer.bitcoin.org/devguide/block_chain.html#block-height-and-forking Page: https://utxohub.com/glossary/double-spend ### What is dust in Bitcoin? A very small bitcoin output. Bitcoin Core defines a dust threshold; whether spending an output is worthwhile also depends on current fees. Spending an output adds data and therefore fees. People often call an output dust when the extra fee to spend it would eat up its value. That cost changes with the fee rate and the output’s spending rules. Bitcoin Core’s policy uses a dust threshold based on output type and a configured dust relay fee rate. It is not the current market fee rate. Outputs above the threshold can still be uneconomical to spend. Relay policy generally discourages new dust outputs, with limited exceptions; it is not a consensus ban. A dusting attack sends dust to many addresses, hoping to link their owners by watching how the dust is later spent. Receiving dust gives the sender no access to your coins. Sources: - Bitcoin Core 30.0: GetDustThreshold in src/policy/policy.cpp. https://github.com/bitcoin/bitcoin/blob/v30.0/src/policy/policy.cpp - Bitcoin Core 29.0: Ephemeral dust relay policy. https://bitcoincore.org/en/releases/29.0/#mempool-policy-and-mining-changes Page: https://utxohub.com/glossary/dust ### What is an OP_RETURN output? A payment output that stores data instead of paying someone. It can never be spent, so nodes don't track it as spendable. OP_RETURN is an instruction that marks an output as provably unspendable, with room for a piece of data. Services use it to anchor timestamps, proofs and protocol messages in the chain, and nodes can leave it out of their set of spendable coins. How much data nodes should pass along has long been argued. Bitcoin Core 30.0, in October 2025, raised its default relay limit from 83 bytes to 100,000 and allowed several such outputs per payment. That is relay policy, not a rule change: what a block may contain is unchanged, and operators can set the old limit back. Sources: - Bitcoin Core: Bitcoin Core 30.0 Release Notes. https://bitcoincore.org/en/releases/30.0/ Page: https://utxohub.com/glossary/op-return ### What is a Bitcoin transaction accelerator? A service, usually run by a mining pool, that tries to include a stuck payment in its next block, sometimes for a charge. Some mining pools take a transaction ID out of band and try to include that payment in the blocks they mine. Free places are usually limited, and paid ones are priced by the payment's size rather than its amount. An accelerator works only when its pool finds a block, so it cannot guarantee confirmation. Replace-by-fee and child-pays-for-parent do the same job through the network itself, without trusting anyone. An accelerator needs only your transaction ID, which is public. Anyone asking for keys or recovery words is a scam. Page: https://utxohub.com/glossary/transaction-accelerator ### What is a BIP-39 passphrase? An extra word or sentence added to recovery words, which creates a completely different wallet. Losing it means the words alone cannot help. BIP-39 lets you add a passphrase of your own choosing on top of your recovery words. The same words with a different passphrase, or none, derive different keys: a separate wallet with its own addresses and balance. People use one as a second secret, or to keep a decoy wallet on the words alone. A wrong passphrase does not fail: it opens a different, usually empty, wallet. Keep it written down separately from the words. Sources: - Bitcoin Improvement Proposals: BIP-39: Mnemonic code for generating deterministic keys. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Page: https://utxohub.com/glossary/passphrase ### What is a derivation path (m/84'/0'/0')? The route a wallet follows to turn one seed into many keys, written like m/84'/0'/0'. A different path gives different addresses. A modern wallet holds one seed and derives its keys in a tree. The path notes which branch: purpose, coin type, account, change and index, separated by slashes. m/84'/0'/0', for example, marks a SegWit account under BIP-84. This explains a common scare: recovery words restored in a different wallet can show an empty balance, because the new wallet may look along a different path. Wallets document the paths they use. Sources: - Bitcoin Improvement Proposals: BIP-32: Hierarchical Deterministic Wallets. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki - Bitcoin Improvement Proposals: BIP-44: Multi-Account Hierarchy for Deterministic Wallets. https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki Page: https://utxohub.com/glossary/derivation-path ### What is cold storage? Keeping your keys on something that never touches the internet, such as a hardware wallet. An online wallet is a hot wallet. A payment is signed wherever the keys are. With cold storage the keys stay offline, on a hardware wallet or a written backup, and only the signed payment crosses to an online machine. Malware on your computer cannot sign without them. A hot wallet keeps keys on a connected device, which is handier for spending. Many people keep everyday money hot and savings cold. Page: https://utxohub.com/glossary/cold-storage ### What is a crypto exchange? A business where people swap ordinary money for bitcoin and other coins. Coins left there are held by the exchange, which controls their keys. A crypto exchange is a company where people buy and sell bitcoin and other coins, for ordinary money or for each other. To trade, you send it money or coins, and it keeps them in an account in your name. Coins left in an exchange account are held for you: the exchange controls the private keys, and your balance is its promise to pay. The US Securities and Exchange Commission warns that if a custodian such as an exchange “is hacked, shuts down, or goes bankrupt, you may lose access to your crypto assets.” Customers of Mt. Gox in 2014 and FTX in 2022 found that out. Withdrawing coins to a wallet you control puts the keys in your hands, and with them the job of keeping them safe. If your wallets are “lost, stolen, damaged, or hacked, you may permanently lose access to your crypto assets,” the same SEC guide says. Sources: - US Securities and Exchange Commission, Investor.gov (Internet Archive copy): Crypto Asset Custody Basics for Retail Investors – Investor Bulletin (12 December 2025). https://web.archive.org/web/20260916121449/https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0 Page: https://utxohub.com/glossary/exchange ### What is a multisig wallet? A wallet whose coins need signatures from several keys, such as 2 of 3, so no single key can spend alone. An ordinary wallet needs one key's signature. A multisig wallet names several keys and a threshold: a 2-of-3 setup spends with any two of the three. People use it for shared funds, and so that one lost or stolen key means neither lost nor stolen bitcoin. The spending rules sit in the payment itself. With Taproot, the keys can combine so that a multisig spend looks like an ordinary single-signature one, which helps privacy. Page: https://utxohub.com/glossary/multisig ### What is a CoinJoin? A payment made together by several people, which breaks the easy link between their old and new addresses. Nobody gives up their coins. Several people combine their inputs in one transaction and take the same amounts back at fresh addresses they each control. From outside, it is no longer obvious which output belongs to which input. The result is an ordinary, valid Bitcoin payment; nobody deposits coins with anyone. How much privacy it gives depends on the amounts, the number of people and what each does afterwards. Gregory Maxwell proposed the idea in 2013. Sources: - Gregory Maxwell, BitcoinTalk: CoinJoin: Bitcoin privacy for the real world. https://bitcointalk.org/index.php?topic=279249.0 Page: https://utxohub.com/glossary/coinjoin ### What are silent payments (BIP-352)? A reusable payment code. Each sender works out a fresh address from it, so the chain doesn't show that those addresses belong to the code. Publishing an address usually means reuse: everyone can watch what arrives at it. A silent-payment code instead lets each sender combine it with their own payment's data to derive a one-off address, which only the receiver can recognise and spend from. It hides one link: an outside observer can't tell that an address was made from the code. Amounts, timing and how the coins are later spent can still connect payments, as they can for any address. The receiver must scan the chain to notice payments, which costs more work than an ordinary wallet check. BIP-352 is finished and ready to adopt, but each wallet chooses whether to support it; sending to a code needs one that does. Sources: - Bitcoin Improvement Proposals: BIP-352: Silent Payments. https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki Page: https://utxohub.com/glossary/silent-payments ### What is Tor? A free network that hides where internet traffic comes from by relaying it through three volunteer-run computers. Bitcoin nodes can use it. Tor, short for The Onion Routing, relays each connection through three computers run by volunteers and encrypts it at every step. The aim, in the Tor Project’s words, is connections that “don’t reveal who is talking to whom”. Websites can also run as onion services, with addresses ending in .onion, which hide where their own computers are. Bitcoin Core can connect to other nodes through Tor and run as an onion service itself, which hides the node’s own internet address. Tor hides where a connection comes from, not what is in the blockchain: payments stay public however they reach the network. Onion routing began at the US Naval Research Laboratory in 1995, and the Tor Project, which develops Tor, became a non-profit in 2006. Silk Road, the drug market the FBI shut down in 2013, ran as an onion service. Sources: - The Tor Project: Tor Project home page. https://www.torproject.org/ - The Tor Project: History. https://www.torproject.org/about/history/ - The Tor Project: Onion services. https://community.torproject.org/onion-services/overview/ - Bitcoin Core: Tor support in Bitcoin. https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md Page: https://utxohub.com/glossary/tor ### What is a light client (SPV)? A wallet that checks payments using block headers and proofs instead of the whole chain. It trusts miners more than a full node does. A full node downloads and checks every block and payment. A light client keeps only the block headers, 80 bytes each, and asks servers for a proof that a payment sits in a block. That is cheap enough for a phone. Simplified payment verification, SPV, comes from section 8 of the Bitcoin white paper. A light client knows a payment is buried under real proof of work, but it cannot check every rule itself, so it trusts that miners are following them. Many mobile wallets are light clients. Some use compact block filters (BIP-158), which let them find their payments without telling a server their addresses. Sources: - Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf - Bitcoin Improvement Proposals: BIP-158: Compact Block Filters for Light Clients. https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki Page: https://utxohub.com/glossary/light-client ### What is a coinbase transaction? The first transaction in every block, created by its miner. It spends no earlier output and pays out the block reward. Every block opens with a coinbase transaction, written by the miner who made the block. Unlike an ordinary transaction it spends no earlier output. It still has one input, a special one that points at nothing and lets the miner write a little data of their own. Its new bitcoin comes from the block subsidy, and it collects the fees of the block's other transactions. Its outputs pay the block reward to the miner or pool, but they cannot be spent for another 100 blocks, a rule called coinbase maturity. Sources: - Bitcoin Developer Reference: Coinbase input: the input of the first transaction in a block. https://developer.bitcoin.org/reference/transactions.html#coinbase-input-the-input-of-the-first-transaction-in-a-block - Bitcoin Core: COINBASE_MATURITY in src/consensus/consensus.h. https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h Page: https://utxohub.com/glossary/coinbase-transaction ### What is the Bitcoin block reward? What a block's miner earns: new bitcoin from the subsidy, plus the fees of every transaction in the block. The subsidy is brand-new bitcoin, created by the coinbase transaction. It halves every 210,000 blocks, about every four years, and is 3.125 bitcoin today. Fees come from the payments the block includes, so the reward rises when people compete for block space. As the subsidy shrinks, fees make up a growing share of what miners earn. Sources: - Bitcoin Core: GetBlockSubsidy in src/validation.cpp. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp Page: https://utxohub.com/glossary/block-reward ### What is the genesis block? Bitcoin's first block, mined by Satoshi Nakamoto on 3 January 2009. Every block since links back to it. Block 0 began the chain. Its only payment carries that day's Times headline, “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”, a timestamp that also comments on the bank bailouts of the day. Its 50 bitcoin reward can never be spent: the software skips connecting the genesis block's payment, so it never entered the spendable set. The quirk has been kept ever since. Sources: - Bitcoin Core: ConnectBlock in src/validation.cpp. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp Page: https://utxohub.com/glossary/genesis-block ### What is a 51% attack? One miner or pool controlling most of the hashrate. They could reverse their own recent payments, but not steal coins or change the rules. Whoever holds most of the hashrate can, given time, build a longer chain than everyone else. With it they could undo their own recent payments, a double spend, or keep chosen payments out of blocks. They cannot spend coins whose keys they don't hold, and they cannot change the rules: every node would still reject a block that broke them. Deeply confirmed payments stay impractical to reverse, which is why confirmations are the defence. Sources: - Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf Page: https://utxohub.com/glossary/51-attack ### What is bitcoin.org? The website Satoshi Nakamoto registered in August 2008. It published the Bitcoin white paper and still hosts it. Volunteers run it today. Satoshi Nakamoto registered bitcoin.org on 18 August 2008, ten weeks before announcing Bitcoin. The white paper has been published there ever since, at bitcoin.org/bitcoin.pdf. The site’s own history says it was first owned by Satoshi and Martti Malmi, Bitcoin’s first two developers, and that when Satoshi left, ownership passed “to additional people, separate from the Bitcoin developers”. It describes itself as “an independent open source project”. In 2021 Craig Wright, who claimed to be Satoshi, sued the site’s anonymous operator, known as Cøbra, and his claim left the white paper inaccessible from bitcoin.org. After the High Court ruled in 2024 that Wright is not Satoshi, the judge set aside the 2021 judgment against Cøbra, because it “was obtained in a claim which was fraudulent”. Sources: - bitcoin.org: About bitcoin.org. https://bitcoin.org/en/about-us - High Court of England and Wales (The National Archives): Crypto Open Patent Alliance v Wright [2024] EWHC 1198 (Ch), para 23.1. https://caselaw.nationalarchives.gov.uk/ewhc/ch/2024/1198 - High Court of England and Wales (The National Archives): Crypto Open Patent Alliance v Wright [2024] EWHC 1809 (Ch), paras 97 and 221. https://caselaw.nationalarchives.gov.uk/ewhc/ch/2024/1809 Page: https://utxohub.com/glossary/bitcoin-org ### What is Bitcointalk? The Bitcoin forum Satoshi Nakamoto opened in November 2009. Much of Bitcoin’s early history, from the pizza offer to Satoshi’s last post, happened there. Satoshi Nakamoto opened the forum on 22 November 2009, at first as part of bitcoin.org, and wrote more than 500 posts there before a last one in December 2010. In July 2011 it moved to its own address, bitcointalk.org, “in order to make it explicitly unofficial”, according to the Bitcoin Wiki. Much of Bitcoin’s early history happened in its threads: Laszlo Hanyecz’s offer in May 2010 to pay 10,000 bitcoins for two pizzas, Satoshi’s fix for the overflow bug that August, and Hal Finney’s 2013 post “Bitcoin and me”, about his early days with Bitcoin. The forum is still running. Its long-time administrator is known as theymos. Sources: - Satoshi Nakamoto Institute: Welcome to the new Bitcoin forum! (22 November 2009). https://satoshi.nakamotoinstitute.org/posts/bitcointalk/5/ - Bitcoin Wiki: BitcoinTalk. https://en.bitcoin.it/wiki/BitcoinTalk - Bitcointalk: Pizza for bitcoins? (18 May 2010). https://bitcointalk.org/index.php?topic=137.0 - Satoshi Nakamoto Institute: Version 0.3.10 - block 74638 overflow PATCH! (15 August 2010). https://satoshi.nakamotoinstitute.org/posts/bitcointalk/376/ - Bitcointalk: Bitcoin and me (Hal Finney) (19 March 2013). https://bitcointalk.org/index.php?topic=155054.0 Page: https://utxohub.com/glossary/bitcointalk ### What is a cypherpunk? Someone who believes in using strong cryptography to protect people’s privacy. Many ideas behind Bitcoin came from the cypherpunks of the 1990s. The cypherpunks began as an email list, started in late 1992 by Eric Hughes, Timothy May and John Gilmore. Programmers, cryptographers and privacy activists argued there about how cryptography could protect people from surveillance. By 1997 the list had perhaps 2,000 subscribers. Eric Hughes set out their thinking in A Cypherpunk’s Manifesto in 1993: “Privacy is necessary for an open society in the electronic age.” Rather than wait for laws to protect privacy, they would build the tools themselves: “Cypherpunks write code.” Several of Bitcoin’s building blocks came from that world. Adam Back announced hashcash on the list in 1997; its proof of work is what Bitcoin’s miners do today. Wei Dai announced b-money there in 1998. The Bitcoin white paper cites both, and Hal Finney and Nick Szabo, who designed earlier forms of digital money, were part of the same circle. Sources: - Eric Hughes: A Cypherpunk’s Manifesto (9 March 1993). https://www.activism.net/cypherpunk/manifesto.html - Wikipedia: Cypherpunk. https://en.wikipedia.org/wiki/Cypherpunk - Cypherpunks mailing list (Internet Archive copy): Adam Back announces hashcash, 28 March 1997. https://web.archive.org/web/20180605005855/https://cypherpunks.venona.com/date/1997/03/msg00774.html - Cypherpunks mailing list (Internet Archive copy): Wei Dai announces b-money, 26 November 1998. https://web.archive.org/web/20180328172450/http://cypherpunks.venona.com:80/date/1998/11/msg00941.html - hashcash.org: Hashcash. http://www.hashcash.org/ - Satoshi Nakamoto: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf Page: https://utxohub.com/glossary/cypherpunk ### Why do Bitcoin addresses start with 1, 3, bc1q or bc1p? The prefix marks the address type: 1 and 3 are older formats, bc1q is SegWit, bc1p is Taproot. Newer types usually cost less to spend from. Addresses beginning 1 are original pay-to-public-key-hash; 3 wraps a script, often an older multisig or a compatibility format. Both predate SegWit. bc1q is SegWit (bech32), cheaper to spend from and better at catching typos; bc1p is Taproot (bech32m). All four are Bitcoin mainnet — the sending wallet just needs to support the type. Sources: - Bitcoin Improvement Proposals: BIP-173: Base32 address format for native v0-16 witness outputs. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki - Bitcoin Improvement Proposals: BIP-350: Bech32m format for v1+ witness addresses. https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki Page: https://utxohub.com/glossary/address-types ### What are Bitcoin inscriptions (ordinals)? Data, such as an image, written into a Taproot payment's witness and tied to one satoshi, so it lives on the blockchain. Ordinals is a scheme that numbers every satoshi; an inscription attaches data to one of them inside a Taproot input's witness. The result is a token or image that exists entirely on chain and can be sent like any other satoshi. Inscriptions are valid payments and appear on explorers as ordinary-looking transactions with extra witness data. Whether they belong on Bitcoin has been argued since 2023; the OP_RETURN relay debate is part of the same argument. Fees for large inscriptions can be high. Sources: - Ordinals: Ordinal Theory Handbook. https://docs.ordinals.com/ Page: https://utxohub.com/glossary/inscriptions ### What is a Bitcoin timelock? A rule inside a payment that stops coins being spent until a certain block height or time has passed. A timelock makes an output unspendable until the chain reaches a set height or timestamp. Wallets show the coins but cannot move them early — the rule is enforced by nodes, not by the wallet. Payment channels, vaults and inheritance setups use timelocks, as do some multisig recoveries. If your wallet says funds are locked until a block or date, a timelock is why; they unlock by themselves when it passes. Sources: - Bitcoin Improvement Proposals: BIP-65: OP_CHECKLOCKTIMEVERIFY. https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki - Bitcoin Improvement Proposals: BIP-112: CHECKSEQUENCEVERIFY. https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki Page: https://utxohub.com/glossary/timelock ### What is a PSBT (partially signed Bitcoin transaction)? A standard format for passing an unsigned or partly signed payment between wallets and signers, until it is fully signed and broadcast. Defined in BIP-174, a PSBT bundles a payment with the information each signer needs, such as which inputs belong to which keys. A coordinator can build it on one machine, signers sign on others, and nobody has to share keys. Hardware wallets and multisig setups rely on it: the unsigned payment travels to the offline device, comes back signed, and only then is broadcast. A PSBT is not a payment yet — it has no transaction ID and cannot confirm. Sources: - Bitcoin Improvement Proposals: BIP-174: Partially Signed Bitcoin Transaction Format. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki Page: https://utxohub.com/glossary/psbt ### What is a watch-only wallet? A wallet that holds addresses or an xpub but no private keys, so it can track balances and payments without being able to spend. People keep a watch-only copy of a cold-storage wallet on a phone or laptop: it sees every payment that arrives, while the keys stay offline. An xpub can feed it the wallet's addresses. An xpub holds public keys, which can make addresses but not sign. A watch-only wallet can receive, since anyone can pay an address, but it can never spend. If one is hacked, the thief sees your history but cannot take the coins. Sources: - Bitcoin Core 29.0: createwallet: disable_private_keys. https://bitcoincore.org/en/doc/29.0.0/rpc/wallet/createwallet/ Page: https://utxohub.com/glossary/watch-only-wallet ### What is a Bitcoin mining pool? A group of miners who share the work of finding blocks and split the rewards, so each gets paid steadily instead of rarely. Mining alone, one small miner might wait years between blocks. A pool combines many miners' hashrate and pays each a share of what it earns, in proportion to the work they contribute. The pool operator builds the block candidates and coordinates; the miners still own their machines. A few large pools account for much of the hashrate, which is why pool concentration is watched as a decentralisation risk. Page: https://utxohub.com/glossary/mining-pool ### What is block height? A block's number, counting from the genesis block at height 0. The current height is the number of blocks since the genesis block. Each new block's height is one more than the block before it, so the latest height tells you the chain's length. Explorers use it as an address for a block: block 0 is the genesis block. A payment's confirmations are the current height minus its block's height, plus one. Schedules like the halving's every 210,000 blocks are set in heights, not dates. Page: https://utxohub.com/glossary/block-height ### What is a stale block? A valid block that lost the race: another block at the same height was built on instead, so the stale one is not in the chain. Two miners sometimes find a block at almost the same moment. Nodes keep the one that becomes part of the chain with the most work; the other goes stale, and its miner loses the reward. A stale block is not an attack, just bad luck, and the race resolves within a block or two. Payments in the loser return to the mempool if the winner didn't include them. Older writing calls these orphan blocks. Sources: - Bitcoin Developer Guide: Block Chain: Block Height And Forking. https://developer.bitcoin.org/devguide/block_chain.html#block-height-and-forking Page: https://utxohub.com/glossary/stale-block ### What is a Bitcoin sidechain? A separate blockchain that bitcoin can move to and back from, trading Bitcoin's rules for different features or speed. Coins move to a sidechain through a peg: bitcoin is locked on mainnet and an equivalent amount is issued on the sidechain, which runs its own rules and block times. Moving back reverses the process. A sidechain is not Bitcoin: its security depends on its own design, such as a federation of signers, not on Bitcoin's miners alone. Liquid is one example. Payments on a sidechain do not appear on a Bitcoin explorer. Sources: - Blockstream: Liquid Network. https://liquid.net/ Page: https://utxohub.com/glossary/sidechain ### Why is bitcoin limited to 21 million? Bitcoin's rules halve the new supply every 210,000 blocks, so issuance slows towards zero. The total approaches 21 million without quite reaching it. The cap isn't written as a number. It falls out of the subsidy schedule: 50 new bitcoin per block in 2009, halving every 210,000 blocks. The series adds up to just under 21 million, with the last fraction arriving somewhere near the year 2140 — uneven block times mean there is no exact date. Because amounts are whole satoshis, the subsidy rounds down to zero rather than ever reaching a clean 21 million. Changing the cap would need the same near-total agreement among users, nodes and miners that any rule change needs. Sources: - Bitcoin Core: GetBlockSubsidy in src/validation.cpp. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp Page: https://utxohub.com/glossary/supply-cap ### What is the gap limit in a Bitcoin wallet? How many unused addresses in a row a wallet checks before it stops looking for your coins when recovering — usually 20. A wallet derives addresses in order along its path. When recovering from words or an xpub, it scans until it finds a run of addresses with no payments — the gap limit, 20 by default in many wallets — and stops. Anything beyond the gap stays unfound. This explains some “missing balance” scares: coins received at an address beyond the gap don't show up. Rescanning with a higher gap limit usually finds them. Sources: - Bitcoin Improvement Proposals: BIP-44: Multi-Account Hierarchy for Deterministic Wallets. https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki Page: https://utxohub.com/glossary/gap-limit ### What is a payjoin (P2EP)? A payment where the receiver adds an input too, breaking the assumption that every input belongs to the sender. It looks like an ordinary payment. In a payjoin, sender and receiver build the transaction together: both contribute inputs, the receiver gets paid, and on chain the payment is indistinguishable from an ordinary one. Standardised as BIP-78, it's also called pay-to-endpoint, or P2EP. Unlike a CoinJoin, amounts stay natural — there are no equal outputs to spot. Both sides must be online together, and the receiver's wallet must support it. Sources: - Bitcoin Improvement Proposals: BIP-78: A Simple Payjoin Proposal. https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki Page: https://utxohub.com/glossary/payjoin ### What is a Bitcoin output descriptor? A short string that describes exactly how a wallet's addresses and spending rules are made from its keys, so any wallet can rebuild the same setup. A descriptor spells out the script type, the keys or xpubs and the derivation paths in one string, such as wpkh(xpub…/84'/0'/0'/0/*). With it, software can find every address and coin of a wallet without guessing. Defined across BIPs 380–386, descriptors are how modern wallets back up and share watch-only setups, multisigs and Miniscript vaults. Like an xpub, a descriptor reveals addresses and history, so treat it as private — though it cannot spend without private keys. Sources: - Bitcoin Improvement Proposals: BIP-380: Output Script Descriptors General Operation. https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki Page: https://utxohub.com/glossary/output-descriptors ### What is a Lightning payment channel? A shared pot of bitcoin between two parties on the blockchain, which they can pay each other from, off-chain, as often as they like. Two people lock bitcoin in a 2-of-2 multisig output on the blockchain: that's the channel. They then update the balance between themselves with signed transactions they don't broadcast — each update is a payment, instant and nearly free. The channel closes when one side broadcasts the latest state, and routing payments across many channels is what makes the Lightning Network. Because only the open and close touch the chain, the payments in between don't appear on a Bitcoin explorer. Sources: - Lightning Labs: Payment Channels. https://docs.lightning.engineering/the-lightning-network/payment-channels Page: https://utxohub.com/glossary/payment-channel ### What is the difference between policy and consensus rules in Bitcoin? Consensus rules decide whether a block is valid — breaking them splits the chain. Policy is what your own node relays, and each operator can change it. Consensus rules are the ones every node checks: the supply schedule, valid signatures, no double spends. A block that breaks them is rejected by the whole network, so changing them needs near-total agreement. Policy rules are local preferences about what to relay or mine, like OP_RETURN data limits or minimum fee rates. They shape the mempool but not validity: a payment outside your policy can still be perfectly valid — which is why debates like the OP_RETURN one stay arguments, not forks. Sources: - Bitcoin Core: Policy (doc/policy). https://github.com/bitcoin/bitcoin/tree/master/doc/policy Page: https://utxohub.com/glossary/policy ### What is the blockchain? Bitcoin's shared record of every payment since 2009, stored in blocks that each link to the one before — which is what makes it a chain. Each block carries a batch of transactions and the fingerprint of the block before it. Change any past transaction and every fingerprint after it breaks, so the history can't be quietly edited: nodes would reject the altered chain. Every node keeps its own copy and checks it against the same rules, which is why no one has to trust a central record-keeper. “Blockchain” has become a buzzword for other uses, but on this site it means Bitcoin's chain. Page: https://utxohub.com/glossary/blockchain ### What is a Bitcoin transaction? A signed instruction that moves bitcoin: it spends some earlier outputs and creates new ones, each with an amount and an owner. A transaction is the only way bitcoin moves. It names the pieces being spent (its inputs), proves with signatures that the sender may spend them, and creates the new pieces (its outputs), usually a recipient and change back to the sender. Once broadcast, a transaction waits in the mempool until a miner includes it in a block. It gets a transaction ID when it's made, so you can follow it from sending to confirmation. Page: https://utxohub.com/glossary/transaction ### What are Bitcoin Runes? A way to make tradable tokens on Bitcoin itself, storing their data in OP_RETURN outputs. Each token is an entry in a transaction, not a separate coin. Runes is a 2024 protocol for issuing and swapping tokens on Bitcoin: the creation and transfers of a token live in ordinary transactions' OP_RETURN data. Wallets and indexers that understand the protocol read those records to track balances. Unlike an inscription, which attaches data to one satoshi, a rune behaves more like a balance entry. Neither is bitcoin itself — they ride on Bitcoin's block space, and they can raise the fees everyone pays when demand spikes. Sources: - Ordinals: Runes. https://docs.ordinals.com/runes.html Page: https://utxohub.com/glossary/runes ### What is a hard fork? A change that loosens Bitcoin's rules, so nodes running old software reject the new blocks. Without near-universal agreement it splits the chain. A soft fork tightens the rules and old nodes still accept the blocks. A hard fork goes the other way — bigger blocks or new rules old software calls invalid — so everyone must upgrade before the switch, or the network splits in two. Splits have happened on purpose: Bitcoin Cash broke away in 2017 over block size, and the market then priced the two coins separately. A hard fork is also the name for the moment two coins share one history up to the split. Sources: - Wikipedia: Bitcoin Cash. https://en.wikipedia.org/wiki/Bitcoin_Cash Page: https://utxohub.com/glossary/hard-fork ### What is self-custody? Holding your own keys, so no company can freeze, lose or take your bitcoin. The alternative, a custodial service, holds them for you. With a custodial account, an exchange or app holds the keys and you ask it to move your coins — convenient, but you're trusting its solvency, security and goodwill. With self-custody, your wallet holds the keys and only you can sign. Self-custody removes the middleman and adds responsibility: lose your recovery words with no backup and no support desk can help. Many people split the difference — spending money custodial, savings self-custodied. Page: https://utxohub.com/glossary/self-custody ### What is a Shamir backup (SLIP-39)? A backup split into several word lists, so any threshold of them — say 2 of 3 — restores the wallet, while one alone reveals nothing. Instead of one list of recovery words to lose or have stolen, a Shamir backup makes several shares. The wallet restores from any threshold of them; a single share on its own gives an attacker nothing. It's based on Shamir's secret sharing, a 1979 cryptographic scheme. SLIP-39 is the standard many Trezor wallets use for this. It is not the same as multisig: the shares rebuild one key, rather than several keys signing separately. Each share needs the same careful, offline storage as recovery words. Sources: - SatoshiLabs: SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes. https://github.com/satoshilabs/slips/blob/master/slip-0039.md Page: https://utxohub.com/glossary/shamir-backup ### What is a paper wallet? A key printed or written on paper rather than kept on a device. Once common, it's now mostly outdated and risky to make safely. A paper wallet is cold storage at its simplest: an address and its private key on paper, kept somewhere safe. To spend, you import or sweep the key into a wallet app. Making one safely is the hard part — a compromised generator site or a printer with memory can leak the key. Modern wallets with recovery words, or a hardware wallet, do the same job with fewer ways to go wrong. Page: https://utxohub.com/glossary/paper-wallet ### What is WIF (wallet import format)? The text format a single private key takes when you export or import it — a string starting with 5, K or L. A raw private key is just a number. WIF wraps it with a checksum and network marker so wallets can move it between apps without typos going unnoticed. Imported WIF keys sit outside a wallet's recovery words — back them up separately. Treat a WIF string like the key it is: anyone who reads it can spend the coins. Most people never need one; it comes up when sweeping a paper wallet or moving an old key. Page: https://utxohub.com/glossary/wif ### What is a hash in Bitcoin? The fingerprint of some data: a fixed-length output of the SHA-256 function, which Bitcoin uses for addresses, transaction IDs and mining. A hash function turns any data into a short, fixed-length code. Change one character of the input and the code comes out completely different, yet the same input always gives the same code — that's why it works as a fingerprint. Bitcoin uses one called SHA-256 throughout: transaction IDs are hashes of the payment, addresses carry hashes of keys or scripts, and mining is the search for a block hash below a target. Working backwards from a hash to its input is not practically possible. Page: https://utxohub.com/glossary/hash ### What is an ASIC miner? A machine built to do nothing but Bitcoin mining: chips that hash trillions of times a second, far beyond any ordinary computer. Early miners used CPUs, then graphics cards. Since 2013 the race has belonged to ASICs — application-specific integrated circuits — whose only job is SHA-256 hashing. A general-purpose computer can no longer compete. ASICs are why mining is an industry: they cost money, need cheap electricity and go obsolete within a few years. Owning one isn't required — the network's work shows up as hashrate whether or not you run machines. Page: https://utxohub.com/glossary/asic ### What is a layer 2 in Bitcoin? A system built on top of Bitcoin that handles payments off the main chain, using it mainly to settle. The Lightning Network is the best known. The main chain is layer 1: secure but limited in space. A layer 2 moves the frequent, small activity elsewhere and anchors back to the chain for finality, aiming for speed and low cost without changing Bitcoin's rules. Lightning settles through payment channels; sidechains like Liquid run a parallel chain with a peg. What a layer 2 gives up for that speed varies — channels need liquidity and watchfulness, sidechains need trust in their operators. Page: https://utxohub.com/glossary/layer-2 ### What does HODL mean? Bitcoin slang for holding coins instead of selling, from a 2013 forum post whose author misspelled “hold” in its title. In December 2013, after a price drop, a bitcointalk user posted “I AM HODLING” — a typo that became the word. It now means keeping your bitcoin through the swings rather than trading them. You'll also see it backronymed as “hold on for dear life”, but that's a later invention. This site doesn't give advice on whether to hold or sell — it's just the word's history. Sources: - BitcoinTalk: I AM HODLING (18 December 2013). https://bitcointalk.org/index.php?topic=375643.0 Page: https://utxohub.com/glossary/hodl ### What is a hardware wallet? A small device that holds your private keys and signs payments inside itself, so the keys never touch your internet-connected computer or phone. A hardware wallet is a small computer with one job: keeping private keys and signing payments with them. The wallet app on your phone or computer prepares a payment and passes it to the device. The device signs it and hands back only the signed payment, so the keys stay inside, even if the computer has a virus. Its screen matters as much as its chip. The computer it plugs into is treated as untrusted, so the device shows the payment on its own screen and signs nothing until you approve. The protection holds “as long as the user correctly verifies the information that is shown on the device’s screen before approving”, says BIP-388, a standard written for such devices. When you set one up, it gives you recovery words to write down. If the device is lost or broken, the words restore the same keys in another wallet, so they need the same care as the device. Wallet apps and devices pass payments back and forth in a shared format, the PSBT, set out in BIP-174. Marek Palatinus and Pavol Rusnák announced their hardware wallet project on Bitcointalk in November 2012. In their design, they wrote, “the keys never leave the device and thus cannot be stolen by a virus, malicious code or an attacker”. The device, Trezor, launched in July 2014. Many companies make hardware wallets today. Sources: - Bitcoin Improvement Proposals: BIP-388: Wallet Policies for Descriptor Wallets. https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki - Bitcoin Improvement Proposals: BIP-174: Partially Signed Bitcoin Transaction Format. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki - Bitcointalk (Internet Archive copy): Trezor: Bitcoin hardware wallet (first posted 5 November 2012). https://web.archive.org/web/20140403133439/https://bitcointalk.org/index.php?topic=122438.0 - Trezor: A decade of pioneering: 10 years since Trezor’s first hardware wallet revolution (29 July 2024). https://trezor.io/blog/news/a-decade-of-pioneering-10-years-since-trezors-first-hardware-wallet-revolution Page: https://utxohub.com/glossary/hardware-wallet ### What is a stablecoin? A token designed to keep a steady value, usually one US dollar, which its issuer promises to buy back. It isn’t bitcoin, and it depends on that issuer. A stablecoin is a digital token meant to stay worth a set amount of an ordinary currency, usually one US dollar. A company creates the tokens when people pay it dollars, and many issuers promise to swap them back at that price on request. A 2021 US government report describes stablecoins as “designed to maintain a stable value relative to a national currency or other reference assets”. Unlike bitcoin, a stablecoin depends on the company behind it. Issuers say they hold reserves to back their tokens, but the same report found no standards for what those reserves had to contain. If an issuer does not honour requests to swap tokens back, or people stop believing it can, it warned, “runs on the arrangement could occur”. Some stablecoins now travel over Bitcoin. In January 2025 Tether said it would bring its dollar stablecoin, USDT, to Bitcoin and the Lightning Network through Taproot Assets, a protocol built by Lightning Labs. “It all comes back to Bitcoin,” said Lightning Labs’ chief executive, Elizabeth Stark. Not every bitcoiner agrees: Frank Corva, a Bitcoin Magazine writer, called USDT on Bitcoin “a stain on the soul of Bitcoin”. Sources: - US President’s Working Group on Financial Markets, FDIC and OCC: Report on Stablecoins (November 2021). https://home.treasury.gov/system/files/136/StableCoinReport_Nov1_508.pdf - Tether: Tether Brings USDt to Bitcoin’s Lightning Network, Ushering in a New Era of Unstoppable Technology (30 January 2025). https://tether.io/news/tether-brings-usdt-to-bitcoins-lightning-network-ushering-in-a-new-era-of-unstoppable-technology/ - Lightning Labs: A New Era for Stablecoins: Tether Is Coming to Bitcoin and Lightning (30 January 2025). https://lightning.engineering/posts/2025-01-30-Tether-on-Lightning/ - Bitcoin Magazine (Frank Corva): I Still Don’t Like Tether (USDT) On Bitcoin And Lightning (19 February 2025). https://bitcoinmagazine.com/takes/i-still-dont-like-tether-usdt-on-bitcoin-and-lightning Page: https://utxohub.com/glossary/stablecoin ### What is Taproot Assets? A protocol from Lightning Labs for creating tokens, such as dollar stablecoins, on Bitcoin and sending them over the Lightning Network. Taproot Assets lets someone create a token on Bitcoin and pass it to other people, either on the blockchain or through Lightning channels. Lightning Labs, the company led by Elizabeth Stark, announced it in April 2022 under the name Taro and renamed it in 2023. It went live on Bitcoin’s main network in October 2023 and on Lightning in July 2024. Stablecoins were the main use Lightning Labs had in mind. A token’s details are not written into the block for anyone to read. They are tucked inside a Taproot output, with the same trick Taproot uses to keep unused spending conditions hidden, and the proof of who owns what is passed between owners off the chain. So on a Bitcoin explorer a Taproot Assets transfer looks like an ordinary Taproot payment: the token and its amount don’t show. Over Lightning, a token payment is swapped into bitcoin at the start, travels through ordinary channels and is swapped back at the end, so the nodes in between handle only bitcoin. In January 2025 Tether said its dollar stablecoin, USDT, would use the protocol on Bitcoin and Lightning. Sources: - Lightning Labs: Taproot Assets (developer documentation). https://docs.lightning.engineering/the-lightning-network/taproot-assets - Lightning Labs: Taproot Assets Protocol (developer documentation). https://docs.lightning.engineering/the-lightning-network/taproot-assets/taproot-assets-protocol - Lightning Labs: Announcing Taro: A New Protocol for Multi-Asset Bitcoin and Lightning (5 April 2022). https://lightning.engineering/posts/2022-4-5-taro-launch/ - Lightning Labs: Mint the Future with Taproot Assets v0.2 (16 May 2023). https://lightning.engineering/posts/2023-05-16-taproot-assets-v0.2/ - Lightning Labs: Taproot Assets on Mainnet: A New Era for Bitcoin and Beyond (18 October 2023). https://lightning.engineering/posts/2023-10-18-taproot-assets-v0.3/ - Lightning Labs: Taproot Assets on Lightning: The Global Financial Interoperability Layer (23 July 2024). https://lightning.engineering/posts/2024-07-23-taproot-assets-LN/ - Tether: Tether Brings USDt to Bitcoin’s Lightning Network, Ushering in a New Era of Unstoppable Technology (30 January 2025). https://tether.io/news/tether-brings-usdt-to-bitcoins-lightning-network-ushering-in-a-new-era-of-unstoppable-technology/ Page: https://utxohub.com/glossary/taproot-assets ### What is Stratum, the mining protocol? The protocol most mining pools use to hand out work to miners’ machines and collect the results. Marek Palatinus introduced it in 2012. A mining pool has to keep thousands of machines busy at once. With Stratum, the pool sends each machine a job: the pieces of the next block it should work on. The machine keeps trying for a winning answer and sends back shares, proof of the work it has done, which the pool uses to split each reward. Marek Palatinus, who ran one of the first pools, announced Stratum on Bitcointalk on 11 September 2012. With the older method, getwork, the faster a machine mined, the more often it had to ask for work, and much faster ASIC machines were on their way, he wrote. Braiins, the company that now runs his old pool, says Stratum “has since been the standard protocol for pooled mining”. It came with a trade-off, which Palatinus named at the start: “miners cannot choose Bitcoin transactions on their own.” The pool decides which payments go into each block. Luke Dashjr, who wrote getblocktemplate (BIP-22 and BIP-23), a method that does let miners choose, doubted Stratum was any better. Stratum V2, published in 2019, guards the connection against tampering and gives miners that choice back. Sources: - Marek Palatinus, mining.bitcoin.cz (Internet Archive copy): Stratum mining protocol (September 2012). https://web.archive.org/web/20120921014023/http://mining.bitcoin.cz:80/stratum-mining - Bitcointalk (Internet Archive copy): [ANN] Stratum mining protocol - ASIC ready (11 September 2012). https://web.archive.org/web/20260222010924/https://bitcointalk.org/index.php?topic=108533.0 - Braiins: Past and future of bitcoin mining protocols: Stratum V2 overview. https://braiins.com/upgrade Page: https://utxohub.com/glossary/stratum ### What is a smart contract? A program that carries out an agreement by itself, such as releasing money once set conditions are met. Nick Szabo coined the term in 1994. The computer scientist Nick Szabo coined the term in a 1994 essay, defining a smart contract as “a computerized transaction protocol that executes the terms of a contract”. The aim was to need fewer trusted middlemen. Two years later he pointed to an everyday example, the vending machine: put in the right coins and it hands over the goods, with no shopkeeper involved. Bitcoin has simple ones built in. Every coin is locked by a short script that says what it takes to spend it: one signature, two signatures out of three (multisig), or a wait until a set time (a timelock). Bitcoin’s developer guide calls these contracts “transactions which use the decentralized Bitcoin system to enforce financial agreements”. Payment channels, the building blocks of the Lightning Network, are made this way. Bitcoin keeps its script language deliberately small. It has no loops, which keeps every script predictable and stops one from running forever. Ethereum, a newer blockchain, took the other path: its white paper lists the lack of loops among the limits of Bitcoin’s scripts, and it was built to run programs of almost any kind. Sources: - Nick Szabo (copy hosted by the University of Amsterdam): Smart Contracts (1994). https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html - Nick Szabo (copy hosted by the University of Amsterdam): Smart Contracts: Building Blocks for Digital Markets (1996). https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html - Bitcoin Developer Guide: Contracts. https://developer.bitcoin.org/devguide/contracts.html - Bitcoin Developer Guide: Transactions. https://developer.bitcoin.org/devguide/transactions.html - ethereum.org: Ethereum Whitepaper. https://ethereum.org/en/whitepaper/ - ethereum.org: Introduction to smart contracts. https://ethereum.org/en/smart-contracts/ Page: https://utxohub.com/glossary/smart-contract ### What is a blind signature? A signature on something the signer can’t see. David Chaum published the idea in 1983 so a bank could issue digital cash it couldn’t trace. A signature usually shows that the signer saw what they signed. A blind signature is made without seeing it. The cryptographer David Chaum explained it with envelopes lined with carbon paper: “Writing a signature on the outside of such an envelope leaves a carbon copy of the signature on a slip of paper within the envelope.” His 1983 paper, “Blind Signatures for Untraceable Payments”, used the trick for money. A bank signs a customer’s digital coin without seeing it. Anyone can check the bank’s signature, so the coin is accepted, but when it comes back the bank can’t tell which customer it was given to, so the payment can’t be traced. Chaum’s company, DigiCash, built its eCash on the idea and patented it. Bitcoin took another path. eCash needed a central company to issue and check every coin, and Satoshi Nakamoto called that “the Achilles heel of Chaumian systems; when the central company shut down, so did the currency.” Bitcoin has no central signer and every payment is public; for privacy, Satoshi wrote, a new key pair is used for every payment. Blind signatures have returned in some newer projects built around Bitcoin, such as Cashu, in which a “mint” issues tokens for bitcoin paid to it over Lightning. As with eCash, the mint must be trusted. In Cashu’s own words, “Ecash is a claim on its mint, not a deposit.” Sources: - David Chaum, Advances in Cryptology (copy on chaum.com): Blind Signatures for Untraceable Payments (1983). https://chaum.com/wp-content/uploads/2022/01/Chaum-blind-signatures.pdf - eCash Technologies press release, as forwarded to the cryptography list: eCash Acquires Technologies from DigiCash (17 August 1999). https://diswww.mit.edu/bloom-picayune/crypto/5472 - Satoshi Nakamoto Institute: Bitcoin open source implementation of P2P currency (12 February 2009). https://satoshi.nakamotoinstitute.org/emails/p2p-research/36/ - Cashu: Cashu: an open protocol for Chaumian ecash on bitcoin. https://cashu.space/ Page: https://utxohub.com/glossary/blind-signature ## BIPs ### BIP-1: BIP Purpose and Guidelines Set out what a BIP is and the first process for writing, discussing and accepting one. This is housekeeping about how changes to Bitcoin are proposed, not a change to Bitcoin itself. It described three kinds of BIP (standards, informational and process) and the stages a proposal goes through. BIP 2 later replaced it. Status: Closed. Page: https://utxohub.com/bips/1 ### BIP-2: BIP process, revised Replaced BIP 1 with a clearer, more detailed process for writing, reviewing and accepting BIPs. This is housekeeping about how changes to Bitcoin are proposed, not a change to Bitcoin itself. It set out the stages a proposal moves through, the editors' duties, how people can comment on a BIP and which licences are allowed. BIP 3 later replaced it. Status: Closed. Page: https://utxohub.com/bips/2 ### BIP-3: Updated BIP Process Sets out how BIPs are written, reviewed, numbered and published, replacing the older BIP 2 process. This is housekeeping about how changes to Bitcoin are proposed, not a change to Bitcoin itself. It uses four simpler stages for a proposal (Draft, Complete, Deployed and Closed) and leaves the editors fewer judgement calls. Status: In use. Page: https://utxohub.com/bips/3 ### BIP-8: Version bits with lock-in by height Defines a way to switch on soft forks by counting blocks, with an option to make sure the upgrade locks in by a set point. BIP 9 used clock times and needed almost every miner to signal support, so a small minority could block an upgrade. BIP 8 counts blocks instead, and can require miners to signal near the deadline so the upgrade is sure to lock in. Status: Finished. Page: https://utxohub.com/bips/8 ### BIP-9: Version bits with timeout and delay Lets miners signal support for several soft forks at once, each using its own bit in a block's version number. An older method could roll out only one upgrade at a time. Here each upgrade locks in once 95% of blocks in a 2,016-block period signal for it on the main network, or gives up after a timeout. After a pause, the bit can be reused for a later upgrade. Status: In use. Page: https://utxohub.com/bips/9 ### BIP-10: Multi-Sig Transaction Distribution Proposed a common format for passing an unsigned payment between people so each can add their signature. A payment that needs several signatures means collecting each one before it can be sent. A shared format would let different wallets work together. It also let an offline device check and sign a payment without a copy of the blockchain. Status: Closed. Page: https://utxohub.com/bips/10 ### BIP-11: M-of-N Standard Transactions Makes payments that need M of N signatures, such as 2 of 3, a standard type that nodes pass on and miners include. It supports set-ups where spending needs more than one signature, such as a wallet guarded by a second signing service, or escrow where any two of a buyer, seller and trusted referee can release the coins. It covers up to three keys. Status: In use. Page: https://utxohub.com/bips/11 ### BIP-12: OP_EVAL Proposed a new script command, OP_EVAL, so the person receiving coins could choose the rules for spending them. A script is the small program that decides who can spend coins. The aim was to support more secure wallets and escrow payments in a way that older software and miners would still accept. Status: Closed. Page: https://utxohub.com/bips/12 ### BIP-13: Address Format for pay-to-script-hash Defines the address format for pay-to-script-hash: the addresses that start with a 3. These addresses stand for a fingerprint of a script, the small program that decides who can spend coins, rather than a single key. That lets someone pay into set-ups such as escrow or shared wallets using an address built the same way as an ordinary one. Status: In use. Page: https://utxohub.com/bips/13 ### BIP-14: Protocol Version and User Agent Separates the network's version number from any one program's version, and lets each node name its software. Tying the two together forced every other Bitcoin program to keep pace with one client's releases. Each node also sends a short 'user agent' text naming its software and version, much like a web browser does. Status: In use. Page: https://utxohub.com/bips/14 ### BIP-15: Aliases Compared ways to let people pay a short, memorable name instead of a long address. Addresses are hard to remember, much like having to type a website's number instead of its name. This BIP weighed several schemes, such as using the first few characters of an address, DNS records and web services. It notes that the payment protocol in BIP 70 may be seen as the alternative. Status: Closed. Page: https://utxohub.com/bips/15 ### BIP-16: Pay to Script Hash Lets a sender pay to a short code standing for the receiver's spending rules, however complex those rules are. Pay-to-script-hash moves the job of setting spending rules, such as needing several signatures, from the sender to the receiver. The sender only needs a short, fixed-length code that is easy to scan from a QR code or copy and paste. Miners showed their support by marking the blocks they mined, and the new rules applied to blocks from 1 April 2012. Status: In use. Page: https://utxohub.com/bips/16 ### BIP-17: OP_CHECKHASHVERIFY (CHV) Proposed a new script command, CHECKHASHVERIFY, to let the person receiving coins set the rules for spending them. Like pay-to-script-hash, the aim was to let a sender pay to a short, fixed-length code however complex the receiver's spending rules are. It was put forward to replace BIP 12 and BIP 16, which tackled the same problem. Status: Closed. Page: https://utxohub.com/bips/17 ### BIP-18: hashScriptCheck Describes another way to let a sender pay to a short fingerprint of the receiver's spending rules. Like pay-to-script-hash in BIP 16, it moves the job of setting spending rules from the sender to the receiver. It frames the change as a new layout for the parts of a payment that lock and unlock coins, and says it works the same as BIP 16 on the network. Status: Finished. Page: https://utxohub.com/bips/18 ### BIP-19: M-of-N Standard Transactions (Low SigOp) Proposed standard payments needing several signatures, built from simple signature checks so more fit in each block. BIP 11 already did this with one multi-signature command, but that command counts as 20 signature checks towards each block's limit. Building the same payments from single checks counts only one per signature, so more of them could fit in a block. Status: Closed. Page: https://utxohub.com/bips/19 ### BIP-20: URI Scheme Proposed bitcoin: links that open a wallet with a payment ready to approve, from a web page or a QR code. The aim was to let people pay by clicking a link or scanning a code instead of copying an address. Wallets were told never to act on a link without the user's approval. BIP 21 later replaced it. Status: Closed. Page: https://utxohub.com/bips/20 ### BIP-21: URI Scheme Set out the bitcoin: link format that opens a wallet with an address and amount filled in, from a click or a QR scan. A link held the address and could add an amount, a label and a message. Wallets were told never to act on a link without the user's approval. BIP 321 later replaced it. Status: Closed. Page: https://utxohub.com/bips/21 ### BIP-22: getblocktemplate - Fundamentals Lets mining software ask a node for a full draft of the next block, so it can build and adjust the block itself. Instead of sending only a block's header to work on, the getblocktemplate command sends the whole block, payments included. Specialised mining software can then put the block together. This matters to miners rather than everyday users. Status: In use. Page: https://utxohub.com/bips/22 ### BIP-23: getblocktemplate - Pooled Mining Adds extras to getblocktemplate for pooled mining, so miners in a pool can see and check the block they work on. There were concerns that mining pools held too much control. By showing miners the details of the proposed block, this BIP lets them check, and possibly change, it before mining. It builds on BIP 22 and is mainly of interest to pools and miners. Status: In use. Page: https://utxohub.com/bips/23 ### BIP-30: Duplicate transactions Stops a block from including a payment with the same ID as an earlier payment whose coins are not all spent. Payment IDs were assumed to be unique, but copies were possible, starting with the payment in each block that rewards the miner. An attack using such copies could knock a fully confirmed payment back to one confirmation and risk making it unspendable. Status: In use. Page: https://utxohub.com/bips/30 ### BIP-31: Pong message Lets a node send a ping with a random number and get it back in a pong, to check a connection still works. Laptops and phones can go to sleep, and busy peers can slow down, leaving connections that look open but no longer respond. Timing the pong helps software spot dead or overloaded peers and pick better ones. Status: In use. Page: https://utxohub.com/bips/31 ### BIP-32: Hierarchical Deterministic Wallets Lets a wallet grow a whole tree of keys from one starting value, so a single backup covers every key. Older wallets made random keys and needed fresh backups as they made new ones. With BIP 32, one seed produces every key. Parts of the tree can be shared, and an extended public key (xpub) can make new addresses without being able to spend. Status: In use. Page: https://utxohub.com/bips/32 ### BIP-33: Stratized Nodes Proposed special nodes that would check the blockchain and answer address lookups for lighter wallets. The full record of payments keeps growing, which makes it hard to handle on phones and low-end computers. This BIP suggested new kinds of node that would safely take over checking and lookups for those wallets, without keeping the whole blockchain. Status: Closed. Page: https://utxohub.com/bips/33 ### BIP-34: Block v2, Height in Coinbase Makes every block record its height, its place in the chain, inside the payment that rewards the miner. Adding the height makes each block and its reward payment unique. The change was rolled out with a vote by version number: once 950 of the last 1,000 blocks used the new version, older-version blocks were rejected. Status: In use. Page: https://utxohub.com/bips/34 ### BIP-35: mempool message Lets one node ask another for the list of unconfirmed payments it is holding. The mempool is a node's waiting room for transactions not yet in a block. This message helps light wallets find payments they sent or received that have no confirmations yet, and lets miners catch up on waiting payments after a restart. Status: In use. Page: https://utxohub.com/bips/35 ### BIP-36: Custom Services Proposed a way for nodes to announce custom add-on services when they connect, without crowding a small shared field. Developers wanted to try extras on the network, such as support for lighter wallets or new ways to route messages. Without a common framework these could clash. This BIP suggested listing each service by name and version in the first message nodes exchange. Status: Closed. Page: https://utxohub.com/bips/36 ### BIP-37: Connection Bloom filtering Lets light wallets ask nodes to send only payments that might matter to them, instead of everything. Simple wallets that do not check every block used to download all payments and throw most away. A Bloom filter, a compact and fuzzy list of what the wallet is looking for, lets a node send only likely matches. It may send some extras but never misses a real match. Status: In use. Page: https://utxohub.com/bips/37 ### BIP-38: Passphrase-protected private key Lets a private key be locked with a passphrase and printed as a code, for paper wallets and physical coins. Anyone who sees an unprotected key printed on paper can spend its coins. This BIP encrypts the key so the passphrase is also needed, and makes guessing it slow. It also lets a maker of physical coins create keys without being able to spend them. Status: In use. Page: https://utxohub.com/bips/38 ### BIP-39: Mnemonic code for generating deterministic keys Lets wallets turn a backup of every key into a list of 12 to 24 ordinary words. Writing down a long random number is error-prone. This BIP turns it into a short list of common words that a wallet can turn back into all of its keys. Anyone who has the words controls the wallet, so they must be kept secret. From 2017 its header summed up the comments on it as 'Unanimously Discourage for implementation'. In July 2026 that line was removed. The BIP now lists its shortcomings, such as having no version number, and names SLIP-0039 as the successor its authors proposed. Status: In use. Page: https://utxohub.com/bips/39 ### BIP-42: A finite monetary supply for Bitcoin Makes sure the new coins paid to miners stop for good, so the total number of bitcoin has a limit. Because of a quirk in the original code, the reward for each block would have jumped back to 50 bitcoin after 64 halvings, so new coins would have kept coming forever. The BIP is written as a joke, but its change is real: the reward is set to zero for good. Status: In use. Page: https://utxohub.com/bips/42 ### BIP-43: Purpose Field for Deterministic Wallets Reserves the first step of a wallet's key tree for a number saying which layout the rest of the tree follows. BIP 32 left wallet makers so much freedom that two 'compatible' wallets could lay out their keys differently and not work together. This 'purpose' number, meant to match the number of the BIP that describes the layout, tells a wallet what to expect. Status: In use. Page: https://utxohub.com/bips/43 ### BIP-44: Multi-Account Hierarchy for Deterministic Wallets Sets out a standard layout for a wallet's keys, with separate branches for each coin, account and change. One backup can hold keys for many accounts and even different cryptocurrencies. Giving each its own branch keeps them apart and avoids reusing addresses across coins, which helps privacy. Change gets its own branch inside each account. Status: In use. Page: https://utxohub.com/bips/44 ### BIP-45: Structure for Deterministic P2SH Multisignature Wallets Sets out how a shared wallet that needs several signatures makes its addresses, so different apps can work together. Each member creates their own keys, and any member's wallet can make all the shared addresses without contacting the others. Making and signing a payment still needs the members to work together. Status: Finished. Page: https://utxohub.com/bips/45 ### BIP-46: Address Scheme for Timelocked Fidelity Bonds Would set a standard way for wallets to make and find coins locked until a set date, used as fidelity bonds. A fidelity bond locks coins for a time to make faking many identities costly, which some privacy systems rely on. With a short fixed list of lock dates, the recovery words alone would be enough to find the bonds again. The keys could also stay offline. Status: Draft. Page: https://utxohub.com/bips/46 ### BIP-47: Reusable Payment Codes for Hierarchical Deterministic Wallets Lets someone share one reusable payment code openly while each payment to them still goes to a new address. Posting one address and being paid to it again and again harms privacy. With a payment code, the sender first makes a small 'notification' payment. After that, both wallets can work out a fresh address for every payment. Status: In use. Page: https://utxohub.com/bips/47 ### BIP-48: Multi-Script Hierarchy for Multi-Sig Wallets Writes down the key layout that wallets already use for shared, multi-signature accounts, so others can follow it. A number of wallets were already using this layout for wallets that need more than one signature. Making it a standard helps them work together. It includes a slot for the script type, so a future type does not need a whole new BIP. Status: In use. Page: https://utxohub.com/bips/48 ### BIP-49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts Defines where a wallet keeps keys for SegWit addresses wrapped in the older pay-to-script-hash format. Wallets that build every key from one backup need to agree on where each kind of address lives. This BIP gives these addresses their own accounts, so only wallets that understand them will look there and handle them properly. Status: In use. Page: https://utxohub.com/bips/49 ### BIP-50: March 2013 Chain Fork Post-Mortem Explains how one large block split the blockchain in two in March 2013, why it happened, and how it was fixed. Older node software hit a database limit and rejected a valid block that newer software accepted, so the network followed two chains. Two mining pools switched back to older software so that one chain won again. It also lists what went right and the follow-up actions. Status: In use. Page: https://utxohub.com/bips/50 ### BIP-52: Durable, Low Energy Bitcoin PoW Proposed changing Bitcoin's mining puzzle to one best solved by light-based chips that use much less energy. Mining uses a lot of electricity, so it mostly pays where power is cheap. This BIP suggested a new puzzle, optical proof of work, to shift miners' main cost from electricity to equipment, so more people could mine and fewer would switch off when rewards shrink. Status: Closed. Page: https://utxohub.com/bips/52 ### BIP-53: Disallow 64-byte transactions Would make payments exactly 64 bytes long invalid, closing loopholes that can fool light wallets and nodes. Each block holds a fingerprint of all its payments, built as a tree. A payment of exactly 64 bytes, not counting its SegWit data, can be mistaken for part of that tree, letting attackers trick light wallets or confuse nodes. Banning such payments would close the gap. Status: Draft. Page: https://utxohub.com/bips/53 ### BIP-54: Consensus Cleanup Defines one soft fork that fixes several long-standing weaknesses in Bitcoin's rules. One bug could let miners with most of the computing power drive difficulty down and speed up blocks. Specially built blocks can take minutes or hours to check. The fixes also stop a trick that fools light wallets and make an old duplicate-payment check unnecessary. Status: Finished. Page: https://utxohub.com/bips/54 ### BIP-60: Fixed Length "version" Message (Relay-Transactions Field) Proposed always including the relay flag in the greeting message nodes exchange, rather than leaving it optional. BIP 37 added a flag to this first message saying whether a node wants to hear about new payments. Because the flag was optional, the message no longer had a fixed length, which made it harder to read and check reliably. Status: Closed. Page: https://utxohub.com/bips/60 ### BIP-61: Reject P2P message Lets a node tell another node why it refused a block or payment it was sent. A reason code helps different Bitcoin programs work together and spot problems. It can also warn light wallets that something is wrong, for example when a payment is refused because its fee is too low. Status: In use. Page: https://utxohub.com/bips/61 ### BIP-62: Dealing with malleability Proposed rules to stop others from altering a payment while it travels across the network, before it is confirmed. Someone could tweak a payment in transit, without its private keys, and it would still be valid. The sender might not recognise it, and a follow-on payment spending its change could become invalid. This BIP listed the known causes, such as loosely formatted signatures, and proposed rules to close them. Status: Closed. Page: https://utxohub.com/bips/62 ### BIP-64: getutxo message Proposed a message letting light wallets ask a node whether particular coins are still unspent. Every full node keeps a list of unspent coins to catch double spending. This message would have let apps without that list ask a node directly, for example to check a pledge had not been spent elsewhere. Nothing proved the answers were true, so a dishonest node could give wrong results. Status: Closed. Page: https://utxohub.com/bips/64 ### BIP-65: OP_CHECKLOCKTIMEVERIFY Lets coins be locked so they cannot be spent until a chosen date or block height. A payment could already be set to wait until a future time, but nothing stopped the coins being spent sooner in another payment. This new check in Bitcoin's scripts, the small programs that decide who can spend coins, makes the lock binding. It supports uses such as escrow, refunds after a deadline and payment channels. Status: In use. Page: https://utxohub.com/bips/65 ### BIP-66: Strict DER signatures Requires every signature to follow one strict, standard format, so all nodes agree on which signatures are valid. Nodes relied on an outside code library, OpenSSL, to read signatures, and it accepted slightly malformed ones. When an update to it changed this, some nodes rejected the chain. This rule accepts only signatures in the exact standard format (DER), so validity no longer depends on that library. Once the whole network enforced it, its author disclosed that it had also, indirectly, fixed a flaw he had found earlier in the rules every node must agree on. Status: In use. Page: https://utxohub.com/bips/66 ### BIP-67: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Defines how to sort the keys behind a shared, multi-key address, so the same keys always give the same address. Some addresses need signatures from several keys to spend. Listing the same keys in a different order gave a different address, making these shared accounts hard to recognise. Sorting the public keys in a fixed way means compatible wallets always produce one address for a given set of keys. Status: Finished. Page: https://utxohub.com/bips/67 ### BIP-68: Relative lock-time using consensus-enforced sequence numbers Lets a payment be held back until a set number of blocks or amount of time after the coins it spends were confirmed. Each input of a payment has a 'sequence number' that was never properly used. This BIP gives it a new meaning: a waiting period, counted from when the coins being spent were confirmed. Among other things, this makes two-way payment channels possible. Status: In use. Page: https://utxohub.com/bips/68 ### BIP-69: Lexicographical Indexing of Transaction Inputs and Outputs Sets a standard order for a payment's inputs and outputs, so the order no longer gives away private details. Wallets each ordered inputs and outputs in their own way, for example putting change last. Watchers could use those habits to spot which wallet made a payment and which output was change. Sorting by fixed rules makes payments from different wallets look alike in this respect. Status: Finished. Page: https://utxohub.com/bips/69 ### BIP-70: Payment Protocol Lets shops send a wallet a signed payment request, so you see who you are paying instead of a bare address. Copying a long address from a web page is error-prone, and an attacker could swap it. With this protocol, the wallet can show the shop's verified name, the customer gets proof of payment for disputes, and the wallet can pass on a refund address automatically. Status: In use. Page: https://utxohub.com/bips/70 ### BIP-71: Payment Protocol MIME types Names the official file types for payment protocol messages sent over the web or by email. This is housekeeping for the BIP 70 payment protocol. It gives each message, such as a payment request, a standard label (a MIME type) so web servers, email programs and wallets handle it correctly. Status: In use. Page: https://utxohub.com/bips/71 ### BIP-72: bitcoin: uri extensions for Payment Protocol Lets a bitcoin: payment link point to a web address where the wallet fetches a full payment request. It adds an optional 'r' part to bitcoin: links in web pages and emails. Wallets that support it fetch the payment request from that address and follow the BIP 70 payment protocol. Older wallets can still use the plain address and amount in the link. Status: In use. Page: https://utxohub.com/bips/72 ### BIP-73: Use "Accept" header for response type negotiation with Payment Request URLs Lets a payment QR code hold a short web link, so the code is less dense and easier to scan. Long payment links make dense QR codes that can be hard to scan. With this BIP, the code holds just a short web address. The wallet tells the server whether it wants a bitcoin: link or a full payment request, and the server replies with that. Status: In use. Page: https://utxohub.com/bips/73 ### BIP-74: Allow zero value OP_RETURN in Payment Protocol Proposed letting payment requests include zero-value data outputs, so no bitcoin is lost when attaching data. An OP_RETURN output lets a payment carry a small piece of data. The BIP 70 payment protocol ignored outputs worth nothing, so merchants had to put some value in these outputs, and that value was lost forever. This change would have let them be worth zero. Status: Closed. Page: https://utxohub.com/bips/74 ### BIP-75: Out of Band Address Exchange using Payment Protocol Encryption Lets wallets swap fresh payment addresses privately, with encrypted payment requests and an optional sender identity. It extends the BIP 70 payment protocol. The sender can choose to sign their request so the receiver knows who is asking, and the reply is encrypted so only the two parties can read it. This lets a wallet keep an address book and fetch a new address for each payment, avoiding address reuse. Status: In use. Page: https://utxohub.com/bips/75 ### BIP-77: Async Payjoin Would let a payer and receiver build a joint Payjoin payment without both needing to be online at the same time. The first Payjoin version needed the receiver to run a secure web server, with both sides online at once. This version passes encrypted messages through a go-between server that cannot read them or link them to users' internet addresses. Payjoin mixes both people's coins in one payment, helping privacy and saving fees. Status: Draft. Page: https://utxohub.com/bips/77 ### BIP-78: A Simple Payjoin Proposal Lets the receiver add their own coins to a payment, so outsiders can no longer assume every input belongs to the payer. Observers usually guess that all the coins going into a payment belong to one person, and try to spot which output is change. With Payjoin, payer and receiver agree on a payment that includes coins from both, which breaks these guesses. The receiver can also combine some of their own coins at the same time. Status: In use. Page: https://utxohub.com/bips/78 ### BIP-79: Bustapay :: a practical coinjoin protocol Proposed Bustapay, a way for payer and receiver to sign one payment together to defeat common tracking methods. The payer first hands over a complete, signed payment; if the joint version never arrives, the receiver can broadcast that one instead. The receiver adds their own coins, hiding who owns what and how much was really sent. BIP 78, Payjoin, is listed as its replacement. Status: Closed. Page: https://utxohub.com/bips/79 ### BIP-80: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Proposed a key layout for the shared, multi-key wallets used by 'voting pools', whose members hold deposits together. From one seed, it gave each currency and each 'series' of deposits its own branch of keys. Spreading deposits across series let most of their private keys stay offline, with only a small part brought online to pay withdrawals. Status: Closed. Page: https://utxohub.com/bips/80 ### BIP-81: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Proposed a key layout for 'voting pool' shared wallets that handle coloured coins, giving each colour its own keys. It is the coloured-coin companion to BIP 80. Each 'colour definition' is shortened with a hash and split across five levels of the key tree, so one seed can handle many colours. Keys at the last level build the shared deposit addresses the pool's members have agreed on. Status: Closed. Page: https://utxohub.com/bips/81 ### BIP-83: Dynamic Hierarchical Deterministic Key Trees Proposed a flexible way for wallets to add new levels to their tree of keys whenever they need them. Earlier standards fixed the layout of a wallet's keys in advance. This scheme reserved the first slot at every level for opening a deeper sub-level, so apps could create sub-accounts and other structures as needed, and share their layouts with each other. Status: Closed. Page: https://utxohub.com/bips/83 ### BIP-84: Derivation scheme for P2WPKH based accounts Sets the key layout wallets use for native segwit addresses, so any compatible wallet can find them from one backup. A wallet makes all its keys from one seed, but must know which branch of its key tree to look in. This BIP reserves branch 84 for native segwit addresses (starting 'bc1q'), so restoring the same backup in another compatible wallet finds the same coins. Status: In use. Page: https://utxohub.com/bips/84 ### BIP-85: Deterministic Entropy From BIP32 Keychains Lets one master backup create separate recovery words, keys and passwords for other wallets and apps. Keeping many separate backups is hard, but sharing one set of recovery words across wallets is risky. With this BIP, one master key creates fresh secrets for each wallet, and the master backup can recreate them all. If one of those secrets leaks, the master key stays safe. Status: In use. Page: https://utxohub.com/bips/85 ### BIP-86: Key Derivation for Single Key P2TR Outputs Sets the key layout wallets use for single-key Taproot addresses, so they can be found again from one backup. Many wallets and signing devices back up only the seed, not which kinds of address were used. This BIP reserves branch 86 of the key tree for Taproot addresses controlled by one key, following BIPs 49 and 84, so a wallet restoring the backup is likely to find those coins. Status: In use. Page: https://utxohub.com/bips/86 ### BIP-87: Hierarchy for Deterministic Multisig Wallets Sets a standard key layout for shared wallets that need several keys to spend, whatever the address type. Earlier layouts for these multi-signature wallets were tied to one address type or kept a list of types. This BIP uses branch 87 for all of them and leaves the address type to the wallet's 'descriptor', a record of the keys and script used, which must also be backed up. Status: Finished. Page: https://utxohub.com/bips/87 ### BIP-88: Hierarchical Deterministic Path Templates Defines a short way to write down which key-tree paths a wallet or signing device will accept. Wallets lay out their keys differently, which makes moving between them hard. A path template states which paths are allowed, so software can describe its own layout, and a device can refuse unexpected paths, such as sending change to an address the sender cannot spend from. Status: Finished. Page: https://utxohub.com/bips/88 ### BIP-89: Chain Code Delegation Lets a co-signer of a shared wallet help approve payments without seeing the wallet's balance or other activity. In shared wallets that need several keys to spend, co-signers usually swap extended public keys (xpubs), which let each of them track every payment. Here one party keeps back part of that data and gives the co-signer just enough to check and sign each payment. It suits an owner who wants privacy from a custodian. Status: In use. Page: https://utxohub.com/bips/89 ### BIP-90: Buried Deployments Replaces old miner-vote checks for three past upgrades with the fixed block heights at which they took effect. BIPs 34, 65 and 66 switched on once enough miners signalled support, and checking this meant looking back over the previous 1,000 blocks. Since those upgrades are long settled, nodes now treat each rule as active from a recorded block height. It is a tidy-up of node software. Status: In use. Page: https://utxohub.com/bips/90 ### BIP-91: Reduced threshold Segwit MASF Sets out how miners could push segwit through with about 80% support, instead of the 95% it originally needed. Once about 80% of recent blocks signal for this BIP, any block that does not also signal for segwit is rejected. That pushes segwit's own vote past its 95% threshold. The rule stops applying once segwit is locked in, active or failed. Status: In use. Page: https://utxohub.com/bips/91 ### BIP-93: codex32: Checksummed SSSS-aware BIP32 seeds Would let people back up a wallet's master secret as a checked code, optionally split into shares, even by hand with pen and paper. Fewer backups are safer from theft, but more are safer from loss. codex32 can split the secret into up to 31 shares, with a chosen number (2 to 9) needed to restore it; fewer shares reveal nothing. A checksum catches mistakes and can be verified by hand. Status: Draft. Page: https://utxohub.com/bips/93 ### BIP-94: Testnet 4 Sets up Testnet 4, a separate network for testing Bitcoin software, whose coins are meant to have no value. Testnet 3 had become hard to use: a quirk let difficulty reset to its minimum, causing floods of blocks, and its coins were being bought and sold. Testnet 4 follows mainnet's rules, with small changes to stop these 'block storms' and timestamp tricks that lower difficulty. Status: In use. Page: https://utxohub.com/bips/94 ### BIP-95: Testnet 5 Would set up Testnet 5, a testing network to replace Testnet 4, with no low-difficulty shortcut for miners. Testnet 4 let a block be mined at the lowest difficulty if 20 minutes passed without one. This was exploited so much that the latest blocks kept being replaced. Testnet 5 drops that exception, raises the minimum difficulty and applies the BIP 54 rule fixes from the first block. Status: Draft. Page: https://utxohub.com/bips/95 ### BIP-98: Fast Merkle Trees Would define a faster, safer Merkle tree, a way to prove an item is in a list without revealing the whole list. Bitcoin's original Merkle tree, used to list a block's payments, has a known flaw with duplicate entries and does more hashing than needed. This design avoids the flaw and is about 55% faster to build and check. It is meant for new features, such as BIP 116. Status: Draft. Page: https://utxohub.com/bips/98 ### BIP-99: Motivation and deployment of consensus rule changes ([soft/hard]forks) Set out the different kinds of change to Bitcoin's rules and proposed how each kind should be rolled out. Discussions of rule changes often led to confusion and delays. This document sorted them into types, such as accidental splits, soft forks that tighten the rules, and hard forks that need every user to upgrade, and suggested a deployment path for each. It is a guide, not a rule change. Status: Closed. Page: https://utxohub.com/bips/99 ### BIP-100: Dynamic maximum block size by miner vote Proposed letting miners vote to raise or lower the maximum block size in small steps, replacing the fixed 1 MB limit. Miners would write their preferred size into each block they mine. Every 2,016 blocks, when difficulty is adjusted, the limit could move by up to 5% if 75% of those blocks backed it. The author argued that miners feel the effects of block size directly. Status: Closed. Page: https://utxohub.com/bips/100 ### BIP-101: Increase maximum block size Proposed raising the maximum block size to 8 MB, then doubling it every two years until 2036. Payment volume was nearing the 1 MB-per-block limit. This plan grew the limit on a fixed schedule based on block timestamps, ending just above 8 GB. As a hard fork, it needed everyone running a full node to upgrade, or they could reject the larger blocks. Status: Closed. Page: https://utxohub.com/bips/101 ### BIP-102: Block size increase to 2MB Proposed a one-time rise in the maximum block size from 1 MB to 2 MB. It aimed to keep fees and block space in line with market expectations in the short term. Older nodes that fully check blocks would be cut off from the network by the first block over 1 MB, so everyone would have needed to upgrade. Status: Closed. Page: https://utxohub.com/bips/102 ### BIP-103: Block size following technological growth Proposed growing the maximum block size slowly, by about 17.7% a year, to keep pace with improving technology. Its author argued that Bitcoin's strength is needing little trust, not handling huge volume, so any rise should be gradual and start well in the future. The limit would rise by 4.4% roughly every 97 days. As a hard fork, every full node would have needed to adopt it. Status: Closed. Page: https://utxohub.com/bips/103 ### BIP-104: 'Block75' - Max block size like difficulty Proposed adjusting the maximum block size automatically to keep blocks about 75% full on average. Like the difficulty adjustment, the limit would change every 2,016 blocks, up or down, based on how full recent blocks were. The aim was to keep fees stable and take people out of block size decisions. All software that fully checks blocks would have needed upgrading. Status: Closed. Page: https://utxohub.com/bips/104 ### BIP-105: Consensus based block size retargeting algorithm Proposed letting miners vote on the block size, with a harder mining target for any miner voting to raise it. Each miner could vote to change the limit by up to 10%, and every 2,016 blocks the limit would be reset to the middle vote. Voting for a rise meant meeting a tougher difficulty target, a cost meant to stop large miners pushing the size up cheaply. Status: Closed. Page: https://utxohub.com/bips/105 ### BIP-106: Dynamically Controlled Bitcoin Block Size Max Cap Proposed letting the maximum block size grow or shrink each difficulty period, based on how full recent blocks were. It offered two options. One doubled or halved the limit depending on how full recent blocks were; the other also considered whether total fees paid to miners were rising or falling. Both aimed to let the limit follow demand rather than stay fixed at 1 MB. Status: Closed. Page: https://utxohub.com/bips/106 ### BIP-107: Dynamic limit on the block size Proposed raising the maximum block size in steps to 6 MB, then letting it grow further with sustained demand. Phase 1 set the limit at 2 MB, then 4 MB, then 6 MB. In phase 2 it would rise by 10% whenever three-quarters of blocks over about four weeks were at least 60% full, and it could never fall. It aimed to balance low fees against the risk of mining becoming centralised. Status: Closed. Page: https://utxohub.com/bips/107 ### BIP-109: Two million byte size limit with sigop and sighash limits Proposed raising the maximum block size from 1 MB to 2 MB, with new limits on signature checks and hashing. Bigger blocks could let an attacker build blocks that take a very long time to check. So alongside the 2 MB limit, it counted signature checks more accurately and capped the data hashed for signatures in each block. Older nodes would be cut off by the first block breaking the old limits. Status: Closed. Page: https://utxohub.com/bips/109 ### BIP-110: Reduced Data Temporary Softfork Proposed a temporary, one-year rule change limiting how much non-payment data a Bitcoin payment could carry. Its author argued that storing arbitrary data, such as 'inscriptions', burdens node operators and makes payments costlier. It would have made large data fields invalid for a year, while coins created before it started could still be spent as before. Status: Closed. Page: https://utxohub.com/bips/110 ### BIP-111: NODE_BLOOM service bit Lets nodes say whether they offer the bloom filter service that some lightweight wallets use to find their payments. BIP 37 assumed every node offered this filtering, but it gives wallets little privacy and can be used to overload nodes. This BIP adds a flag that nodes use to announce the service, so node operators can switch it off. Status: In use. Page: https://utxohub.com/bips/111 ### BIP-112: CHECKSEQUENCEVERIFY Lets coins be locked so they can only be spent once they have waited a set time or number of blocks after arriving. Some arrangements need a waiting period that starts only when coins arrive, such as an escrow that times out 30 days after funding, or Lightning payment channels. Working with BIP 68, this lets a script, the small program that decides who can spend coins, require that the coins being spent are old enough. Status: In use. Page: https://utxohub.com/bips/112 ### BIP-113: Median time-past as endpoint for lock-time calculations Uses the middle time of the last 11 blocks, not one block's own clock, to decide when time-locked payments can go through. Block timestamps don't have to be in order, so miners had a reason to fake the time and include time-locked payments early to collect more fees. The middle time of the last 11 blocks only ever moves forward, which removes that reason. Status: In use. Page: https://utxohub.com/bips/113 ### BIP-114: Merkelized Abstract Syntax Tree Proposed a way to lock coins under many alternative spending rules while revealing only the one actually used. Coins are spent by meeting the rules in a script, a small program, and every branch of it has to be shown even if it isn't used. This proposal organised the branches in a tree so only the used branch is revealed. That would have allowed more complex conditions, saved space and improved privacy. Status: Closed. Page: https://utxohub.com/bips/114 ### BIP-115: Generic anti-replay protection using Script Proposed a script check that ties a payment to one particular chain, so it can't be copied onto another chain after a split. If Bitcoin ever split into two lasting chains, a payment made on one could be replayed on the other. This check would make a payment valid only if a chosen block is in the chain's history. It could also help a wallet stay safe when an unconfirmed payment it received is double-spent. Status: Closed. Page: https://utxohub.com/bips/115 ### BIP-116: MERKLEBRANCHVERIFY Would let a script check that one or more items come from a list fixed in advance, without revealing the whole list. Today a script, the small program that decides who can spend coins, has to show every possible spending condition, even unused ones. That wastes space and reveals private details of a contract. This new check would let coins commit to a set of keys or rules and reveal only the ones needed when spending. Status: Draft. Page: https://utxohub.com/bips/116 ### BIP-117: Tail Call Execution Semantics Would let a script reveal and run only the spending rule actually used, out of a large set fixed in advance. Earlier upgrades (BIP 16 and segwit) still require all of a coin's spending rules to sit in one script, used or not. Together with BIP 116, this would let coins commit to a practically unlimited number of separate spending paths and reveal only the path taken, which saves space and keeps the others private. Status: Draft. Page: https://utxohub.com/bips/117 ### BIP-118: SIGHASH_ANYPREVOUT for Taproot Scripts Would add a type of signature that isn't tied to one exact coin, so one pre-signed payment can respond to many possible ones. Systems that settle later on the blockchain often prepare a reply payment in advance. Today each signature commits to one exact coin, so a new signature is needed for every case. This opt-in signature, for taproot scripts, could be reused for any coin with a compatible script. Status: Draft. Page: https://utxohub.com/bips/118 ### BIP-119: CHECKTEMPLATEVERIFY Would let coins be locked so they can only be spent by a payment that matches a template fixed in advance. Setting coins up to move in a set way today relies on signing transactions ahead of time, which needs trust, coordination and safe storage of those signatures. This check would compare the spending payment, including its outputs, against a fingerprint of a template chosen in advance. Status: Draft. Page: https://utxohub.com/bips/119 ### BIP-120: Proof of Payment Proposed a way for a wallet to prove it made a past payment, so the payment could act as a ticket or key. The BIP gives examples such as using it as the key to a pre-paid hotel room, or a video rental watched on any device. The proof is made on demand, can be used only once, and shows you hold the keys behind the payment, without sharing a name, password or email address. Status: Closed. Page: https://utxohub.com/bips/120 ### BIP-121: Proof of Payment URI scheme Proposed a link format, similar to bitcoin: payment links, for asking a wallet to produce a Proof of Payment. This is a companion to BIP 120. Whoever wants the proof creates a btcpop: link, which can be shown as a QR code or sent over NFC to the payer's wallet. The wallet then sends its proof to the destination named in the link, such as a web address. Status: Closed. Page: https://utxohub.com/bips/121 ### BIP-122: URI scheme for Blockchain references / exploration Would add blockchain: links that open a block, payment or address in whichever explorer or app the user prefers. Wallets often send people to one fixed blockchain explorer, or leave them to copy and paste. A standard link type would let apps, posts and messages point to a payment or block and leave the choice of tool to the user. Status: Draft. Page: https://utxohub.com/bips/122 ### BIP-123: BIP Classification Sorts BIPs into four layers, from the core rules everyone must follow to optional features in apps. This is housekeeping for the BIP process. Some standards must be followed by everyone for Bitcoin to work, while others are optional. Each BIP is placed in the consensus, peer services, API/RPC or applications layer, and lower layers are harder to agree on and roll out. Status: In use. Page: https://utxohub.com/bips/123 ### BIP-124: Hierarchical Deterministic Script Templates Proposed a shared template format so different wallets build the same scripts from the same keys. Wallets that work together, for example on a shared wallet that needs two of three keys to spend, often create keys and scripts in different ways and can't match up. Templates based on BIP 32 key paths would make them produce identical results, including for more complex time-locked contracts. Status: Closed. Page: https://utxohub.com/bips/124 ### BIP-125: Opt-in Full Replace-by-Fee Signaling Lets a sender mark a payment as replaceable, so it can be swapped for one paying a higher fee if it is slow to confirm. Many nodes wouldn't replace a waiting payment with another that spends the same coins, so a stuck payment was hard to fix. With this signal, nodes may accept a replacement. A recipient may choose to wait for a confirmation before treating a payment that carries the signal as paid. Status: In use. Page: https://utxohub.com/bips/125 ### BIP-126: Best Practices for Heterogeneous Input Script Transactions Would set common patterns for payments that combine coins from several addresses, so they reveal less about the sender. When a wallet spends coins received at different addresses together, it shows they belong to the same person. These guidelines shape such payments, for example with at least two outputs of equal value, so ordinary payments look like privacy-protecting ones and are harder to analyse. Status: Draft. Page: https://utxohub.com/bips/126 ### BIP-127: Simple Proof-of-Reserves Transactions Defines a standard way for a company holding customers' bitcoin to prove that it controls a given amount. Companies holding coins for users have lost them without saying so. This sets out a proof shaped like a payment that can never be confirmed, signed with the keys to the company's coins, so anyone can check the funds exist. It formalises the existing method and has known privacy weaknesses. Status: Finished. Page: https://utxohub.com/bips/127 ### BIP-128: Timelock-Recovery Storage Format Would set a standard file format for recovery plans: pre-signed payments that move coins to a backup wallet after a delay. Pre-signed payments can protect against a lost seed or help with inheritance. This plan uses two payments, with a waiting period before the second, so the owner can still cancel. A shared format lets one wallet create the plan and another app or service watch it and carry it out. Status: Draft. Page: https://utxohub.com/bips/128 ### BIP-129: Bitcoin Secure Multisig Setup (BSMS) Defines a safe, step-by-step way to set up a multisig wallet, one that needs several keys to spend, across different devices. If someone tampers with the setup of a shared wallet, they could trick users into sending coins to the wrong address, and leaked details harm privacy. Here a coordinator gathers each signer's key, builds the wallet's description and sends it back, and each signer checks its own key is in it. Status: Finished. Page: https://utxohub.com/bips/129 ### BIP-130: sendheaders message Lets a node ask its peers to announce new blocks by sending the block's header, a short summary, instead of just its ID. Before this, a node announced a new block by its ID, and the peer then had to ask for the header separately. Sending the header straight away saves a round of messages and handles changes to the chain more smoothly. This is behind-the-scenes plumbing between nodes. Status: In use. Page: https://utxohub.com/bips/130 ### BIP-131: "Coalescing Transaction" Specification (wildcard inputs) Proposed a new kind of payment that would spend every coin held at one address with a single signature. Spending many small coins sent to the same address means listing each one and repeating the signature, which makes the payment large and costly. This 'coalescing' payment would have swept them up in one go. It needed a hard fork, a rule change that older software would not accept. Status: Closed. Page: https://utxohub.com/bips/131 ### BIP-132: Committee-based BIP Acceptance Process Proposed that committees for developers, miners, merchants and users vote on whether each BIP is accepted. This was about the BIP process, not Bitcoin's rules. BIP 1 set out how to write a BIP but not how one is accepted. This proposal added fixed periods for comment and opinion, and counted a BIP as accepted with 70% support in three of the four groups. Status: Closed. Page: https://utxohub.com/bips/132 ### BIP-133: feefilter message Lets a node tell its peers not to announce payments whose fee rate is below a level it sets. Nodes keep a limited mempool, the waiting area for unconfirmed payments, and turn away low-fee payments that are unlikely to be mined. Telling peers its minimum fee rate means they skip announcing payments it would reject anyway, which saves bandwidth. Status: In use. Page: https://utxohub.com/bips/133 ### BIP-134: Flexible Transactions Proposed a new, more flexible payment format built from labelled fields, to make future upgrades easier. The format would have fixed all known ways for a payment's ID to be changed before it confirms, and let old signatures be dropped to save space. It needed a hard fork, a rule change that older software would not accept. Status: Closed. Page: https://utxohub.com/bips/134 ### BIP-135: Generalized version bits voting Proposed a more flexible way for miners to signal support for upgrades, with separate thresholds for each one. BIP 9 let miners signal readiness for a soft fork using bits in each block, with a fixed 95% threshold. This would have let each upgrade set its own threshold, counting period and waiting time, and cover any kind of rule change, not just soft forks. Status: Closed. Page: https://utxohub.com/bips/135 ### BIP-136: Bech32 Encoded Tx Position References Would give each confirmed payment a short reference based on where it sits in the blockchain, easier to read out than its ID. A payment ID is 64 characters long and can be slow for some software to look up. A reference such as tx1:rqqq-qqqq-qwtv-vjr records the block number and the payment's position in it. Unlike an ID it can point to the wrong place if the chain changes, so apps must not show it until a payment has 6 confirmations. Status: Draft. Page: https://utxohub.com/bips/136 ### BIP-137: Signatures of Messages using Private Keys Defines a standard way to sign a message with a Bitcoin private key, so others can check it came from an address's owner. People sign messages to prove they control funds, for audits, event entry and more. With several address types in use, it wasn't clear which type a signature belonged to. This sets one format that different wallets can agree on. A newer format, BIP 322, has more advantages. Status: In use. Page: https://utxohub.com/bips/137 ### BIP-138: Compact Encryption Scheme for Non-seed Wallet Data Would encrypt a wallet's setup details so backups can be stored anywhere, and opened only by the wallet's own keyholders. Wallets that need several keys also need a record of which keys and rules they use, and losing it can be almost as bad as losing the seed. This lets you keep an encrypted copy online without exposing addresses or keys. Listed cosigners open it with their xpub. Private keys must never go in it. Status: Draft. Page: https://utxohub.com/bips/138 ### BIP-139: Wallet Metadata Export Format Status: Draft. Page: https://utxohub.com/bips/139 ### BIP-140: Normalized TXID Proposed a version of the payment ID that ignores signatures, so nobody could change a payment's ID by altering them. A signer, or someone else, could tweak how a payment was signed, which changed its ID. Any later payment built on the old ID then became invalid. This 'normalised' ID would have left out the signature data, so it stayed the same. Status: Closed. Page: https://utxohub.com/bips/140 ### BIP-141: Segregated Witness (Consensus layer) Moves signatures into a separate part of each payment, so they can't change its ID, and lets blocks hold more. Before this, changing how a payment was signed changed its ID. Segwit keeps signature data apart from the part that sets the ID. It also counts that data at a discount using a new measure, weight, which is where virtual bytes (vB) in fee rates come from. Status: In use. Page: https://utxohub.com/bips/141 ### BIP-142: Address Format for Segregated Witness Proposed an address format for segwit payments, written in the same style as older Bitcoin addresses. Segwit added new kinds of payment, and wallets needed a standard address to receive them directly. This design used the same base58 style as older addresses, with fixed lengths and a version number for future upgrades. Status: Closed. Page: https://utxohub.com/bips/142 ### BIP-143: Transaction Signature Verification for Version 0 Witness Program Changes how segwit signatures are checked, making checks faster and making signatures cover the amount being spent. With the original method, the work to check a payment's signatures grew sharply with its size, so one large payment could take many seconds to verify. The new method avoids repeated work. Signing the amount also lets offline signing devices know exactly what they are spending and the fee. Status: In use. Page: https://utxohub.com/bips/143 ### BIP-144: Segregated Witness (Peer Services) Lets nodes share segwit payments and blocks, including their signature data, without confusing older nodes. This is behind-the-scenes plumbing between nodes. Segwit stores signatures in a new place, so nodes need a way to say they support it and to request and pass on that data. Older nodes keep receiving data in the format they understand. Status: In use. Page: https://utxohub.com/bips/144 ### BIP-145: getblocktemplate Updates for Segregated Witness Updates the request miners use to get a block template so that it handles segwit payments. Mining software uses getblocktemplate to ask a node which payments to put in the next block. This adds what segwit needs, such as each payment's weight and the block's weight limit. It mainly matters to miners and mining pool software. Status: In use. Page: https://utxohub.com/bips/145 ### BIP-146: Dealing with signature encoding malleability Proposed two rules to stop anyone relaying a payment from changing the form of its signatures. Anyone passing a payment along could change a signature into another valid form, without the private key. For payments made without segwit that changes the payment's ID and breaks any unconfirmed payments that depend on it. These rules would have allowed only one form. Status: Closed. Page: https://utxohub.com/bips/146 ### BIP-147: Dealing with dummy stack element malleability Requires an extra, unused value in multi-signature checks to be empty, so it can't be swapped to change a payment. Because of a design flaw, the check for payments needing several signatures uses up an extra item that it never looks at. Anyone relaying the payment could swap that item, which could change the payment's ID. This rule requires the item to be empty. Status: In use. Page: https://utxohub.com/bips/147 ### BIP-148: Mandatory activation of segwit deployment Makes nodes reject blocks that don't signal support for segwit during a set period in 2017, to push segwit to switch on. Segwit was waiting for blocks to signal support for it. For a fixed window, nodes running this rule refuse any block that doesn't signal, which makes the existing segwit upgrade lock in. The rule stops applying once segwit is locked in. Status: In use. Page: https://utxohub.com/bips/148 ### BIP-149: Segregated Witness (second deployment) Proposed a second launch of segwit, backed by users' nodes, that would lock in by a deadline without needing most miners. Miners had been slow to signal for segwit's first launch. This backup plan would only have run if that attempt failed. It gave users time to prepare and no longer needed most miners to agree, while still letting miners switch segwit on early. Status: Closed. Page: https://utxohub.com/bips/149 ### BIP-150: Peer Authentication Proposed a way for nodes to prove who they are to trusted peers, to spot impostors and unlock extra services. Node operators may want to give certain peers extra access, or check they haven't connected to an attacker posing as a known peer. This would have let peers identify each other with keys, without sending secrets or making nodes easy to track. It relied on the encrypted links of BIP 151. Status: Closed. Page: https://utxohub.com/bips/150 ### BIP-151: Peer-to-Peer Communication Encryption Proposed encrypting the traffic between Bitcoin nodes so outsiders can't easily read it or tamper with it unseen. Nodes talked to each other unencrypted, so an internet provider could link a user to their addresses and see the amount and recipient of new payments. Encryption would make that much harder and make tampering detectable, though message sizes and timing would still show. Status: Closed. Page: https://utxohub.com/bips/151 ### BIP-152: Compact Block Relay Lets nodes send new blocks in a compact form that leaves out payments the receiving node has already seen. Most transactions in a new block are already waiting in a node's mempool, so sending them again wastes bandwidth and can briefly swamp home internet connections. Compact blocks send short payment IDs instead, and the node fills in the rest from what it has. Status: In use. Page: https://utxohub.com/bips/152 ### BIP-154: Rate Limiting via peer specified challenges Proposed making peers solve a small proof-of-work puzzle to earn some connection slots on a node. It is cheap to flood the network with fake nodes that use up connection slots, which can cut honest nodes off from each other. Asking newcomers to do some work for certain slots would have made such attacks more costly. Status: Closed. Page: https://utxohub.com/bips/154 ### BIP-155: addrv2 message Lets nodes share longer network addresses, such as newer Tor and I2P addresses, with each other. The old message for passing on node addresses only had room for 128 bits, too short for newer Tor addresses, which offer better encryption and privacy, or for I2P. This lets nodes reachable over these networks be found and connected to. These are internet addresses for nodes, not Bitcoin addresses. Status: In use. Page: https://utxohub.com/bips/155 ### BIP-156: Dandelion - Privacy Enhancing Routing Proposed hiding where a payment came from by passing it along a random chain of nodes before spreading it widely. The usual way of spreading a payment lets spy nodes work out which node, and so which internet address, sent it. Dandelion would first send it along a random path, the 'stem', and then spread it normally, the 'fluff'. Status: Closed. Page: https://utxohub.com/bips/156 ### BIP-157: Client Side Block Filtering Lets light wallets check each block for their payments using small filters from full nodes, keeping more of their activity private. Light wallets don't download every block, so they ask full nodes for help. An older method made them reveal what they were looking for and put a load on nodes. Here a node sends a small filter for each block, the wallet checks it itself, and downloads the whole block only when it might hold its payments. Status: In use. Page: https://utxohub.com/bips/157 ### BIP-158: Compact Block Filters for Light Clients Defines the small, compressed block filters that light wallets use to spot blocks that may contain their payments. This is the companion to BIP 157. It sets out exactly how a block's filter is built and squeezed down so it is cheap to download. The basic filter covers what ordinary wallets look for, such as the addresses paid and the coins spent in a block. Status: In use. Page: https://utxohub.com/bips/158 ### BIP-159: NODE_NETWORK_LIMITED service bit Lets nodes that keep only recent blocks say so, promising to serve at least the last 288 blocks, about two days. Some nodes delete old blocks to save disk space, which is called pruning. They can still pass on new blocks and payments, but can't hand out the full history. This BIP gives them a flag to announce that, so other nodes and light wallets know what to ask them for. Status: In use. Page: https://utxohub.com/bips/159 ### BIP-171: Currency/exchange rate information API Proposed a standard way for apps to ask a server for currency exchange rates against bitcoin. Wallets that show amounts in dollars or other currencies need exchange rates from somewhere. This set out a common set of web requests and replies, so any app could fetch rates from any server that followed it. It did not change how Bitcoin itself works. Status: Closed. Page: https://utxohub.com/bips/171 ### BIP-172: Define Bitcoin Subunits as Satoshis Would make 'satoshi' the standard name for the smallest unit of bitcoin, a hundred-millionth of a coin, with 'sats' as the short form. People use several names for Bitcoin's smallest unit, which can confuse newcomers. This proposal would settle on 'satoshi' or 'satoshis', shortened to 'sat' or 'sats', with 100,000,000 satoshis in one bitcoin. It also says how screen readers should pronounce the words. Status: Draft. Page: https://utxohub.com/bips/172 ### BIP-173: Base32 address format for native v0-16 witness outputs Defines Bech32, the address format starting 'bc1' used for SegWit payments, designed to catch typing mistakes. Older addresses mix upper and lower case, are awkward to read aloud and take up more room in QR codes. Bech32 uses a single case and a stronger error check, so a wallet can spot almost any mistyped address before money is sent. It was made for the new kinds of output that SegWit added. Status: In use. Page: https://utxohub.com/bips/173 ### BIP-174: Partially Signed Bitcoin Transaction Format Defines PSBT, a standard format for passing an unsigned payment between wallets and devices so each can add its signature. Before this, each wallet had its own way of handling payments that need more than one signature. PSBT gives them one shared format. It also carries the details a hardware wallet or offline device needs to sign safely without looking up the coins being spent itself. Status: In use. Page: https://utxohub.com/bips/174 ### BIP-175: Pay to Contract Protocol Proposed a way to create a payment address from the terms of a contract, so both sides can prove who was paid and what for. Shops and customers usually rely on invoices and receipts. This set out how an invoice plus the merchant's extended public key could produce a one-off address. The address looks like any other on the blockchain, and spending from it needs both the contract and the merchant's private key. Status: Closed. Page: https://utxohub.com/bips/175 ### BIP-176: Bits Denomination Defines 'bits' as a name for 100 satoshis, a millionth of a bitcoin, to make small amounts easier to read. Small amounts written in bitcoin need many decimal places, which makes it easy to be out by a factor of ten. In bits, any amount needs at most two decimal places. Apps are encouraged to offer bits, but nothing obliges them to switch. Status: Finished. Page: https://utxohub.com/bips/176 ### BIP-177: Redefine Bitcoin's Base Unit Would make 'one bitcoin' mean the smallest unit, so amounts become whole numbers and today's 1 BTC equals 100 million bitcoins. Bitcoin's ledger counts whole units; the eight decimal places are a display habit. This proposal would call each smallest unit 'a bitcoin' and drop the name 'satoshi', while 'BTC' keeps its current meaning. Apps should let people switch between the old and new displays. The coins themselves would not change. Status: Draft. Page: https://utxohub.com/bips/177 ### BIP-178: Version Extended WIF Would add a tag to exported private keys saying which type of address they were used with. One private key can sit behind several kinds of address. When a key is imported, today's format doesn't say which kind was used, so the wallet has to watch them all. This extension would record the address type, so the wallet only needs to track the right one. Status: Draft. Page: https://utxohub.com/bips/178 ### BIP-179: Name for payment recipient identifiers Suggests calling Bitcoin addresses 'invoices' or 'invoice addresses', to stress that each should be used only once. The word 'address' suggests something that rarely changes, like a postal or email address. Bitcoin addresses are meant for a single payment, with a fresh one for each. This BIP proposes 'Bitcoin Invoice Address', with 'Bitcoin' and 'Address' optional, so people treat them as one-time use. Status: Finished. Page: https://utxohub.com/bips/179 ### BIP-180: Block size/weight fraud proof Proposed a short proof that light wallets could check to spot a block that breaks the size limit. Light wallets don't download whole blocks, so they can't check a block's size themselves. This set out a short proof, built from pieces of the block, showing that a block is over the size or weight limit. A light wallet could check the proof against the block header it already has. Status: Closed. Page: https://utxohub.com/bips/180 ### BIP-197: Hashed Time-Locked Collateral Contract Would define scripts that lock bitcoin as collateral for a loan made on another blockchain, returned when the loan is repaid. It describes two scripts, small programs that decide who can spend coins. A borrower locks bitcoin for a set time while borrowing another currency elsewhere. If they repay, they get the bitcoin back. If not, it can be swapped to cover the loan, or split between borrower and lender in shares agreed at the start. Status: Draft. Page: https://utxohub.com/bips/197 ### BIP-199: Hashed Time-Locked Contract transactions Set out a script that pays one person if they reveal a secret, or refunds the sender after a deadline. This is the hashed time-locked contract, or HTLC. A script is a small program that decides who can spend coins. Here the seller can claim the coins by revealing a secret, and if they don't, the buyer gets them back once time runs out. The BIP notes that the Lightning Network uses such scripts to pass payments along safely. Status: Closed. Page: https://utxohub.com/bips/199 ### BIP-300: Hashrate Escrows (Consensus layer) Would let coins move to separate side networks and back, with miners approving each withdrawal slowly over months. This is the 'drivechain' design. Coins sent to a sidechain, a separate network with its own rules, are locked on Bitcoin. To bring them back, miners vote on a withdrawal over a long period, instead of a fixed group of key holders signing it. People who ignore sidechains are unaffected. Status: Draft. Page: https://utxohub.com/bips/300 ### BIP-301: Blind Merged Mining (Consensus layer) Would let Bitcoin miners earn fees from other blockchains without running their software, by selling the right to make each block. Normally, to mine another chain alongside Bitcoin, miners must run that chain's software and get paid in its coins. Here, users of the other chain build its blocks and bid in bitcoin for the right to have theirs accepted. Miners take one winning bid at a time and are paid on Bitcoin. Status: Draft. Page: https://utxohub.com/bips/301 ### BIP-310: Stratum protocol extensions Would let mining machines and mining pools agree which extra features they support, starting with 'version rolling'. Stratum is the protocol mining hardware uses to get work from a pool. Adding features was risky, because some pools drop the connection on an unknown message. This adds one set-up message to agree on features, the first being a way to vary some bits of the block header while searching for a block. Status: Draft. Page: https://utxohub.com/bips/310 ### BIP-320: nVersion bits for general purpose use Would set aside 16 bits of each block header for miners to use freely, rather than for signalling upgrades. Part of each block header is used by miners to signal support for soft forks. Mining hardware also wants spare bits to vary while searching for a valid block. Reserving 16 bits lets node software ignore them, so it stops showing false warnings about unknown upgrades. Status: Draft. Page: https://utxohub.com/bips/320 ### BIP-321: URI Scheme Defines 'bitcoin:' payment links and QR codes that fill in the address, amount and a note in a wallet. This updates BIP 21 so people can pay by clicking a link or scanning a QR code. It covers modern address types, how to add new payment methods, and an optional proof of payment. Wallets must always get the person's approval before acting on a link. Status: Finished. Page: https://utxohub.com/bips/321 ### BIP-322: Generic Signed Message Format Defines a standard way to sign a message with any type of Bitcoin address, showing the signer could spend coins sent there. The old message-signing method only works with addresses starting with '1'. This one works with any address type by reusing Bitcoin's own spending rules. The BIP notes that no signed message can truly prove someone controls funds; it can only show they will be able to spend coins sent to that address. Status: Finished. Page: https://utxohub.com/bips/322 ### BIP-323: 24 nVersion bits for general purpose use Would set aside 24 bits of each block header as spare room for mining hardware, more than BIP 320's 16. Mining chips try huge numbers of variations of a block header to find a valid one. BIP 320's 16 spare bits proved too few, so some devices have started varying the timestamp instead. This would reserve 24 bits for that job and stop using them to signal upgrades. Status: Draft. Page: https://utxohub.com/bips/323 ### BIP-324: Version 2 P2P Encrypted Transport Protocol Lets nodes encrypt the traffic between them, making it harder for eavesdroppers to tell where a payment came from. Nodes used to talk in plain, readable data. Someone watching every connection could link a payment to the node that first sent it, tamper with messages, or spot and block Bitcoin traffic. Version 2 encrypts the connection when both nodes support it and makes the data look random. It also saves a little bandwidth. Status: In use. Page: https://utxohub.com/bips/324 ### BIP-325: Signet Defines signet, a kind of test network where blocks need a signature as well as mining, so testing is steadier. Testnet lets people try things without real money, but it is unreliable, with long gaps and sudden bursts of blocks. On a signet, blocks must be signed by keys chosen when the network is set up, so they arrive more predictably. This suits long-running tests between several organisations, such as exchanges. Status: Finished. Page: https://utxohub.com/bips/325 ### BIP-326: Anti-fee-sniping in taproot transactions Would have wallets vary a timing setting in Taproot payments so ordinary payments and contract closures look alike. Wallets add a setting that stops a payment being mined before the next block, to discourage miners from re-mining recent blocks to grab fees. This would have them pick one of two ways of doing it at random. Lightning and similar contracts sometimes close using the second way, so they would blend in with everyday payments. Status: Draft. Page: https://utxohub.com/bips/326 ### BIP-327: MuSig2 for BIP340-compatible Multi-Signatures Lets several people combine their keys into one and sign together, producing what looks like a single ordinary signature. With MuSig2, a group shares control of a Taproot output that looks on the blockchain like it belongs to one person. Spending needs every member to sign, but only one key and one signature are recorded, which saves space and improves privacy. Everyone in the group must take part. Status: In use. Page: https://utxohub.com/bips/327 ### BIP-328: Derivation Scheme for MuSig2 Aggregate Keys Defines how a group sharing a MuSig2 key can make a fresh shared address for every payment from one extended public key. Good practice is to use a new address for each payment. Rather than every member combining many keys each time, this turns the group's combined key into a single xpub from which new addresses can be worked out. Anyone holding it can see those addresses, so it needs the same care as any xpub. Status: Finished. Page: https://utxohub.com/bips/328 ### BIP-329: Wallet Labels Export Format Would set a standard file format for moving the labels people add in one wallet over to another. Wallets let people tag payments, addresses and coins with notes, such as where money came from. These labels help avoid privacy leaks when spending, but there was no common way to move them. This format, which also records coins marked as frozen, would let people switch wallets without losing them. Status: Draft. Page: https://utxohub.com/bips/329 ### BIP-330: Transaction announcements reconciliation Would let pairs of nodes compare which payments they've heard about, instead of announcing every one to each other. Today each node tells every connected peer about each new payment, which uses a lot of bandwidth. This step towards a scheme called Erlay lets two nodes regularly work out what the other is missing. Cheaper relay would let nodes keep more connections, making the network harder to split, and lower the cost of running a node. Status: Draft. Page: https://utxohub.com/bips/330 ### BIP-331: Ancestor Package Relay Would let nodes pass on a payment together with the unconfirmed payments it depends on, so they're judged as a group. A node judges each payment on its own fee. A low-fee payment can be turned away even when a later payment spending it pays enough for both. Sharing them as a package would make fee bumping, such as CPFP, more reliable, which matters for Lightning and similar protocols. Status: Draft. Page: https://utxohub.com/bips/331 ### BIP-332: Stale Tip Relay Would let nodes tell each other about recent valid blocks that lost the race to join the main chain. Miners sometimes find blocks that end up left behind, called stale blocks. How often this happens is a sign of how well blocks spread across the network. This optional message would share them, and having one already can make switching chains quicker if its branch later wins. Status: Draft. Page: https://utxohub.com/bips/332 ### BIP-337: Compressed Transactions Would define a compact encoding that can shrink a Bitcoin payment to less than half its normal size. Many parts of a typical payment hold padding or common values that can be written more briefly. This encoding packs them tightly, and can optionally point to a coin by its block and position instead of its long ID. One aim is to make payments easier to pass along in other ways, such as hidden inside images. Status: Draft. Page: https://utxohub.com/bips/337 ### BIP-338: Disable transaction relay message Proposed a message letting a node tell a peer that their connection will only ever carry blocks, never payments. Some nodes open extra connections just for blocks, which makes the network harder to split and harder to map. The node at the other end couldn't tell such a link would never carry payments. This message would have said so for the whole connection, helping nodes accept more incoming connections. Status: Closed. Page: https://utxohub.com/bips/338 ### BIP-339: WTXID-based transaction relay Lets nodes announce and request payments by an ID that covers the whole payment, including its signature data. Nodes used to name payments by an ID that leaves out the signature data SegWit keeps apart. Because that data can be altered without changing the ID, a node that rejected one version still had to fetch others with the same ID. Using an ID that covers everything removes this waste. Status: In use. Page: https://utxohub.com/bips/339 ### BIP-340: Schnorr Signatures for secp256k1 Defines Schnorr signatures for Bitcoin, a 64-byte signature type with stronger security proofs that lets several signers act as one. Bitcoin first used a signature type called ECDSA. Schnorr signatures use the same elliptic curve and keys, but rest on a proven security basis, can't be altered by outsiders, are a fixed size and can be checked in batches. They also let several people sign together as one, which helps efficiency and privacy. Status: In use. Page: https://utxohub.com/bips/340 ### BIP-341: Taproot: SegWit version 1 spending rules Adds Taproot, a new kind of output that can be spent with one signature or with other conditions that stay hidden unless used. Taproot coins are locked to a single key and, if wanted, to other spending conditions too. If everyone agrees, a spend looks like any ordinary one-signature payment and the extra conditions stay hidden. If not, only the condition actually used is revealed. This improves privacy and saves space. Status: In use. Page: https://utxohub.com/bips/341 ### BIP-342: Validation of Taproot Scripts Sets the rules for the scripts inside Taproot coins, the small programs that decide who can spend them. This updates Bitcoin's script language for Taproot. Signature checks use Schnorr signatures, a slow multi-signature instruction is replaced by a more efficient one, and some limits are simplified. It also reserves spare instructions so new features can be added cleanly later by soft fork. Status: In use. Page: https://utxohub.com/bips/342 ### BIP-343: Mandatory activation of taproot deployment Proposed a way to switch on Taproot that would, if needed, have forced miners to signal support before a deadline. Under this plan, Taproot would switch on once 90% of blocks in a period signalled support. If that hadn't happened near the end, blocks that failed to signal could be rejected, so miners couldn't hold back a widely backed change forever. It was built to fit alongside 'Speedy Trial', a separate method released in Bitcoin Core. Status: Closed. Page: https://utxohub.com/bips/343 ### BIP-345: OP_VAULT Proposed vaults: coins that must wait through a set delay before being spent, during which a backup key can pull them to safety. If someone steals your keys, there is usually little you can do. With a vault, any withdrawal must wait, say a day, and during that wait the coins can be sent to a recovery path guarded by a much safer key. It needed new Taproot script instructions added by soft fork. BIP 443 was later proposed to replace it. Status: Closed. Page: https://utxohub.com/bips/345 ### BIP-346: OP_TXHASH Would add a script instruction that lets coins check details of the payment spending them, enabling new kinds of spending rules. Today a Bitcoin script can't easily look at the payment trying to spend it. OP_TXHASH would let it pick out chosen parts of that payment, such as its outputs, and fingerprint them. Paired with a signature-checking instruction, this could support today's signing options and many new ones. It would be added to Taproot scripts by soft fork. Status: Draft. Page: https://utxohub.com/bips/346 ### BIP-347: OP_CAT in Tapscript Defines OP_CAT, a Taproot script instruction that joins two pieces of data into one, to be added by soft fork. Taproot scripts have no general way to combine pieces of data, which limits what they can do. OP_CAT would fill that gap, with a cap of 520 bytes on the result, making it possible to build and check structures such as Merkle trees inside scripts. It reuses the number of Bitcoin's original OP_CAT instruction. Status: Finished. Page: https://utxohub.com/bips/347 ### BIP-348: CHECKSIGFROMSTACK Would add a script instruction that checks a signature on any message, not just on the payment being made. Bitcoin scripts can check a signature, but only one that signs the spending payment itself. OP_CHECKSIGFROMSTACK would check a Schnorr signature over any piece of data the script supplies, with a given public key. It would be added to Taproot scripts by soft fork. Status: Draft. Page: https://utxohub.com/bips/348 ### BIP-349: OP_INTERNALKEY Would add a script instruction that fetches a Taproot coin's main key, saving space in some scripts. Every Taproot coin has a main key, the 'internal key', alongside any backup scripts. Scripts that need that key today must repeat it in full. OP_INTERNALKEY would supply it directly, saving 8 vbytes (a measure of payment size) in some cases, and keep scripts in step if the key changes. It would be added by soft fork. Status: Draft. Page: https://utxohub.com/bips/349 ### BIP-350: Bech32m format for v1+ witness addresses Defines Bech32m, a fixed version of the error check used in newer bc1 addresses, including Taproot ones. The original bc1 address format had a flaw: extra or missing letter 'q's just before a final 'p' could slip past its error check. Bech32m fixes this for newer segwit address versions, such as Taproot's, so wallets can catch that kind of typing mistake. The first segwit addresses keep the original format. Status: In use. Page: https://utxohub.com/bips/350 ### BIP-351: Private Payments Proposed reusable 'payment codes' that let a sender and receiver work out private addresses only the two of them can calculate. Reusing one address lets anyone link your payments together. Under this plan a receiver could publish one payment code; each sender would post a short notice on the blockchain once, then pay to fresh addresses only the pair could work out. It was closed after work on it stopped. Status: Closed. Page: https://utxohub.com/bips/351 ### BIP-352: Silent Payments Lets someone share one reusable address while each payment to it lands at a new, unlinkable address on the blockchain. Staying private normally means a fresh address for every payment, which means talking to the sender first. With silent payments, the sender's wallet works out a unique Taproot address from the receiver's public code, so outsiders can't tie payments together. The receiver's wallet has to scan the blockchain to find them. Status: Finished. Page: https://utxohub.com/bips/352 ### BIP-353: DNS Payment Instructions Lets people use an email-style name such as ₿alice@example.com that wallets look up to find where to send a payment. Long addresses are hard to read out or check. This BIP stores a bitcoin: payment link in the internet's domain name system, signed with DNSSEC so wallets can check it is genuine. Wallets should still prefer a plain address when one is available, and names that give out on-chain addresses should change them often to avoid reuse. Status: Finished. Page: https://utxohub.com/bips/353 ### BIP-360: Pay-to-Merkle-Root (P2MR) Would add a new output type, P2MR, that works like Taproot without its key-only way to spend, to resist some quantum attacks. A future quantum computer might work out a private key from a public key left on the blockchain for a long time. Taproot coins are exposed this way; P2MR coins, with addresses starting bc1z, remove that weak spot. It does not protect a payment waiting to confirm; that may need new quantum-safe signatures. Status: Draft. Page: https://utxohub.com/bips/360 ### BIP-361: Post Quantum Migration and Legacy Signature Sunset Would phase out today's signatures once quantum-safe addresses exist: first blocking payments to vulnerable addresses, then requiring a rescue proof. A quantum computer could steal coins whose public keys are already visible. Phase A, about three years after activation, would stop payments to quantum-vulnerable addresses. Phase B, two years later, would let old-style signatures spend only with an extra quantum-safe 'rescue' proof. Coins never moved by owners who can't give one would stay locked. Status: Draft. Page: https://utxohub.com/bips/361 ### BIP-370: PSBT Version 2 Updates the PSBT file format for unsigned payments so inputs and outputs can still be added after the file is first made. A PSBT is a file that carries an unfinished payment between wallets and signing devices until everyone has signed. The first version fixed the payment's inputs and outputs at the start. Version 2 lets more be added later, which helps when several people build one payment, and keeps each input's details in one place. Status: In use. Page: https://utxohub.com/bips/370 ### BIP-371: Taproot Fields for PSBT Adds the extra details signing devices need to sign Taproot payments using the shared PSBT file format. Taproot brought a new kind of signature and a new way of building scripts into an address, which the older PSBT format, the file that carries an unsigned payment, could not describe. These new fields carry Taproot signatures, keys and scripts, so wallets and hardware signers can pass Taproot payments between them for signing. Status: In use. Page: https://utxohub.com/bips/371 ### BIP-372: Pay-to-contract tweak fields for PSBT Would add fields to PSBT files so signers can spend coins whose keys were adjusted to commit to an extra message. Some protocols, such as timestamping services, 'tweak' a public key so that it commits to a piece of outside data. To spend those coins later, the signer must apply the same tweak to the private key. This BIP would let a PSBT, the file wallets pass around for signing, carry that information. Status: Draft. Page: https://utxohub.com/bips/372 ### BIP-373: MuSig2 PSBT Fields Adds fields to PSBT files so several people can jointly produce one MuSig2 signature for a shared key. MuSig2 lets a group combine their keys into one standard key and sign together. It needs extra rounds of messages that the PSBT format, the file passed around for signing, could not hold. These fields carry each person's key, their one-time values and their partial signatures. Status: Finished. Page: https://utxohub.com/bips/373 ### BIP-374: Discrete Log Equality Proofs Would standardise a short proof that a shared secret was worked out with a particular private key, without revealing that key. In silent payments, the sender's device works out the receiver's address from a secret built with its own keys. A wrong result can still look valid, so coins could be lost. This proof lets the device show other software that it did the sum correctly, without giving away the private key. Status: Draft. Page: https://utxohub.com/bips/374 ### BIP-375: Sending Silent Payments with PSBTs Would let wallets and signing devices build payments to silent payment addresses using PSBT files. A silent payment address can't be turned into the final address until all of the payment's inputs are known, which the PSBT format did not allow for. This BIP adds fields and duties so the signer can work out the address and others can check it, so coins aren't sent to the wrong place. Status: Draft. Page: https://utxohub.com/bips/375 ### BIP-376: Spending Silent Payment outputs with PSBTs Would add a PSBT field holding the extra key detail a signer needs to spend coins received through silent payments. Coins received by silent payments sit at Taproot addresses whose keys are adjusted in a way normal Taproot signing does not expect. BIP 375 covers sending; this BIP covers spending, by letting a PSBT, the file passed around for signing, carry the adjustment the signing device needs. Status: Draft. Page: https://utxohub.com/bips/376 ### BIP-379: Miniscript Would define Miniscript, a structured way to write Bitcoin's spending rules so software can check, combine and sign for them. Bitcoin script, the small language that decides who can spend coins, is awkward and full of edge cases. Miniscript covers a useful part of it in a tidy form, so wallets can see what a script allows, combine conditions such as multisig and time locks, estimate what spending will cost, and produce the signatures it needs. Status: Draft. Page: https://utxohub.com/bips/379 ### BIP-380: Output Script Descriptors General Operation Defines output script descriptors, a short text format that says exactly which addresses a wallet uses. A backup of keys alone, such as recovery words, doesn't say which address types or key paths a wallet used, so other software restoring it may not find the same addresses. A descriptor writes this down in one line with a checksum, helping backups and watch-only wallets work the same across different software. Status: In use. Page: https://utxohub.com/bips/380 ### BIP-381: Non-Segwit Output Script Descriptors Defines how descriptors write the three original standard types: pay to public key, pay to public key hash, and pay to script hash. Before segwit there were three main standard formats: paying straight to a public key, to a hash of a public key, or to a hash of a script. This BIP lets a descriptor, the text that records which addresses a wallet uses, name each of them. Status: In use. Page: https://utxohub.com/bips/381 ### BIP-382: Segwit Output Script Descriptors Defines how descriptors write the two segwit address types, one for a single key and one for a script. Segwit added two standard formats: one paying to the hash of a single public key, and one paying to the hash of a script. This BIP gives descriptors, the text that records which addresses a wallet uses, a way to name them, including when they are wrapped inside an older pay-to-script-hash address. Status: In use. Page: https://utxohub.com/bips/382 ### BIP-383: Multisig Output Script Descriptors Defines how descriptors describe multisig, where a set number of several keys, such as 2 of 3, must sign to spend. Threshold multisig is the most common complex script in Bitcoin. multi() keeps the keys in the order they are written, while sortedmulti() sorts them first, so the order they were listed in doesn't matter. Status: In use. Page: https://utxohub.com/bips/383 ### BIP-384: combo() Output Script Descriptors Defines combo(), a descriptor that takes one key and covers the standard address types older wallets made from it. Older wallets kept a list of keys and watched several address types for each. To ease the move to descriptor-based wallets, combo() takes one key and produces pay to public key and pay to public key hash scripts, plus two segwit forms when the key is in compressed form. Status: In use. Page: https://utxohub.com/bips/384 ### BIP-385: raw() and addr() Output Script Descriptors Defines raw() and addr(), which let a descriptor wrap any script or any address exactly as it is. Not every coin uses a pattern that descriptors have a name for. These two catch-alls let a wallet describe any output script, written as hex, or any address, so descriptor-based software stays compatible with the scripts already in use. Status: In use. Page: https://utxohub.com/bips/385 ### BIP-386: tr() Output Script Descriptors Defines tr(), the descriptor for Taproot outputs, covering the main key and an optional tree of other scripts. Taproot added a new standard output format. A Taproot output can be spent with one key, or by meeting one of several scripts arranged in a tree. tr() lets a descriptor, the text that records which addresses a wallet uses, state both parts. Status: In use. Page: https://utxohub.com/bips/386 ### BIP-387: Tapscript Multisig Output Script Descriptors Defines multi_a() and sortedmulti_a(), descriptors for multisig spending rules inside Taproot scripts. Like the older multi() and sortedmulti(), these take a threshold and a list of keys, so that a set number of them must sign. The difference is that they produce the kind of script used inside Taproot, work only inside tr(), and allow up to 999 keys. Status: In use. Page: https://utxohub.com/bips/387 ### BIP-388: Wallet Policies for Descriptor Wallets Defines wallet policies, a compact form of descriptors that hardware signing devices can store and show to users to check. Hardware signing devices have little memory and small screens, yet users should be able to check which account a payment uses. Wallet policies trim descriptors to the essentials and list the extended public keys separately, so a whole account, with its receive and change addresses, can be registered and reviewed on the device. Status: Finished. Page: https://utxohub.com/bips/388 ### BIP-389: Multipath Descriptor Key Expressions Would let one descriptor cover both a wallet's receiving addresses and its change addresses. Wallets usually need two almost identical descriptors, one for receiving addresses and one for change, that differ in a single step of the key path. This BIP lets that step list more than one value, commonly <0;1>, so a single descriptor stands for both. Status: Draft. Page: https://utxohub.com/bips/389 ### BIP-390: musig() Descriptor Key Expression Would let descriptors include a MuSig2 combined key, so wallets can more easily use keys shared by several people. MuSig2 lets several people merge their public keys into one key and sign together. musig() lets a descriptor list each participant's key and builds the combined key from them, for use in Taproot and silent payment descriptors. Status: Draft. Page: https://utxohub.com/bips/390 ### BIP-391: Binary Output Descriptors Proposed a compact binary file format for passing descriptors, with names and other details, between wallets. A descriptor written as text has no header software can recognise, no room for details such as a wallet name or start block, and stores keys inefficiently. This BIP reused the PSBT file layout to fix that. It was withdrawn after BIP 393 proposed another way to carry wallet details. Status: Closed. Page: https://utxohub.com/bips/391 ### BIP-392: Silent Payment Output Script Descriptors Would add sp(), a descriptor for silent payment wallets, so they can be backed up and restored like other wallets. Silent payments give each payment its own Taproot address, worked out from the receiver's keys and the sender's inputs. sp() records the receiver's silent payment keys in a standard form, so different wallets can understand them and recover funds using existing descriptor tools. Status: Draft. Page: https://utxohub.com/bips/392 ### BIP-393: Output Script Descriptor Annotations Would let descriptors carry extra notes, such as where to start scanning the blockchain, to help restore a wallet. Restoring a wallet from a descriptor can be slow, or miss coins, if the software doesn't know which block to start from or how many unused addresses in a row to check. Annotations add these settings to the end of a descriptor, like a web link's query string, without changing the addresses it produces. Status: Draft. Page: https://utxohub.com/bips/393 ### BIP-394: rawtr() Output Script Descriptors Status: Draft. Page: https://utxohub.com/bips/394 ### BIP-431: Topology Restrictions for Pinning Would set out opt-in, stricter relay rules for unconfirmed payments, making it harder for others to block a fee bump. Someone can sometimes 'pin' a payment, using relay limits to stop it being fee-bumped, which matters for protocols with deadlines such as Lightning. Payments marked version 3 would be kept small, with at most one unconfirmed parent or child. The BIP links the code that adds these rules to Bitcoin Core. Status: Draft. Page: https://utxohub.com/bips/431 ### BIP-433: Pay to Anchor (P2A) Would define Pay to Anchor, a tiny output anyone can spend, used as a hook for adding fees to a payment later. Systems such as Lightning sign payments before the right fee is known. An anchor output lets someone later attach a child payment that adds fees. It needs no key or signature, which keeps it small, and should be paired with BIP 431. The BIP says Bitcoin Core already relays payments that spend these outputs. Status: Draft. Page: https://utxohub.com/bips/433 ### BIP-434: Peer Feature Negotiation Defines a 'feature' message that nodes send when first connecting, to tell each other which new optional features they support. Adding a new feature to how nodes talk used to mean raising a shared protocol version number, which needs different software projects to coordinate. With this message, a node can announce any new feature, and peers that don't recognise it simply ignore it rather than disconnecting. It mainly matters to node software developers. Status: Finished. Page: https://utxohub.com/bips/434 ### BIP-440: Varops Budget For Script Runtime Constraint Would give script operations a cost budget based on how much data they handle, to keep scripts quick to check. Early on, many features of script, the small program that decides who can spend coins, were switched off or tightly limited to stop scripts that take nodes too long to check. This BIP sets a cost for each operation based on the data it touches, as a framework other proposals can use to allow more safely. Status: Draft. Page: https://utxohub.com/bips/440 ### BIP-441: Restoration of disabled script (Tapleaf 0xC2) Would add a new Taproot script version that brings back script commands switched off in Bitcoin's early days, with larger limits. Many script commands were disabled early on because they could make nodes do too much work. This BIP would re-enable them in a new kind of Taproot script, raise size limits and allow much bigger numbers, relying on the cost budget in BIP 440 to stop scripts that are too slow to check. Status: Draft. Page: https://utxohub.com/bips/441 ### BIP-442: OP_PAIRCOMMIT Would add a script command that combines two pieces of data into one fingerprint, so scripts can commit to several items at once. Scripts, the small programs that decide who can spend coins, can easily lock coins to a single piece of data, but not to several together. OP_PAIRCOMMIT hashes two items into one and can be repeated to build trees of items. It is aimed at contracts such as delegation and Lightning Symmetry channels. Status: Draft. Page: https://utxohub.com/bips/442 ### BIP-443: OP_CHECKCONTRACTVERIFY Would add a script command that lets coins carry a piece of data and set rules for the outputs they are spent to. Today, limiting where coins can go next mostly relies on signing payments in advance. OP_CHECKCONTRACTVERIFY would let a coin hold committed data and check, when it is spent, that the new outputs follow set rules. It is meant as a building block for ideas such as vaults and shared coins like Ark. Status: Draft. Page: https://utxohub.com/bips/443 ### BIP-446: OP_TEMPLATEHASH Would add a script command that commits coins to the exact payment that must later spend them. Systems built on top of Bitcoin, such as Lightning, often have everyone sign payments in advance just to fix how coins will move. OP_TEMPLATEHASH would let a Taproot script name that spending payment directly, cutting back-and-forth between parties and making such protocols simpler, safer and sometimes more efficient. Status: Draft. Page: https://utxohub.com/bips/446 ### BIP-448: Taproot-native (Re)bindable Transactions Would switch on three script commands together, OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK and OP_INTERNALKEY, to improve layer-two systems. These small additions to Taproot scripts would let coins commit to the payment that spends them, check signatures on any message, and reuse the Taproot key cheaply. Together they make 'rebindable' signatures possible, enabling a simpler kind of payment channel called LN-Symmetry (Eltoo). How it would be activated is left for later. Status: Draft. Page: https://utxohub.com/bips/448 ### BIP-449: OP_TWEAKADD - x-only key tweak addition Would add a script command that adjusts a public key by a given number, the same way Taproot adjusts keys. Taproot already 'tweaks' keys, but a script can't do this itself. OP_TWEAKADD would let a script work out a tweaked public key and keep using it, without revealing private keys or relying on hash locks. It is aimed at contracts such as delegation and proving the order in which people signed. Status: Draft. Page: https://utxohub.com/bips/449 ### BIP-450: Formosa—Seed encoding by themed mnemonic stories Would turn a wallet backup into short themed sentences instead of unrelated words, to make recovery words easier to remember. Lists of unrelated recovery words are hard to memorise. Formosa builds the backup from short sentences using themed word lists, keeping the same security. It would work with existing BIP 39 backups: a Formosa phrase converts back to standard words, so the same keys and addresses result. Status: Draft. Page: https://utxohub.com/bips/450 ### BIP-451: Dust UTXO Disposal Protocol Would set a standard way for wallets to get rid of tiny unwanted coins by giving their whole value to miners as a fee. Attackers send tiny amounts, called dust, hoping you'll later spend them with your other coins and link your addresses. Instead of locking dust forever, a wallet would spend it in a payment with no change and a single 'ash' data output. A shared format lets disposals be batched and hides which wallet you use. Status: Draft. Page: https://utxohub.com/bips/451 ### BIP-458: Half-Aggregation of BIP 340 Signatures Status: Draft. Page: https://utxohub.com/bips/458 ### BIP-459: DahLIAS fully aggregated signatures for secp256k1 Status: Draft. Page: https://utxohub.com/bips/459 ### BIP-460: CISA for Taproot Key Path Spends in SegWit v2 Status: Draft. Page: https://utxohub.com/bips/460 ### BIP-461: Deterministic ECDSA Signatures Would standardise a single way to make ECDSA signatures, so a given key and message always give the same signature. A signing device has some free choice when it makes a signature, and bad firmware could use that to leak your secret key. If every device follows this one method, you can load the same key into two devices, sign the same message on both, and compare: any difference shows one of them is misbehaving. Status: Draft. Page: https://utxohub.com/bips/461