Pay to Public Key Hash
Most Bitcoin payments lock coins so that only the holder of one particular key can spend them. This documents exactly how that lock is written and later unlocked, which is the pattern behind an ordinary Bitcoin address.
16 standards
Every output carries the condition under which it may be spent. Standards here define the common templates, from the everyday pay to public key hash to ones that carry data alongside the condition.
Also searched as P2PKH, pay to, multisig, PushDrop, R puzzle, unlocking script.
The conditions attached to an output that say how it may be spent. The spender supplies an unlocking script that has to satisfy them.
Open in the glossary16 standards, spread across 5 of the 12 topics.
Most Bitcoin payments lock coins so that only the holder of one particular key can spend them. This documents exactly how that lock is written and later unlocked, which is the pattern behind an ordinary Bitcoin address.
Filed under Scripts
Locking scripts is the main subject of these 3.
Most Bitcoin payments lock coins so that only the holder of one particular key can spend them. This documents exactly how that lock is written and later unlocked, which is the pattern behind an ordinary Bitcoin address.
Sometimes you want to lock coins so that anyone who knows a particular secret can claim them, without publishing the secret itself. This describes a way to do that using a value which already appears inside every signature.
Some funds should not be movable by one person acting alone. This documents the direct way to require several signatures before an output can be spent, and is honest about what it costs in privacy.
These are about something else, and deal with locking scripts on the way.
The same script can be written as raw bytes, as hexadecimal, or in a readable assembly form, and tools disagree about the details. This documents all three so software can convert between them without surprises.
Bitcoin's scripting instructions are numbers, which machines read easily and people do not. This defines a readable way to write them down, so a developer can inspect a script and reason about what it does.
Attaching data to an unspendable output means the coins attached to it are gone for good, which some argue is the wrong way to think about Bitcoin. This offers a way to carry data on an output that can still be spent afterwards.
Attaching data to an output normally makes it unspendable, so the data and the ownership cannot travel together. This describes a script that carries arbitrary data and leaves the output spendable, letting a token hold its own details.
Once the layers of the network are named, the next question is which pieces of a transaction belong to which layer. This works through where outputs, indexes and scripts sit and how they relate.
Every library prints Bitcoin script in a slightly different readable form, so output from one tool is not accepted by another. This fixes one form so scripts can be moved between tools and languages.
Different fungible token systems on Bitcoin SV have each invented their own way of writing an amount and a token identifier onto a transaction output, so wallets and contracts have had to support multiple incompatible formats just to move the same kind of balance. That means extra parsing code, extra bugs, and scripts that cannot easily inspect a token output the way they can a plain payment. A shared, script-readable layout means any wallet or contract can check and build these outputs the same way, every time.
Bitcoin Script is a low-level stack machine with no names or structure, so a script of any real size is nearly impossible to read, review, or safely edit once written. Because a published covenant can never be changed after it is funded, mistakes hidden in that unreadable stack manipulation are typically found only after it is too late to fix. This gives developers a way to write covenant logic in a readable form and, just as importantly, to read back and verify a script someone else already deployed.
When an AI agent spends money on your behalf, it usually does so with a password-like credential that can drain whatever account sits behind it, and if something goes wrong you have to notice, log in, and revoke that credential while the agent keeps spending in the meantime. There was no way to hand an autonomous agent a fixed amount of money it could use on its own, anywhere, while guaranteeing the owner could never lose more than that amount and could always take the rest back in a single action.
On BSV, the usual "spend after a certain block height" protections in Bitcoin scripts have been turned off, so there was no safe way to give one person a key that works right away and another person a key that only works after a deadline. Anyone trying to build this by hand could accidentally create a lock that looks safe but can actually be spent immediately, or one that can be used to jam the other party's ability to act before the deadline.
A wallet balance just shows a number. It does not tell you whether the asset behind that number can be frozen, blocked, or reversed by someone other than the person holding it. Developers end up guessing, or reading custom code, to find out whether a token truly belongs to its holder or is secretly on a leash held by its issuer. This gives a clear, checkable way to tell those two kinds of token apart just by looking at the script.
Moving coins between two different blockchains usually means trusting an exchange or bridge to hold your funds while the swap happens, and that middleman can freeze, lose, or steal them. This describes a way for two wallets to trade coins across chains directly, so that either the trade completes for both sides or each party simply gets its own coins back, with nobody ever holding the other's funds and neither side needing to be online at the same moment.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic