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
  • Participants
  • Protocol Steps
  • Security Measures
  • Notes
  • Conclusion

Was this helpful?

Edit on GitHub
Export as PDF
  1. Transactions

Graph Aware Sync Protocol

PreviousBSV Unified Merkle Path (BUMP) FormatNextScalable Transaction Processing in the BSV Network

Last updated 1 year ago

Was this helpful?

Ragnar Friedman

Abstract

GASP is designed to synchronize transaction data between two parties in a blockchain environment. It ensures the legitimacy and completeness of transaction data using a recursive reconciliation method.

Participants

  • Alice: Initiates the sync process.

  • Bob: Responds and participates in the sync process.

Protocol Steps

  1. Initialization

    • Alice starts by sending a bloom filter containing all current spendable TXID+VOUTs as elements.

  2. Receiving and Building List

    • Bob receives the filter and builds a list of his items that are not members of the set.

  3. Transaction Verification

    • Bob sends an INV (Inventory) message to Alice for each item not in the set.

    • The INV includes:

      • Output, transaction, and associated merkle proof.

      • Any metadata (such as labels, descriptions, or local timestamps) associated with transactions or outputs.

      • A list of VOUTs spent by its inputs and associated metadata hashes.

      • The preimage for each hash, including all metadata and the merkle proof or broadcast response.

  4. Alice's Response

    • For each INV, Alice responds with a list of input transactions she does not know about.

    • If Alice has the transaction but the metadata hash differs, she requests updated metadata.

    • If Alice lacks the transaction, she requests the entire transaction.

  5. Recursive Transaction Sync

    • Bob responds to Alice's requests with an INV containing the encompassing transaction, done recursively.

      • When including the full transaction, all metadata is provided.

      • When only metadata is included, it encompasses the list of spent VOUTs and associated metadata hashes.

  6. Error Handling and Recovery

    • In case of errors, affected transactions are ignored and not synced.

    • If errors prevent a party from fully anchoring transactions back to the blockchain, these transactions are ignored.

    • Failures experienced by one party are not communicated to the other due to the declaratory nature of the protocol.

  7. Finalization of Sync

    • The process continues until there are no more INVs for Bob to send.

    • Once complete, all of Bob's records are considered synced with Alice.

  8. Role Reversal

    • The roles reverse, with Bob sending Alice a bloom filter.

    • The parties then exchange data in the other direction, following the same steps.

Security Measures

  • Verification of merkle proofs and the longest chain of block headers.

  • Recursively requesting information until all inputs are fully proven.

  • Invalidating transactions that cannot be linked back to a valid proof.

Notes

  • The protocol is adaptable to various blockchain environments.

  • The recursive nature ensures thorough and complete data synchronization.

  • The protocol emphasizes security, efficiency, and data integrity.

Conclusion

GASP offers a robust and secure method for synchronizing transaction data between parties in a blockchain network, leveraging recursive data exchange and thorough verification mechanisms.

ragnar.friedman@proton.me