Comment on page

LNPBP-8: Single-use-seals

LNPBP: 0008
Vertical: Cryptographic primitives
Title: Single-use-seals
Author: Peter Todd
Status: Proposal
Type: Standards Track
Created: 2017-12-05
Finalized: 2021-11-16
Based on:
License: CC0-1.0


A single-use-seal is an abstract mechanism to prevent double-spends. The current proposal defines core single-use-seal terminology and procedures which must be supported and implemented according to this guidelines by any specific single-use-seal implementation.


Concept of single-use-seal was developed as a result of research work on cryptographic commitments, consensus protocols in distributed systems and client-side-validation [1, 2, 3, 4].


Existing cryptographic commitment primitives does not allow to create "two-level" commitments, whether at initial stage a commiter 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.


For a given data structure $l$ providing single-use-seal definition and a message $m$ single-use-seal implementation MUST support two fundamental operations:
  • Close seal $l$ over message $m$, producing a witness $w_l$:
  • 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. Secondly, authentication is generally useful. Thus we have:
  • Generate a new seal bound to pubkey p:
  • Close seal $l$ over message $m$, authenticated by signature $s$ valid for pubkey $p$:
    Obviously, in the above, pubkey can be replaced by any cryptographic identity scheme, such as a Bitcoin-style predicate script, zero-knowledge proof, etc.
  • Finally, while some single-use-seal implementations MAY support the ability to prove that a seal is open, e.g. as of a given block height or point in time. This however is optional, and as it can be difficult to implement, it is suggested that seal-using protocols SHOULD avoid depending on this functionality existing.


An obvious single-use-seal implementation is to simply have a trusted notary, with each seal committing to that notary’s identity, and witnesses being cryptographic signatures produced by that notary. A further obvious refinement is to use disposable keys, with a unique private key being generated by the notary for each seal, and the private key being securely destroyed when the seal is closed.
For a scalable, trust-minimized, single-use-seal implementation we can use a proof-of-publication ledger, where consensus over the state of the ledger is achieved in a trust-minimized manner (i.e. Bitcoin blockchain).

Reference implementation

The reference implementation is version 1.0 of single_use_seals crate, which is a part of the client-side-validation library developed and maintained Dr Maxim Orlovsky at LNP/BP Strandards Association.
If the implementation differs from the spec, the spec has a higher priority.


  1. 1.
    Peter Todd. Preventing Consensus Fraud with Commitments and Single-Use-Seals
  2. 2.
    Peter Todd. Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication.
  3. 3.
    Peter Todd. Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance.
  4. 4.
    Peter Todd. Building Blocks of the State Machine Approach to Consensus.
This document is licensed under the Creative Commons CC0 1.0 Universal license.