At 09:30 UTC on 9 November 2026, block 975,157 confirmed a transaction of 223 bytes whose ID starts with 47b6082f. It spends one earlier output worth 9,109,701 satoshis and creates two new ones, of 288,100 and 8,820,000 satoshis; the 1,601 satoshis that are missing went to the miner as a fee. Nowhere in those bytes is there a sender’s balance or a recipient’s name. There are two small locks and one key that opened an older lock. Those locks are written in Bitcoin Script, the little programming language every full node runs to decide whether a coin may move.
Seventeen years earlier, on 12 January 2009, block 170 carried a transaction with the same skeleton: one input, two outputs, a version number and a lock time. It sent 10 BTC to a new lock and 40 BTC back to its creator. Hal Finney wrote on the Bitcointalk forum on 19 March 2013 that he had been the recipient of the first bitcoin transaction, ten coins sent by Satoshi Nakamoto as a test, and the 10 BTC payment in block 170 is the one usually identified as that test. The format has gained fields since then, and the opcode that judged that payment, OP_CHECKSIG, is still part of the rules every node enforces.
Every address prefix a wallet shows, 1, 3, bc1q or bc1p, names one of a handful of standard locks. Multisig, time locks and the relay rules of nodes are all, in the end, rules about how those locks are written and run, and they can be read directly in the bytes.
A Bitcoin transaction moves locks, not balances
Bitcoin keeps no accounts. It keeps a set of unspent outputs, each one an amount with a lock attached, and a transaction destroys some of them and creates new ones. An output is always spent whole, so a payment usually produces change back to the sender, and a wallet’s balance is only the sum of the outputs its keys can open. Coin selection, dust, consolidation and the privacy clues that outputs leave are covered in our lesson on the UTXO and account models; here they are taken as known.
The same goes for fees. A transaction pays by size, counted in weight units and virtual bytes, at a rate in satoshis per virtual byte that the sender picks and miners rank. How that auction works, how replace-by-fee and child-pays-for-parent rescue a stuck payment and why six confirmations became a habit are explained in our guide to the mempool and transaction fees. Where those bytes come from, and what each of them does, is another matter.
One idea from the white paper frames the rest. Satoshi Nakamoto wrote in section 2: “We define an electronic coin as a chain of digital signatures.” Each output says which signature it wants; each input supplies it. If public keys and signatures are new to you, read how private and public keys work first, because every lock below ends with a signature check.
The bytes of a Bitcoin transaction, field by field
A transaction is a short string of bytes with a fixed order. The Bitcoin developer reference documents it field by field. Counts and lengths use a variable-size integer called compactSize: one byte for values up to 252, then a marker byte (0xfd, 0xfe or 0xff) followed by 2, 4 or 8 bytes. Numbers are stored little-endian, the least significant byte first, which is why hex dumps look scrambled to a human eye.
Seven fields, two of them only in SegWit transactions
| Field | Size | What it holds |
|---|---|---|
| version | 4 bytes | 1 or 2 in most transactions; 2 switches on relative time locks (BIP 68). Bitcoin Core relays versions 1 to 3 |
| marker and flag | 2 bytes (0x00 0x01) | Present only when the transaction carries witness data (SegWit) |
| input count | compactSize | Number of inputs |
| inputs | 36 bytes + script + 4 bytes each | Outpoint (previous txid and output index), scriptSig, sequence |
| output count | compactSize | Number of outputs |
| outputs | 8 bytes + script each | Value in satoshis and scriptPubKey (the lock) |
| witness | variable | One stack of items per input, SegWit only |
| lock time | 4 bytes | Earliest block height or time at which the transaction is valid |
An input points at an earlier output and brings the proof
An input does not say how much it spends. It names an earlier output by its outpoint: the 32-byte ID of the transaction that created it plus a 4-byte index of the output within that transaction. The node looks the outpoint up in its UTXO set, finds the amount and the lock, and checks the proof. That lookup is why a transaction cannot be validated by someone who does not know the coins it spends.
The txid inside an outpoint is stored in internal byte order, the reverse of what block explorers display. The input of our 9 November transaction spends an output of transaction 403f3c54…f864, yet the raw hex starts that field with 64f81cf0. Both are the same 32 bytes read in opposite directions.
After the outpoint comes the scriptSig, the data that satisfies the old lock, with its length in front. For old address types it holds a signature and a public key; for SegWit spends it is empty and the proof moves to the witness. The input ends with a 4-byte sequence number. Today it does three jobs: a value below 0xffffffff lets the lock time apply, 0xfffffffd is the value wallets use to signal that they accept fee bumping (BIP 125), and in version 2 transactions it can carry a relative time lock (BIP 68).
An output is an amount and a lock
An output has two parts only: a value in satoshis on 8 bytes and a scriptPubKey, the locking script. The value may be zero, which is how data outputs work. The scriptPubKey decides everything about ownership: whoever can produce data that makes it succeed can spend the amount, and nothing else in the protocol records who owns it.
One input per block is different. The coinbase transaction that pays the miner has a single input with a null outpoint, 32 zero bytes and index 0xffffffff, and a free-form script of up to 100 bytes that must start with the block height since BIP 34. Its outputs claim the subsidy plus fees, the amount that halves every 210,000 blocks as explained in our lesson on the bitcoin halving and the block subsidy.
Transaction 47b6082f, read byte by byte
Here is the full hex of the transaction from block 975,157 on mempool.space, cut at the field boundaries. It weighs 565 weight units and spends a native SegWit output, so the marker, flag and witness fields are present.
02000000 version 2
00 01 SegWit marker and flag
01 1 input
64f81cf0...543c3f40 previous txid (403f3c54...f864 reversed)
00000000 output index 0
00 scriptSig length 0 (empty)
fdffffff sequence 0xfffffffd
02 2 outputs
6465040000000000 288,100 sat (0x046564)
16 0014 08696e26...a99d96 22-byte script: OP_0, push 20 bytes (P2WPKH)
2095860000000000 8,820,000 sat (0x869520)
17 a914 33972a6d...8e5177 87 23-byte script: OP_HASH160, push 20, OP_EQUAL (P2SH)
02 witness: 2 items for input 0
47 3044...01 71 bytes: DER signature + sighash byte 0x01
21 02e1b9f5...213edd 33 bytes: compressed public key
33e10e00 lock time 975,155 (0x0ee133)Read in order, the bytes tell a small story. Version 2. One input, taking output 0 of an earlier transaction, which according to the explorer held 9,109,701 satoshis in a P2WPKH lock. An empty scriptSig, because the proof sits in the witness. A sequence of 0xfffffffd, which signals that the sender accepts fee bumping. Two outputs: 288,100 satoshis to a bc1q address and 8,820,000 satoshis to an address starting with 3. Then the witness: a signature that ends with 0x01, the SIGHASH_ALL flag, and the public key whose hash matches the old lock. Last, a lock time of 975,155.
Which output is the payment and which is the change? The bytes do not say. An explorer or a chain analyst can only guess, and the guess can be wrong. The sums only confirm the fee: 9,109,701 minus 288,100 minus 8,820,000 leaves 1,601 satoshis, which no output claims and the miner collects.
Where the txid, the weight and the fee rate come from
The txid is the double SHA-256 hash of the transaction serialized without the marker, flag and witness, displayed in reverse byte order. Strip those fields from the hex above and 114 bytes remain; their double SHA-256, reversed, is 47b6082f…d26a. Leaving the witness out of the ID is what lets a signature change without changing the txid, a property SegWit introduced.
Weight counts non-witness bytes four times and witness bytes once: 114 x 3 + 223 = 565 weight units, or 141.25 virtual bytes, which explorers round up to 142 vB. The fee of 1,601 satoshis divided by 141.25 gives about 11.3 satoshis per virtual byte. That was the rate this transaction paid when it was mined; it says nothing about the rate to pay today, which mempool.space quoted at 1 to 2 sat/vB at the same hour.
Bitcoin Script: a stack language with no loops
Bitcoin Script is read left to right. Data items are pushed onto a stack; opcodes pop items, work on them and push results. There are conditionals (OP_IF, OP_ELSE) but no loops and no jumps backwards, so every script finishes in a number of steps known in advance. That is a deliberate limit: a node must be able to check thousands of scripts per block without risking a program that runs forever.
Bitcoin Core’s source sets hard ceilings on top. A single pushed element may hold at most 520 bytes, a script at most 10,000 bytes, a script may execute at most 201 non-push opcodes, the stack may hold at most 1,000 items, and OP_CHECKMULTISIG accepts at most 20 public keys. Arithmetic opcodes work on numbers of at most 4 bytes. Those values are in the file script.h and in the interpreter, and they are consensus rules: a block containing a script that breaks them is invalid.
Spending a P2PKH output, one opcode at a time
The most famous P2PKH spend may be the one in block 57,043. On 18 May 2010 a forum user named laszlo offered 10,000 bitcoins for a couple of large pizzas on Bitcointalk, and on 22 May he reported that the trade was done. The transaction confirmed that day at 18:16 UTC has 131 inputs, all of the P2PKH type, and a single output of 10,000 BTC. Its first input spends an output of 150 BTC whose lock is this:
OP_DUP OP_HASH160 <05bf3a3aea6335a3949c0a351ff3afcba884e125> OP_EQUALVERIFY OP_CHECKSIGThe input’s scriptSig is 140 bytes: a 73-byte signature and a 65-byte uncompressed public key, two pushes and nothing else. The node runs the scriptSig first, which leaves those two items on the stack, then runs the scriptPubKey on that stack. The table shows the stack after each step, top of the stack on the right.
| Step | Item executed | Stack afterwards |
|---|---|---|
| 0 | scriptSig pushes its two items | sig, pubKey |
| 1 | OP_DUP copies the top item | sig, pubKey, pubKey |
| 2 | OP_HASH160 hashes it: RIPEMD-160 of SHA-256 | sig, pubKey, hash(pubKey) |
| 3 | push the 20 bytes 05bf3a3a…e125 from the lock | sig, pubKey, hash(pubKey), 05bf3a3a…e125 |
| 4 | OP_EQUALVERIFY compares the two hashes and fails the script if they differ | sig, pubKey |
| 5 | OP_CHECKSIG checks sig against pubKey and the transaction | true |
Step 4 is where a wrong key stops: a different public key gives a different hash, and the script ends in failure before any signature is checked. Step 5 is where a wrong signature stops. Only a party holding the private key behind that public key can sign this particular transaction, so only that party can produce data that leaves true on the stack.
The pizza transaction also shows what this early script format cost in space. 111 of its 131 inputs were outputs of 0.01 BTC each, and every one carried its own scriptSig of 138 to 140 bytes, mostly a 65-byte uncompressed public key and a signature. With the outpoint and sequence, each input took about 180 bytes, and the whole transaction 23,620 bytes for a single output. A native SegWit input with a compressed key takes about 68 virtual bytes today.
Why the lock holds a hash of the key, not the key
The very first outputs, like the ones in block 170, put the whole public key in the lock, followed by OP_CHECKSIG. That type, pay-to-public-key, takes 65 bytes of public key in every output, and anyone can see the key before it is ever used. Pay-to-public-key-hash replaced it with a 20-byte hash. The output is shorter, and the public key appears on chain only when the coin is spent.
The 20-byte hash is also what an address encodes. A legacy address is that hash plus a version byte and a checksum, written in Base58 so that a typo is caught before money leaves. Our lesson on what a crypto address is shows the encoding; the point here is that an address is a compact description of a scriptPubKey, not an account.
The two scripts run one after the other, not glued together
In Bitcoin’s first release the node joined the scriptSig and the scriptPubKey into one script and ran it. That allowed a scriptSig to contain opcodes that interfered with the lock, and a later fix split the run in two. Bitcoin Core’s interpreter still carries the comment that the two scripts must be evaluated sequentially on the same stack rather than concatenated, citing CVE-2010-5141.
Success has a precise meaning. After both scripts have run, the stack must not be empty and its top item must count as true. In Script, a byte string is false when it is empty, made only of zero bytes, or zero with the sign bit set (negative zero); anything else is true. If any opcode fails along the way, for example a VERIFY opcode meeting false, the whole spend is invalid.
Fifteen opcodes switched off in August 2010
The script language Satoshi first shipped was larger. A commit made under the name s_nakamoto on 15 August 2010, with the message “misc changes”, added a check that makes any script containing OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT or OP_RSHIFT fail. The same commit lowered the maximum pushed element from 5,000 to 520 bytes and cut numeric operands from 258 to 4 bytes. The commit message gives no reason; today’s Bitcoin Core labels the check “Disabled opcodes (CVE-2010-5137)”, a reference to a bug in that family of opcodes.
“Disabled” undersells it. Even inside a branch of an OP_IF that never executes, one of those opcodes makes the script fail. Bringing OP_CAT back is a live proposal, BIP 347, one of the debates of our coming lesson on Bitcoin governance and BIPs.
Five output types, four address prefixes
Wallets do not invent locks. They use a small set of standard templates, each with its own address format. Knowing the template behind an address tells you what the spender will have to reveal and roughly how many bytes it will cost.
P2PK and P2PKH: the 2009 locks
Pay-to-public-key (P2PK) is the lock of block 170: a public key and OP_CHECKSIG; to spend it, the scriptSig holds only a signature. It has no address format of its own. Pay-to-public-key-hash (P2PKH) is the five-opcode lock run in the table above. Its addresses start with 1 on mainnet, like the 1XPTgDRh… address behind the pizza input.
P2SH: the lock that holds only a hash of a script
BIP 16, written by Gavin Andresen and applied to blocks from 1 April 2012, introduced pay-to-script-hash. The scriptPubKey is OP_HASH160, a 20-byte hash and OP_EQUAL. The spender reveals the full script, the redeemScript, as the last push of the scriptSig, along with the data it needs. A node first checks that the redeemScript hashes to the value in the lock, then runs the redeemScript itself on the remaining stack.
P2SH moved the cost and the complexity from the payer to the spender. Someone paying a 2-of-3 multisig wallet sends to a short address starting with 3, as the 8,820,000-satoshi output of our 9 November transaction does, and never sees the keys. The redeemScript is a pushed element, so the 520-byte limit applies to it: at most 15 compressed public keys in a multisig. BIP 16 was a soft fork, a rule change that old nodes still accept, as explained in our lesson on soft forks and hard forks.
SegWit and Taproot outputs, in two lines
SegWit version 0, activated in August 2017, added P2WPKH (OP_0 plus a 20-byte key hash) and P2WSH (OP_0 plus a 32-byte script hash), with addresses starting with bc1q; the proof moves into the witness. Taproot, activated in 2021, added P2TR (OP_1 plus a 32-byte key), with addresses starting with bc1p. How the witness, weight, Schnorr signatures and script trees work is the subject of the next lesson of this path, SegWit and Taproot.
OP_RETURN, bare multisig and anchors
Three other output kinds turn up in every block. An OP_RETURN output starts with an opcode that fails at once, so it can never be spent; it carries data, usually with a value of zero, and nodes do not keep it in the UTXO set. Bare multisig puts the full m-of-n script in the output, with no hash. And explorers now show a tiny output labelled anchor (pay-to-anchor): the four-byte script OP_1 followed by the two bytes 0x4e73, which Bitcoin Core recognises by that exact pattern and which is spent with an empty witness, no signature at all. It exists so that a later child transaction can add a fee.
Output types in nine blocks of 9 November 2026: a small sample
There is no single official count of output types, and the long-running charts of transactionfee.info now live at mainnet.observer as interactive graphics. So Coindaro made its own count: it read the raw blocks 975,149 to 975,157 from mempool.space on 9 November 2026 and sorted every output by its script template. It is a small sample, nine blocks whose header timestamps run from 08:30 to 09:33 UTC that morning, and its two halves already disagree, which is the point of the table.
| Output type | Address prefix | Blocks 975,149-975,154 (42,379 outputs) | Blocks 975,155-975,157 (40,551 outputs) | All nine blocks (82,930 outputs) |
|---|---|---|---|---|
| P2WPKH | bc1q | 60.3% | 46.6% | 53.6% |
| OP_RETURN (data) | none | 18.9% | 40.2% | 29.3% |
| P2TR | bc1p | 8.2% | 3.2% | 5.8% |
| P2SH | 3 | 5.7% | 1.9% | 3.8% |
| P2PKH | 1 | 5.4% | 1.9% | 3.7% |
| P2WSH | bc1q (longer) | 1.6% | 0.5% | 1.0% |
| Pay-to-anchor | none | 0.0% | 5.7% | 2.8% |
Source: Coindaro’s count of the 82,930 outputs created in blocks 975,149 to 975,157 (37,675 transactions), raw blocks from mempool.space, 9 November 2026. A nine-block sample, about one hour of the chain, not a trend. P2PK and bare multisig outputs did not appear in it.
Native SegWit keys dominate both halves. The rest swings: data outputs were 19% of outputs in the first six blocks and 40% in the next three, and anchors went from none to 2,323, all of them in block 975,155. Block 975,157 alone held 7,941 data outputs among its 15,923 outputs, close to one for each of its 7,959 transactions. A few large batches of data-carrying or anchor-using transactions are enough to move a three-block share by tens of points, so read any one-day snapshot of output types as weather, not climate. Leaving data outputs aside, P2WPKH still made up about three quarters of the spendable outputs created in each half (74.3% and 77.9%).
What a signature commits to: the sighash flags
OP_CHECKSIG does not check a signature against the whole transaction as it sits on the wire. It checks it against a digest built from a modified copy of the transaction, and the last byte of the signature, the sighash flag, says which parts went into that copy. The Bitcoin developer guide lists the options. All of them sign the lock time.
| Flag (byte) | What the signer commits to | What others can still change |
|---|---|---|
| SIGHASH_ALL (0x01) | All inputs and all outputs | Nothing except other inputs’ signature scripts |
| SIGHASH_NONE (0x02) | All inputs, no outputs | Where the money goes, unless another signature protects the outputs |
| SIGHASH_SINGLE (0x03) | All inputs and the one output with the same index | Every other output |
| ALL | ANYONECANPAY (0x81) | This input and all outputs | Other inputs can be added or removed |
| NONE | ANYONECANPAY (0x82) | This input only | Everything else |
| SINGLE | ANYONECANPAY (0x83) | This input and its matching output | Other inputs and outputs |
Nearly every wallet payment uses SIGHASH_ALL; both our 2026 transaction and the pizza input end their signatures with 0x01. The other flags exist for cooperation between people who do not trust each other. With ALL | ANYONECANPAY, for example, a group could fund a single output, each contributor signing only their own input and the fixed target, and the transaction becomes valid only when the inputs add up.
SIGHASH_SINGLE carries an old trap. If a signer uses it on an input whose index has no matching output, the original code signs the value 1 instead of a real digest, which the developer guide describes as breaking the security scheme: a signature made that way can be reused. Wallets avoid the case altogether.
Signatures themselves are DER-encoded ECDSA in legacy and SegWit v0 scripts, usually 71 or 72 bytes with the flag. BIP 66, enforced from block 363,725 in July 2015, made strict DER encoding a consensus rule. Even then a third party could alter a valid signature into another valid one and so change the txid of an unconfirmed transaction, a problem known as malleability. SegWit removed it by taking signatures out of the txid, as the next lesson explains.
Multisig and the extra item OP_CHECKMULTISIG eats
A multisig lock requires m signatures out of n public keys. The script is a number m, the n keys, the number n and OP_CHECKMULTISIG, with m and n written as the opcodes OP_1 to OP_16. A 2-of-3 lock looks like this:
OP_2 <pubKeyA> <pubKeyB> <pubKeyC> OP_3 OP_CHECKMULTISIG
scriptSig: OP_0 <sigA> <sigC>The opcode pops n, the keys, m and the signatures, then walks through both lists. Signatures must come in the same order as their keys, because the code moves forward through the keys and never goes back. Then it pops one more item. Bitcoin Core’s interpreter says it plainly: “A bug causes CHECKMULTISIG to consume one extra argument whose contents were not checked in any way.” Removing the extra pop would change how scripts already on the chain evaluate, so the bug stayed, and every multisig spend starts its scriptSig with a throwaway OP_0 to feed it.
Because the extra item was never checked, anyone relaying a multisig spend could swap the OP_0 for another value and change the transaction’s ID without breaking it. BIP 147 closed that hole with the NULLDUMMY rule: the dummy must be an empty byte array. Bitcoin Core had enforced it as relay policy since version 0.10.0, and it became a consensus rule with the SegWit deployment of 2017.
Multisig is how companies, funds and careful individuals spread control of cold storage over several devices or people, and how escrow works without an escrow agent holding the coins; our glossary entry on multisig wallets covers the practical side. In practice almost nobody uses bare multisig outputs any more. Bitcoin Core’s relay policy accepts bare multisig with at most 3 keys, and P2SH or P2WSH wrapping keeps the long script out of the output until it is spent. Under P2SH the standard scriptSig limit of 1,650 bytes is, according to the developer guide, large enough for a 15-of-15 multisig with compressed keys.
Timelocks: coins that cannot move before a date
Bitcoin has four time-lock tools. Two sit in the transaction itself and say when the transaction becomes valid; two are opcodes inside a lock and say when an output may be spent. Two are absolute (a block height or a date), two are relative (a delay counted from when the coin was created).
nLockTime and the fee-sniping guard in our transaction
The 4-byte lock time at the end of every transaction is read as a block height when it is below 500,000,000 and as a Unix time otherwise. A transaction with a lock time in the future cannot enter a block yet. The rule has a catch from 2009: it only applies if at least one input has a sequence number below 0xffffffff, which is why wallets that set a lock time also lower the sequence.
Our 9 November transaction carries lock time 975,155, and mempool.space shows it confirmed in block 975,157. Which wallet built it is unknown, but the pattern is a known habit called anti-fee-sniping, followed by Bitcoin Core’s wallet among others. Core’s source sets the lock time to the height of the current chain tip, so the transaction can enter only the next block or a later one. The aim is to discourage fee sniping, an attack where a large miner re-mines the latest block to grab its fees: a transaction that cannot be placed at an earlier height gives such a miner less to take. In about one case in ten Core picks a height up to 100 blocks older at random, so that transactions broadcast some time after signing, such as some CoinJoin transactions, blend in.
OP_CHECKLOCKTIMEVERIFY: a lock with a date on it
nLockTime only delays a transaction that someone has already signed, and the signer can always sign another one without it. BIP 65, by Peter Todd, puts the date inside the output. OP_CHECKLOCKTIMEVERIFY compares a number in the script with the spending transaction’s nLockTime and fails unless the lock time has the same type and is at least as large, with an input sequence below 0xffffffff. Since the transaction cannot be mined before its lock time, the coin cannot move before the date in the script. BIP 65 redefined a no-op opcode, OP_NOP2, so it was a soft fork; Bitcoin Core records its activation at block 388,381, mined on 14 December 2015.
<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGRelative locks: nSequence and OP_CHECKSEQUENCEVERIFY
BIP 68 gave the sequence field a second life in transactions of version 2 or higher. When bit 31 is not set, the low 16 bits hold a delay that must pass between the confirmation of the output being spent and the spending transaction. Bit 22 picks the unit: blocks, or units of 512 seconds. The maximum is 65,535 blocks, about 455 days at ten minutes per block, or 65,535 x 512 seconds, about 388 days.
BIP 112 added the matching opcode, OP_CHECKSEQUENCEVERIFY, in place of OP_NOP3, so that an output can demand such a delay. The two were deployed together with BIP 113, which measures time by the median timestamp of recent blocks, and Bitcoin Core records their activation at block 419,328, mined at 23:16 UTC on 4 July 2016. A relative lock is what payment channels need: one party can close a channel alone, but must wait a fixed number of blocks before taking its share, leaving the other party time to react. The Lightning Network, the subject of a later lesson in this path, is built on that delay.
| Tool | Where it lives | Absolute or relative | Introduced |
|---|---|---|---|
| nLockTime | Transaction field | Absolute (height or time) | 2009, original code |
| OP_CHECKLOCKTIMEVERIFY | Output script | Absolute | BIP 65, block 388,381, 14 Dec 2015 |
| nSequence lock | Input field (version 2+) | Relative (blocks or 512-second units) | BIP 68, block 419,328, 4 Jul 2016 |
| OP_CHECKSEQUENCEVERIFY | Output script | Relative | BIP 112, block 419,328, 4 Jul 2016 |
Inheritance plans use the same tools in a slower way: a wallet can lock coins to an owner’s key today and add a second path that opens to a relative’s key only after a year of no movement. Few consumer wallets expose these options, but the opcodes behind them have been part of consensus since 2015 and 2016.
Consensus rules versus standardness
Everything above that makes a block invalid is consensus: the script limits, the disabled opcodes, NULLDUMMY since 2017, the time-lock rules. Nodes enforce a second, stricter layer on transactions they have not yet seen in a block, called standardness or relay policy. A non-standard transaction is not invalid; nodes running default settings simply refuse to pass it on. The mempool lesson linked above explains the policy limits on size, dust and fee rate (400,000 weight units, dust computed at 3 sat/vB, 0.1 sat/vB minimum relay fee in current Bitcoin Core). The script-related policy is what matters here.
| Bitcoin Core policy (policy.h, master branch, 9 Nov 2026) | Value | Consensus limit for comparison |
|---|---|---|
| Maximum standard scriptSig | 1,650 bytes | 10,000-byte script |
| Bare multisig relayed | Up to 3 keys | Up to 20 keys |
| Signature operations in a P2SH redeemScript | 15 | None specific |
| Maximum P2WSH witness script | 3,600 bytes | 10,000 bytes |
| Transaction versions relayed | 1 to 3 | Any |
| Minimum non-witness size | 65 bytes | None |
Beyond the numbers, policy accepts only the known output templates listed earlier and requires scriptSigs that only push data. A script built from some unusual combination of opcodes may be perfectly valid, but it will travel only if a miner receives it directly and chooses to include it. Once in a block, every node accepts it, because blocks are judged by consensus alone.
Policy can change in a software release without a fork; consensus cannot change without a soft or hard fork, with the coordination described in the lesson on forks. The larger OP_RETURN data limit that Bitcoin Core 30.0 brought in October 2025, described in the mempool lesson, was such a policy change (documentation written before it still speaks of 80 bytes); the dispute around it belongs to the coming lesson on Bitcoin governance.
Reading your own transactions on an explorer
With these pieces, an explorer page reads differently. The inputs tab lists outpoints and, for each, the type of lock that was opened; the outputs tab lists the new locks. An input of type P2PKH will show a signature and a full public key, a P2WPKH input shows the same two items in the witness, and a P2TR key-path input shows a single signature of 64 or 65 bytes. Our guide on how to read a block explorer walks through the screens.
Two habits follow. Check the lock time and the sequence numbers when a payment seems stuck: a lock time in the future, or a non-final sequence on a transaction that relies on it, explains a delay that no fee will fix. And remember that the network sees scripts, not people: an explorer cannot tell whether an output goes to a merchant or back to the sender as change.
That last point matters at tax time. In the United States the IRS treats bitcoin as property, and our guide to crypto taxes in the United States notes that moving coins between your own wallets is not taxable, except for coins used to pay the fee. In the United Kingdom, as our UK crypto tax guide explains, a transfer between addresses you control is not a disposal for HMRC. Since the chain cannot show who controls an output, the proof is yours to keep: the txid, the date and a note of which outputs were your own.
The next lesson of this path picks up where the output table stopped: how SegWit moved signatures into the witness and why Taproot made a multisig look like a single-key payment.
