3.2. Single-use-seals

This proof of publication medium can be of a different nature, including centralized forms, like a newspaper from the example in previous chapter. However, in RGB we are interested only in using decentralized medium, which has to be censorship-resistant, like a bitcoin blockchain – and we need a form of cryptographic commitment which can achieve the properties of proof-of-publication. This form was, again, proposed by Peter Todd as a “single-use-seal”: a commitment to make a future commitment such that it can be proven that no alternative commitment can be ever created.

Existing cryptographic commitment primitives does not allow to create "two-level" commitments, whether at initial stage a committer commits to commit to a certain (potentially yet unknown) message in the future, once and only once. Given a trustless way of performing verification of such commitments the primitive may be a basic building block for creating decentralized, private and censorship-resistant state machines and smart contracting systems which will be protected from "double-spend" attacks. Analogous to the real-world, physical, single-use-seals used to secure shipping containers, a single-use-seal primitive is a unique object that can be closed over a message exactly once. In short, a single-use-seal is an abstract mechanism to prevent double-spends.****

Single-use-seal cryptographic primitive was proposed by Peter Todd in 2016 as an abstract concept developing idea of timestamps further. LNP/BP Standards Association have developed an application of the single-use-seals to bitcoin transactions, which allows multiple independent protocols to use the same transactions for the single-use-seal operations without knowledge of each other. This construction is called “deterministic bitcoin commitments” and is defined in a series of LNPBP standards (___).

Briefly, bitcoin transaction output-based single-use-seals (TxO seals) is a particular application of single-use-seals to bitcoin transaction graph, either as a part of any bitcoin blockchain (longest PoW chain, federated sidechain etc) or state channel (Lightning network channel and other types of state channels), i.e. in terms of single-use-seals, seal medium is represented by a bitcoin transaction graph.

The parties running protocol agree on some transaction output in any given bitcoin transaction graph as a place with special meaning ("seal"), and require that a future transaction spending this output ("witness transaction") contained a deterministic bitcoin commitment to some a message. Any independent party having access to the transaction graph MUST:

1. not be able to detect the presence of the commitment in a given transaction graph (hiding property of TxO seals) even if the original message is known,

2. being provided information about specific protocol used for message commitments and access to deterministic bitcoin proof data (see LNPBP-8) be able to verify the commitment such as it will be valid only and only for the message with which the original commitment was created (verifiably property of TxOSUS).

The defined procedure is not the only way in which bitcoin blockchain or transaction graph can be used as a seal medium for single-use seals (for instance, a seal may be defined as a first time some specific public key appears in the blockchain); however these options are not part of the current standard.

Seal or defined seal: Bitcoin transaction outpoint: a combination of transaction identifier (consensus-defined double SHA256 hash of fully-signed valid bitcoin transaction) and transaction output number. Transaction output number MUST be represented as a 32-bit unsigned integer1.

Witness transaction: transaction spending an output specified by a given seal.

Closed seal: a seal for which a transaction spending output matching seal definition is known. This transaction MAY be part of longest block chain, or MAY not be a part of it (existing only within a Lightning network channel or as a part of any other off-chain transaction graph). It's up to particular implementation to decide whether such transaction (named witness transaction) should be considered valid or not; however this rules MUST require that the witness transaction MUST be a valid bitcoin transaction (i.e. it can be validated with libbitcoinconsensus or Bitcoin Core instance).

Defined seal consists of 256-bit consensus-defined double SHA-256 hash of a fully-signed valid bitcoin transaction (transaction identifier, “txid”) and 32-bit transaction output index. The transaction identifier may be skipped if a new seal is defined within the witness transaction closing another seal, such that the txid is not known; however in such case protocols (like RGB) must provide guarantees that the witness transaction is deterministically and non-ambigius defined.

Seal must be considered defined only and only all of transaction data are known, the transaction is fully signed and both transaction structure and signatures validated with bitcoin consensus rules using Bitcoin Core — or is a part of most recent signed state of a state channel (like in Lightning Network, using trusted lightning node).