BRC-64

Overlay Network Transaction History Tracking

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.

Ty Everett7 Aug 2023changed 1 May 20262 min read

Why: Overlay networks tracked only the current live set of UTXOs (Unspent Transaction Outputs), with no standard way to recover what a spent coin used to be or how it got there.
What: BRC-64 is a standard for tracking the transaction history of overlay network outputs by extending how BRC-22 topic managers mark inputs for retention and how BRC-24 lookup services return ancestry data.
How: Topic managers flag which spent inputs to keep as coinsToRetain (and optionally coinsRemoved) when admitting a transaction under BRC-22, and BRC-24 lookup services respond to history queries with BEEF whose Transaction.inputs[].sourceTransaction chain a client can walk to rebuild prior states.

What this lets you do

Mark which spent inputs a topic manager should retain for history
Distinguish coins removed from the live set from coins kept for lookups
Query a lookup service for earlier versions of a UTXO
Reconstruct a UTXO's lifecycle by walking sourceTransaction ancestry in returned BEEF
Drop the older BRC-36 envelope approach in favor of BEEF-based history

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-64 accurately, including what it depends on.

The specification

Read the original

Abstract

This document proposes a solution for tracking transaction histories within UTXO-based overlay networks by extending the BRC-22 submission result model to identify which spent topical coins should be retained for history and by extending BRC-24 lookup behavior to return BEEF that preserves source-transaction ancestry. This allows clients to traverse the lifecycle of topical outputs directly from returned transaction data. The older notion of extending BRC-36 JSON envelopes is now historical and is not the current interoperable mechanism.

Motivation

BRC-22 successfully enables the tracking and synchronization of UTXOs across various topics in overlay networks, yet it does not accommodate the preservation of UTXO histories which can hold valuable network data. Transaction histories are key to understanding the full lifecycle of UTXOs, acting as a crucial component for certain applications in areas like network analysis and auditability. The absence of a history tracking standard leads to information gaps, preventing a comprehensive understanding of network state changes. This document presents a solution to this problem by providing a clear and standardized mechanism for maintaining and accessing transaction histories in UTXO-based overlay networks.

Specification

We introduce extensions to the BRC-22 and BRC-24 standards to encapsulate the input history of network transactions. Topic managers in BRC-22 can prescribe which transaction inputs should be conserved and linked with admitted transaction outputs, designating inputs pertinent for later history traversal. BRC-24 lookups then return enough BEEF to reconstruct those relationships.

Changes to the BRC-22 Standard

Topic managers in overlay networks now perform the following additional steps:

Verify the inputs from the transaction tagged with their topic labels to determine their relevance.
Return coinsToRetain input indices for any spent topical predecessors that should remain queryable for history.
Optionally return coinsRemoved input indices for spent topical predecessors that are removed from the live topical set.
Preserve enough transaction ancestry to later reconstruct source transactions for those retained historical coins.

Changes to the BRC-24 Standard

The lookup services specified under BRC-24 can now:

Accept queries for the previous renditions of specific UTXOs (formats for these queries depend on the specific lookup service).
Assemble and return BEEF sufficient to reconstruct the responsive outputs and their ancestry.
Optionally associate service-defined context bytes with each returned output when that helps identify the role of a historical rendition.

Current SDK-side historical reconstruction is performed by traversing Transaction.inputs[].sourceTransaction ancestry. Implementations that wish to support interoperable history traversal SHOULD therefore ensure that returned BEEF is rich enough for clients to rebuild this chain.

Implementation

Developers should adapt their existing BRC-22 based systems to collect and preserve pertinent transaction inputs when admitting new transaction outputs. Lookup services following BRC-24 should return BEEF with sufficient ancestry for clients to traverse historical state transitions. The older BRC-36-envelope approach SHOULD be considered deprecated for new interoperable implementations.

Was this helpful?

Summary