LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Introduction
  • Background
  • Discussion: Hash Chains versus Dependent Transactions

Was this helpful?

Edit on GitHub
Export as PDF
  1. State Machines

Simplifying State Machine Event Chains in Bitcoin

PreviousOutputs, Overlays, and Scripts in the Mandala Network

Last updated 1 year ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

Abstract

This document explores an alternative approach to managing long chains of events on Bitcoin's blockchain: using a single non-final transaction coupled with a hash chain, rather than creating lengthy chains of dependent transactions. By incrementing sequence numbers and including the hash of preceding events in subsequent events, this approach significantly reduces computational requirements and transaction costs while preserving auditability. The inherent security of hash chains further ensures the integrity of event chains, making this method more efficient and reliable compared to the conventional approach.

Introduction

The proliferation of blockchain technology, especially Bitcoin, has spawned a myriad of innovative use-cases. A prominent one is tracking long chains of events on the blockchain to create an auditable, immutable record. Historically, this has been achieved by creating chains of dependent transactions, where each event in the chain corresponds to a spend of a Unspent Transaction Output (UTXO) that represents the event chain. While effective for some use-cases, this model encounters challenges when applied to very large sequences of events. It also imposes significant computational burdens on network nodes, resulting in escalating transaction costs.

In this document, we propose a more efficient and cost-effective method to achieve the same objectives by utilizing a simple hash chain within a non-final transaction, rather than creating long chains of dependent transactions. The primary advantage lies in its ability to deliver the same benefits - traceability, auditability, and immutability - with reduced complexity and cost.

Background

Bitcoin's blockchain technology is essentially a distributed ledger that stores a chain of blocks, each containing a list of transactions. A long chain of dependent transactions is a model in which every event in an event chain is appended as a new transaction consuming and recreating a UTXO.

The UTXO (Unspent Transaction Output) model is used in Bitcoin to track ownership of coins. In this model, transactions consume one or more UTXOs and create one or more new UTXOs.

A hash chain is a succession of data hashes where each hash contains the hash of its predecessor. This creates an immutable sequence, as altering any element in the chain would necessitate recomputing all following hashes, a computationally impractical task.

Discussion: Hash Chains versus Dependent Transactions

In our proposed model, rather than appending each new event as a spend of a UTXO, a non-final transaction is created for the entire chain of events. The first event is put into an output of the transaction, and for each subsequent event, the sequence number is incremented, and a hash of the previous event is included in the new event. Consequently, the transaction is continually updated with new events, building a hash chain. The final output includes the final event's data and the hash of the previous event.

This method implies that only one transaction is registered on-chain, but anyone with the correct set of events can easily validate that the events in the chain were properly recorded. No one can tamper with the set of events in the chain because this would break the hash chain. This method simplifies the recording of long chains of events on-chain, without the need for large sets of dependent transactions.

The key advantages of this approach are:

  1. Computational Efficiency: Creating a hash chain within a single transaction drastically reduces the computational load compared to creating a long chain of dependent transactions. This efficiency directly translates to a reduction in transaction costs and improved scalability.

  2. Integrity and Security: The immutable nature of the hash chain ensures the integrity and security of the event sequence. Any attempts to alter the events would disrupt the hash chain, making tampering evident and practically impossible.

  3. Auditability: Similar to the traditional approach, the proposed method preserves the ability to trace back and validate the history of each event in the sequence. This auditability is essential for many applications of blockchain technology.

  4. Reduced Complexity: By consolidating the event chain into a single transaction, the process is simplified and more manageable. This reduction in complexity not only improves efficiency but also makes it easier for users and developers to interact with and understand the event chain.

  5. Scalability: As the number of events in the chain grows, the relative benefit of using this approach over dependent transactions increases, making it a more scalable solution for large event chains.

In conclusion, by replacing long chains of dependent transactions with a single non-final transaction and a hash chain, we present a more efficient and cost-effective approach to record long chains of events on Bitcoin's blockchain. This model exhibits the same traceability, auditability, and immutability as the conventional approach but with significantly reduced complexity and transaction costs. This simplification of event chains on Bitcoin offers promising potential for a wide array of applications, including smart contracts, supply chain tracking, and digital identity verification. As blockchain technology continues to evolve, the exploration and adoption of such innovative solutions will be crucial for improving efficiency and scalability.