23 standards
A transaction has to be written down before it can be sent anywhere. Standards here define the layouts: the raw form, the extended forms that carry extra context, and the way one specific output is named.
Also searched as raw transaction, extended format, envelope, TXO, outpoint, serialization.
A reference to one specific transaction output, written as the transaction id followed by the index of the output within it.
Open in the glossary23 standards, spread across 4 of the 12 topics.
Bitcoin transactions travel as raw bytes, and anyone writing software that reads or builds them needs to know exactly what those bytes mean. This documents that layout, field by field.
Filed under Transactions
Transaction formats is the main subject of these 5.
Sending someone a transaction is not enough for them to trust it: they also need the earlier transactions and the proofs showing the money is real. This defines a single package carrying all of it, so software from two different vendors can exchange a payment the recipient can actually check.
Bitcoin transactions travel as raw bytes, and anyone writing software that reads or builds them needs to know exactly what those bytes mean. This documents that layout, field by field.
Raw transaction bytes are compact but almost impossible to search or filter. This describes a structured representation of the same data that can be stored in an ordinary document database and queried like any other record.
A transaction on its own does not carry enough to check that its signatures are valid: the amounts and locks being spent live in earlier transactions. This adds those missing pieces, so a service can validate what it is given without looking anything up.
Referring to one particular coin is easy; referring to it so another program can act on it is not, because its amount and its lock live elsewhere. This defines the smallest complete way to name an output together with what is needed to use it.
These are about something else, and deal with transaction formats on the way.
An application that wants to move money has to build a Bitcoin transaction, and building one correctly means handling keys, fees and change. This lets the application describe what it wants to happen and hand the actual work to a wallet, which already knows how to do it safely.
Spending money you already hold means pointing at the specific coins you own and proving you are allowed to spend them. This gives an application a way to name those coins when asking a wallet to build a transaction, along with everything the wallet needs to check the claim before it signs.
Confirming a payment traditionally means running a full copy of the blockchain, which is far too heavy for a phone or a web page. This describes how a recipient can satisfy themselves a payment is genuine using only block headers and a short proof.
An application that has received a payment on someone's behalf has no standard way to hand it over. This defines how a transaction and its proofs are submitted into a wallet, so the wallet recognises the funds as the user's own.
Recording a long series of events on chain by chaining one transaction to the next gets expensive and slow. This describes carrying the same history as a chain of hashes inside a single transaction that keeps being updated instead.
Sending proofs for several transactions separately repeats the same hashes over and over. This defines a compact form that carries proofs for many transactions at once with the shared parts included only once.
Earlier descriptions of how a light client checks a payment were spread across documents and leaned on each other. This states the process on its own terms so it can be read and implemented without following a trail of references.
Storing a proof in a database means keeping it small and quick to read back. This defines a compact binary shape for a single transaction's proof, aimed at storage rather than transmission.
Different proof formats each solved part of the problem, leaving processors and clients converting between them. This defines one format that is cheap for a transaction processor to produce and convenient for a client to check.
A bundle carrying several transactions leaves the recipient guessing which one is the subject and which are supporting evidence. This constrains the bundle to a single subject transaction so there is nothing to guess.
A proof spanning a whole block is larger than needed when the transactions of interest sit close together. This encodes the path within a subtree instead, which is smaller for that common case.
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
The same frame is useful for a transaction that already carries the details needed to validate it on its own. This defines that variant while leaving the header untouched, so existing readers still work.
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
Sending many tiny transactions as separate packets spends more on overhead than on content. This packs the ones heading the same way into a single frame.
The list of transaction hashes making up a subtree also needs to travel over an ordinary byte stream, not just one-to-many delivery. This defines that form and how a receiver takes it in.
Some BSV transaction bundles need to say 'here is everything about this one transaction' without being limited to only its ancestor history. Before this, a format that pinned down a single subject transaction, Atomic BEEF, forced the bundle to contain only ancestors and nothing else, which breaks when a protocol needs sibling or related transactions included too. Without a way to say 'this bag is about transaction X, and it can contain whatever a given use case requires,' a developer had no clean way to hand over a flexible, well-identified bundle.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic