Payment Evidence Statements for BREAD and BEEF

Abstract

This BRC defines a payment evidence statement, a small canonical JSON object in which a receiver records what it verified about an unmined payment and what it did not: the ancestors anchored by a Merkle path to a header it trusts, whether every input reaches one, the longest and shortest unconfirmed distance to an anchor, which unconfirmed transactions passed script, amount and lock-time checks, and the payment's observed status. A receiver that reports ancestry distance, as BREAD does, and a receiver that holds a [object Object] can each make one from the evidence it already has. No statement says that a payment will be mined. The BRC also converts Electrum-form Merkle branches to BRC-74 paths and defines an optional signature and wallet method.

Motivation

Two kinds of evidence are in use for a payment that is not yet mined.

The first is ancestry distance. The receiver walks back from the payment through its unconfirmed ancestors until it reaches a transaction with a Merkle path to a block header, and reports the number of steps. The number records distance; which checks were run is a separate fact. ElectrumSVP's release notes for version 0.2.0-beta.1 describe evidence of this kind under the name BREAD: "Improved BREAD verification, including local proof-data handling, unconfirmed transaction verification, confirmed-ancestor anchoring, hop reporting, and BREAD JSON export". Its 0.2.0 release notes expand the name as Blockchain Referenced Evidence and Data.

The second is BEEF (BRC-62, with the Atomic form of BRC-95 and the V2 form of BRC-96), which carries unconfirmed ancestors back to transactions with BRC-74 Merkle paths. With it, a receiver can run every script, check every signature, and check that each transaction's inputs cover its outputs, the checks that BRC-67 lists for simplified payment verification. When it does, the result answers whether every spend from those coins to the payment is valid. The BEEF alone does not say whether a receiver ran those checks, or against which headers.

Neither kind of evidence answers whether the payment will be mined, or whether a conflicting spend of one of its inputs exists. Those depend on what miners do next. A receiver can look for a conflicting spend at a given moment, through a node it runs or a service it asks, and that observation is the most it can hold.

Each kind of evidence is described in its own terms today. "Three hops" and "a valid BEEF" may describe the same payment, and neither phrase alone lists the checks behind it. A statement in common terms lets:

• a user see what their wallet checked before they hand over goods;
• an application apply one acceptance policy, whichever wallet serves it;
• a wallet of either kind report what it knows, without adopting the other kind's format or architecture.

Scope and conformance

Layer. Interface: what one program tells another about a payment, whether wallet to application, wallet to user or wallet to wallet. Whether to accept a payment is policy, and this document does not set it.

Three roles are used, and a MUST binds only an implementation that claims the role its sentence names:

• a maker produces statements (sections 2 to 4, 6 and 7);
• a reader reads them (section 5);
• a wallet that offers the method of section 8, which that section binds.

Adoption is voluntary. A wallet that makes no statements does not follow this document, and its other behaviour is unaffected.

What this document does not require. How a maker obtains its material or its block headers; how it stores anything; which transport carries a statement; whether a maker validates at all (a statement whose validation is "none" conforms); whether and how it checks for a conflicting spend; the values of its bounds and of a reader's; and the BRC-100 interface, which section 8 uses optionally. A statement is self-contained: reading it needs no service and no key, and checking its anchors needs only block headers.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in capitals.

Specification

1. Terms

• Payment: the transaction a statement is about.
• Txid: the double SHA-256 of a transaction's bytes. Inside a transaction, a BEEF, an Atomic BEEF's prefix and a BRC-74 path, a txid is in internal byte order, the order the hash gives; in a statement, and in this document's tables, it is 64 lowercase hexadecimal digits in display order, the reverse. A maker MUST compute every txid from the bytes it holds. An input names the transaction it spends by txid in internal byte order, and the maker matches it against the txids it computed in that same order. A txid written beside the bytes is a claim.
• Material: what the maker holds of the payment's ancestry, of one of two kinds: a BEEF as received (BRC-62 V1, 0100beef, or BRC-96 V2, 0200beef, alone or inside a BRC-95 Atomic BEEF), or raw transactions and Merkle paths from the maker's own records. A statement is made over one material.
• Header source: the block headers the maker trusts, by height, and its tip, the highest of them; the source holds the tip's header. How the maker obtains them is outside this document. Every anchor is only as good as this source (see Security Considerations).
• Median time past: the median of the timestamps (bytes 68 to 71 of the 80-byte header, little-endian) of the 11 blocks ending at the header source's tip, that is the tip and the 10 blocks below it. A maker whose header source lacks one of those headers has no median time past.
• Merkle path: BRC-74 bytes. In a BEEF, a path counts for a transaction only when that transaction's entry names its index: BRC-62's has-BUMP byte 01 and index, or BRC-96's format 01 and index. In records, a path is held for a txid, as BRC-74 bytes or as an Electrum-form branch (section 6).
• Own path: for a txid at offset x of level 0 of a path of tree height h (the lowest such offset, if the txid is at more than one), the h steps that fold it. At step i, from 0 to h - 1, the working hash and its sibling, the node at offset (x >> i) XOR 1 of level i, are hashed together, the left node first, as the double SHA-256 of their 64 bytes. The sibling is the hash the path gives at that offset, the working hash again where the path marks that offset a duplicate (flag 01), or the node computed from the two nodes below it. The working hash starts as the txid and its last value is the root. A step with no sibling ends the fold with no root, and a txid that is not at level 0 has no own path. A one-transaction block is the exception: a path of tree height 1 that holds one node, the txid at offset 0, has no step, and its root is the txid.
• Anchor: a transaction the maker holds, with a Merkle path that (a) gives a root by the fold of the transaction's own path, which takes exactly the path's tree height of steps, or none for a one-transaction block; (b) names a height at or below the header source's tip at which the header source holds a header; (c) gives a root equal to the Merkle root of that header (bytes 36 to 67 of the 80-byte header, in internal byte order); (d) is for a transaction that is not exactly 64 bytes long; and (e) at no step of the own path hashes 64 bytes, the two nodes in the order hashed, that decode as a transaction. Any field carried with the material that asserts confirmation, a height or a header included, is a claim, and is not evidence of an anchor.
• Decodes as a transaction, for 64 bytes: read in the standard transaction serialization, they give, ending exactly at byte 64, a 4-byte version; an input count of at least 1; each input as a 32-byte txid, a 4-byte index, a script length and that many bytes, and a 4-byte sequence number; an output count of at least 1; each output as an 8-byte value, a script length and that many bytes, with every value, and the running sum of the values, at most 2,100,000,000,000,000; and a 4-byte lock time. Counts and lengths are VarInts, in any of their forms.
• Unconfirmed set U: the transactions the walk of section 2.1 reaches that are not anchors. The payment is in U unless it is itself an anchor.
• Unresolved input: an input of a transaction in U whose source transaction the maker does not hold.

2. Making a statement

2.1 The walk

The maker starts at the payment and visits each transaction once, in whatever order the material holds them. It reads the Merkle path of each visited transaction that has one, as BRC-74 permits (below). A path that meets condition (b) of an anchor is checked as one (section 1), and its transaction is not followed further. A path that does not meet condition (b), because it names a height above the tip or one for which the header source holds no header, is not checked: the maker treats its transaction as if it carried no path. Every other visited transaction joins U, and each of its inputs is followed to the transaction it spends, or recorded as unresolved if the maker does not hold that transaction. The inputs come from the held bytes, never from anything carried beside them. The maker decodes only the transactions the walk visits. It reads the rest of the material only as far as its framing needs and, in an Atomic BEEF, as far as each entry's txid and the outpoints its inputs name, to tell an ancestor from an unrelated entry. Framing a BEEF reads every path in it, and a node's flag sets the node's length, so a path that holds a flag other than 00, 01 or 02 cannot be framed: it is MALFORMED whether or not a visited transaction names it.

A BEEF V2 entry that carries only a txid holds no transaction, so an input that spends it is unresolved. BRC-96 treats such an entry as valid by agreement between the parties exchanging the BEEF, and that agreement is not evidence a statement records. A maker that holds the transaction MAY make its statement from its records instead.

An Atomic BEEF that lacks an ancestor is material here. BRC-95 fails the validation of such an Atomic BEEF; a maker reads it, and the statement names the inputs that are unresolved. A statement about it does not say that it passes BRC-95 validation. BRC-95's other rules apply as written: the subject, the 32 bytes after the prefix read in internal byte order, is the payment, and the material holds the subject and its ancestors and nothing else. An ancestor is any entry the material holds whose txid an input of the subject, or of another ancestor, names, an anchor's inputs included. A transaction beyond an anchor is therefore an ancestor: BRC-95 permits it, the byte bound counts it, and the walk does not visit it. An entry that carries only a txid has no inputs, so it names no further ancestor, and one whose txid no such input names is unrelated, as an unrelated transaction is.

A maker MUST refuse, with the code given, and return no statement:

A path that BRC-74 does not permit is one with a tree height of 0 or more than 64; a flag other than 00, 01 or 02; two nodes at one offset of a level; a node outside the tree, at an offset of 2^(h - i) or more at level i of a tree of height h; or a node, given as a hash or as the duplicate of its sibling, that differs from the node computed from the two nodes below it. These are checked on the path of every visited transaction, whether or not it meets condition (b), and the flags on every path of a BEEF, since framing reads them. Nodes off a transaction's own path take part in these checks and in nothing else.

A maker MUST have all four bounds and MUST refuse beyond them, never describe part of a graph. It MUST NOT emit a statement longer than its bound on statement length, and refuses OVER_BOUND instead. Their values are policy. A maker SHOULD use 1,000,000 bytes as its bound on statement length, the value section 5 recommends for a reader's bound, so that a reader with that bound reads every statement a maker with it emits.

After a reorganisation that replaces the block a path names, the header source holds another header at that height, and material that holds the path is refused ANCHOR_MISMATCH (condition c) until its path is replaced.

2.2 Anchoring and distance

• fullyAnchored is true when no input is unresolved.
• distanceMax, when the payment is fully anchored, is the number of transactions of U on the longest path from the payment back to an anchor. It is 1 when every input of the payment spends an anchor's output, and 0 when the payment is itself an anchor. It is null when the payment is not fully anchored.
• distanceMin is the number of transactions of U on the shortest path from the payment back to an anchor, whether or not the payment is fully anchored. It is 0 when the payment is itself an anchor, and null when no path reaches an anchor.

A path's number of transactions of U equals its number of edges from the payment to the anchor: for a chain D, C, B, A in which D spends C, C spends B, B spends A and only A is anchored, both distances are 3.

2.3 Validation

A transaction X of U is validated when the maker has run each check below on X and on every transaction of U that X descends from, and every check passed. Only a transaction whose ancestry is fully anchored can be validated, because the checks read the outputs it spends.

1. Scripts. For each input, the unlocking script followed by the locking script of the output it spends evaluates to true under the consensus rules in force for the block after the header source's tip. Some of those rules depend on the height at which the spent output was created: for an output that an anchor created, the height of the anchor's block, and for an output that a transaction of U created, the block after the tip, as SV Node judges an output created in its mempool (validation.cpp L2667-L2674 and L2692-L2696). On mainnet the Genesis upgrade activated at height 620,538 and the Chronicle upgrade at 943,816 (SV Node chainparams.cpp L18-L23); for example, OP_2MUL is enabled for an output created at or above 943,816 and disabled for one created below it (interpreter.cpp L360-L372). A maker whose next block is below an upgrade's activation height applies the rules from before it. This check includes every signature check (BRC-67 step 1).
2. Amounts. Each output's value, and the sum of X's outputs, is from 0 to 2,100,000,000,000,000 [object Object], and the outputs X spends add up to at least the sum of its outputs. BRC-67 step 2 asks for more than the outputs, as a stand-in for a fee rate. This check asks only that no value is created, and section 2.4 reports the fee.
3. Lock time. X can be mined in the block after the header source's tip as it stands: its nLockTime is 0; or every input's sequence number is 0xFFFFFFFF; or its nLockTime is below 500,000,000 and below that block's height; or its nLockTime is 500,000,000 or more and below the median time past (section 1). An input that spends an output of an anchored coinbase transaction does so only if that block's height is at least the coinbase's height plus 100, the network's coinbase maturity (SV Node consensus.h L75). An input that spends an output of an anchored transaction whose first output's locking script begins 006a0463667478 (OP_FALSE OP_RETURN and a push of cftx), a confiscation transaction (frozentxo_db.cpp L614-L636), does so only if that block's height is at least the anchor's height plus 1,000 (consensus.h L79, validation.cpp L2627-L2636). Before Genesis, the relative lock times of BIP 68, set by each input's sequence number, also bound a transaction of version 2 or above (validation.cpp L272-L273 and L3463-L3468, policy.h L247-L255); a maker whose next block is below the Genesis activation height applies them too. BRC-67 step 4 asks that nLockTime and each nSequence be set to the values the receiver expects. This check asks only whether X can be mined in the next block; which values a receiver expects is its policy.

Only a check that ran under the consensus rules and failed is a refusal, and the maker then returns no statement:

A maker MUST NOT refuse because of a limit it sets for itself, such as a bound on a script's memory, operations or number length, or because of a stricter rule it applies for its own use. When the maker cannot complete a check on a transaction, it MUST leave that transaction, and every transaction of U that descends from it, out of the validated set, and MUST NOT refuse because of it. It cannot complete a check when its interpreter does not implement an opcode the script uses under the rules in force, or treats it otherwise than those rules do (as disabled, as invalid or as doing nothing); when an evaluation reaches one of its own limits; when a lock time needs a median time past it does not have; or when check 3 needs a relative lock time and the maker does not implement those. Nor can it complete the checks on a transaction of U whose own first output's locking script begins 006a0463667478: that is a confiscation transaction, which SV Node accepts only when it is whitelisted (validation.cpp L2562-L2587), and a maker cannot know the whitelist. A maker MAY also leave out a transaction that passes these checks but not a stricter check of its own, and it need not check a transaction that descends from one it left out. A statement records only checks that passed: a maker MUST NOT count as validated a transaction whose checks were not all completed.

A maker that ran a check and found that it failed MUST refuse. It MUST NOT then report that transaction as not checked, or make a distance-only statement about the same payment from material that holds it, while the failure stands; for PREMATURE, that is until a later tip lets check 3 pass.

validated lists the validated transactions. validation is "all" when the payment is fully anchored and every transaction of U is validated, "none" when U is not empty and no transaction is validated, and "partial" otherwise. A maker that runs no checks reports "none", and conforms. A payment that is itself an anchor has an empty U, so its validation is "all" whether or not the maker validates: the checks of this section apply to U, so both kinds of maker have run the same checks on such a payment, and both make the same statement.

When more than one refusal applies, a maker MAY report any of them.

2.4 Fee

lowestFeeRate covers validated transactions only. It is the fee and size of the validated transaction whose fee per byte is lowest, as {"bytes": size, "satoshis": fee}, where the fee is what its inputs spend less what its outputs pay, and the size is the length of its bytes. Among equal rates it is the one with the smallest txid. It is null when no transaction is validated. Two integers carry the rate without rounding. Whether the rate is enough for a miner is policy.

2.5 Status and observations

status is {"depth": d, "event": e}, where e is the event furthest down this table among those the maker observed for the payment, whatever order it observed them in:

A maker MUST say mined when the payment is itself an anchor, and MUST NOT say it otherwise, whatever it was told.

conflicts is {"checked": false}, or a check the maker made for a conflicting spend:

{"at": t, "checked": true, "found": f, "kind": k, "scope": s}

• at: when the observation was made, in Unix seconds, no later than madeAt.
• found: true if a transaction other than those in U was observed spending an output in scope.
• kind: own-node, a node the maker operates, or third-party, a node or service operated by another party.
• scope: payment, the outputs the payment's own inputs spend, or unconfirmed, the outputs spent by every transaction of U.

How the observation is made is operation, and outside this document. found: false says only that none was seen at time at.

madeAt is when the statement was made, in Unix seconds.

tip is {"blockHash": b, "height": n}: the header source's tip when the statement was made, and the double SHA-256 of its header in display order. Every depth and lock-time verdict in the statement is for that tip: check 3 was made for the block at n + 1.

3. The statement

A statement is a JSON object with exactly these fields:

Every txid and block hash is 64 lowercase hexadecimal digits, in display order. Every array is in strictly ascending order of the strings and integers named, so no txid (or txid and vout) is in it twice.

4. Canonical form

A statement is exchanged as the bytes of its canonical form:

• keys sorted by their bytes at every level, with no whitespace and the separators , and :;
• integers in decimal, from 0 to 2^53 - 1, with no sign, leading zero, fraction or exponent; there are no other numbers;
• strings only from the values of section 3, so no character is ever escaped; null, true and false as JSON writes them;
• the whole encoded as ASCII.

This is the canonical form of BRC-179 section 7.2, extended with integers and null as above. A maker MUST emit it.

5. Reading a statement

A reader has a bound on the length of the bytes it reads. Its value is policy, and a reader SHOULD use 1,000,000 bytes, the value section 2.1 recommends for a maker's bound on statement length. A reader MUST, in this order:

1. refuse OVER_BOUND if the bytes are longer than its bound, before it parses them;
2. refuse MALFORMED_STATEMENT unless the bytes are ASCII, nest arrays and objects at most 32 deep (the outermost object is depth 1), and parse as a JSON object, with no key twice in one object, whose version is a string;
3. refuse UNKNOWN_VERSION if version is not bsv-payment-evidence/v1, and read no further;
4. refuse MALFORMED_STATEMENT if the bytes are not the canonical form of the object they parse to; if a field is missing, unexpected or of the wrong type (a boolean is true or false, never a number); if a txid or block hash is not 64 lowercase hexadecimal digits; if a vout is above 2^32 - 1, the largest output index a transaction can name; if an array is not in the strictly ascending order section 3 gives; if validation, status.event, conflicts.kind or conflicts.scope has a value that sections 2.3 and 2.5 do not list; or if the fields disagree with one another:
   • fullyAnchored is true exactly when unresolved is empty;
   • no txid is in both anchors and unconfirmed;
   • the payment is either in anchors, with unconfirmed empty, or in unconfirmed;
   • distanceMax is null exactly when fullyAnchored is false, and distanceMin is null exactly when anchors is empty;
   • for a payment in anchors, anchors holds that entry only and both distances are 0; otherwise a fully anchored payment has an anchor, a distance that is not null is at least 1 and at most the length of unconfirmed, and distanceMin is at most distanceMax;
   • validated is within unconfirmed, and validation is the value section 2.3 gives for these lists;
   • the payment is in validated only if validated equals unconfirmed and fullyAnchored is true;
   • the txid of an unresolved entry is not in anchors, unconfirmed or validated;
   • lowestFeeRate is null exactly when validated is empty, and its bytes is at least 1;
   • status.event is mined exactly when the payment is in anchors, and status.depth is a positive integer then and null otherwise;
   • conflicts.at, when present, is at most madeAt;
   • every anchor's height is at most tip.height, and for a payment in anchors, status.depth is tip.height less the payment's anchor height, plus 1.

A reader MUST NOT take a statement to say more than its fields do. A fully anchored payment is not a mined payment. Validation all does not mean the payment will be mined. found: false does not mean that no conflicting spend exists.

6. Merkle branches in the Electrum form

The Electrum protocol's blockchain.transaction.get_merkle returns a Merkle branch as {"block_height": h, "merkle": [...], "pos": p}: the sibling hashes from the bottom of the tree up, each as hex in display byte order, and the transaction's index in the block. Electrum-protocol servers return branches in this form. A maker MAY hold paths in this form, and raw transactions held with such branches are material (section 1). A maker that converts a branch to a BRC-74 path MUST:

1. compute the txid from the raw transaction it holds;
2. refuse MALFORMED, and make no path, if the raw transaction does not decode completely; if the branch is not an object of exactly block_height, merkle and pos, with non-negative integers h and p (h below 2^64, since BRC-74 writes it as a VarInt) and each sibling 64 lowercase hexadecimal digits; if it has more than 64 siblings (BRC-74's limit on a tree's height); or if p is 2^n or more, where n is the number of siblings (with no sibling, p is 0). The conversion refuses nothing else;
3. write the path with block height h and tree height n, or, with no sibling, tree height 1 and the transaction alone at offset 0, a one-transaction block. Level 0 holds the transaction at offset p with flag 02 and its txid in internal byte order, and, when n > 0, the first sibling at offset p XOR 1. Each level i from 1 to n - 1 holds sibling i at offset (p >> i) XOR 1. Nodes in a level are in ascending offset. A sibling equal to the working hash at a level where the working node's offset is even is written with flag 01 and no hash; every other sibling is written with flag 00 and its hash in internal byte order.

The conversion hashes the branch only to find those duplicates. The converted path is a Merkle path like any other: it anchors only through the checks of section 1, against the maker's own header source, so a step that hashes 64 bytes that decode as a transaction is refused ANCHOR_MISMATCH there, when the path is checked. Only the siblings, h and p are used. A maker that holds a branch and does not convert it MUST check it as if converted, with the same refusals and the same anchor. Folding the branch as the Electrum protocol does and folding the converted path give the same root.

7. Signing (optional)

A maker MAY sign the canonical bytes of a statement as a BRC-77 message. The BRC-77 serialization travels beside the statement, never inside it. A verifier checks it over the exact bytes it received; any other serialization of the same object does not verify. A signature says who made a statement and adds nothing to what the statement claims.

8. Offering statements to applications (optional)

A wallet that implements BRC-100 MAY offer one additional method, getPaymentEvidence:

• Arguments. Either txid, a payment the wallet holds, or atomicBEEF, an Atomic BEEF (BRC-95) for the wallet to evaluate without storing it; and sign, a boolean, false when omitted. For atomicBEEF the material is that Atomic BEEF alone: the wallet's records resolve none of its inputs, so any party with the same bytes and the same headers can make the same statement. For atomicBEEF, too, status.event is received unless the payment is an anchor, whatever the wallet's records say of the payment, and conflicts is {"checked":false} or an observation made for this call.
• Result. statement, the statement as a string, and, when sign is true, signature, the BRC-77 serialization as hex. A string keeps the bytes exact across transports that re-serialize objects.
• Errors. A refusal is a BRC-100 error, with status "error", a code of ERR_EVIDENCE_ followed by the refusal code of section 2 (for example ERR_EVIDENCE_ANCHOR_MISMATCH), and a description; no statement is returned. For txid, a payment the wallet does not hold and a call the user has not permitted for that payment both give the code ERR_EVIDENCE_UNKNOWN_TXID with the same description. A call with neither txid nor atomicBEEF gives ERR_MISSING_PARAMETER, one with both gives ERR_CONFLICTING_PARAMETERS, and a sign that is not a boolean gives ERR_INVALID_PARAMETER_VALUE, the codes BRC-100 suggests for those cases; none returns a statement.

A wallet that offers the method MUST return the statement's canonical bytes (section 4) unchanged, and its errors as above.

The method is not one of BRC-100's methods. It changes no BRC-100 argument, result, call code or default behaviour, and an application that does not call it sees no change. This document assigns it no wire call code. As BRC-100's compatibility contract requires of an unsupported extension, a wallet that does not offer the method fails the call explicitly, and that failure says nothing about the payment.

An application learns whether a wallet offers the method by calling it, never from the getVersion string (BRC-205 section 6), and a wallet that publishes a BRC-179 capability manifest declares it there as <product>.<surface>.getPaymentEvidence, at the tier of its most sensitive step.

Rationale

Two distances. The longest path is the worst case. A payment is good only if every input is good, and a short path through one input says nothing about a long path through another, so a limit on unconfirmed depth compares with distanceMax. distanceMin, the distance to the nearest anchor, exists even when some input is unresolved. On a chain the two are equal; on S5 they are 3 and 1. Carrying both lets an application see the gap.

A failed check is a refusal. A statement that recorded a failed check would rely on every application reading it correctly in order not to accept an invalid payment. A refusal cannot be misread, and it keeps none meaning "not checked".

Not checked is not failed. A validation refusal (section 2.3) says the payment cannot be mined as it stands, so it is kept for checks that ran under the consensus rules and failed. A maker's own limits, and rules its interpreter does not implement, only leave transactions out of the validated set: the statement then says less, and nothing false.

A path that does not match is a refusal. A Merkle path that leads to a root other than that of the header the maker trusts at its height is contradicted evidence: it is fabricated, or from a block the maker's chain does not hold. Treating its transaction as unconfirmed would hide that. A path above the tip, or at a height for which the header source holds no header, is neither confirmed nor contradicted, so its transaction is walked as an unconfirmed one, and a later statement may anchor it. A path that BRC-74 does not permit is wrong whatever the headers say, so it is refused before any header is read.

The own path. Two inner nodes read as a transaction are 64 bytes long, so condition (d), which never anchors a 64-byte transaction, keeps inner nodes from standing for a transaction. Condition (e) keeps a transaction from standing for inner nodes, and, like condition (a), it concerns only the steps that fold the transaction's own txid, since only those decide what the path proves about that transaction. Nodes elsewhere in a compound path are checked against one another and nothing more: a pair among them that decodes as a transaction proves nothing about this transaction either way (vector S14).

Partial material is reported. A statement exists to say what is missing, so an Atomic BEEF that lacks an ancestor is read and the gap is named. Refusing it would leave a receiver that holds partial evidence no way to say so. Bytes that are wrong in themselves, such as an unrelated entry in an Atomic BEEF, a txid twice or a path BRC-74 does not permit, are refused.

Bounds refuse. A walk cut short would report unresolved inputs for a reason a reader cannot see. A statement longer than a reader's bound is refused unread, so a maker refuses to emit one longer than its own, and one recommended value for both keeps a maker and a reader that use it in agreement.

Status apart from evidence. Broadcast, relay and mining are events the maker observes, and the evidence fields are checks it ran. Keeping them apart stops a report of the first kind standing in for the second. mined is the one status the evidence itself supports, so it is the one status derived from it. The tip is named so that a reader can check the depth, and the lock-time verdict, against its own headers.

Test Vectors

The vectors were generated from code by the reference implementation, never typed.

Common inputs: the header source is the table below and its tip is 950,010, unless a vector says otherwise; madeAt is 1793318400 (2026-10-30T00:00:00Z); the Genesis and Chronicle activation heights are mainnet's, 620,538 and 943,816, and every block here is at height 949,999 or above, so every output is created, and every input judged, under the rules in force after both; the maker's bounds are 1000 transactions, a distance of 100, 32,000,000 bytes of material and 1,000,000 bytes of statement unless a vector says otherwise; the maker validates unless a vector says "distance only"; status is received and conflicts is not checked unless a vector says otherwise; a reader's bound is 1,000,000 bytes unless a vector says otherwise. The headers are synthetic: the header source is an input of each vector, so no proof of work is needed. Every key is the secp256k1 secret SHA-256(payment evidence test vector: + label), and every signature uses RFC 6979 nonces. The keys are test keys and protect nothing.

Keys

Every output pays P2PKH to the payer key, and every input is signed by it with SIGHASH_ALL | SIGHASH_FORKID, except as follows. BADSIG's signature is by the not the payer key. The second output of A6 is locked with 8d5487 (OP_2MUL OP_4 OP_EQUAL), and X6 spends it with 52 (OP_2). T64 is exactly 64 bytes: its input's unlocking script is 51515151 in place of OP_TRUE, and its only output has an empty locking script, which P64 spends with 51 (OP_TRUE). TL and TLATE carry lock times given as a time, 1793002399 and 1793002400, with sequence 0xfffffffe. A transaction that carries a Merkle path spends output 0 of a transaction whose txid, in internal byte order, is SHA-256(payment evidence test vector: + its name), with the unlocking script OP_TRUE; only the conflict check of section 2.1 reads that input (vector M20). T01's output value is the first from 100,000 up that puts 01 at byte 4 of its txid in internal byte order. DS spends A1 output 0 and, with OP_TRUE, the outpoint A1 itself spends. Z4, txid 3721db44eccd6e28b0b7cb36cbab33dbdb1f8643603f4d437ace61442800466b, is spent by P4 and held by no maker. CF and CFU each have a first output of 0 satoshis locked with 006a046366747815019d57f040e087001d86955e34665a10eef59c654f, which begins 006a0463667478, so each is a confiscation transaction: CF is mined, and CFS spends its second output; CFU spends A1 output 0.

Header source

Vectors S11 and M12 use a header source that holds the 11 blocks ending at the tip: the table above plus a header at height 950000, block hash a7259cbb2bde89b111fb6b7a61f1ce9ebeb2088db84f2f1e00933598fa4e9f23:

00000020d50cbe4fa99f43bdcd39efc070f7635f17b65aa6cb99fd70be0f3b6375213c42a59eb7b873142035ddceaee8caa686bb7ece1e9ee4ab72e2ba46314439191194e8ffde6affff7f2000000000

Their median time past is 1793002400. The table alone holds no header at height 950000, so it gives no median time past.

Vector M22 uses a header source that is the table above plus the block of CF, at height 949,999, block hash 18fb1eb3ef350fad0145f44278a930e575156e6c8ebc168738328453508c6afb:

000000200b21c7e7ebd8f56f14cf86e3184298b27152624f94d981c89691a359265aba67d5a41d520d3d2ba29119cbde4eb4adc93e164d822ea42243404d87501a16466990fdde6affff7f2000000000

Transactions

Merkle paths

Each anchored transaction is in a block of its own, as the leaf at pos; the other leaves are SHA-256(payment evidence test vector: filler + height + + index), except as follows. In the block of A8, the leaves at 2 and 3 are the first and the last 32 bytes of T64. In the block of T01, the leaf at 3 is R, 0000000000000000000451515151ffffffff0100000000000000000000000000 (internal byte order), so that T01's txid in internal byte order followed by R decodes as a transaction. The Electrum form gives pos and the siblings bottom-up; the BRC-74 path is its conversion (section 6).

