Crate single_use_seals

Source
Expand description

§Single-use-seals

Set of traits that allow to implement Peter’s Todd single-use seal paradigm. Information in this file partially contains extracts from Peter’s works listed in the “Further reading” section.

§Single-use-seal definition

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.

A single-use-seal implementation supports two fundamental operations:

  • Close(l,m) → w — Close seal l over a message m, producing a witness w.
  • Verify(l,w,m) → bool — Verify that the seal l was closed over message m.

A single-use-seal implementation is secure if it is impossible for an attacker to cause the Verify function to return true for two distinct messages m1, m2, when applied to the same seal (it is acceptable, although non-ideal, for there to exist multiple witnesses for the same seal/message pair).

Practical single-use-seal implementations will also obviously require some way of generating new single-use-seals:

  • Gen(p)→l — Generate a new seal based on some seal definition data p.

§Terminology

Single-use-seal: a commitment to commit to some (potentially unknown) message. The first commitment (i.e., single-use-seal) must be a well-defined (i.e., fully specified and unequally identifiable in some space, like in time/place or within a given formal informational system). Closing of a single-use-seal over message: fulfilment of the first commitment: creation of the actual commitment to some message in a form unequally defined by the seal. Witness: data produced with closing of a single use seal which is required and sufficient for an independent party to verify that the seal was indeed closed over a given message (i.e.б the commitment to the message had been created according to the seal definition).

NB: It is important to note that while it is possible to deterministically define was a given seal closed, it yet may be not possible to find out if the seal is open; i.e., seal status may be either “closed over message” or “unknown”. Some specific implementations of single-use-seals may define a procedure to deterministically prove that a given seal is not closed (i.e., opened), however, this is not a part of the specification, and we should not rely on the existence of such a possibility in all cases.

§Trait structure

The main trait is SingleUseSeal, which should be implemented for a single-use seal data type. It references component types for seal witness SealWitness, which are a published witness PublishedWitness and a client-side witness ClientSideWitness.

§Sample implementation

Examples of implementations can be found in the bp::seals module of bp-core crate.

§Further reading

Structs§

NoClientWitness
Some single-use seal protocols may not distinguish client-side seal closing witness and have just the published one. To use SealWitness type in such protocols, the SingleUseSeal must set its SingleUseSeal::CliWitness to NoClientWitness type.
SealWitness
Seal closing witness, consisting of published and client-side parts.

Enums§

SealError
Errors indicating cases of failed single-use seal verification with SealWitness::verify_seal_closing and SealWitness::verify_seals_closing procedures.

Constants§

LIB_NAME_SEALS
Strict type library name for single-use seals.

Traits§

ClientSideWitness
A client-side part of the seal closing witness SealWitness.
PublishedWitness
A published part of the seal closing witness SealWitness.
SingleUseSeal
Trait for the types implementing single-use seal protocol, composing all their components (seal definition, message, and seal closing withness) together, and implementing the logic of the protocol-specific verification of the seal closing over the message (see Self::is_included).