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
  • Motivation
  • Argument

Was this helpful?

Edit on GitHub
Export as PDF
  1. Opinions

Security and Scalability Benefits of UTXO-based Overlay Networks

Ty Everett (ty@projectbabbage.com)

Abstract

Various methods exist for keeping track of systems that derive their state from the Bitcoin network. Some architectures require all parties to have awareness of all transactions to prevent divergence in their computed view of the state. This leads to the need for trust in centralized indexing systems, as it is not feasible for end-users to be aware of all transactions at scale. This BRC argues that UTXO-based overlay networks offer a more secure and scalable approach to managing these states.

Motivation

While indexers can't forge transactions or signatures that never existed, they can potentially withhold pertinent information from clients. When higher-order application states are computed by these indexing systems and served to clients, the clients must trust that the indexers are providing all relevant information without omission. In these systems, there is no intrinsic way to link causal events or updates (multiple future transactions could constitute future direct updates according to arbitrary rules), and no mechanism exists for clients to effectively reconcile the state and chain of events with the rest of the network without trust. This is in contrast to a UTXO-native approach, where clear rules state that only a single future event (the spend) can ever constitute an update.

Argument

There are several advantages to UTXO-based overlay network architectures. These include:

  • Double-spend prevention: Miners ensure that at most one potential future input can ever consume a given output. Knowledge of a given output constitutes knowledge that at most one future input will ever consume such output, updating the state.

  • Clients stay in sync: Clients are kept in sync with the rest of the network for several reasons:

    a. Any attempt to mutate the state of the network will either succeed or be immediately rejected by the miners if it is a double-spend.

    b. In case of a double-spend, it is possible to discover the spending transaction which the client was previously unaware of, and take it into account for future operations.

    c. The client does not need to trust an indexing system to provide the latest state; if old data or an incomplete chain of spends is provided, the client will easily be made aware by miners if they attempt to spend already-spent UTXOs.

  • Reduced data processing: Clients need only be aware of the specific UTXOs pertinent to their interactions, giving them knowledge of the specific spending constraints that can later constitute updates to their data. They rely on miners to guard against double spends, benefiting from an inherently reliable way to reconcile state in the event they do occur.

UTXO-based overlay networks provide a more secure and scalable approach to overlay network design that removes the need for trusted blockchain scanning systems while ensuring network participants don't need to process all data themselves. This results in a more efficient and trustless way of managing states derived from the Bitcoin network.

PreviousLegitimate Uses for mAPINextImproving on MLD for BSV Multicast Services

Last updated 1 year ago

Was this helpful?