Vision to Reality 5: Conceptualizing the Future

The main purpose of the Bitcoin Cash blockchain is to maintain a ledger of unspent outputs and their locking scripts. As a result, the XO templating system supports a very wide set of usecases ranging from the simplest P2PKH payment to complex multi-step smart contracts. This article explains some of the core XO concepts that either do not exist in traditional wallets, or are handled differently in XO.

---

mindmap
  root )Responsibilities(

    [INVITATIONS]
      (Connects)
        📱 Apps
        👛 Wallets
        👥 Users
      (Coordinates)
        ⚡ Actions
        🧩 Variables
        📥 Inputs
        📤 Outputs

    [TEMPLATES]
      (Describes)
        🧩 Variables
        💸 Transactions
        📥 Inputs
        📤 Outputs
        🏷️ Lockscripts
      (Defines)
          ⚡ Actions
          💸 Transactions
          💾 Data

    [ENGINE]
      (Generates)
        🔑 Keys
        🪪 Identities
        ✉️ Invitations
        💸 Transactions
      (Manages)
          🤫 Secrets
          🧩 Variables
          📤 Outputs
          🏷️ Lockscripts

Introduction

In previous articles of this series, we have covered many different technical aspects of the XO ecosystem. While doing so, we have touched on various concepts as needed to provide context. Over time, these concepts have become more clear and better structured.

We also have many concepts that we have not yet talked about, so this will be both an introduction to new concepts, as well as clarification on previously mentioned ones.

Concepts

Origins

When working in any new system, it can sometimes be unclear where data comes from.

In the XO templating system, new data can only be introduced by explicit instructions in templates.

These instructions tell the XO engine to:

• create new data (generate: statements inside intents),
• provide existing data (variables: and secret: statements inside intents) or
• expect manual provision of data from users (variables: and secret: inside requirements.)

Intents

The XO templating system is capable of producing a number of different data structures such as transactions, outputs and locking scripts.

The request structure used to create such things is called an intent.

In the context of template writing, intents tell the XO engine what roles and data to start with for things such as start and follow-up actions, default change outputs and default receiving locking scripts.

Actions

Actions in XO define things one can do. When an action is executed, it results in a data structure, usually a transaction to be broadcast to the Bitcoin Cash network.

Actions comes with requirements and responsibilities that must be fullfilled. Some requirements can be fullfilled by any party, and some are responsibilities carried by a specific party.

State

Many usecases expect information to be stored and available for later follow-up actions. In XO templates, state is defined in the state: section on outputs.

Such templated state is then stored only with the output it is tied to, and is not available in any other context than the output definition. In order to access this state later, it has to be explicitly propagated in one of the outputs follow-up actions.

After an output is spent, associated template state is archived and can later be pruned to reclaim storage space.

It is also possible for an application to manually tell the engine to store and manage custom state, and the engine automatically creates and manages some state on its own.

While all state is treated the same under the hood, in order to clarify the context for each case they are categorized into templated state, engine state and application state.

Invitations

Invitations are data structures used to coordinate actions. They are created with minimal information, and then participants commit additional details to the invitation until all information required by the action is available.

An invitation is complete when it has all required information, including block-chain related requirements such as signed inputs. When an invitation is complete, it can be used to execute the coordinated action by any party.

Commits to an invitations have an expiration time after which one should not assume the data within the commit to remain valid.

If an invitation with expired commits has all data required to execute the action it is still technically possible to attempt to complete the action.

Reservations

Resources are automatically reserved by the XO engine when included in a commit to an invitation.

Reservations expires if not used within a limited amount of time. It is not possible to create a reservation for an already reserved resource.

It is also possible to manually make or remove a reservation for a given resource.

Reservations in the XO system do not provide hard guarantees and only keep the local instance of the XO engine from making conflicting commitments.

Eventual Consistency

The XO engine operates on the Bitcoin Cash blockchain and across networks, both of which provide no guarantees for handling race conditions or data delivery.

As a result, the XO engine operates on a principle of eventual consistency, where all data is pending by default, and gets finalized over time. State is handled in an append-only setup and the most recent version of any data is computed from its history. This allows multiple separate engines using the same underlying seed to eventually agree on the aggregate state, but it also means that there are expected to be periods of time where they have, and operate on, stale or pending data.

This also applies to blockchain state, where the blockchain itself manages the eventual consistency.

Discovery

When the XO engine creates transactions and outputs they are tagged according to the action in the template used to create them, and carry full information and state.

However, the XO engine is also responsible for monitoring activity on all locking scripts it creates. When new or unknown activity is detected, it starts with no understanding of the activity and simply stores the blockchain data structures, then tags the transaction outputs with the template and locking script identifiers. An output that does not have a tag for its output definition instead inherits the default output declaration, if defined in the locking script it relates to.

Such unknown activity can come from things like airdrops or privacy invasive dusting attacks, but they can also happen when two or more wallets use the same seed and one of them creates a new transaction. The initiating wallet then has full state and information, while the other wallets see new unknown activity. If synchronized they will later come to an eventual consistency and use the properly defined data for the activity.

Synchronization

In a state based system like XO, loss of information can lead to loss of funds. Therefor, it is important that state is replicated and stored in multiple places to avoid single points of failures.

Since state in XO is being continously generated with activity, it is not feasable to make manual state backups. Doing so would mean making a new state backup every time new information is created, or risk losing funds when that new information is lost.

As a result, XO uses a state synchronization feature that automatically replicates encrypted information to configured services, as well as to local storage.

This means even some template-level "secrets" are synchronized this way, but in XO private keys are never synchronized directly. Instead, the derivation information needed to recreate the keys from the account's root entropy is stored in the state.

By default, the XO engine will refuse to operate under non-safe conditions where there is no state storage, or where state replication is insufficient.

Backups

Traditional BIP-32 or BIP-44 compliant wallets usually make backups through a set of 12 or 24 words as defined in BIP-39.

This allows recovery of all necessary information to restore access to funds, but does not allow recovery of metadata, documentation or smart contract state information.

XO uses BIP-39 seed phrases to create and recover XO accounts, but goes further by using derived keys to encrypt state before replicating through synchronization services.

This allows XO to provide a backup experience similar to traditional wallets while still being able to fully recover all state and metadata in a reasonably safe and private manner.

Accounts

It is common in traditional wallet applications to provide users access to more than one wallet. The term wallet in this context usually refers to either a key (for single-key wallets), a root entropy (for BIP32 based wallets) or a derivation path based off a single shared root entropy (common in multichain wallets).

As a result, the term wallet is ambigous and XO instead uses accounts that correspond to a single root entropy, similar to other BIP-32 based wallets.

This means that an application using the XO stack can work with multiple accounts, each with its own unique history, state and metadata.

Composition

Composition in XO refers to taking multiple actions at the same time, such that they are executed together in a single transaction, even though each action would normally have resulted in a separate transaction.

The main value of composition is atomic execution, but safe execution is not always possible and composition is currently not supported in the engine. Further, we know this is a very difficult thing to do safely and as a field is something that is not yet well-explored.

When it does get implemented, we expect all actions to be restricted from composition by default. Even when explicitly allowed, if there are irreconcilable restrictions between two or more transactions, that would still prevent them from being composited.

Note that even complex usecases with multiple locking scripts usually do not need composition as the usecase's template defines exactly how to safely handle those interactions.