15 standards
Background Evaluation Extended Format. One bundle carrying a transaction, its ancestors and their proofs, so the recipient can verify the lot without asking anybody for anything. Several standards extend or restrict it.
Also searched as Background Evaluation Extended Format, Atomic BEEF, bundle.
A format that bundles a transaction together with the ancestor transactions and merkle proofs needed to check it. The recipient can verify it against block headers alone, without asking a node or an indexer for anything.
Open in the glossary15 standards, spread across 5 of the 12 topics.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
Filed under Transactions
BEEF is the main subject of these 7.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.
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.
Two parties who have already exchanged proofs for a transaction resend all of it every time it comes up again. This lets a bundle name a transaction the other side already has instead of repeating it.
Once a second kind of object has its own space, it needs a frame to travel in and a route back for submissions. This defines those wire forms.
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
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.
These are about something else, and deal with beef on the way.
Finding your own application's data on the blockchain means either scanning everything or trusting somebody else's index. This defines how to submit transactions to a service that tracks only the subset you care about, and how it reports back what it accepted.
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
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.
An index that only keeps current data cannot answer questions about how something got to be the way it is. This extends the index to retain the spent history as well, so past states remain queryable.
A payment large enough to need several transactions will not fit in a web request header, where the payment scheme puts it. This moves the payment into the request body when it grows too big.
The address space carrying transactions was not designed to carry anything else, so a second kind of object has nowhere to go. This divides it into planes, giving each kind of object its own room.
When someone sends you a token on Bitcoin, you cannot just trust the number they tell you: you need to check it came from a real issuance and was never double-counted through splits or merges, without running a full blockchain indexer. Existing proof formats either strip out the very transaction history token math depends on, or only work for simple single-path assets, leaving no safe way to check a token tip you just received while offline.
Two different wallets checking the same unconfirmed payment describe what they verified in totally different ways, so there is no way to compare "three hops back to a confirmed block" against "a valid BEEF" or to let an app set one acceptance rule that works regardless of which wallet it is talking to. This leaves users and apps guessing what was actually checked before goods change hands, with no shared way to say it.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic