LNPBP-8: Single-use-seals
Last updated
Last updated
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$:
Close($l$,$m$)→$w_l$
Verify that the seal $l$ was closed over message $m$:
Verify($l$,$w_l$,$m$)→bool
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:
Gen($p$)→$l$
Close seal $l$ over message $m$, authenticated by signature $s$ valid for pubkey $p$:
Close($l$,$m$,$s$)→$w_l$
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).
If the implementation differs from the spec, the spec has a higher priority.
This document is licensed under the Creative Commons CC0 1.0 Universal license.
The reference implementation is version 1.0 of , which is a part of the developed and maintained Dr Maxim Orlovsky at LNP/BP Strandards Association.
Peter Todd. Preventing Consensus Fraud with Commitments and Single-Use-Seals
Peter Todd. Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication.
Peter Todd. Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance.
Peter Todd. Building Blocks of the State Machine Approach to Consensus.