Overlay Network Transaction History Tracking

Ty Everett ([email protected])

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.