Developer reference
This is the reference layer: the P2P message types, script opcodes, RPC field names and protocol structures you meet reading bitcoin code or decoding a raw transaction, rather than while buying anything.
It exists because the Bitcoin Core developer glossary, which is where most of these terms are still looked up, has barely changed since 2021, and several of its entries no longer describe the software. The BIP70 payment protocol it documents was deleted from Bitcoin Core in version 0.20.0. Its bloom filter entries describe a mechanism Core stopped serving by default in 0.19.0. Every one of those is rebuilt here against what the code does now, with the correction stated rather than quietly applied.
The terms fall into groups. Message types like inv, getdata and MSG_FILTERED_WITNESS_BLOCK belong to the peer to peer protocol. Opcodes like OP_RETURN and OP_CHECKSIG belong to Script. Signature hash flags, sequence numbers and locktime govern what a signature actually commits to. The X509 and payment request entries are historical, and they say so.
Most readers will never need this section, and that is fine. It is here so a search for an exact field name lands on a page that explains it accurately instead of on a one line stub.
47 terms. Last reviewed 2026-09-24.
Terms in Developer reference
- Bitcoin Scriptalso ScriptBitcoin Script is the small stack-based language that every bitcoin output carries, setting the conditions someone must satisfy before those coins can be spent again.
- Bitcoin URIalso BIP21A Bitcoin URI packs the details of a payment into one clickable string that begins with bitcoin: and can carry an address, an amount, and a label.
- Certificate chainA certificate chain is the ordered list of certificates that connects the one a server presents back to a root your device already trusts, each link signed by the next.
- CompactSizealso Compact size unsigned integer, VarIntCompactSize is the variable length integer bitcoin uses to prefix counts and lengths in serialized data, costing one byte for values below 253 and up to nine for the rest.
- Descriptor checksumA descriptor checksum is the eight character code after the hash mark in an output descriptor, a BCH code that catches typing and copy errors before a wallet imports the wrong keys.
- Intermediate certificateAn intermediate certificate sits between a root and a leaf, signed by the root and signing the leaf, so the root's private key can stay offline and unused.
- Internal byte orderInternal byte order is the layout bitcoin uses inside serialized structures: integers written least significant byte first, and hash digests written in the order SHA-256 produced them.
- LabelThe label in a Bitcoin URI names the person or business being paid, and in a wallet it is the private note you attach to an address or a transaction.
- Leaf certificateThe leaf certificate is the end-entity certificate presented by the server you actually connected to, and it proves control of a domain name, nothing about the people behind it.
- MSG_BLOCKMSG_BLOCK is inventory type 2, the code a node puts in a getdata message to ask a peer for one complete block by its hash.
- MSG_CMPCT_BLOCKMSG_CMPCT_BLOCK, inventory type 4, is a request-only code: it never appears in an announcement and is legal only inside a getdata message sent to a peer that agreed to it first.
- MSG_FILTERED_WITNESS_BLOCKThe filtered witness block type sits in BIP144's reserved list and in Bitcoin Core's source enum, with no implementation behind it in either place.
- MSG_TXMSG_TX marks an inventory entry as a transaction, type code 1, and it is how your unconfirmed payment gets announced to peers before any of them have seen its contents.
- MSG_WITNESS_BLOCKThe witness block inventory type is how a segwit-aware node asks for a block in the extended serialization, with every signature attached instead of stripped away.
- MSG_WITNESS_TXA witness transaction request, sent as getdata, tells a peer to return the named transaction with its signature data still attached rather than stripped out.
- OP_CHECKMULTISIGOP_CHECKMULTISIG verifies a group of signatures against a list of public keys in one step, and Taproot spends cannot use it at all because it blocks batch verification.
- OP_CHECKSIGOP_CHECKSIG takes a public key and a signature off the stack and verifies that the signature commits to this transaction, which is the check that actually proves you own the coins.
- OP_DUPOP_DUP copies the top item on the stack so it can be used twice, which is why the standard pay-to-public-key-hash script can both hash your public key and verify against it.
- OP_EQUALOP_EQUAL compares the top two stack items byte for byte and pushes a true or false result, and it is the last opcode in every pay-to-script-hash output.
- OP_EQUALVERIFYOP_EQUALVERIFY compares the top two stack items and kills the script instantly if they differ, which is how a legacy spend proves it presented the right public key.
- OP_HASH160OP_HASH160 runs SHA-256 over the top stack item and then RIPEMD-160 over that result, leaving a 20 byte digest, the same fingerprint carried inside every address beginning with 1 or 3.
- OP_RETURNOP_RETURN is the opcode that makes a transaction output provably unspendable, which lets a small amount of arbitrary data be written to the blockchain without bloating the set of live coins.
- OP_VERIFYOP_VERIFY pops the top stack item and aborts the entire script unless that item is true, turning any test in Bitcoin Script into a hard requirement.
- Opcodealso Data-pushing opcode, Non-data-pushing opcodeAn opcode is a single byte of Bitcoin Script that tells a validating node what to do next, either pushing data onto the stack or performing one operation on what is already there.
- Payment protocol (BIP70)also Payment protocol, BIP70The payment protocol (BIP70) was bitcoin's attempt to replace bare addresses with signed, certificate-backed payment requests, and Bitcoin Core removed the last of its support in version 0.20.0.
- PaymentDetailsPaymentDetails is the inner BIP70 message that actually described a payment: which outputs to pay, how much, when the request expires, and where to send the signed transaction.
- PaymentRequestPaymentRequest is the outer BIP70 envelope: it wraps a serialized PaymentDetails blob together with a certificate chain and a signature, so the payer could check who was asking.
- PKIalso Public key infrastructurePKI, or public key infrastructure, is the system of certificate authorities, certificates and trust stores that lets software decide whether a public key really belongs to the name attached to it.
- Point functionThe point function turns a private key into a public key by multiplying the secp256k1 generator point by that number, and it is the one-way step every bitcoin address is built on.
- PP amountPP amount was the satoshi-denominated field inside a BIP70 output, set to zero when the merchant wanted the payer to choose how much to send.
- PP expiresPP expires was the optional Unix timestamp in a BIP70 PaymentDetails message that told a wallet to stop honoring the request once that moment had passed.
- PP memoPP memo was the free-text UTF-8 note that BIP70 let a merchant, a payer, or an acknowledging server attach to a payment for a human to read.
- PP merchant dataPP merchant data was an opaque byte string a BIP70 merchant put in a payment request and got back untouched, so the incoming coins could be matched to an order.
- PP pki dataPP pki data was the field in a BIP70 payment request that carried the merchant's certificates, DER encoded, leaf first, with any intermediates behind it and the root left out.
- PP pki typePP pki type was the one-word string in a BIP70 payment request that said how the merchant had signed it: none, x509 with SHA-256, or x509 with SHA-1.
- PP scriptPP script was the required field in a BIP70 output holding the raw locking script the payer had to reproduce, the same bytes that end up in a transaction output.
- Pubkey scriptalso scriptPubKey, Locking scriptThe pubkey script is the short piece of Bitcoin Script attached to every transaction output, stating the conditions that must be met before the coins in that output can move again.
- R parameterThe R parameter is the BIP72 addition to a bitcoin URI that replaces the payment address with a URL your wallet is expected to fetch a signed request from.
- ReceiptA receipt in bitcoin is whatever evidence you keep that a payment happened: in BIP70 it was a signed acknowledgment from the merchant, and in practice it is the transaction ID.
- Redeem scriptalso redeemScriptA redeem script is the full spending contract hidden behind a pay-to-script-hash output, supplied by the spender at the end of the signature script and hashed to check it matches.
- Root certificateA root certificate is the self-signed trust anchor at the top of a certificate chain, and it is trusted only because your operating system or browser vendor put it there.
- RPC byte orderRPC byte order is the reversed way bitcoin software displays 32 byte hashes, and it is the form of every transaction ID you copy from a wallet or a block explorer.
- Signature scriptalso scriptSig, Unlocking scriptA signature script is the unlocking data an input carries to satisfy the pubkey script of the output it spends, and on modern SegWit inputs it is empty.
- SSL signatureSSL signature is the name BIP70 gave to the bytes signing a PaymentRequest with a web server's certificate key, and the label was already a misnomer when it was written.
- URI QR codeA URI QR code is the square black and white pattern that encodes a bitcoin: URI, so a camera can read the address and amount that would otherwise be typed.
- Witness scriptThe witness script holds the real spending conditions of a P2WSH output and travels in the witness, where its bytes are weighted at a quarter of the usual cost.
- X.509 certificatealso X509 certificatesAn X.509 certificate is a signed file that binds a public key to a name and a validity period, and it is the format behind every HTTPS connection you make to an exchange.
The other 13 sections
- BasicsWhat bitcoin is, what a satoshi is, and the handful of ideas the rest of the glossary is built on.
- Addresses & keysWhere coins get sent, what a private key actually controls, and how one seed produces thousands of addresses.
- Wallets & custodyHot, cold, custodial and multisig, and what each one changes about who can move your coins.
- Privacy & securityThe attacks that take people's bitcoin, and the habits and tools that stop them.
- Transactions & feesWhat a bitcoin transaction is made of, why it costs what it costs, and how to unstick one.
- Buying & exchangesOrder types, spreads and fee schedules: the vocabulary an exchange uses while it is charging you.
- Markets & investingMarket cap, volatility and spot ETFs. The language of price, without the price predictions.
- Mining & consensusHow new blocks get made, what difficulty adjusts, and why the rules hold with nobody in charge.
- Protocol & upgradesSegWit, Taproot, soft forks and BIPs: how bitcoin changes and who gets to decide.
- Lightning & layer 2Payment channels, invoices and routing, for moving bitcoin without paying for space in a block.
- Regulation & taxKYC, the Travel Rule, MiCA and capital gains: the rules that reach your account and your tax return.
- Culture & historyMt. Gox, the genesis block, HODL, and the events and slang that shaped how people talk about bitcoin.
- Nodes & softwareBitcoin Core, full nodes, pruning and RPC: the software that enforces the rules.
Frequently asked questions
Who is this section for?
Anyone reading bitcoin's source, decoding a raw transaction, or working against the P2P protocol and the RPC interface. It is the reference layer rather than the buying layer, and none of it is needed to own or spend bitcoin.
What is Bitcoin Script?
The small stack-based language that decides whether a coin may be spent. It has no loops, on purpose, which makes the cost of every script predictable before it runs. Most transactions use one of a handful of standard patterns.
Why do byte orders keep changing?
Because bitcoin displays hashes in the opposite order to the one it stores them in. Internal byte order is what the protocol uses, while RPC output and block explorers reverse it. Mixing the two is the classic first bug.
Where does the authoritative documentation live?
In the source and in the BIPs rather than on any one site. Entries here cite the specification where one exists, and correct the older developer documentation where it has fallen out of date rather than repeating it.