Comment on page
Vertical: Cryptographic primitives
Author: Peter Todd
Type: Standards Track
Based on: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
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
Verifyfunction 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$:
)→$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.