Four vectors use a path other than the conversion:

Material

An Atomic BEEF here is 01010101, the subject's txid in internal byte order, and a BRC-62 V1 BEEF (0100beef) carrying the paths listed, in order, and then the transactions listed, in order, each anchored one with the index of its path. Where a vector says V2, the BEEF is a BRC-96 V2 BEEF (0200beef) in the same order, each anchored transaction in format 01 with its path's index, each one listed as txid only in format 02, and each other in format 00. Its length and SHA-256 confirm the bytes. Records are raw transactions and Electrum-form paths, by name, from the tables above.

Statements

Equality: identical bytes of the canonical form.

S1: distance 1, every check run

• Material: Atomic BEEF of P1: paths A1; transactions A1 (path 0), P1; 433 bytes, SHA-256 63b6ac11d00e79ad817f1942305428d0114c0ce79f0e9224cae3df1be26079f0.
• Inputs: status handed-to-broadcaster; a conflict check at 1793318340, kind own-node, scope unconfirmed, found false.

{"anchors":[{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001,"txid":"2c0746d0edc5d2afb97495acbcc4584087bdc07027360aa03b28cbf40e6ee344"}],"conflicts":{"at":1793318340,"checked":true,"found":false,"kind":"own-node","scope":"unconfirmed"},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":{"bytes":192,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"handed-to-broadcaster"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"e2127516adc12a98fdc758e7d6ab36c38505cb6731f6c9b68c3cdc02b3a33896","unconfirmed":["e2127516adc12a98fdc758e7d6ab36c38505cb6731f6c9b68c3cdc02b3a33896"],"unresolved":[],"validated":["e2127516adc12a98fdc758e7d6ab36c38505cb6731f6c9b68c3cdc02b3a33896"],"validation":"all","version":"bsv-payment-evidence/v1"}

S2: a chain of three, every check run

• Material: Atomic BEEF of D2: paths A2; transactions A2 (path 0), B2, C2, D2; 816 bytes, SHA-256 4dfaa602f47e4720d77226c76f49576775c06442aca3a7df4a02ba9c9fa4b6ac.

{"anchors":[{"blockHash":"64a53adabc6a36de2c5176485d47e64c06f56d1b588e638ba8c7d349bdc459fc","height":950002,"txid":"ecd202a719806cfd5e5a5d768878512bc440a3239e49708a7ab4ea98bc618ee6"}],"conflicts":{"checked":false},"distanceMax":3,"distanceMin":3,"fullyAnchored":true,"lowestFeeRate":{"bytes":191,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","unconfirmed":["04f2afb7c402d0f1d33759631f1375d95a6f641d40d554336ad5a9fba668239a","83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","8e16699f0cd9d4b020d71caaeeed19e4a07c03f4fcdfb08c09d3f55ee594695c"],"unresolved":[],"validated":["04f2afb7c402d0f1d33759631f1375d95a6f641d40d554336ad5a9fba668239a","83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","8e16699f0cd9d4b020d71caaeeed19e4a07c03f4fcdfb08c09d3f55ee594695c"],"validation":"all","version":"bsv-payment-evidence/v1"}

S3: the same chain, distance only

• Material: Atomic BEEF of D2: paths A2; transactions A2 (path 0), B2, C2, D2; 816 bytes, SHA-256 4dfaa602f47e4720d77226c76f49576775c06442aca3a7df4a02ba9c9fa4b6ac.
• Inputs: distance only.

{"anchors":[{"blockHash":"64a53adabc6a36de2c5176485d47e64c06f56d1b588e638ba8c7d349bdc459fc","height":950002,"txid":"ecd202a719806cfd5e5a5d768878512bc440a3239e49708a7ab4ea98bc618ee6"}],"conflicts":{"checked":false},"distanceMax":3,"distanceMin":3,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","unconfirmed":["04f2afb7c402d0f1d33759631f1375d95a6f641d40d554336ad5a9fba668239a","83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","8e16699f0cd9d4b020d71caaeeed19e4a07c03f4fcdfb08c09d3f55ee594695c"],"unresolved":[],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S4: the same chain from the receiver's records, the path in Electrum form, distance only

• Material: records: transactions A2, B2, C2, D2; the Electrum-form path of A2; payment D2.
• Inputs: distance only.

{"anchors":[{"blockHash":"64a53adabc6a36de2c5176485d47e64c06f56d1b588e638ba8c7d349bdc459fc","height":950002,"txid":"ecd202a719806cfd5e5a5d768878512bc440a3239e49708a7ab4ea98bc618ee6"}],"conflicts":{"checked":false},"distanceMax":3,"distanceMin":3,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","unconfirmed":["04f2afb7c402d0f1d33759631f1375d95a6f641d40d554336ad5a9fba668239a","83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","8e16699f0cd9d4b020d71caaeeed19e4a07c03f4fcdfb08c09d3f55ee594695c"],"unresolved":[],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S5: an uneven diamond: longest path 3, shortest 1

• Material: Atomic BEEF of P3: paths A3; transactions A3 (path 0), B3, C3, P3; 999 bytes, SHA-256 8b8bd197f55ef26145ea1fee3a87a32fd38dc98a05498f21a35fc839496d2828.

{"anchors":[{"blockHash":"4ef4e7bfd2500d3ef2c4b89cce091e27feb0f1a82a4ceaca0395f35b9827eda7","height":950003,"txid":"05e134ab77ba252ee5b17bc519fcfc24d23d70bf0c3f40eea65ca43ea53f61fe"}],"conflicts":{"checked":false},"distanceMax":3,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":{"bytes":339,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"215984478daf11bbe5da2cd5946792e2a1247f11f644eb7ed95e49e27ce56da6","unconfirmed":["215984478daf11bbe5da2cd5946792e2a1247f11f644eb7ed95e49e27ce56da6","6a5434d9c86b7a77bfec289f42d0344ff80d904d8542f1001779cad3fabf1b00","96c8a32fb64394dfc9357306687db01d67c8cadd4ae7483f3123f27f8e6e48f1"],"unresolved":[],"validated":["215984478daf11bbe5da2cd5946792e2a1247f11f644eb7ed95e49e27ce56da6","6a5434d9c86b7a77bfec289f42d0344ff80d904d8542f1001779cad3fabf1b00","96c8a32fb64394dfc9357306687db01d67c8cadd4ae7483f3123f27f8e6e48f1"],"validation":"all","version":"bsv-payment-evidence/v1"}

S6: one input whose source is not held, every check run

• Material: Atomic BEEF of P4: paths A4; transactions A4 (path 0), B4, P4; 773 bytes, SHA-256 54b7baac8d64b816291290e1b75c26294433be4ef89ee44328cacb45088dfa35.

{"anchors":[{"blockHash":"ee55e78df915a761c888acb74bf87c5290c24af8a170e8510e7e43f6104e2916","height":950004,"txid":"2749e001f0e6a84653059d4a2404641852717ebd373d935d0ec80b240afd8bae"}],"conflicts":{"checked":false},"distanceMax":null,"distanceMin":2,"fullyAnchored":false,"lowestFeeRate":{"bytes":192,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c","unconfirmed":["6208df575795dfb167aabee64512316b37caf163e0d4bf67b2262cb37997a595","df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c"],"unresolved":[{"txid":"3721db44eccd6e28b0b7cb36cbab33dbdb1f8643603f4d437ace61442800466b","vout":0}],"validated":["6208df575795dfb167aabee64512316b37caf163e0d4bf67b2262cb37997a595"],"validation":"partial","version":"bsv-payment-evidence/v1"}

S7: the same from the receiver's records, distance only

• Material: records: transactions A4, B4, P4; the Electrum-form path of A4; payment P4.
• Inputs: distance only.

{"anchors":[{"blockHash":"ee55e78df915a761c888acb74bf87c5290c24af8a170e8510e7e43f6104e2916","height":950004,"txid":"2749e001f0e6a84653059d4a2404641852717ebd373d935d0ec80b240afd8bae"}],"conflicts":{"checked":false},"distanceMax":null,"distanceMin":2,"fullyAnchored":false,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c","unconfirmed":["6208df575795dfb167aabee64512316b37caf163e0d4bf67b2262cb37997a595","df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c"],"unresolved":[{"txid":"3721db44eccd6e28b0b7cb36cbab33dbdb1f8643603f4d437ace61442800466b","vout":0}],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S8: the payment is itself an anchor, its path in Electrum form

• Material: records: transactions E5; the Electrum-form path of E5; payment E5.

{"anchors":[{"blockHash":"ab14e92c0acb7212d9a1219e6c468b0f2c4ee53a7c351486bf99e916dfa1f90f","height":950006,"txid":"ed1c8314bd18dfb4fd9ef30e067899b2719d6df46730470e8ae22e4c8fee67a3"}],"conflicts":{"checked":false},"distanceMax":0,"distanceMin":0,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":5,"event":"mined"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"ed1c8314bd18dfb4fd9ef30e067899b2719d6df46730470e8ae22e4c8fee67a3","unconfirmed":[],"unresolved":[],"validated":[],"validation":"all","version":"bsv-payment-evidence/v1"}

S9: a signature by the wrong key, distance only

• Material: Atomic BEEF of BADSIG: paths A1; transactions A1 (path 0), BADSIG; 433 bytes, SHA-256 078b4cf6087ea739dd9987c131aa1f75b78383c482ccf7cc5eb9885ffe09a694.
• Inputs: distance only.
• Note: For a maker that has not run check 1 on this material. A maker that has run it refuses (M6) and makes no distance-only statement about it (section 2.3).

{"anchors":[{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001,"txid":"2c0746d0edc5d2afb97495acbcc4584087bdc07027360aa03b28cbf40e6ee344"}],"conflicts":{"checked":false},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"664569513982851cb5aefe29541ddf7de327a14206111191b9d5c07bfa59a60d","unconfirmed":["664569513982851cb5aefe29541ddf7de327a14206111191b9d5c07bfa59a60d"],"unresolved":[],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S10: a Merkle path above the header source's tip: not checked, the walk goes on

• Material: Atomic BEEF of D2: paths A2; transactions A2 (path 0), B2, C2, D2; 816 bytes, SHA-256 4dfaa602f47e4720d77226c76f49576775c06442aca3a7df4a02ba9c9fa4b6ac.
• Inputs: the header source is the table cut at its tip, height 950001.

{"anchors":[],"conflicts":{"checked":false},"distanceMax":null,"distanceMin":null,"fullyAnchored":false,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001},"txid":"83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","unconfirmed":["04f2afb7c402d0f1d33759631f1375d95a6f641d40d554336ad5a9fba668239a","83a6965907f29d1b0561a9da97c7fccaf160aa38dbb2a8a5cfad4d5745362db7","8e16699f0cd9d4b020d71caaeeed19e4a07c03f4fcdfb08c09d3f55ee594695c","ecd202a719806cfd5e5a5d768878512bc440a3239e49708a7ab4ea98bc618ee6"],"unresolved":[{"txid":"9ad939dc90a785679522429363796caf013ff87d7c9f357d3937347dad51d22d","vout":0}],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S11: a lock time given as a time, below the median time past

• Material: Atomic BEEF of TL: paths A1; transactions A1 (path 0), TL; 432 bytes, SHA-256 e3bd46b61095b816c1987425c42261de15430961a55a9a9a3e4468264b223291.
• Inputs: the header source is the table plus the header at height 950000 given below it.

{"anchors":[{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001,"txid":"2c0746d0edc5d2afb97495acbcc4584087bdc07027360aa03b28cbf40e6ee344"}],"conflicts":{"checked":false},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":{"bytes":191,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"525c61889807b4ba61f16c1f71f91d6ec30e794c8ff6f8727cf9b986bbc35acf","unconfirmed":["525c61889807b4ba61f16c1f71f91d6ec30e794c8ff6f8727cf9b986bbc35acf"],"unresolved":[],"validated":["525c61889807b4ba61f16c1f71f91d6ec30e794c8ff6f8727cf9b986bbc35acf"],"validation":"all","version":"bsv-payment-evidence/v1"}

S12: the same, without a header the median time past needs: left out

• Material: Atomic BEEF of TL: paths A1; transactions A1 (path 0), TL; 432 bytes, SHA-256 e3bd46b61095b816c1987425c42261de15430961a55a9a9a3e4468264b223291.
• Note: The header source is the table, which holds no header at height 950000, so the median time past of the 11 blocks ending at the tip cannot be computed.

{"anchors":[{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001,"txid":"2c0746d0edc5d2afb97495acbcc4584087bdc07027360aa03b28cbf40e6ee344"}],"conflicts":{"checked":false},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"525c61889807b4ba61f16c1f71f91d6ec30e794c8ff6f8727cf9b986bbc35acf","unconfirmed":["525c61889807b4ba61f16c1f71f91d6ec30e794c8ff6f8727cf9b986bbc35acf"],"unresolved":[],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

S13: a script the maker cannot evaluate: left out, validation partial

• Material: Atomic BEEF of P6: paths A6; transactions A6 (path 0), B6, X6, P6; 872 bytes, SHA-256 b9b3fe3ca0e6d200c60600dff944f8a4be80c74c282608bbdd7e4d21b82aeea5.
• Note: A6 is mined at 950007, above the Chronicle activation height, so OP_2MUL (0x8d) is enabled for its output and X6's input evaluates to true under the rules in force. This vector is for a maker whose interpreter does not implement OP_2MUL, or treats it as disabled: it cannot complete the check, so it leaves X6, and P6, which spends it, out of the validated set. A maker that implements OP_2MUL validates both, and its statement differs (validation all); no vector is given for it.

{"anchors":[{"blockHash":"a036c06c92ea0d49b3b6862932aa4533730bcc711249099595efd41573bd33db","height":950007,"txid":"a7274c4562611d5914aee0f2e991a81176f446ecde0d70eeefe6cfc6404b379b"}],"conflicts":{"checked":false},"distanceMax":2,"distanceMin":2,"fullyAnchored":true,"lowestFeeRate":{"bytes":191,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"420adb2e2fd48ee95bae1e7e972b329a516106e6bfb1b6a321d399561822670f","unconfirmed":["420adb2e2fd48ee95bae1e7e972b329a516106e6bfb1b6a321d399561822670f","6158929cc6db06e57aad638ac4b426e53ab9dc1593e33a5b08eabcae6c26f3eb","c60f7125b095b56b4c703a279599203ccee550bf33811e53617f3c8c44312690"],"unresolved":[],"validated":["6158929cc6db06e57aad638ac4b426e53ab9dc1593e33a5b08eabcae6c26f3eb"],"validation":"partial","version":"bsv-payment-evidence/v1"}

S14: a pair off the anchor's own path that decodes as a transaction: the anchor holds

• Material: Atomic BEEF of P8: paths A8-compound; transactions A8 (path 0), P8; 466 bytes, SHA-256 1467a7df31c392303975b6ddf4268b6fb02f5b0844187d1d7d38f0c05f8b5007.
• Note: Offsets 2 and 3 of A8's path are the two halves of T64's bytes. The fold of A8's own path hashes A8 with offset 0, then their parent with the node computed from offsets 2 and 3, and never that pair, so condition (e) holds.

{"anchors":[{"blockHash":"f954b173e1932e44aafc432a0171c2b4c755f11cd479cf3bae8da4d82bcb87fc","height":950009,"txid":"6ee90c20d3bbd231987e0573f79320f22f9f150a9fa56ec5b5802a99421cd17c"}],"conflicts":{"checked":false},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":{"bytes":191,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"db874543d0c2b32bfe1e38c17a15609285746d278a7abe919e334ae83ee5f98e","unconfirmed":["db874543d0c2b32bfe1e38c17a15609285746d278a7abe919e334ae83ee5f98e"],"unresolved":[],"validated":["db874543d0c2b32bfe1e38c17a15609285746d278a7abe919e334ae83ee5f98e"],"validation":"all","version":"bsv-payment-evidence/v1"}

S15: S6 as a BEEF V2 that carries Z4 by txid only

• Material: Atomic BEEF (V2) of P4: paths A4; transactions A4 (path 0), Z4 (txid only), B4, P4; 806 bytes, SHA-256 018e960e6caeee1fa521da01bf18d91524e13f95ead1704b5557482efa19231f.
• Note: The same statement as S6: a txid-only entry holds no transaction, so the input that spends Z4 is unresolved (section 2.1).

{"anchors":[{"blockHash":"ee55e78df915a761c888acb74bf87c5290c24af8a170e8510e7e43f6104e2916","height":950004,"txid":"2749e001f0e6a84653059d4a2404641852717ebd373d935d0ec80b240afd8bae"}],"conflicts":{"checked":false},"distanceMax":null,"distanceMin":2,"fullyAnchored":false,"lowestFeeRate":{"bytes":192,"satoshis":50},"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c","unconfirmed":["6208df575795dfb167aabee64512316b37caf163e0d4bf67b2262cb37997a595","df3f2029548cb31866c12a73d1ff6da9e3515acf66ce6c145ef34ce2e2ef9d6c"],"unresolved":[{"txid":"3721db44eccd6e28b0b7cb36cbab33dbdb1f8643603f4d437ace61442800466b","vout":0}],"validated":["6208df575795dfb167aabee64512316b37caf163e0d4bf67b2262cb37997a595"],"validation":"partial","version":"bsv-payment-evidence/v1"}

S16: a payment that is a confiscation transaction: left out, validation none

• Material: Atomic BEEF of CFU: paths A1; transactions A1 (path 0), CFU; 470 bytes, SHA-256 9235e27de1c705025668181fd6113f2ad27e82952b3d8c761b4cc3d0abac0aeb.
• Note: CFU's first output begins 006a0463667478, so CFU is a confiscation transaction, which SV Node accepts only when it is whitelisted. A maker cannot know the whitelist, so it cannot complete the checks on CFU: CFU is left out, and not refused (section 2.3).

{"anchors":[{"blockHash":"d73120d63050557443631be249d95eaaae2ee72d05375d199b9d8d33e34c5e9e","height":950001,"txid":"2c0746d0edc5d2afb97495acbcc4584087bdc07027360aa03b28cbf40e6ee344"}],"conflicts":{"checked":false},"distanceMax":1,"distanceMin":1,"fullyAnchored":true,"lowestFeeRate":null,"madeAt":1793318400,"status":{"depth":null,"event":"received"},"tip":{"blockHash":"e125c62d3654c2f138f1c39bb74c56181e6d325c38844fd30cc1939d701c493a","height":950010},"txid":"b93c53d9615c0a2bf6f72791a41abc329d70944630f4fd5dc894fd6c5cf5418c","unconfirmed":["b93c53d9615c0a2bf6f72791a41abc329d70944630f4fd5dc894fd6c5cf5418c"],"unresolved":[],"validated":[],"validation":"none","version":"bsv-payment-evidence/v1"}

Refusals by a maker

Equality: a refusal with the code shown, and no statement.

M3's input, in full:

0101010144e36e0ef4cb283ba00a362770c0bd874058c4bcac9574b9afd2c5edd046072c0100beef00feffffffff01000000010ddbe8f7bd041d50ea45fa1d9abc6c62fc35e5e91cb1ef61d2c3ba08c72a75ea000000000151ffffffff01a0860100000000001976a9149b0cc517962e22315ce8b46fd4fdd02db0bab31988ac0000000000

M4's header source is the table above with the header at height 950001 replaced by:

000000206b0d72cc817bdfe98bc0ccb64c9c8c0a70774fe82939b6a50cff8db0fce17353fbac2f5d9533c2686ccf4c05aeb9bd51ed9e5ea108156765378a6e1209a309424002df6affff7f2000000000

Conversion of an Electrum-form branch

The anchor of S8, transaction E5 (txid ed1c8314bd18dfb4fd9ef30e067899b2719d6df46730470e8ae22e4c8fee67a3), is at index 4 of a block of five, so its branch repeats the working hash at two levels:

{"block_height":950006,"merkle":["ed1c8314bd18dfb4fd9ef30e067899b2719d6df46730470e8ae22e4c8fee67a3","6b157ae9550c8fac7e5aab7c7121162e30ae5cb397a4bd97a661df741d2fcd44","9655485f14b20de881eefc0d22692ea5c3d9b724db6afe9206fbeb30eb5885b8"],"pos":4}

Its BRC-74 path, byte for byte:

fef67e0e0003020402a367ee8f4c2ee28a0e473067f46d9d71b29978060ef39efdb4df18bd14831ced0501010301010000b88558eb30ebfb0692fe6adb24b7d9c3a52e69220dfcee81e80db2145f485596

Level 0 holds E5 at offset 4 (flag 02) and offset 5 with flag 01; level 1 holds offset 3 with flag 01; level 2 holds offset 0 with flag 00 and its hash. The same branch with pos 12 leaves a bit over after its three siblings: refused MALFORMED. A branch of 65 siblings, its three repeated, with pos 0, is longer than any BRC-74 tree: refused MALFORMED.

Refusals by a reader

Equality: a refusal with the code shown. Each input is a change to the bytes of a statement above, S1 unless the change names another.

Signature

The receiver key signs the canonical bytes of S1 as a BRC-77 message verifiable by anyone, with the key ID pinned to 571fc1f4ed6fafc9cfaa07f77e12149cd95a29f5981bb4633f6f39e47397df19 (the maker draws it at random). Equality: identical bytes.

4242330103fb1aaf51797cd0551feeeacb42dfd98be2bbcd072e6d9445d3a2620b103c3adc00571fc1f4ed6fafc9cfaa07f77e12149cd95a29f5981bb4633f6f39e47397df193045022100d6baa4f0054d9235a8f9fcdd059c83b7360f4a058e0bc397796c466323c2434a02207733ce0babc4ec3cd64200ff2843428939f0a62eb18d6b27b0b1c84b2f147ba9

It verifies over the bytes of S1, and does not verify over the bytes of R3, the same object with one space added.

Implementations

A reference implementation exists: a module of a wallet that makes a statement from an Atomic BEEF or from the wallet's records, in either mode, converts Electrum-form branches, and reads statements. Its script checks run on the interpreter of the wallet's existing BEEF verifier, the one its incoming payments pass, and it counts an input as passed only when that verifier accepts it. That interpreter predates Chronicle, so the implementation leaves out, and never refuses, a transaction whose script uses an opcode Chronicle restored or a signature with the sighash bit 0x20, or a transaction of version 2 or above whose script fails there. It does not implement the relative lock times of section 2.3, check 3, either, and leaves out a transaction that needs one.

Security Considerations

A statement is not a guarantee. A fully anchored payment with validation all has valid spends from proven coins to the payment. It can still go unmined: a conflicting spend may reach miners first, or its fee may be too low for them. A statement records evidence; the receiver's own policy decides whether to accept the payment.

Who made it. A statement says what its maker checked. An unsigned statement from the payer, or from any party with an interest in the payment being accepted, is no evidence: relying on it is relying on that party's word. A receiver makes its own statement from the material, or reads one from a maker it trusts, signed (section 7) when it has travelled.

The header source. An anchor is only as good as the header that confirms it. A source that serves headers whose proof of work nobody checked lets whoever controls it turn any Merkle path into an anchor. A maker SHOULD use headers whose proof of work it has checked. A reader of another party's statement can check the tip and each anchor's height and block hash against its own headers.

A 64-byte transaction. A block header does not say how tall the block's Merkle tree is, and the txid of a 64-byte transaction is computed as an inner node of the tree is, the double SHA-256 of 64 bytes. That allows two attacks, and the anchor definition closes each. In the first, two sibling inner nodes, read together as a transaction, have a Merkle path to the real root: whoever orders a block's transactions can search for an order in which such a pair also parses as a transaction with an output anyone can spend. Condition (d) closes it, since a 64-byte transaction is never an anchor. In the second, a real 64-byte transaction is mined, and its two halves are offered as the bottom step of a path one level taller, so that a transaction whose txid is the first half appears proven; vector M19 builds that shape, a txid with 01 at byte 4 beside a sibling that completes a transaction. Condition (e) closes it, since no step of the own path may hash 64 bytes that decode as a transaction. Neither condition alone is enough. No ordinary payment needs a 64-byte transaction, which has 4 bytes for all of its scripts together. A miner who orders a block can place beside an honest transaction a sibling it searched for, so that the transaction's path fails (e); that payment is then refused, never wrongly accepted.

Bounds. A payment can have very many ancestors, and every script costs time to evaluate. A maker bounds the material's size in bytes and the walk before it does that work (section 2.1), and a maker that evaluates scripts for others SHOULD also limit the work each script may do. Reaching such a limit leaves a transaction unvalidated; it is never a refusal (section 2.3). A statement grows with the payment, since each unconfirmed transaction and each unresolved input adds an entry: one transaction of hundreds of thousands of inputs whose sources are not held gives a statement of tens of megabytes. A maker bounds the statement it emits, and a reader the bytes it parses, at 1,000,000 bytes by default for both (sections 2.1 and 5).

Frozen outputs. SV Node refuses a transaction that spends an output on its freeze lists (validation.cpp L2596-L2607). No header carries those lists, so the checks of section 2.3 do not cover them: a validated transaction can spend a frozen output and never be mined.

Observations age. found: false held at time at, a status held at madeAt, and the depth at tip. A later conflicting spend or a later block changes none of those fields.

The method as an oracle. An application that may call the method of section 8 with any txid could learn which transactions the wallet holds, if the wallet answered calls it has not permitted otherwise than calls about a transaction it does not hold. Section 8 gives both the same error. With atomicBEEF, the status is received unless the payment is an anchor, and a conflict check is one made for that call, so the answer depends on the bytes, the wallet's headers and that check, and on nothing the wallet's records hold.

Privacy. A statement lists txids of the payment's ancestry, and a signed one links the maker's key to the payment. A maker SHOULD give a statement only to whom the user chose, such as the application that asked about that payment.

Not tested

• No mainnet or testnet run: the vectors use synthetic headers without proof of work.
• A second implementation, written from this document over @bsv/sdk 1.10.4, shares no code with the reference, but it reads the same vectors file and has the same author. On this revision it agrees with every vector, S1 to S16, M1 to M25 and R1 to R22, with the conversion and the signature, and with the document's own tables and material descriptions, 71 checks in all; a randomised pass over altered materials, paths, branches and statements found no fault. None has been run over the Go or Python SDKs.
• No vector covers the maturity of a coinbase output, an output created before Genesis or before Chronicle, a relative lock time before Genesis, a transaction of version 2 or above, or a signature with the sighash bit 0x20.
• Confiscation and freezing: M22 spends a confiscation output before it matures, and S16 leaves out a confiscation transaction. No vector spends a confiscation output once mature, and none covers a frozen output, since no maker here holds a freeze list.
• Vector S13 is for a maker whose interpreter lacks OP_2MUL. No maker that implements it has been run on that material, and the statement such a maker would make is not given.
• No vector holds an ancestor beyond an anchor in an Atomic BEEF.
• No reorganisation was run. Vector M4, a header whose Merkle root differs from the path's, has the shape of one.
• No wallet offers the method of section 8, so no application has called it, and no capability manifest has declared it. The reference implementation makes the statement for its atomicBEEF argument, without the method's errors.
• The conversion of section 6 has not been run on branches fetched from a live Electrum-protocol server.
• No conflicting-spend observation was made: the vectors record the fields only.
• The bounds on statement length are exercised at one value each: the reader's in R18 and the maker's in M25.
• No wallet that reports ancestry distance today, BREAD in ElectrumSVP included, has produced a statement.

References

• BRC-9: Simplified Payment Verification (step 9, on payment channels).
• BRC-62: Background Evaluation Extended Format (BEEF) Transactions.
• BRC-67: Simplified Payment Verification.
• BRC-74: BSV Unified Merkle Path (BUMP) Format.
• BRC-77: Message Signature Creation and Verification.
• BRC-95: Atomic BEEF Transactions.
• BRC-96: BEEF V2, Txid Only Extension.
• BRC-100: Wallet-to-Application Interface (its Backwards Compatibility Contract, error structure and parameter errors).
• BRC-179: Signed Capability Manifest for Wallet and Tool-Server Method Exposure (sections 5 and 7.2).
• BRC-205: Extensible Wallet Version Strings and Account Labels (section 6).
• SV Node at commit 6504a3aff65ba97c0f6c80962b033e35ecbfed4b, for the activation heights, the era of OP_2MUL, the height of an output created in the mempool, coinbase and confiscation maturity, confiscation transactions, frozen outputs, and relative lock times before Genesis: src/chainparams.cpp L18-L23, src/script/interpreter.cpp L360-L372, src/consensus/consensus.h L75-L79, src/validation.cpp L272-L273, L2562-L2636, L2667-L2696 and L3463-L3468, src/frozentxo_db.cpp L614-L636 and src/policy/policy.h L247-L255; and its v1.2.0 release notes, on Chronicle: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0
• ElectrumSVP 0.2.0-beta.1 release notes, on BREAD: https://github.com/TruthMachine/ElectrumSVP/releases/tag/v0.2.0-beta.1
• ElectrumSVP 0.2.0 release notes, for the name BREAD: https://github.com/TruthMachine/ElectrumSVP/releases/tag/v0.2.0
• The Electrum protocol, blockchain.transaction.get_merkle: https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain-transaction-get-merkle
• BIP 68, relative lock times: https://github.com/bitcoin/bips/blob/6ac8c268704a479bdf65fad642c46d43cf19677e/bip-0068.mediawiki
• RFC 2119 and RFC 8174: key words. RFC 6979: deterministic ECDSA nonces.