# Graph Aware Sync Protocol

Ragnar Friedman <ragnar.friedman@proton.me>

## 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.

## Status Note

This document is an exploratory graph synchronization proposal. It is not the current wallet-toolbox user wallet storage synchronization protocol. Current wallet-toolbox storage synchronization is the chunked, resumable storage-provider protocol specified by [BRC-40](/outpoints/0040.md). Current transaction exchange and wallet APIs generally use BEEF / Atomic BEEF rather than the bloom-filter INV flow described here.

## 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bsv.brc.dev/transactions/0076.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.